wait for argument a variable?

[Shannon]

Simple question: Can the argument in a "wait for (time)" be a
variable? (in a test bench of course. not worried about synthesis)

i.e.
some_integer := 7
....
holdtime := 10 * some_integer * 1 us;
wait for holdtime;

 

[jeppe]

Not sure but try something like this:

holdtime := 10 us * some_integer us;

 

[[email protected]]

Simple question: Can the argument in a "wait for (time)" be a
variable? (in a test bench of course. not worried about synthesis)

i.e.
some_integer := 7
....
holdtime := 10 * some_integer * 1 us;
wait for holdtime;

Yes. The above code will work and will wait for 70 us. See Dr. Ashenden's book (3rd edition) page 59.

 

[KJ]

Simple question:  Can the argument in a "wait for (time)" be a
variable?  (in a test bench of course.  not worried about synthesis)

i.e.
some_integer := 7
...
holdtime := 10 * some_integer * 1 us;
wait for holdtime;

Yes.

KJ

P.S. Wouldn't it be easier to just try this on a simulator rather
than posting to a newsgroup?

 

[Shannon]

Yes.

KJ

P.S.  Wouldn't it be easier to just try this on a simulator rather
than posting to a newsgroup?

My professors always told me to ask questions in class. If I have a
question likely others do too. Thank you for educating more than just
me today.

 

[Alessandro Basili]

My professors always told me to ask questions in class. If I have a
question likely others do too. Thank you for educating more than just
me today.

Your professors are definitely right in telling you so and I am also
very well convinced that none of your professors encouraged you to post
a question on a newsgroup if the answer is readily available somewhere
else or with some minor effort.

In this context I strongly suggest you a couple of readings that will
help you out building relationships in the community:

from the comp.lang.vhdl FAQ:

- http://www.vhdl.org/comp.lang.vhdl/FAQ1.html#0.3

from an interesting link that you can also find in the FAQ but that I
would like to underline as well:

- http://www.catb.org/~esr/faqs/smart-questions.html#before

For what concerns your question in particular, quoting the "IEEE
Standard VHDL Language Reference Manual" (IEEE Std 1076, 2000 Edition):

The wait statement causes the suspension of a process statement or a procedure.
wait_statement ::=
[ label : ] wait [ sensitivity_clause ] [ condition_clause ] [ timeout_clause ] ;
sensitivity_clause ::= on sensitivity_list
sensitivity_list ::= signal_name { , signal_name }
condition_clause ::= until condition
condition ::= boolean_expression
timeout_clause ::= for time_expression

Since your variable/constant is of type TIME, your situation does follow
the standard.

Al

 

[Shannon]

wow. seriously? I'm being scolded for asking a simple question.
REALLY?? I mean sorry to put you out. Sorry to massively affect the
traffic in this NG. If it's beneath you to help then DON'T REPLY! Is
this the way you really want to moderate this group? Sheesh. I
apologize if my question was not up to your standards.

P.S. seriously?

My professors always told me to ask questions in class.  If I have a
question likely others do too.  Thank you for educating more than just
me today.

Your professors are definitely right in telling you so and I am also
very well convinced that none of your professors encouraged you to post
a question on a newsgroup if the answer is readily available somewhere
else or with some minor effort.

In this context I strongly suggest you a couple of readings that will
help you out building relationships in the community:

from the comp.lang.vhdl FAQ:

 -http://www.vhdl.org/comp.lang.vhdl/FAQ1.html#0.3

from an interesting link that you can also find in the FAQ but that I
would like to underline as well:

 -http://www.catb.org/~esr/faqs/smart-questions.html#before

For what concerns your question in particular, quoting the "IEEE
Standard VHDL Language Reference Manual" (IEEE Std 1076, 2000 Edition):

The wait statement causes the suspension of a process statement or a procedure.
wait_statement ::=
[ label : ] wait [ sensitivity_clause ] [ condition_clause ] [ timeout_clause ] ;
sensitivity_clause ::= on sensitivity_list
sensitivity_list ::= signal_name { , signal_name }
condition_clause ::= until condition
condition ::= boolean_expression
timeout_clause ::= for time_expression

Since your variable/constant is of type TIME, your situation does follow
the standard.

Al

 

[Jonathan Bromley]

from an interesting link that you can also find in the
FAQ but that I would like to underline as well:

- http://www.catb.org/~esr/faqs/smart-questions.html#before

Whoa. First off, what's "not smart" about the OP's
question? It shows inquiry, interest, and a reasonable
grasp of the basics. Looks fine to me. How many VHDL
users do _you_ know who can tell you the _full_ story
about the wait statement? It's complicated and subtle.

Second, let's not get too hung up about Eric Raymond's
priggish and defensive protection of his chosen tribe
of hackers. As usual with his stuff, you'll find much
wisdom in that article - but also much that irritates
and makes little sense outside the self-satisfied
community of hackers. Take with a pinch of salt.

