ESL is electronic system level modelling: a recent development whereby transactional models of hardware components can be called directly by device driver code without modelling processor cores or busses. It is especially useful for architectural exploration where a designer can rapidly experiment with different SoC configurations in terms of how many busses, what is connected to which bus and how wide the various busses and caches are.
We cover the motivational history of ESL, looking at how firmware and behavioural models were two types of IP divided from each other despite being generally in a common language: C++. We discuss architectural exploration using mixed-abstraction models.
ESL uses procedure calls between components in a S/W (software) coding style whereas traditional hardware modelling has used shared variables to model nets that connect the components. We need, at times, to convert between these S/W and H/W styles. We will need a transactor. This is a small software entity that converts between the two modelling styles.
To help us investigate the key aspects of this methodology without using extensive libraries of any sort we use our own processor, the almost trivial nominalproc, and we cook our own transactional modelling library rather than using the industry standard TLM 2.0 library.
The practical take an instruction set simulator of a nominal processor and then sub-class it in two different ways: one to make a conventional net-level model and the other to make an ESL version. The nominal processor is wired up in various different example configurations, some using mixed-abstraction modelling.
We briefly looked at blocking and non-blocking transaction styles and then extend them with timing annotations to give performance estimates that vary in accuracy. The various phases of the non-blocking style can be separately annotated to give a result, known as approximately-timed, that should be as accurate as a cycle-based simulation result.
On the other hand, there is a much looser timing model that is more suitable for use with blocking models. The ESL models can then run ahead of each other and of the global simulation time, each keeping track of its local offset in a variable called delta and checkpointing with the EDS kernel when necessary or at intervals of a time quantum. Having a large quantum can expose design bugs (good) and leads to a fast model.