«

Jonathan Bromley wrote:

> So far, so traditional. But I still find it offensive to have to
> name the connections every time I invoke the procedure. Am I alone?

I agree. To get around that I
keep the procedures in the
process scope instead
of packaging them.



> I like to add one additional layer of encapsulation, adding a
> "wrapper" procedure in the stimulus-generator process...

That sounds like a better way to do it.


> The wrapper procedures simply take general-purpose package
> procedures like CpuWrite(rec, adrs, data) and specialise them
> with the signals that will be used by that specific process.
> There's no loss of portability, and IMHO a great gain in clarity
> of the mainstream stimulus generator code. Even in complicated
> cases, the wrapper procedures are simple and short.
>
> Criticism welcome!


Can't think of a criticism.
Looks clean to me.
I will try it out.
Thanks for the posting.



-- Mike Treseler

Mike Treseler wrote:
> Jonathan Bromley wrote:
>
>> So far, so traditional. But I still find it offensive to have to
>> name the connections every time I invoke the procedure. Am I alone?
>
>
> I agree. To get around that I
> keep the procedures in the
> process scope instead
> of packaging them.

Every engineering problem probably has the right thing
that works for it. For me, this approach works well for
tests where there is only one test in the test suite and
there is only one engineer runnig the verification.
My experience with this was that once you have more than
one test (or more than one verification engineer), then
you can end up with a maintence issue. Find a bug in a
procedure, fix it in many places. To get around this on
one project, I split the file into multiple pieces and then
merged them to create an entire testbench - yuck.

In addition, from an organizational point of view, having
the procedures in a package makes it easier to identify the
test from the support code.

Going further, for my system-level testbenches (which I also
use for subblock testing), the procedure only packs
transactions into record. I use a separate bus functional
model to handle to implement the signal protocol, as well
as other functionality, such as protocol checkers (looking
for bad things happening on the interface - for example
in a memory model I have one that looks for simultaneous
read and write).

It is also possible to architect a testbench that the additional
things I like putting in the BFM live in a separate model. One
nice thing about having them in a BFM with the functionality is
that I can keep an error count of each type, and then at the end
issue a transaction to the model that causes the error count to
be printed for each separate, and then return an accumulated
value.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~
Jim Lewis
Director of Training private.php?do=newpm&u=
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~