Cyclone III FIFO problem

[Altera_Forum]

Hi, 

 I have a problem with a Cyclone III design which uses two 512byte Fifos.  The problem is that the design is working fine, and after changing sth. e.g. adding some signals to signal tab, the design doesnt work after synthesis.  If I look at the FIFO input and output signals in signal tab, I can see that there are some bits wrong at the FIFO output. The Fifo Input Clock is 125mhz and the output clock is 33mhz. In signal tab I sample with 125mhz.  In the classic timing analyser there are no timingviolation. How could that be?  - maybe because the timings for CYCIII in Quartus are preliminary (I use 7.1 SP1) - are there knowing bugs for dual portet rams or other ram problems? - are there knowing bugs in CYC-C3-EN?  Is there a solution to avoid such a problem?  regards  Cyclone

[Altera_Forum]

tan defaults to cutting timing between unrelated clocks.  

 in signaltap, use 2 capture windows, one for each clock. you could easily be seeing eroneous errors.  --dalon

[Altera_Forum]

--- Quote Start ---  tan defaults to cutting timing between unrelated clocks.   --dalon  --- Quote End ---    what do you mean with "tan defaults"?    --- Quote Start ---   in signaltap, use 2 capture windows, one for each clock. you could easily be seeing eroneous errors.   --- Quote End ---    I know that it is not good to sample a signal with another clock domain, but I think that it is not a clock domain problem because I handle data all-around from one fifo to another and I should get the right data also on the 125 clock domain (FIFO 2) wich should be OK in Signal Tab.    ----->DATA--->|_FIFO_1__________|---->DATA---->|__FIFO_2_________|---> DATA _____125Mhz___===============_____33Mhz___================ ___125Mhz    regards   Cyclone

[Altera_Forum]

--- Quote Start ---  maybe because the timings for CYCIII in Quartus are preliminary (I use 7.1 SP1)  --- Quote End ---     I can't tell whether you're wondering if the timing is preliminary or if you already know it and just wonder if that's related to the problem. If the former, look for a Fitter compilation message like the one below, which I got with QII 7.1 SP1.  Warning: Timing characteristics of device EP3C25E144C7 are preliminary

[Altera_Forum]

--- Quote Start ---  tan defaults to cutting timing between unrelated clocks.  --- Quote End ---       --- Quote Start ---  what do you mean with "tan defaults"?  --- Quote End ---     The dual-clock FIFO megafunction has embedded cut-path timing assignments for paths going between clock domains. The Classic Timing Analyzer (not TimeQuest in QII 7.1 SP1) uses those automatic cross-domain cuts. In the Timing Analyzer compilation report, they will be listed in the "Timing Analyzer Settings" table (example below) if they were used or in the "Ignored Timing Assignments Table" if the design didn't need them.      --- Quote Start ---  +--------------------------------------------------------------------------------------------------------------------------------------+ ; Timing Analyzer Settings ; +-------------------------------------------------------+--------------------+-----------------+-------------------------+-------------+ ; Option ; Setting ; From ; To ; Entity Name ; +-------------------------------------------------------+--------------------+-----------------+-------------------------+-------------+ ; Cut Timing Path ; On ; delayed_wrptr_g ; rs_dgwp|dffpipe4|dffe5a ; dcfifo_o4e1 ; ; Cut Timing Path ; On ; rdptr_g ; ws_dgrp|dffpipe7|dffe8a ; dcfifo_o4e1 ; +-------------------------------------------------------+--------------------+-----------------+-------------------------+-------------+  --- Quote End ---  

[Altera_Forum]

