I have some hard to debug issues in my FPGA image processing project: when I read the memory from the Virtex 4 chip at 15KHz rate (rather low). There are some undefined delays that are semi random: sequential reading of the memory has delays after every 32 accesses. I suspect that "after 10ns" constraint is not accurate enough. I use that constraint to make sure that the read memory clock is delayed from the process' clock that generates the read address.
The only "after 10ns" style constraint I use is for "OFFSET IN AFTER 10 ns" which I don't actually use or "OFFSET OUT AFTER 10 ns" which I do. These are timing constarints to verify that your input setup times are within your needs or the clock-to-out times are acceptable.
If you're trying to delay an output clock by 10 ns, your approach is incorrect.
The output might be delayed through phase shifting of the Digital Clock Manager (DCM) but you have to pay attention to clock domain crossings. If you have a faster clock - such as a 100 MHz clock - you can delay an output by another 10 ns by just adding one more clock of delay into your generated signal.
So - since "after 10ns" isn't an actual constraint - what are you trying to do?
Assuming that is in you HDL code, it is part of the many things that are good for simulation but do not synthesize. It might be beneficial to read up on what constructs of your preferred HDL can actually be synthesized.
|> > The "after 20ns" is ignored for synthesis. |> >
|> > -- Mike Treseler |> |> |> Why is it ignored? It seems that it works fine in the other design.
Just by accident... How would you do the 20ns in HW? Remember that gate delay is only specified as a maximum value. Everything below depends on voltage, temperature, chip binning and tide level, ie. you can't count on it.
The only way to get a reliable delay is running with a fast clock (>5-10times your delay) and doing clocked delay stages. But you have to live with the jitter if your signal is asynchronous to the clock.
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Now this explains why I had some designs work perfectly only in simulations but not on chip. I was just lucky that it worked in the other case. I am adding some more code so I can use 4 times faster clock and split it by 2 twice so I can get needed clock and 4 possible stages that will be used instead of "after 10ns" and "after 20ns".
Oftentimes you can get some degree of relative control by proper placement of LUTs/FFs (or appropriate term for your technology.) But this would only give you relative control, which would vary over temp/voltage/process. Generally, the best solution is to use the appropriate clock period, and put the critical items in FFs. Then control the location of the FFs to suppress routing variability.
Typically (but not very often), I will use such a behavioral construct to force the simulation tool to reflect 'reality' where a signal is guaranteed to be delayed (some tiny bit) from another. Unless doing timing simulation, the value is just a token delay to prevent ambiguity with event order.
In your particlar case, muxing the two signals prior to a FF is probably the ideal solution, since clock_rd is gated. There are additional issues to be concerned with, though: getting onto the clock tree. If there are just a few loads in a Xilinx part, and they are all arranged properly, you could get away with local clocking (no global buffer.) But you still may need to be concerned about interaction with other clock domains.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.