Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
1,731 Views

Qsys-generated .SDC files for HPS generate zillions of warning messages

I have a Qsys design named "soc_system" which instantiates the HPS. This is a Cyclone V SOC, running Quartus Prime 17.0. 

 

When generating HDL, Qsys seems to be outputting two SDC files: soc_system_hps_fpga_interfaces.sdc and soc_system_hps_hps_io_border.sdc. Both these files seem to be automatically included in the project under soc_system.qip. Both of these files generate compile warnings on every single line, thereby resulting in hundreds and hundreds (and hundreds more) spurious warning messages completely clogging my compile reports. Examples: 

 

On soc_system_hps_hps_io_border.sdc, the first warnings look like this: 

Warning (332174): Ignored filter at soc_system_hps_hps_io_border.sdc(1): hps_io_hps_io_emac1_inst_TX_CLK could not be matched with a port 

Warning (332049): Ignored set_false_path at soc_system_hps_hps_io_border.sdc(1): Argument <to> is an empty collection 

    Info (332050): set_false_path -from * -to [get_ports hps_io_hps_io_emac1_inst_TX_CLK] 

 

 

 

 

The rest are similar. The reason is that my top-level ports are not named that way. Those names reflect the names of the ports to the soc_system.v module. 

 

On soc_system_hps_fpga_interfaces.sdc, the first warnings looks like this: 

Warning (332174): Ignored filter at soc_system_hps_fpga_interfaces.sdc(3): *fpga_interfaces|f2sdram~FF_3768 could not be matched with a register 

Warning (332049): Ignored set_false_path at soc_system_hps_fpga_interfaces.sdc(3): Argument <from> is an empty collection 

    Info (332050): set_false_path -from [get_registers {*fpga_interfaces|f2sdram~FF_3768}] 

 

Here I have less insight into the nature of the problem. 

 

 

I am not clear if this is normal, or if it's an indication that there's something wrong in my design or on my project configuration, or what I can do about it. Anyone have any insight?
0 Kudos
5 Replies
Altera_Forum
Honored Contributor I
144 Views

Hmm, I just looked and saw that they are specifically included in the Timequest settings. Maybe I should just remove them? But I'd like to understand them better before I start trying stuff at random.

Altera_Forum
Honored Contributor I
144 Views

I am not that familiar with this topic, however yesterday I read that if .sdc files are part of the .qip "library", they should not be included in the TimeQuest settings as well. See the Quartus Handbook vol 3 https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/hb/qts/qts_qii5v3.pdf page 7-57 or page 106 ("If SDC files for IP blocks in your design are included through with a .qip, do not re-add them manually.")

Altera_Forum
Honored Contributor I
144 Views

Something is messed up with your HPS peripheral I/O settings. Go back to the HPS parameter editor in Qsys and check the I/O sets you are using for the particular peripherals you want to use. Look and see if you see any warnings in the parameter editor that might help figure this out. 

 

Also, have you made I/O connections in the Pin Planner? You say you are not using those names, but then what are you naming everything? Are you assigning other signals in the design to I/O pins reserved for the HPS?
Altera_Forum
Honored Contributor I
144 Views

 

--- Quote Start ---  

Something is messed up with your HPS peripheral I/O settings. Go back to the HPS parameter editor in Qsys and check the I/O sets you are using for the particular peripherals you want to use. Look and see if you see any warnings in the parameter editor that might help figure this out. 

 

Also, have you made I/O connections in the Pin Planner? You say you are not using those names, but then what are you naming everything? Are you assigning other signals in the design to I/O pins reserved for the HPS? 

--- Quote End ---  

 

 

For soc_system_hps_hps_io_border.sdc, the problems seems to be that I didn't name my pins the way Qsys expected me to. So it generated, for instance,set_false_path -from * -to [get_ports hps_io_hps_io_inst_emac1_TXD0] 

 

 

Whereas I named that pin more rationally to hps_emac1_TXD0. My short term fix was to edit that SDC file after each Qsys generate, swapping "hps_io_hps_io" for simply "hps", and getting rid of "_inst_". That fixes it, since then the SDC file matches my pin names. The problem is that it's another step I need to take after running Qsys generate (even if it's scripted). There are other ways I could handle it too, all with varying pluses and minuses. Like, I could rename all my pins to match the ones Qsys expects. That would really be the solution, even if I'd have to live with all those hideous pin names. I'll probably give in and do that eventually. 

 

Since the interior workings of the HPS are rather opaque from a Qsys standpoint, I don't believe there's any straightforward way to change the names of the various interfaces it uses when exporting its I/O. So I'm pretty much left with taking what it gives and making the best of it. 

 

 

Soc_system_hps_fpga_interfaces.sdc remains a mystery. The comment at the top of the file says 

# These false paths fix a problem with the HPS timing library for the F2SDRAM bridge. 

# This issue only affects timing analysis. There are no functionality problems with the bridge 

 

 

Sounds fine, but none of the set_false_path assignments ever match anything in my design. For a while I was just commenting out all the lines in the file until I realized that I could more easily nuke all the warnings withe message suppression manager, using the file name as keyword. Solved.
MSchw18
Beginner
144 Views

Hi, did you find an answer to this problem?

I'm having the same issue. My top level pins have reasonable names, but the sdc file keeps getting regenerated. I can get the warnings to go away if I change the names in the sdc file.

Reply