UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor jmhbfe
Visitor
406 Views
Registered: ‎05-24-2018

combining pre- and post-implementation libraries for simulation

I have a design, let's call it top, in top.v.  top instantiates module1 as module1_0.

 

I have a testbench, call it top_tb in top_tb.v.  It instantiates top.  It also instantiates module1 as module1_1 for itself.  (E.g., module1 in the testbench communicates with module1 in the design.  Like rs232 or i2c or spi.)

 

When simulating post-implementation, xsim generates a design netlist into <proj>.sim/sim_1/impl/func/xsim/top_tb_func_impl.v.  This includes module1 (module1_0), but it has several new ports as a result of optimizations.  It compiles this netlist into xil_defaultlib.

 

Then it compiles the testbench top_tb.v into xil_defaultlib, then it compiles the instantiated module1 (module1_1) into xil_defaultlib, and overwrites the previous definition.  Now the version of module1 in xil_defaultlib does not have the new ports.

 

Then it elaborates, and finds that the instantiation of module1 in top_tb_func_impl.v uses ports for module1 that are not in the definition for module1 in xil_defaultlib.  Duh.

 

I have tried bracketing the instantiation of module1 in top_tb.v with a "`uselib lib=tb_lib / `uselib" pair.  No difference.  I tried adding a config block to top_tb.v with "instance top_tb/module1_1 liblist tb_lib".  No difference.  In both cases, no errors or warnings, either.

 

How do I:

A) get the original RTL for module1, as instantiated in top_tb, to compile into tb_lib instead of xil_defaultlib, and

B) get xelab to bind the instantiation in top_tb to the definition in tb_lib, while still binding the instantiation in top to the definition in xil_defaultlib?

0 Kudos
4 Replies
Moderator
Moderator
343 Views
Registered: ‎04-24-2013

Re: combining pre- and post-implementation libraries for simulation

Hi @jmhbfe,

 

Which version of the tools are you using and can you supply a test project that shows the issue?


Best Regards
Aidan

 

------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if this answered your question
Give Kudos to a post which you think is helpful and may help other users
------------------------------------------------------------------------------------------------------------------
0 Kudos
Visitor jmhbfe
Visitor
334 Views
Registered: ‎05-24-2018

Re: combining pre- and post-implementation libraries for simulation

Aidan, thank you for responding.

 

Using 2018.1.  Targeting Artix-7 device that's not supported in 2018.2 WebPack.  I can probably throw together a test case but I won't be paid to do so. :)  As far as I know the problem will occur any time a module is used in both the design and the testbench.  The netlist of the post-implementation version of the module, with the same name, will have different ports than the testbench version.

 

The obvious approach is to compile the testbench version into a library other than xil_defaultlib (like tb_lib), but I can't figure out how to map the binding in xelab, i.e., the testbench binds to the version in tb_lib, and the design binds to the version in xil_defaultlib.  Pretty straightforward kind of problem.  There's an answer record that says to use a config block that specifies the binding on a per-instance basis, but either it's ignored or I don't know how to get xelab to use it.  I tried pointing xelab to the config block instead of the testbench top and running it manually, didn't help.  The config block does show up in tb_lib with no warnings or errors, just doesn't seem to do anything.  In any case, xelab seems to scan the default library before bothering with the config block, and since there are about 100 other instances that have to bind with the default libraries, I can't exactly remove the default library list and specify ALL the instances.  Might work, though.  Should be an exercise for someone who's actually being paid to solve these kinds of problems.

 

There's an ancillary problem with using two libraries, that Vivado can't keep track of where it loads the glbl module--seems to like to put it into xil_defaultlib, but then xelab looks for it as tb_lib.glbl in work, or some such drivel.  Workaround is to either provide my own copy of glbl.v and put it where it belongs, or to simply copy the glbl.sdb from xil_defaultlib into tb_lib.  But in the latter approach, first you have to reset the post-implementation simulation, run it, let it fail, then copy glbl.sdb, and re-run the sim.  Make any changes, start all over.

 

I tried supplying parameters that I otherwise wouldn't need in the hopes that a parameterized version would have a different name in the netlist.  Nope.  The first instantiation, even if it's parameterized, keeps the nominal name.

 

I also tried editing the post-implementation netlist to manually change all the offending module names (both definition and instantiations), but there's no easy way to run the simulation without Vivado blithely re-creating the netlist!

 

A more or less workable workaround is to make a complete copy of ALL the modules used in both the design and the testbench, and CHANGE the names of the testbench versions, but then if you make any changes to any of the modules you have to remember to change it in both places.  Very poor design flow.  I did it anyway, and now xelab/xsim (can't tell which) crashes with ERROR: [XSIM 43-3294] Signal EXCEPTION_ACCESS_VIOLATION received.  Since there's now nothing special about the design or the testbench, the crash is...well, something else.  Something for a different forum thread.

 

The obvious approach from Xilinx point of view would be to change the names of all modules in the netlist, just like it does with parameterized modules, but do so with ALL modules that are in any way changed from the pre-synth version.  Poof.  All the problems disappear.  I mean, ALL of them.  Well, except maybe the crash.

 

I'll see what I can come up with.

 

jmh

0 Kudos
Visitor jmhbfe
Visitor
329 Views
Registered: ‎05-24-2018

Re: combining pre- and post-implementation libraries for simulation

Can't get any simpler than this.

0 Kudos
Visitor jmhbfe
Visitor
321 Views
Registered: ‎05-24-2018

Re: combining pre- and post-implementation libraries for simulation

Apparently turning off "preserve hierarchy" can alleviate or eliminate the problem, too, but that can mess up internal path names that may be important in .xdc files, for example....
0 Kudos