Subject: Re: Brainstorming VHDL 200x
From: lancet@us.ibm.com
Date: Wed Apr 19 2000 - 06:17:29 PDT
1. We thought of global signal too. Some synthesis tools didn't care for
that very much. In addition, design reuse was a bit of a pain using global
signals. So they weren't very portable either... I've also considered
(and still do) that the VHDL API work may be more appropriate for
"breaking" the hierarchy. A standard mechanism is what I want. When I
think of this in VHDL terms, I think of a new syntax like "probe" or
reusing an existing syntax like alias. In either case, I think it would be
easy to identify misuse. In a "synthesizeable" design, one would be
prohibited from using an "out of scope" name. I don't consider this
"dumbing down."
2. Clocked processes would still be written as process( your_clk_here )
style.
3. No, I don't mean entity instantiation. This request has to do with
synthesis and managing design information more than anything else. If I
have a reusable design, it will typically have generics. If that design is
large enough, I might want to synthesize it on its own. Synthesis tools
allow a method of passing generics through a command interface. The
question is, how are those generics documented as part of the design.
True, in the instantiation of this design, I'll have to associate the
generics, but what assures that the generics I associate in the
instantiation match the generics I pass by command? Now, I can do this
today by adding a "wrapper" layer but that is more work than a
configuration that sets the generics...
5. Wolfgang reminded me that reduction operator would be nice. I think
that is what he meant by his comment to my number 4. z <= and d; might
mean that all the bits of d are anded together for a single bit result.
Lance
Wolfgang.Ecker@infineon.com on 04/19/2000 02:28:15 AM
Please respond to stds-vasg@ieee.org
To: stds-vasg@ieee.org
cc:
Subject: AW: Brainstorming VHDL 200x
A few comments to the thoughts
1. We use global signals declared in a package to get access to signals
deep inside a design hierarchy. The advantage is, that the access to the
signals remains even if the hierarchy changes. Another advantage is, that
the TB-code is more re-usable, due to the fact, that we do not have to
specify a hierarchy to requested signal, which in turn is mostly different
between different designs. So, I personally do not need access over unit
boundaries.
2. Looks good, could be defined similarly to drivers (when a driver has to
be
created).
3. Do you mean entity instantiation here? For component isntantiation, this
should be possible.
4. Declaring the vector wide logical operations for that types would help
much
also.
- Wolfgang
-----Ursprüngliche Nachricht-----
Von: lancet@us.ibm.com [mailto:lancet@us.ibm.com]
Gesendet am: Dienstag, 18. April 2000 21:05
An: stds-vasg@ieee.org
Betreff: Re: Brainstorming VHDL 200x
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.
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.
3. A means (through configuration declaration, I think) to set the formals
of an entity other than by instantiation. As I understand it, the formals
of the "top" entity in a configuration declaration cannot be bound. That
binding may only occur by instantiating the "top"
4. A way to make some types more like subtypes. For example,
std_ulogic_vector and std_logic_vector... It's true that they are closely
related and one can use type conversion, but it would be nice for them to
be like std_ulogic and std_logic.
Cheers,
Lance
This archive was generated by hypermail 2b28 : Wed Apr 19 2000 - 08:21:29 PDT