Re: async clk input, clock glitches


"Antti" <Antti.Lukats@xxxxxxxxxxxxxx> wrote in message
news:0139131e-741b-438b-bfb4-580a19213014@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On 29 Mrz., 20:27, "KJ" <kkjenni...@xxxxxxxxxxxxx> wrote:

the 4Mhz clock is really not a clock, its byte write strobe from
external host

Let's be blunt, any signal that you use "rising_edge(xxx)",
"falling_edge(xxx)", "xxx'event and xxx = '1'", "xxx'event and xxx='0' and
all the other variants thereof are edge sensitive signals, whether it is a
free running 'clock' is irrelevant.


most of the FPGA logic can/should be clocked with this strobe,

So then why did you (from an earlier post) bring this strobe into a flip
flop that is clocked by the 50 MHz clock? You've created a new signal
internal to the device that you can't observe and will be violating
setup/hold timing by design which means that this signal will be metastable
at some times and you're using edges of it internally....it's highly
unlikely now that that internal signal is nice and monotonic...that's why
you're seeing the flaky operation.

If you intend to use the 4MHz clock/strobe/whatever to sample things inside
the FPGA, then don't muck with it, use it directly as you would use the 50
MHz osc clock and don't insert any logic/flops/anything in the path.

and i see little reasons to move all that logic into 50mhz clock domain

The reason is that the two clock domains almost inevitably will need to
communicate with one another. That communication will be cross clock
domains, it is 'usually' simpler to synchronize up front and then clock
everything with one clock. The simple answer to the 'reason to move...' is
to avoid the type of timing grief that you're experiencing. Then again,
experience something for yourself is almost always the best teacher.


ah, the 4 mhz strobe/clk is routed as global clock, I do insert the
global buffer primitives by hand and verify that the are implemented
by the tools as well.


Having to do gyrations with tools to get it to 'work', generally only
results in things that work on certain boards, or start failing at different
temperatures and other odd things. The reason is that the fundamental
design issue has not been addressed, band aids have only been added to
address symptoms seen on a limited set of boards.

Fundamentally, you need to decide
1. If you want to have things running around internally in the FPGA in two
different clock domains and use proper handshaking/dual clock fifo
techniques everyplace signals from the two come together.
2. Synchronize the 4MHz to the 50 MHz up front and then run everything in
the FPGA at 50 MHz and have only one clock domain.

Either approach is viable, #1 will take more effort on your part to get
working. Whether the payoff is worth it to you or not is a decision that
only you can make.

if any FF is clocked by local routing in Actel FPGA then it is
complete disaster

I think I said basically the same thing previously about having to fix many
other designer's designs by getting rid of internally generated clocks. By
the way, that type of design issue is not unique to Actel.

Kevin Jennings


.

Relevant Pages

  • Mixed clocked/combinatorial coding styles (another thread)
    ... I need to integrate a clock divider... ... Register reuse ... it is less critical for signals. ... Style depends a lot on the writer and his perception of the design. ...
    (comp.lang.vhdl)
  • Re: state machine reset
    ... - you see a change only in the next clock cycle ... There are reasons to compute other signals based on next_state. ... Typically this leads to higher clock cycle performance of the design ... I modify state in the state machine. ...
    (comp.lang.vhdl)
  • Re: IBM Clown "Easter Egg"
    ... external and delivered as a non overlaping two phase 12V signals. ... that design was either not oscillating at all or taking off at the 2nd ... or even third harmonic of the crystal mucking up timing. ... The 0026 is an amazing clock driver, ...
    (comp.os.cpm)
  • Re: regarding the post PnR timing simulation.....
    ... SRST signal changes its value to close in time to the active edge of clock ... It should be changed at least 0.748 ns before the active edge. ... - you are clocking the design with too high frequency. ... All signals are completely routed. ...
    (comp.arch.fpga)
  • Re: Now on 8.2.03i Re: Xilinx ISE ver 8.2.02i is optimizing away and removing "redundant" logic -
    ... "input setup/hold time" is the time required before a clock edge to ... Setup time is the time for the signal to be stable prior to ... live in isolation it is connected to outside devices that may have timing ... the calling module and in the signals used in the submodule. ...
    (comp.arch.fpga)