Description

Having experimented with the fan-out controls, we are now seeing issues with buffer insertion, receiving "buffer limit reached" errors. What is the buffer insertion limit and how do you control the number of buffers available?

Would a better strategy be to use the RTL-based fan-out attributes so that the replication occurs in Synplify Pro and less buffers are needed by ACE?

Answer

There are a number of controls that can be used to manage buffer insertion in the ACE GUI, Projects Perspective, Options, Advanced Design Preparation tab:

• "Fanout limit" (default 95) – Sets the overall limit across the design. The corresponding implementation option is fanout_limit.
• "Fanout limit for critical nets" (default 0) –  To enable this feature, set the value to greater than 0 (ideally to a low value such as 10-20). The implementation option name is critical_fanout_limit. With this option enabled, ACE selects the top 20% of critical connections, and then applies this new fan-out limit to them, independent of the value of fanout_limit.  This feature provides the ability to focus in on the relevant nets that require reduced fan-out in order to close timing.

To control the number of buffers inserted, there is a further ACE option (not accessible from the GUI), max_buffer_limit (default varies by device). This option sets the maximum number of buffers inserted during resynthesis and placement. If you experience "buffer limit reached" errors, then this value can be increased; however, the value is customized for each device to offer a balance between fabric resources, and the number of buffers inserted, which reduces available logic.

Note
"Post-PnR buffer limit", accessible under the Place and Route tab is not currently used. Changing this value will not change the number of buffers inserted.

Setting ACE Options

Two of the options described above are available under the ACE GUI. Alternatively any ACE option can also be set in the GUI using the Tcl console with the following command:

# To set implementation options
cmd> set_impl_option <name> <value>

# To read implementation options back
cmd> get_impl_option <name>

Finally, if you are using the Achronix example script or batch flow, these options can be added to the ace_options.tcl file, (under /src/constraints).

Optimal Strategy

To answer the original question, the best strategy is to add fan-out limits in the RTL, for Synplify Pro to then perform any required replication. This method requires fewer buffers inserted by ACE. As a general rule, the better you can make the netlist, the better the final result — quality up front pays off later down the line. Another advantage is that it is generally easier to add constraints to the RTL. However, if your coding standard does not support having specific constraints within the RTL, then the Synplify Pro project FDC file can be used to apply the constraints. See How Do I Control Fan-Out on a Specific Signal? for details on applying these constraints.

With the fan-out limit constraints added, it is easy to view and check the synthesized netlist using the Synplify technology viewer.