SystemC based Virtual Prototypes of SoC & Electronics systems enables the early software development in parallel to hardware design. This is the most popular example of shift-left concept in SoC desigm.

This article by Brian Bailey, covers an interesting discussion about the various methodologies that enable Shift Left paradigm in the SoC design flow. 

Read more ..

This article is the summary of DVCon India 2015 poster session, jointly presented by Continental Automotive & CircuitSutra Technologies.

​In today’s world, ICs are becoming increasingly complex. As a result, the density of ICs is increasing to accommodate more functionality on a smaller area. Competition to release electronic products early in market along with maintaining low costs is increasing among vendors. To achieve this, verification of these ICs in least possible time is the key factor.
 
Especially for analog parts of an IC, a complete parametric test needs to be done after silicon availability. These tests are performed on an automatic test equipment (ATE) controlled by a suite of test-cases. Development of such a testsuite is a time consuming process and debugging possibilities on the ATE system are very limited as long as silicon samples are not available. To create a full suite of correct and running test-cases for an ATE before the targeted IC is actually ready, we simulate the entire test environment using SystemC. In this poster, we focus on challenges and benefits of using SystemC for Virtual prototyping, development and verification of test cases for physical ICs.
 
VirtualATE, designed in SystemC, is a model of the programmers interface of the physical ATE system, which includes the drivers and monitors controlled by the test-cases. These drivers and monitors are connected to a SystemC model of the IC. This combined system is compiled into an executable which is static for all tests to be executed. The test-cases are compiled into a shared object that is loaded at run time by the VirtualATE.
 
VirtualATE supplies the inputs to the IC model and collects the outputs. The result file is generated in the same format as on the real ATE system. The generation of this result file includes comparison against a golden reference file to decide whether the test-case is a fail or a pass. However, the VirtualATE system has the advantage that it can be configured to also generate signal traces not only from the pads of the IC but even for internal signals. For the development and debugging of the testcases this is a big advantage even after silicon availability. In this way, a working test-suite can be achieved long before the physical IC is available. These testcases can be directly run on physical IC for its verification once IC is available.
 
Without VirtualATE, we have to wait until the physical IC is released for running the test cases to detect any bugs in the test programs which consumes more time as compared to doing with VirtualATE.
 
Even after silicon availability VirtualATE can still play an important role. One aspect is the before mentioned traceability. On the real ATE system only the pads could be traced via an oscilloscope which can be a time consuming task. The VirtualATE on the other hand allows simple correlation of various (even internal) signals. On real ATE it is difficult to debug some aspects without internal register visibility.

Another aspect that makes the VirtualATE a useful vehicle after silicon availability is the possibility to easily run several instances at the same time. Testsuite development with real ATE is very time consuming as one can not work in parallel unless one acquires several very expensive ATE systems.
 
Test Setup:
The diagram below shows the set-up used for VirtualATE:

​

​Example:
The below code snippet is from a test program testing an ADC parameter.
 
SetVoltage(AN0, 0.1V)
Wait(Conversion_Time);
adc_result=Raddr(0x0010);
 
In the above code snippet, VirtualATE is setting the voltage of the ADC channel AN0 to 0.1V. After waiting for the conversion time, the digital value from the corresponding result register is read.
 
In this way, inputs can be applied on pins and registers can be read/written to verify the functionality of the models and test programs. Without VirtualATE, we have to wait until the physical IC is released for running the test cases to detect any bugs in the test programs.

Typical test case issues dectected with Virtual ATE

• Wrong address used in SPI transfer
• Wrong range expected for result
• Result stored in wrong location
• Saturation of ADC not handled correctly
• Endless loops due to not changing condition
• Mixing voltages and currents
• Missing initialization
• Wrong ADC range

 
Pros:

1. Time to market of the product reduces as the test program development starts in parallel with physical IC development.
2. Easy to develop and debug test programs as internal signals and registers can be traced in vcd and log file.
3. Multiple Instance of VirtualATE can be created so that many people can work in parallel to develop and verify the test programs.
4. Reusability.

 
Cons:

1. Models have to be accurate because bugs could increase development time of accurate test programs.
2. Additional resources are required to develop and maintain the models.

 
Conclusion:
With the VirtualATE setup we are able to develop complete test suites for the ATE system before silicon availability. This approach saves us a development time of 3 to 6 month. Besides these time savings, VirtualATE also allows a more efficient debugging of the test-cases by parallelizing work and the possibility to trace all relevant signals of the DUT.