how do I test signals in a testbench that are 1 or 2 levels down in the UUT?

There has to be a way to do this, right?

If I want to test a signal in the UUT, I just have to do this in my testbench:

if(txcomstart /= '0') then error

Reply to
Dan K
Loading thread data ...

Dan K wrote: ...

Maybe google for a vhdl testbench example to get started.

Here's one:

formatting link

-- Mike Treseler

Reply to
Mike Treseler

If this is VHDL, then there isn't. Well-known limitation of the language Most simulators have a work-around. For ModelSim this is 'SignalSpy'.

Reply to
RCIngham

...

As mentioned by Robert if you use Modelsim then look up SignalSpy which is very powerful and dead easy to use. If you use Riviera then you might be able to use VHDL2007/8. I am not 100% sure if the VHDL2007/8 syntax below is correct but it might look something like this:

txcomstart

Reply to
HT-Lab

e

As others have mentioned, SignalSpy may give you what you want to do, but I'd also suggest that if you get in the habit of designing components and testbenches to test those components that you won't need to have a testbench dig down into the hierarchy in the first place.

  1. Create a testbench for 'instance.vhd' and validate that 'instance.vhd' is working as expected.
  2. Now that 'instance.vhd' is a tested known good widget, it can be included in 'UUT' and a testbench created for UUT. The things that the UUT testbench tests are the outputs of UUT, there is no need for testing signals internal to UUT or anything that it may happen to instantiate.

If you think creating testbenches for each individual entity/ architecture is more trouble than it's worth (and in some cases it might be) then you're implicitly saying you're willing to debug those things working at a higher level in the design hierarchy. Even in that situation though, every single one of those embedded widgets all the way up and down the design hierarchy will all still have some effect that can be tested for all the way back up to the top level and therefore by a system level testbench.

One could conclude from that observation that there is only a need for a system level testbench and that would technically be correct, but in all but the simplest designs would be a serious problem since it is not likely that a system level testbench model would adequately cover and test all of the possible usage scenarios (i.e. how it works in the real world).

If you really want to see if some signal in some widget buried down in the hierarchy is working as intended but don't want to create a testbench to verify proper operation, then simply add the signal to the wave window and view that it is working as intended.

Kevin Jennings

Reply to
KJ

If you are testing the internal signal completely within the context of the internal entity/architecture in which it appears, then you can create either a procedure or a function called by an assertion statement within that architecture, to monitor that signal. The procedure could update a scoreboard, etc. to manage error status and reporting, or just handle reporting locally. It can be turned on and off based on a generic, or simply escaped with synthesis_on/off comments if you always want it simulated. Assertion statements are generally ignored by synthesis only, so any function they called would be ignored automatically. One of the advantages of this method is that it is automatically available to be used with any testbench that includes the entity/architecture. Design it, test it, integrate it; the test goes with the functionality wherever it is used. Of course this requires modifying the source code to insert your checking code. If you have separate personnel/organizations for design and verification, then the functions/procedures need to be stubbed out in a package and inserted into the design by the designer, then that package can be maintained by the verification folks.

If this signal is a port on a buried instance somewhere, and you used components and configurations to build up the hierarchy, you could use a configuration to replace the architecture of interest with a different "wrapper" architecture that re-instances the entity/ architecture and includes instrumentation code around it. This is one of the few situations where I would consider the overhead and pain of components and configurations to be worthwhile.

Andy

Reply to
Andy

I tried that with Riviera 2007.06, which did not seem to understand it. I could not find anything in the docs about that syntax. I have not downloaded the newest version of Riviera yet, so maybe that was added very recently. In the version I have, you use a "signal_agent" to access internal signals.

Reply to
Duane Clark

Thanks for trying it out. I did a search and found some VHDL2006 info (Riviera-Pro 2008.02) on the Aldec Website but I couldn't find anything related to hierarchical references.

formatting link

Hans

formatting link

Reply to
HT-Lab

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.