ESL Electronic System Level Design Theoretical Framework and

ESL Electronic System Level Design Theoretical Framework and Technical Challenges. National Microelectronics Institute September 2006 Dr David Greaves (david. greaves@cl. cam. ac. uk) University of Cambridge Computer Laboratory

Typical So. C (Virata Helium Family)

Talk Overview Event driven simulation With zero delay signals System. C 1. 0 and 2. 0 Use of ISS, native compilation and hybrids Transactional Interfaces Programmers' Views Transactors Temporal logic, transactor and bus-monitor synthesis Pending issues. . .

Pre-Electronic System Level (Pre-ESL) Instruction Set Simulator

EDS: event-driven simulation Components: T_now, current time variable, Event list: (time, net, value) list, Net list, Model list – with net sensitivities. Algorithm: while(eventlist) { e = car(eventlist); eventlist=cdr(eventlist) tnow = time(e); Net[net(e)] : = value(e); wake up (run) models sensitive to net(e); } When a model runs, it inserts future events in the event list

EDS: zero delay modelling using signals and delta cycles Behavioural RTL is usually written with zero delays Need to avoid shoot through Solution: signals and gated event list signal nets have a current and pending next value pending updates are committed at end of each gated batch

OSCI System. C www. systemc. org A free C++ library for simulation or synthesis Large support throughout industry A component is a C++ class Hierarchic netlist achieved via instancing EDS kernel, signals and threads package Trampoline model call (SC_METHOD) Blocking models (SC_THREAD) System. C V 1 for signal nets System. C V 2 allows threads to run along `nets'

Pre-ESL 2: Using native C compiler Instruction Set Simulator

Pre-ESL 3: Avoiding ISS

What is process software like ? wait() 1. Software aims to use a minimum of: 1. Threads 2. Shared variables wait()

What does RTL look like ? wait() 1. RTL has a multitude of: -- Threads -- Shared variables (every net is one). always @(poesdge clock) begin a <= e 1; b <= e 2; if (e) c <= e 3; . . . end

Verilog/VHDL Synthesisable RTL is very low-level: Designer has complete control over every state register. No scope for automated time/space refold: EG. To implement 32 -stage FIR filter one can – Use one multiplier 32 times – Use eight multipliers 4 times each – etc. . Successful because: 1. They serve fine as hierarchical netlist languages 2. For synthesis, designer has control to net and gate level when needed, 3. Test-bench stimulus is not a separate language. Unfortunately: They require designer to think in terms of hardware Verilog is poorly equipped for structures/records.

Behavioural Synthesis (from C/System. C etc) Compiling software into hardware is 'old hat' in the research community: Generate a custom VLIW datapath+controller, by • 1. Perform symbolic elaboration, accumulating operations to be committed in a major cycle, • 2. Start a new major cycle at user markups, name aliases or according to a time/space heuristic reaching its target • 3. For each form of major cycle, determine static or arbitrated details for each of the datapath resources. Very hard to extend Verilog/VHDL synthesis rules in this way (behavioural Verilog compiler failed). C++/System. C should work well, but not legacy code. Most flows still use manual recode to RTL (? ).

Transactional Interfaces (TLMs) DUT Programmers’ Model Port n Terminal set partitioned into sets known as ports Relative timing between ports should be floating (i. e. irrelevant to semantic of individual port) Some or all ports are now software-style, transactional interfaces Normally now use subroutine calling instead of shared variables, Various calling styles: client/server, blocking/non-blocking, A number of subroutine call entry points and upcalls can be defined for each port • EG: Read, Write, Interrupt, Start, Stop, Remaining ports still use EDS-style shared variables to model their nets.

What does a Transactor look like ? DUT (RTL) Transactor is an RTL or C++ component, wired to a net-level port. The transactor provides a transactional-style API. Eg: A serial port on the device is converted to a software-friendly read_byte() and write_byte() pair of entry points by the transactor. The transactor can also make up-calls into C models. The transactor encompasses the transaction semantics of the port and presents each transaction as one subroutine call.

Transactional Interfaces (TLMs) 2 DUT Programmers’ Model Port n A Transactional Port has an idle state and executes discrete transactions with a (nominal) idle state between each transaction. Connected harnesses and models experience flow control at each port so that different versions of the DUT are accommodated without surrounding changes. Flow control nets and read/writebar transaction type nets subsumed by thread blocking and subroutine names. Temporal logic expressions can relate wire protocol to method signature System timing can be considerably changed – perhaps a different interleaving of transactions occurs compared with RTL model. Master clocks ultimately are no-longer needed.

Programmer's View State DUT Programmers’ Model Port n Internal state partitioned ‘Programmer's Model’ and Opaque remainder. A default PV is sometimes defined in terms of RTL arrays: Array contents preserved, giving ‘Memory Preservation View’ modelling. Multiple PV's in different sub-systems may 'overtake' each other.

ESL – the grail view:

Hybrid RTL/ESL – using transactors Interface Specifications

Where to get a Transactor ? DUT Transactors can be: Hand-coded in C or RTL, or Synthesised from a formal spec. A hand-coded transactor can serve as a user-friendly form of formal specification of an RTL port. Multiple transactors can be synthesised (refactored)from one starting spec, varying by Client/server, Sending side/receiving side, Blocking/nonblocking, Multiplexing/Vertical.

Synthesised Bus Monitors DUT 1 DUT 2 Bus protocol spec can be compiled to a monitor. Monitor checks for consistency, safety and liveness.

Synthesised Interface Automata DUT 1 DUT 2 A pair of bus protocol specs can be synthesised to provide glue logic. Inputs required are: Left-hand interface specification, Right-hand interface specification, Data conservation rule(s). Glue logic is either: Simple combinational logic An interface automata with internal state. One side, or other, or both, may be ESL transactional interfaces.

Interface Specification Syntax Various dialects exist: Sugar/PSL, OVA Vera. Composition of regexps and temporal logic: wait a blocking a; b Sequencing a* Repetition a|b Alternation ^a Posedge a a / b, a/b, ~a Boolean connectives a. Wb Weak until a. Ub Strong until Public and private domain libraries emerging ? Will be embedded in Spirit IP XACT Schema ?

Executable I/F Specs – Example Bus R/W Nets = { clk, d, a, rwb, sel, rdy }; read(A) : ( a == A / rwb / sel; wait(^clk / rdy); read == d; ~sel; ) write(A, D) : ( a == A / ~rwb / sel; wait (^clk / rdy); ~sel; )

OSCI System. C Progress System. C 2. 0 allows arbitrary channels between modules, rather than just netlist-like signals of 1. 0. OSCI TLM Group released TLM prototypes. Foundation for individual bus and port protocols • AHB, AMBA, OCP and so on. . . System. C Verification Standard: TLM monitoring and logging System. C Metainfo Standard: Read and write non-functionals OSCI TLM Group now releasing PV+T coding recommendations: Adds timing/cycle parameters to a transactional signature TLM 2. 0 adds more details and tracing facilities

Challenges Ahead Flows must be joined up! Who writes the I/F specs, what syntax? Non-deterministic multi-core kernel threads! C++ binary linkage portability issues! Multi-threaded programming/debugging is hard! Thread-safe System. C kernel for multiprocessors? Embed Sugar/PSL in Spirit IP XACT

The end David. Greaves@cl. cam. ac. uk