Serial data from shift register to FIFO

Hi,

yea no problem :) As i said i deleted one delay path - there are no negative slack in the design now. However timing analzyer still complains about those unconstrained clocks - i'll just leave it like that.

I'm afraid that my hardware doesn't have a JTAG - the uC on the board programs the fpga.

Is it better to always have a JTAG and use signal tap ? i suppose that it's very accurate ? is signal tap better than very high speed logic analzyer (let's say 200 Mhz) ?

I'm capturing data correctly in the simulation. I made a vector file with known bits - and i know what i'm exactly reading from FIFO - and that works for the simulation. even for this 85c slow mode and -sdfmax (although it complaints a lot about hold violations)

you really helped me a lot with understanding some stuff - still lots of job to do, i have been learning fpga topic for about a month - and don't get all the concepts quite well yet :)

Cheers :)

madness

madness123,

wow... lot's issues there, but let's go by order.

1) the LCELL primitive does not make a signal global. That's what the GLOBAL primitive is for. But in general, Quartus knows to do that automatically when appropriate.

(there's a tricky case that calls for LCELL, involving clocks from regular I/O pins, but let's not diverse here).

3,4) This is something you need to correct before you proceed any further.

The output of "synchro_delay" is used as clock in "temp3". That is why Quartus thinks it's a clock -- because it is!

This calls for a create_generated_clock constraint. Since it's a FF output, a -divide_by 2 applies at the very least -- that signal will never switch faster than half the clock_in frequency.

The same goes for "clock_receive".

BTW, do you have a derive_pll_clocks command in your SDC?

5) Don't worry about that.

--- Quote Start ---

I'm afraid that my hardware doesn't have a JTAG - the uC on the board programs the fpga.

Is it better to always have a JTAG and use signal tap ? i suppose that it's very accurate ? is signal tap better than very high speed logic analzyer (let's say 200 Mhz) ?

--- Quote End ---

You should always include some way of accessing JTAG pin on a board design. The standard 10-pin header is kind of large, so its not always easy to have it available, but there are smaller connectors that can be used.

--- Quote Start ---

I'm capturing data correctly in the simulation. I made a vector file with known bits - and i know what i'm exactly reading from FIFO - and that works for the simulation. even for this 85c slow mode and -sdfmax (although it complaints a lot about hold violations)

--- Quote End ---

Simulations only reflect reality to the extent that you provide a realistic set of stimulus. For example, your data sender and receiver probably have the same clock frequency in simulation, but in real hardware, two clocks with the same frequency are not really the same frequency (unless you have them locked to a common frequency reference).

--- Quote Start ---

you really helped me a lot with understanding some stuff - still lots of job to do, i have been learning fpga topic for about a month - and don't get all the concepts quite well yet :)

--- Quote End ---

FPGA tools have a steep learning curve, especially if you try to understand them without a little guidance.

Cheers,

Dave

A generic recommendation.

If you have a signal X driving flip-flop R's clock pin, then there may be two correct options:

- X is a clock or something alike. You apply a clock constraint (create_clock or create_generated_clock) to that signal

- X is asynchronous. You use asynchronous techniques on R's output and you set a false path exception from R's output.

If you're not doing either of those things, then you're doing something wrong and you're not constraining your design properly.

Hi,

rbugalho

--- Quote Start ---

1) the LCELL primitive does not make a signal global. That's what the GLOBAL primitive is for. But in general, Quartus knows to do that automatically when appropriate.

(there's a tricky case that calls for LCELL, involving clocks from regular I/O pins, but let's not diverse here).

--- Quote End ---

I have read it from your post on this forum :) when you suggested as farest i rember it with using clocks from regular I/O to the other user:).

--- Quote Start ---

BTW, do you have a derive_pll_clocks command in your SDC?

--- Quote End ---

I have that because i'm using a pll module in my device. I have a 125 MHz crystal which feeds the pll input - and after that i get 125 MHz and 375 Mhz clocks.

Here's my SDC for now:

--- Quote Start ---

create_clock -name recovered_clock -period 8 [get_registers {NRZI_receiver:nrzi_receiver_module|clock_receive}]

create_clock -name clock_in -period 8 [get_ports {PIN_clock_in}]

derive_clock_uncertainty

derive_pll_clocks

--- Quote End ---

125 MHz will be used for logic in the device.

And 375 is used for data and clock recovery from my NRZI bit stream input.

From the module i put earlier NRZI_receiver i get a 125 MHz clock - and that's clock_receive. And when i constrain it with that period - i get hold violation of slack -0.033.

Here's the SDC:

--- Quote Start ---

create_clock -name recovered_clock -period 8 [get_registers {NRZI_receiver:nrzi_receiver_module|clock_receive}]

create_clock -name clock_in -period 8 [get_ports {PIN_clock_in}]

derive_clock_uncertainty

derive_pll_clocks

--- Quote End ---

I have thought now about the thing i wrote. This clock receiver is 125 MHz - and it's generated from this counter:

--- Quote Start ---

synchro[] = (synchro[] + 1) & !(temp1 xor temp2) & (synchro[]!=2);