Sure, the OP could have found the answer for himself.
But KJ's suggestion that he try it in a simulator is
disingenuous: tools have bugs, and sometimes support
non-LRM-conforming constructs because some big customer
demanded it, so that's not a safe way to decide what's
OK and what's not. And the VHDL LRM is a very densely
written and highly technical document; it's usually
easier to ask an expert than to ask the LRM, especially
if you're not an experienced LRM wonk.

To Shannon: yes, wait-for can be given an arbitrary
expression provided it yields a result of type "time".
The expression is computed at the moment execution
hits the wait statement, and its value determines
the wait behaviour.

 

[KJ]

Sure, the OP could have found the answer for himself.  
But KJ's suggestion that he try it in a simulator is
disingenuous:

Perhaps you should re-read my post. I answered the OP's question
straight off, clearly, concisely and politely.

As a postscript, I simply suggested that it would likely be easier to
simply try the idea out rather than posting to a newsgroup and waiting
for an answer (and did not write it in a way that suggested that the
question was somehow beneath the standards of the group).

As I did in this case, there are many times in the past when I've
suggested that people try it out for themselves. That is sound
advice. Trying and doing for yourself in almost all cases makes for a
better learning experience than simply reading the words of others.
Not only that, but sometimes you find that people post rubbish...but
the way that you find out that it is rubbish is by actually trying it
out for yourself. You stating that I was being disingenuous when I
wasn't seems to show that you got torqued by Basili's response and
decided to take it out on both him and me.

You likely know the saying about 'Give a man a fish...'. I gave the OP
the fish as well as a lesson in fishing.

tools have bugs, and sometimes support
non-LRM-conforming constructs because some big customer
demanded it, so that's not a safe way to decide what's
OK and what's not.

You're off on a tangent here...but OK. But let me also point out that
in the situations you just described the *only* way to demonstrate the
bug or non-conformance is to *use* the tool.

And the VHDL LRM is a very densely
written and highly technical document; it's usually
easier to ask an expert than to ask the LRM, especially
if you're not an experienced LRM wonk.

I agree, but will add
- Many times an 'expert' comes in the form of software that can be
queried rather than the response from a human.
- The human can also be in error as well whether or not they are an
'expert' or not.

Learning can come about in many ways, don't discount any
method...unless it has really been shown to be a poor learning method,
or a method that just simply doesn't work for you.

Kevin Jennings

 

[Jonathan Bromley]

As a postscript, I simply suggested that it would likely be easier to
simply try the idea out rather than posting to a newsgroup and waiting
for an answer (and did not write it in a way that suggested that the
question was somehow beneath the standards of the group).
Accepted.

You stating that I was being disingenuous when I
wasn't seems to show that you got torqued by Basili's response and
decided to take it out on both him and me.

Could be, although I still think it's worth pointing out the
possible weakness in "trying it out" as a way of checking whether
something is legal in the language. I would never dispute that
experiment is a valuable learning tool, though.

- Many times an 'expert' comes in the form of software that can be
queried rather than the response from a human.
- The human can also be in error as well whether or not they are an
'expert' or not.

All entirely true. We're in a field where Stuff Is Complicated,
and any source of information - experts, commonsense, software,
even the LRM - can be flawed by human error. Oftentimes the answer
is simple, unambiguous and pretty much universally agreed. But
you need to be on your guard for those few places where something
goes wrong.

For context, and as an excuse: I'm struggling right now (along
with a lot of colleagues) on migrating a large codebase from
one tool to another, and finding that their LRM conformance
is <cough> imperfect. So I'm a tad sensitive about
such things. Should mention, though, that my woes are with
SystemVerilog. VHDL is much better specified and less messy.

 

[Jan Decaluwe]

For context, and as an excuse: I'm struggling right now (along
with a lot of colleagues) on migrating a large codebase from
one tool to another, and finding that their LRM conformance
is<cough> imperfect. So I'm a tad sensitive about
such things. Should mention, though, that my woes are with
SystemVerilog. VHDL is much better specified and less messy.

Are you also struggling with LRM-compliant but different
behavior among tools? (As fas as I can tell, SystemVerilog
has produced even more opportunities for nondeterministic races
than Verilog.)

 

[Alessandro Basili]

Whoa. First off, what's "not smart" about the OP's
question? It shows inquiry, interest, and a reasonable
grasp of the basics. Looks fine to me. How many VHDL
users do _you_ know who can tell you the _full_ story
about the wait statement? It's complicated and subtle.

I have never qualified the question as "not smart" (it's not my fault if
the link name is called that way) and indeed I took the time to point
out a reference (in this case the LRM) to solve the OP's doubt.

My point was rather about the method than the subject. I never talked
about "standards" of any question, but I felt that the OP confused the
newsgroup with her class:

My professors always told me to ask questions in class. If I have a
question likely others do too. Thank you for educating more than just
me today.

which IMHO is not true. Therefore the suggestions to follow the NG's FAQs.

Second, let's not get too hung up about Eric Raymond's
priggish and defensive protection of his chosen tribe
of hackers. As usual with his stuff, you'll find much
wisdom in that article - but also much that irritates
and makes little sense outside the self-satisfied
community of hackers. Take with a pinch of salt.

