Clock Edge notation

[Kevin Neilson]

"Ray Andraka" <ray@andraka.com> wrote in message
news:3F134720.D19A8BCA@andraka.com...

Mine used a barrel shift in the feedback to get a gain that increased with
the
size of the error. Had to do that to get a quick lock and still be able
to
chase the reference. The reference was derived from a quad encoder on the
mechanical media path. The PLL had to adjust a process to keep a certain
number
of events between encoder pulses. All in all, it was a pretty nasty
problem
because of the dynamics and limited resolution of the encoder.

Kevin Neilson wrote:

I like that idea. Actually, I recalled that mine had a time-varying gain,
but it was much simpler. The gain was high before lock, and after locking,
the gain switched to something lower. The gain was just implemented by
left-shifting the output from the loop filter (which was just a comb or
moving-average filter), so the gain could only be powers of two. Does the
barrel shifter you describe increase the order of the loop? That probably
makes it a lot harder to describe mathematically. I would have liked to do
an analysis of mine, but of course I didn't have time, and for my
application stability was much more important than lock time so I didn't
really have to optimize it.
-Kevin

 

[Kevin Neilson]

"Ray Andraka" <ray@andraka.com> wrote in message
news:3F134720.D19A8BCA@andraka.com...

Mine used a barrel shift in the feedback to get a gain that increased with
the
size of the error. Had to do that to get a quick lock and still be able
to
chase the reference. The reference was derived from a quad encoder on the
mechanical media path. The PLL had to adjust a process to keep a certain
number
of events between encoder pulses. All in all, it was a pretty nasty
problem
because of the dynamics and limited resolution of the encoder.

Kevin Neilson wrote:

I like that idea. Actually, I recalled that mine had a time-varying gain,
but it was much simpler. The gain was high before lock, and after locking,
the gain switched to something lower. The gain was just implemented by
left-shifting the output from the loop filter (which was just a comb or
moving-average filter), so the gain could only be powers of two. Does the
barrel shifter you describe increase the order of the loop? That probably
makes it a lot harder to describe mathematically. I would have liked to do
an analysis of mine, but of course I didn't have time, and for my
application stability was much more important than lock time so I didn't
really have to optimize it.
-Kevin

 

[Kevin Neilson]

"Ray Andraka" <ray@andraka.com> wrote in message
news:3F134720.D19A8BCA@andraka.com...

Mine used a barrel shift in the feedback to get a gain that increased with
the
size of the error. Had to do that to get a quick lock and still be able
to
chase the reference. The reference was derived from a quad encoder on the
mechanical media path. The PLL had to adjust a process to keep a certain
number
of events between encoder pulses. All in all, it was a pretty nasty
problem
because of the dynamics and limited resolution of the encoder.

Kevin Neilson wrote:

I like that idea. Actually, I recalled that mine had a time-varying gain,
but it was much simpler. The gain was high before lock, and after locking,
the gain switched to something lower. The gain was just implemented by
left-shifting the output from the loop filter (which was just a comb or
moving-average filter), so the gain could only be powers of two. Does the
barrel shifter you describe increase the order of the loop? That probably
makes it a lot harder to describe mathematically. I would have liked to do
an analysis of mine, but of course I didn't have time, and for my
application stability was much more important than lock time so I didn't
really have to optimize it.
-Kevin

 

[Kevin Neilson]

"Ray Andraka" <ray@andraka.com> wrote in message
news:3F134720.D19A8BCA@andraka.com...

Mine used a barrel shift in the feedback to get a gain that increased with
the
size of the error. Had to do that to get a quick lock and still be able
to
chase the reference. The reference was derived from a quad encoder on the
mechanical media path. The PLL had to adjust a process to keep a certain
number
of events between encoder pulses. All in all, it was a pretty nasty
problem
because of the dynamics and limited resolution of the encoder.

Kevin Neilson wrote:

