Knowledge Center
Knowledge Center

Models and Abstractions

Models are abstractions of devices


No flow can be described without talking about models. A model is an abstraction of a device. Many models, such as those written in Verilog or VHDL, are executable. Being executable means that a tool, such as a simulator or emulator, can exercise the model and, when stimulated, produce results. Other models are not executable, but instead contain information that can be read by a tool, manipulated and written back. These models, such as a coverage model, may control a flow.

Most models associated with design are executable models. These can be at a number of abstractions including SPICE, transistor, RTL, or one of many ESL abstractions. An abstraction means that a certain aspect of a model is not deemed important for a particular kind of analysis. Designs for SoC flows tend to be abstractions in the temporal axis, the data axis or the functionality axis. The introduction of ESL modeling has added three additional forms of abstraction, namely concurrency, communications and configurability. A brief description of each axis is provided here, but those wanting a full description of the taxonomy of abstractions should consult ESL Models and their Application: Electronic System Level Design and Verification in Practice (Embedded Systems).

Temporal abstraction
The temporal axis defines the timing in the model. Typical types of timing may be partially ordered, meaning that that the start and end of something are only known in terms of the relationship to when other things started and finished in this particular execution. Instruction cycle, cycle-approximate and cycle accurate all have the notion of an actual clock with known period, and thus actual times are known. However, different levels of accuracy are still possible as the exact number of clock cycles that elapse between significant events has some degree of uncertainty. Certain tasks within a design flow require sub-clock cycle accuracy and analog design usually has whatever timing accuracy is necessary in order to ensure all changes are piecewise linear.

Data abstraction
The data axis defines the level of precision of data. At the highest level, data may be abstracted to an event without any actual concept of the actual data. Within an ESL flow, it is typical to work with transactions which hold packets of data that have no correspondence with the way in which data would actually be organized in the final system. Design uses notions of integers, floating point values or similar such data type, where its numerical accuracy is known but how it is represented in hardware is not known. Bit logic provides that mapping of value into the hardware that will store it.

Functionality abstraction
This attempts to define the precision of the operations themselves. For example, a mathematical formula defines precedence but not order. The algorithm must be scheduled and this is often the operation performed during high-level synthesis. Even at the register transfer level, order is still somewhat loose and dependency analysis can allow sharing, reordering or other kinds of optimization to be made.

Concurrency defines the amount of processing or execution of an application that can be performed simultaneously. An implementation does not have to utilize all of the available concurrency as this may produce a solution that does not fit the non-functional requirements of the design such as cost, size or power consumption constraints. Concurrency is sometimes restricted by the model of computation imbedded in a language. For example, the C language is a sequential language and so a tool has to extract the available concurrency that may exist in the model by performing dependency analysis. Other languages allow for concurrency to be described directly.

When more than one processing element exists, there must be communications between them. That communication can take many forms and is highly dependent on the architecture of the final solution. Very fine grained parallelism such as operations within an instruction or dedicated pieces of hardware are naturally handled by point to point communication or pipelines. At the other end of the spectrum, two software threads that need to communicate are likely to use some form of shared-memory to communicate with one another. For example, an all-software solution could use shared memory, or pipes layered on top of shared memory. A multi-processor software solution could use hardware FIFOs or queues between processors.

Concurrency and communications are somewhat tied by technology solutions. In general coarser levels of concurrency can afford to use more generic, shared forms of communications, whereas very fine levels of concurrency need more dedicated, faster access methods.

How fixed is the design? An ASIC generally embeds all aspects of the design in hardware and they cannot be modified, but in many cases, a certain degree of flexibility is built into devices.

Most people would consider software to be configurable, but it is the configurability of the platform that the software runs on, or is embedded in, that is just as important. The only difference between hardware and software in this regard is the delivery mechanism. Software, written in such languages as C or C++, is modified at design time and compiled to work on existing hardware solutions, but once it is shipped it cannot be easily modified in the field, although mechanisms may exist on some devices for downloading new or modified compiled executables from a network. Java code on the other hand can be modified or retargeted for different hardware since the compilation step is deferred until close to execution time and thus has more configurability.

Dedicated fixed-function hardware solutions are often very rigid and can only perform a single task. A processor with a fixed instruction set is also considered a fixed solution. However, a processor with an extensible instruction set has some degree of configurability. This configurability is handled by the tools in the design path. Hardware can also be built to be configurable. For example a Serial/ Deserialiser (SerDes) I/O block can be configured to support a number of different serial protocols. Many communications processors can also support the higher levels of the protocol for these communications mechanisms. A reprogrammable fabric, such as an FPGA or PLD, can be reprogrammed at start-up, or even possibly reprogrammed during operation of the system.