Virtual Prototyping in SpaceFibre

System-on-Chip Design
Ilya Korobkov, Junior Researcher,
Saint-Petersburg State University of
Aerospace Instrumentation
ilya.korobkov@guap.ru

© Accellera Systems Initiative 1

 Network Memory Controller
MIPS 32 OVP
4KEp RAM

AXI BUS

Registers Routing table Broadcast controller DMA

Interrupt/Acknowledge
controller

Crossbar
SpaceFibre port 1 SpFi controller 1
SpaceFibre port 2 SpFi controller 2 Configuration port

SpaceFibre port 3 SpFi controller 3

...
SpaceFibre port N SpFi controller N SystemC/TLM 2.0

*SpaceFibre – abridgement SpFi

© Accellera Systems Initiative 2
VSP: Cadence Virtual System Platform
Virtual prototype

Create new IP blocks (tlmgen)

Provide access to processor models
(ARM Fast Models , Imperas)
Assemble the IP blocks into a
virtual prototype
Work with virtual prototype
(configuration, simulation,
debugging)
Software
Using virtual prototype for
running embedded software
Testing embedded software
inside the prototype

Analyze performance of
architecture and embedded
software
© Accellera Systems Initiative 3
 tlmgen tool
• generates a set of TLM module templates
• helps to avoid common errors as naming inconsistencies,
register overlapping, and illegal register accesses by the
software
• speed up development time
• provides form of input data:
 simple register definition language (simpleRDL)
 IP-XACT XML

© Accellera Systems Initiative 4

 simpleRDL format
RDFfile (Register Description File) input data for tlmgen
• Description modelling memory-mapped registers: field,
register and register bank
• Ports specification
• Parameter specification

© Accellera Systems Initiative 5

 Use tlmgen
Generate TLM-2.0 module template for “DMA”
dma

doc test src inc cfg build

dma.tex dma_hwtest dma_bank.cxx dma.h dma.conf

dma_base_tlm2.cxx dma_bank.hxx dma_model.conf.internal dma_build.sh
dma_tlm2.cxx dma_base_tlm2.hxx
systemc dma.cpp dma_reg_defs.h
dma_reg_defs_const.hxx
dma_reg_desc_macro.hxx
dma_test.cpp dma_register_class.hxx
dma_test.h dma_standard_headers.hxx
dma_test_tlm2.cxx dma_tlm2.hxx
dma_test_tlm2.hxx platform_type_defs.hxx
tlm2_test_build.sh

© Accellera Systems Initiative 6

 Benefits of tlmgen
• Input data format is simple and clear
• IP developer can add new sockets, class, threads and
processes to template
• Supports SystemC classes sc_register,
sc_register_field, and sc_register_bank
• Decrease time developing IP block
• Helps to avoid common errors as naming
inconsistencies, register overlapping

© Accellera Systems Initiative 7

 Debugging SystemC Code (1/3)
• Source Browser displays the source code of model during
simulation
• Developer can view the values of SystemC objects
• Lets create breakpoints on objects, functions, processes,
• View the variables and data members,
• Stop the simulation at breakpoints
• Display the call stack and the list of processes
• Step the simulation
• You can also invoke your text editor from the Source
Browser to edit the model’s source file

© Accellera Systems Initiative 8

Debugging SystemC Code (2/3)

© Accellera Systems Initiative 9

 Debugging System Code (3/3)
• sc_event eventControlBandwidthCredit in
dma.spf_DMAs4_0 not active
• We should check source code when this sc_event
notify

© Accellera Systems Initiative 10

Analyzing Simulation Performance (1/3)
• Static information about your SystemC design
• Simulation run-time information
• More than 10 standard performance metrics:
throughput, TLM 2.0 response status, read accesses,
write accesses, bytes transferred …

© Accellera Systems Initiative 11

Analyzing Simulation Performance (2/3)
Resource usage
CPU and Memory

Run-time distribution
between processes

© Accellera Systems Initiative 12

Analyzing Simulation Performance (3/3)
Set chart options for
analyze modeling results

Plots with
required
parameters
© Accellera Systems Initiative 13
 Streaming via SpaceFibre port
To test performance of SpFi ports for streaming we used traffics:
• Video: SVGA RGB 60Hz, 1.42Mbytes, accepted latency < 16 ms
• Audio: Kodec G.711, 160 bytes, 0.05 packet/ms, accepted latency < 100 ms
• Sensor data: 1Kbytes, 50 packet/ms, accepted latency < 5 ms
• Control data: 260 bytes, 0.02 packet/ms, accepted latency < 0.1 ms
• Background: 1Kbytes, 25 packet/ms, accepted latency – not defined
Network Memory Controller #1 Network Memory Controller #2
Control data
Sensor data
Background data
Tx Traffic Output SpFi 1.25 Gbit/s Input SpFi Rx Unit #1
generator #1 port #1 port #1

