RTL Design Tradeoffs

There are five major corners to be considered when doing an RTL design.

• Functionality
  • features
  • options
  • precision
  • debug features
• Chip area
  • gate count
  • storage space
• Speed
  • faster clock speed
  • less number of clock cycles
• Power consumption
  • dynamic power (gate switching power)
  • static power
• Simplicity
  • development time / verification time
  • maintainability
  • reusability

 

These are called corners because trying to optimize toward one corner will often pull the design further away from the others.  Each design has a unique landscape of where these corners are located.   The landscape picture may be changing as the design team moves through design and implementation, and discover things they may not be fully aware earlier in the project.  A design team that is agile enough to be able to accommodate changes late in the process will have a better opportunity of getting the best design.

Sometimes there exists an option that will give a big win to two or more corners at the same time; however, it is rare to find a solution that gives a win to all corners.  So, designing is an act of balancing between these corners based on the landscape and the IP requirements.  Each design can have different requirements .e.g. some don’t need high speed and some don’t care about power consumption.

Speed and area form a classic hardware design trade-off.  High speed often requires high area.   Power consumption can usually go hand in hand with area.  You can sometimes add extra data gating to block unnecessary propagation of signal activities.  This reduces power consumption but hurts timing and area slightly.

Another interesting pair is functionality and simplicity.  It is often assumed that functionality is a must have and simplicity is not that important.  Often times adding more functionality can add more area, hurt speed and hurt simplicity.  The team should be ready to consider this trade off as well.  Like the other corners, simplicity can often go against the others and we will have to optimize for it if we care enough.  For example, the Harvard architecture is a trade-off for simplicity and speed, against area.

It’s not always that hardware designers should try to negotiate for less functionality.  Sometimes it’s useful to add features that don’t cost too much.  I often add a feature to swap input bits or bytes.  It’s something relatively cheap to hardware but can be costly in software if the input format isn’t compatible.  Another example was from one of my first designs, a Viterbi decoder.   The requirement called for supporting various data block sizes and the maximum was about 600 samples.  So, I did what most would do, round up the configuration register and counter sizes to 10 bits, which would support up to 1024 samples, plenty more than what was needed.   Some months after the chip was completed, a system engineer came by and wanted to know if he could process 1500 samples with the hardware decoder.  He simply found a new use case that wasn’t in the spec before.  No, he could not.  It was unfortunate that the hardware was there but just couldn’t be used because the configuration register was one bit short.   In hindsight, using an 11-bit register would have doubled the maximum supported block size with pretty much negligible area and timing impact.  So, that would have been a good trade-off for more features.