Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > VHDL signal activity and attributes ?

Reply
Thread Tools

VHDL signal activity and attributes ?

 
 
whygee
Guest
Posts: n/a
 
      04-13-2010
Hello,

I search a way to safely detect that all the signals
of my entities have settled before my testbench
fires another clock cycle. I find no way in the
langage to indicate that there is no delta cycle
left, so the time can advance to the next step.
And even in the next step, I can't know if activity
has been scheduled to happen :-/

I could XOR_reduce all the signals I want to observe
and then apply a simple attribute, but the closest
I come is the 'active attribute, that won't even
tell me if the signal is scheduled to change in the future.

All I could do is assume things about the tested design,
and these assumptions are dangerous and not future-proof
or fool-proof. Or else I could remove all the timing
information from the model, but this would remove
all value or interest in the model :-/

If anyone has a trick or idea, i'll gladly read it !

yg
--
http://ygdes.com / http://yasep.org
 
Reply With Quote
 
 
 
 
whygee
Guest
Posts: n/a
 
      04-13-2010
Hi !

Alan Fitch wrote:
> A postponed process is guaranteed to run after all deltas have passed -
> would that help? I'm not sure I quite understand what you're looking for,

oh yes, that's one idea.
It does not solve all my issues but it's an interesting method.
I don't have my reference books and must rely on the 'net
to find the informations.

Another side of the problem is :
how are the processes executed ?
I mean, if I write a process without sensitivity list,
which loops continuously, is the process executed
at every delta time ? Or does it loops continuously
inside the delta ? I imagine that the order in which
the processes are executed inside the delta is not
easily controlled but that can be circumvented.


> regards
> Alan

thank you,
yg

--
http://ygdes.com / http://yasep.org
 
Reply With Quote
 
 
 
 
whygee
Guest
Posts: n/a
 
      04-13-2010
hi !

Alan Fitch wrote:
> All postponed processes are guaranteed to run after all non-postponed
> processes.
> If you have more than one postponed process they will run in an
> unspecified order.
> A postponed process may not cause another delta.


OK, this confirms what I just read in other places.

"A postponed process can't cause another delta"
_at the same clock time_, but what if it causes
a delay and then causes another delta ?
I believe that it is ok because it avoids
the time paradox.

