Serial data from shift register to FIFO

--- Quote Start ---

It will be clock recovered from NRZI data - bit stream with no clock in one cable. The receiving module will recover the clock from the data - this 125 Mhz clock (different form the 125 Mhz from PLL and used in read part of fifo), and use this clock to put the data itself to shift register and to generate those wrreq pulses.

--- Quote End ---

Well, you haven't quite described how you are going to 'recover' this 125MHz clock yet, so lets leave this discussion for now.

--- Quote Start ---

Next questions:

1) I haven't done quite good yet conditions for generating those fifo wrreq pulses, - when i try to do smth with that, sometimes i get:

the cursor is the actual sync detect, and i get those strange spikes - i tried to use the cursor to check if there's one near them or one them - but there are zero value in the spike.

--- Quote End ---

The spikes are fine, so long as they exist on signals that will route to registers. The register will only 'see' the signal at a clock edge. The spikes occur due to combinatorial operations on signals with different delays.

--- Quote Start ---

2) when i compile a design i automatically get this in modelsim (included testbench in quartus options)

Does vho suggests that in gate_level simulations i have actual delays from the device ?

--- Quote End ---

The .vho file is output by Modelsim along with an .sdo file that contains timing. You can simulate the .vho without timing, with maximum timing, minimum timing, and typical timing.

I don't know what Quartus defaults to using. Read the documentation, or simply use Modelsim directly.

Cheers,

Dave

--- Quote Start ---

The spikes are fine, so long as they exist on signals that will route to registers. The register will only 'see' the signal at a clock edge. The spikes occur due to combinatorial operations on signals with different delays.

--- Quote End ---

by routing to registers do you mean that it can be only routed to the infomational d input of register? it can't be used as a clock signal to latch the data into a register, beacuse the register will recognize it as a clock edge and wrong data would be latched?

--- Quote Start ---

I don't know what Quartus defaults to using. Read the documentation, or simply use Modelsim directly.

--- Quote End ---

I use ModelSim-Altera. When i compile a design - modelsim starts up.

By using Modelsim do you suggest that i should make a Modelsim project and setup there the simulation and run it from there after compilation in quartus ?

I'll try to find those maximum timing, minimum timing, and typical timing options later in the documentation.

cheers :)

It apears that madness has NativeLink enabled and his project set to launch a gate level simulation whenever it finishes compiling.

madness123,

you can launch simulations (RTL or gate-level) using the

Tools -> Run EDA Simulation tool menu.

Yes, only to the D inputs.

Or more generally, it's generally OK to have glitches in signals which will only be captured synchronously. Not OK for clocks or asynchronous signals.

--- Quote Start ---

by routing to registers do you mean that it can be only routed to the infomational d input of register? it can't be used as a clock signal to latch the data into a register, beacuse the register will recognize it as a clock edge and wrong data would be latched?

--- Quote End ---

Yep, you've got it.

--- Quote Start ---

I use ModelSim-Altera. When i compile a design - modelsim starts up.

By using Modelsim do you suggest that i should make a Modelsim project and setup there the simulation and run it from there after compilation in quartus ?

--- Quote End ---

I also use Modelsim-ASE (and Modelsim-SE). I start the tools from the Start Menu directly, rather than use NativeLink. I then source a script, eg., see the sim.tcl script I pointed to in the example design.

--- Quote Start ---

I'll try to find those maximum timing, minimum timing, and typical timing options later in the documentation.

--- Quote End ---

In Modelsim, look at the vsim help (type 'vsim -help'), the timings can be applied to your design using the .sdo file and the argument -sdftyp -sdfmin or -sdfmax. However, I rarely use these. If the RTL simulation is fine, and the gate-level without timing is fine, and TimeQuest indicates timing has passed, I move on to hardware testing. The delays make simulation of big designs take forever.

Cheers,

Dave

Hi Dave,

your example is really good - gives the idea, i have made my own script - when i didn't knew smth i just looked at the *.do files generate by quartus or directly in tcl of model sim (when doing smth it returns the tcl command).

