System level verification

[csliu]

One way is generate golden file with behavior model, then build top level
test bench and dump the test data and compare with the golden file.

FPGA emulation is another way, too.

 

[Joyee]

A good design process is to have two teams, one that designs the RTL code and one that designs the test cases at the top level (Component interface). Both teams use the hardware specification as a reference.

The design team make some validation at the block level to validate the basic functionality and the corner cases that are not obvious at the system level.

It is important for the test team to have a test plan that describe the test cases relative to each features of the component. It is always a good idea to implement DFT facilities in the design to improve testability.

Specman is a very good langage for system level validation. It include a powerfull list manipulation commands, randomisation and coverage support.

Regards,
shell3

Actually, I cannot agree with writng separate test case for testing each feature of DUT. By using Specman, you can represent features in coverage. Specman can help you direct the random beam to specific verification room. So, through checking coverage report, you can get to which feature is covered and which is not. This method can reduce manual effort significantly.

Additionally, in my view, engineers often mix system verification with system trade-off. As a project starts, we need system exploration to make a well trade-off. Its main task is for performance evaluation, software-hardware trade-off. In fact, in my opinion, I don't think it can be called as system verification.

Then after that, we can construct sub-modules in HDL and verify them one by one. At this stage, we call it module verification. We construct reference module for each module in DUT. After modules are fully tested, we can integrate them together.

To this point, we call it system verification. As we integrate them, we must re-use the verification work on each module, say temporal checker, reference module of sub-modules, scoreboard and functional coverage metrics which may help us allocate the problem during system verification if there is and also help us observe the verification process. At this stage, we also need the reference module of system. How can we know this reference module is correct? Actually, the correctness depends on DUT or these two modules, HDL module and reference module depends on each other.

Joyee

 

[dada1019]

System-on-a-chip Verification Methodology and Techniques is a good introduction of system level verification. you can download it from this forum.

 

[beckchm]

you can just do soft-verification,

hard-veri is very expensive