--- Quote Start ---  I can't tell whether you're wondering if the timing is preliminary or if you already know it and just wonder if that's related to the problem. If the former, look for a Fitter compilation message like the one below, which I got with QII 7.1 SP1.  Warning: Timing characteristics of device EP3C25E144C7 are preliminary  --- Quote End ---    Im not wonering about that message, but I want to know if that could have sth. to do with my problem     --- Quote Start ---  The dual-clock FIFO megafunction has embedded cut-path timing assignments for paths going between clock domains. The Classic Timing Analyzer (not TimeQuest in QII 7.1 SP1) uses those automatic cross-domain cuts. In the Timing Analyzer compilation report, they will be listed in the "Timing Analyzer Settings" table (example below) if they were used or in the "Ignored Timing Assignments Table" if the design didn't need them.  --- Quote End ---    What ist "embedded cut-path timing "?  I have configured the FIFOs so that there is no relation between the two clock domains.

[Altera_Forum]

--- Quote Start ---  What ist "embedded cut-path timing "?  I have configured the FIFOs so that there is no relation between the two clock domains.  --- Quote End ---     Typically the dcfifo megafunction is used to transfer data between clock domains that do not have a synchronous relationship or that do have a synchronous relationship but with a phase difference that prevents synchronous transfers. For some applications, a Classic Timing Analyzer project-wide cut-path setting is enough to prevent timing analysis of the cross-domain paths through the FIFO. Now that I think about it, this is probably what Dalon referred to, not the cuts specific to the FIFO that I had in mind. For other applications, other cut-path settings are needed, and those settings are embedded in the FIFO megafunction HDL for use by the Classic Timing Analyzer.  In the "More Timing Settings" dialog box, "Cut paths between unrelated clock domains" defaults to "On" for the Classic Timing Analyzer. That project-wide cut covers cases like the FIFO write and read clocks coming from two different clock pins on the device (whether or not a PLL is between the device input clock pin and the FIFO).  For some dcfifo applications, the Classic Timing Analyzer will by default analyze the timing between the FIFO clock domains. An example is the FIFO write and read clocks coming from two outputs of the same PLL. The Classic Timing Analyzer considers these clocks to be related to each other unless you have a cut-path setting. The dcfifo megafunction embeds the cut-path settings into its HDL for you as shown at the end of this post.  With TimeQuest, you have to add the false-path exceptions yourself. That might be as simple as false-path exceptions in both directions between write clock and read clock if you have no synchronous paths between those clock domains outside the FIFO. (The dcfifo megafunction has paths going both directions between domains. You can use set_clock_groups instead of set_false_path for this.) If cutting between clocks might cut too many paths, you can create false-path exceptions for TimeQuest similar to those embedded in the dcfifo HDL for use by the Classic Timing Analyzer.  This is discussed in the Single- and Dual-Clock FIFO Megafunction User Guide, version 4.0, Chapter 3, page 3-9:    --- Quote Start ---  Setup and hold-time violations that occur on the synchronization pipeline registers (*dcfifo*dffpipe*) can be safely ignored.  In the Classic Timing Analyzer, these paths are cut by default and therefore no timing violations are reported.  However, in the TimeQuest Timing Analyzer, these paths are not cut automatically. To remove the resulting setup and hold-time violations, you must apply the Set False Path timing constraint to explicitly cut these timing paths.  --- Quote End ---    The cut-path settings I showed in my previous post are listed inside a megafunction HDL file. I did a little looking and found them for my test case. My dual-clock FIFO MegaWizard variation file instantiated the dcfifo megafunction. When that megafunction was synthesized, the dcfifo_o4e1.tdf AHDL file was created in my db directory. That file had the line shown below. The end of this line has the two cut-path settings I copied from the "Timing Analyzer Settings" table to my previous post.  OPTIONS ALTERA_INTERNAL_OPTION = "AUTO_SHIFT_REGISTER_RECOGNITION=OFF;REMOVE_DUPLICATE_REGISTERS=OFF;suppress_da_rule_internal=d101;suppress_da_rule_internal=d102;suppress_da_rule_internal=s102;{ -from ""rdptr_g"" -to ""ws_dgrp|dffpipe7|dffe8a"" }CUT=ON;{ -from ""delayed_wrptr_g"" -to ""rs_dgwp|dffpipe4|dffe5a"" }CUT=ON";