Serial data from shift register to FIFO

[Altera_Forum]

Hi, 

let's assume conditions:  Receive domain: Data clock : 125 MHz Data encoded with with 5b/4b method Data frame contains 32 * 64 bits (4bits before encoding - 40 * 64 bits in 5bit version) Frame frequency is 44 kHz  The begin of the frame is synchronized with following bits "11000"  So first i have to detect the beginning of the frame - i use for this 15 bit shift register. Serial data goes into the shift registers , and sync is asserted when the most significant 10 bits are 1100011000 and the least significant are different from 11000. Shift register is clocked with 125 MHz.  My object is to: After getting sync flag, i need to decode 5 lsb bits of shift register into 4 bits. And put them into the FIFO.   After decoding data from 5 bit to 4 bit i get 25 MHz clock to drive the wrclk of the fifo.  So my question is ->  How to correclty get this 5 bits (then 4 bits) into the fifo ?  I assume that this 25 MHz clock is derived directly from this 125 MHz clock , so the are synchronized. I should also assert correctly wrreq signal in fifo - and use a counter to write only these 32 * 64 bits and nothing else.   wrreq must be asserted somehow before the rising edge of wrclk (falling edge) ? What if i assert it in the rising edge? Will data be put into the fifo, or on the next cycle? Or something wrong will happen ?  I suppose that i should use a synchronizer for the sync flag in 125 Mhz- but don't know how to do it - it will give some delay to the sync in 25 MHz domain. I will lose then the actual data from the shift register (it will be shifted with 125Mhz clocks before i will be able to correctly read those 5 bits and put them into 25 Mhz clock domain) ?  Sorry for the mess, thanks for any suggestions and help best regards madness

[Altera_Forum]

--- 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

[Altera_Forum]

--- 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 :)

[Altera_Forum]

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.

[Altera_Forum]

--- 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

[Altera_Forum]

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:)

[Altera_Forum]

--- 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

[Altera_Forum]

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

[Altera_Forum]

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 ?

[Altera_Forum]

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 :)

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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.

[Altera_Forum]

--- 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

[Altera_Forum]

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.

[Altera_Forum]

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 : )

[Altera_Forum]

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.

[Altera_Forum]

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 

[Altera_Forum]

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.

[Altera_Forum]

--- 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 ?

[Altera_Forum]

In ModelSim, it's the tcheck_set command IIRC.

[Altera_Forum]

Hi, 

thanks Dave and rbugalho for the help so far :)  I have to do some configuration of my design - the configuration could be changed during the normal operation (with the dip switch). By configuration i mean the order of bits, number of generated wrreq to fifo and stuff like that. My questions:  1. Should I debounce a dip switch with some circuit ? 2. I suppose that the change in operation of the design should be done synchronously after one full operation is done (the new operation would be done with the new parametrs). 3. The receiver, transmitter - in a different files should change their operation - i was thinking about using a record with info about counts number, order of bits etc. - so i would make smth like:  signal counts_nr : integer range 0 to conf_record.to_count;should i constrain an integer in such manner? or give it full range and then only:  if counter < conf_record.to_count then....4. I'm using now integers to do counting in my design - what about the default value of integers ? when i want it to start from some nr like 2000 - in simulation it works - will it work after synthesis ?   5. where can i find some really cool educational stuff for begginers - practical examples ?  here's what i found so far:  http://people.ece.cornell.edu/land/courses/ece5760/finalprojects/ http://www.altera.com/literature/dc/lit-design-contest.jsp  best regards madness123