I like that idea. Actually, I recalled that mine had a time-varying gain,
but it was much simpler. The gain was high before lock, and after locking,
the gain switched to something lower. The gain was just implemented by
left-shifting the output from the loop filter (which was just a comb or
moving-average filter), so the gain could only be powers of two. Does the
barrel shifter you describe increase the order of the loop? That probably
makes it a lot harder to describe mathematically. I would have liked to do
an analysis of mine, but of course I didn't have time, and for my
application stability was much more important than lock time so I didn't
really have to optimize it.
-Kevin

 

[Jay]

In article se10110@yahoo.com says...

Hi all.

I was actually thinking about digital PLLs recently when I was doing
investigation on analog PLLs.

Can someone describe the basic parts and operation of a DPLL?
Essentially these are the components I figured would be needed and this
is how the operation might work, I'd appreciate comments....

Just wondering, I never got any responses to my original (and slightly
off-topic) post. Was I off in my design insights? I'm actually thinking
about using my aforementioned design in a project, I would like to know
if it's a good starting point or not...

One thing I was particularly curious about, when thinking about my own
design, do I have to worry about synchronizing / clock domain problems
between the two reference inputs to the loop or does the standard two-
DFF design actually take care of that?

I'm guessing that the *outputs* (Up/Down) from the DFF loop should be
put through a de-metastablizer (two DFF in series or something) since
those outputs could change irrespective of my system clock. Comments?

Oh, finally, is there a better frequency/phase detector than the
standard two-DFF one? I know that the two-DFF one hunts when the
phase/frequency are close to being locked.

Thanks!

-- Jay.

 

[Rudolf Usselmann]

Jasson,

take a look at out free USB 1.1 PHY IP core. It includes
a very simple DPLL. It is written in Verilog however.

Best Regards,
rudi
--------------------------------------------------------
www.asics.ws --- Solutions for your ASIC/FPGA needs ---
----------------- FPGAs * Full Custom ICs * IP Cores ---
FREE IP Cores --> http://www.asics.ws/ <-- FREE IP Cores

 

[Charles M. Elias]

"Brad Smallridge" <bsmallridge@dslextreme.com> wrote in message news:<vhav5viql77dbc@corp.supernews.com>...

It would appear, however, that I can get the Global Signals to work as
inputs. But when I do, then I loose an I/O. That doesn't seem right. Like
buying a three input OR gate and only being able to use two of the inputs at
any one time.

Brad

Brad,

I can't explain the loss of other I/O pins when the global signals are
used. This could be a fitter problem. If it is, I wish you the best
of luck trying to get Cypress to fix it.

We are having a number of difficulties with the 39K device fitter.
One of the scariest ones is this: We successfully fitted a design and
then wished to make a change that involved adding a pin. Since the
prototype board is already wired, we "fixed" the previously fitted
pins prior to fitting the design with the added pin. The design does
not fit. As a sanity check, we removed the new signal from the design
and tried to fit it with the pins "fixed" as the fitter previously
assigned them. The design will not fit. If we remove the compiler
directive that keeps the pinout from changing, the design will fit and
has the same pinout that we instructed it to keep. This does not bode
well for future designs where one wants to make a change without
changing the pin assignments previously made.

I am sorry to report that Cypress seems unwilling to fix this and
several other problems with the 39K fitter.

Best regards,

Charles

 

[Ray Andraka]

No it was a fixed second order loop. The barrel shifts just increased the
gain.

Kevin Neilson wrote:

"Ray Andraka" <ray@andraka.com> wrote in message
news:3F134720.D19A8BCA@andraka.com...
Mine used a barrel shift in the feedback to get a gain that increased with
the
size of the error. Had to do that to get a quick lock and still be able
to
chase the reference. The reference was derived from a quad encoder on the
mechanical media path. The PLL had to adjust a process to keep a certain
number
of events between encoder pulses. All in all, it was a pretty nasty
problem
because of the dynamics and limited resolution of the encoder.

Kevin Neilson wrote:


I like that idea. Actually, I recalled that mine had a time-varying gain,
but it was much simpler. The gain was high before lock, and after locking,
the gain switched to something lower. The gain was just implemented by
left-shifting the output from the loop filter (which was just a comb or
moving-average filter), so the gain could only be powers of two. Does the
barrel shifter you describe increase the order of the loop? That probably
makes it a lot harder to describe mathematically. I would have liked to do
an analysis of mine, but of course I didn't have time, and for my
application stability was much more important than lock time so I didn't
really have to optimize it.
-Kevin

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@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

 

