Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Why do VHDL testbenches not usually include hierarchical signals fo the DUT

Status
Not open for further replies.

matrixofdynamism

Advanced Member level 2
Joined
Apr 17, 2011
Messages
593
Helped
24
Reputation
48
Reaction score
23
Trophy points
1,298
Activity points
7,681
While a testbench can be written that treats the DUT as a black box i.e provide input stimulus and then compare the output with expected values, it would be advantageous to be able to assert values of internal signals also in RTL simulation. I understand that this may not be possible once the design has been synthesized which will change the internal details of the design.

All the examples and application notes I have seen of VHDL testbench yet create a testbench which only looks at the top level signals of the entity under test. Is looking inside the DUT to create a testbench that is more thorough in its verification activity discouraged? I have heard/read that VHDL 2008 includes the possibility to use hierarchical signal names. However, all tools may not support it yet.

So my question is, why don't I find testbench examples that use hierarchical signals in the DUT to verify the design? Is it not "orthodox" practice yet or does it have some serious drawbacks?
 

This is something that has existed in Verilog since the beginning. I specifically use it to access internal nodes like reset generator outputs to determine when the TB can start sending data. Hence I don't have to resort to long timeouot delays waiting for the reset to complete. You'll see stuff like that done on other Verilog testbenches.

VHDL though only introduced this in 2008, so typically what happens is people learn a language and any updates never become part of their repertoire. Similar to the problem with Verilog still being taught with ports declared in the module declaration and also as wire/reg signals. Instead of using the simpler C style syntax for module port declarations in Verilog 2001 (it's 2016 and pretty much every mainstream tool supports this syntax now).

It's understandable when a new feature is introduced and users are hesitant to use the new language feature due to portability problems between tools. Unless users complain about missing features or the tool vendor "cares" about compatibility of their tool with the latest standard, then introduction of support can vary between quickly to never. FPGA vendors tend to lean towards the never side and big tool vendors lean towards the quickly side.
 
Modelsim/Questa has had the signal spy library/tools for a long time (google search takes me to posts from 2003!) that allow you to get to any signal in the hierarchy in the same way you can in verilog/vhdl2008.

As for examples - Im with ADS-EE. People dont learn new stuff very quickly. Those that want the feature probably are using signal spy, otherwise they are just working around it. If you are doing real black box testing you have zero access to the internals (otherwise it's called grey or white box!). Have a google on this for examples. eg. http://www.pldworld.com/_hdl/2/_ref/se_html/manual_html/c_vhdl29.html

Personally Im of the opinion that you should only ever read signals like this - driving them would be a crazy thing to do, unless you're trying to force errors.
 
  • Like
Reactions: shaiko

    shaiko

    Points: 2
    Helpful Answer Positive Rating
Personally Im of the opinion that you should only ever read signals like this - driving them would be a crazy thing to do, unless you're trying to force errors.

Been there done that, testing for error conditions that should never happen unless some random particle hits the silicon is impossible without doing something like this. Without this it's hard to check if your recovery logic will work or not, or if it will even detect the problem in the first place!

Before anyone asks, yes I've worked on stuff that required that level of reliability, i.e. can't shutdown/power_cycle/reset, but still has to recover gracefully without intervention.
 

Interesting post.

This is something that has existed in Verilog since the beginning.

Can you please post a good example of how this is done in Verilog?
 

Interesting post.
Can you please post a good example of how this is done in Verilog?

Something like...
te0630_top_inst.cpu_top_inst.i_core_top.i_pipeline_top.i_alu_top.blk_mem_gen_v7_3_1x16384_cfi_inst.inst.native_mem_module.blk_mem_gen_v7_3_inst.memory == 1'b1

The above piece of code shows comparison of memory (located somewhere deep in the design), with a 1 bit value in the test-bench.
 
  • Like
Reactions: shaiko

    shaiko

    Points: 2
    Helpful Answer Positive Rating
The above piece of code shows comparison of memory (located somewhere deep in the design), with a 1 bit value in the test-bench.


And how do you force a value?
 

te0630_top_inst.cpu_top_inst.i_core_top.i_pipeline _top.i_alu_top.blk_mem_gen_v7_3_1x16384_cfi_inst.i nst.native_mem_module.blk_mem_gen_v7_3_inst.memory = 1'b1
 
  • Like
Reactions: shaiko

    shaiko

    Points: 2
    Helpful Answer Positive Rating
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top