Subject: Re: Brainstorming VHDL 200x
From: Evan Lavelle (eml@riverside-machines.com)
Date: Wed Apr 19 2000 - 01:22:03 PDT
lancet@us.ibm.com wrote:
>
> A few thoughts...
>
> 1. A means to cross scope and visibility boundaries. It is frequrently
> necessary in a "test bench" to read and/or write signals deep in the design
> under test. Reading signals (or variables for that matter) is useful for a
> test bench to understand the state of the design under test. Based on the
> designs state, test benches may choose different (more stressful) inputs.
> Writing to a "signal" is interesting so that a test bench can force bad
> machine behavior. Writing signals, of course, has to deal with the
> semantics of updating a signal. There are cases where one wants to add a
> driver to a resolved signal. There are other cases where one wants to
> override the effective value of the signal. Still other cases exist where
> one wants to override the effective value with a function of the effective
> value.
It seems to me that visibility rules are fundamental to any high-level
language. Adding a mechanism to bypass the rules will remove the
encapsulation and error-checking benefits of the rules, and would make
the rules pointless. Ok, this would be useful in a testbench, but how
can the analyser tell that this particular usage is an allowed testbench
usage, and not just an "incorrect" piece of code? Surely the solution
isn't to dumb down the language.
Anyone verifying a program in a.n.other high-level language, such as C,
has exactly the same problem that we have, and they solve it in the same
way - they define the object to which they require visibility at an
outer scope level, ie. they make it external or, in our case, make it
package-resident. This doesn't seem to be an issue in C development.
However, if this isn't appropriate, then I think the correct place to
deal with the problem is in the simulator (we need somewhere to 'break'
the language, so the obvious place is the sim). For instance, to read a
hidden signal in ModelSim, you can add a trigger signal in the
testbench, and arrange for the trigger to be driven if the required
signal changes:
when { /tb/uut/U10/req_signal } {
force /tb/trigger
$examine(/tb/uut/U10/req_signal)
}
Ok, this isn't portable, but this problem is only relevant during
development, when a single simulator will generally be used.
> 2. A short-hand notation to denote a process sensitivity list that
> contains all the names read in that process. Process( all ) comes to my
> mind. This would ensure that simulation and synthesis results "match" in
> level sensitive storage element inference.
Good idea. I suppose the only downside is that simulation of clocked
processes will be slower if this is used indiscriminately. I suspect
that there will also be combinatorial cases in which pre- and post-synth
sims will differ (can't think of one right now) but this will be a case
of buyer bewares.
Evan
This archive was generated by hypermail 2b28 : Wed Apr 19 2000 - 01:32:31 PDT