synchro[].clk = !clock_in; -- clock in equals to 375Mhz

--- Quote End ---

So i suppose that div by 3 or smth like that would maybe do the trick.

But for now i couldn't find my pll clk output in the collection when trying to add the constrain itself.

--- Quote Start ---

Simulations only reflect reality to the extent that you provide a realistic set of stimulus. For example, your data sender and receiver probably have the same clock frequency in simulation, but in real hardware, two clocks with the same frequency are not really the same frequency (unless you have them locked to a common frequency reference).

--- Quote End ---

Dave it's the idea to recover the data and clock from that data (received form single optic cable). I JUST HOPE that this would work :D

I know for a FACT that this NRZI_Receiver worked for a 125 Mbits stream - i now just want to use it in a different manner (it was orginally written to put this recovered data into the RAM - with some other AHDL logic to delay somehow the data and to latch it correctly into the ram - as farest i understood it - it had a generated clock from a counter as ram wrclk - so not a very good practice i suppose - that's what i learned from you :) )

And as i said, i'm now using this receiver - with exepction of a FIFO, and the method with getting the data into the fifo (only one clock and using wrreq every 5th bit as you suggested)

cheers : )

create_clock -name recovered_clock -period 8 
create_clock -name clock_in -period 8 
derive_clock_uncertainty
derive_pll_clocks

Line 1 is incorrect.

create_clock are used to constrain base clocks -- ie, clocks that you feed to the FPGA pins.

Clocks generated inside the FPGA are to be constrained using create_generated_clocks (or derive_pll_clocks for PLL clocks).

"clock_receive" is being generated by a register, running on some other clock.

So, you MUST constrain it using create_generated_clock, taking the 375 MHz PLL output clock as base and applying a -divide_by 3.

That said, avoid logic generated clocks as much as possible.

If possible, use the 125 MHz input clock or 125 MHz PLL output clock, instead of using the counter.

Hi,

rbughalo

i used :

--- Quote Start ---

create_generated_clock -name recovered_clock -source [get_pins {pll_generator|altpll_component|auto_generated|pll1|clk[2]}] -divide_by 3 [get_registers {NRZI_receiver:nrzi_receiver_module|clock_receive}]

--- Quote End ---

and that works. Still got that other clock warning earlier - when tried to use on synchro_delay also as a generated clock - i got negative slacks.

--- Quote Start ---

That said, avoid logic generated clocks as much as possible.

If possible, use the 125 MHz input clock or 125 MHz PLL output clock, instead of using the counter.

--- Quote End ---

I don't suppose i can - i don't know any other possibilty to correctly synchronize to incoming bit stream to latch the bits correctly.

1) Perhaps stupid question - if i really don't know what the clock frequency is in register like synchro_delay - will it be usefull to use a signal tap to determine that ?:)

2) When i used a 125 MHz clock from the pll to drive my state machine - which reads data from fifo and manipulates it - i got lots of problems - hold volations in simulation. When i used this clock in other parts of the design - the simulation got MAD - everything stoped working - all other small changes in the design - like adding new fsm state and doing smth in there got it all wrong (yellow hold volations - LOTS OF THEM, and clock was undefined for small time - red - than defined - really madness :D )

My all problems gone when i started using 125 MHz from input clock directly. Everything works fine - and now even in slow 85c sdfmax i don't get any hold violations.

I suppose i did smth wrong, but i'll stick with that 125 MHz from input, and only 375 MHz from PLL to recover the clock and data to FIFO.

cheers :)

madness

Were you getting hold violations or setup violations in TimeQuest?

If they're hold, try to set the fitter option to optimize hold timing.

(for the next project, replace use of logic generated clocks with clock enables)

1) No, you need to be able to figure out, from the working of your design, what's going on.

2) You got violations in the simulation, but not timing violations from TimeQuest?

By the way, I noticed in some earlier posts that you had timing violations in the simulation, in a dual-clock FIFO component.

If you're using a dual-clock FIFO with 2 or more synchronization stages, this is to be expected.

The DCFIFO core actually has two use modes

A) Only 1 Synchronization stage, when the read and write clock are related.

B) 2 or more synchrnonization stages, when the read and write clocks are not related. In this case, the DCFIFO will add false path exceptions at the clock crossing logic.

In the latter case, it's quite normal not to get timing violations in TimeQuest, but to get timing violations in simulation -- TimeQuest simply did not analyse the path.

In order to perform gate level simulation of such design, you need to disable the timing checks on the first stage of synchronization registers -- the ones that are complaining.

--- Quote Start ---

Were you getting hold violations or setup violations in TimeQuest?

If they're hold, try to set the fitter option to optimize hold timing.

--- Quote End ---

I was getting those hold violations in simulation when using 125 MHz clock from PLL. Everything was fine in TimeQuest. No problems with 125 Mhz from PIN.

Yes i'm using 2 stage synchronizer.

--- Quote Start ---

you need to disable the timing checks on the first stage of synchronization registers -- the ones that are complaining.

--- Quote End ---

How to do that ?