How do I synchronize gray code counts safely across asynchronous clock domains?

I tried the multicycle with 2/1 and 1/0. In the latter case, I am now getting setup time violations, as well as the skew violation. The fitter is still inserting unnecessary (from my view) delay between flops. These flops are in the same or adjacent LABs, but the physical routing is going all over the place.

I am facing a similar situation. Did you ever figure out a good way to constrain these?

No, I am afraid I have not.

Thanks. I have filled a support request. If I hear anything from them I will post it here.

I have a similar problem with setting the rules for a Gray Counter.

I did not receive a useful reply from Altera support. However the local FAE helped a lot and came back with some suggestions. I also found some papers at zimmer (http://www.zimmerdesignservices.com/index.php?section=12)design that describe the problem and solutions for the ASIC world. His technique doesn't work directly but there is some very good information there.

1. The first step is to generate a list of all source to destination registers that cross a gray code domain and extract their timing information. I created a TCL script that runs in TimeQuest which generates this list and outputs it to a file. This information can't be calculated from the SDC file due to limits Quartus has in which functions can be called during SDC. So I do it ahead of time and store the information in a file.
   • Use get_registers to get a list of all the gray coded registers for both the read and write sides of the FIFO.

   • Use get_timing_paths -from to get a list of all paths that go from a gray coded register to another register.

   • Write the timing information along with the path source and destination registers to the output file.

   • Each line in the file is: src_reg_name dest_reg_name src_clock dst_clock src_period dst_period counter_width_in_bits

   • Not all of the information in the output file is used but it is easy to calculate so I added it in case it becomes useful later.

2. In my SDC file I use set_clock_groups to tell the system which clocks are related.

3. In my SDC file, after all the set_clock_groups statements, I call another TCL script that dynamically generates timing constraints for each source->destination pair in the file output from the first stage.
   • I create a new clock for each source and destination clock listed in the file. All the skew constraints will use the new clocks. Remember, the original clocks have clock groups applied and will be ignored for cross clock timing analysis. Our new clocks will be setup to ignore all signals EXCEPT the gray coded paths we care about. The Zimmer paper discusses why this is necessary.

   • I use set_min_delay, set_max_delay, and set_false_paths to prevent timing analysis on all signals on the new clocks

   • I use set_max_delay to set a constraint equal to the desired skew on the new_src_clk->new_dest_clk path.

   • The tricky part is the skew limit. The set_max_delay command causes Quartus to limit the max_delay path but that path includes the clock_source routing delay to the register. We don't expect that clock_source delay to vary a lot from register to register (for a given clock) but we don't know what that delay is and we don't have a good way to calculate it. So, I set the skew limit to be the source clock period and add a 2ns fudge factor to account for clock source delay. So far that seems to work.

4. To check the skew I use another TCL script that I run from TimeQuest which generates skew reports for each timing model. This script was created by folks at Altera. I modified it slightly to match the names of the registers in my design.

1. Each build uses gray coded timing information from the last time you ran the generate timing file script. This is not too big a deal since most of the time the gray coded paths don't change that often.

2. You have to run the 'generate timing information' script each time you add another FIFO (or remove one) in order to update the timing information file. I run it when I know the design has changed or when it has been a while just for good measure. I don't run it every time because it takes a long time and most of the time the output file is unchanged.

3. The script called from the SDC file to dynamically generate skew constraints does not seem to add much delay to the build process. My build take about 2.5 hours and the skew part seems to make < 5min difference - if that.

4. The script to generate the timing information (run after the build completes) takes a long time to run (~30 minutes or more).

5. The script to generate skew report takes a long time to run (~30 minutes or more).

6. The skew limit is fudged a little due to the source_clock routing delay being used by Quartus for set_max_delay.

1. cv_lib.tcl is a library with routines that are called from other scripts.

2. gen_fifo_constraints.tcl is called from TimeQuest to generate the gray code timing data file.

3. skew_report.tcl is called from TimeQuest to generate all the skew reports.

lappend ::auto_path "<path to directory containing cv_lib>"
package require cv_lib
...
#  generate clocks <create_clock>
#  constrain clocks <set_clock_groups>
...
cv_lib::create_fifo_skew_constraints

Sorry for my poor English, I'm from China

Yes I think you are confused.