OUT, INOUT and BUFFER
Paul Uiterlinden
I have some questions/thoughts about the mode of port signals. It
seems to me that most people are using OUT for normal (unidirectional)
outputs. To me, this seems not correct, because it causes two
problems:
1) A port signal can not be read.
2) A signal can be driven by multiple outputs of mode OUT.
The first problem is resolved by either using an intermediate signal
(which is cumbersome), or using the mode INOUT (which I find terrible,
because the interface becomes less clear), or using mode BUFFER
(which I think is the correct way).
The second problem is settled by using unresolved signals, or
(again) by using mode BUFFER. Using unresolved signals has the
disadvantage of introducing an extra TYPE, causing the need of
calling conversion functions (which is inconvenient) when
assigning for example a std_logic_vector to an std_ulogic_vector.
All in all, in my opinion the `correct' usage of the modes is:
IN : inputs
BUFFER : outputs that never are tri-stated
OUT : tri-statable outputs (unidirectional)
INOUT : real bidirectional ports
I know problems occur when combining components written according
to the rules above, and components not using BUFFER. However, when
applied consistently, these rules only has advantages, and seem
more in line with the `spirit of VHLD' (or more consistent with
the hardware it is supposed to describe).
This brings a last question in mind: what is the `spirit of VHDL'?
Or: why have the rules been made as they are? The LRM (1987) is not
of much help here: it just states the rules, and not their reasons.
I hope someone can provide some thoughts and background information
(or pointers to such info).
--
Paul Uiterlinden
Lucent Technologies
Bell Labs Innovations
Botterstraat 45 Tel : +31 35 687 4892
P.O. Box 18 Fax : +31 35 687 5964
1270 AA Huizen Email : uiter...@lucent.com
the Netherlands
Dan Prysby
The table as given looks simple.
When using VHDL for real world designs, several problems may appear.
One recent one:
1. using type IN for top level I/O input pins with internal
pullup/pulldown components.
The vendor library may set the pullup port type to INOUT, the
input buffer input port is of type IN so then the I/O port must be
set to type INOUT.
Can't be an IN because this port can be driven by the pullup.
This is CONFUSING - seeing INOUT on ports that are inputs,
yet this is the only syntax that is correct if this condition
exists.
Dan Prysby
Paul Uiterlinden wrote:
I have some questions/thoughts about the mode of port signals. It
seems to me that most people are using OUT for normal (unidirectional)
outputs. To me, this seems not correct, because it causes two
problems:
1) A port signal can not be read.
2) A signal can be driven by multiple outputs of mode OUT.
The first problem is resolved by either using an intermediate signal
(which is cumbersome), or using the mode INOUT (which I find terrible,
because the interface becomes less clear), or using mode BUFFER
(which I think is the correct way).
The second problem is settled by using unresolved signals, or
(again) by using mode BUFFER. Using unresolved signals has the
disadvantage of introducing an extra TYPE, causing the need of
calling conversion functions (which is inconvenient) when
assigning for example a std_logic_vector to an std_ulogic_vector.
All in all, in my opinion the `correct' usage of the modes is:
IN : inputs
BUFFER : outputs that never are tri-stated
OUT : tri-statable outputs (unidirectional)
INOUT : real bidirectional ports
-snip-
Richard Iachetta
Paul Uiterlinden <uiter...@lucent.com> wrote in article <333BEB3B...@lucent.com>...
> This brings a last question in mind: what is the `spirit of VHDL'?
> Or: why have the rules been made as they are? The LRM (1987) is not
> of much help here: it just states the rules, and not their reasons.
Paul, I agree with your concerns. I don't know what the 'spirit of VHDL'
is regarding these things, but I personally believe (strongly) that we
should be able to feedback a signal of mode OUT back into the
module and use it -- especially if it is not a top level module. Its a
royal pain that for every signal of mode OUT that feeds back, I have
to create an internal signal with a different name and then assign
the output to that internal signal at the end. It make the language
more cumbersome and harder to read. You're right that INOUT is
not appropriate because nothing is coming 'in'. BUFFER may be a
good solution but 1) it is not as descriptive as OUT and can be
misleading because for internal modules, there is no actual
buffer device and 2) There are a number of restrictions and
limitations on ports of mode BUFFER that caused Peter
Ashenden to write in the book THE DESIGNERS GUIDE TO
VHDL, "These restrictions severely limit the uses
of buffer ports, so they are not commonly used in practice".
So, we've been avoiding them and using internal signals that
are assigned at the end to the port of mode OUT.
--
Richard Iachetta
IBM Corporation
iach...@vnet.ibm.com
Jari Mutikainen
Hello VHDL-users,
> Richard Iachetta wrote:
>
> I don't know what the 'spirit of VHDL'
> is regarding these things, but I personally believe (strongly) that we
> should be able to feedback a signal of mode OUT back into the
> module and use it -- especially if it is not a top level module. Its a
> royal pain that for every signal of mode OUT that feeds back, I have
> to create an internal signal with a different name and then assign
> the output to that internal signal at the end.
I agree 100%. I have NEVER met ANY VHDL-user, who likes this @#$$%*
restriction of VHDL. I haven't ever understood why on earth the 'makers' of
VHDL made the language this way. Is there anybody out there, who wants
to have it this way ? Why ?
Hey, you VHDL-VIPs reading this newsgroup,
Would it be possible to change this aspect of the language in the next
release of the VHDL-standard ? If this was changed, the current designs
would still work, wouldn't they? There would be just another level of
freedom in the future. I'm sure every VHDL-user in the world would
appreciate it from the bottom of his/her heart.
Kind Regards Jari Mutikainen
P. Cnudde VH14 (8218)
Jari Mutikainen wrote:
> I agree 100%. I have NEVER met ANY VHDL-user, who likes this @#$$%*
> restriction of VHDL. I haven't ever understood why on earth the 'makers' of
> VHDL made the language this way. Is there anybody out there, who wants
> to have it this way ? Why ?
>
Sorry to disappoint you but I like this feature and I do consider myself
to be a VHDL user.
The reason why I consider this to be correct is simple: Analogy with the
semantics of procedures.
I find it very good from protection point that a variable in a procedure
of type "OUT" is not readable within the procedure itself. Having this a
different way would result is lot's of problems. (What would you put in
the sensitivity list of concurrent procedure calls for example)
I simply like that OUT means OUT and not something else.
Once you agree that it is logical for procedures then you should accept
that it would make no sense to have a different semantic for entities.
> Hey, you VHDL-VIPs reading this newsgroup,
> Would it be possible to change this aspect of the language in the next
> release of the VHDL-standard ? If this was changed, the current designs
> would still work, wouldn't they? There would be just another level of
> freedom in the future.
If you want freedom: use verilog. (and C)
If you want safety and compiler built-in protection: use VHDL (and ADA)
Peter
--
________________
_________________________________________________\ /______
\ /
Peter Cnudde Alcatel Telecom
Voice: 32-3-240 8218 Switching Systems Division
Paper: 32-3-240 9947 Francis Wellesplein 1
mailto:cnu...@sh.bel.alcatel.be 2018 Antwerpen, Belgium
______________________________________________________\ /___________
\ /
\/
John Derrick
Jari Mutikainen wrote:
>
> Hello VHDL-users,
>
> > Richard Iachetta wrote:
> >
> > I don't know what the 'spirit of VHDL'
> > is regarding these things, but I personally believe (strongly) that we
> > should be able to feedback a signal of mode OUT back into the
> > module and use it -- especially if it is not a top level module. Its a
> > royal pain that for every signal of mode OUT that feeds back, I have
> > to create an internal signal with a different name and then assign
> > the output to that internal signal at the end.
>
> restriction of VHDL. I haven't ever understood why on earth the 'makers' of
> VHDL made the language this way. Is there anybody out there, who wants
> to have it this way ? Why ?
>
> Would it be possible to change this aspect of the language in the next
> release of the VHDL-standard ? If this was changed, the current designs
> would still work, wouldn't they? There would be just another level of
> appreciate it from the bottom of his/her heart.
>
> Kind Regards Jari Mutikainen
I have to state the obvious. Restrictions like this do have purpose.
If you work on very large projects with many, many designers, I have,
this is a very useful restriction. It is not unlike the
"restrictiveness" of an object oriented language. Sometimes it doesn't
appear to be a win. Almost always however, if you add enough people to
the project the picture changes..
Richard Iachetta
John Derrick <jder...@austin.ibm.com> wrote in article
<334128...@austin.ibm.com>...
John, I'm just not seeing the benefit, small project or large. If a module
port is declared as OUT, the language can still enforce that nothing can
come 'in' on that port. But inside the module, the designer needs to be
able to use that signal -- its just a signal that goes to an output port.
Every other hardware language I've ever used allows this because its
such a natural thing to do in hardware. Can you give a specific example
of where this restriction is a win? Does it outweigh the potential for
mistakes due to the added confusion of extra signals with different
names just to drive out of the module?
Janick Bergeron
Richard Iachetta wrote:
> John, I'm just not seeing the benefit, small project or large. If a module
> port is declared as OUT, the language can still enforce that nothing can
> come 'in' on that port. But inside the module, the designer needs to be
> able to use that signal -- its just a signal that goes to an output port.
> Every other hardware language I've ever used allows this because its
> such a natural thing to do in hardware. Can you give a specific example
> of where this restriction is a win? Does it outweigh the potential for
> mistakes due to the added confusion of extra signals with different
> names just to drive out of the module?
Here is what I think is the reason behind the interdiction on reading an
OUT port:
Since VHDL's intent is to model hardware, you have to think about the
hardware implication of "reading" and OUT port. Electrically, ports have
no direction: a pin on a device will carry a signal in either direction.
If you "read" an output pin, you are using the pin as an inout
*electrically*.
If, on the other hand, you want to read whatever you are driving out,
that
means that you must buffer your feedback point from the outside world
i.e. use
an internal signal.
I therefore disagree that it is such a "natural thing to do in hardware"
because, in hardware, the port is an INOUT (unless buffered of course in
which
case you are implementing the equivalent of the internal signal or
BUFFER port).
Just think about how you would synthesize an OUT port that you read
back...
In Verilog, pin directions are simply advisory: in reality ALL pins are
inouts.
VHDL decided to logically enforce the port directions hence the
restrictions
on IN and OUT ports and the BUFFER port.
Now, can anyone tell me what LINKAGE ports are for? I think it is for
the coolant fluid, but I could be wrong
--
Janick Bergeron Qualis Design Corporation Ph.: (503)
350-3663
Director of PO Box 4444 Fax: (503)
643-1583
Technology Beaverton, OR, USA, 97075-4444
jan...@qualis.com
VHDL - Verilog - Synthesis - Modelling - Verification -
Training
use STD.DISCLAIMER.all; library QUOTE; use
QUOTE.FUNNY;
William Billowitch
Janick Bergeron wrote:
>
> Now, can anyone tell me what LINKAGE ports are for? I think it is for
> the coolant fluid, but I could be wrong
Late in the 20'th century, after 10 years of searching, it appears
that digital designers world wide are still in search of the meaning
of the elusive LINKAGE port.
Rumor has it that one of the original VHDL language designers had
problems
with the drive train in his car. He started to write a letter to his
car dealer asking for a new linkage pArt to use in replacing the
defective one. Through accidental cut and paste, portions of this letter
were transferred into the VHDL LRM. Someone in the standards group,
reading the LRM draft, felt embarrased not to know what the linkage
part actually meant, but realized that surely someone mistyped
PART instead of PORT. As with most standards, once something makes it
into the draft, it takes dynamite to get it out...the rest is history
:-)
Prof. I. Lirpa
Shannon Hill
The problem with OUT is that RTL can implicitly
consume the OUT value, like a register that holds
its value...
D : in std_logic ;
Q : out std_logic ;
begin
process begin
if( enable = '1' ) then
Q <= D ;
end if;
end process;
When this RTL is CAN BE EXPLICITLY used as an gate's input! This
means your compile-for-simulation of the synthesized
result will fail.
We discovered this while trying to simulate vhdl
equations synthesized from RTL.
Ports of mode OUT may have some benefit to someone,
but we NEVER use them here. (Long live BUFFER.)
+----------------------------+----------------------------+
| Shannon Hill | em: hi...@synnet.com |
| 3COM Switching Division | fx: 508-264-1861 |
| 80 Central Street | ph: 508-264-1420 |
| Boxborough, MA 01719 | (email or fax preferred) |
| gender=M +----------------------------+
+----------------------------+
Richard Iachetta
Janick Bergeron <jan...@qualis.com> wrote in article
<3341B003...@qualis.com>...
I think we're talking about 2 different things. At the top level of your
chip,
you need to have output buffers, physically. The signal at the output of
the buffer is different from the signal at the input (by a delay at least)
and so should have a different name. But VHDL is forcing us
to treat every 'internal' module as a mini-chip in itself. For internal
modules, the concept of "driving out of the module" does not apply.
There is no driver or buffer other than the gate creating the signal.
Its just a signal that is "read" by gates outside the module and can just
as easily be "read" by gates inside the module. The port should not be
INOUT because you want to enforce that nothing comes 'in'.
Richard Iachetta
P. Cnudde VH14 (8218) <cnu...@sh.bel.alcatel.be> wrote in article
<3340C6...@sh.bel.alcatel.be>...
>
> If you want freedom: use verilog. (and C)
> If you want safety and compiler built-in protection: use VHDL (and ADA)
>
> Peter
I want freedom. :-) Rather than beat this subject to death, let me turn
to a different gripe. It would really be great if VHDL allowed you to
mix boolean expressions with equations. Verilog allows this, as
does Abel and I think AHDL (but its been a while since I've used
AHDL). An example:
y <= bus_gnt and (read or write)
and enabled and (address = REG1) and (state = S5);
Most other languages would know to expand the boolean to logic for
evaluation so if S5 was defined as "101" then (state = S5) in this
context means (state(0) and not state(1) and state(2)). In VHDL,
you either have to write it like that or do something like:
y <= '1' when (bus_gnt = 1') and ((read = '1') or (write = '1'))
and (enabled = '1') and (address = REG1) and (state = S5);
else '0';
For equations that have many single bit terms, the above way of
writing it is much more cumbersome. And while we're at it, it
would be great if the boolean compare on a standard_logic_vector
could compare to a hex number. So, something like:
(address = 0xfffe3754) would generate an equation that is true
if the bits of address match that hex number. Right now you
have to specify 0xfffe3754 as "11111111111111100011..." or
specifiy a constant that is equal to all those bits written out.
William Billowitch
Richard Iachetta wrote:
>
> P. Cnudde VH14 (8218) <cnu...@sh.bel.alcatel.be> wrote in article
> <3340C6...@sh.bel.alcatel.be>...
> >
> > If you want freedom: use verilog. (and C)
>
> y <= bus_gnt and (read or write)
> and enabled and (address = REG1) and (state = S5);
>
> Most other languages would know to expand the boolean to logic for
> evaluation so if S5 was defined as "101" then (state = S5) in this
> context means (state(0) and not state(1) and state(2)). In VHDL,
> you either have to write it like that or do something like:
>
> y <= '1' when (bus_gnt = 1') and ((read = '1') or (write = '1'))
> and (enabled = '1') and (address = REG1) and (state = S5);
> else '0';
>
> For equations that have many single bit terms, the above way of
> writing it is much more cumbersome. And while we're at it, it
> would be great if the boolean compare on a standard_logic_vector
> could compare to a hex number. So, something like:
> (address = 0xfffe3754) would generate an equation that is true
> if the bits of address match that hex number. Right now you
> have to specify 0xfffe3754 as "11111111111111100011..." or
> specifiy a constant that is equal to all those bits written out.
>
> --
> Richard Iachetta
> IBM Corporation
> iach...@vnet.ibm.com
Well Richard,
The language supports everything you asked for....
Function "=" (constant l : std_logic_vector;
constant r : bit_vector ) return std_logic;
would allow you to write:
std_logic_lval := (address = 16#fffe3754#)
exactly as you wanted. Better read the section of the LRM on
overloaded operators and based literals.
We built a package set called the Std_Regpak which provides
many of the functions you are requesting here.
--
Sincerely,
-------------------------------------------------------------
William Billowitch e-mail : w...@vhdl.com
The VHDL Technology Group Web : http://www.vhdl.com
100 Brodhead Road, Suite 140 Phone : 610-882-3130
Bethlehem, PA 18017 Fax : 610-882-3133
Volker Hetzer
John Derrick wrote:
>
> Jari Mutikainen wrote:
> >
> > Hello VHDL-users,
> >
> > > Richard Iachetta wrote:
> > >
> > > I don't know what the 'spirit of VHDL'
> > > is regarding these things, but I personally believe (strongly) that we
> > > should be able to feedback a signal of mode OUT back into the
> > > module and use it -- especially if it is not a top level module. Its a
> > > royal pain that for every signal of mode OUT that feeds back, I have
> > > to create an internal signal with a different name and then assign
> > > the output to that internal signal at the end.
> I have to state the obvious. Restrictions like this do have purpose.
> If you work on very large projects with many, many designers, I have,
> this is a very useful restriction.
Then, why is this a useful restriction?
Volker
Ross Swanson
Paul Uiterlinden wrote:
>
> All in all, in my opinion the `correct' usage of the modes is:
>
> IN : inputs
> BUFFER : outputs that never are tri-stated
> OUT : tri-statable outputs (unidirectional)
> INOUT : real bidirectional ports
>
> to the rules above, and components not using BUFFER. However, when
> applied consistently, these rules only has advantages, and seem
>
Buffer ports are to restrictive so its to diffcult
to be 'consistent' when a team of people are sharing/reusing
code:
If a component instance has a port of type buffer tied to
a port of the entity then that port must be type buffer.
If a entity has a port of type buffer which is associated
to a formal port of a component instance then the formal
port can not be type out.
Buffer ports can only have one source.
Tom Phinney
Shannon Hill <hi...@synnet.com> wrote in article <33425F...@synnet.com
<snip>
> but we NEVER use them here. (Long live BUFFER.)
When I started using VHDL, I had to work with a vendor's synthesizer with a
Beta VHDL front-end that did not support BUFFER. So I used only OUT and
std_logic/std_logic_vector.
Later I worked with more-experienced colleagues who had a number of space-
and aircraft-qualified chips under their belts. They taught me to use
BUFFER and std_ulogic/std_ulogic_vector wherever possible (i.e., wherever
the driven net should have exactly one driver).
Why? Because BUFFER and std_ulogic/std_ulogic_vector imply exactly one
driver, and the available tools will note an error either if the net is
undriven or if it has more than one driver. No testing or synthesis
required.
Also, a BUFFER output is available locally for internal use, since the
value on the driven net is always the value that the BUFFER is driving.
(This is not true for an OUT, where the net value can be different than
that driven by the OUT.)
Within a chip we use OUTs and std_logic/std_logic_vector only for
multi-driven nets, and BUFFERs everywhere else that an output is needed.
When we need to do low-level structural design, we use core cell models
with BUFFERs for 2-state outputs, and with OUTs for 3-state outputs. Pad
cell models are as needed: BUFFER for 2-state outputs, OUT for 3-state
outputs, INOUT for bidirectionals or input pads with pullups, pulldowns, or
integral bus repeaters.
I haven't used LINKAGE yet, but I've seen it used in pad cell models for
non-signals: analog and Vdd/Vss.
In summary, VHDL permits fine specification of intent, which designers of
life-critical or mission-critical chips frequently use.
Tom Phinney
Honeywell
Tom Phinney
Richard Iachetta <iach...@vnet.ibm.com> wrote in article
<01bc3f97$128c08b0$dce42381@gaia>...
>
> I want freedom. :-) Rather than beat this subject to death, let me turn
> to a different gripe. It would really be great if VHDL allowed you to
> mix boolean expressions with equations. Verilog allows this, as
> does Abel and I think AHDL (but its been a while since I've used
>
> y <= bus_gnt and (read or write)
> and enabled and (address = REG1) and (state = S5);
<snip>
--------------
Booleans have two states. Std_logic has nine. The presumption that
booleans can substitute for standard logic is based on the belief that "if
it's not true, it must be false." How about if it's undefined, or gone to
'X'?
It's easy to write a function EQ(l,r) to compare two scalars or same-length
vectors and propagate all nine values. This preserves the std_logic
semantics. The above would become
y <= bus_gnt and (read or write)
and enabled and eq(address, REG1) and eq(state, S5);
Note that this approach also preserves the semantics of
idle <= not eq(state, S5);
whereas, for the requested functionality (booleans as two-valued
std_logic),
idle <= not (state = S5);
would return a value of '1' when state was undefined.
My first chip using VHDL was based on an earlier design in AHDL, and had a
large number of gated clocks for ultra-low power. We had a lot of trouble
getting rid of the logic faults induced by the above boolean
mis-conceptualization.
We finally solved the problem by using the above EQ functions and by
replacing if/then/else/end if sequences with case/when/when others/end case
sequences to handle all of the undefined cases. After replacement the
simulator found previously masked uninitialized states.
Tom Phinney
Honeywell
Paul Uiterlinden
Shannon Hill wrote:
>
> The problem with OUT is that RTL can implicitly
> consume the OUT value, like a register that holds
> its value...
>
> D : in std_logic ;
> Q : out std_logic ;
> begin
>
> process begin
> if( enable = '1' ) then
> Q <= D ;
> end if;
> end process;
>
> When this RTL is CAN BE EXPLICITLY used as an gate's input! This
> means your compile-for-simulation of the synthesized
> result will fail.
I am not quite sure what you mean with "can be explicitly used as
an gate's input". And what is it that fails? Could you please
elaborate on this?
Janick Bergeron
In article <01bc3f88$ce5f8580$dce42381@gaia>,
Richard Iachetta <iach...@vnet.ibm.com> wrote:
>I think we're talking about 2 different things. At the top level of your
>chip,
>you need to have output buffers, physically.
logically needed but *does* modify the logic of the feed-back point.
What I think we are arguing about is the value of VHDL in enforcing
that your feed-back point be before the buffer is the port is OUT or BUFFER,
otherwise use an INOUT port.
> The signal at the output of
>the buffer is different from the signal at the input (by a delay at least)
>and so should have a different name.
Agreed. Hence the BUFFER port or the internal signal methodology:
the actual signal on the port is NOT the same as the signal fed back.
> But VHDL is forcing us
>to treat every 'internal' module as a mini-chip in itself. For internal
>modules, the concept of "driving out of the module" does not apply.
>There is no driver or buffer other than the gate creating the signal.
Why? I can just as easily put another driver on the signal connected to
the OUT port internally in a chip. That additional driver, once implemented,
will affect the feedback value because there is no output buffer, hence the
port is really an INOUT. Whether that was the intent or not is another matter.
>Its just a signal that is "read" by gates outside the module and can just
>as easily be "read" by gates inside the module. The port should not be
>INOUT because you want to enforce that nothing comes 'in'.
And how do you enforce that? That's EXACTLY what the BUFFER port is and
does. That's also why the BUFFER port has all those (apparently) weird
limitations... What you are asking for is already available in VHDL.
I understand (and share) your frustration, but this is a small annoyance
for the certainty that what you are simulating is what you'll be building
electrically.
Richard Iachetta
William Billowitch <w...@vhdl.com> wrote in article
<3342C0...@vhdl.com>...
>
> The language supports everything you asked for....
>
> Function "=" (constant l : std_logic_vector;
> constant r : bit_vector ) return std_logic;
> would allow you to write:
>
> std_logic_lval := (address = 16#fffe3754#)
>
> exactly as you wanted. Better read the section of the LRM on
> overloaded operators and based literals.
>
> We built a package set called the Std_Regpak which provides
> many of the functions you are requesting here.
Sounds great. But where do I get Std_Regpak? Neither my
simulator nor my synthesizer has it. Thanks.
Richard Iachetta
>Richard Iachetta <iach...@vnet.ibm.com> wrote in article
><01bc3f97$128c08b0$dce42381@gaia>...
>>
>> I want freedom. :-) Rather than beat this subject to death, let me
turn
>> to a different gripe. It would really be great if VHDL allowed you to
>> mix boolean expressions with equations. Verilog allows this, as
>> does Abel and I think AHDL (but its been a while since I've used
>> AHDL). An example:
>>
>> y <= bus_gnt and (read or write)
>> and enabled and (address = REG1) and (state = S5);
>
Tom Phinney <tom.p...@ibm.net> wrote in article
<01bc3ff6$ce464e30$50e32581@t_phinney_2>...
> Booleans have two states. Std_logic has nine. The presumption that
> booleans can substitute for standard logic is based on the belief that
"if
> it's not true, it must be false." How about if it's undefined, or gone
to
> 'X'?
Good point. But actual hardware never tries to compare something to
X, U or Z for example; just 1's and 0's. That's why I think that 1's and
0's can be implied in the compare. I define how I would like to see it
work below.
>
> It's easy to write a function EQ(l,r) to compare two scalars or
same-length
> vectors and propagate all nine values. This preserves the std_logic
> semantics. The above would become
>
> y <= bus_gnt and (read or write)
> and enabled and eq(address, REG1) and eq(state, S5);
>
Ok, but... Then I'd have to write EQ, other functions for less than,
greater than, less than or equal, etc. when all that is built into
VHDL's Boolean compare. I also think the Boolean compare is
more readable than functions in an equation. I also worry
that the synthesizer may do a poorer job synthesizing
functions in the middle of equations but perhaps that worry
is unfounded.
> Note that this approach also preserves the semantics of
>
> idle <= not eq(state, S5);
>
> whereas, for the requested functionality (booleans as two-valued
> std_logic),
>
> idle <= not (state = S5);
>
> would return a value of '1' when state was undefined.
>
Again, good point, but I think its reasonable that the
compare should return 'U' if 'U', 'X', 'Z', 'W' or '-' were involved
in any way on the right or left side. I don't know if I couldn't define it
such that most VHDL users would be happy, but I personally would be
happy if the boolean equal, in the context of an equation compare, would
return '1' when the left is '0' or 'L' and the right is '0' or 'L' or when
the
left is '1' or 'H' and the right is '1' or 'H', else return 'U'. Some
might
argue that with this definition you can't compare to 'U' or 'Z' for
example. You still can with the old ways; just not inside an equation like
this. The only reason to compare to stuff like 'U', etc. is for simulation
code and you wouldn't use this construct for simulation code. You'd
use it to design hardware.
>
> My first chip using VHDL was based on an earlier design in AHDL, and had
a
> large number of gated clocks for ultra-low power. We had a lot of
trouble
> getting rid of the logic faults induced by the above boolean
> mis-conceptualization.
>
> We finally solved the problem by using the above EQ functions and by
> replacing if/then/else/end if sequences with case/when/when others/end
case
> sequences to handle all of the undefined cases. After replacement the
> simulator found previously masked uninitialized states.
>
Gated clocks? Fun stuff. I think if it worked the way I described, you
would have still found the uninitialized states because the compare would
return 'U'.
Richard Iachetta
Janick Bergeron <jan...@qualis.qualis.com> wrote in article
<5i0n10$m...@news.rain.net>...
> In article <01bc3f88$ce5f8580$dce42381@gaia>,
> Richard Iachetta <iach...@vnet.ibm.com> wrote:
> > But VHDL is forcing us
> >to treat every 'internal' module as a mini-chip in itself. For internal
> >modules, the concept of "driving out of the module" does not apply.
> >There is no driver or buffer other than the gate creating the signal.
> Why? I can just as easily put another driver on the signal connected to
> the OUT port internally in a chip. That additional driver, once
implemented,
> will affect the feedback value because there is no output buffer, hence
the
> port is really an INOUT. Whether that was the intent or not is another
matter.
>
Janick, This is the best explanation I've seen for the restriction. I
didn't think
about other drivers outside the module that can drive onto the output and
would
hence have to affect the feedback into the module. I never do that myself
inside
a chip but I know some people do internal tri-stateable busses, etc.
Thanks.
Tom Phinney
Ross Swanson <swa...@est07.md.essd.northgrum.com> wrote in article
<3342C9...@est07.md.essd.northgrum.com>...
-----------
VHDL's features can help you if you let them. Here is a set of rules which
we arrived at empirically, and which really work for us:
1) Any net that logically has a single driver should be declared, at all
module levels in the hierarchy, as std_ulogic or std_ulogic_vector and the
port type at the module interfaces should be IN or BUFFER.
2) Any net that logically has multiple drivers should be declared, at all
driving module levels in the hierarchy, as std_logic or std_logic_vector
and the port type at the module interfaces should be OUT or INOUT. If all
of the drivers are limited to a single module (and perhaps its instantiated
sub-modules), and the signal is to be exported from the module (toward the
root of the hierarchy), then the signal should be cast/converted to a
similarly-named std_ulogic or std_ulogic_vector and then exported through a
BUFFER port. This rule can be ignored where external considerations (such
as testbench requirements) require that the driven signal be std_logic or
std_logic_vector.
3) In general, IN ports should use std_ulogic or std_ulogic_vector. This
means that a cast/conversion from std_logic or std_logic_vector may be
necessary in the instantiating hierarchy level. This rule can be ignored
where it makes more sense to do the cast/conversion within the module, such
as at the level of the chip pads.
4) Within library cells, all 2-state outputs where both states are actively
driven (the norm) should be declared as BUFFERs. All 3-state outputs and
single-ended outputs of library cells should be declared as OUTs.
Within a chip, these rules lead to heavy use of BUFFERs and std_ulogic /
std_ulogic_vector for normal nets. Tri-state nets and some nets with
multiple single-ended drivers (fast carry logic and some dynamic logic come
to mind) become the only internal std_logic / std_logic_vector nets.
Externally, the environment is not as well determined, and so external
inputs to the chip can be declared either as std_logic or std_ulogic; this
decision should be based on your standard project practice. Declaring the
external signals as std_logic means that the inputs will need a
conversion/cast at the point of logical pad-cell instantiation; declaring
the external signals as std_ulogic is more consistent with the internal
practice, facilitating reuse of the design as a macro, but may require
cast/conversion in the testbench or board level of the hierarchy.
Many may disagree with these rules; no problem :-). But these rules do use
the capabilities of VHDL for maximal early error detection -- each
std_ulogic net must have EXACTLY one driver. Also, in general the number
of extra signals required for std_logic nets which have dual std_ulogic
nets [because of the conversion/casts of (2) and (3)] will be less than the
number of extra signals that will be required to provide output values
within a module declared with OUTs.
It took us quite a while to evolve this set of rules; they do work well.
Tom Phinney
Honeywell Inc.
Industrial Automation and Control
Andrew Hana
: All in all, in my opinion the `correct' usage of the modes is:
: IN : inputs
: BUFFER : outputs that never are tri-stated
: OUT : tri-statable outputs (unidirectional)
: INOUT : real bidirectional ports
I agree - it is the usage that we have used for many years - without any problems.
Andrew
Andrew Hana
Richard Iachetta (iach...@vnet.ibm.com) wrote:
: and 2) There are a number of restrictions and
: limitations on ports of mode BUFFER that caused Peter
: Ashenden to write in the book THE DESIGNERS GUIDE TO
: VHDL, "These restrictions severely limit the uses
: of buffer ports, so they are not commonly used in practice".
: So, we've been avoiding them and using internal signals that
: are assigned at the end to the port of mode OUT.
: --
I've never had any problems with using BUFFER. What are these restrictions?
The only 'restriction' that I can think off that has any major impact is the
one that restricts direct connects of BUFFERs and OUTs and INOUTs. Yes, there
is a restriction, but generally,
1) Connectivity is easily handled with a graphical entry tool - which should
generate the correct VHDL when mixing BUFFERs and OUTs - all that is needed
is a connecting signal. Any VHDL generating tool should be able to handle
that.
2) If you're not using a graphical entry tool, then component instantiations
must be a real pain for you, and having the extra complexity of inserting
a connecting signal is something you could do without. In this instance,
sticking to one mode is best.
3) If OUTs are never used, then BUFFERs work just fine.
Have I missed something?
Andrew
Janick Bergeron
In article <01bc4175$df2f0130$70e32581@t_phinney_2>,
Tom Phinney <tom.p...@ibm.net> wrote:
>
> (VHDL guidelines)...
>
Big BIG (and many) thumbs up!!!!!
Johnny Smooth
Jumpin' in late, but I haven't seen it mentioned yet...
In VHDL'93 I believe there is an attribute sig'DRIVING_VALUE
(I think that's its name ) that you can use on an OUT
to make it's value available internal to the block. At
least you don't have to create another signal... :-/
--
John
"Whoever undertakes to set himself up as a judge in
the field of Truth and Knowledge is shipwrecked by
the laughter of the gods."
Albert Einstein
Brandon Azbell
That is true. Unfortunately, when working with Synopsys,
which currently only supports VHDL'87, that is a "feature"
which can not be exploited.
--
Regards,
Brandon Azbell Texas Instruments
Technical Staff - ASIC Applications and Design Chicago Design Center
b-az...@ti.com
Shannon Hill
Tom Phinney wrote:
>
...
> 1) Any net that logically has a single driver should be declared, at all
> module levels in the hierarchy, as std_ulogic or std_ulogic_vector and the
> port type at the module interfaces should be IN or BUFFER.
>
...
--
The problem with using std_ulogic and std_ulogic_vector is that the
standard IEEE (and the synopsys-supplied add-ons) packages do not
fully overload all the functions for both flavors; std_logic and
std_ulogic are fully implemented, while std_ulogic and
std_ulogic_vector are not.
Trying to follow this practice where unidriver nets are all
std_ulogic* turned into a big hassle, so we gave up. The
fundamental 9-state type we use is std_logic & std_logic_vector,
which seems to work well for both our sim and synth tools.
We also noticed a tremendous difference in simulation
performance depending on whether the design was std_ulogic
or std_logic. Surprisingly, some simulators are faster with
std_logic, others are faster with std_ulogic. Amazing.
Stephen A. Bailey
Ross Swanson <swa...@est07.md.essd.northgrum.com> wrote in article
<3342C9...@est07.md.essd.northgrum.com>...
> Paul Uiterlinden wrote:
> >
> > All in all, in my opinion the `correct' usage of the modes is:
> >
> > IN : inputs
> > BUFFER : outputs that never are tri-stated
> > OUT : tri-statable outputs (unidirectional)
> > INOUT : real bidirectional ports
> >
> > I know problems occur when combining components written according
> > to the rules above, and components not using BUFFER. However, when
> > applied consistently, these rules only has advantages, and seem
> > more in line with the `spirit of VHLD' ...
> >
> Buffer ports are to restrictive so its to diffcult
> to be 'consistent' when a team of people are sharing/reusing
> code:
Perhaps you should find a vendor that supports VHDL '93.
In VHDL '93, you can read the driving value of an output port
using new predefined attributes:
if P'Driving_Value = '1' then
...
else
...
end if;
Also, if you use guarded signals (BUS or REGISTER kind),
you can use the predefined attribute 'Driving to determine
if the process is currently driving the signal before getting
the driving value via 'Driving_Value.
--
Stephen Bailey
VeriBest Inc.
6101 Lookout Rd., Suite A
Boulder, CO 80301
mailto:sba...@veribest.com http://www.veribest.com
voice: 303-581-2467 fax: 303-581-9972
Steve Gibson
Richard Iachetta wrote:
<snip>
> Tom Phinney <tom.p...@ibm.net> wrote in article
> <01bc3ff6$ce464e30$50e32581@t_phinney_2>...
> > Booleans have two states. Std_logic has nine. The presumption that
> > booleans can substitute for standard logic is based on the belief that
> "if
> > it's not true, it must be false." How about if it's undefined, or gone
> to
> > 'X'?
>
> Good point. But actual hardware never tries to compare something to
> X, U or Z for example; just 1's and 0's. That's why I think that 1's and
> 0's can be implied in the compare. I define how I would like to see it
> work below.
>
Havn't been following this thread, hope I don't have this out of
context, but the above comment about "actual" hardware is a gross
simplification, a usefull model in some cases ( basic digital logic
courses for instance), it can be argued that "actual" hardware is
*never* just 1s and 0s but some signal level *greater than* or *less
than* some threshold(s). In actual hardware there is any number of ways
to generate an X, U, Z, for example, don't drive the line (tri-state).
I have found this aspect of VHDL usefull for EXACTLY this reason, ie.
modeling the start-up behaviour of self-starting circuits.
(digital oscilators etc.)
Just my 2c worth.
Regards,
--
Steve Gibson
ADI Limited, CCIS Systems Group
Email: gib...@ccis.adisys.com.au
Snail: 22 Stirling Hwy
Nedlands
Western Australia
Nbrs : (tel) +61 9 333 8917 (fax) +61 9 333 8889
Richard Iachetta
Steve Gibson <gib...@ccis.adisys.com.au> wrote in article <334BFD...@ccis.adisys.com.au>...
> Richard Iachetta wrote:
> > Good point. But actual hardware never tries to compare something to
> > X, U or Z for example; just 1's and 0's. That's why I think that 1's and
> > 0's can be implied in the compare. I define how I would like to see it
> > work below.
> >
> <snip>
>
> Havn't been following this thread, hope I don't have this out of
> context, but the above comment about "actual" hardware is a gross
> simplification, a usefull model in some cases ( basic digital logic
> courses for instance), it can be argued that "actual" hardware is
> *never* just 1s and 0s but some signal level *greater than* or *less
> than* some threshold(s). In actual hardware there is any number of ways
> to generate an X, U, Z, for example, don't drive the line (tri-state).
> I have found this aspect of VHDL usefull for EXACTLY this reason, ie.
> modeling the start-up behaviour of self-starting circuits.
> (digital oscilators etc.)
Steve, My above quote does not say that actual hardware is just 1's
and 0's. I think that's clear even without the context. The context of the
quote was a discussion of whether or not it makes sense to allow
constructs like: (i.e. mixture of equation and boolean compares)
Y <= A and B and C and (Address = Some_Constant_Vector);
where Y, A, B and C are std_logic and the term in () is a Boolean
compare. When a designer writes an equation like that, he is
specifying a compare within an equation. My observation is that
he does not intend to create hardware that "compares" things like
'X' and 'Z'; he's just specifying a 1's and 0's compare circuit and
the synthesizer will generate gates for that accordingly just like
it will generate an AND gate for the "A and B" part. That's why
I was lobbying for the above shorthand notation to the legal
VHDL which is:
Y <= '1' when (A = '1') and (B = '1') and (C = '1') and
(Address = Some_Constant_Vector) else '0';
This form gets a little unwieldy with more terms and the
shorthand that I want is permitted in other HDLs.
Jari Mutikainen
Hello all (again),
Richard Iachetta wrote:
> The context of the
> quote was a discussion of whether or not it makes sense to allow
> constructs like: (i.e. mixture of equation and boolean compares)
>
> Y <= A and B and C and (Address = Some_Constant_Vector);
>
> where Y, A, B and C are std_logic and the term in () is a Boolean
> compare.
> That's why
> I was lobbying for the above shorthand notation to the legal
> VHDL which is:
>
> Y <= '1' when (A = '1') and (B = '1') and (C = '1') and
> (Address = Some_Constant_Vector) else '0';
I agree with Richard. I'd love to have this possibility in VHDL too.
And as Richard already pointed out, this is nothing but a shorthand
notation for something, that already is part of VHDL. Thus there
shouldn't be any 'philosophical reasons' for objecting his proposal.
Here is my next idea for improving VHDL: Make it possible to
access (at least read) signals through the levels of hierarchy.
Quite often in my test bench I would like to sample and write some
internal signal value into a file. I'd like to be able to refer to
that signal through the level of hierarchy
like "TOP.CORE_LOGIC.COLUMN_COUNTER_1.COUNT".
Of course, I don't want this possibility to be accepted for synthesis !
But it should be allowed for testbenching (= simulation purposes).
Any comments on this ?
Kind Regards Jari Mutikainen
David Fura
>Richard Iachetta wrote:
>
>> The context of the
>> quote was a discussion of whether or not it makes sense to allow
>> constructs like: (i.e. mixture of equation and boolean compares)
>>
>> Y <= A and B and C and (Address = Some_Constant_Vector);
>>
>> where Y, A, B and C are std_logic and the term in () is a Boolean
>> compare.
>> That's why
>> I was lobbying for the above shorthand notation to the legal
>> VHDL which is:
>>
>> Y <= '1' when (A = '1') and (B = '1') and (C = '1') and
>> (Address = Some_Constant_Vector) else '0';
>I agree with Richard. I'd love to have this possibility in VHDL too.
>And as Richard already pointed out, this is nothing but a shorthand
>notation for something, that already is part of VHDL. Thus there
>shouldn't be any 'philosophical reasons' for objecting his proposal.
VHDL already supports what you want - it just takes some work that's all. One
possibility is to overload '=' to operate over std_logic, taking two
std_logics as input and returning std_logic as output. In other words
you could write a new function. I guess you'd want to return '1' for
exact compares and '0' otherwise.
You could also overload the "and" operator to operate on one std_logic and
one boolean, returning std_logic. Although I like the other option better.
>Here is my next idea for improving VHDL: Make it possible to
>access (at least read) signals through the levels of hierarchy.
>Quite often in my test bench I would like to sample and write some
>internal signal value into a file. I'd like to be able to refer to
>that signal through the level of hierarchy
>like "TOP.CORE_LOGIC.COLUMN_COUNTER_1.COUNT".
>Of course, I don't want this possibility to be accepted for synthesis !
>But it should be allowed for testbenching (= simulation purposes).
>Any comments on this ?
This is a superb idea and should be added by default unless there is some
*very* good reason not too. I could never understand why this wasn't put in
originally.
David Fura
Levetate Design Systems
df...@levetate.com
Janick Bergeron
In article <dfura.7....@seanet.com>, David Fura <df...@seanet.com> wrote:
>>Richard Iachetta wrote:
>>Here is my next idea for improving VHDL: Make it possible to
>>access (at least read) signals through the levels of hierarchy.
>>Quite often in my test bench I would like to sample and write some
>>internal signal value into a file. I'd like to be able to refer to
>>that signal through the level of hierarchy
>>like "TOP.CORE_LOGIC.COLUMN_COUNTER_1.COUNT".
>
>>Of course, I don't want this possibility to be accepted for synthesis !
>>But it should be allowed for testbenching (= simulation purposes).
>
>>Any comments on this ?
>
>This is a superb idea and should be added by default unless there is some
>*very* good reason not too. I could never understand why this wasn't put in
>originally.
Hierarchical names are two edged swords. They can be very powerful
but I have seen many verilog models reach dead ends because hierarchical
names had painted them into a corner. I love them too but use with
caution!
First, hierarchical references require forward referencing i.e. the
ability to reference something before you've actually declared it. In
VHDL, because of the strong type checking, it is not immediately
possible. A possible work around may be to define a "deferred" alias
where the actual aliasing is performed and type-checked at elaboration
time.
Second, hierarchical names depend on a particular structure. How can
you garantee that the structure will be maintained for all possible
applications of your testbench? If you are monitoring the state of a
state machine in a testbench, is that state machine at the same
hierarchical location and has the same name in the behavioral model,
the RTL model, and the gate-level model? Or is it even there at all in
the behavioral model? What if the state register was
modifed/recoded/retimed by the synthesis tool? You would need an
elaboration-time object selection mechanism a la if-generate that
would work for sequential statements (if-generate only works for
parallel statements) so you can switch hierarchical reference based
on the configuration being simulated.
Third, how do you provide hierarchical names that handle if- and
for-generate statements? What happens if the hierarchy is generated
out of the model?
Fourth, how do you enforce their usage for testbenches only? VHDL does
not differentiate between design and testbench entities/architectures.
Fifth, what if the type of the hierarchically accessed object was not
defined at the refering level? The aliasing mechanism alluded to in
the first paragraph would require that the type declaration be moved
to a package, thereby increasing maintenance effort and making an
essentially private type globally visible.
VHDL already supports what you want - it just takes some work that's
all (that should sound familiar :-). Global signals in packages can be
used as a "mailbox" to monitor internal state (albeit 1 delta-cycle
behind) in a fashion independent of the structure. See example below
for monitoring the state of a state machine. Note how the STRING type
is used to keep the state type private.
VHDL toolsets usually provide a mechanism for monitoring internal
values. As long as you don't use the internal value ot drive/control
your testbench, this should be sufficient. Regressionable testbenches
should not depend on checking an internal state value: they are not
supposed to depend on a particular implementation.
Personally, I don't have much use for hierarchical names to signals
and/or variable. But I would love to be able to be able to call
procedures inside en entity e.g. a bus-functional model of the 68000
only has the pins found on a 68k device but contains READ/WRITE cycle
procedures. I would like to be able to call these procedures from my
testbench to cause a cycle to appear on the pins of the 68k. Bus cycle
procedures are not part of the physical interface of a device, yet I
have to had control ports with a made-up protocol to trigger them and
return status information. Hiearchical task calls in Verilog makes using
bus-functional model really easy.
Here's what I would like an entity to look like:
entity MC68000 is
port (...); -- Physical pins
procedure READ(...); -- Procedural interface
procedure WRITE(...);
end;
Components would also have procedural interfaces that could be mapped
just like generics and ports. Each interface procedure is implemented
in the architecture as a process, much like a concurrent procedure call.
The drivers are associated with the process implementing the procedure,
not with the process calling them.
But hey, given the fact that VHDL-93 is not widely available even after
4 years, I'm not holding my breath!!!
--
Janick Bergeron Qualis Design Corporation Ph.: (503) 350-3663
Director of PO Box 4444 Fax: (503) 643-1583
Technology Beaverton, OR, USA, 97075-4444 jan...@qualis.com
VHDL - Verilog - Synthesis - Modelling - Verification - Training
--
-- Copyright (c) 1997 Qualis Design Corporation.
-- All rights reserved.
--
-- Qualis Design Corporation
-- PO Box 4444
-- Beaverton OR 97075-4444
-- Phone: +1-503-644-9700
-- E-mail: in...@qualis.com
-- World Wide Web: http://www.qualis.com
--
package MONITOR_PKG is
signal STATE_IMAGE : STRING(1 to 8);
end MONITOR_PKG;
entity TEST is
end TEST;
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use STD.TEXTIO.all;
use WORK.MONITOR_PKG.all;
architecture BENCH of TEST is
component FSM
port (FRAME_SYNC : in STD_LOGIC;
CLK : in STD_LOGIC;
RESET : in STD_LOGIC);
end component;
for all:FSM use entity WORK.FSM(RTL);
signal FRAME_SYNC : STD_LOGIC;
signal CLK : STD_LOGIC;
signal RESET : STD_LOGIC;
begin
DUT:FSM port map (FRAME_SYNC, CLK, RESET);
process
begin
CLK <= '0'; wait for 10 ns;
CLK <= '1'; wait for 10 ns;
end process;
TEST_PROCEDURE: process
begin
FRAME_SYNC <= '0';
RESET <= '1';
wait until CLK = '1';
RESET <= '0';
FRAME_SYNC <= '0'; wait until CLK = '1';
FRAME_SYNC <= '0'; wait until CLK = '1';
FRAME_SYNC <= '1'; wait until CLK = '1';
FRAME_SYNC <= '0'; wait until CLK = '1';
FRAME_SYNC <= '1'; wait until CLK = '1';
FRAME_SYNC <= '1'; wait until CLK = '1';
FRAME_SYNC <= '0'; wait until CLK = '1';
FRAME_SYNC <= '1'; wait until CLK = '1';
FRAME_SYNC <= '0'; wait until CLK = '1';
FRAME_SYNC <= '0'; wait until CLK = '1';
FRAME_SYNC <= '1'; wait until CLK = '1';
FRAME_SYNC <= '1'; wait until CLK = '1';
RESET <= '1';
wait until CLK = '1';
RESET <= '0';
FRAME_SYNC <= '1'; wait until CLK = '1';
FRAME_SYNC <= '0'; wait until CLK = '1';
FRAME_SYNC <= '1'; wait until CLK = '1';
FRAME_SYNC <= '1'; wait until CLK = '1';
FRAME_SYNC <= '0'; wait until CLK = '1';
FRAME_SYNC <= '0'; wait until CLK = '1';
assert FALSE
report "Simulation completed"
severity FAILURE;
end process TEST_PROCEDURE;
process
variable L : LINE;
begin
wait until CLK = '1';
WRITE(L, "State is " & STATE_IMAGE);
WRITELINE(OUTPUT, L);
end process;
end BENCH;
library IEEE;
use IEEE.STD_LOGIC_1164.all;
entity FSM is
port (FRAME_SYNC : in STD_LOGIC;
CLK : in STD_LOGIC;
RESET : in STD_LOGIC);
end FSM;
use WORK.MONITOR_PKG.all;
architecture RTL of FSM is
type STATE_TYP is (OUT_OF_SYNC, SYNCING, IN_SYNC, SYNC_LOSS);
signal STATE : STATE_TYP;
begin
process (CLK)
begin
if RESET = '1' then
STATE <= OUT_OF_SYNC;
elsif CLK = '1' then
case STATE is
when OUT_OF_SYNC =>
-- Start to sync when a frame sync has been detected
if FRAME_SYNC = '1' then
STATE <= SYNCING;
end if;
when SYNCING =>
-- Go in sync when a second frame sync has been detected
if FRAME_SYNC = '1' then
STATE <= IN_SYNC;
else
STATE <= OUT_OF_SYNC;
end if;
when IN_SYNC =>
-- Remain in sync while a frame sync has been detected
if FRAME_SYNC = '0' then
STATE <= SYNC_LOSS;
end if;
when SYNC_LOSS =>
-- Go back in sync if the frame sync has been recovered
if FRAME_SYNC = '1' then
STATE <= IN_SYNC;
else
STATE <= OUT_OF_SYNC;
end if;
end case;
end if;
end process;
process (STATE)
begin
case STATE is
when OUT_OF_SYNC => STATE_IMAGE <= "OUT_SYNC";
when SYNCING => STATE_IMAGE <= "SYNC'ING";
when IN_SYNC => STATE_IMAGE <= "IN_SYNC ";
when SYNC_LOSS => STATE_IMAGE <= "SYNCLOSS";
end case;
end process;
end RTL;
nsi0412110-alblas
Andrew Hana wrote:
>
> : All in all, in my opinion the `correct' usage of the modes is:
>
> : IN : inputs
> : BUFFER : outputs that never are tri-stated
> : OUT : tri-statable outputs (unidirectional)
> : INOUT : real bidirectional ports
>
>
> Andrew
I agree, but there is one exception. In a vhdl netlist (after
synthesis, with the 'real' components) sometimes 2-state buffers are
put in parallel. At least these buffers should have a port of type
'OUT'. Normally, at this level vhdl is generated and not written, so
this is not really a designer's problem.
Up to now, I haven't seen a book about VHDL in which the reasons of
certain rules and limitations are explained. This would help a lot in
'understanding' VHDL and would prevent people to work around limitations
(like adding intermediate signals to read from ports of type 'out').
In my opinion most limitations of 'out' and 'buffer' are actually
not disadvantages, but advantages. Treating them as such makes life
much easier...
There is, however, one rule I don't understand:
"It is not allowed to connect a signal, coming from a port of type
'out' at a lower level, to a port of type 'buffer'" (almost equivalent
with: "A port of type 'buffer' may have just 1 source").
Does anyone know why??
+----------------------+
| +---------+ |
| | out | buffer |
| | --->|--------->|----
| | | |
| +---------+ |
+----------------------+
Rob Alblas
Lucent Technologies
r.al...@lucent.com
Mark Ronan
... stuff deleted ...
|>
|> Personally, I don't have much use for hierarchical names to signals
|> and/or variable. But I would love to be able to be able to call
|> procedures inside en entity e.g. a bus-functional model of the 68000
|> only has the pins found on a 68k device but contains READ/WRITE cycle
|> procedures. I would like to be able to call these procedures from my
|> testbench to cause a cycle to appear on the pins of the 68k. Bus cycle
|> procedures are not part of the physical interface of a device, yet I
|> have to had control ports with a made-up protocol to trigger them and
|> return status information. Hiearchical task calls in Verilog makes using
|> bus-functional model really easy.
Another useful addition would be multiple PACKAGE BODIES. This would facilitate
the changing of function implementations without forcing the VHDL designer
to comment/eliminate the alternate function implementation. These could be
referenced in the Configuration just like different architectures can be
referenced.
Yet another useful addition would be deferred TYPE definitions. Deferred
TYPE definitions would facilitate and aid type abstraction which is a useful
concept if I want to write a model that uses the same types at all levels
of functional abstraction, yet uses different representations/implementations.
This implies that the designer using a specific type can not access
sub-elements of that type without using a "get" or "put" type function.
Here's an idea:
Package p1 is
type MYINT;
end p1;
Package body1 of p1 is
type MYINT is integer range 0 to 255;
end body1;
Package body2 of p1 is
type MYINT is std_ulogic_vector(7 downto 0);
end body2;
... more stuff deleted ...
Mark
-------------------------------------------------------------------------
| Mark W. Ronan | NORTEL | Phone: +1 (613) 763-4839 |
| VHDL Methodology | P.O. Box 3511 | |
| | Station C | Fax: +1 (613) 763-7241 |
| | Ottawa, Ontario, Canada | |
| | K1Y 4H7 | Email: ma...@nortel.ca |
| | | |
-------------------------------------------------------------------------
| This message may contain information proprietary to Northern Telecom |
| so any unauthorised disclosure, copying or distribution of its i |
| contents is strictly prohibited. |
-------------------------------------------------------------------------
--
Mark
-------------------------------------------------------------------------
| Mark W. Ronan | NORTEL | Phone: +1 (613) 763-4839 |
| VHDL Methodology | P.O. Box 3511 | |
Richard Iachetta
David Fura <df...@seanet.com> wrote in article <dfura.7....@seanet.com>...
> >Richard Iachetta wrote:
> >
> >> The context of the
> >> quote was a discussion of whether or not it makes sense to allow
> >> constructs like: (i.e. mixture of equation and boolean compares)
> >>
> >> Y <= A and B and C and (Address = Some_Constant_Vector);
> >>
> >> where Y, A, B and C are std_logic and the term in () is a Boolean
> >> compare.
>
> >> That's why
> >> I was lobbying for the above shorthand notation to the legal
> >> VHDL which is:
> >>
> >> Y <= '1' when (A = '1') and (B = '1') and (C = '1') and
> >> (Address = Some_Constant_Vector) else '0';
>
> >I agree with Richard. I'd love to have this possibility in VHDL too.
> >And as Richard already pointed out, this is nothing but a shorthand
> >notation for something, that already is part of VHDL. Thus there
> >shouldn't be any 'philosophical reasons' for objecting his proposal.
>
> VHDL already supports what you want - it just takes some work that's all. One
> possibility is to overload '=' to operate over std_logic, taking two
> std_logics as input and returning std_logic as output. In other words
> you could write a new function. I guess you'd want to return '1' for
> exact compares and '0' otherwise.
>
> You could also overload the "and" operator to operate on one std_logic and
> one boolean, returning std_logic. Although I like the other option better.
You can do a lot of neat things if you use VHDL as a programming language
and that's fine for writing models and simulation test benches and such,
but the bottom line for designers is that if the operation is not supported by
the synthesizer, then it doesn't do us any good. Maybe a good synthesizer
will allow you to write functions to overload the equals operator; I'd be a
little surprised, but I don't really know. The synthesizer that I'm currently
using does not support that.
--
Rich Iachetta
IBM Corporation
iach...@vnet.ibm.com
Tom Phinney
nsi0412110-alblas <r.al...@lucent.com> wrote in article
<334DE73E...@lucent.com>...
: <snip>
:
: In my opinion most limitations of 'out' and 'buffer' are actually
: not disadvantages, but advantages. Treating them as such makes life
: much easier...
:
: There is, however, one rule I don't understand:
: "It is not allowed to connect a signal, coming from a port of type
: 'out' at a lower level, to a port of type 'buffer'" (almost equivalent
: with: "A port of type 'buffer' may have just 1 source").
:
: Does anyone know why??
:
: +----------------------+
: | +---------+ |
: | | out | buffer |
: | | --->|--------->|----
: | | | |
: | +---------+ |
: +----------------------+
:
-------------
I agree; this is an aggravating and probably unnecessary restriction.
A port of type out is usually associated with a resolved signal (assuming
out was used for multiple or disconnecting/guarded drivers, else buffer
would have been more appropriate in the first place).
A port of type buffer is usually associated with an unresolved signal,
though this is not required.
That's the only potential source of problems that I see, and clearly is not
an adequate justification for a blanket prohibition. Particularly when the
recast as unresolved could occur in the instantiating port association
list.
And the reasons why one might want a tri-state or otherwise multiply-driven
signal at one hierarchy level to be treated as a singly-driven signal at
outer hierarchy levels are obvious.
So perhaps you should submit this as a response to the current VHDL.org
query for desired features for the next iteration of the VHDL standard.
Tom Phinney
> You can do a lot of neat things if you use VHDL as a programming language
> and that's fine for writing models and simulation test benches and such,
> but the bottom line for designers is that if the operation is not supported
by
> the synthesizer, then it doesn't do us any good. Maybe a good synthesizer
> will allow you to write functions to overload the equals operator; I'd be
a
> little surprised, but I don't really know. The synthesizer that I'm
currently
> using does not support that.
This implies that designers don't need to write testbench code themselves,
which is in line with all the prior discussions in this long chain about why
"std_logic should be equivalent to bit" (my characterizations of "if it's not
a '1', it must be a '0'").
VHDL supports bit and boolean very well, including the obvious isomorphism.
Most toolsets can synthesize bit. IMHO people who need to design in 2-state
logic should use them, and convert to/from std_(u)logic only at the pads or
when driving/receiving an internal tri-state bus.
Of course they could always just use verilog -- a language designed primarily
for synthesis rather than simulation. :) But VHDL was designed for
simulation and description, and I personally find this ability to specify
functionality at an exquisitely fine level to be most useful on difficult
design details (such as gated clocks, ratiometric timing chains, aggressive
ALU designs, etc). It's also wonderful in testbenches, where verilog is much
weaker. (E.g., testing setup and hold without 'last_event is cumbersome at
best.)
Some time ago in this chain I posted a note about how we addressed Richard's
issues in a 1993 design, including using normal function syntax eq(l,r)
rather than overloading of "=" because our tools supported the former but not
the latter.
That note also mentioned our rude awakening to the need to ensure 'X'
propagation through such "=" evaluations. In that case we had converted from
an Altera AHDL-based design and, like Richard, found the inability to mix
boolean and std_logic bothersome. But the design itself was aggressively
low-power for an explosive environment, with many gated clocks, on-chip RAM,
and latch/FF resets only where essential (because core cells with a reset are
larger and slower and consume more power). For us, 'X' propagation was an
absolute necessity just to determine the proper programmatic initialization
sequence!
Again IMHO, people who have totally synchronous designs, with global reset
(including all local RAM), can safely ignore 'X' propagation and do their
designs using bit. All others need to assess their potential for getting
into trouble with this simplification (bit instead of stdulogic) and
design/code accordingly.
Tom Phinney
Honeywell Inc
Industrial Automation & Control
Jos De Laender
This is a multi-part message in MIME format.
--------------38946F1579C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mark Ronan wrote:
>
> ... stuff deleted ...
>
>
> Another useful addition would be multiple PACKAGE BODIES. This would facilitate
> the changing of function implementations without forcing the VHDL designer
> to comment/eliminate the alternate function implementation. These could be
> referenced in the Configuration just like different architectures can be
> referenced.
Fully supported ! I asked in the past already why this
is not included (analogous to multiple architectures), but nobody
seems to know a satisfactory answer.
> Here's an idea:
>
> Package p1 is
> type MYINT;
> end p1;
>
> Package body1 of p1 is
> type MYINT is integer range 0 to 255;
> end body1;
>
> Package body2 of p1 is
> type MYINT is std_ulogic_vector(7 downto 0);
> end body2;
>
> ... more stuff deleted ...
--------------38946F1579C
Content-Type: text/plain; charset=us-ascii; name=".@Signature.World"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename=".@Signature.World"
\\\|/// ir. Jos De Laender
( 0 0 ) Alcatel Telecom - SSD (Switching Systems Division)
oo0-(_)-0oo ASIC design - VH14
_\ ' ` /_
\ \ALCATEL/ / F. Wellesplein 1, B-2018 Antwerp, Belgium
\ TELECOM /
\ \ / / E-mail : mailto:jd...@sh.bel.alcatel.be
\ \ / /
o0 Y 0o Alcatel Bell : http://www.bel.alcatel.be
\|/ Alcatel Telecom : http://www.alcatelecom.be
* Phone : (32)(0) 3 240 74 61
Fax : (32)(0) 3 240 99 47
--------------38946F1579C--