TOOLS OF XCELLENCE
parent clk
II_0(parent) is_verilog = 1 is_error_blackbox = 1 syn_noprune = 1
sub_7_error1 COMPILATION FAILED clk dummy din[7:0] [7:0] out[7:0]
[7:0]
[7:0] [7:0]
din1[7:0]
uut1 din1[7:0]
[7:0]
uut1(sub_7_error1) w=7 is_verilog = 1 is_error_blackbox = 1 syn_noprune = 1
[7:0]
II_0 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.
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 Fourth Quarter 2012
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 continueon-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 Xcell Journal
63