Validity of data on rising edge of clock

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
It seems to be annoying to have my data valid on the rising edge of a
clock internal to the FPGA.  If I have a process that has logic on the
rising edge of a clock that generates or processes some sort of data,
and another process that samples this data, to say put into a memory
buffer.  What are you guys doing in order to skew the clock out of
phase so it samples the data on the rising edge of this clock?  For
example if you have

process(clk)
begin
 if(clk'event and clk='1') then
    some_array(some_index) <= data;
 end if;
end process;

and ....

process(clk)
begin
 if(clk'event and clk='1') then
    data <= data+1;
 end if;
end process;

This will have a horrible outcome because the data is not valid on the
rising edge?  Right?  What is a nice way to get around this?  Besides
using things like clock managers?


Re: Validity of data on rising edge of clock

Quoted text here. Click to load it

It's valid for the entire clock cycle AFTER the leading edge...

Quoted text here. Click to load it

Using standard logic design techniques that have been in existence for
decades.  You're not grasping the fact that any flip flop changes state
only AFTER the rising edge of the clock....which is exactly what your
processes say as well.

Quoted text here. Click to load it
-- KJ: You won't get here until AFTER the rising edge of the clock.
Quoted text here. Click to load it
-- KJ: You won't get here until AFTER the rising edge of the clock.
Quoted text here. Click to load it
Sure it's valid, it won't start to change until AFTER the rising edge
but it get sampled on what is there right AT the rising edge...not
after, not before.  The only 'difference' between simulation and real
world flip flops is that a real world device will have a propogation
delay specified in nanoseconds whereas the simulation environment the
delay will be one simulation delta cycle.

Quoted text here. Click to load it
Wrong.


Design using standard synchronous design techniques.  In fact the two
processes you've shown will do exactly what you want them to do; there
will be a two clock cycle latency between when 'data' first switches
and when the memory gets updated, but that's exactly what you specified
that you wanted which is also the way that most people would go about
doing what you appear to want.  You wouldn't use any sort of 'clock
manager' or anything else to skew the clock either.

KJ


Re: Validity of data on rising edge of clock
Quoted text here. Click to load it

Synchronous data is valid for a long time before
the rising clock edge, but only for a short time
after the edge. I am always sampling the
"old" value, so what happens during the clock
to Q change does not really matter.

       -- Mike Treseler



Re: Validity of data on rising edge of clock
Quoted text here. Click to load it
Hi Lloyd,
You might want to read about hold time. If you look at the V4 timing
datasheet, DS302, you'll find the CLB FFs have a negative hold time.
HTH, Syms.



Site Timeline