I do agree that *everything* should be taken with a pinch of salt, even
the words of an expert that share his wisdom or simply his point of
view. I find Eric Raymond's article quite to the point when he talks
about doing something "before you ask", that is why I pointed out the
link to that paragraph.

If you are concerned that Eric Raymond's article does not embody the
spirit of this NG I would probably be on the same boat, nevertheless I
take it with the grain of salt it needs to extract any useful
information from the noise of nowadays communications.
If you think the quoted article is disrespectful and should be removed
from the FAQs of this NG than probably we need to face this issue more
intensively and I encourage you to send your comments to the editor of
the FAQ:

(e-mail address removed)-technik.uni-dortmund.de (Edwin Naroska)

or maybe open a dedicated thread (which can be ignored by people not
interested).

Sure, the OP could have found the answer for himself.

That is why I also pointed out the "try yourself first" approach
reported in Raymond's article.
This approach is surely the most powerful even though potentially very
dangerous, since we can be deceived by the fact that "it worked" and
miss the grasp on the problem. I doubt though the OP was interested in
your mentioned complicated and subtle nuances of the "wait statement".
She showed interest in a case where the wait statement was involved and
the time expression was a variable of TIME type and that's it (or at
least I didn't catch anything between the lines).

But KJ's suggestion that he try it in a simulator is
disingenuous: tools have bugs, and sometimes support
non-LRM-conforming constructs because some big customer
demanded it, so that's not a safe way to decide what's
OK and what's not. And the VHDL LRM is a very densely
written and highly technical document; it's usually
easier to ask an expert than to ask the LRM, especially
if you're not an experienced LRM wonk.

Do you really believe the OP would have asked the question if she went
through a simulator without any problem? And what is the added value of
an expert with the respect to a tool which is used by tons of users who
are actively reporting all sorts of bugs? On top of it the OP didn't ask:

Can the argument in a "wait for (time)" be a
variable? since the simulator XYZ is giving me an error of type 123.

which would have been much more appropriate, showing the interest of the
OP to solve his/her problem and triggering the possibility for a "bug
report".

I found KJ's suggestion rather to the point and I admit I got a little
shaky myself on the OP's reply to that post when she disingenuously
wrote about her professors.

I do not argue the value of the question, but I do disagree with the
process the OP chose to learn something. Have I been too rude? Did I
hurt somebody's feeling? Well I didn't intend to, but I do believe the
NG is a valuable resource for people to learn, stimulating thoughts and
doubting answers, in a process that foster searches and exchange of
point of views and I did not read any of the former in the OP's first
intent.

Al

 

[Jonathan Bromley]

Are you also struggling with LRM-compliant but different
behavior among tools? (As fas as I can tell, SystemVerilog
has produced even more opportunities for nondeterministic races
than Verilog.)

After all these years, my sanity-preservation strategies
are fairly well honed

I'm not sure why you think SV is any worse than vanilla
Verilog. It also provides various tools to help you if
you are perverse enough to want to get things right:
clocking blocks, $sampled, ... although those too have
their pitfalls, and the poor RTL designer is in just
as much of a mess as always (pun intended).

 

[Jan Decaluwe]

After all these years, my sanity-preservation strategies
are fairly well honed

I had inferred - probably incorrectly - that the original
code was written by someone else

I'm not sure why you think SV is any worse than vanilla
Verilog.

Not from personal experience, and perhaps incorrect again.

My thoughts about this orginate from reading Janick Bergeron's
"Writing Testbenches with SystemVerilog", when he explains
program versus module threads and why you need "clocking"
blocks to describe proper synchronous behaviour.

Jan

 

[Jonathan Bromley]

My thoughts about this orginate from reading Janick Bergeron's
"Writing Testbenches with SystemVerilog", when he explains
program versus module threads and why you need "clocking"
blocks to describe proper synchronous behaviour.

This is getting a bit OT for c.l.vhdl, but it may
at least provide a few moments of schadenfreude.

Way back when, program blocks, clocking blocks
and modules all worked together in a specific
way to give race-free interaction between testbench
and DUT. Unfortunately, when SV hit the public
streets, people started doing odd things. First
they asked what would happen if you used a clocking
block without a program block, or vice versa, since
there's nothing in the language syntax to say you
can't do that. Second, people had the temerity
to create verification environments where the
DUT/TB division was perhaps not quite so clear-cut
as the inventors of clocking and program blocks
might have imagined. And finally, they sometimes
manipulated signals (and even, horror of horrors,
clocking blocks) in a way that wasn't directly
related to any clock. Faced with this rebellious
and perverse behaviour by users, the SV community
had no choice but to specify in reasonable detail
what these constructs actually do. And some of
those things are not terribly convenient, but
at least they are now (since 1800-2009) fairly
well defined. Used properly, they are not
plagued by nondeterminism.

So we're now left with the situation that
clocking blocks and programs give a certain
set of very useful behaviours if used in just
the right way; but, when abused, those same
constructs can do remarkably silly things.

Anyway... like I said, it's way OT for here.
Still kinda fun, though.