Hi all,
Altera's site has the page "Simplify Design Reuse with Dynamic SDC Constraints"
http://www.altera.com/support/exampl...clock-sdc.html
which intriguingly implies that SDC constraints files can be automated.
How is this useful you ask?
Consider the case of a Qsys component that has an associated set of top-level pin constraints, eg., external device setup/hold requirements and clock-to-output delays, or an asynchronous interface that needs timing paths cut. An automated SDC file would find every instance of the Qsys component in the design, map the ports on each component instance to top-level pins, and then setup constraints on those pins. The Qsys component _hw.tcl file can automatically add the SDC file to the project, and since that SDC script would automatically parse the design, the user does not have to do anything to setup the SDC constraints.
This all sounds nice, but I'm having a hard time using the TimeQuest Tcl API to navigate the design hierarchy.
Caveat/Warning: I searched through all of the .SDC files in the Quartus IP folder and none use the technique described by the Altera link above :(
I did find that the DDR constraints scripts do perform some form of mapping, but they use Tcl API calls that do not appear to be documented (involving netlist atoms).
I've attached a zip file with my current attempts at getting this to work. Rather than using a Qsys system, I created a simplified design containing a registered 2:1 multiplexer (mux_2to1.vhd), along with components that contain instances of that component, or generated instances of that component (because the path name to an instance created with a generate statement is different than a normal instance).
Success: quartus_map and the Tcl ::quartus::rtl package
When I failed to get TimeQuest to do what I want, I decided I would try and figure out how the "RTL Netlist Viewer" was getting the information it displays on the GUI. The attached zip file contains Tcl procedures that implement the mapping from component instance ports to top-level pins. This at least proves the concept is feasible. Unfortunately these packages are not available in TimeQuest (quartus_sta), so pre-flow or post-flow scripts would be required to create an intermediate Tcl file containing the pin mapping.
Not Quite Success: TimeQuest (quartus_sta) and the ::quartus::sdc and sdc_ext packages
The TimeQuest scripts in the zip can be used to find the mapping from the 2:1 multiplexer register clock, reset, and output ports, since those are a 1:1 mapping from the underlying low-level register. However, I cannot figure out how to map the sel, d[0], and d[1] combinatorial input ports on the component to pins in the design. There does not appear to be an API call that can be called with component/entity port names that then map to internal register/cell names. The examples show that you can find the combinatorial dataa, datab, datac, and datad ports on the low-level lookup table, but the connection from these inputs changes for each instance in the design! There is no static mapping ... argh!
The zip file contains a top-level readme.txt file describing how to reproduce my tests.
I look forward to any suggestions anyone has!
Cheers,
Dave
Altera's site has the page "Simplify Design Reuse with Dynamic SDC Constraints"
http://www.altera.com/support/exampl...clock-sdc.html
which intriguingly implies that SDC constraints files can be automated.
How is this useful you ask?
Consider the case of a Qsys component that has an associated set of top-level pin constraints, eg., external device setup/hold requirements and clock-to-output delays, or an asynchronous interface that needs timing paths cut. An automated SDC file would find every instance of the Qsys component in the design, map the ports on each component instance to top-level pins, and then setup constraints on those pins. The Qsys component _hw.tcl file can automatically add the SDC file to the project, and since that SDC script would automatically parse the design, the user does not have to do anything to setup the SDC constraints.
This all sounds nice, but I'm having a hard time using the TimeQuest Tcl API to navigate the design hierarchy.
Caveat/Warning: I searched through all of the .SDC files in the Quartus IP folder and none use the technique described by the Altera link above :(
I did find that the DDR constraints scripts do perform some form of mapping, but they use Tcl API calls that do not appear to be documented (involving netlist atoms).
I've attached a zip file with my current attempts at getting this to work. Rather than using a Qsys system, I created a simplified design containing a registered 2:1 multiplexer (mux_2to1.vhd), along with components that contain instances of that component, or generated instances of that component (because the path name to an instance created with a generate statement is different than a normal instance).
Success: quartus_map and the Tcl ::quartus::rtl package
When I failed to get TimeQuest to do what I want, I decided I would try and figure out how the "RTL Netlist Viewer" was getting the information it displays on the GUI. The attached zip file contains Tcl procedures that implement the mapping from component instance ports to top-level pins. This at least proves the concept is feasible. Unfortunately these packages are not available in TimeQuest (quartus_sta), so pre-flow or post-flow scripts would be required to create an intermediate Tcl file containing the pin mapping.
Not Quite Success: TimeQuest (quartus_sta) and the ::quartus::sdc and sdc_ext packages
The TimeQuest scripts in the zip can be used to find the mapping from the 2:1 multiplexer register clock, reset, and output ports, since those are a 1:1 mapping from the underlying low-level register. However, I cannot figure out how to map the sel, d[0], and d[1] combinatorial input ports on the component to pins in the design. There does not appear to be an API call that can be called with component/entity port names that then map to internal register/cell names. The examples show that you can find the combinatorial dataa, datab, datac, and datad ports on the low-level lookup table, but the connection from these inputs changes for each instance in the design! There is no static mapping ... argh!
The zip file contains a top-level readme.txt file describing how to reproduce my tests.
I look forward to any suggestions anyone has!
Cheers,
Dave