Forum: FPGA, VHDL & Verilog Unit testing- too much maintenance overhead?

von R L (Guest)

Rate this post
0 useful
not useful
Hi, all,
I will be happy to hear your thoughts on this.

I'm working on some complex designs, with ten or more subunits. I know 
its often recommended, in the software world, to do unit level testing, 
as well as design-level testing, but i find that later maintaining those 
testbenches is very time consuming.

so, how do you simulate and test your designs? On what level?
Note - im bot talking about verification here, just testing as part of 
the design process itself.


von P. K. (pek)

Rate this post
0 useful
not useful
If you can simulate (which you most probably refer to as "testing") your 
sub blocks embedded within the higher entity, no problem.

However, sometimes it's easier to simulate lower level entities 
standalone (doing it the "divide and conquer" way). You may better reach 
special conditions and be sure it works before going to a greater 
context. Depends on how complex your "complex designs" are...

von Colibri (Guest)

Rate this post
0 useful
not useful
As soon as full test coverage is demanded, there is no other way than 
simulating at block level

von P. K. (pek)

Rate this post
0 useful
not useful
And of course it's a big difference whether your design goes into an 
FPGA (simulate, among other reasons, to avoid to many synthesis 
iterations) or into an ASIC (full coverage required, as masks are 
expensive) ...


Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [vhdl]VHDL code[/vhdl]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]

Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.