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

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.

In the end I came up with the following solution which is overly complicated but does work. The design I'm using it on is a StratixV 5SGXEA7K2F40C3 with 123,666 of 234,720 ALMs used ( 53 % ).

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.

There are some issues with this approach:

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.

I have attached the files I am using. They are not generic. You will have to modify paths and such. You will also need to change the pattern matching value for the places where lists of registers are being generated. I'm not an expert with TCL so please excuse any strangeness you find! Or make improvements.

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.

In you SDC file you will need to add a reference to the cv_lib library. You will also need to make a call to the function create_fifo_skew_constraints after you generate all your clocks and clock constraints.

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