ESL, FPGAs, and configurability

It doesn’t seem like it was over five years ago when I decided the time was right to start planning and putting together my first book on the subject of electronic system level (ESL) design and verification. The resulting book ESL Design and Verification – co-written with Grant Martin and Andy Piziali was published in early 2007 and since then a second book has been added ESL Models and their Application, that builds on this earlier work.

One of the things I wanted to include in those books was a taxonomy for ESL, so that hopefully definitions would not get to be so word distorted and confused as they had become in many other areas of EDA. I had worked on the original industry taxonomy while chairing the System Level group within VSIA and turned that into another book, but it was not suitable for describing systems at the ES level.

While it adequately defined abstraction, it lacked the ability to describe aspects related to the complexity of the system. To give you a simple example: I could describe an 8-bit adder at the transistor or register transfer level. Fairly simple. I could also describe that in an abstract manner using the plus sign operating on variables that had been defined to be fixed width. It is abstract, but not complicated. I could – who knows why – expand that adder to operate on a mega-bit wide number, making it one of the largest chips in existence, but it is still no more complex (ok – so I would run out of pins and need to add complexity to get the numbers in and out, but still it is not complex).

Anyways, I retained two axis to describe the temporal and data abstractions from the original taxonomy and added three new ones – concurrency, communications and configurability, as shown in Figure 1.


The first two of the new axis (concurrency and communication) have been discussed in the industry before and deal with the amounts on independent things going on in the system and the degree with which those concurrent elements communicate. The finer grained the communications, the more complex the system gets. This can range from two programs running on different computers over the Internet, where they may exchange data once or twice during operation, to many state machines with complex interactions between them, to systems where resources are shared between multiple systems – each needed them to get their jobs done and with time constraints attached. The axes were defined with a typical processor based system in mind, but they could equally apply to other types of systems.

Now, let’s get to that final axis – configurability. When I first put this in, a number of people thought it was a strange addition. It relates to when and how a system can be modified. This can range from never (think of a non-configurable black box piece of hard IP), to at design time, at configuration time, at startup time, to dynamically.

Now, we are not talking about just the software side of things here, we are talking about hardware as well. On this scale, I would consider most software to be fixed at design time, unless you want to consider self modifying code, or the ability of software to download new versions when they become available.

With FPGAs we start having the ability to move into the last two ticks on the scale where we can see the hardware being changed significantly during operation. Today, we do see chips being created that make this possible, although most of the chips have somewhat separated resources – a processor, and some FPGA resource. But there are some that have small pockets of FPGA type resources scattered throughout the chip that are totally intended for this type of reconfiguration.

One particular example used it for making modifications to the chip (bug fixes), or for adding debug capabilities. This would be classified as programmable or configurable. But there are very few run-time reconfigurable systems yet – even though the FPGAs have some support in to allow this. Of course there is little tool support for this kind of reconfiguration yet. It almost requires that the EDA tool chain be shipped with the device so that software could be compiled into hardware if additional performance was required in the same way that a just-in-time compiler for JAVA switches from interpreted code to compiled code when it identifies a performance advantage.

Just-in-time hardware coupled with an operating system that can view programmable resources as just another shared resource – to be given to the task with the highest priority, or closest deadline. This would actually defer many of the hardware / software partitioning tradeoffs until runtime where it could be decided based on how the system was actually put to use, or the traffic patterns that it sees. Maybe this will be part of the next swing of Makimoto’s wave – but a discussion about that will have to wait until another time.

So, if you know of designs that do actively modify the hardware during operation, I would love to hear about them, and in particular the tool chain that goes along with them. I am guessing it will be another decade before this becomes general practice.

Brian Bailey – keeping you covered