Clock Edge transitions..

[VHDL User]

Hi All,
I have a basic doubt. When a signal transitions on a clock edge, and I
want to use the final value of this signal for computation on the same
clock edge (and drive some other signal on the same edge) HOW do I do it ?
Simulation takes the previous value of the signal as the transition is
scheduled ater the simulation delta. I also fear a race condition like
situation.
This is my code :

Ap : process(Clk)
begin
if (posedge(Clk))
A<='1';
end if;
end process Ap;
Bp : process(Clk)
begin
if (posedge(Clk) and A='1')
B<='1';
end if;
end process Bp;

A is global signal, so access by Bp is not a issue.When Ap and Bp get
executed simultaneously, on the +ve edge, an event is scheduled on A after
Simulation delta.This would mean the B signal would be asserted only on
next edge,as A is "seen" as old value,which may not be 1. So,how do I make
B also transit before the next edge ?
One way could be to sample A after some time,say after 1/10 th of period
or something like that. But that is arbitrary? A and B are output signals.
Would using variables in the process and converting back later help to
avoid the delta delay? Or adding a wait for 0ns statement ? Wouldnt
synthesis of this code lead to a potential race condition ?
Thanks a lot.Please let me know if more details are needed.
Bye.

 

[Ken Smith]

Hi All,
I have a basic doubt. When a signal transitions on a clock edge, and I
want to use the final value of this signal for computation on the same
clock edge (and drive some other signal on the same edge) HOW do I do it ?
Simulation takes the previous value of the signal as the transition is
scheduled ater the simulation delta. I also fear a race condition like
situation.
This is my code :

Ap : process(Clk)
begin
if (posedge(Clk))
A<='1';
end if;
end process Ap;
Bp : process(Clk)
begin
if (posedge(Clk) and A='1')
B<='1';
end if;
end process Bp;
[...]
avoid the delta delay? Or adding a wait for 0ns statement ? Wouldnt
synthesis of this code lead to a potential race condition ?

I'll take on only what happens in a real part.

Inside a real part, the "A" and "B" signals will only take on their new
values some short time after the edge of "Clk". In most parts the new
value is actually based on the value on the input to the flip-flop just
before the edge. This means that "B" will become "1" one clock cycle
after "A" does in almost all cases.

In real parts there can be a problem with clock skew where one part of the
chip see the edge before another. Chip designers go to great lengths to
reduce clock skew but you should not ignore the question when working with
large parts.

 

[rickman]

Hi All,
I have a basic doubt. When a signal transitions on a clock edge, and I
want to use the final value of this signal for computation on the same
clock edge (and drive some other signal on the same edge) HOW do I do it ?
Simulation takes the previous value of the signal as the transition is
scheduled ater the simulation delta. I also fear a race condition like
situation.
This is my code :

Ap : process(Clk)
begin
if (posedge(Clk))
A<='1';
end if;
end process Ap;
Bp : process(Clk)
begin
if (posedge(Clk) and A='1')
B<='1';
end if;
end process Bp;

A is global signal, so access by Bp is not a issue.When Ap and Bp get
executed simultaneously, on the +ve edge, an event is scheduled on A after
Simulation delta.This would mean the B signal would be asserted only on
next edge,as A is "seen" as old value,which may not be 1. So,how do I make
B also transit before the next edge ?
One way could be to sample A after some time,say after 1/10 th of period
or something like that. But that is arbitrary? A and B are output signals.
Would using variables in the process and converting back later help to
avoid the delta delay? Or adding a wait for 0ns statement ? Wouldnt
synthesis of this code lead to a potential race condition ?

I am a little fuzzy on things sometimes, but I am pretty sure that this
is not a problem due to a thing called delta time. The clock edge
transition triggers each of the two processes in an arbitrary order.
But the output transitions (A and B) are queued to occur not immediately
in the simulator, but after 1 delta time (which is not mapped to real
time but occurs in zero real ns). So the Bp process will read the same
value of A (the older one) regardless whether it runs before or after
process Ap.

Once all the events scheduled for zero delta time are run, then the
processes that were scheduled for 1 delta time are run and so on until
no more delta time events are queued and the simulator then looks at the
next real time event.