I'm still fighting with the project. Got some more questions:)

I took from a colleague his NRZI receiver working on clock 375 MHz, and started timing simulation with -sdfmax for slow 1200mv 85c model: heres the result:

https://sites.google.com/site/pauldab/home/sim.jpg

When using this model with sdo file - i can now see that the edges of different signal are not perfectly aligned.

There are lots of combinatorial spikes when the design tries to synchronize to the beginning of the frame (those spikes are on the wrreq generated every 5th bit).

In spite of them, i put in the receiver couple of predefined frames, and get a correct 32 bit data when reading from fifo on every position.

However i get those yellow warnings at the top:

--- Quote Start ---

# ** Warning: */DFFEAS HOLD Low VIOLATION ON DATAIN WITH RESPECT TO CLK;# Expected := 0.186 ns; Observed := 0.1 ns; At : 14942.564 ns# Time: 14942564 ps Iteration: 1 Instance: /madi_tb/uut/\nrzi_in_fifo_module|dcfifo_mixed_widths_component|auto_generated|rs_dgwp|dffpipe11|dffe12a[3]

--- Quote End ---

And a warning after compilation in quartus :

--- Quote Start ---

Warning (332060): Node: NRZI_receiver:nrzi_receiver_module|synchro_delay was determined to be a clock but was found without an associated clock assignment.

--- Quote End ---

Here's also a quartus compilation report from timequest corresponding to nodes in NRZI Receiver module:

https://sites.google.com/site/pauldab/home/timequest.jpg

How to add correct constraints for such report?

-0.061 - it's a small number - is that acceptable if the design works in simulation?

And what about those Slow 1200mV 85c 0c and Fast 0c models.

I assume that Slow 1200mV used by me with sdfmax is the worst scenario that i could not possibly meet in real device?

Should i be worried only when such timing problems occur in those two other models?

----------------------------

And now a silly question for an FSM - cause i will need that. I know that there are two approaches - only one state in FSM (no next_state : state) - combined cominatorial and synchronous logic.

And the second one that they are separated (two states -> current, next).

I just want to synchronously count my channles read from fifo - and on the number that was read do some action.

I have used this combined approach - it worked but i wanted to try for educational puproses the second one approach. I put here only the synchonous part:

PROCESS(fsm_clock, reset_pll_in)
BEGIN
    IF (reset='0') THEN
            current_state <= IDLE;
    ELSIF rising_edge(fsm_clock) THEN
            current_state <= next_state;
        IF counter_flag = '1' THEN
            channel_counter <= channel_counter + 1;
        END IF;
    END IF;
END PROCESS;    

And as i suppose i can't in the lower combinatorial part use channel_counter <= channel_counter + 1 cause when in this state the desing would add this 1 many many times.

I figured out that i could use a flag in a combinatorial state when i want to add 1 to the counter, and then the upper synchronous part would detect this flag and add counter. It works, but i'm wondering if it could be done more elegant? Or to know your opinion about those two types of approches to FSM.

best regards

thanks again Dave:)

--- Quote Start ---

your example is really good - gives the idea, i have made my own script - when i didn't knew smth i just looked at the *.do files generate by quartus or directly in tcl of model sim (when doing smth it returns the tcl command).

--- Quote End ---

Yes, that's exactly how you learn to use the Tcl features of the tools.

--- Quote Start ---

Warning (332060): Node: NRZI_receiver:nrzi_receiver_module|synchro_delay was determined to be a clock but was found without an associated clock assignment.

--- Quote End ---

This warning is important. It means exactly what it says. You have used a signal in a clock-like fashion, i.e., you've used it as the clock port on a registered process. There's two possible constraints for this case; either

1) Its a clock derived from another clock, eg., a clock divided-by-2.

2) Its a new clock completely asychronous from other clocks, eg., a handshake signal used to cross logic domains.

You need to tell TimeQuest which of these two options it is, and then TimeQuest can correctly analyze the timing. Until then, the numbers that TimeQuest produces cannot be analyzed.

