cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
555 Views
Registered: ‎11-28-2018

Test Bench for multiple packaged IP modules

We've made a number of IP modules and packaged them so they can be used in a Vivado 'Block Diagram'.

These blocks are closely interrelated (thick interfaces between them) but cannot be consolidated into a single IP block for reasons beyond my control.

 

I have been charged with building a simulation TB for these IP blocks. It makes a lot of sense to test them all together. I want to do this by simply instantiating the blocks in a System Verilog TB, that is, I don't want to build a wrapper IP (packaged) module around them or a block diagram.

And, importantly, I don't want to have to manually hardcode the many library dependencies each of these IP block has (multiple Xilinx IP cores used in each, etc.).

 

Now, my question is this: what would you do to test a multiple-IP-block combo?

 

I know I can auto-generate a simulation script for each separate IP core that will nicely encapsulate all the nasty stuff for me under a simple shell script. If I find no better way to do this I will build my TB out of those auto-generated per-IP-block TBs. But I do hope there is a better way.

 

Thanks!

Tags (2)
0 Kudos
2 Replies
Highlighted
Moderator
Moderator
502 Views
Registered: ‎05-31-2017

HI jaruiz@kaleao ,

If you are willing to simulate the complete BD then the only way is that for sure you should have the wrapper generated for that BD and instantiate it in TB. 

Highlighted
Contributor
Contributor
482 Views
Registered: ‎11-28-2018

I only need to simulate a few blocks of the many that make up the BD but yes, I think the easiest way to do it would be building a BD around them and generating a wrapper, etc. as you suggest.

 

Instead of the BD I have concocted a scheme that unpacks the IP blocks in question, generates their simulation sources, extracts the library dependencies, etc. so the blocks can be tested on a regular non-BD test bench. It works and is generic enough to be usable in other cases like this (no hardcoded dependencies) but it certainly looks fragile and jury-rigged.

 

Thanks for your suggestion!

0 Kudos