BTW, A does not need to be a global signal to be visible by process Bp
(I'm not sure there *are* global signals vs. global variables). They
just need to be in the same entity or you can pass A around in a port
declaration.

--

Rick "rickman" Collins

(e-mail address removed)
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

 

[VHDL User]

I am a little fuzzy on things sometimes, but I am pretty sure that this
is not a problem due to a thing called delta time. The clock edge
transition triggers each of the two processes in an arbitrary order.
But the output transitions (A and B) are queued to occur not immediately
in the simulator, but after 1 delta time (which is not mapped to real
time but occurs in zero real ns). So the Bp process will read the same
value of A (the older one) regardless whether it runs before or after
process Ap.

Once all the events scheduled for zero delta time are run, then the
processes that were scheduled for 1 delta time are run and so on until
no more delta time events are queued and the simulator then looks at the
next real time event.

Precisely. I have mentioned in my post that due to simulation
delta cycle,A will be updated only 1 delta delay later,and hence B will
always read the old value of A.My problem is how to change B based on new
value of A before next positive edge.
My fear of a race condition was only for the hardware.In
simulation, delta delays ensure that no race conditions arise,but (as you
yourself pointed out ) in real time, the two signals get updated in "zero"
time.
My problem still remains.How do I update B once A has been
updated, before the next positive edge.

BTW, A does not need to be a global signal to be visible by process Bp
(I'm not sure there *are* global signals vs. global variables). They
just need to be in the same entity or you can pass A around in a port
declaration.

Sure.I agree completely.By "global" I meant signal in same
entity. Sorry for the needless confusion.

 

[Paul Uiterlinden]

[snip]
My problem still remains.How do I update B once A has been updated,
before the next positive edge.

Solution: put the stuff in one process, make A a variable.

Think in hardware. What you wrote down originally are two flip-flops (Ap
and Bp). You want to clock in the updated value of Ap into Bp. That does
not make sense. If it does, Ap should not have been a flip-flop in the
first place.

Paul.

 

[Brian Drummond]

Precisely. I have mentioned in my post that due to simulation
delta cycle,A will be updated only 1 delta delay later,and hence B will
always read the old value of A.My problem is how to change B based on new
value of A before next positive edge.

If you want this to work in real hardware, I think the only way is to
combine both A and B into the same process, so they react to the same
event. (And then use a variable A_int inside the process for A, so that
B sees the new value of that internal variable, not the "old" value of
A. Assign A_int to A somewhere in the process)

If you are simply doing simulation, you can add "clock skew" to B by
clocking B off a separate clock signal, ClkB, and assigning ClkB <= Clk;
This introduces a race condition and causes much head-scratching later.
(I found this inside a memory simulation model recently. I changed a
signal type, deleting an old assignment for type conversion purposes.
So, having advanced my data by 1 delta cycle, the simulation results
changed by an entire clock cycle!)

- Brian

 

[rickman]

Precisely. I have mentioned in my post that due to simulation
delta cycle,A will be updated only 1 delta delay later,and hence B will
always read the old value of A.My problem is how to change B based on new
value of A before next positive edge.

You can't since the Bp FF is edge triggered and won't sample the other
inputs until the next clock edge. If you want B to be updated anytime A
changes, you should remove the clock reference.

My fear of a race condition was only for the hardware.In
simulation, delta delays ensure that no race conditions arise,but (as you
yourself pointed out ) in real time, the two signals get updated in "zero"
time.

There will be no race condition in the hardware. Hardware always has
delays. The only problem would be if the clock routing delay is more
than the signal delay. In FPGAs the manufacturer assures this will not
happen. In ASICs it is up to you.

My problem still remains.How do I update B once A has been
updated, before the next positive edge.

Now I don't understand what you are trying to do. Your code describes
two FFs, one a simple clocked FF which starts in some unknown state and
transitions to a '1' on the first clock edge remaining there forever.
The second FF does nothing until the Ap FF becomes a '1' and then does
the same on the next clock edge (not the same one).

What are you trying to do?


--

Rick "rickman" Collins

(e-mail address removed)
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

 

[Element Blue]

You can't since the Bp FF is edge triggered and won't sample the other
inputs until the next clock edge. If you want B to be updated anytime A
changes, you should remove the clock reference.



There will be no race condition in the hardware. Hardware always has
delays. The only problem would be if the clock routing delay is more
than the signal delay. In FPGAs the manufacturer assures this will not
happen. In ASICs it is up to you.



Now I don't understand what you are trying to do. Your code describes
two FFs, one a simple clocked FF which starts in some unknown state and
transitions to a '1' on the first clock edge remaining there forever.
The second FF does nothing until the Ap FF becomes a '1' and then does
the same on the next clock edge (not the same one).

What are you trying to do?

Ok.What I had presented was "representative" code of my actual
code, only to highlight the problem. Certainy the FFs dont stay there
forever. My only concern was the clock edge where both signals are
supposed to change. What I am trying to do is to ensure B changes before
the next clock edge.

 

[rickman]

Ok.What I had presented was "representative" code of my actual
code, only to highlight the problem. Certainy the FFs dont stay there
forever. My only concern was the clock edge where both signals are
supposed to change. What I am trying to do is to ensure B changes before
the next clock edge.

Then Bp should not be a clocked process. By definition a clocked
process only changes on the clock edge.

My question is not about your sample code, but I don't understand what
you are trying to do with these two signals. If you want B to change
immediately on A changing, why do you put it in a clocked process? I
think I am missing something.

--

Rick "rickman" Collins

(e-mail address removed)
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

 

[Ken Smith]

Ok.What I had presented was "representative" code of my actual
code, only to highlight the problem. Certainy the FFs dont stay there
forever. My only concern was the clock edge where both signals are
supposed to change. What I am trying to do is to ensure B changes before
the next clock edge.

Can't you code "B" as combinatorial logic?

 

[Element Blue]

My question is not about your sample code, but I don't understand what
you are trying to do with these two signals. If you want B to change
immediately on A changing, why do you put it in a clocked process? I
think I am missing something.

Ok.I ll explain the context. There is a memory block which asserts
signal A (Ready) on a clock edge. The reader block must assert the B
(Upload) signal before the next clock edge,as that is when data appears on
the data bus if Upload is high.Otherwise I incur a clock cycle delay.
The read takes 2 cycles (2 words) and as soon as second word is read,
Upload is to be deasserted irresepective of whether memory is ready for
the next read or not ( irresp. of A),ie.,only 2 word accesses at a time.
As you and Ken have pointed out, making Bp a non clocked process
definitely helped. Thanks.

 

[rickman]

Ok.I ll explain the context. There is a memory block which asserts
signal A (Ready) on a clock edge. The reader block must assert the B
(Upload) signal before the next clock edge,as that is when data appears on
the data bus if Upload is high.Otherwise I incur a clock cycle delay.
The read takes 2 cycles (2 words) and as soon as second word is read,
Upload is to be deasserted irresepective of whether memory is ready for
the next read or not ( irresp. of A),ie.,only 2 word accesses at a time.
As you and Ken have pointed out, making Bp a non clocked process
definitely helped. Thanks.

This is an example where thinking not in the HDL, but in terms of
hardware would have made your solution very obvious. What you are
describing is a clocked signal, A, from the memory that must be gated
(anded) with an enable, another clocked signal. You were trying to
include the AND in the clocked signal while it should be a combinatorial
function that combines the two clocked signals.

I always think in terms of block level (sort of like RTL diagrams) logic
and then write HDL to describe my digital blocks. I have seen some
really bad code when people try to write HDL like it was software.

--

Rick "rickman" Collins

(e-mail address removed)
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

 

[Paulo Valentim]

If you want this to work in real hardware, I think the only way is to
combine both A and B into the same process, so they react to the same
event. (And then use a variable A_int inside the process for A, so that
B sees the new value of that internal variable, not the "old" value of
A. Assign A_int to A somewhere in the process)

While I agree this is probably the best tactic I propose another
alternative method which although not the best way, it is another way
of looking at it. The way is to clock the process which calculates B
on a negative edge. Therefore A process would be on the positive edge.
Then on the negative edge B gets calculated which would fulfill your
"B getting updated before the next positive clock edge".

The problem with this idea is timing. You better have a small critical
path from A to B. It has to have a delay of at most half the clock
period. Also I'm not sure if you can constrain this later with the
synthesis tool so it knows this half period constraint.

- Paulo Valentim

 

[Mike Treseler]

This is an example where thinking not in the HDL, but in terms of
hardware would have made your solution very obvious. What you are
describing is a clocked signal, A, from the memory that must be gated
(anded) with an enable, another clocked signal. You were trying to
include the AND in the clocked signal while it should be a combinatorial
function that combines the two clocked signals.

I always think in terms of block level (sort of like RTL diagrams) logic
and then write HDL to describe my digital blocks. I have seen some
really bad code when people try to write HDL like it was software.

Yes, sometimes it is better to start with schematic entry.
On the other hand, I have seen some really good code
where the designer understands hardware and the
HDL and the synchronous templates and data structures
and algorithmic design.

-- Mike Treseler

 

[Element Blue]

This is an example where thinking not in the HDL, but in terms of
hardware would have made your solution very obvious. What you are
describing is a clocked signal, A, from the memory that must be gated
(anded) with an enable, another clocked signal. You were trying to
include the AND in the clocked signal while it should be a combinatorial
function that combines the two clocked signals.

Yeah.Things are a lot clearer now that you have put it like this.
I never really did think of it this way. Infact this has simplified
similar logic elsewhere in my system. I am still learning HDLs and this
is an important lesson to me..thanks.

 

[ALuPin]

Try to split the signals in an combinational part and one
"registered" part.


signal A, next_A : std_logic;
signal B, next_B : std_logic;

process(Clk)
begin
if rising_edge(Clk) then
A <= next_A;
end if;
end process;

process(Clk)
begin
if rising_edge(Clk) then
B <= next_B;
end if;
end process;

-- combinational process
process(other_condition, A)
begin
next_A <= A;
-- next_A <= '0';

if other_condition='1' then
next_A <= '1';
end if;
end process;

-- combinational process
process(next_A, B)
begin
next_B <= B;
-- next_B <= '0';

if next_A='1' then
next_B <= '1';
end if;
end process;