Breaking The Three Laws

 

Keeping Your RTL Clean: Part 1

It’s pretty obvious that if we can avoid FPGA-hostility in our designs then the prototype will be ready sooner. However, we can’t expect RTL designers to compromise the final chip design just in order to help us prototypers. So that’s why we advocate Design-for-Prototyping as the way to make the design more robust and portable so that everybody wins.

Most, if not all, chip design teams will work to a given RTL style guide but we wonder how many of those style guides include steps to avoid FPGA hostility. We don’t need the design to include specific FPGA elements or features but at least it should allow us to make use of those in our prototyping efforts without too much extra effort. One sure way to do this is to use wrappers.

What is a wrapper?

The term “wrapper” may mean different things to different people, but we think of a wrapper as an RTL construct that keeps technology-specific design elements from “contaminating” the surrounding RTL. For example, as seen in figure 1, if the chip design calls for the instantiation of a specific leaf cell from the silicon library, then we do NOT write this directly into the RTL. Instead, we declare a new module in the RTL where we need to make the instantiation, and then write the leaf-cell inside that new module (preferably in a separate file). The new module is called a wrapper.

Figure 1: Wrapper contents changed to suit RTL target

This simple step of creating a module sub-hierarchy for the instantiation means that we can change or remove its contents )in this case the particular leaf cell) without having to change the surrounding RTL. It also means that the surrounding RTL is kept technology-independent i.e. is not “contaminated” by the leaf-cell instantiation. After all, it only takes one leaf-cell to make the whole of the RTL at that level technology-specific.

Consider a simple case where the chip design requires that we add a voltage level-shifter on a signal. The designer should NOT instantiate the level shifter cell into the RTL directly, but instead place it in a wrapper and use that wrapper in the RTL. Later, the content of the wrapper could be replaced, for example with a new level-shifter for a different silicon technology i.e. the RTL is already more portable. More importantly from the point of view of a prototyper is that we don’t need level shifters during prototyping, and it is trivial to replace it with a pass-though wire. It is also possible to automate this replacement, and some sophisticated users even have a file-list generation tool which will reference different files with their different definitions of the wrapper module depending on the target technology.

Are wrappers essential?

Figure 2: Certify creates sub RTL for library leaf cell

If you are not lucky enough to receive such nice portable RTL but instead our example leaf-cell is instantiated directly in the RTL, then the work around is to create a new definition for the cell for use during prototyping. You will need to do something anyway, because the FPGA tool chain will otherwise treat the leaf cell as a black box. The good news is that if you have the source .lib file for the silicon technology library which includes the leaf cell definition then the Certify tool from Synopsys will automatically reference the .lib file. Certify will then create functionally equivalent RTL for the leaf-cell and use it in the rest of the FPGA tool flow, as shown in figure 2.

So much for leaf cells; the real power of wrappers comes when we can agree an internal style and naming policy and can start to automate the content creation for prototyping, based on the boundary names. etc. In the next blog post we will explore that and go on to look at the much more interesting case of using wrappers for instantiating memories.

We hope it helps!

Doug and Mick

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • LinkedIn