Bharat MP, Test and Verification Solutions Ltd.2015-01-19T13:02:38+00:00

Name:Bharat MP
Designation:Engineer
Title:Why Synthesis From SystemC?

Content : Hardware design has the well-established Verilog and VHDL hardware description languages with tools and design flows based on them. Why should you bother to understand how to use SystemC, a system design language, for hardware design and synthesis? Consider a scenario where a system designer has created an architectural model of a SoC in SystemC and you are a hardware designer. The architectural model contains a variety of models, including processor models, abstract bus models, and peripheral models. The peripheral models capture the full functionality and interface of the peripherals, although at a high level of abstraction. This allows the system designer to hand you the peripheral models as an executable specification, along with written requirements for the area, speed, and power consumption for the peripherals.

Interpretation Errors
——————————
You need to implement the peripherals and verify the implementation in the context of the entire system. If you use a Verilog or VHDL synthesis tool, you need to rewrite the peripheral models in Verilog or VHDL, which is a time-consuming and error-prone process. Or you can synthesize the peripheral models from SystemC. Instead of throwing away the work done at the system level and recoding the design, you can take the abstract, non-synthesizable peripheral models and refine them into synthesizable models.

Verification Reuse
————————–
As an added advantage, you can use the system-level verification environment to check the correctness of your implementation as you refine it.

Why TVM
—————
1. As the design is in SystemC. Instead of having foreign language for verification, we can have systemC verification methodlogy.
2. Again if every one uses their own methodology, then there will be inter-operable issue. which can be avoided using TVM.
3. Block level to full chip migration will be easy.
4. Crave library support all IEEE randomization support, which is plus.
5. On time randomization support. which not available with legacy systemC Testbenches.
6. In legacy systemC Test benches we use functions( for example mem_wr , mem_rd , config_wr or config_rd) for generating transactions. As transactions are genearted by calling function, randomization will be difficult. As they are converted into sequence( class) randomization will be easy.
7. Two levels of randomization
1. sequence item level
2. sequence level.
8. Factory/Phasing/raise and drop objection/timeout/cofing db/default sequence support similar to UVM.

Register for the event here