Institut für Computertechnik ICT Institute of Computer Technology Interaction of SystemC AMS Extensions with TLM 2.0 Markus Damm, Christoph Grimm Vienna University of Technology Martin Barnasconi NXP Semiconductors

Institut für Computertechnik SystemC TLMSystemC AMS Embedded AMS systems Tight interaction between AMS and digital HW/SW sub-systems Dedicated interfaces between analog and digital domain How should a TLM  AMS interface be defined? AMS-TLM interface

Institut für Computertechnik “TDF-Cluster“ SystemC AMS TDF A CD Timed DataFlow – Synchronous Dataflow with timing annotation Enables static scheduling – fast simulation of sampled analog signals at discrete time points Sampling period associated to token production/consumption B Sine-source Bit-source Modulation Environment Schedule: B A A C D…D 100x data rates e.g. sampling period of 2 ms here… …implies a samling period of 20  s here! 2 ms 20  s 2 ms 20  s

Institut für Computertechnik SystemC AMS – SystemC synchronization SystemC AMS has its own execution semantics and simulation time  synchronization needs! SystemC AMS provides converter ports which allows TDF modules to connect to usual SystemC Discrete Event signals. Accessing these ports triggers synchronization to SystemC kernel Note: SystemC AMS is temporally decoupled, similar to the TLM 2.0 loosely timed coding style! Note that t TDF  t DE always holds! If the data rate is > 1, the data token even “warp ahead“ t TDF !

Institut für Computertechnik Requirements for AMS-TLM interface Avoid “signal-level” interface (DE  TDF converter ports) between AMS and TLM avoid unnecessary kernel context switching maintain concept of “loosely coupled independent processes”: avoid strict timing synchronization between processes Create direct interface between AMS Timed Data Flow and TLM 2.0 Loosely-timed coding style maintain temporal decoupling for both engines efficient packing an unpacking of “analog samples” (data) in/from transactions Introduction of specialized converter modules / channels can be instantiated and configured by the user part of design refinement methodology

Institut für Computertechnik Basic idea of a generic TLM  TDF converter WRITE transaction data is streamed to TDF cluster directly Incoming TDF “samples” are passed to READ transactions The converter has to be part of the TDF-cluster Transactions mostly won’t come in regularly  We use buffers which are accessed via transactions The TDF cluster might run ahead too far in time  We need synchronization means! TLM  TDF converter TDF- CLUSTER TLM Interconnect output-buffer input-buffer dummy DE signal TDF sub mod ule TDF sub module DE  TDF converter port …and: what means “too far” exactly?

Institut für Computertechnik Implementation Our current conversion approach assumes loosely timed initiators Blocking interface, no backward path used Initiators may use temporal decoupling Issues: Transactions may arrive out of order (delays)  we need buffers which also keep timing information If a write-transaction has a delay annotation, the converter doesn’t know if the buffer has enough space by that time  we need a projected free buffer space concept TLM and TDF might warp ahead too much of each other  we need to trigger synchronization

Institut für Computertechnik TLM  TDF converter implementation TLM  TDF converter TDF- CLUSTER TLM Interconnect TDF sub module output-buffer The output buffer keeps the timestamp of the transaction the respective data was sent with (similar to payload event queue). If the TDF sub-module fires, it uses only data with a timestamp  the current SystemC AMS time If an incoming transaction has a delay > 0, a projected free buffer space is computed the transaction is returned with an error if the (projected) free buffer space is too small for the data Synchronization: buffer underrun WRITE-transactions 

Institut für Computertechnik TDF  TLM converter implementation TDF  TLM converter TDF- CLUSTER TLM Interconnect TDF sub module input-buffer If the TDF submodule fires, the incoming data token are copied into the input buffer (usual FIFO). We store only the timestamp of the oldest buffer token Transactions are annotated with an delay according to the timestamp of the youngest token returned If buffer holds not enough data for the read request, an error is returned Synchronization: buffer overflow READ-transactions 

Institut für Computertechnik Conclusion / future work Connecting TLM2 and SystemC AMS models makes sense regarding the design of mixed signals SoCs Efficient communication between AMS and digital HW/SW part Sophisticated synchronization TLM2 temporal decoupling processes can work well together with SystemC AMS statically scheduled TDF processes. The presented work is a technical feasibility analysis, more groundwork has to be done. Study Approximately-timed initiators and converter channels Apply methods to Real-life demonstrator

Institut für Computertechnik Thank you for your attention! Your: questions comments ideas objections