A View from the Top: A Virtual Prototyping Blog


Moving towards ESL – History repeats itself!

Never let the future disturb you. You will meet it, if you have to,
with the same weapons of reason which today arm you against the present.
Marcus Aurelius Antoninus (121 AD – 180 AD), Meditations, 200 A.D.

So this is my attempt to define ESL. Well, while the term has been coined quite some time ago by Gary Smith, I would claim it still is in its beginning. Predicting the future is difficult, to say the least. But call me German and overly structured, but I think we can learn from the past. Today the ESL space is pretty fragmented. Generally everybody who deals with the pre-RTL aspects is counted in this category. There are several sub-categories, probably best described as a comparison what we have at the RT Level.

History of abstractions and how to move between themThis graph shows how the industry moved up in abstraction levels so far, this time it indicates also how you move between them. Without exception at each abstraction level so far we had the following categories:

1. Verification at the next higher level of abstraction. Example: In 1992 I developed a HDTV Motion Estimator Chipset for a telecom provider. The design was at the gate-level. But to verify that the six chips interacted correctly we used RTL for verification as it was much faster.

2. Equivalence checking within and between abstraction levels. Example: Equivalence checking from gate to gate was driven by the need to verify that the optimizations did not screw up the intended functionality. The same was true at the RT Level. The next step was to verify between RTL and Gate that the functionality had been maintained given all the optimizations predicting implementation aspects.

3. Synthesis from one level to the next. Example: Once the appropriate synthesis subset of a standard language like Verilog had been defined logic synthesis from one level to the next started taking off.

There are similarities when we look at the pre-RT Level in which the set of ESL tools play today.

1. Verification at the pre-RT Level. This is what Gary Smith I think calls the intelligent test bench. This has been the first part to take off at the RT-level and with moving verification to the transaction level it has been the first part taking off in ESL too. The usage of SystemVerilog transactions for verification documents that. The interesting change this time around is that things do not only get more complex but we have a new component in the system – embedded software is required to model a system completely as verification reference. And that’s where we are facing a bit of a dilemma, given that software designers and hardware designers are quite different. But the next and new category, virtual platforms, offers a valid solution.

2. Virtual Platforms at the pre-RT Level: Including Synopsys there are several players in this field. A virtual platform virtualizes the hardware to allow efficient pre-silicon software development and to compress project schedules by allowing the development of post-silicon tests to be started early. There are other use models for virtual platforms, mostly around performance analysis and optimization. The requirements with respect to accuracy and speed depend a lot on the targeted application domain. Real-time software for example seems to require generally more accuracy in the modeling of the underlying hardware.

3. Equivalence Checking: The first companies in this domain (SystemC to SystemC and SystemC to RTL) are out, although they are in early stage.

4. Synthesis from SystemC to RTL. Several companies like Mentor and Forte provide offerings in this space. Now that the industry has a standard language (SystemC) and as we are getting close to a behavioral synthesis subset definition with SystemC, this area probably has room for growth.

Signal and Transaction-LevelVirtual platforms are one of the main drivers for the ESL area today. As an example this figure illustrates in the bottom a generic block diagram with protocol blocks, busses and processors at the signal level. Transactors used in verification IP are utilized to drive signals based on transaction input. The top portion of the diagram shows the corresponding block diagram as virtual platform at the transaction-. At that level of abstraction, connections to real world I/O of USB, Ethernet, SATA and PCI, as well as skins and virtual representation of the actual device can be used to interact with the virtual platform.

Independent of language questions the transaction-level is the undisputed next abstraction level above RTL.

With the standardization of the TLM-2.0 API, SystemC now offers a very suitable infrastructure for fast execution of virtual platforms. With processor models by itself reaching speed levels above 100MIPS, full platforms of several processors and peripherals can be integrated in SystemC using TLM-2.0 and still run between 20 and 50 MIPS at the platform level. Furthermore, SystemC is already well integrated with the rest of the design and verification flows – all bigger simulation vendors offer SystemC support in their mixed-language simulation engines. This makes it the perfect choice for virtual platforms for pre-silicon embedded software development and – once available – linkages to verification.

I am looking forward to your comments! But please remember:

Prediction is very difficult, especially about the future.
Niels Bohr (1885 – 1962)

Share and Enjoy:
  • del.icio.us
  • Digg
  • Facebook
  • Google Bookmarks
  • Print
  • Twitter
  • StumbleUpon
  • LinkedIn
  • RSS