Design Article
Tell us What You Think
We want to know what you thought about this Design. Let us know by adding a comment.
Bugs Be Gone!
Angela Sutton, Synopsys
11/29/2012 2:28 PM EST
Constraints cleanup
Specifying adequate and correct constraints will affect both the quality of results and functionality. Constraints declarations should generally include three components: definition of primary clocks and clock groups; asynchronous clock declarations; and false and multicycle path declarations.
Checking these constraints prior to synthesis is a good idea. A tool with a constraints checker that discovers syntax errors and looks at the applicability of timing constraints and instance names will alert you to problems. It will, for example, report on how constraints will be applied after wild-card expansions, as well as the clock relationships that resulted after you defined clock constraints. It will also flag timing constraints that aren’t being applied due to nonexistent or invalid types of arguments and objects.
To generate a constraints checker report titled projectName_cck.rpt in the Synplify Pro/Premier software, prior to synthesis:
Be sure to also avoid potential meta-instabilities by running an “asynchronous clock report” that will alert you to paths that start in one clock domain and end in another.
To generate the Clock Synchronization Report projectName_async_clk.rpt.csv in the Synplify Pro/Premier software:
Good practices include checking that you have adequately and completely constrained your design without having overconstrained it (which will result in longer runtimes and, potentially, the reporting of false critical paths). Be sure to check that you have completely specified multicycle and false paths, and that you have set constraints on derived clocks (set_multicycle_path, set_false_path).
Shortening the debug time
It can now take multiple hours to see the results of implementing a potential RTL or constraints fix. Let’s examine how to reduce iterations using a combination of hierarchical “divide-and-conquer” design approaches and a continue-on-error (CoE) capability that allows you to uncover multiple errors in a single synthesis iteration.
Block-based flows have become necessary in order to save runtime. These flows also allow for design preservation, or the ability to lock down parts of the design that already work. A tool that supports block-based flows allows you to create RTL partitions, called compile points, prior to synthesis. Some software also enables designers to black-box a portion of the design with errors and completely export that portion as its own separate design subproject for rework. Once fixed, the subproject will be merged back either as a netlist using a bottom-up flow or as RTL using a top-down flow -- or even using a hybrid of both top-down and bottom-up flows.
To integrate and troubleshoot large designs, it is important to find groups of specification errors as early as possible in the design process. For example, a CoE feature provides an aggregate report of errors with each synthesis pass. CoE tolerates nonfatal, nonsyntax HDL compilation problems and certain mapping errors so that designers can analyze and complete as much of the design as possible with each synthesis iteration. To invoke the CoE feature in the Synplify Premier software with the Synplify Pro/Premier GUI, enable the Continue-on-Error checkbox on the left side of the Project View.
With TCL: set_option –continue_on_error 1
Modules containing errors and the parent module of instances that have interface errors are flagged with a property is_error_blackbox=1 and highlighted graphically as shown in Figure 3.
To find all “Erroneous Instances” using TCL: c_list [find -hier -inst * -filter @is_error_blackbox==1]
To list all the “Erroneous Modules” with TCL: get_prop -prop inst_of [find -hier -inst * -filter @is_error_blackbox==1]
To view Erroneous Modules ready for black-boxing or export, look for red boxes in the HDL Analyst RTL View (Figure 3).
Figure 3. The HDL Analyst RTL view highlights modules that contain errors, as well as the parent module of an instance with an interface error, as shown. (Click Here to see a larger, more detailed version of this image).
Isolating problems by exporting a module
You can export modules that have errors as a completely standalone synthesis project in order to perform focused debug of the module. The export process creates an isolated synthesis project containing all of the individual module’s source files, language standard and compiled libraries, including directory paths and the path order for included files, required to synthesize and debug the module on its own. Modules that incur errors are automatically tagged with an error property in the design database, as indicated in the previous section, and are highlighted in the design schematic. This makes it easy to find the modules that you want to extract for rework.
To export a module and all associated source files for debug in isolation, in the Synplify Pro/Premier software GUI (Figure 4), first select a design block or instance in the Design Hierarchy view or RTL view. Then, right click and select “Generate Dependent File List” from the pop-up menu.
Figure 4. Problematic modules in the design can be exported as their own separate synthesis project for rework, allowing you to isolate the problem. (Click Here to see a larger, more detailed version of this image).
As each hierarchical module is fixed you can reintegrate it into the design, either as RTL to be resynthesized in the context of the entire design (top-down synthesis flow) or as a netlist (bottom-up flow) as illustrated in Figure 5.
Figure 5: As working modules become available, they can be re-integrated into the design, using either a top-down (RTL) or bottom-up (netlist-level) integration (Click Here to see a larger, more detailed version of this image).
Meeting timing with the inevitable use of design hierarchies can be a challenge. Hierarchical boundaries may limit performance unless timing budgets are created for each hierarchical partition of the design. Some tools automatically set timing budgets when you use RTL partitions called manual locked compile points. Synplify Pro/Premier software also has automatic compile points that create automatic partitions under the hood, for example for runtime speedup using multiprocessing. The budgeting feature produces interface logic models (ILMs) for each RTL partition, with the result that the software can figure out how to meet timing targets for each partition. You can override manual locked compile point automatic timing budgets by specifying a constraints file for each compile point.
In a recent Global User Survey conducted by Synopsys, 59 percent of designers identified “getting the design specification right” as one of their most significant design challenges. This challenge can translate to design delays and, in worst-case scenarios, design failure. Design tools must adapt to catch errors early and provide greater visibility into the design’s operation so that the specification can be validated and fixed. These tools must also provide a means of feedback on proposed design fixes.
About the author
Angela Sutton is Staff Product Marketing Manager at Synopsys. Angela can be contacted at sutton@synopsys.com
If you found this article to be of interest, visit Programmable Logic Designline where – in addition to my Max's Cool Beans blogs – you will find the latest and greatest design, technology, product, and news articles with regard to programmable logic devices of every flavor and size (FPGAs, CPLDs, CSSPs, PSoCs...).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for my weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you [grin]).
Specifying adequate and correct constraints will affect both the quality of results and functionality. Constraints declarations should generally include three components: definition of primary clocks and clock groups; asynchronous clock declarations; and false and multicycle path declarations.
Checking these constraints prior to synthesis is a good idea. A tool with a constraints checker that discovers syntax errors and looks at the applicability of timing constraints and instance names will alert you to problems. It will, for example, report on how constraints will be applied after wild-card expansions, as well as the clock relationships that resulted after you defined clock constraints. It will also flag timing constraints that aren’t being applied due to nonexistent or invalid types of arguments and objects.
To generate a constraints checker report titled projectName_cck.rpt in the Synplify Pro/Premier software, prior to synthesis:
- Synplify Pro/Premier GUI: Run -> Constraint check
- Or using TCL: project -run constraint_check
Be sure to also avoid potential meta-instabilities by running an “asynchronous clock report” that will alert you to paths that start in one clock domain and end in another.
To generate the Clock Synchronization Report projectName_async_clk.rpt.csv in the Synplify Pro/Premier software:
- Synplify Pro/Premier GUI: Analysis->Timing Analyst and select “Generate Asynchronous Clock Report” check box.
- Using TCL: set_option -reporting_async_clock
Good practices include checking that you have adequately and completely constrained your design without having overconstrained it (which will result in longer runtimes and, potentially, the reporting of false critical paths). Be sure to check that you have completely specified multicycle and false paths, and that you have set constraints on derived clocks (set_multicycle_path, set_false_path).
Shortening the debug time
It can now take multiple hours to see the results of implementing a potential RTL or constraints fix. Let’s examine how to reduce iterations using a combination of hierarchical “divide-and-conquer” design approaches and a continue-on-error (CoE) capability that allows you to uncover multiple errors in a single synthesis iteration.
Block-based flows have become necessary in order to save runtime. These flows also allow for design preservation, or the ability to lock down parts of the design that already work. A tool that supports block-based flows allows you to create RTL partitions, called compile points, prior to synthesis. Some software also enables designers to black-box a portion of the design with errors and completely export that portion as its own separate design subproject for rework. Once fixed, the subproject will be merged back either as a netlist using a bottom-up flow or as RTL using a top-down flow -- or even using a hybrid of both top-down and bottom-up flows.
To integrate and troubleshoot large designs, it is important to find groups of specification errors as early as possible in the design process. For example, a CoE feature provides an aggregate report of errors with each synthesis pass. CoE tolerates nonfatal, nonsyntax HDL compilation problems and certain mapping errors so that designers can analyze and complete as much of the design as possible with each synthesis iteration. To invoke the CoE feature in the Synplify Premier software with the Synplify Pro/Premier GUI, enable the Continue-on-Error checkbox on the left side of the Project View.
With TCL: set_option –continue_on_error 1
Modules containing errors and the parent module of instances that have interface errors are flagged with a property is_error_blackbox=1 and highlighted graphically as shown in Figure 3.
To find all “Erroneous Instances” using TCL: c_list [find -hier -inst * -filter @is_error_blackbox==1]
To list all the “Erroneous Modules” with TCL: get_prop -prop inst_of [find -hier -inst * -filter @is_error_blackbox==1]
To view Erroneous Modules ready for black-boxing or export, look for red boxes in the HDL Analyst RTL View (Figure 3).
Figure 3. The HDL Analyst RTL view highlights modules that contain errors, as well as the parent module of an instance with an interface error, as shown. (Click Here to see a larger, more detailed version of this image).
Isolating problems by exporting a module
You can export modules that have errors as a completely standalone synthesis project in order to perform focused debug of the module. The export process creates an isolated synthesis project containing all of the individual module’s source files, language standard and compiled libraries, including directory paths and the path order for included files, required to synthesize and debug the module on its own. Modules that incur errors are automatically tagged with an error property in the design database, as indicated in the previous section, and are highlighted in the design schematic. This makes it easy to find the modules that you want to extract for rework.
To export a module and all associated source files for debug in isolation, in the Synplify Pro/Premier software GUI (Figure 4), first select a design block or instance in the Design Hierarchy view or RTL view. Then, right click and select “Generate Dependent File List” from the pop-up menu.
Figure 4. Problematic modules in the design can be exported as their own separate synthesis project for rework, allowing you to isolate the problem. (Click Here to see a larger, more detailed version of this image).
As each hierarchical module is fixed you can reintegrate it into the design, either as RTL to be resynthesized in the context of the entire design (top-down synthesis flow) or as a netlist (bottom-up flow) as illustrated in Figure 5.
Figure 5: As working modules become available, they can be re-integrated into the design, using either a top-down (RTL) or bottom-up (netlist-level) integration (Click Here to see a larger, more detailed version of this image).
Meeting timing with the inevitable use of design hierarchies can be a challenge. Hierarchical boundaries may limit performance unless timing budgets are created for each hierarchical partition of the design. Some tools automatically set timing budgets when you use RTL partitions called manual locked compile points. Synplify Pro/Premier software also has automatic compile points that create automatic partitions under the hood, for example for runtime speedup using multiprocessing. The budgeting feature produces interface logic models (ILMs) for each RTL partition, with the result that the software can figure out how to meet timing targets for each partition. You can override manual locked compile point automatic timing budgets by specifying a constraints file for each compile point.
In a recent Global User Survey conducted by Synopsys, 59 percent of designers identified “getting the design specification right” as one of their most significant design challenges. This challenge can translate to design delays and, in worst-case scenarios, design failure. Design tools must adapt to catch errors early and provide greater visibility into the design’s operation so that the specification can be validated and fixed. These tools must also provide a means of feedback on proposed design fixes.
About the author
Angela Sutton is Staff Product Marketing Manager at Synopsys. Angela can be contacted at sutton@synopsys.com
If you found this article to be of interest, visit Programmable Logic Designline where – in addition to my Max's Cool Beans blogs – you will find the latest and greatest design, technology, product, and news articles with regard to programmable logic devices of every flavor and size (FPGAs, CPLDs, CSSPs, PSoCs...).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for my weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you [grin]).
|
|
|
|
|
Navigate to related information