Bugs Be Gone!

Debugging big designs
Probing all signals is out of the question in a big design, since the amount of data generated would be astronomical and the amount of additional debug logic required to probe the data too great. A common problem with on-chip debug methodologies is that it can be difficult to predict ahead of time which signals to probe and monitor.

Some debug software solves this problem to a degree by allowing you to take a divide-and-conquer approach. Multiplexed sample groups allow designers to selectively sample and switch between groups of signals through a multiplexed path and shared IICEs. This strategy increases the signals and conditions that you can observe without increasing data storage requirements. You can switch between signal groups of interest on the fly, without having to spend time re-instrumenting, and resynthesize a newly instrumented design.

Unfortunately, the very debug IICE logic that enables you to probe and sample data will consume chip resources, including memory Block RAMs. You can reduce on-chip BRAM usage by storing IICE sampled data off-chip in SRAM memory cards. This approach has the added benefit of increasing the depth of sample data that you can capture.

My design won’t synthesize
Design errors may be occurring that prevent a clean synthesis and P&R run. Thousands of RTL and constraint source files can turn that first successful synthesis and place-and-route run into a multiweek endeavor. When performing FPGA-based prototyping, it is necessary to render ASIC design source files “FPGA ready.” One example is the need to achieve gated clock conversion.

Gated clock structures in an ASIC that you may be prototyping in an FPGA are not necessary in the FPGA implementation, and cause inefficient use of FPGA resources. An efficient way to deal with this problem is to have the FPGA synthesis software convert the clocks. For example, a gated/generated clock-conversion feature will move generated clocks and gated clock logic from the clock pin of a sequential element to the enable pin. This allows you to tie sequential elements directly to the source clock, removing skew issues and reducing the number of clock sources required in the design, saving resources.

To enable the Gated Clocks option in the Synplify Premier software:

• Select Project->Implementation Options
• On the GCC & Prototyping Tools tab, click on the Clock Conversion checkbox

Or in TCL, the command
set_option -fix_gated_and_generated_ clocks 1

performs gated and generated clock conversion in Synplify Pro/Premier, while
set_option -conv_mux_xor_gated_clocks 1

performs gated-clock conversion on muxes or OR gates in the clock tree in Synplify Premier for Synopsys HAPS-based designs.

A “complete” set of clock constraints includes having the clock defined in all the correct places and having defined relationships between the generated clocks. Clock conversion may fail upon the first attempt due to missing clock constraints, where a clock that feeds a sequential element is missing, or due to misplaced clock constraints, in which a clock has become disassociated from its true source for some reason, such as the creation of a black box between the clock source and its destination. In many cases, the failure to convert is due to incomplete constraints. For example, there might be a combinatorial loop in the gating logic that needs to be broken via an exception constraint before clock conversion can occur. A Gated Clock Report, available after the compile stage of synthesis, tells you which gated and generated clocks converted and their clock name, type, group and associated constraints. Another list of clocks that did not convert contains an error message explaining why. Figure 2 shows an example of the report.


If, for example, there are black boxes in your design, you can assist automated gated clock conversion further by specifying software-specific directives in your RTL. For example, by using the syn_gatedclk_clock_en directive you can specify the name of the enable pin within a black box, while the syn_gatedclk_clock_en_polarity directive indicates polarity of the clock enable port on a black box. Each converted instance and clock pin driving the instance is assigned a searchable property and can thus be identified in the design database and extracted into a custom TCL/Find script-generated report.

Port mismatches
A design can include files that originate from multiple sources both inside and outside of your company. When instantiating IP or preverified hierarchical blocks in a design, “port mismatch” specification mistakes are a common problem and can be difficult to fathom, especially when they occur in mixed-language designs. For example, if a top-level VHDL entity “Top” instantiates a Verilog module “sub,” the top-level VHDL declares sub to have 4-bit ports whereas the actual Verilog module only has 3-bit ports. Synplify Premier software, for example, will flag a mismatch immediately and cite it in a separate log report as a hyperlinked error:

Interface Mismatch between View work.sub.syn_black_box and View work.sub.verilog
Details:
========
 The following bit ports in the Source View work.sub.syn_black_box do NOT exist in the Target View work.sub.verilog
=========================================
    Bit Port in1[4]
    Bit Port in2[4]
    Bit Port dout[4]

With multiple levels of hierarchy, how do you trace the mismatch back to the offending module’s RTL definition? It is necessary for the tool to tag all module instances in some way, for example with an orig_inst_of property. The property’s value contains the original RTL name of the module for easy reference back to the RTL. Suppose, for example, an instance of sub called sub_3s incurs a port mismatch error. You can retrieve the RTL module’s original name, “sub,” using the following TCL commands:

get_prop -prop orig_inst_of {v:sub_3s}

which returns the value “sub”