The worst-case needs to be determined from all process models, eg., the fast model might have the best setup time and the worst hold time, whereas the slow process model might have the worst setup time, and best hold time. You need to look at them all.

--- Quote Start ---

And now a silly question for an FSM - cause i will need that. I know that there are two approaches - only one state in FSM (no next_state : state) - combined cominatorial and synchronous logic.

And the second one that they are separated (two states -> current, next).

--- Quote End ---

The style I prefer is to separate the logic into a finite state machine and data path logic (called the FSM-D style), where the data path logic is stuff like counters and shift registers. The FSM is then design as;

1) Create the FSM as a mixed Mealy/Moore. In a Mealy machine the outputs are dependent on state and inputs, whereas a Moore depends only on state.

2) Register the Mealy outputs that need it, eg., outputs that will go to the top-level design. Not all Mealy outputs need to be registered, eg., signals that go to the data path logic, like the load and enable controls on a counter.

The FSM can be documented using an algorithmic state machine (ASM) style, which is a flow chart that directly transcribes into VHDL or Verilog. Drawing the ASM chart has the added advantage that if the ASM chart looks too complicated, then likely your FSM can be improved.

Here's a document with a shift register design and an ASM chart. Look at the design starting on page 45:

http://www.ovro.caltech.edu/~dwh/carma_board/ad9956_tests.pdf (http://www.ovro.caltech.edu/%7edwh/carma_board/ad9956_tests.pdf)

I've attached the code from my CVS repository. It does not contain all the components needed to compile it. I'm just including it so that you can see the correspondence between the VHDL and the ASM chart.

There's other examples of ASM charts in documents here:

http://www.ovro.caltech.edu/~dwh/carma_board/ (http://www.ovro.caltech.edu/%7edwh/carma_board/)

Cheers,

Dave

Hi Dave !

thanks once again for your patience and help ! i'm really appreciated.

I have been trying to constrain those clocks - but with no positive result for setup time and slack. Tried to create clocks in my sdc file for clock_receive and synchro_delay, because they are getting this warnings:

--- Quote Start ---

Warning (332060): Node: NRZI_receiver:nrzi_receiver_module|synchro_delay was determined to be a clock but was found without an associated clock assignment.

Warning (332060): Node: NRZI_receiver:nrzi_receiver_module|clock_receive was determined to be a clock but was found without an associated clock assignment.

--- Quote End ---

But with no result. I was even trying to connect my nrzi stream input pin to the LCELL buffer (because i read somewhere here on this forum, that it makes the signal global ?)

1) Does the LCELL make the signal global ? or the GLOBAL primitive is for that ? I was trying to find how to make signals global in some other way, or to at least change input pins to global. I know that it's somewhere in the options - but wasn't able for now. As farest i know Quartus automatically assigns global signals.

2) I took a second approach and changed in "Physical Synthesis Optimiations" Effort Level to Extra and in "Fitter Settings" option Optimize multi-corner timing.

This haven't changed anything.

3) Here's my NRZI_Receiver module - perhaps with this you would be able to help me with constraining the design, or tell if there are some mistakes. This module is written in AHDL - the rest of my design is in VHDL:

SUBDESIGN NRZI_receiver
(
    clock_in     : INPUT;  -- 375 MHz
    nrzi_data_in          : INPUT;
    data_receive : OUTPUT;
    clock_receive: OUTPUT;
)
VARIABLE
    temp1 : DFF;
    temp2 : DFF;
    synchro : DFF; 
    -------------------
    synchro_delay : DFF;
    -------------------
    temp3 : DFF;
    clock_receive : DFF;
    data_receive : DFF;
BEGIN
    temp1.clk = clock_in;
    temp1 = nrzi_data_in;
    temp2 = temp1;
    temp2.clk = clock_in;
    synchro = (synchro + 1) & !(temp1 xor temp2) & (synchro!=2);
    synchro.clk = !clock_in;  
    
    synchro_delay = !synchro0 & !synchro1; 
    synchro_delay.clk = clock_in; 
    temp3.clk = synchro_delay;  
    temp3 = nrzi_data_in;  
    clock_receive = !synchro0 & !synchro1; 
    clock_receive.clk = !clock_in;
    data_receive = (temp3 xor nrzi_data_in);
    data_receive.clk = clock_in;
