The discussion on my previous blog post about “the ideal ESL language” made me think some more about the purpose of a hardware modeling or description language. If you look closely, you realize that there are two quite different goals being pursued by the tools and languages discussed there.
On one hand, we have the task of supporting the design of new hardware bits, for the purpose of creating it. On the other hand, we have the task of describing a particular design for the purpose of simulating it. These two are not necessarily the same.
To use an analogy with building a house, a design language helps the architect create the house (piece of hardware). Since the architect relies on craftsmen and experts (compilers) to do detailed design (how to put in windows, where to put light switches, etc.), the high-level description does not contain all the details of the house. However, if you are trying to simulate the house (piece of hardware) so that its inhabitants (software) don’t see the difference to the real thing, the details are sometimes what matters most. For example, the precise way to operate the stove in the house is very important for familiarity, but is a detail most likely left out of the architect’s initial drawings.
A design language can leave many things unspecified to be filled in by a compiler, but these things can be absolutely core to a description language. In particular, programming register maps tend to be created as a not-too-important side activity in hardware design. They do not really need to be visible in higher-level ESL languages, as they can obviously be filled in later by a tool or a human. But for a description language, they are absolutely core.
A description language can also leave out many parts of the hardware. If the software being used or written does not use certain modes or functions of a piece of hardware, those pieces can be ignored and implemented as dummies. That means that support for dummies is very important in description languages. But dummies make little sense in a design language, as you are unlikely to design a chip with lots of area spent on dummy functions that do nothing.
A description language can also ignore crucial aspects like power constraints and synthesis constraints. These are guidelines for a compilation step that has no bearing on the description of the hardware — the description language should describe what ended up happening, not the if, please, what, and buts that guided how we got there.
For virtual platform creation, you seem to need a bit of both. I maintain that most of a VP is based on old hardware that exists, which calls for languages with strong description abilities. That’s the space that Simics DML was designed for. For the small part of the hardware that is novel would be nice to have some way to convert from a design language to a virtual platform. Here, I don’t really see any usable current tools or languages — SystemC is really more a design language, but if you want a virtual platform model, you have to use it as a description language. There is no automagic getting to a fast abstract model from a design-oriented description. That’s why we need new, higher level systems, that can push out decent descriptions from a design.
5 thoughts on “Describe is not the same as Design”
I like your comparison of a “design language” vs. “description language”, and one of the faults of systemC for target software simulation is the (miss) use of the abstraction level I’ve heard referred to as systemC-ilog. It is just too common to create systemC models at too low of a level of abstraction for target SW simulation. Maybe Simics DML is a solution, but currently proprietary?
I suspect that the Carbon folks may disagree with the sentence “There is no automagic getting to a fast abstract model from a design-oriented description.”
While not really a language should we consider the meta-data of IP-XACT also as a “description language”?
I don’t think so. They are perfectly clear that their models are in the 10KHz range, at best, while a fast simulation is at 100MHz to 1GHz… faster than RTL certainly, but not a fast virtual platform by any stretch.
It lacks semantics for the registers, so let’s say it is half a description language.
As I understand it, IP-XACT is just a way to describe connections between highlevel blocks. Seems more like a netlist language.
Yes, that is how I understand it too. There is nothing to describe WHAT a register does, only WHERE it is (and some of its simpler properties).