My current idea is to drop all the timing specification
of the model (I'll see later) and use something like :


signal clk : std_logic;

postponed process
begin
-- delay
wait for 1ms;
-- cause delta
if (clk='0')
then
clk<='1';
else
clk<='0';
end if;
end process;

Of course, this is not the end of the story,
since something as simple as this does
not require "postponed". Some side-effect-prone
stuff will be added later.

The fact that this postponed process is the only
timing controller helps things, but the tested
model might contain delayed signals which could
cause the whole thing to fall apart. I could
wait for more than 1ms, like 1 day or something "long"
but who knows what nasty side effect this could cause...

thanks for the hints, I knew I missed something

> regards
> Alan

yg
--
http://ygdes.com / http://yasep.org
 
Reply With Quote
 
Paul Uiterlinden
Guest
Posts: n/a
 
      04-13-2010
whygee wrote:

> Hi !
>
> Alan Fitch wrote:
>> A postponed process is guaranteed to run after all deltas have passed -
>> would that help? I'm not sure I quite understand what you're looking for,

> oh yes, that's one idea.
> It does not solve all my issues but it's an interesting method.
> I don't have my reference books and must rely on the 'net
> to find the informations.
>
> Another side of the problem is :
> how are the processes executed ?


They are all executed at simulation start (time=0, delta=0) and run until
they encounter a wait statement, which will suspend the process. A
sensitivity list is an implicit wait statement at the end of the process.
The process resumes after the wait statement is fulfilled.

Reaching the end of a process causes execution to continue at the top again.

> I mean, if I write a process without sensitivity list,


and without a wait statement...

> which loops continuously, is the process executed
> at every delta time ?


No.

> Or does it loops continuously inside the delta ?


Yes. And because the process never suspends, no delta cycle occurs anymore.
In other words: the simulator hangs, until you kill it.

Always a nice situation to debug, as you cannot break the simulator to
continue with single stepping, to find exactly where the error is. At
least, that's my experience with ModelSim.

> I imagine that the order in which
> the processes are executed inside the delta is not
> easily controlled but that can be circumvented.


The order of execution of processes that resume at exact the same delta is
undetermined. The delayed update of signals (one delta, or some real time,
like 1 ns) makes sure that this undeterministism is not a problem and does
not create a race condition. Unless of course you are mucking around with
shared variables, but that's another story.

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.
 
Reply With Quote
 
whygee
Guest
Posts: n/a
 
      04-13-2010
Paul Uiterlinden wrote:
> Reaching the end of a process causes execution to continue at the top again.

without waiting for another delta time,
if i understand correctly (and your post is clear about it)

>> I mean, if I write a process without sensitivity list,

> and without a wait statement...

yes (it's not mentioned, it's not implied)

>> which loops continuously, is the process executed
>> at every delta time ?

> No.
>
>> Or does it loops continuously inside the delta ?

> Yes. And because the process never suspends, no delta cycle occurs anymore.
> In other words: the simulator hangs, until you kill it.

ouch...

>> I imagine that the order in which
>> the processes are executed inside the delta is not
>> easily controlled but that can be circumvented.

> The order of execution of processes that resume at exact the same delta is
> undetermined. The delayed update of signals (one delta, or some real time,
> like 1 ns) makes sure that this undeterministism is not a problem and does
> not create a race condition. Unless of course you are mucking around with
> shared variables, but that's another story.

oh, it's probably worse than that

i've see "wait for 0ns" somewhere, i'll have to try too.

thanks,
yg
--
http://ygdes.com / http://yasep.org
 
Reply With Quote
 
Tricky
Guest
Posts: n/a
 
      04-14-2010

>
> > Or does it loops continuously inside the delta ?

>
> Yes. And because the process never suspends, no delta cycle occurs anymore.
> In other words: the simulator hangs, until you kill it.
>
> Always a nice situation to debug, as you cannot break the simulator to
> continue with single stepping, to find exactly where the error is. At
> least, that's my experience with ModelSim.
>



I was always under the impression that one loop of a process is 1
delta. If a process never waits, it will go for infinite delta's,
which is why you set an iteration limit inside modeslsim to prevent
loops like this occuring.
 
Reply With Quote
 
Paul Uiterlinden
Guest
Posts: n/a
 
      04-14-2010
Alan Fitch wrote:

> A delta consists of
>
> 1. All runnable processes run until they suspend (e.g. hit a wait, or in
> the case of a sensitivity list reach the bottom - which is of course an
> implicit "wait on")
>
> 2. Once all processes suspend, signals update (possibly creating events,
> which trigger processes to be runnable again - a new delta).
>
> This code
>
> process
> begin
> end process;
>
> gets stuck at time 0 ns delta 0 and can never escape.


And that's why ModelSim (don't know for other simulators) generates a nice
warning for such a situation:

** Warning: [2] stuck.vhd(: (vcom-1090) Possible infinite loop: Process
contains no WAIT statement.

And to get more explanation, run "verrror 1090":

vcom Message # 1090:
A process that has no sensitivity list, contains no wait statements,
and contains no calls to procedures that contain wait statements will
execute forever without advancing time.

IEEE Std 1076-2002, 9.2 Process statement:
The execution of a process statement consists of the repetitive
execution of its sequence of statements. After the last statement in
the sequence of statements of a process statement is executed,
execution will immediately continue with the first statement in the
sequence of statements.

This message can be suppressed with the vcom option -nowarn 2.

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.
 
Reply With Quote
 
whygee
Guest
Posts: n/a
 
      04-14-2010
Alan Fitch wrote:
> wait for 0 ns;
> will wait for 1 delta.

thanks for the confirmation,

> regards
> Alan

yg
--
http://ygdes.com / http://yasep.org
 
Reply With Quote
 
 
 
Reply

Thread Tools

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

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


Similar Threads
Thread Thread Starter Forum Replies Last Post
No Signal and Signal 'Low' MapleE. Wireless Networking 0 03-20-2010 08:32 PM
VHDL-2002 vs VHDL-93 vs VHDL-87? afd VHDL 1 03-23-2007 09:33 AM
Aside from delta cycles and/or resolution functions, how can the effective value of a signal differ from a driving signal of its? Colin Paul Gloster VHDL 0 01-11-2007 01:31 PM
threading.Thread vs. signal.signal Jack Orenstein Python 0 09-17-2005 11:24 PM
Async-signal safe functions in signal handlers (unix) Michael Pronath Python 1 01-03-2005 01:10 PM



Advertisments