Re: Showing my ignorance of VHDL again...

rickman wrote:
> . . .
> differently and reaches the end of the process. At the top of this
> process, it waits for the "Start" signal again, but if the "Start" flag
> is already set, it hangs.
>
> So does a wait statement always perform an edge detect by default?

No.
You can wait UNTIL an expression has a value of true or
you can wait ON a signal_id for *any* value change.

> Here is my wait statement...
> wait until ARM_Bus_Start or rising_edge(Reset);
> If ARM_Bus_Start is already set when this executes, the process hangs
> here.


Consider View, Source
and setting some breakpoints.
Run/step code and watch the signals.

Either the wait is in a different process
or ARM_Bus_Start is not true at the right time.

-- Mike Treseler

Mike Treseler

Mike Treseler wrote:
>
> rickman wrote:
> > . . .
> > differently and reaches the end of the process. At the top of this
> > process, it waits for the "Start" signal again, but if the "Start" flag
> > is already set, it hangs.
> >
> > So does a wait statement always perform an edge detect by default?
>
> No.
> You can wait UNTIL an expression has a value of true or
> you can wait ON a signal_id for *any* value change.
>
> > Here is my wait statement...
> > wait until ARM_Bus_Start or rising_edge(Reset);
> > If ARM_Bus_Start is already set when this executes, the process hangs
> > here.
>
> Consider View, Source
> and setting some breakpoints.
> Run/step code and watch the signals.
>
> Either the wait is in a different process
> or ARM_Bus_Start is not true at the right time.

I did look at everything in detail in the simulator. The wait statement
shown above executes with ARM_Bus_Start set to true and the process is
hung at that wait. I have solved the problem by testing ARM_Bus_Start
before I execute the wait and it runs as expected. So it is pretty
clear that the issue is the wait requiring a change in state of a signal
in the expression before it evaluates the expression.

I will try some more tests when I get a chance.

--

Rick "rickman" Collins


Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

rickman

"Thomas Stanka" <> wrote in message
news: om...
> Mike Treseler <> wrote:
> > You can wait UNTIL an expression has a value of true or
> > you can wait ON a signal_id for *any* value change.
>
> Modelsim don't come along with
>
> mysig<='1';
> wait for 1 us;-- to allow signal update
> wait until mysig='1';
>
> because mysig is allready '1'. In my opinion this is a bug, Modelsim
> should perform a test if mysig is allready '1' (Maybe there's
someone
> out correcting my opinion).
>
No, it's not a bug. It's the way VHDL is defined. As someone else
said, a wait statement is implicitly sensitive to all the signals
in the boolean condition. So in your example, you can re-write

wait until mysig = '1';

as

wait on mysig until mysig = '1';


In Rick's original example, where the testbench "hung", you can
sometimes use this approach

wait until ArmStart for 100 us; -- 100 us timeout
if ArmStart'EVENT then
-- yippee, event occurred before time out
-- so carry on

else
report "ArmStart didn't occur within 100 us - Doh!";
end if;

regards

Alan

--
Alan Fitch
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:

Fax: +44 (0)1425 471573 Web:
http://www.doulos.com

The contents of this message may contain personal views which are not
the
views of Doulos Ltd., unless specifically stated.

Alan Fitch

Don't waste your time. Think 2 sec. If the wait until was sensitive on
condition level and your signal ARM_Bus_Start is true for 10ns and your
simulator's resolution is set at 1ps then the process would be executed
10000 times in row. Your simulation will take 6 month to execute.

Check in your vhdl book. If you don't have a book, I recommend The
Designer's Guide to VHDL by Peter Ashenden.

P.A. wrote in is book : the condition is tested whenever an event occurs on
any of the signals mentioned in the condition.

regards
FE
Sr ASIC Designer

"rickman" <> wrote in message
news:...
> Mike Treseler wrote:
> >
> > rickman wrote:
> > > . . .
> > > differently and reaches the end of the process. At the top of this
> > > process, it waits for the "Start" signal again, but if the "Start"
flag
> > > is already set, it hangs.
> > >
> > > So does a wait statement always perform an edge detect by default?
> >
> > No.
> > You can wait UNTIL an expression has a value of true or
> > you can wait ON a signal_id for *any* value change.
> >
> > > Here is my wait statement...
> > > wait until ARM_Bus_Start or rising_edge(Reset);
> > > If ARM_Bus_Start is already set when this executes, the process hangs
> > > here.
> >
> > Consider View, Source
> > and setting some breakpoints.
> > Run/step code and watch the signals.
> >
> > Either the wait is in a different process
> > or ARM_Bus_Start is not true at the right time.
>
> I did look at everything in detail in the simulator. The wait statement
> shown above executes with ARM_Bus_Start set to true and the process is
> hung at that wait. I have solved the problem by testing ARM_Bus_Start
> before I execute the wait and it runs as expected. So it is pretty
> clear that the issue is the wait requiring a change in state of a signal
> in the expression before it evaluates the expression.
>
> I will try some more tests when I get a chance.
>
> --
>
> Rick "rickman" Collins
>
>
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design URL http://www.arius.com
> 4 King Ave 301-682-7772 Voice
> Frederick, MD 21701-3110 301-682-7666 FAX

FE