Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Defining Stimulus type and encapsulating parameters

Reply
Thread Tools

Defining Stimulus type and encapsulating parameters

 
 
Tricky
Guest
Posts: n/a
 
      04-29-2009
I have the following type I can use in testbenches, normally as a
generic:

type stimulus_type is (random, count, from_file)

following the generic, I have to have other generics like:
RANDOM_SEED, COUNT_FROM, FILE_PATH that define how the stimulus is
constrained. But these generics have to always be present and given
some value, even if they are not used. Annoyingly, I have to have
these 3 secondary generics for each ip stimulus.

Would there be a more clever way of doing it to encapsulate the
parameters better, via subtyped records or something (if thats even
allowed) where I could do something like:

generic (
IP_A_STIM : stimulus_type := (type => from_file, filepath => "c:\data
\some_data");
IP_B_STIM : stimulus_type := (type => random, seed => 12345);
....etc
);

This would probably make it difficult, if not impossible to override
the generic via TCL when you call VSIM, but I thought it was an
interesting thought experiment. I cant think how Id even start -
parsing it might fail as the types wouldnt be the same. Anyone else
with some clever ideas?

 
Reply With Quote
 
 
 
 
Mike Treseler
Guest
Posts: n/a
 
      04-29-2009
Tricky wrote:

> This would probably make it difficult, if not impossible to override
> the generic via TCL when you call VSIM, but I thought it was an
> interesting thought experiment.


My brain is too tired for such an experiment.
I put canned data into the testbench package as
some constant structure. The generic could just be an index
the defaults to the simplest version.

If the stim data is computable,
I generate the constants in the testbench
using a vhdl function.

-- Mike Treseler
 
Reply With Quote
 
 
 
 
Tricky
Guest
Posts: n/a
 
      04-30-2009

>
> * type t_stim_control is record
> * * kind: stinulus_type; -- (random, count, from_file)
> * * random_seed: integer;
> * * count_from: *integer;
> * * file_path: string (1 to 100); *-- sadly this must be constrained
> * end record;


Am I right in thinking with VHDL-2008 standard, when its fully adopted
in 2018, would remove this constraining restriction, allowing the
function to return the record with the given constant string defining
the length?

Another question, how am I going to now override this function call
via the VSIM -gGENERIC=stuff call in TCL? my knowledge of TCL extends
to calling VLIB, VMAP, VCOM and VSIM, though willing to learn/see some
more clever stuff.

Thanks for the help, I think ill borrow this into my
Testbench_tools_package.

Richard
 
Reply With Quote
 
HT-Lab
Guest
Posts: n/a
 
      04-30-2009

"Tricky" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

>>
>> type t_stim_control is record
>> kind: stinulus_type; -- (random, count, from_file)
>> random_seed: integer;
>> count_from: integer;
>> file_path: string (1 to 100); -- sadly this must be constrained
>> end record;

>
>Am I right in thinking with VHDL-2008 standard, when its fully adopted
>in 2018,


I am hoping for 2017 but then again I am an optimist

> would remove this constraining restriction, allowing the
>function to return the record with the given constant string defining
>the length?


Not sure if it is answering your question but VHDL2008 allow type generics
and generics on packages,

>Another question, how am I going to now override this function call
>via the VSIM -gGENERIC=stuff call in TCL? my knowledge of TCL extends
>to calling VLIB, VMAP, VCOM and VSIM, though willing to learn/see some
>more clever stuff.


As a minimum I would learn 3 extra Modelsim Tcl commands, force, examine and
when

Hans
www.ht-lab.com


 
Reply With Quote
 
Tricky
Guest
Posts: n/a
 
      04-30-2009

>
> But I guess you've thought of that, and have a specific
> reason why you don't want it???
>


Actually I didnt really think of that - I was coming at this from the
POV of someone else being presented with the TB and then being
overwhelmed with setup generics, but actually what I didnt consider
was that they are more likely to run it from a TCL script, so this
second method makes ALOT more sense.

Ill still keep the first function in the tool package though - might
be useful one day
 
Reply With Quote
 
JimLewis
Guest
Posts: n/a
 
      04-30-2009
Tricky,
Since Jonathan has already thrown several stones at your
problem, first I will comment.

WRT using records such as, "type t_stim_control is record":
I use these for dynamic controls and make them signals. This
way if I can switch between configurations of my UARTs during
a given test and I don't have to have separate test cases for
it. Note you have to use appropriate synchronization when
switching between different configurations.

I like the initialized generics approach and use this frequently.

Since your switching is static, you could also use separate
architectures for the random and from_file. This adds some
complexity WRT controlling it from a simulation. I typically
use a configuration. With a configuration, I can select
the architecture and map any generics that need to be mapped
or re-mapped. Typically I will leave the generics off the
component and have them only on the entity - this means I can
only map them in the configuration. This also means that each
entity only needs the generics that it uses. Alternately
you could put the entire set of generics on each entity
and the component, but this seems like lots of busy work.

Configurations seem to add some complexity to running your
testbench, but at the end of the day (or project) when you
need to run regressions, all this information is either
specified in a configuration or in your simulation
run script with command line generics. Configurations
allow you to do this in a organized, language standard
fashion. They also allow you to reach down levels of hierarchy,
so there is no need to pass generics through the hierarchy
to get access to them - so I only do this when there is a
logical, encapsulation reason to do this.

With that said, the fine print would also say that I don't
do everything with configurations. For example, I select
between the gate and rtl versions of my design by using
default binding (most recently compiled architecture).
Otherwise, you quickly double the number of configurations
you need.

Cheers,
Jim
SynthWorks VHDL Training
 
Reply With Quote
 
JimLewis
Guest
Posts: n/a
 
      04-30-2009
Richard,
> > * type t_stim_control is record
> > * * kind: stinulus_type; -- (random, count, from_file)
> > * * random_seed: integer;
> > * * count_from: *integer;
> > * * file_path: string (1 to 100); *-- sadly this must be constrained
> > * end record;

>
> Am I right in thinking with VHDL-2008 standard, when its fully adopted
> in 2018, would remove this constraining restriction, allowing the
> function to return the record with the given constant string defining
> the length?


Yes and that works within the function, however, the object to which
you assign the value to must know the size.

OTOH, a protected type with internal variables does this very well.
Unfortunately shared variables cannot currently be design ports.
For now that means putting them in a package and dealing with
issues if you have multiple instances of the same component -
the same issues as putting a record signal in a package.
In VHDL-2008 an interesting option that becomes available is
define the shared variable within the BFM that needs to be
configured and access the shared variable using a hierarchical
reference.

> Another question, how am I going to now override this function call
> via the VSIM -gGENERIC=stuff call in TCL? my knowledge of TCL extends
> to calling VLIB, VMAP, VCOM and VSIM, though willing to learn/see some
> more clever stuff.

You can avoid the command line switches by using a VHDL
configuration

Cheers,
Jim
 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      04-30-2009


I like to use a package to define a record with fields for all the
different generics I might need. Then I pass that record down through
the hierarchy as a generic on every entity (you can use sub-records
for sub-levels of hierarchy if you want). This gives me a language-
defined way (works on any simulator or synthesis tool) to manage
generics in an easy way. If you need to add a generic for a lower-
level entity, just add it to the record, define it at the top, and
extract the value only where it is needed. The record is just a
modifiable conduit through which you can pass anything that you want
down through the hierarchy, without having to manually plumb it
through each intervening level of the hierarchy.

The value of the record generic can be defined at the top level, or
defined in a package, or set by a top-level generic index into an
array of such records defined in a package.

I like to avoid the maintenance headaches of configurations and
component declarations.

What I really want is to use records as signal ports, but with user
defined modes for each element (a single record port consisting of in,
out & inout sub-ports). That way you could use the same "conduit"
technique to pass an entire interface up and down through multiple
levels of hierarchy easily.

Andy
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Stimulus From VCD moogyd@yahoo.co.uk VHDL 2 12-11-2007 09:10 PM
generate stimulus in a 'do' file Guy_Sweden VHDL 3 08-03-2007 01:29 PM
opening an image, using it for simulation stimulus wallge VHDL 3 09-18-2006 02:04 PM



Advertisments