HOME    COMMUNITY    BLOGS & FORUMS    Breaking The Three Laws
Breaking The Three Laws
  • About

    Breaking the Three Laws is dedicated to discussing technically challenging ASIC prototyping problems and sharing solutions.
  • About the Author

    Michael (Mick) Posner joined Synopsys in 1994 and is currently Director of Product Marketing for Synopsys' DesignWare USB Solutions. Previously, he was the Director of Product Marketing for Physical (FPGA-based) Prototyping and has held various product marketing, technical marketing manager and application consultant positions at Synopsys. He holds a Bachelor Degree in Electronic and Computer Engineering from the University of Brighton, England.

Keeping Your RTL Clean: Part 1

Posted by Doug Amos on January 18th, 2012

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

2 Responses to “Keeping Your RTL Clean: Part 1”

  1. John Eaton says:

    This method is greatly enhanced when you add ip-xact to the wrapper.

    For example, I create a wrapper for a generic sram that has a slave sram bus interface and a slave mbist interface. The sram bus is connected to the user logic while the mbist one is ported up to the top level.

    Now if I need to replace the sram with an asic specific one all I have to do is change the port names in the busInterface description. New signals can even be added.

    If the asic vendor does not want to see all of the sram cuts buried deep in with the core logic then redefine the mbist bus to be the reversed mirror of the sram bus and all of the sram signals are instantly ported up to the top level. This lets you do bist groupings.

    With ip-xact you do not need to agree on any style or naming policies. It lets you map port names.

    • Doug Amos says:

      HI John,
      I’ve been meaning to follow up on your comment for a while.
      you make a good point, and I comeletely agree; a wider use of IP-XACT would greatly benefit prototyping methodology. The expedient of having FPGA equivalents for some key SoC blocks, and using IP-XACT to allow their use error-free replacement without any drama, can really be at the heart of good Design-for-Prototyping flow. I recall that STEricsson had been using this approach as far back as 2009, and I presented together with Gregory Prieur of STEricsson on the subject at the SAME Conference in Sophia Antipolis, France that year. The slides are still available here if you want to see their use of IP-XACT in a prototyping flow.