Signals across two clock domains

My objects:
I want to transfer large group of signals clocked at clock66M to signals
used at clock100M domain safely and reliably and vice verse without using
any FIFO mechanism: to save clocks and improve performances.

I am using the following method:

process(clock66M, nReset66M)
begin
if(nReset66M = '0') then
X, Y, Z <= (others=>'0'); -- signals are to be transferred
flag <= '0' -- 1 bit signal to control
transfer
elsif(clock66M'event and clock66M = '1') then
if(some conditions under clock66M are true) then
X <= ...;
Y <= ...;
Z <= ...;
flag <= '1';
end if;
end if;
end process;

Then flag is used at clock100M domain as follows:

process(clock100M, nReset100M)
begin
if(nReset100M = '0') then
flag100M <= '0';
Any100M <= (others=>'0');
elsif(clock100M'event and clock100M = '1') then
flag100M <= flag;
if(flag100M = '1') then -- (K)
Any100M <= f(X,Y,Z);
end if;
end if;
end process;
A
clock 66M: 1 1 1 1 1 1 1 1
(rising edge)
flag 0 0 0 1 1 1 1 1
X,Y,Z I I I J J J J J

clock100M: 1 1 1 1 1 1 1 1 1 1 1 (rising
edge)
B
flag100M: 0 0 0 0 0 1 1 1 1 1
possibility 1
C
Any100M: N N N N N N M M M M
D E
flag100M: 0 0 0 0 0 0 1 1 1 1
possibility 2
F
Any100M: N N N N N N N M M M

Point A: flag has 1 latched under clock66M and signal group has new value J
latched; Point B: flag100M has 1 latched under clock100M, it may be
metastable, but it always has two possible results: 1 or 0, based on whether
or not the following 'if' statement (K) is implemented at next clock: at
next clock, if 'if' statement (K) is implemented, it is a 1, if not, it is
0. Here B has 1 latched under clock100M; Point C: Any100M has M latched
under clock100M, involving X, Y, Z values latched under clock66M; Point D:
flag100M has 0 latched under clock100M, no action at next clock Point E:
flag100M has 1 latched under clock100M, this time its value is not at
metastable state due to the long time distance from A to E; Point F: Any100M
has a value M latched under clock100M, involving X, Y, Z values latched
under clock66M;

Now let's see if there is a possibility that Any100M is latched with wrong
value. If so, it is disastrous!

X, Y, Z values are used at Point C and F. If we can fit the design so that
signals X, Y and Z can reach Any100M within (10ns - setup time), there is no
problem. If not, it is a problem.

With Xilinx Navigator, I hope to establish a time item in *.ucf and check if
those conditions are met, if so, design is save and reliable.

Any comments are appreciated.

Weng

Weng Tianxiang

Weng,

There are a couple of problems with your approach.

A behavioral simulator should not be used to verify correct
functionality of signals crossing a clock domain. It is very
difficult to simulate all the possible clock relationships to make
this a reliable method.

There is also a problem of metastability on flip-flops, which is
caused by the violation of setup and hold timing requirements, which
is likely to happen with two asynchronous clocks.

You need to re-synchronize the signals in the 100 MHz clock domain, by
using at least 2 flip-flops before using the signal. You also need to
make sure your logic can accept signal assertions + / - one clock
period in relation to other signals.

Scott

(Weng Tianxiang) wrote in message news:<. com>...
> My objects:
> I want to transfer large group of signals clocked at clock66M to signals
> used at clock100M domain safely and reliably and vice verse without using
> any FIFO mechanism: to save clocks and improve performances.
>
> I am using the following method:
>
> process(clock66M, nReset66M)
> begin
> if(nReset66M = '0') then
> X, Y, Z <= (others=>'0'); -- signals are to be transferred
> flag <= '0' -- 1 bit signal to control
> transfer
> elsif(clock66M'event and clock66M = '1') then
> if(some conditions under clock66M are true) then
> X <= ...;
> Y <= ...;
> Z <= ...;
> flag <= '1';
> end if;
> end if;
> end process;
>
> Then flag is used at clock100M domain as follows:
>
> process(clock100M, nReset100M)
> begin
> if(nReset100M = '0') then
> flag100M <= '0';
> Any100M <= (others=>'0');
> elsif(clock100M'event and clock100M = '1') then
> flag100M <= flag;
> if(flag100M = '1') then -- (K)
> Any100M <= f(X,Y,Z);
> end if;
> end if;
> end process;
> A
> clock 66M: 1 1 1 1 1 1 1 1
> (rising edge)
> flag 0 0 0 1 1 1 1 1
> X,Y,Z I I I J J J J J
>
> clock100M: 1 1 1 1 1 1 1 1 1 1 1 (rising
> edge)
> B
> flag100M: 0 0 0 0 0 1 1 1 1 1
> possibility 1
> C
> Any100M: N N N N N N M M M M
> D E
> flag100M: 0 0 0 0 0 0 1 1 1 1
> possibility 2
> F
> Any100M: N N N N N N N M M M
>
> Point A: flag has 1 latched under clock66M and signal group has new value J
> latched; Point B: flag100M has 1 latched under clock100M, it may be
> metastable, but it always has two possible results: 1 or 0, based on whether
> or not the following 'if' statement (K) is implemented at next clock: at
> next clock, if 'if' statement (K) is implemented, it is a 1, if not, it is
> 0. Here B has 1 latched under clock100M; Point C: Any100M has M latched
> under clock100M, involving X, Y, Z values latched under clock66M; Point D:
> flag100M has 0 latched under clock100M, no action at next clock Point E:
> flag100M has 1 latched under clock100M, this time its value is not at
> metastable state due to the long time distance from A to E; Point F: Any100M
> has a value M latched under clock100M, involving X, Y, Z values latched
> under clock66M;
>
> Now let's see if there is a possibility that Any100M is latched with wrong
> value. If so, it is disastrous!
>
> X, Y, Z values are used at Point C and F. If we can fit the design so that
> signals X, Y and Z can reach Any100M within (10ns - setup time), there is no
> problem. If not, it is a problem.
>
> With Xilinx Navigator, I hope to establish a time item in *.ucf and check if
> those conditions are met, if so, design is save and reliable.
>
> Any comments are appreciated.
>
> Weng

Scott Dickson

Hello,

Without paying much attention to what you described below, I'd go for
Flancter (google "flancter weinstein"). It's simple and reliable method for
transferring data between clock domains. I once tested it with some
modifications and wrote a paper (unpublished) about the experiment. If you
want I can email the .pdf for you...

Regards,
juza

"Weng Tianxiang" <> wrote in message
news: om...
> My objects:
> I want to transfer large group of signals clocked at clock66M to signals
> used at clock100M domain safely and reliably and vice verse without using
> any FIFO mechanism: to save clocks and improve performances.
>
> I am using the following method:
>
> process(clock66M, nReset66M)
> begin
> if(nReset66M = '0') then
> X, Y, Z <= (others=>'0'); -- signals are to be transferred
> flag <= '0' -- 1 bit signal to control
> transfer
> elsif(clock66M'event and clock66M = '1') then
> if(some conditions under clock66M are true) then
> X <= ...;
> Y <= ...;
> Z <= ...;
> flag <= '1';
> end if;
> end if;
> end process;
>
> Then flag is used at clock100M domain as follows:
>
> process(clock100M, nReset100M)
> begin
> if(nReset100M = '0') then
> flag100M <= '0';
> Any100M <= (others=>'0');
> elsif(clock100M'event and clock100M = '1') then
> flag100M <= flag;
> if(flag100M = '1') then -- (K)
> Any100M <= f(X,Y,Z);
> end if;
> end if;
> end process;
> A
> clock 66M: 1 1 1 1 1 1 1 1
> (rising edge)
> flag 0 0 0 1 1 1 1 1
> X,Y,Z I I I J J J J J
>
> clock100M: 1 1 1 1 1 1 1 1 1 1 1 (rising
> edge)
> B
> flag100M: 0 0 0 0 0 1 1 1 1 1
> possibility 1
> C
> Any100M: N N N N N N M M M M
> D E
> flag100M: 0 0 0 0 0 0 1 1 1 1
> possibility 2
> F
> Any100M: N N N N N N N M M M
>
> Point A: flag has 1 latched under clock66M and signal group has new value
J
> latched; Point B: flag100M has 1 latched under clock100M, it may be
> metastable, but it always has two possible results: 1 or 0, based on
whether
> or not the following 'if' statement (K) is implemented at next clock: at
> next clock, if 'if' statement (K) is implemented, it is a 1, if not, it is
> 0. Here B has 1 latched under clock100M; Point C: Any100M has M latched
> under clock100M, involving X, Y, Z values latched under clock66M; Point D:
> flag100M has 0 latched under clock100M, no action at next clock Point E:
> flag100M has 1 latched under clock100M, this time its value is not at
> metastable state due to the long time distance from A to E; Point F:
Any100M
> has a value M latched under clock100M, involving X, Y, Z values latched
> under clock66M;
>
> Now let's see if there is a possibility that Any100M is latched with wrong
> value. If so, it is disastrous!
>
> X, Y, Z values are used at Point C and F. If we can fit the design so that
> signals X, Y and Z can reach Any100M within (10ns - setup time), there is
no
> problem. If not, it is a problem.
>
> With Xilinx Navigator, I hope to establish a time item in *.ucf and check
if
> those conditions are met, if so, design is save and reliable.
>
> Any comments are appreciated.
>
> Weng

jussi l

When is the flag signal reset to '0' ???
As far as I see in the code flag is reset to zero only on a reset.
So that means once a change occurs on x,y,z flag goes to '1' and after that
any subsequent changes in the signals X,Y,Z dont cause any change in flag
|---------------------------------
|
flag ---------------|

| | |
event on x,y,z ---------------|---------|-------------|-----------

so that means any subsequent event on x,y,z is just flopped onto the 100M
domain in every clock edge(clk100M) because flag100M will always be '1'
once an event happens on X,Y,Z and will be cleared only on a reset.
So whats the use of flag in this code???



(Weng Tianxiang) wrote in message news:<. com>...
> My objects:
> I want to transfer large group of signals clocked at clock66M to signals
> used at clock100M domain safely and reliably and vice verse without using
> any FIFO mechanism: to save clocks and improve performances.
>
> I am using the following method:
>
> process(clock66M, nReset66M)
> begin
> if(nReset66M = '0') then
> X, Y, Z <= (others=>'0'); -- signals are to be transferred
> flag <= '0' -- 1 bit signal to control
> transfer
> elsif(clock66M'event and clock66M = '1') then
> if(some conditions under clock66M are true) then
> X <= ...;
> Y <= ...;
> Z <= ...;
> flag <= '1';
> end if;
> end if;
> end process;
>
> Then flag is used at clock100M domain as follows:
>
> process(clock100M, nReset100M)
> begin
> if(nReset100M = '0') then
> flag100M <= '0';
> Any100M <= (others=>'0');
> elsif(clock100M'event and clock100M = '1') then
> flag100M <= flag;
> if(flag100M = '1') then -- (K)
> Any100M <= f(X,Y,Z);
> end if;
> end if;
> end process;
> A
> clock 66M: 1 1 1 1 1 1 1 1
> (rising edge)
> flag 0 0 0 1 1 1 1 1
> X,Y,Z I I I J J J J J
>
> clock100M: 1 1 1 1 1 1 1 1 1 1 1 (rising
> edge)
> B
> flag100M: 0 0 0 0 0 1 1 1 1 1
> possibility 1
> C
> Any100M: N N N N N N M M M M
> D E
> flag100M: 0 0 0 0 0 0 1 1 1 1
> possibility 2
> F
> Any100M: N N N N N N N M M M
>
> Point A: flag has 1 latched under clock66M and signal group has new value J
> latched; Point B: flag100M has 1 latched under clock100M, it may be
> metastable, but it always has two possible results: 1 or 0, based on whether
> or not the following 'if' statement (K) is implemented at next clock: at
> next clock, if 'if' statement (K) is implemented, it is a 1, if not, it is
> 0. Here B has 1 latched under clock100M; Point C: Any100M has M latched
> under clock100M, involving X, Y, Z values latched under clock66M; Point D:
> flag100M has 0 latched under clock100M, no action at next clock Point E:
> flag100M has 1 latched under clock100M, this time its value is not at
> metastable state due to the long time distance from A to E; Point F: Any100M
> has a value M latched under clock100M, involving X, Y, Z values latched
> under clock66M;
>
> Now let's see if there is a possibility that Any100M is latched with wrong
> value. If so, it is disastrous!
>
> X, Y, Z values are used at Point C and F. If we can fit the design so that
> signals X, Y and Z can reach Any100M within (10ns - setup time), there is no
> problem. If not, it is a problem.
>
> With Xilinx Navigator, I hope to establish a time item in *.ucf and check if
> those conditions are met, if so, design is save and reliable.
>
> Any comments are appreciated.
>
> Weng

Sajan

Hi Sajan,
My project have a PCI 66/64 interface running on 66MHz and a DDR SDRAM
system running on 100MHz.

When a write or a read data transaction starts on PCI interface, I got
the transaction starting address at 66MHz.

Now one thing I want to do is to get the PCIStartingAddress latched on
66MHz transferred to 100MHz domain and write PCIStartingAddress with
read/write commmand to DDR DIMM I/O with 100MHz as soon as possible.
PCIStartingAddress and read/write direction latched on 66MHz doesn't
change until next transaction. You are right that flag should be reset
somewhere after PCIStartingAddress is used.


|---------------------------|
66MHz | |
flag ---------------| |------


66MHz | data are latched, don't change
x,y,z ---------------|**********************************

|--------------------------|
100MHz | |
flag100M -----------------| |--

| | @100MHz
delta T-->| | 1 clock | based on x,y,z
New100M ------------|xxxx|xxxxxxxxxxxxxx|++++++++++++++

So when flag is viewed as 1 indicated by flag100M from 100MHz domain,
x,y,z values can be safely used in 100MHz domain.
From the point x,y,z latched under 66MHz to the point x,y,z used under
100MHz is (delta T + 1 clock at 100MHz).
Delta T may be less than 1 clock or longer than 1 clock at 100MHz
based on phases between rising edges of 66MHz and 100MHz.

If Xilinx Navigator can indicate that paths from x,y,z to New100M are
shorter than (10ns - setup time), New100M can be latched reliably
without any problem. 10ns is 1 clock time for 100MHz.

Thank you.

Weng

Hi Jusa,
I am very interested in your paper and related sources.
Please email me all those materials.

Thank you.

Weng

Weng Tianxiang

(Weng Tianxiang) wrote in message news:<. com>...
> My objects:
> I want to transfer large group of signals clocked at clock66M to signals
> used at clock100M domain safely and reliably and vice verse without using
> any FIFO mechanism: to save clocks and improve performances.

....

> Any comments are appreciated.
>
> Weng

Wrong, wrong, wrong!

Your technique does not work. Any time you pass multiple related
signals between clock domains, you either need a FIFO or you need to
hold the value in a register, synchronize a "ready" signal between the
clock domains (and synchronize an "acknowledge" signal back to the
sending clock domain - which kills the goal of saving clocks) to grab
the registered signals.

Scott Dickson is right that you cannot use a behavioral simulator to
accurately model this situation. The problem is that a simulator will
use ideal matched delays and never show you a multi-clock skewing
problem.

Scott mentioned that you need a pair of flip-flops to synchronize each
signal. That is not good enough. The related synchronized signals
could become skewed and then some data values will be transferred a
cycle too soon or a cycle too late.

I suggest you download and study my SNUG 2001 paper on
multi-asynchronous clock design to better understand the problem.
www.sunburst-design.com/papars

The paper is written for Verilog design but the techniques apply to
all digital design. Multi-clock design is poorly taught (at best) in
colleges and is not well understood in industry. I wonder how many
Mars-Landers have become Mars-Torpedoes due to poor multi-clock design
practices!

Regards - Cliff Cummings
----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
Verilog On-Site Training Sale - 4-day Courses for $1,200/Student
/ www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training

Cliff Cummings

Cliff Cummings,
Very appreciate your comments.

I can open you website, but fail to open Paper window. I appreciate if
you send me a copy of your paper about the subject by email.

But I totally disagree with your claim: "wrong, wrong, wrong".

What I have planned is exactly what you say:
"you need to hold the value in a register, synchronize a "ready"
signal between the clock domains to grab the registered signals."

This statement is wrong:
"(and synchronize an "acknowledge" signal back to the sending clock
domain - which kills the goal of saving clocks)"

I don't generate "acknowledge" signal back!!! Never. In a one-person
fully controlled design environment, I don't need any type of
acknowledge signals. Everything goes by designed rules, no
communications between two clock domain except starting signal.

Please carefully read my scheme: Assuming signals directions:
Clock66MHz domain --> Clock100MHz domain.
1. All crossing boundary signals are registers clocked by Clock66MHz,
not combinatorial, and they will be kept unchanged for at least as
long as possible, for example, more that 4 clocks at Clock66MHz. Their
values will not change until next transaction starts that is far
beyond their lifespan.

2. Flag is a register and it is latched by Clock66MHz with all
crossing boundary signals latched at the same clock of Clock66MHz;
Flag is used to really transfer "event happening message" to
Clock100MHz domain.

3. Flag100M is a register clocked by Clock100MHz, and fed by Flag
signal.

4. All problem here is Flag100M. It has metastability problem.
There are 3 situations:
a. Flag100M is stable at 0 during next setup time period of
Clock100MHz:
Wait one more clock under Clock100MHz to get next 1 value;
b. Flag100M is stable at 1 during next setup time period of
Clock100MHz:
Immediately goes as planed. All crossing boundary signals latched at
Clock66MHz can be used reliably if their paths to targeted signals at
Clock100MHz are shorter than (10ns - setup time). During that period,
no crossing boundary signals change values. So there is no any problem
here.
c. Flag100M is at metastable state during next setup time period of
Clock100MHz: it means that during the settup time period, Flag100M may
change value from 0 to 1, causing next level registered values
unstable.

So in my design, I have a plan to do the design in two stages:
1. Use 2 clock scheme, that means the following equations are used:

process(nRESET100M, CLK100M)
begin
if(nRESET100M) then
Flag100M(1 downto 0) <= "00";
elsif(CLK100M'event and CLK100M = '1') then
Flag100M(1 downto 0) <= Flag100M(0) & flag;
end if;
end process;

Condition indicating that event is happening:
Flag100M(1 downto 0) = "11"

If that scheme is successful without any error, I would like to change
above condition to:
Flag100M(0) = '1'. <-- this scheme is what I want to prove.

Thank you.

Weng



(Cliff Cummings) wrote in message news:< om>...
> (Weng Tianxiang) wrote in message news:<. com>...
> > My objects:
> > I want to transfer large group of signals clocked at clock66M to signals
> > used at clock100M domain safely and reliably and vice verse without using
> > any FIFO mechanism: to save clocks and improve performances.
>
> ...
>
> > Any comments are appreciated.
> >
> > Weng
>
> Wrong, wrong, wrong!
>
> Your technique does not work. Any time you pass multiple related
> signals between clock domains, you either need a FIFO or you need to
> hold the value in a register, synchronize a "ready" signal between the
> clock domains (and synchronize an "acknowledge" signal back to the
> sending clock domain - which kills the goal of saving clocks) to grab
> the registered signals.
>
> Scott Dickson is right that you cannot use a behavioral simulator to
> accurately model this situation. The problem is that a simulator will
> use ideal matched delays and never show you a multi-clock skewing
> problem.
>
> Scott mentioned that you need a pair of flip-flops to synchronize each
> signal. That is not good enough. The related synchronized signals
> could become skewed and then some data values will be transferred a
> cycle too soon or a cycle too late.
>
> I suggest you download and study my SNUG 2001 paper on
> multi-asynchronous clock design to better understand the problem.
> www.sunburst-design.com/papars
>
> The paper is written for Verilog design but the techniques apply to
> all digital design. Multi-clock design is poorly taught (at best) in
> colleges and is not well understood in industry. I wonder how many
> Mars-Landers have become Mars-Torpedoes due to poor multi-clock design
> practices!
>
> Regards - Cliff Cummings
> ----------------------------------------------------
> Cliff Cummings - Sunburst Design, Inc.
> Verilog On-Site Training Sale - 4-day Courses for $1,200/Student
> / www.sunburst-design.com
> Expert Verilog, SystemVerilog, Synthesis and Verification Training

Weng Tianxiang

Weng Tianxiang wrote:
> Cliff Cummings,
> Very appreciate your comments.
>
> I can open you website, but fail to open Paper window. I appreciate if
> you send me a copy of your paper about the subject by email.

I think that was a typo, try this:

http://www.sunburst-design.com/papers/

> But I totally disagree with your claim:

Consider reading Cliff's paper and
thinking about it a while.

Synchronization is something that
everyone gets wrong the first time.

-- Mike Treseler

Mike Treseler

Cliff's paper about FIFO #1 is a requisite reading for any serious
digital programmers who want to make a design across clock domains.

Excellent, very clear, understandable and hopely reliable by board
testing.

But finally the design still has rooms to improve.

Weng



Mike Treseler <> wrote in message news:<>...
> Weng Tianxiang wrote:
> > Cliff Cummings,
> > Very appreciate your comments.
> >
> > I can open you website, but fail to open Paper window. I appreciate if
> > you send me a copy of your paper about the subject by email.
>
> I think that was a typo, try this:
>
> http://www.sunburst-design.com/papers/
>
> > But I totally disagree with your claim:
>
> Consider reading Cliff's paper and
> thinking about it a while.
>
> Synchronization is something that
> everyone gets wrong the first time.
>
> -- Mike Treseler

Weng Tianxiang

Weng Tianxiang wrote:

> I see many papers you posted on google.comp.vhdl.
> But I didn't see your post on my post
> "Signals across two clock domains"
> I would like to listen to your comments.

I didn't respond because your posting
did not contain a question.


If you had asked:

"How can I interface a 66 MHz data bus to
an FPGA running at 100MHz?"

I might have answered:

Consider running your FPGA at 66 MHz also.

-- Mike Treseler

Mike Treseler