Interaction of SystemC AMS Extensions with TLM 2.0

1. Interaction of SystemC AMS Extensions with TLM 2.0 Markus Damm, Christoph GrimmVienna University of Technology Martin Barnasconi NXP Semiconductors

2. Embedded AMS systems AMS-TLM interface Receiver Serial Interface Modulator/ demod. DSP Host processor Antenna front-end ADC Calibration & Control Micro- controller SystemC AMS SystemC TLM Memory Imaging DSP Transmitter DAC to all blocks Audio DSP High Speed Serial Interface Power Manage- ment RFdetector Temp.sensor Oscillator Clock Generator • 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?

3. SystemC AMS TDF …implies a samlingperiodof 20 s here! Sine-source “TDF-Cluster“ A 20 s 50 20 s 100 C D 20 s 20 s 100 1 B 1 2 ms 1 01001100 Environment 2 ms Modulation e.g. samplingperiodof 2 mshere… Bit-source datarates Schedule: B A A C D…D 100x • 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

4. 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! Ifthedata rate is > 1, thedatatokeneven “warp ahead“ tTDF ! Note that tTDF tDEalways holds!

5. 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

6. Basic idea of a generic TLMTDF converter TLMTDF converter TDF submodule TDF-CLUSTER TLMInterconnect dummy DE signal TDF submodule DETDF converter port • 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! input-buffer output-buffer …and: what means “too far” exactly?

7. 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

8. TLMTDF converter implementation WRITE-transactions TLM  TDF converter TDF submodule TDF-CLUSTER TLMInterconnect • 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 output-buffer

9. TDFTLM converter implementation READ-transactions TDF  TLM converter TDF submodule TDF-CLUSTER TLMInterconnect • 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 input-buffer

10. 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

11. Your: • questions • comments • ideas • objections Thank you for your attention!