END;

As farest i understand the design:

  temp1.clk = clock_in;
    temp1 = nrzi_data_in;
    temp2 = temp1;
    temp2.clk = clock_in;
   and this condition : !(temp1 xor temp2)

Temp1 and Temp2 are used to detect the edges of the nrzi_data_in stream.

When temp1 and temp2 have different values (01 or 10) the xor condition itself gives a true statement, using negation ! on this - resets the 2 bit synchro counter (so edge detecton - when edge detected the counter starts to count again)

(synchro!=2)

This condition is used for counting from 0 to 2 ( 0,1,2,0,1,2,0,1,2,0,1,2....)

synchro_delay = !synchro0 & !synchro1; 
    synchro_delay.clk = clock_in; 
clock_receive = !synchro0 & !synchro1; 
    clock_receive.clk = !clock_in;

These two are our clocks that timing analysis have problem with. I think that

!synchro0 & !synchro1; is used to detect the 0 value of counter (00 , gives 1 using this statement)

Clock receive generates the 125 MHz clock for the receving part of my design - metioned earlier shift_register, and wrreq for fifo en etc.

    data_receive = (temp3 xor nrzi_data_in);
    data_receive.clk = clock_in;

This part i suppose is smth with getting "real bits" from nrzi stream. But really don't know. The design of receiver is rather simple - i wrote what i think about it, but don't really understand for right now why use once a rising edge and falling edge. (need to think about it more :) )

Some reports:

https://sites.google.com/site/pauldab/home/controlsignals.jpg

4) As you can see my clock_receive and synchro_delay are clock signals accroding to quartus. I think that due to fan-out quartus gave the clock_receive global routing.

Would giving the same routing to synchro_delay help ? If yes how to do it ?

5) Isn't that strange that my main clock PIN_clock_in 125 Mhz from crystal is routed global and not global ? perhaps i have done smth bad in the other part of design or is this normal ?

And lastly

https://sites.google.com/site/pauldab/home/worstcase.jpg

Thanks in advance for any help Dave :)

best regards

madness

I will add one more question :)

I tried to use similiar receiver running 500 MHz clock - the higher clock gives better resolution and the clock and data are perhaps more accurate ?

But when running in simulation i got some strange red yellow errors in the top and nothing in design.

Does the simulator have a max limit that it can work in gate_level simulation with timing for the device ? because the max of cyclone III is about 470 Mhz.

Or am i just messing smth and it should work ?

Still wasn't able to correcty constain these clocks without getting negative slack on 375 Mhz clock from PLL in all slow 85c slow 0c and fast timing models.

I deleted one delay in the nrzi receiver design:

--    synchro_delay = !synchro0 & !synchro1; 
--    synchro_delay.clk = clock_in; 
    temp3.clk = !synchro0 & !synchro1;--synchro_delay;  
    temp3 = nrzi_data_in;  

There are no negative slacks in the design from now.

The simulation gives good result when reading from FIFO.

But I still get (much more less) hold timing violations in simulation (although timing analzyer gives no warning).

Can i assume that i will receive correct data on the device even with those hold violations in my simulation? Will do that maybe next week :)

Hi madness,

Sorry, I haven't had a chance to look at the previous posts in detail. As a general comment, you really want to make sure TimeQuest does not generate any warnings or errors. However, if you have incorrectly constrained the design, then you might get warnings or errors that are meaningless.

I'd recommend trying your new design in hardware, and using SignalTap II to capture data traces. Look at those data traces with respect to the simulation, and see if they match. Measure your error rates. Are you capturing data correctly?

Setting up the appropriate synchronization logic and TimeQuest constraints is often an iterative process.

Cheers,

Dave