I don't think sensitivity list of a process is necessary
Weng Tianxiang
I have been wondering about why there is a need for Sensitivity List
of a process to exist in VHDL since the first lesson on it.
If I missed a signal in a sensitivity list of a process, VHDL Exemplar
would detect it and give a warning. While doing simulations with
Modelsim, it DOESN'T GIVE A WARNING AND IF A SIGNAL IS MISSED, ANY
ACTION OF THE MISSING SIGNAL WILL BE IGNORED BY THE RULE, CAUSING
PAINFUL "FALSE ERROR": logic is correct, but waveforms are wrong.
Based on advanced software engineering, any currently available VHLD
coompilers SHOULD HAVE THE ABILITY TO AUTOMATICALLY DETECT THE
EXISTENCE OF SENSITIVITY LIST TO A PROCESS.
SO MY QUESTION IS:
Why cannot new version of VHDL suggest to totally drop the concept of
sensitivity list and relieve VHDL users' heavy burder to maintain an
unnecessary SENSITIVITY LIST?
Weng
Andrew MacCormack
difference between a combinatorial process, a flip-flip-inferring
process, a latch-inferring process, synchronous or asynchronous resets,
etc.?
--
___#--- Andrew MacCormack and...@tality.com
L_ _| Senior Design Engineer
| | Tality, Alba Campus, Livingston EH54 7HH, Scotland
! | Phone: +44 1506 595360 Fax: +44 1506 595959
T A L I T Y http://www.tality.com
Paul Baxter
"Andrew MacCormack" <and...@cadence.com> wrote in message
news:3D80C5F7...@cadence.com...
> So, without a sensitivity list, how could the language tell the
> difference between a combinatorial process, a flip-flip-inferring
> process, a latch-inferring process, synchronous or asynchronous resets,
> etc.?
Are you thinking for instance for the case when one day we'll be able to use
both rising and falling clock edges.
process (clk)
begin
a <= b; -- processed whenever there's an event on clk i.e. any edge
end process;
vs.
process
begin
a <= b; -- a bit pointless to use a process
end process;
Mike Treseler
> SO MY QUESTION IS:
> Why cannot new version of VHDL suggest to totally drop the concept of
> sensitivity list and relieve VHDL users' heavy burder to maintain an
> unnecessary SENSITIVITY LIST?
I'm here to testify that you can lay that burden down.
If you write every process like this, you will never have
to maintain another SENSITIVITY LIST:
process (reset, clk)
begin
if reset ='1' then
-- . . .
elsif rising_edge(clk) then
-- . . .
end process;
-- Mike Treseler
Joe Hass
>So, without a sensitivity list, how could the language tell the
>difference between a combinatorial process, a flip-flip-inferring
>process, a latch-inferring process, synchronous or asynchronous resets,
>etc.?
I don't want to sound like I'm flaming or being rude, but I'm not
sure that this argument stands up. If I recall correctly, Synopsys
ignores the sensitivity list for synthesis so the original poster may
have a valid question. I thought about it for a minute and now I
must confess that I'm curious myself...are there examples of where we
really must have a sensitivity list in order to understand the _intent_
of the process?
For example, statements enclosed with an "if (rising_edge'clk)..."
imply an edge sensitive flip flop. Conditional structures that do
not include all possible cases infer a latch. There are similar
ways to infer asynchronous resets. Anything else would be purely
combinational logic.
I understand that having a sensitivity list can make the _simulation_
process more efficient, but do we need it to infer the logic function?
Perspiring minds want to know...
Joe
--
K. Joseph Hass jh...@cambr.uidaho.edu
Center for Advanced Microelectronics & Biomolecular Research
801 University Blvd. SE Suite 206 505-272-7055 (voice)
Albuquerque, NM 87106 505-272-7041 (fax)
Clyde R. Shappee
well! A beauty to behold; a symphony in operation.
The synthesis tools will be very, very kind.
Clyde R. Shappee
Egbert Molenkamp
VHDL can also be used to write testbenches (not synthesisable),
can be used simulation models including timing (not synthesisable either).
Did you ever tried to synthesise a VITAL output (also VHDL)?
You can describe the behaviour of a system in VHDL without
knowing how to implement it. A simple example, I used before, is
a system which only sensitive to a change of A. If A is changed
the outpout should be A and B (B is another input).
With the 'incomplete' sensitivity list this can be easily written as:
process(A)
begin
output <= A and B;
end process;
It is clear that the designer does not want an AND gate!
It is correct VHDL. Since ModelSim is a VHDL simulator ModelSim
indeed can simulate this behavior.
However a synthesis tool can not (yet?) handle an 'incomplete'
sensitivity list. I would prefer that the tooling would
generate an error ("ERROR: incomplete sensitivity list is not
supported) but in fact the tool changed the (intended)
behaviour of the user by adding the signals the tool is
missing (and producing a warning).
(E.g. do you like a compiler that changes your C-code?)
I think there was a proposal, or a discussion in this newsgroup,
to add to the language a construct like:
process(ALL)
begin
..
'ALL' is a reserved word, so it can not be a signal name.
In this case ALL means "all signals read in this process".
This would solve your problem.
Egbert Molenkamp
"Weng Tianxiang" <w...@umem.com> wrote in message
news:511e4538.02091...@posting.google.com...
Jonathan Bromley
> I don't want to sound like I'm flaming or being rude, but I'm not
> sure that this argument stands up. If I recall correctly, Synopsys
> ignores the sensitivity list for synthesis so the original poster may
> have a valid question. I thought about it for a minute and now I
> must confess that I'm curious myself...are there examples of where we
> really must have a sensitivity list in order to understand
> the _intent_
> of the process?
>
> For example, statements enclosed with an "if (rising_edge'clk)..."
> imply an edge sensitive flip flop. Conditional structures that do
> not include all possible cases infer a latch. There are similar
> ways to infer asynchronous resets. Anything else would be purely
> combinational logic.
I think you are correct IF the only thing you ever want to do
is to write conventional synthesisable models; as you have
pointed out, the standard synthesisable templates imply the
required logic structure, without any need to reference the
sensitivity list. And as others have noted, many synthesis
tools do exactly this inference, and either complain about your
sensitivity list if it doesn't agree, or (inexcusably IMHO)
silently "correct" your sensitivity list for you.
HOWEVER...
when writing non-synthesisable code there are situations
in which the sensitivity list is appropriate in order to
specify functionality. Not many, I agree; but there are
such situations. So I totally disagree with the original
poster's suggestion that sensitivity lists are redundant.
I think it's rather a pity that VHDL has never adopted
the notion of a "wildcard" sensitivity list (cf Verilog-2001)
for creating combinational processes. If this construct
existed, it would reduce the effort of writing sensitivity
lists to a negligible level and people would probably stop
whingeing about it.
process (all) -- sensitive to all signals that
-- are ever read in the process
begin
...
end process;
--
Jonathan Bromley
HDL Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: jonathan...@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com
This e-mail and any attachments are confidential and Doulos Ltd. reserves
all rights of privilege in respect thereof. It is intended for the use of
the addressee only. If you are not the intended recipient please delete it
from your system, any use, disclosure, or copying of this document is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Colin Marquardt
> I think it's rather a pity that VHDL has never adopted
> the notion of a "wildcard" sensitivity list (cf Verilog-2001)
> for creating combinational processes. If this construct
> existed, it would reduce the effort of writing sensitivity
> lists to a negligible level and people would probably stop
> whingeing about it.
>
> process (all) -- sensitive to all signals that
> -- are ever read in the process
> begin
> ...
> end process;
[/me sees his emacs vhdl-mode advocacy process triggered...]
Recent vhdl-mode versions can complete the sensitivity list for you.
See http://opensource.ethz.ch/emacs/vhdl-mode.html
Cheers,
Colin
Nicolas Matringe
>
> [/me sees his emacs vhdl-mode advocacy process triggered...]
>
> Recent vhdl-mode versions can complete the sensitivity list for
> you. See http://opensource.ethz.ch/emacs/vhdl-mode.html
hi
I never managed to make this work (ver 3.31.21). How do you do it?
Nicolas
Mike Treseler
Nicolas Matringe wrote:
> I never managed to make this work (ver 3.31.21). How do you do it?
Using the menu it's
VHDL, Update, Sensitivity List (cursor inside the process)
or
VHDL, Update, Sensitivity List Buffer (updates all processes)
-- Mike Treseler
Weng Tianxiang
One thing I have to underscore is:
SENSITIVITY LIST IS ONLY USED IN SOFTWARE SIMULATION SITUATIONS, THEY
ARE NEVER USED WHEN A DESIGN IS BEING SYNTHESIZED!!!
So now it is clear that the original question become this one: Are
currently available simulation software are smart enough to detect
which signal must be traced, which one can be ignored in a process
simulation?
No one will be suspicious about it.
So answer to the original question is clear: SENSITIVITY LIST IS
REDUNDENT!!!
This was the answer I had already have in my mind before delivering
the question.
If you are interested in other VHDL stupidities, my paper and
presentation about new proposed 5 key words for VHDL/Verilog are
available by email request.
Weng
Mike Treseler <mike.t...@flukenetworks.com> wrote in message news:<3D821592...@flukenetworks.com>...
Jos De Laender
Dear,
first of all , I at least am enerved by your shouting , paper
plugging and onsollicited mails. But that aside.
I'm afraid you totally missed the point.
VHDL is not only a description language for hardware but also
for the testbenches and models that go along with it. There it
can be used to increase simulation performance by triggering
processes only then when it is absolutely needed.
Suppose you have two processes P1,P2 processing data and
dumping it in a databuffer. A third process P3 is processing
the data. In the case the databuffer is expressed as signal,
it can make a lot of sense to trigger process P3 only by
a 'event' signal in order not to run the process on every
datachange. (Hey, doesn't you make you think this about
a clocked process ?)
P3 : process(Event)
begin
XYZ <= Data;
end
I certainly don't want Data in the process sensitivity list.
Having said this, there is indeed the 'problem' of
sensitivity lists in synthesized combinatorial logic.
There you often unintended forget a signal. Synthesizers
do this often then for you (it can be debated if they
should do this automatically).
But don't exagerate this 'problem'. If you want to have
all read signals in the sensitivity list make a trivial
preprocessor on your code to do so. My colleague Colin
Marquardt pointed already out that emacs can do this
already for you. (Colin , does emacs already set coffee ? ;-) )
Best regards,
Jos
Colin Marquardt
> My colleague Colin Marquardt pointed already out that emacs can do
> this already for you. (Colin , does emacs already set coffee ? ;-)
> )
Sure. Just download coffee.el from
http://www.chez.com/emarsden/downloads/ and connect it to your
RFC2324-compliant coffee maker. :-)
HTH,
Colin
Colin Marquardt
> Colin Marquardt wrote:
>>
>> [/me sees his emacs vhdl-mode advocacy process triggered...]
>>
>> Recent vhdl-mode versions can complete the sensitivity list for
>> you. See http://opensource.ethz.ch/emacs/vhdl-mode.html
>
> I never managed to make this work (ver 3.31.21). How do you do it?
If you split out the entity in its own file, maybe it is because
vhdl-mode can't find the related entity. Set the variable
'vhdl-entity-file-name' correctly in this case.
Read more in the online help (C-c C-h).
Cheers,
Colin
Jos De Laender
Perfect ! ;-)
Troels Smit
> of a process to exist in VHDL since the first lesson on it.
When I started to learn VHDL the same thing bothered me until I read
that the the synthesislist was used to make the simulation faster, as
the simulator would only have to check process' with the changed
signal in its sensitivity list for changes, and I read this in a
Xilinx paper. (ModelSIM creators).
But now I just think that this is a side effect of the sensitivity
list.
But I to vote for the process (ALL) version, for future VHDL
compilators !
Anywasy, if you tell modelsim to compile for synthesis, it will give
you the warnings you want. Or if you compile with the ISE it will also
give a warning.
Regards,
Troels
Renaud Pacalet
> Hi,
> One thing I have to underscore is:
> SENSITIVITY LIST IS ONLY USED IN SOFTWARE SIMULATION SITUATIONS,
THEY
> ARE NEVER USED WHEN A DESIGN IS BEING SYNTHESIZED!!!
>
> So now it is clear that the original question become this one: Are
> currently available simulation software are smart enough to detect
> which signal must be traced, which one can be ignored in a process
> simulation?
>
> No one will be suspicious about it.
>
> So answer to the original question is clear: SENSITIVITY LIST IS
> REDUNDENT!!!
>
> This was the answer I had already have in my mind before
delivering
> the question.
>
> If you are interested in other VHDL stupidities, my paper and
> presentation about new proposed 5 key words for VHDL/Verilog are
> available by email request.
>
signal CLK, Q, D: BOOLEAN;
...
process -- what would this be without a sensivity list?
begin
if CLK then
Q <= D;
end if;
end process;
There are 2 kinds of people asking for modifications in standards:
1) The Paranoïd adds or removes features in order to increase
safety. He likes compilers issuing: "you can't do that because it's
far too dangerous". He hates compilers issuing nothing and deciding
what behavior to implement between the several possible.
2) The HurryManHurry removes every feature that takes more than 2
seconds to enter and adds any feature that replaces a string of
lenght N+1 by a string of length N because he thinks people will
meet the deadline with all those precious seconds they'll save.
There are 2 kinds of designers:
1) The FirstSiliconRightOrDie that accepts any solution to reduce
the risk of a second run. This one always asks for 2 more weeks of
simulation. He's never in time for tape out.
2) The IDonTUnderstandItShouldWork always swear he simulated every
possible test in every possible situation; everything was OK and so
he really doesn't understand why this $ 1M silicon crashes after
frame #2.
Of course Paranoïd and FirstSiliconRightOrDie are very good friends
while IDonTUnderstandItShouldWork curses HurryManHurry because of
that last and fatal optimization of the language.
I have another suggestion about VHDL: a good compiler should guess
where the semicolon should be...
Regards,
--
Renaud Pacalet, ENST / COMELEC, 46 rue Barrault 75634 Paris Cedex 13
Tel. : 01 45 81 78 08 | Fax : 01 45 80 40 36 | Mel : pac...@enst.fr
###### Fight Spam! Join EuroCAUCE: http://www.euro.cauce.org/ ######
Tuukka Toivonen
>> So answer to the original question is clear: SENSITIVITY LIST IS
>> REDUNDENT!!!
> There are 2 kinds of people asking for modifications in standards:
> 1) The Paranoïd adds or removes features in order to increase
> safety. He likes compilers issuing: "you can't do that because it's
[...]
> 2) The HurryManHurry removes every feature that takes more than 2
> seconds to enter and adds any feature that replaces a string of
In my opinion, the request to remove sensitivity belongs to actually both of
these classes.
First, the sensitivity list is a source for great amount of bugs in code. If
you forget to insert a signal in to sensitivity list, the simulation might
work, or it might equally well not to work. Or it might work until you
switch using another simulator, or edit some completely unrelated piece of
code.
It also takes quite much time to update the sensitivity list, unless one is
using something like Emacs that can do it automatically. Much larger waste
of time is used for debugging the code: I have spent days for debugging only
to find that the bug was that a signal was missing in a sensitivity list.
The sensitivity list is also quite useless for synthesis. And for simulation
you could just equally well use the "wait on .." statement.
Mike Treseler showed a way to get rid most of the sensitivity list. However,
if I understood him correctly, one would be required to write everything as
sequential statements then. No easy way to component instantiation or other
concurrent statements.
If you ask me: yes, get rid of the sensitivity list. It's useless source of
simulation bugs. At least the "all" keyword should be supported, as
suggested.
Mike Treseler
> First, the sensitivity list is a source for great amount of bugs in code.
This can only be true if you write or edit
combinational processes for synthesis.
> Mike Treseler showed a way to get rid most of the sensitivity list. However,
> if I understood him correctly, one would be required to write everything as
> sequential statements
That is not what I had in mind.
Concurrent statements require no sensitivity list, so
they are irrelevant to a discussion about how evil
sensitivity lists are.
To restate my suggestion, if you don't like maintaining
sensitivity lists, don't write combinational processes.
Use concurrent statements as needed and clocked processes
wherever possible.
-- Mike Treseler
Tuukka Toivonen
> To restate my suggestion, if you don't like maintaining
> sensitivity lists, don't write combinational processes.
Ok, now I understand. But I still think that in principle combinational
sequential processes are sometimes (often) very useful and much easier to
write and understand than equivalent bunch of concurrent statements. Too
useful to be ignored even if one then needs to maintain the horrible
sensitivity list.
If one has bunch of signals, say vectorx, vectory, vectorz that are
closely related, and need to be updated with combinational logic depending
on the state machine state. With concurrent statements:
with state select vectorx <= first when s1, second when s2;
with state select vectory <= first when s1, second when s2;
with state select vectorz <= first when s1, second when s2;
With sequential case statement the signals can be grouped logically:
case state is
when s1 => vectorx <= first; vectory <= first; vectorz <= first;
when s2 => vectorx <= second; vectory <= second; vectorz <= second;
end case;
Thus, in concurrent "select" statement the grouping is done by signal, but
in sequential "case" statement the grouping is by state, which may be much
more easier to understand in many situations.
Maybe this small example is not so obvious, but it is when one has dozen of
signals and states, some having default values in many states and so on.
Phil Tomson
From a simulator internals standpoint, I would tend to think that having a
sensitivity list would be more efficient because it acts as a hint to the
simulator to say that the process shouldn't be activated/executed unless
one of the singals in the list has an event. Without a sensitivity list
the process would always be run, which might result in longer simulation
time when compared to including relevant signals in a sensitivity list.
However, I suppose that an internal sensitivity list could be built for each
process as the VHDL code is analyzed (do any simulators do this already?).
Phil
Mike Treseler
> If one has bunch of signals, say vectorx, vectory, vectorz that are
> closely related, and need to be updated with combinational logic depending
> on the state machine state. With concurrent statements:
> with state select vectorx <= first when s1, second when s2;
> with state select vectory <= first when s1, second when s2;
> with state select vectorz <= first when s1, second when s2;
> With sequential case statement the signals can be grouped logically:
> case state is
> when s1 => vectorx <= first; vectory <= first; vectorz <= first;
> when s2 => vectorx <= second; vectory <= second; vectorz <= second;
> end case;
>
> Thus, in concurrent "select" statement the grouping is done by signal, but
> in sequential "case" statement the grouping is by state, which may be much
> more easier to understand in many situations.
I agree with your argument that complex concurrent statements are undesirable.
In this case, I would adopt a single-process state machine style that
has all the advantages you list, but no sensitivity list maintenance.
-- Mike Treseler
Jos De Laender
Once more, see my previous answer and the answer of a lot of others :
a simulator _must not_ do this. For those who might doubt on the
meaning of _must not_ : It is forbidden to do so !
(I'm not kidding : people of my language group often interpret
_must not_ as 'not needed')
It can be a very valid user choice , especially in non-synthesizable
models and testbenches to selectively trigger a process and not
on all changes.
The good solutions is :
x) preprocess your code to include all right hand signals in the
sensitivity list. Apparently emacs does this already.
x) inclusion of an all keyword in vhdl. But I guess that by then
this generation of designers is not designing anymore and probably
next generation will use something different. C++ I was told, but
let's see ;-)
Jos
Renaud Pacalet
>> I have been wondering about why there is a need for Sensitivity
List
>> of a process to exist in VHDL since the first lesson on it.
>
> When I started to learn VHDL the same thing bothered me until I
read
> that the the synthesislist was used to make the simulation faster,
as
> the simulator would only have to check process' with the changed
> signal in its sensitivity list for changes, and I read this in a
> Xilinx paper. (ModelSIM creators).
> But now I just think that this is a side effect of the sensitivity
> list.
>
> But I to vote for the process (ALL) version, for future VHDL
> compilators !
>
And what would be the meaning of ALL in this case:
signal CLK, Q, D: BOOLEAN;
...
process(ALL)
begin
if CLK then
Q <= D;
end if;
end process;
Who's supposed to decide whether it's a latch or a DFF?
Keith R. Williams
Is this valid VHDL (assuming "ALL" is allowed)?
Wouldn't these be better:
process(ALL) --DFF
begin
if rising_edge(CLK)
then Q <= D;
end if;
end process;
process(ALL) --latch
if CLK = '1'
then Q <= D;
end if;
end process;
...not that I much care for the ALL option in any case.
----
Keith
Renaud Pacalet
> In article <am6kko$psc$1...@avanie.enst.fr>, pac...@enst.fr says...
>> And what would be the meaning of ALL in this case:
>>
>> signal CLK, Q, D: BOOLEAN;
>> ...
>> process(ALL)
>> begin
>> if CLK then
>> Q <= D;
>> end if;
>> end process;
>>
>> Who's supposed to decide whether it's a latch or a DFF?
>
> Is this valid VHDL (assuming "ALL" is allowed)?
Depends on what definition you have for ALL. This code was supposed
to be a case where the default sensitivity list isn't obvious at
all...
>
> Wouldn't these be better:
>
> process(ALL) --DFF
> begin
> if rising_edge(CLK)
> then Q <= D;
> end if;
> end process;
>
> process(ALL) --latch
> if CLK = '1'
> then Q <= D;
> end if;
> end process;
>
OK, but is it really much better than the way we're coding today:
process(CLK) --DFF
begin
if CLK then
Q <= D;
end if;
end process;
process(CLK, D) --latch
begin
if CLK then
Q <= D;
end if;
end process;
> ...not that I much care for the ALL option in any case.
Neither do I...
Keith R. Williams
> Keith R. Williams wrote:
>
> > In article <am6kko$psc$1...@avanie.enst.fr>, pac...@enst.fr says...
> >> And what would be the meaning of ALL in this case:
> >>
> >> signal CLK, Q, D: BOOLEAN;
> >> ...
> >> process(ALL)
> >> begin
> >> if CLK then
> >> Q <= D;
> >> end if;
> >> end process;
> >>
> >> Who's supposed to decide whether it's a latch or a DFF?
> >
> > Is this valid VHDL (assuming "ALL" is allowed)?
>
> Depends on what definition you have for ALL. This code was supposed
> to be a case where the default sensitivity list isn't obvious at
> all...
What I meant was that I was assuming that we're adding the "ALL" option
to the VHDL language, is the rest legal? In particular, is "IF CLK
THEN" legal, assuming CLK is a signal.
I think my coding style is clearer. I only have to look at the if
statement to know that it's a FF or a latch. I don't have to go back an
look at the sensitivity list.
Personally, I stick to having only the clock and asynchronous reset on
the sensitivity list of a clocked process. If there is anything else on
the sensitivity list it's an asynchronous process. I find it very easy
to follow this style.
Again, I'm not sure your 'IF' statement is legal (I'm asking here).
----
Keith
Weng Tianxiang
> I agree with your argument that complex concurrent statements are undesirable.
>
Two separate state machinie structures style have many advantages over
one sturecture style. We can talk this issue in other title.
>
>
> In this case, I would adopt a single-process state machine style that
> has all the advantages you list, but no sensitivity list maintenance.
>
>
> -- Mike Treseler
Joe's claim that "Concurrent statements require no sensitivity list"
is wrong. For Concurrent process, they still need sensitivity list,
clock and nreset signals.
A: process(nRESET, CLK)
Begin
...
End;
Here you have to repeat the useless signals too. Compilers know what
you want to do.
ABSOLUTELY NO NEED TO REPEAT THIS USELESS INFORMATION TOO FOR ANY
SITUATIONS.
The question here is whether VHDL compilers are smart enough to
generate internally the sensitivity list to relieve user's burden to
do it manually.
Anyone who is opposed to the idea that sensitivity list is redundent
please tell an example that shows VHDL compiler cannot correctly
compile the example due to lack of sensitivity list. There are people
saying mcxxx can make sensitivity list for VHDL, why VHDL compilers
cannot do it? VHDL compilers cannot do it not because they lack
ability to do it, but because there are STUPID rules preventing them
to do it.
Ray Andraka
for example:
a<= b0 when sel='0' else b1;
an equivalent sequential statement is:
process(a, b0,b1,sel)
begin
if sel = '0' then
a<= b0;
else
a<= b1;
end if;
end process;
Using the sensitivity list in that manner usually is not synthesizable, but then synthesizable VHDL is but a
small subset of the language. There are times in simulation testbenches where it is very handy to use the
sensitivity list (memory models come to mind), and not have the process activate on signals that are not in the
list. Most synthesis tools will complete the sensitivity list and post a warning if the list was not complete in
order to avoid erroring out. This is not LRM behaviour, nor is it what would be expected based on the notion of
a sensitivity list...it is a fabrication to allow the synthesis to keep going. DON'T DO IT in synthesizable code
though, it will lead to simulation mismatches or worse, as well as unpredictable behavior when going between
tools.
If you don't like using sensitivity lists, use the concurrent statements, or code using strictly synchronous
logic. The language is robust in this regard and does not require changing.
Weng Tianxiang wrote:
>
> Joe's claim that "Concurrent statements require no sensitivity list"
> is wrong. For Concurrent process, they still need sensitivity list,
> clock and nreset signals.
>
> A: process(nRESET, CLK)
> Begin
> ...
> End;
>
> Here you have to repeat the useless signals too. Compilers know what
> you want to do.
>
> ABSOLUTELY NO NEED TO REPEAT THIS USELESS INFORMATION TOO FOR ANY
> SITUATIONS.
>
> The question here is whether VHDL compilers are smart enough to
> generate internally the sensitivity list to relieve user's burden to
> do it manually.
>
> Anyone who is opposed to the idea that sensitivity list is redundent
> please tell an example that shows VHDL compiler cannot correctly
> compile the example due to lack of sensitivity list. There are people
> saying mcxxx can make sensitivity list for VHDL, why VHDL compilers
> cannot do it? VHDL compilers cannot do it not because they lack
> ability to do it, but because there are STUPID rules preventing them
> to do it.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email r...@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Ray Andraka
outside of a process,
for example:
a<= b0 when sel='0' else b1;
an equivalent sequential statement is:
process(a, b0,b1,sel)
begin
if sel = '0' then
a<= b0;
else
a<= b1;
end if;
end process;
Using the sensitivity list in that manner usually is not synthesizable, but then synthesizable
VHDL is but a small subset of the language. There are times in simulation testbenches
where it is very handy to use the sensitivity list (memory models come to mind), and not
have the process activate on signals that are not in the list. Most synthesis tools will
complete the sensitivity list and post a warning if the list was not complete in
order to avoid erroring out. This is not LRM behaviour, nor is it what would be
expected based on the notion of a sensitivity list...it is a fabrication to allow the synthesis
to keep going. DON'T DO IT in synthesizable code though, it will lead to simulation
mismatches or worse, as well as unpredictable behavior when going between tools.
If you don't like using sensitivity lists, use the concurrent statements, or code using strictly
synchronous logic. The language is robust in this regard and does not require changing.
Moreover, making all signals sensitive all the time will result in considerably slowed simulation
because the process will be triggered every time any signal inside the process has an event instead
of only when signals on the sensitivity list have an event. In purely synchronous designs, this
would be a disaster considering that normally all that is on the sensitivity list is clk and async reset.
Furthermore, the use of the sensitivity list also provides a red flag when you accidently put async
logic in the process, as many beginners are prone to do.
Personally, I find the when-else concurrent construct to be more concise and more readable than the
equivalent if-then-else statements, especially when there are several clauses.
Weng Tianxiang wrote:
--
Renaud Pacalet
> What I meant was that I was assuming that we're adding the "ALL"
option
> to the VHDL language, is the rest legal? In particular, is "IF
CLK
> THEN" legal, assuming CLK is a signal.
>
This would have to be decided. I will not decide myself as I am not
interested in such an add...
> I think my coding style is clearer. I only have to look at the if
> statement to know that it's a FF or a latch. I don't have to go
back an
> look at the sensitivity list.
Matter of taste. It could be less obvious with a more complex
process. I am accustomed to check the sensivity list and understand
immediately what kind of process I am reading. As a teacher it has
a great benefit for me: when reading the code written by one of my
students I extract every sensivity list and they always fall in 4
different cases:
- (CLOCK) -- OK, synchronous process, check the
-- if - end if structure.
- (CLOCK, RESET) -- OK, synchronous process with asynchronous
-- reset check the if - else - end if
-- structure.
- (DATA, SEL, A, B) -- OK, combinational process, check that
-- every case is covered.
- anything else -- high probability of serious
-- misunderstanding-- -> check with the
-- student.
>
> Personally, I stick to having only the clock and asynchronous
reset on
> the sensitivity list of a clocked process. If there is anything
else on
> the sensitivity list it's an asynchronous process. I find it very
easy
> to follow this style.
>
> Again, I'm not sure your 'IF' statement is legal (I'm asking
here).
It's legal according to the LRM. So I use it. Your interpretation of
"legal" may be different from mine. I don't consider Synopsys as a
lawyer here ;-). As CLK is the only signal in the sensivity list,
and it's a boolean, then:
process(CLK)
begin
if RISING_EDGE(CLK) then -- assuming RISING_EDGE(CLK) beeing
-- defined on boolean
...
is equivalent to:
process(CLK)
begin
if CLK then
...
Remember: we're debating in order to simplify the language. So using
RISING_EDGE where it's not needed at all just because a synthesizer
uses a pattern recognition method to identify DFFs instead of a
semantic analysis looks counterproductive to me. Why not keep the
language as it is and ask EDA vendors to improve their parsers?
Last but not least: there is a real gain in simulation runtime with
a smart use of sensivity lists (true with synthesizable code and
even more with high level models). Adding every RHS signal in a
kind of implicit sensivity list will slow down everything but the
adoption of SystemC...
Tuukka Toivonen
> testbenches where it is very handy to use the sensitivity list (memory
> models come to mind), and not
You could use "wait on" in that case. Since "wait" is generally not
synthesizable anyway, it would also clearly indicate that the model is only
for simulation purposes.
> If you don't like using sensitivity lists, use the concurrent statements,
As I described in previous post, they are much more inconvenient to use,
especially on complex state machines.
> or code using strictly synchronous logic.
You can't instantiate components in sequential process statement (which is
what I think you mean with synchronous logic).
> Moreover, making all signals sensitive all the time will result in
> considerably slowed simulation because the process will be triggered every
> time any signal inside the process has an event instead of only when
> signals on the sensitivity list have an event. In purely synchronous
> designs, this would be a disaster considering that normally all that is on
> the sensitivity list is clk and async reset. Furthermore, the use of the
Not necessarily: it would be quite easy for the VHDL compiler to figure out
a subset of the signals, for which to wait. Consider this:
process(CLK) is begin
if CLK='1' and CLK'event then
...
end if;
end;
Compiler could easily figure out that nothing happens until CLK has an
event. Thus it can wait for only CLK, no matter what's inside the "if".
> sensitivity list also provides a red flag when you accidently put async
> logic in the process, as many beginners are prone to do.
I'm not sure what you mean. Anyway, serious languages should be designed for
professionals, not for beginners. None of us is using Pascal or Logo either,
right?
I have to maintain sensitivity lists like this by hand (since I haven't yet
moved to Emacs). And it is not nice, especially if it's wrong, you get no
warnings from simulator, just---maybe!---incorrect behaviour:
process(state,START,enable,nS_RESET,wrapout_1,wrapout_2,MVEC1_RST,MVEC2_RST,
cnta, cntb, cntc, cntd, cnte, cntf, cntg,cnta_cout,cntb_cout,cntc_cout,cntd_cout,cnte_cout,cntf_cout,cntg_cout,
add_r,sub_r,sa_d2,norm_out, str_dr0,str_dr1,str_dr2,
sb1r_1,sb1c_1,sb2r_1,sb2c_1,corr_1,sb1r_2,sb1c_2,sb2r_2,sb2c_2,corr_2) is
Andrew MacCormack
sensitivity list that do different things:
latch : process (clk, d)
begin
if clk = '1' then
q <= d;
end if;
end;
ff : process (clk)
begin
if clk = '1' then
q <= d;
end if;
end;
Now, you can argue that a FF should, strictly speaking, have
"rising_edge" or clk'event in its if statement, but that is actually
redundant when there is no reset and clk is the only item in the
sensitivity list (implied or explicit). Also, latches aren't often used
unless you're at IBM, so this may not be a common construct but it does
illustate why you need a sensitivity list.
--
___#--- Andrew MacCormack and...@tality.com
L_ _| Senior Design Engineer
| | Tality, Alba Campus, Livingston EH54 7HH, Scotland
! | Phone: +44 1506 595360 Fax: +44 1506 595959
T A L I T Y http://www.tality.com
Tuukka Toivonen
> latch : process (clk, d)
> begin
> if clk = '1' then
> q <= d;
> end if;
> end;
>
> ff : process (clk)
> begin
> if clk = '1' then
> q <= d;
> end if;
> end;
This is how it could be done with sensitivity list. If there wouldn't be
sensitivity list available, one could use:
latch : process
begin
if clk = '1' and d'event then
--Or just: if clk = '1' then
q <= d;
end if;
end;
ff : process
begin
if clk = '1' and clk'event then
q <= d;
end if;
end;
Which one would be clearer? i think it's matter of taste, at least in this
case. However, I don't see this as a reason to have sensitivity list, if
other matters speak against it.
Keith R. Williams
> Keith R. Williams wrote:
>
> > What I meant was that I was assuming that we're adding the "ALL"
> option
> > to the VHDL language, is the rest legal? In particular, is "IF
> CLK
> > THEN" legal, assuming CLK is a signal.
> >
>
> This would have to be decided. I will not decide myself as I am not
> interested in such an add...
AFAISI the issue was more of a "what if"...
> > I think my coding style is clearer. I only have to look at the if
> > statement to know that it's a FF or a latch. I don't have to go
> back an
> > look at the sensitivity list.
>
> Matter of taste. It could be less obvious with a more complex
> process. I am accustomed to check the sensivity list and understand
> immediately what kind of process I am reading. As a teacher it has
> a great benefit for me: when reading the code written by one of my
> students I extract every sensivity list and they always fall in 4
> different cases:
> - (CLOCK) -- OK, synchronous process, check the
> -- if - end if structure.
> - (CLOCK, RESET) -- OK, synchronous process with asynchronous
> -- reset check the if - else - end if
> -- structure.
> - (DATA, SEL, A, B) -- OK, combinational process, check that
> -- every case is covered.
> - anything else -- high probability of serious
> -- misunderstanding-- -> check with the
> -- student.
Perfectly reasonable. I write code the same way, though I do have
asynchronous processes (I still don't like the idea of "ALL" though.
> > Personally, I stick to having only the clock and asynchronous
> reset on
> > the sensitivity list of a clocked process. If there is anything
> else on
> > the sensitivity list it's an asynchronous process. I find it very
> easy
> > to follow this style.
> >
> > Again, I'm not sure your 'IF' statement is legal (I'm asking
> here).
>
> It's legal according to the LRM. So I use it. Your interpretation of
> "legal" may be different from mine. I don't consider Synopsys as a
> lawyer here ;-). As CLK is the only signal in the sensivity list,
> and it's a boolean, then:
^^^^^^^
Ah! That's what I was wondering. I always use signals for clocks (and
most other things).
> process(CLK)
> begin
> if RISING_EDGE(CLK) then -- assuming RISING_EDGE(CLK) beeing
> -- defined on boolean
> ...
>
> is equivalent to:
>
> process(CLK)
> begin
> if CLK then
> ...
>
> Remember: we're debating in order to simplify the language. So using
> RISING_EDGE where it's not needed at all just because a synthesizer
> uses a pattern recognition method to identify DFFs instead of a
> semantic analysis looks counterproductive to me. Why not keep the
> language as it is and ask EDA vendors to improve their parsers?
Because I have work to do! I'll make it as idiot proof for the parsers
as I can. Productivity tanks when the parser does something unexpected.
> Last but not least: there is a real gain in simulation runtime with
> a smart use of sensivity lists (true with synthesizable code and
> even more with high level models). Adding every RHS signal in a
> kind of implicit sensivity list will slow down everything but the
I'm certainly not arguing these points!
I was focusing in on your use of the sensitivity list and boolean
clocks. I see this as obfuscation. I much prefer clocks being signals
and the use of rising_edge. To each, I guess.
> adoption of SystemC...
Yuck.
----
Keith
Ray Andraka
Tuukka Toivonen wrote:
> > or code using strictly synchronous logic.
>
> You can't instantiate components in sequential process statement (which is
> what I think you mean with synchronous logic).
No, what I mean is the processes should only have clk and async_reset in the sensitivity list, nothing else.
>
Why on God's green earth do you have big sensitivity lists like this? Are you designing asynchronous state machines? Synchronous
state machines only change on the clock, so the only things you need in the sensitivity list are the clock and async reset. If you
are doing a mealy machine, you can put the output decodes in concurrent statements immediatly above the state machine for those
outputs that are a combinatorial function of a state and an input.
>
> I have to maintain sensitivity lists like this by hand (since I haven't yet
> moved to Emacs). And it is not nice, especially if it's wrong, you get no
> warnings from simulator, just---maybe!---incorrect behaviour:
>
> process(state,START,enable,nS_RESET,wrapout_1,wrapout_2,MVEC1_RST,MVEC2_RST,
> cnta, cntb, cntc, cntd, cnte, cntf, cntg,cnta_cout,cntb_cout,cntc_cout,cntd_cout,cnte_cout,cntf_cout,cntg_cout,
> add_r,sub_r,sa_d2,norm_out, str_dr0,str_dr1,str_dr2,
> sb1r_1,sb1c_1,sb2r_1,sb2c_1,corr_1,sb1r_2,sb1c_2,sb2r_2,sb2c_2,corr_2) is
--
Renaud Pacalet
>> and it's a boolean, then:
> ^^^^^^^
>
> Ah! That's what I was wondering. I always use signals for clocks
(and
> most other things).
>
> ...
> I was focusing in on your use of the sensitivity list and boolean
> clocks. I see this as obfuscation. I much prefer clocks being
signals
> and the use of rising_edge. To each, I guess.
signal is not a type, it's an object class, just as variable, file
or constant. boolean is a type, like real, integer, bit or
std_ulogic. You can have boolean signals, integer signals,
std_ulogic signals, etc. You can even build large record types
mixing booleans, integers, arrays, other records, etc and declare a
signal of such a type:
type COMMAND_TYPE is (IDLE, READ, WRITE);
type ERROR_TYPE is (FORBIDEN_ACCESS, UNALIGNED_ACCESS,
UNKNOWN_ADDRESS);
type IN_INTERFACE is record
WRITE_DATA: INTEGER range 0 to 2**BUS_WIDTH -1;
ADDRESS: INTEGER range 0 to 2**ADD_WIDTH - 1;
COMMAND: COMMAND_TYPE;
end record;
type OUT_INTERFACE is record
READ_DATA: INTEGER range 0 to 2**BUS_WIDTH -1;
ERROR: ERROR_TYPE;
end record;
...
entity OP1 is
CLOCK, RESETN: Boolean;
FROM_CPU: in IN_INTERFACE;
TO_CPU: out OUT_INTERFACE;
end OP1;
Regards,
PS: to those who have large sensivity lists I suggest the use of
records.
Tuukka Toivonen
>> You can't instantiate components in sequential process statement (which is
>> what I think you mean with synchronous logic).
> No, what I mean is the processes should only have clk and async_reset in
> the sensitivity list, nothing else.
Let me try again: so with "synchronous logic" you mean a sequential process
statement which has only CLOCK and ASYNC_RESET in the sensitivity list? It's
just the same, can't instantiate components inside, therefore Mealy-type
outputs are necessary when part of the state machine is implemented with
instantiated components. And with Mealy-type outputs, you need to have more
in the sensitivity list than just CLOCK and ASYNC_RESET.
So I'm using two (or more) -process FSM coding style, because I can not
think any way how to do that with just one process.
http://groups.google.com/groups?th=84ce1e91e657bcb&seekm=a55kae%24sje%241%40ares.cs.utwente.nl
> Are you designing asynchronous state machines? Synchronous state machines
> list are the clock and async reset. If you are doing a mealy machine, you
> can put the output decodes in concurrent statements immediatly above the
> state machine for those outputs that are a combinatorial function of a
> state and an input.
The Mealy-type outputs are exactly the problem: it is not practical to put
them in concurrent statements. There are so many Mealy-type output signals
and their semantics are such that doing that would be even more difficult
than maintaining the sensitivity list. When I put the Mealy-type outputs
inside the process, I can use default values for the output signals (helps
much when there are many similar states) and I can use the "case" statement
(which is sequential) which groups very nicely the states together.
(By saying that Mealy-type outputs are a problem, I don't mean they are
generally a bad idea, just that VHDL with process sensitivity lists can not
elegantly handle them.)
Troels Smit
>
> signal CLK, Q, D: BOOLEAN;
> ...
> process(ALL)
> begin
> if CLK then
> Q <= D;
> end if;
> end process;
>
> Who's supposed to decide whether it's a latch or a DFF?
Well the syntheziser ofcause !!
It would be quite easy to tell people that when using the ALL command,
we are working without LATCHES, which is desireabel in, I guess, 98%
of all designs.
For the people who want to use latches and other clever 'only
simulation' stuff, they would have to include an old style synthesis
list.
** For the teacher dude, maybe then the students won't have to think
about what ** signals are read, and this might be bad. But anyone with
more than a one
** semester expirience in HDL will have no problem understand what is
ment.
Weng Tianxiang
with him on the following points:
1. "There are times in simulation testbenches
where it is very handy to use the sensitivity list (memory models come
to mind), and not have the process activate on signals that are not in
the list."
Big trouble to skip any signals in the sensitivity list to get any
performance benefits in current situations that requeire all signals
shown in the list.
2. "If you don't like using sensitivity lists, use the concurrent
statements, or code using strictly synchronous logic"
Bad idea.
The only place I use for generating logic, not registers is to make
state machines. The method of two processes to define a state machine
is a very good practice. I will insist to using it. But the burden to
maintain the sensitivity list is so heavy that since I wrote my first
state machine in VHDL, I hate the sensitivity list. The reason is THAT
SENSITIVITY LIST CAN BE GENERATED BY VHDL COMPILERS INTERNALLY, AND IS
NOT NEEDED FOR PROGRAMMERS TO GENERATE IT MANUALLY. Verilog's
accepting "all" as sensitivity list never means it would slow down the
simulations. Actually the simulations go as well as before. For it,
Verilog compilers generate sensitivity lists INTERNALLY.
The following is my example on how long a sensitivity list may be:
SDRAMStateB : process(SDRAMState, nRESETGlobal, Count4KCarryOut,
MTInSDRAMWrite, MTInSDRAMRead, WriteFIFOEmpty, TAddress0_S,
ActiveExpireRead, RefreshState, MReadFIFOHit, nPowerReady_C,
CommandBit, CKE_O, ReadStatus, InComingCommandBit,
ActiveExpireWrite, MEnable_S,
WriteFIFOAllByteEnabled, nDQ_R1_SyndromeOK, TReadSDRAMIdle,
DQM_O, NextBankNotPreActive, ReadFIFOPreFull, WriteNewPage,
WriteFIFOWriteEnable,
ReadNewPage, SendBurstRead_B, ActiveState, ChipGroupReady,
WriteFIFOInjectWrite, BankState, WriteFIFOByteEnable(0),
ClearSendBurstRead_B,
AutoRefresh0State, AutoRefresh1State, TReadSDRAMWait0, M66EN_R,
AutoRefresh2State, AutoRefresh3State, TReadFIFOHit, ChipRowPtr,
TReadFIFOHeadPtrHit, RefreshCountCout, TWriteSDRAMWait, nC_BE_R0_0,
DMAReadSDRAMStart_B, DMAReadSDRAMDataS, DMAReadSDRAMWaitS,
InBurstRead) The state machine is for SDRAM controller. It has 39
states.
Before using Modelsim to do simulations after the state machine
changes, I would use Exemplar to generate any warning messages
relating with the state machine about any possible missing signals in
the list and correct it.
Ray Andraka <r...@andraka.com> wrote in message news:<3D87CBB4...@andraka.com>...
Ray Andraka
Weng Tianxiang wrote:
My response is soly to Ray Andraka's response. I strongly disagree
with him on the following points:
%
Big trouble to skip any signals in the sensitivity list to get any
performance benefits in current situations that requeire all signals
shown in the list.
Not all signals in a process are necessarily needed in a sensitivity list. The extreme case is synchronous logic where sensitivity to a clock and an asynchronous reset is all that is needed. There are usually many other signals in the process, and if they were also in the sensitivity list the process gets executed every time one of them changes. Clocked logic is easy enough to recognize, so although it is illustrative, it is perhaps not a compelling case.
Ceratin behavioral models can be easier to write if some processes are
only triggered when signals in the sensitivity list are changed.
One that comes to mind is a transmission gate, which has the requirement
to pass a signal in either direction when conducting and neither direction
when not conducting. Most of the methods (this is not a trivial model
to write) I've seen require some signals to not be on the sensitivity list.
2. "If you don't like using sensitivity lists, use the concurrent
statements, or code using strictly synchronous logic"
I take exception to this being a "bad idea". There are many ways to code a state machine. If you don't like the sensitivity lists, there are ways to avoid long ones. A single process state machine can be as readable (some might argue more readable) than a two process one. Most of what can be done in a combinatorial process can also be done with concurrent statements (the exception that I can think of being for loops). You can also use functions or procedures to help make it more readable. The point is, the reason for a sensitivity list is that it gives the language more flexibility and generality. There are models out there that will break if the sensitivity lists as provided in the LRM are bypassed. Sensitivity lists have the side benefit of reducing simulation times if there is no need to execute a process in response to every signal that wiggles, but the main reason is for the flexibility and generality. Remember, synthesizable VHDL is but a small subset of the total language. Please don't be asking for changes like this unless you understand the ramifications to the whole language, not just the synthesizable subset. One of the reasons for using VHDL over verilog is that it provides so much more flexibility for describing hardware and systems than verilog does. Dumbing it down in this manner to cater to a few synthesis only folks serves only to dilute the language's richness.
IMHO, this is an inappropriate way to do the SDRAM controller design, it would likely not get past one of our design reviews. One of the beauties of VHDL is that you have many different avenues available to you as a designer. If the code in your chosen approach is messy, then perhaps you should look at different styles. We've got several SDRAM controllers, and guess what, none have anything other than clock or global_reset in the sensitivity lists!
Jos De Laender
Weng Tianxiang wrote:
>
> My response is soly to Ray Andraka's response. I strongly disagree
> with him on the following points:
>
> 1. "There are times in simulation testbenches
> where it is very handy to use the sensitivity list (memory models come
> to mind), and not have the process activate on signals that are not in
> the list."
>
> Big trouble to skip any signals in the sensitivity list to get any
> performance benefits in current situations that requeire all signals
> shown in the list.
>
I don't see any argument here. Can you please give an _argument_.
Ray has given the memory model example and in a post hereafter
the example of a clocked process, I've given earlier the example
of different processes processing data on an 'event signal'.
Jos
Andrew MacCormack
would be handy to have the possibility of PROCESS (ALL) which
automatically generates a sensitivity list involving all RHS signals.
But saying "VHDL 2003 should not have sensitivity lists" is silly
because it removes backwards compatibility with exisiting VHDL....
currently, not having a sensitiviy list means something specific and
incompatible with it meaning "generate a sensititivy list".
So why not add "PROCESS(ALL)" to avoid maintaining the sensitivity lists
manually but still allow people to do it the hard way if they so wish or
if they actually want an incomplete list for some behavioural model?
Surely that way, everyone is happy? Or are there some language purists
out there that dislike this pragmatism?
Cheers,
Jos De Laender
I guess this is a fair conclusion.
-
ticktack
language but not VHDL. I don't know how many people really use VHDL
as a simulation language, or a modeling language. For me, VHDL is
just an HDL. For that, the langauge is overkilling.
1. VHDL is not good for high level modeling.
Nobody should be doubt about it.
2. VHDL is not good for testbench authoring.
Again, nobody should be doubt about it.
3. VHDL is hardly a safe-language or reusability.
Many tools are ported from Verilog, only support various subsets of VHDL
at the vendor's conveniece.
4. Backend is dominated by Verilog.
Unless you are rich enough to afford two sets of the same tool.
(Note, I am no fan of Verilog either.)
I only use VHDL to do the following.
1. RTL
2. Clock modeling
So, I actually don't care most of "advanced" VHDL constructs,
TT
Ray Andraka
by number 4, or why it matters.
VHDL is very powerful as a hardware modeling tool and has the advantage of
allowing you to easily substitute gate level, RTL level or behavioral models
depending on the goal of the simulation. We use it and Matlab extensively in
models and testbenches for our designs. If you only look at VHDL as a
synthesis input and ignore the rest of the language, then I can see where the
rest of the language can seem to be onerous. On the other hand, if you are
only interested in synthesis, the synthesizable subset only requires that you
know a small fraction of the language because much of it doesn't apply (too
bad schools seem to teach VHDL for modeling more than VHDL for synthesis). We
do use matlab for much of our systems level models because of the advanced DSP
and i/o features available there. For hardware modeling though, VHDL is more
appropriate because it makes it much easier to arrive at bit-true behavioral
models. For test benches, a major advantage is the ability to substitue
behavioral models for hardware that is not yet developed or has already been
proven (in order to speed simulation).
The VHDL generate, generics, and attributes make it more useful than other
HDLs for writing parameterized code. Parameterization and hierarchy are the
key to getting reuse. We do have a high degree of reuse in our designs
because we have used these vhdl features to create reusable parameterized
placed macros. If you find the language too rich, no one (well maybe your
employer does) says you have to use it, and even if you do, no one says you
have to use the full richness of the language. I personally think the strong
typing of VHDL makes it much safer than an untyped language like verilog,
since it provides a level of checking to make sure you are consistent with
your data types.
ticktack wrote:
--
Jos De Laender
>
> I am just as puzzled as any VHDL users. Ada might have been a great
Shouldn't this read "might be a" ? ;-)
> language but not VHDL. I don't know how many people really use VHDL
> as a simulation language, or a modeling language. For me, VHDL is
> just an HDL. For that, the langauge is overkilling.
>
> 1. VHDL is not good for high level modeling.
> Nobody should be doubt about it.
I'm (a) nobody. VHDL has very good features for high level modelling
in my opinion. Granted , there are missing some features
(generics in ADA sense or templates in C++ sense is one
that comes to mind) but probably you would call it then even
more overkill ?
> 2. VHDL is not good for testbench authoring.
> Again, nobody should be doubt about it.
I'm (a) nobody.
> 3. VHDL is hardly a safe-language or reusability.
> Many tools are ported from Verilog, only support various subsets of VHDL
> at the vendor's conveniece.
Why ?
> 4. Backend is dominated by Verilog.
> Unless you are rich enough to afford two sets of the same tool.
> (Note, I am no fan of Verilog either.)
That's more because there's no need to go further than
the Verilog possibilities. Netlists are not exactly high level,
are they ?
ticktack
> ticktack wrote:
>>
>> I am just as puzzled as any VHDL users. Ada might have been a great
>
> Shouldn't this read "might be a" ? ;-)
Ada had a good time in the history. It has a lot of controvercial
features, which was new, and good at that time.
You can tell me how many people still in favor of it these days.
>> language but not VHDL. I don't know how many people really use VHDL
>> as a simulation language, or a modeling language. For me, VHDL is
>> just an HDL. For that, the langauge is overkilling.
>>
>> 1. VHDL is not good for high level modeling.
>> Nobody should be doubt about it.
>
> I'm (a) nobody. VHDL has very good features for high level modelling
> in my opinion. Granted , there are missing some features
> (generics in ADA sense or templates in C++ sense is one
> that comes to mind) but probably you would call it then even
> more overkill ?
The "overkill" statement is based on the assumption that "VHDL is used
only for RTL and low-level analog device modeling".
Actually, I agree that VHDL has some very good features. However, I found
there is a lot of contructs that nobody uses. For example, the statement
block in a entity. As a language, it is huge.
If you take a look at the history, usually simple and effective things
survive.
For modeling, can you tell me how much lines you have to write to model a
fifo? (just the simplest you can think of)
>> 2. VHDL is not good for testbench authoring.
>> Again, nobody should be doubt about it.
>
> I'm (a) nobody.
I have seen people's code. Maybe you have a better solution here.
Suppose that I have two modules (entity/architecture/configuration) needs
some synchronization. You must use signal as a port or in a common
package. The use of signal in either case is pretty awkward.
Unlike hardware modeling, controllability is very important for testbench.
Testbench is just common software. You could use all the facilities that
your OS provides you. VHDL lacks that kind of libraries. A language
without extensive standard library support is dead.
By the way, I have seen many cases when VHDL testbench causes run time
bottleneck.
>> 3. VHDL is hardly a safe-language or reusability.
>> Many tools are ported from Verilog, only support various subsets of VHDL
>> at the vendor's conveniece.
>
> Why ?
That is the reality. There is no standard binary format for VHDL.
Unfortunately, I have to use many different tools. I have to carry all these
VHDL files with me, compile (in the right order) again and again.
If you only use VHDL with Modelsim, you probably don't feel the pain. As
a reality, VHDL is not fully supported by many EDA tools.
ticktack
> VHDL is very powerful as a hardware modeling tool and has the advantage of
> allowing you to easily substitute gate level, RTL level or behavioral models
> depending on the goal of the simulation. We use it and Matlab extensively in
> models and testbenches for our designs. If you only look at VHDL as a
> synthesis input and ignore the rest of the language, then I can see where the
> rest of the language can seem to be onerous. On the other hand, if you are
> only interested in synthesis, the synthesizable subset only requires that you
> know a small fraction of the language because much of it doesn't apply (too
> bad schools seem to teach VHDL for modeling more than VHDL for synthesis). We
> do use matlab for much of our systems level models because of the advanced DSP
> and i/o features available there. For hardware modeling though, VHDL is more
> appropriate because it makes it much easier to arrive at bit-true behavioral
> models. For test benches, a major advantage is the ability to substitue
> behavioral models for hardware that is not yet developed or has already been
> proven (in order to speed simulation).
Actually, this is the first time that hear a system guy uses VHDL. Very
interesting. Have you looked at SystemC? Can you share your opinion on
that?
> The VHDL generate, generics, and attributes make it more useful than other
> HDLs for writing parameterized code. Parameterization and hierarchy are the
> key to getting reuse. We do have a high degree of reuse in our designs
> because we have used these vhdl features to create reusable parameterized
> placed macros. If you find the language too rich, no one (well maybe your
> employer does) says you have to use it, and even if you do, no one says you
> have to use the full richness of the language. I personally think the strong
> typing of VHDL makes it much safer than an untyped language like verilog,
> since it provides a level of checking to make sure you are consistent with
> your data types.
To tell you the truth, those generate, generics... are on of the reasons
that I found VHDL awkward. These should belong to preprocesing languages.
This is how your OS is written. Can you compare the pros and cons of using
preprocessors?
TT
Jos De Laender
>
> To tell you the truth, those generate, generics... are on of the reasons
> that I found VHDL awkward. These should belong to preprocesing languages.
> This is how your OS is written. Can you compare the pros and cons of using
> preprocessors?
>
Some of it _could_ be done using preprocessing.
It _should_ however be done in the language itself. For instance
to safeguard type safety on generics, or to allow dynamically
calculated values.
Compare it with C++. Templates (but also classes etc) can be 'emulated'
with preprocessing. Nevertheless they are in the language (much for
the same reasons : typesafety, dynamic behaviour etc...)
Jos
Jos De Laender
>
> On Sat, 28 Sep 2002 09:55:12 +0000, Jos De Laender wrote:
>
> > ticktack wrote:
> >>
> >> I am just as puzzled as any VHDL users. Ada might have been a great
> >
> > Shouldn't this read "might be a" ? ;-)
>
> Ada had a good time in the history. It has a lot of controvercial
> features, which was new, and good at that time.
>
> You can tell me how many people still in favor of it these days.
I am at least. And quite some project leaders of mission critical
software. Avionics industry is a classic example.
>
> >> language but not VHDL. I don't know how many people really use VHDL
> >> as a simulation language, or a modeling language. For me, VHDL is
> >> just an HDL. For that, the langauge is overkilling.
> >>
> >> 1. VHDL is not good for high level modeling.
> >> Nobody should be doubt about it.
> >
> > I'm (a) nobody. VHDL has very good features for high level modelling
> > in my opinion. Granted , there are missing some features
> > (generics in ADA sense or templates in C++ sense is one
> > that comes to mind) but probably you would call it then even
> > more overkill ?
>
> The "overkill" statement is based on the assumption that "VHDL is used
> only for RTL and low-level analog device modeling".
>
> Actually, I agree that VHDL has some very good features. However, I found
> there is a lot of contructs that nobody uses. For example, the statement
> block in a entity. As a language, it is huge.
Agree to some extent. Never used that neither.
>
> If you take a look at the history, usually simple and effective things
> survive.
>
> For modeling, can you tell me how much lines you have to write to model a
> fifo? (just the simplest you can think of)
>
I'm not one of those who's convinced number of lines to write is
a quality measurement of a language.
Besides that, apart from the interface to the external world, a simple
behavioural fifo should take only a few lines.
> >> 2. VHDL is not good for testbench authoring.
> >> Again, nobody should be doubt about it.
> >
> > I'm (a) nobody.
>
> I have seen people's code. Maybe you have a better solution here.
> Suppose that I have two modules (entity/architecture/configuration) needs
> some synchronization. You must use signal as a port or in a common
> package. The use of signal in either case is pretty awkward.
>
See my remark above on number of lines. Furthermore, if this type
of constructs is the majority of your code, it might indeed be
a better choice to go for Verilog for instance.
> Unlike hardware modeling, controllability is very important for testbench.
> Testbench is just common software. You could use all the facilities that
> your OS provides you. VHDL lacks that kind of libraries. A language
> without extensive standard library support is dead.
>
Partly agreed. Not that Verilog is better here, but it has at least
a now standardized escape way via its PLI C-interface.
> By the way, I have seen many cases when VHDL testbench causes run time
> bottleneck.
Yes, especially when people don't understand what belongs
in a sensitivity list ;-) or the difference signal/variable.
>
> >> 3. VHDL is hardly a safe-language or reusability.
> >> Many tools are ported from Verilog, only support various subsets of VHDL
> >> at the vendor's conveniece.
> >
> > Why ?
>
> That is the reality. There is no standard binary format for VHDL.
> Unfortunately, I have to use many different tools. I have to carry all these
> VHDL files with me, compile (in the right order) again and again.
>
> If you only use VHDL with Modelsim, you probably don't feel the pain. As
> a reality, VHDL is not fully supported by many EDA tools.
That's right. But it's a different type of discussion. From a language
point of view I would undoubtedly say that VHDL is the better choice.
Looking however to the combination (language+supporting tools+people
that know to work with it) the outcome will be different ...
Regards,
Jos
>
ticktack
> ticktack wrote:
>>
>> On Sat, 28 Sep 2002 09:55:12 +0000, Jos De Laender wrote:
>>
>> > ticktack wrote:
>> >>
>> >> I am just as puzzled as any VHDL users. Ada might have been a great
>> >
>> > Shouldn't this read "might be a" ? ;-)
>>
>> Ada had a good time in the history. It has a lot of controvercial
>> features, which was new, and good at that time.
>>
>> You can tell me how many people still in favor of it these days.
>
> I am at least. And quite some project leaders of mission critical
> software. Avionics industry is a classic example.
Choosing which language to use for which project is sometimes a political
thing. For example, I have to use VHDL because somebody paying me ask me to
use it. I don't know anybody who uses Ada to develop something and still
loves it in these days.
>> For modeling, can you tell me how much lines you have to write to model a
>> fifo? (just the simplest you can think of)
>>
>
> I'm not one of those who's convinced number of lines to write is
> a quality measurement of a language.
That is right. For me, I am more concerned about the capability of
representation of algorithm by syntax. I generally don't care the number
of lines, but I do care the process of translating algorithm to programs.
If you do that exercies that I suggested, you would know how much details
you have to cover to represent a simple high-level concept.
> Besides that, apart from the interface to the external world, a simple
> behavioural fifo should take only a few lines.
I don't think you can write it in just a few lines.
>> >> 2. VHDL is not good for testbench authoring.
>> >> Again, nobody should be doubt about it.
>> >
>> > I'm (a) nobody.
>>
>> I have seen people's code. Maybe you have a better solution here.
>> Suppose that I have two modules (entity/architecture/configuration) needs
>> some synchronization. You must use signal as a port or in a common
>> package. The use of signal in either case is pretty awkward.
>>
> See my remark above on number of lines. Furthermore, if this type
> of constructs is the majority of your code, it might indeed be
> a better choice to go for Verilog for instance.
This is not about the number of lines.
>> Unlike hardware modeling, controllability is very important for testbench.
>> Testbench is just common software. You could use all the facilities that
>> your OS provides you. VHDL lacks that kind of libraries. A language
>> without extensive standard library support is dead.
>
> Partly agreed. Not that Verilog is better here, but it has at least
> a now standardized escape way via its PLI C-interface.
I use C++ for testbench, not Verilog.
>> By the way, I have seen many cases when VHDL testbench causes run time
>> bottleneck.
>
> Yes, especially when people don't understand what belongs
> in a sensitivity list ;-) or the difference signal/variable.
>
>>
>> >> 3. VHDL is hardly a safe-language or reusability.
>> >> Many tools are ported from Verilog, only support various subsets of VHDL
>> >> at the vendor's conveniece.
>> >
>> > Why ?
>>
>> That is the reality. There is no standard binary format for VHDL.
>> Unfortunately, I have to use many different tools. I have to carry all these
>> VHDL files with me, compile (in the right order) again and again.
>>
>> If you only use VHDL with Modelsim, you probably don't feel the pain. As
>> a reality, VHDL is not fully supported by many EDA tools.
>
> That's right. But it's a different type of discussion. From a language
> point of view I would undoubtedly say that VHDL is the better choice.
> Looking however to the combination (language+supporting tools+people
> that know to work with it) the outcome will be different ...
I agree this is a different topic. Let's stop here.
Youxin
ticktack
>> To tell you the truth, those generate, generics... are on of the reasons
>> that I found VHDL awkward. These should belong to preprocesing languages.
>> This is how your OS is written. Can you compare the pros and cons of using
>> preprocessors?
>>
>
> Some of it _could_ be done using preprocessing.
>
> It _should_ however be done in the language itself. For instance
> to safeguard type safety on generics, or to allow dynamically
> calculated values.
For complex statements, in general, type safety is
necessary, if VHDL has something like MACRO. All we do with those
generics, configuration is static, and usually parameterized. I don't know
how type-safe has anything to do with that. Type safety still plays a role
after configuration, if the configuration is not syntactically correct.
Actually, the advantage of using preprocessor is to allow configuration
to be unique across the langauge boundary.
> Compare it with C++. Templates (but also classes etc) can be 'emulated'
> with preprocessing. Nevertheless they are in the language (much for
> the same reasons : typesafety, dynamic behaviour etc...)
I think what I am talking about is simple constructs like generic,
configuration, not complicated things like template. There is no such
things in VHDL.
TT
Jos De Laender
>
> Choosing which language to use for which project is sometimes a political
> thing. For example, I have to use VHDL because somebody paying me ask me to
> use it. I don't know anybody who uses Ada to develop something and still
> loves it in these days.
There might be a 'political' aspect sometimes too. On the other hand
I'm sure there are at least a few guys who know _why_ they pay you
for doing it in VHDL (or ADA for that matter) ;-)
> That is right. For me, I am more concerned about the capability of
> representation of algorithm by syntax. I generally don't care the number
> of lines, but I do care the process of translating algorithm to programs.
I've taken several algorithms from Cormen,Leiserson and Rivest into
VHDL. Mostly no big deal. For instance, I modelled huge sparsely
occupied
rams with Red Black trees. No problem.
> I don't think you can write it in just a few lines.
What would be the big problem ? I have no analyzer/elaborator right
here available but I would go along the lines of :
Define type of record containg
whatever type you want to store in a fifo.
access types to make a doubly linked list.
Define two signals (marshalls) pointing to begin/end of list
Define a push and pop procedure acting on this linked list.
Push would do new SomeStruct and link it in. Pop would delete
and link it out.
Seems not more difficult nor easy then in C ?
(Granted, object orientation and templates could make even
more nice. There's C++ or Ada much better , but none of the
HDL's is better in it)
> I use C++ for testbench, not Verilog.
>
Good choice too.
But I guess that, unless you have quite dumb testbenches without
feedback from output to input, you have to couple it somewhere to
Verilog/VHDL ? That's where a standard C interface should come in.
ticktack
My interpretation of the original complain of the thread is "VHDL is a
language on paper". Although I do not agree that sensitivity list should
be removed, I agree that VHDL is a language that was designed to be too
ambitous. As a result, I have never seen a tool that can understand the
whole langauge.
TT
ticktack
> ticktack wrote:
>>
>> Choosing which language to use for which project is sometimes a political
>> thing. For example, I have to use VHDL because somebody paying me ask me to
>> use it. I don't know anybody who uses Ada to develop something and still
>> loves it in these days.
>
> There might be a 'political' aspect sometimes too. On the other hand
> I'm sure there are at least a few guys who know _why_ they pay you
> for doing it in VHDL (or ADA for that matter) ;-)
I don't think they understand. They are businessmen.
Between VHDL and Verilog, I will choose VHDL. But as I said, I only use it
for RTL/simple analog modeling.
>> That is right. For me, I am more concerned about the capability of
>> representation of algorithm by syntax. I generally don't care the number
>> of lines, but I do care the process of translating algorithm to programs.
>
> I've taken several algorithms from Cormen,Leiserson and Rivest into
> VHDL. Mostly no big deal. For instance, I modelled huge sparsely
> occupied
> rams with Red Black trees. No problem.
You must be paid huge bucks to do so.
Ususlly I will ask more to do things that I don't like m(_)m
>> I don't think you can write it in just a few lines.
>
> What would be the big problem ? I have no analyzer/elaborator right
> here available but I would go along the lines of :
>
> Define type of record containg
> whatever type you want to store in a fifo.
> access types to make a doubly linked list.
>
> Define two signals (marshalls) pointing to begin/end of list
>
> Define a push and pop procedure acting on this linked list.
> Push would do new SomeStruct and link it in. Pop would delete
> and link it out.
>
> Seems not more difficult nor easy then in C ?
Why can't you use array instead of linked list?
> (Granted, object orientation and templates could make even
> more nice. There's C++ or Ada much better , but none of the
> HDL's is better in it)
>
> But I guess that, unless you have quite dumb testbenches without
> feedback from output to input, you have to couple it somewhere to
> Verilog/VHDL ? That's where a standard C interface should come in.
What is the standardization progress of VHPI?
Jos De Laender
> I don't think they understand. They are businessmen.
That's your point of view. I don't share it. (at least not that flat ;-)
)
> > I've taken several algorithms from Cormen,Leiserson and Rivest into
> > VHDL. Mostly no big deal. For instance, I modelled huge sparsely
> > occupied
> > rams with Red Black trees. No problem.
>
> You must be paid huge bucks to do so.
> Ususlly I will ask more to do things that I don't like m(_)m
Wish it was true ... As a matter of fact I did it in a few
hours during a sick leave. Just to keep the skills sharp ...
>
> >> I don't think you can write it in just a few lines.
> >
> > What would be the big problem ? I have no analyzer/elaborator right
> > here available but I would go along the lines of :
> >
> > Define type of record containg
> > whatever type you want to store in a fifo.
> > access types to make a doubly linked list.
> >
> > Define two signals (marshalls) pointing to begin/end of list
> >
> > Define a push and pop procedure acting on this linked list.
> > Push would do new SomeStruct and link it in. Pop would delete
> > and link it out.
> >
> > Seems not more difficult nor easy then in C ?
>
> Why can't you use array instead of linked list?
Same reason as in C : array is possible if you limit in
advance the size of your problem. Mostly at the expense of
overusing memory for the average case. An array of (pointers,
access values) could be a compromise.
But again, general implementations of vector-like things is
often done with linked lists of dynamically allocated elements.
You use C++, thus see to the STL for instance.
>
> > (Granted, object orientation and templates could make even
> > more nice. There's C++ or Ada much better , but none of the
> > HDL's is better in it)
> >
> > But I guess that, unless you have quite dumb testbenches without
> > feedback from output to input, you have to couple it somewhere to
> > Verilog/VHDL ? That's where a standard C interface should come in.
>
> What is the standardization progress of VHPI?
No idea. Lost track a bit on that one. I did some interfacing to
Mentor Modelsim and also to Cadence NC and I guess coming to a
standard will not be easy ;-) . The interfaces are quite different !
(although the concept of interfacing is easy enough to have a
simple routine interfacing with both simulators in only a few
hours).
Jos De Laender
I guess you mean _synthesis_ tools ? Simulators seem to be reasonably
close.
When I say _reasonably_ close, I'm having your usage of C++ in mind ;-)
There it took years to have a compiler that supported the full standard.
Even that bad that even now people are afraid of using STL / templates
or powerful things such as found in the boost library. So I would say
that in this respect VHDL is in good company ;-)
>
> TT
ticktack
> ticktack wrote:
>>
>> I think we are off the track.
>>
>> My interpretation of the original complain of the thread is "VHDL is a
>> language on paper". Although I do not agree that sensitivity list should
>> be removed, I agree that VHDL is a language that was designed to be too
>> ambitous. As a result, I have never seen a tool that can understand the
>> whole langauge.
>
> I guess you mean _synthesis_ tools ? Simulators seem to be reasonably
> close.
Not really. Modelsim has a problem of enum type, it thinks all enum types
are just integer. NCSim had more problems, for example,
it has restrictions on generics. Scirocco has more and more problems, I
don't have have the patient to know what went wrong.
Myself just use VHDL for RTL, but I am also dealing with the VHDL code produced by
others.
> When I say _reasonably_ close, I'm having your usage of C++ in mind ;-)
>
> There it took years to have a compiler that supported the full standard.
> Even that bad that even now people are afraid of using STL / templates
> or powerful things such as found in the boost library. So I would say
> that in this respect VHDL is in good company ;-)
What makes VHDL horrible is that all we get is a spec. Corperation has to
spend big bucks to buy those commercial stuff to find out that it actually
does not support the whole VHDL. In the C++ world, things are much
simpler -- if you don't like it, modify the GCC.
TT
Michal Rutka
[...]
ticktack> For modeling, can you tell me how much lines you have to
ticktack> write to model a fifo? (just the simplest you can think of)
I've just remember a real example. Once I've written a model of ATM
ASIC. Almost a half of the ASIC was an cell FIFO, a big one, via an
external DRAM. The FIFO had a dynamic delay. For modelling it I needed
just 1 line:
atm_out <= TRANSPORT atm_in AFTER cell_delay * atm_cell_duration;
This one line replaced about 40k gates (DRAM not included), thus not
only a FIFO itself, but a huge part of controller too.
Regards,
Michal
Michal Rutka
ticktack> features. However, I found there is a lot of contructs that
ticktack> nobody uses. For example, the statement block in a
ticktack> entity. As a language, it is huge.
I am a nobody that uses blocks. I found them very nice for defining a
local scope. Usually, on the entity level I have signals in a form of
records, and integers. When it comes down to write it to some RAM,
which has logic vectors as an interface, I make a conversion inside a
block, with signals locally defined in the block.
Regards,
Michal
Jos De Laender
> ticktack> For modeling, can you tell me how much lines you have to
> ticktack> write to model a fifo? (just the simplest you can think of)
>
> I've just remember a real example. Once I've written a model of ATM
> ASIC. Almost a half of the ASIC was an cell FIFO, a big one, via an
> external DRAM. The FIFO had a dynamic delay. For modelling it I needed
> just 1 line:
>
> atm_out <= TRANSPORT atm_in AFTER cell_delay * atm_cell_duration;
>
> This one line replaced about 40k gates (DRAM not included), thus not
> only a FIFO itself, but a huge part of controller too.
Super !
But a bit of cheating with respect to the original thread. You
(rightly) build on the event system being a FIFO.
Jos
ticktack
>>>>>> "ticktack" == ticktack <tick...@attbi.com> writes:
> [...]
> ticktack> For modeling, can you tell me how much lines you have to
> ticktack> write to model a fifo? (just the simplest you can think of)
>
> I've just remember a real example. Once I've written a model of ATM
> ASIC. Almost a half of the ASIC was an cell FIFO, a big one, via an
> external DRAM. The FIFO had a dynamic delay. For modelling it I needed
> just 1 line:
>
> atm_out <= TRANSPORT atm_in AFTER cell_delay * atm_cell_duration;
I think in general, FIFO in VLSI concerns about empty/full states, the
reason we want to model it is to find the boundary conditions for that.
I don't know what you can get from your code,
TT
ticktack
> I am a nobody that uses blocks. I found them very nice for defining a
> local scope. Usually, on the entity level I have signals in a form of
> records, and integers. When it comes down to write it to some RAM,
> which has logic vectors as an interface, I make a conversion inside a
> block, with signals locally defined in the block.
Why don't you use package? or just define in architecture?
The only case that make it nice is that, you have common stuff across your
architectures. Note, only one of your architecture would be elaborated, so
the "common" does not even exist.
I have never found a single case that can justify the usage of entity
statements. (I am a person don't like redundunt choices, how about you?)
TT
ticktack
> ticktack wrote:
>
>> >> I don't think you can write it in just a few lines.
>> >
>> > What would be the big problem ? I have no analyzer/elaborator right
>> > here available but I would go along the lines of :
>> >
>> > Define type of record containg
>> > whatever type you want to store in a fifo.
>> > access types to make a doubly linked list.
>> >
>> > Define two signals (marshalls) pointing to begin/end of list
>> >
>> > Define a push and pop procedure acting on this linked list.
>> > Push would do new SomeStruct and link it in. Pop would delete
>> > and link it out.
>> >
>> > Seems not more difficult nor easy then in C ?
>>
>> Why can't you use array instead of linked list?
>
> Same reason as in C : array is possible if you limit in
> advance the size of your problem. Mostly at the expense of
> overusing memory for the average case. An array of (pointers,
> access values) could be a compromise.
>
> But again, general implementations of vector-like things is
> often done with linked lists of dynamically allocated elements.
> You use C++, thus see to the STL for instance.
I don't know which STL you are using. Mine is array for vectors.
TT
Tuukka Toivonen
I'm nobody too =)
>> local scope. Usually, on the entity level I have signals in a form of
In article <pan.2002.10.01....@attbi.com>, ticktack wrote:
> Why don't you use package? or just define in architecture?
Packages don't specify local scope inside an architecture. A new
architecture for just signal conversion is an overkill (needs its own entity
too and can't be defined in-place).
Michal Rutka
ticktack> On Mon, 30 Sep 2002 14:24:08 +0200, Michal Rutka wrote:
>>>>>>> "ticktack" == ticktack <tick...@attbi.com> writes:
>> [...]
ticktack> For modeling, can you tell me how much lines you have to
ticktack> write to model a fifo? (just the simplest you can think of)
>> I've just remember a real example. Once I've written a model of
>> ATM ASIC. Almost a half of the ASIC was an cell FIFO, a big one,
>> via an external DRAM. The FIFO had a dynamic delay. For modelling
>> it I needed just 1 line:
>>
>> atm_out <= TRANSPORT atm_in AFTER cell_delay * atm_cell_duration;
ticktack> I think in general, FIFO in VLSI concerns about empty/full
ticktack> states, the reason we want to model it is to find the
ticktack> boundary conditions for that. I don't know what you can
ticktack> get from your code,
In general yes, but I was modelling an ASIC with a FIFO, so instead of
modelling general FIFO and controller, I just modelled two of them in
one line. Empty and full flags too ;-). After the FIFO, the ASIC has a
transmission MUX which generates empty ATM cell when FIFO is empty,
thus
IF atm_out'LAST_ACTIVE > atm_cell_duration THEN
cell_out <= empty_cell;
ELSE
cell_out <= atm_out;
END IF;
The FIFO overflow (full flag), means that the ASIC drops ATM cell. So
the cell_delay has a maximum (i.e. maximum numbers of cells that can
be stored in the DRAM). The TRANSPORT AFTER construction drops cells
automaticly for me.
With this code I was modelling a system, not a general FIFO. I never
needed to write a model of a general FIFO :-).
Regards,
Michal
ticktack
the package. If it specific to a certain operation, put it in the
architecture or process, function, procedure. Logically, I can't rule
out anything that is in-between. The question is that do you really need
that many different scopes?
Remember, you are not suppose to write an essay in the architecture.
Modulized it to function or procedure. If you want local things, you can
put it local there.
I really don't want to see many type definitions, many scopes, it is very
confusing when you build up large blocks.
Logically I understand that the entity statements have a different scope,
my argument is if it is helpful to make your code elegant. By and large,
I believe, it is a practical matter, So some real example would be
helpful.
Again, langauge (not code) should be elegant, and compact, VHDL is just
too big.
Youxin
ticktack
TT
On Tue, 01 Oct 2002 08:39:05 +0000, Tuukka Toivonen wrote:
Tuukka Toivonen
> Difficult to understand. Probably some code would help.
entity foo is
port(
a: in std_logic_vector(4 downto 0);
);
end;
architecture rtl of foo is
component bar is
port(
x: in integer range 0 to 31;
);
end component;
begin
ex1: block
signal x:integer range 0 to 31;
begin
x <= to_integer(unsigned(a));
b1: bar port map(x);
end block;
-- other statements here...
-- more statements...
-- very long architecture...
end;
..pseudo code etc. but should show why and where blocks are useful. Using
blocks, you can group concurrent statements like with processes you can
group sequential statements. Signals don't need to be defined then in the
beginning of the architecture, but near the place you actually need them.
This helps maintaining and understanding code (easy to find all places where
a particular signal is used).
Mike Treseler
> ..Using blocks, you can group concurrent statements like with processes you can
> group sequential statements. Signals don't need to be defined then in the
> beginning of the architecture, but near the place you actually need them.
For large architectures, keeping signal declarations near the related code
is a big win for readability.
The other advantage for large designs is limiting the scope
of signal identifiers. I might want use the identifer "counter" or "i"
in the block of processes I'm working on, without worrying about
previous or future use of that identifier in the rest of the architecture.
-- Mike Treseler
ticktack
Although I don't use BLOCK, I think your justification makes sense.
But I vaguely remember BLOCK is declared to be deprecated by the new VHDL
standard. I am not sure.
TT
Mike Treseler
ticktack wrote:
> Sorry, I thought you were talking about the statements in entity block.
> Although I don't use BLOCK, I think your justification makes sense.
> But I vaguely remember BLOCK is declared to be deprecated by the new VHDL
> standard. I am not sure.
VHDL uses BLOCK internally for handling components.
I Don't expect it will go away.
-- Mike Treseler
ticktack
BLOCK internally. As long as the standard does not require so (which I
think it should not), there is no need to use BLOCK to handle COMPONENT.
Maybe they decided not to remove it, as what I said, I am not sure.
TT
Mike Treseler
ticktack wrote:
>there is no need to use BLOCK to handle COMPONENT.
I agree. You don't need it in your code. The compiler uses it.
-- Mike Treseler