[Glen Herrmannsfeldt]

"Jason Berringer" <look_at_bottom_of@email.com> wrote in message
news:kJCVa.3413$Cx4.543634@news20.bellglobal.com...

Hello, I have attached a portion of code for a binary to bcd counter, 20
bits parallel input, and a 24 bit BCD output parallel. Although internally
it converts it to serial to go through the conversion. I'm attempting the
shift and add three (if greater than or equal to 5) method, but I am
having
some problems. It works great on the simulator (Aldec Active HDL) and I
can
synthesize it but when I put it on the chip I'm getting some odd things. I
am using 16 input toggle switches and i debounced pb switch as a load
switch, and my outputs are LEDs. When I set this up on the board my
outputs
go as follows:

The attachment didn't come through. Can you just include some of the code
in the body, instead of an attachment?

-- glen

 

[Glen Herrmannsfeldt]

"Glen Herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:MzFVa.9078$cF.2637@rwcrnsc53...

"Jason Berringer" <look_at_bottom_of@email.com> wrote in message
news:kJCVa.3413$Cx4.543634@news20.bellglobal.com...
Hello, I have attached a portion of code for a binary to bcd counter, 20
bits parallel input, and a 24 bit BCD output parallel. Although
internally
it converts it to serial to go through the conversion. I'm attempting
the
shift and add three (if greater than or equal to 5) method, but I am
having
some problems. It works great on the simulator (Aldec Active HDL) and I
can
synthesize it but when I put it on the chip I'm getting some odd things.
I
am using 16 input toggle switches and i debounced pb switch as a load
switch, and my outputs are LEDs. When I set this up on the board my
outputs
go as follows:

The attachment didn't come through. Can you just include some of the code
in the body, instead of an attachment?

OK, it did come through but I was looking in the wrong place. Still, it is
often easier just to include it.

I am much better at reading verilog than VHDL, but it doesn't look right to
me. Though I think I don't understand the algorithm, I think it needs to be
more complicated than that, though if you do an iterative algorithm it might
not be so hard. How many clock cycles does it take to get the data from
input to output? How many different values did you put through the
simulator in testing?

-- glen

 

[Glen Herrmannsfeldt]

"Jason Berringer" <look_at_bottom_of@email.com> wrote in message
news:IlGVa.3393$mv6.617644@news20.bellglobal.com...

Here is the code (after my text) instead of an attachment in case others
cannot read it.

It takes (or should take) 20 to 21 clock cycles to get the data from the
input to the output. I put a few numbers through the simulation the only
correct values are 0 and 1, all other tested were incorrect. I'm pretty
sure
it's a simple error that I'm not catching, I just can't see it at present.
Most of the stuff that I have done has been a bit more simple than this.
The
algorithm works from a sample I've seen (no code just an explanation).
Start
by shifting the most significant bit of your binary number into the least
significant bit of your "units" bcd value, when the number in the "units"
value is 5 or greater add 3 to it. Shift again, if the value is 5 or
greater
add 3 to it, the values will continue to spill over to the "tens",
"hundreds", "thousands", etc. You must add 3 to each of the bcd digits if
any is five or greater, by the last shift (same number of shifts as your
input binary value (in my case 20 bits)) you'll have the bcd
representation.
The example I mentioned above was for a microcontroller.

As I said, I read Verilog much better than VHDL. I didn't even notice the
loop yesterday, which is why I didn't think it was complicated enough. OK,
thought for today:



(snip)

elsif rising_edge(clk) then

Does the following generate a gated clock?

if shift_en_s = '1' then

The following statement must be done before the rest. While simulators may
execute them in order, synthesized logic tends to execute them all at the
same time.

bcd_value := bcd_value(22 downto 0) & ser_out_s;
bcd_out_s <= bcd_value;

Does this generate a gated clock? Can you do it in traditional synchronous
logic form, where either the previous contents, or the contents with "0011"
added are loaded back in? (Also with the shift_en_s enable.)

