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

Translate This Thread From English to

Threaded View
I'm working with Spartan3 and ISE 7.1, simulating a small VHDL test
program I noted that signal updates within a process are done on clock
rising edges, while cuncurrent assignments, out of the process, are
done along falling edges.
Is it all correct?

Re: timings

Quoted text here. Click to load it

For a functional sim all should change on the rising_edge.
Maybe some of your processes are using falling_edge.

         -- Mike Treseler

Re: timings
Mixing rising and falling-edge triggering is sometimes used to avoid
hold-time problems when there is significant clock skew. Obviously, it
reduces the max operating clock rate by more than half.
A more conventional (and better and faster) approach uses low-skew
global clock distribution, and then clocks all flip-flops on the rising
Peter Alfke, Xilinx
Marco wrote:
Quoted text here. Click to load it

Re: timings
I have no processes working on the falling_edge, just one and working
on the rising_edge. I have found that on the simulation of the
behavioural model concurrent assignaments done outside the process are
done on falling_edges, while during the post-palece-and-route
simulation those updates appear on the rising_edge as I expect, any
I can also the small delay of each line of a vector being updated
inside the process: if my vector value moves from 0 to 240, I see it
changing in the sequence 0 -> 16 -> 48 -> 176 -> 240 (start to end
within 0.2ns). I made some experiment changing the placement of the
otput pads of those vector bits (putting one for each bank instead of
all in one bank) and I found the total time required to change from 0
to 240 to become 0.2ns, with a new sequence 0 -> 64 -> 80 -> 112 ->
As this is my first approach to real vhdl programming I'd like to hear
from you if what I see is correct or, at least, comprehensible.

Re: timings
Marco, my advice is to design synchronously, use only the rising edges
of a common clock, and do not worry about picosecond delays. (you
mentioned 4 actions within 0.2 ns, hard to believe...)
Peter Alfke
Marco wrote:
Quoted text here. Click to load it

Site Timeline