Design guidelines

So far we have explored how procedure can improve the success rate of FPGAbased prototyping with the various teams. Let’s now summarize more technical recommendations, many gathered from other places in this book but some introduced here in this overview for the first time. The following table, which is split across two pages, summarizes the main technical recommendations for the whole SoC project team to follow in order make FPGA-based prototyping a more productive part of the project.

Summary of technical recommendations in Design-for-Prototyping.png

Follow modular design principles

Modular design is an architectural approach to design wherein special attention is given to creating simple, reusable, and individually distinct functional units to more effectively address the goals of the project. Modular design can and should be utilized from early in the project specification all the way through design and even in the prototyping flow itself. Good modularity in the original RTL structure will affect the prototyping effort.

One example of a modular approach (which has bearing on the prototyping effort) is the specification and design of multiple modular channels. These could be scaled up or down to more or fewer channels, and enable single-core operation of a multi-core (or multi-processor) design. Another example is enabling culling of logic that is not conducive to FPGA adaptation, and considering how this might be accomplished in a way that is simple for the prototype designer without interrupting other project goals.

There are almost always test modes, experimental clock modes, and atypical clock modes that are not required by the prototype. Frequently, it is reasonable to remove them using stub files, or by replacing registers with constants, etc., and then allowing synthesis to cull the coupled logic. The implementation in the flow might utilize ifdef’s, libraries, code generators, or constraint files (via RTL modification tools which enable the designer to preserve the purity of the original RTL, but maintain the flexibility to better accommodate the prototyping flow).

The creation of stub files can also be very helpful to the prototyping effort as well as other aspects of the design process when implemented on other functional units. Typically a stub file will consist of whatever interface logic is required to enable the function of the rest of the SoC. In many cases, this may just be a set of constants and pass-through signals to appropriately drive the default values of outputs.

Recommendation: use modular coding style with technology-independent logic elements. Introduce target technology elements only at leaf level or at well-defined functional blocks.

Create simple modules

Beyond just using generic logic, it is important to keep the design modules simple and small. Try to avoid making the code excessively general purpose. An RTL design can have excessive complexity when designers attempt to make a module so flexible that it becomes virtually unusable in any specific context. The design of state machines is another example where keeping it simple can be helpful. Some state machine designs span across many pages of case/if statements. This type of design is indecipherable to anyone but the original designer, weak for reuse, prone to error, and difficult to modify. If these machines also include the write-address mechanism for a large register file, it will be very difficult to modify the code in a way that will make the most efficient use of FPGA memory.

Refactoring is another important concept to consider in the SoC design process. Refactoring simplifies code through small redesigns when problems are discovered with the architecture, interfaces, etc. This can include reorganizing functional blocks or dataflow, redefining interfaces or bus protocols, and so on. Refactoring frequently includes extracting common code from one or more blocks and implementing it with more singularity of purpose (often in a single block or function).

Pre-empt RTL changes with ‘define and macros

The RTL code will need to be modified in some areas for the target technology implementations and this needs to be done in a manner to isolate the change while FPGA-Based Prototyping Methodology Manual 279 preserving the original structure. A good method to pre-empt prototyping changes is to use `define and `ifdef macros. Standard macro names could be adopted and these should be listed in the company-wide source style guide along with guidelines for their usage. In that way a single macro definition at the top-level or in synthesis scripts can be used to allow or mask a large number of RTL changes made to the prototype. Example uses of a macro could be for isolating BIST or memory instantiations.

Avoid latches

While latches can be implemented in the FPGA, they can be inefficient and cause complications in timing analysis. For example, latch-based designs can be used to achieve a lower power SoC but will not be correctly processed by the synthesis FPGA technology mapping tools because the power-saving behavior is not fully modeled in the original RTL.

If latches or FFs could be used to the same effect in the SoC then we should try to use FFs instead of latches; it will simplify the adaptation of the RTL for prototyping. One way to accommodate this type of design is to automate the implementation of latches after the synthesis of a gate-level netlist based on FFs. This may be done on the entire chip, or on an as-needed basis for specialized blocks that require latches. In the later case, it may simplify the task if steps are taken to isolate or otherwise mark the sequential elements requiring conversion.

Avoid long combinatorial paths

If the SoC is designed to be used with the latest technology library then it is very possible that there might be 30 or more levels of logic in some combinatorial paths between sequential elements. This may be perfectly permissible in SoC designs where these levels can be placed very close together and have intrinsically low delay in any case. In an FPGA the logic in these paths will be rationalized as much as possible and mapped into look-up tables (LUTs) but nevertheless, some ten or more LUTs may be needed to create the same critical path. The delay of the LUT is not such a problem as that of the interconnect between them, which might be difficult for the place & route tool to keep short, especially if there are many such paths or the FPGA utilization is too high.

If long paths are expected in the SoC design then it would be preferable if these could be broken into sub-paths by the use of pipelining, which would require some rescheduling in the design.

Avoid combinatorial loops

Combinatorial loops can cause unpredictable behavior in general. Intentional loops to create oscillators or state elements should be replaced with black boxes that can be mapped to technology specific implementations later in the flow.

Unintentional loops can result from incomplete RTL, for example, when not all values are specified in case statement or else statements are missing from if trees or even if default conditions are missing inside always blocks. These would all be caught by even the most superficial simulations, but synthesis tools may generate logic with unintended behavior in these situations.

Loops are sometimes not seen in SoC RTL because of bottom-up design flow and the loops are only completed when the whole design is assembled top-down. Potentially, this first top-down assembly may only occur at the start of a prototyping project. (Note that synchronizing block boundaries eliminates this and many other pitfalls.)

The behavior of circuits containing feedback loops is dependent upon propagation delays through gates and interconnections. Due to process variation and temperature effects, such circuits may be unstable in a given technology and should be avoided.

By carefully re-specifying the logic definition to clearly state the desired function will usually eliminate the combinatorial loop.

Provide facility to override FFs with constants

Consider the possibility of overriding registers with constants wherever possible to increase the adaptability of the SoC design. Examples include configuration registers, such as those used for test modes, experimental clock modes, and atypical clock modes.

These can be implemented with `ifdef macros, code generators, stub files, or constraint files. The synthesis tool will then propagate the constants-eliminating logic that can cause difficulties in the prototyping flows. This can be useful for ATPG flows that are not based on post processing a gate-level netlist and the elimination of clock muxes tied to unused clock configurations, etc. An approach to constant forcing should be taken which leaves the RTL source intact for later use in SoC implementation.