if bcd_value(3 downto 0) >= "0101" then
bcd_value(3 downto 0) := bcd_value(3 downto 0) + "0011";
end if;

(snip)

Gated clocks are especially hard in FPGA's.

-- glen

 

[Mike Treseler]

Glen Herrmannsfeldt wrote:

Does the following generate a gated clock?
if shift_en_s = '1' then

Not if it follows the line

elsif rising_edge(clk) then

in a synchronous process.

It's the process template that
gives you a synchronous clock, not
any single sequential statement.

The following statement must be done before the rest. While simulators may
execute them in order, synthesized logic tends to execute them all at the
same time.


bcd_value := bcd_value(22 downto 0) & ser_out_s;
bcd_out_s <= bcd_value;

Actually, the synth will give you a netlist that simulates
the same as that code, executed in order.

Sequential statements execute in zero sim time.
The only delay is for rising_edge(clk).

Your code is a hardware specification that can only
be completely understood in the context of simulation. There is
usually no one-to-one correspondence between code statements
and the synthesis netlist components.

Does this generate a gated clock? Can you do it in traditional synchronous
logic form, where either the previous contents, or the contents with "0011"
added are loaded back in? (Also with the shift_en_s enable.)


if bcd_value(3 downto 0) >= "0101" then
bcd_value(3 downto 0) := bcd_value(3 downto 0) + "0011";
end if;

This synthesizes nothing unless bcd_value is assigned
directly or indirectly to an entity port.

If this assignment occurs within a synchronous process,
the output will be registered by clk.

Gated clocks are especially hard in FPGA's.

If you stick to the synchronous process template, you
will never have one to worry about.

-- Mike Treseler

 

[Mike Treseler]

Paul Leventis wrote:

Hi Jason,

First off, that's a pretty cool little algorithm... had to prove to myself
that it worked. ...

I'm not sure that I've found the problem with your code, ...

The best and quickest way to do both is to write a testbench an run a sim.
This quickly resolves all questions about how the langage works
and how the logic functions.

(0) I think the first problem is a lack of comments... uncommented code is
always wrong

My favorite comments are a plain text description at the top of each
process about function and handshake protocols.
These can be collected at the top of the architecture after the
sim is working.

Detail comments at the end of line, can often be replaced by
by well-named statement labels, constants and variables.

(1) Process #3. I hate variables. Especially variables mixed with
signals...

Signals are the only way in and out of a process.

you must be very disciplined when using variables (I only use
them in for loops...). So I honestly don't know what the code will
translate into, as you are assigning a value to variable, then assigning to
the variable to a signal, then changing the value of the variable.

In the case referenced, the first value is exported to the signal at
the next clk and the second value is held by the variable until the next clk, if
it is needed.

This is not as complex as you think. Variables are stuck inside the process.
They only reach the entity ports if you make a signal assignment inside
the process. Synthesis will use a register to save the variable's *final* value.
only if this value is needed at the next clk.

Run a sim sometime, and watch the variables as you trace code.

-- Mike Treseler

 

[Peter Alfke]

Here is a time-proven hardware design for bit-serial binary to parallel
BCD conversion. (I published this in 1973 in the Fairchild TTL
Applications Handbook).

Implement a bunch of 4-bit loadable shift register, but do not
interconnect them.
For each shift register drive a 4-bit adder (without carry in, but with
carry output) from the 4 shift register outputs. Put a binary eleven (B)
as other input on the adder.
Connect the adder outputs to the shift register load inputs, but skewed
one position downstream ( bit 0 of the adder drives bit 1 of the shift
register ).
Then use the carry output as load enable for "its" shift register, and
also as input for the LSB of the downstream shift register ( both as
shift- and as load- input)
The S3 output ( most significant sum) goes nowhere. That's it.

Shifting in binary data (MSB first) doubles the binary value on every
shift. The adder monitors this and, on its carry output, signals that
there is a value 5 or larger, which needs intervention: add 3 before the
next shift ( which is equivalent to adding 6 after having shifted it)
and load a carry into the next higher bit position.
The neat trick is that the 4-bit adder simultaneously adds eleven to
create a carry that detects the need for modification, and also adds
three to do the modification.

