Models of computation and languages for embedded system design A Jantsch and I Sander Abstract Models of computation MoC are reviewed and organised with respect to the time abstraction they use Continuous time discrete time synchronous and untimed MoCs are distinguished System level models serve a variety of objectives with partially contradicting requirements Consequently it is argued that different MoCs are necessary for the various tasks and phases in the design of an embedded system Moreover different MoCs have to be integrated to provide a coherent system modelling and analysis environment The relation between some popular languages and the reviewed MoCs is discussed to find that a given MoC is offered by many languages and a single language can support multiple MoCs It is contended that it is of importance for the quality of tools and overall design productivity which abstraction levels and which primitive operators are provided in a language However it is observed that there are various flexible ways to do this e g by way of heterogeneous frameworks coordination languages and embedding of different MoCs in the same language 1 Introduction A system on a chip SoC can integrate microcontrollers digital signal processors DSPs memories custom hardware and reconfigurable hardware in the form of field programmable gate arrays FPGAs together with a communication structure and analogue to digital A D and digital to analogue D A converters on a single chip Fig 1 In total there may be dozens or hundreds of such components on a single SoC These architectures offer an enormous potential However they are also tremendously complex and heterogeneous This does not only apply for the hardware but also for the software Moreover the overall system complexity grows much faster than system size due to the component interaction In fact intra system communication is becoming the dominant factor for design validation and performance analysis Consequently issues of communication synchronisation and parallelism must play a prominent role in all system design languages 1 1 Hardware and software In order to manage the complexity and heterogeneity of SoC applications Edwards et al 1 believe that the design approach should be based on the use of one or more formal methods to describe the behaviour of the system at a high level of abstraction before a decision on its decomposition into hardware and software is taken The final implementation of the system should be made by using automatic synthesis from this high level of abstraction to ensure implementations that are correct by construction q IEE 2005 IEE Proceedings online no 20045098 doi 10 1049 ip cdt 20045098 Paper first received 28th July and in revised form 3rd November 2004 The authors are with the Department for Microelectronics Information Technology Royal Institute of Technology Electrum 229 Kista 16440 Sweden E mail axel imit kth se 114 Validation through simulation or verification should be done at the higher levels of abstraction This is in contrast to current design practice which typically leads to an early definition of the interfaces between hardware and software After these interfaces have been specified and fixed by system designers the hardware and software is developed in separate subprojects by different teams Each of them only validates their design against the specified interfaces but there is little opportunity to re evaluate these interfaces or the overall hardware software partitioning This is unfortunate because only when more details of the different parts are explicitly modelled analysed and understood will certain requirements constraints and needs become apparent Example In a mixed hardware software design project a task scheduler shall be implemented in software During the system specification it has been determined that the hardware timer sets a flag every 50 ms which is the basic time unit for the scheduler Even though the used timer has a much higher resolution during system design and hardware software interface specification it is decided that the only information passed from the hardware timer to the software scheduler is the flag which is set by the timer and reset by the scheduler There is no apparent reason why the interface should be more complicated than this as previous product generations have successfully used this mechanism Also simplicity is a major design goal since experience has shown that over dimensioned designs have caused increased hardware cost delayed development and resulted in performance bottlenecks It becomes apparent only much later that the new product requires a more sophisticated scheduler Due to challenging real time requirements it sometimes happens that the scheduler is invoked up to 5 ms after the interrupt from the hardware timer It turns out that it would still be possible for the scheduler to properly schedule all tasks without timing violations because this situation never happens several times in a row and one specific task can be delayed in that case For this to work properly the scheduler has to know IEE Proc Comput Digit Tech Vol 152 No 2 March 2005 to high abstraction and it does not mean there is only one detailed implementation For instance the delay can be given as a minimum maximum latency range which is well specified but still leaves sufficient freedom for various implementation options Fig 1 Possible system on a chip architecture how many ms have elapsed since the last timer tick Even though the timer has this information readily available the hardware software interface has no means to convey it More often than not it is very difficult or impossible to change the interface specification Several design teams work with the given specification and too much hardware and software had to be changed and revalidated Thus if possible a more local solution to this kind of problem is sought For instance in our case the software engineers might be tempted to infer the elapsed time by counting executed instructions This kind of ad hoc solution causes a set of problems such as undocumented dependency on a particular processor type and clock frequency with a nightmare of potential validation problems To avoid ending up in ad hoc problem fixes and local optimisations Edwards et al 1 argue for a system specification that is detailed enough to identify this kind of problem early on but which does not commit to specific implementations and detailed interface definitions Essentially