SystemC in SOC Development

Guruprasad PV, Global Edge Software

Abstract:

The objective of this paper is to explain the role of systemC in hardware development cycle.

Most Engineers would be aware of Advantages and restrictions of SystemC. This paper does not go in to merits and demerits but it tries to explain the role it plays in accelerating the software development and the need for unit and system level verification.

Introduction:

In today's competitive environment early release of chips to the market is the focus of many semiconductor companies. SystemC is used with this objective. SystemC is a C++ based Hardware Modelling language which is used by many semiconductor companies. It helps in accelerating the software/firmware development cycle by providing System on Chip model to software developers.

Role of SystemC:

Below diagram gives an overview of the flow cycle of any SOC before it is released to the market.

RTL Flow (traditional flow)

1. With this approach, software engineers can test their software only when first revision of the chip is released. Though the software engineers may have their software ready as per new hardware specification they cannot test it until base version of the chip is ready or FPGA is ready.
2. Second problem could be the bug in FPGA. If there is an any issue in hardware (e.g.: some registers could not be programmed etc) then to release the next bit file (FPGA) it will take long time. As software engineers are dependent on this, they may not be able to proceed further.

Flow with SystemC

1. With this approach, software engineers can test the software on VP which is developed using systemC
2. If there is any bug found in VP model (e.g.: connection between two hardware blocks missing etc...) then the amount of time to fix the bug and to release the next version of VP to software team will be very less.

The above diagram describes the software development which is developed parallelly while RTL design is in progress. This parallel execution of hardware and software is achieved by using Virtual Prototype model.

Virtual prototype consists of all hardware blocks which are presented in SOC. Software Engineers can start writing the code as per hardware specification. When software is verified by porting on Virtual Prototype they can directly port the same in real hardware. By this way, time to release the real hardware will be reduced (as software is already up).

Virtual prototype is developed using SystemC and TLM (Transaction Level Modelling).

All hardware blocks functionality of SOC is defined and verified using systemC.

There is a great responsibility on model developers as the software programmers depend on VP model.

When the model is verified (using test benches and system level verification) it would be used by the software team to write their code as per the requirement. When the software code is working in VP model, they can execute different tasks until Real Hardware is available.

As this code is already proven, the amount of time spent on Real Hardware would be less and by this, time to release to the market is also reduced.

What happens when software code works in model but fails in Real Hardware?

When this scenario is encountered it takes double the effort for Software team as they have to debug the code which has been ported on VP model. If the problem is in VP model, it dilutes the very essence VP development. Therefore model developers have great responsibility in creating the model as per the specification.

Unit Level and System Level verification of VP model

To make the system more robust, two levels of verification may be required. One is at unit level and second is at system level. In most of the cases, model working at unit level should work in system level but there could be exceptions. This may be primarily due to connection or configuration issues.

Unit Level verification:

Unit level verification is to verify the functional behaviour of an individual block. Unit level verification is standalone. It does not require the availability of other modules. Test bench will be used to drive the required inputs to this module. Based on these inputs and the functionality of the module, output of this module will be verified.

Signals can be verified by reading the signal or observing it on VCD.

Test benches at unit level are ideal for testing the state machine of the model where each state is driven by signals from other blocks which may not be exposed at system level.

System level verification:

System level verification verifies the behaviour of the whole system when all the modules are integrated. Similar to unit level, each hardware block would be verified by loading the images of the Test Cases (axf,elf etc).

In system level verification, some of the state machines of the model may not be visible but all the modules' interface will be verified.

Consider a module having a state machine as above. In unit level verification all the 3 states can be verified

Signal vct which is from another hardware block can be simulated by driving that input using test bench. Model moves from state2 to state3. In state3 when register reg_d is set to 1, control moves from state3 to state1.

In system level, state1 and state3 can be observed while state 2 cannot be observed as it is not under user control which makes the model to move from state1 to state3 (unless other hardware block has not asserted the vct signal)

This is an example for simple state machine; unit level plays a important role when the state machine is complex.

Let us take one simple SOC (System On Chip) which consists Counter, Advanced Interrupt Controller (AIC), ARM Processor.

SOC (System on Chip)

In unit level verification each hardware blocks behaviour will be verified individually. In the above diagram all hardware blocks input will be driven individually to verify the behaviour of those blocks.

In system level verification, driving the input signals of counter, SOC behaviour will be verified (because counter output is given as input to AIC and AIC output is given as input to ARM processor). If ARM enters an ISR handler, then it is assumed that interrupt logic counter is verified.

More the verification at unit level, lesser the verification effort at system Level (depends on complexity)

Conclusion:

Time line for Model developers has to be short and model developers need to stick to this tight deadline. Any delay in releasing the model makes it highly redundant (as RTL development would be catching up). Model should not have any major bugs and number of Bugs should be as minimum as possible.

More the Bugs reported, less it would be used by the software developer's.