Video
Tx Traffic Audio Output SpFi 1.25 Gbit/s Input SpFi
port #2 Rx Unit #2
generator #2 port #2

© Accellera Systems Initiative 14

 SpaceFibre port model
Port consists of input and output
Port includes:
• Virtual Channels (VC) with 1Kbytes buffers for data storage
• Medium Access Control multiplexes output data and provides QoS
• VC de-multiplexing distributes input data between VCs

OUTPUT SpFi port INPUT SpFi port

Access Control
Sensor data

mulitplexing
VC1 buffer Medium Link VC1 buffer
Tx Traffic Control data

VC de-
generator VC2 buffer 1.25 VC2 buffer Rx Unit
Background
VC3 buffer Gbit/s VC3 buffer

© Accellera Systems Initiative 15

 What is SpaceFibre QoS?
Medium Access Control provides QoS:
Sheduled: time is separated into max 256 time-slots during which VC can be
scheduled to send data
Video frame 1 Video frame 2
... ... ...
Time
Slots for
Slots for VC5 other VCs
16 ms

The current time-slot is indicated by time value which is distributed broadcast

Priority: 16 priorities. VC with high priority will be entitled to first send data
Bandwidth Reserved: determines the limitations of the link utilization by VC.

© Accellera Systems Initiative 16

 Schedule Compaction
Wasted
If VC scheduled in the time-slot Size of video frame bandwidth

does not have data to send, Streaming video Sensor Sensor

data 1
other VCs are permitted to use Slot 182 Slot 183 Slot 184 Slot 185 Slot 186 Slot 187 Slot 188 Slot data 2
189 Slot 190 ...
...
the wasted bandwidth
Slots for sending Time
video frame via VC 5

VC5, priority = 14 VC1, priority = 15 (the lowest)

Sensor Sensor VC shall compete with
Streaming video data 1 data 2 others for sending data
... Slot 182 Slot 183 Slot 184 Slot 185 Slot 186 Slot 187 Slot 188 Slot 189 Slot 190 ... based on the priority
Schedule Comaction –
two traffics assigned Time
to one time-slot

Hence, VC5 must have higher priority than VC1 to guarantee that VC5 will
be entitled to finish sending video frames. Then VC1 can send sensor data

© Accellera Systems Initiative 17

 SpFi port performance testing (1/4)
Situation: port #2 was disabled. All data went through the port #1
Network Memory Controller #1 Network Memory Controller #2
Control data
Sensor data
Background data Overload!
Tx Traffic Output SpFi Input SpFi Rx Unit #1
generator #1 port #1 port #1
Video
Audio
Tx Traffic Output SpFi Input SpFi
port #2 Rx Unit #2
generator #2 port #2

Result: sensor data were delayed

too long, because the link was
occupied by the video traffic.
Sensor latency - unacceptable

© Accellera Systems Initiative 18

 SpFi port performance testing (2/4)
SpaceFibre Solution: use Scheduled and Priority QoS (SPQ) to get
schedule compaction

Result: all data were delivered with

acceptable latencies.

But there is problem – idle virtual channel: not transferred all sensor data
Size of video frame Idle time
Reason: SpaceFibre limits
Sensor Sensor
Streaming video data 1 data 2 amount of priorities and
... Slot 182 Slot 183 Slot 184 Slot 185 Slot 186 Slot 187 Slot 188 Slot 189 Slot 190 ... time-slots
Slots for sending Time
video frame via VC 5

© Accellera Systems Initiative 19

 SpFi port performance testing (3/4)
Our solution: use Schedule Compaction with Adaptive Data Streaming Service
ADSS can dynamically change VC priorities and time value that defines the
current time-slot. It removes the limitations of priorities and time-slots.

Result: 1) no idle virtual channel 2) more time-slots for scheduling: from 256 to 512

The increment of transmitted sensor data is up to 2.7%

© Accellera Systems Initiative 20

 SpFi port performance testing(4/4)
Is the increment by 2.7% small result?
It’s good result for spacecraft, because the reliability was improved!

Result depends on traffic and schedule: Packet size: 1.33 packet/ms

Packet rate: 260 bytes

The increment of transmitted sensor

data is up to 10.5%

© Accellera Systems Initiative 21

 Conclusion
OVP technology and
SystemC/TLM 2.0 languages Cadence VSP Software

They allowed to perform simulation and to

analyze performance of the Network
Memory Controller project

© Accellera Systems Initiative 22

 Thank you for attention!

Questions?

e-mail: ilya.korobkov@guap.ru

© Accellera Systems Initiative 23