Subject: [vhdl-200x-dta] Re: Best testbench style for microprocessor bus simulation
From: Jim Lewis (Jim@SynthWorks.com)
Date: Thu Jan 29 2004 - 15:28:54 PST
VHDL-200X DTA topic hits about the middle of this thread.
Jim Lewis <Jim@SynthWorks.com> wrote:
>>What it sounds like you want is a transaction based
>>testbench. Using procedures is a good start:
>>
>> -- Baud Rate = 115200. ExtClk = 20 MHz. Divisor = 11
>> CpuWrite(CpuRec, UART_DIVISOR_HIGH, X"0000");
>> CpuWrite(CpuRec, UART_DIVISOR_LOW, X"000A");
Jonathan Bromley wrote:
>
> [...]
>
> Is it just me, or does anyone else find this pretty clumsy?
>
... Snip ...
>
> I like to add one additional layer of encapsulation, adding a
> "wrapper" procedure in the stimulus-generator process...
>
> -- architecture contains the CPU-interface record CpuRec,
> signal CpuRec: CpuRec_Type;
> -- and this process that does the work...
> CPU_stimulus_generator: process
>
> -- Wrapper procedure:
> procedure CpuWrite(in REG: Reg_Adrs_Type; in DATA: Data_Type) is
> begin
> CpuWrite(CpuRec, REG, DATA);
> end;
>
> -- and more procedures for CpuRead, etc, etc
>
> begin
> ...
> CpuWrite(UART_DIVISOR_HIGH, X"0000");
> CpuWrite(UART_DIVISOR_LOW, X"000A");
> ...
> end process;
>
> 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!
First, I feel your pain. However, since we have
worked the procedures down to only having one extra
signal, the record, I don't feel it that much. To
remove this one signal name, you propose to add the
clutter of the translation procedures and potential
simulation inefficiency of the additional layer of
procedure calls.
Engineering wise, there is probably a balance point.
Your suggestion probably works great if there are only
a few procedures and if no additional procedures will be
added.
I think I would always be willing to type the extra
name. If I was really that concerned about it, I would
make the record name C.
The language is up for revision, so rather than argue
about the merits of the wrapper approach, I would
prefer to brain-storm on language changes that would
help this situation.
The VHDL-200X Data Types and Abstractions (DTA) group
(headed by Peter Ashenden) is looking at adding generics
to packages (including type generics). One of the
things that comes with this is instantiatable
packages. So I have been wondering, if I instantiate
a package in a process declaration region, can the
package see signals in the process environment and
can procedures in the instantiated package see signals
by side-effect? This most would solve the same problem.
Currently it is planned that this feature will be based
on the SUAVE proposal (but perhaps with some syntax
changes). For links to the SUAVE work, go to:
http://www.eda-twiki.org/vhdl-200x/vhdl-200x-dta/proposals/proposals.html
Another problem I have with using a single record is that
the record must be inout (both the transaction source and
the BFMs drive elements of the record). This limits the
record to use of types with a resolution function - and in
my case I take the easy way out by using the std_logic
family. Currently there is a fast track proposal to address
this issue by making it possible to specify modes of record
elements individually. For more information see:
http://www.eda-twiki.org/vhdl-200x/vhdl-200x-ft/proposals/ft17_composite_interface_mode.txt
Comments welcome. :)
More information on the VHDL-200X is at:
http://www.eda-twiki.org/vhdl-200x
Anyone can participate as an observer. If you are an IEEE member
and a DASC member you can be a voting member and vote on issues.
However, do note people do listen and are concerned about the
issues of observers. Speaking as the team leader of the
modeling and productivity group and co-team leader of
fast track, I would welcome people with language skills like
Jonathan and Mike to contribute to working group proposal
writing.
Cheers,
Jim
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Thu Jan 29 2004 - 15:32:06 PST