System-level Verification vs Module-level verification

N

Neeraj

Guest
Hi everyone,
I've got a basic question and I guess its a general one (in the sense
that it doesn't concern verilog specifically).

1. I was wondering how System-level Verification of an SoC is
different from Module-level verification. How are they different?
One obvious answer would be that System-level Integration involves all
the modules of the SoC i.e, how they interact, what kind of interfaces
they have etc. Module-level integration, on the contrary, is just
fixing bugs in a given module.
The reason I have this doubt is that traditionally, module-level
verification is carried out by ensconcing the module in a testbench
that will simulate the environment the module is meant to ultimately
function in.
If that is indeed the case, then why on earth would anyone require
system-level verification? Wouldn't that be a repeat of the same
exercise in that the modules would basically only be responding to
stimuli from the external world (external world for the module).
Something that we already made them do in the testbench during
module-level verification.

2. It would be great if anyone out there could give me pointers as to
what I should look out for when I'm carrying out system-level
verification (e.g focusing on interrupts, data transfers, protocols
etc)

Thanks in advance for your comments! :)
 
Some interesting things to look for in System level verification are

1. The througput through the module changes dramatically in system
level, I am talking about a case of a SOC which has a common system bus
to interface all the modules. Because of multiple blocks beeing active
simultaneously, there might be interesting cases when there block of
interest is not beeing able to get enough bus access to sustain the
desired data rates, this will generate interesting cases like FIFO
underflow etc.

2. Interaction between modules. The module level test env might not
include all the relavent blocks, there might be some assumptions made
which might be different from what the other block actually does.

3. As you already mentioned, things like interrupts, bus arbitration
etc might be of more interest in system level verification.

I think system/module level verification can not be viewed as "one
trying to replace the other". I think both of them are required. Module
level verification should be used for functional coverage, and system
level should be used for verifying end to end data flow and other
things mentioned above.

Thanks
Niel
 
Thanks for your comments! :)
Neil wrote:
Some interesting things to look for in System level verification are

1. The througput through the module changes dramatically in system
level, I am talking about a case of a SOC which has a common system
bus
to interface all the modules. Because of multiple blocks beeing
active
simultaneously, there might be interesting cases when there block of
interest is not beeing able to get enough bus access to sustain the
desired data rates, this will generate interesting cases like FIFO
underflow etc.

2. Interaction between modules. The module level test env might not
include all the relavent blocks, there might be some assumptions made
which might be different from what the other block actually does.

3. As you already mentioned, things like interrupts, bus arbitration
etc might be of more interest in system level verification.

I think system/module level verification can not be viewed as "one
trying to replace the other". I think both of them are required.
Module
level verification should be used for functional coverage, and system
level should be used for verifying end to end data flow and other
things mentioned above.

Thanks
Niel
 

Welcome to EDABoard.com

Sponsor

Back
Top