Shift in binary data, MSB first, and watch the BCD develop on the
parallel shift register outputs. Note that BCD needs more bit positions
than binary, so leave some headroom.
Works like a champ, flawlessly since 30 years ago.

Peter Alfke, no longer at Fairchild (but it was an interesting 10 years)
====================

Mike Treseler wrote:

Paul Leventis wrote:
Hi Jason,

First off, that's a pretty cool little algorithm... had to prove to myself
that it worked. ...

I'm not sure that I've found the problem with your code, ...

The best and quickest way to do both is to write a testbench an run a sim.
This quickly resolves all questions about how the langage works
and how the logic functions.

(0) I think the first problem is a lack of comments... uncommented code is
always wrong

My favorite comments are a plain text description at the top of each
process about function and handshake protocols.
These can be collected at the top of the architecture after the
sim is working.

Detail comments at the end of line, can often be replaced by
by well-named statement labels, constants and variables.

(1) Process #3. I hate variables. Especially variables mixed with
signals...

Signals are the only way in and out of a process.

you must be very disciplined when using variables (I only use
them in for loops...). So I honestly don't know what the code will
translate into, as you are assigning a value to variable, then assigning to
the variable to a signal, then changing the value of the variable.

In the case referenced, the first value is exported to the signal at
the next clk and the second value is held by the variable until the next clk, if
it is needed.

This is not as complex as you think. Variables are stuck inside the process.
They only reach the entity ports if you make a signal assignment inside
the process. Synthesis will use a register to save the variable's *final* value.
only if this value is needed at the next clk.

Run a sim sometime, and watch the variables as you trace code.

-- Mike Treseler

 

[Mike Treseler]

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

 

[rickman]

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

rick.collins@XYarius.com
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

 

[Rienk van der Scheer]

rickman wrote:

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.

I am using ModelSim XE II/Starter 5.6e.

Suggestion:

if (ARM_Bus_Start) then
-- continue immediately
else
-- note: removed rising_edge because it is implied in the 'wait until'
wait until ARM_Bus_Start or Reset;
endif;

Your problem is that you should remember that a wait statement in VHDL
will always wait for some event. In your situation, you don't want to
wait at all when the condition is already met.

Regards,

Rienk

 

[Alan Fitch]

"Thomas Stanka" <thomas@stanka-web.de> wrote in message
news:d92cdee8.0308040057.30784b34@posting.google.com...

Mike Treseler <mike.treseler@flukenetworks.com> 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:
alan.fitch@doulos.com
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.

 

[FE]

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" <spamgoeshere4@yahoo.com> wrote in message
news:3F2DF114.F6DDB8AE@yahoo.com...

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

rick.collins@XYarius.com
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

 

[Alan Fitch]

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3F2EFF97.9072E30A@yahoo.com...

I added a variable to calculate a time for a wait statement in a
testbench and am not getting this error from ModelSim...
^^^ now??

Signal arm_command is read by the VITAL process but is NOT in the
sensitivity list

This is the line of code producing the error...

WaitTime := (ARM_command.RelTime - (now - CurrentTime));

I follow this up with a check for negative values before using in
the
wait. ARM_command is a signal and WaitTime and CurrentTime are
variables. And of course all these objects are of type time. This
same
calculation done directly in the wait statement gives no error.

It sounds like Modelsim is confused. Is it actually an error, or just
a warning? Having a signal read that is not in the sensitivity list
is not an error. Can you disable Modelsim's synthesis checks?

If it's a warning, just ignore it.

If it's an error, it sounds like a bug.

regards

Alan

p.s. I know it's nothing to do with this error, but I'd check for
negative values before assigning, just because I am paranoid (!). In
particular I wonder what happens if you assign a negative time value
to a variable of type time?
e.g.

assert ( (ARM_command.RelTime - (now - CurrentTime)) >= 0 ns )
report "negative time value";

waittime := ...

p.p.s.
Reading the LRM shows I really am being paranoid, as type TIME is
guaranteed to include the range -2**9+1 to 2^9-1, so negative
time values in variables of type TIME are ok.





--
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:
alan.fitch@doulos.com
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.