Multiple clock domains

Hi all,

I'm a newbye in VHDL and I would like to submit a question. I have a
system wich is clocked at 24MHz by
an external oscillator. This clock is the input of a PLL internal to
the FPGA. The outputs of the PLL are
two clocks: one at 48MHz to clock a CPU and a custom logic called "A",
and the other one at 24MHz to
clock a custom logic called "B". These two clocks are produced without
phase shifts as stated by the PLL
megawizard plug-in manager.

The custom logic "A" (clocked at 48MHz) receives some input signals
from the custom logic "B" (clocked at
24MHz). The question is: do the custom logic "B" signals have to be
syncronized with the 48MHz clock ?
Does the metastability issue apply also if the 24MHz clock is strictly
derived from the 48MHz one ?

Best Regards

/Alessandro

alessandro.strazzero@gmail.com <alessandro.strazzero@gmail.com> wrote:
 
> I'm a newbye in VHDL and I would like to submit a question. I have a
> system wich is clocked at 24MHz by an external oscillator. 
> This clock is the input of a PLL internal to the FPGA. 
> The outputs of the PLL are two clocks: one at 48MHz to clock 
> a CPU and a custom logic called "A", and the other one at 24MHz to
> clock a custom logic called "B". 
(snip)

> The question is: do the custom logic "B" signals have to be
> syncronized with the 48MHz clock ?

If you can meet the setup and hold times, then you are safe.

-- glen

On Nov 25, 4:18=A0pm, "alessandro.strazz...@gmail.com"
<alessandro.strazz...@gmail.com> wrote:
> Hi all,
>
> I'm a newbye in VHDL and I would like to submit a question. I have a
> system wich is clocked at 24MHz by
> an external oscillator. This clock is the input of a PLL internal to
> the FPGA. The outputs of the PLL are
> two clocks: one at 48MHz to clock a CPU and a custom logic called "A",
> and the other one at 24MHz to
> clock a custom logic called "B". These two clocks are produced without
> phase shifts as stated by the PLL
> megawizard plug-in manager.
>
> The custom logic "A" (clocked at 48MHz) receives some input signals
> from the custom logic "B" (clocked at
> 24MHz). The question is: do the custom logic "B" signals have to be
> syncronized with the 48MHz clock ?
> Does the metastability issue apply also if the 24MHz clock is strictly
> derived from the 48MHz one ?
>
> Best Regards
>
> /Alessandro

In general, if you don't need domains to be synchronous, you should
specify TIG constraints between the domains so the tool doesn't have
to spend time timing those paths, which improves overall time-cost
budget. If you want the domains to be synchronous, beings that both
clocks are derived as simple multiple (1x/2x) and from the same PLL,
this is no problem. The tool should time those paths as if they are
synchronous by default as long as you put your clock constraint on the
input to the PLL. And both of these type of outputs from the same PLL
typically have a low-skew characteristic between these outputs of the
same PLL.
John

On Nov 25, 4:18=A0pm, "alessandro.strazz...@gmail.com"
<alessandro.strazz...@gmail.com> wrote:
> Hi all,
>
> I'm a newbye in VHDL and I would like to submit a question. I have a
> system wich is clocked at 24MHz by
> an external oscillator. This clock is the input of a PLL internal to
> the FPGA. The outputs of the PLL are
> two clocks: one at 48MHz to clock a CPU and a custom logic called "A",
> and the other one at 24MHz to
> clock a custom logic called "B". These two clocks are produced without
> phase shifts as stated by the PLL
> megawizard plug-in manager.
>
> The custom logic "A" (clocked at 48MHz) receives some input signals
> from the custom logic "B" (clocked at
> 24MHz). The question is: do the custom logic "B" signals have to be
> syncronized with the 48MHz clock ?
> Does the metastability issue apply also if the 24MHz clock is strictly
> derived from the 48MHz one ?
>
> Best Regards
>
> /Alessandro

Your synthesis/place and route/timing tools will likely properly
constrain data moving from the B to the A clock domain (i.e.
accounting for whatever phase offset there may be in the actual
implementation). That said, it's common to implement a proper clock
domain crossing in a case like this, even if it's just a simple clock
enable transfer.

Chris

On Thu, 25 Nov 2010 13:18:09 -0800 (PST),
"alessandro.strazzero@gmail.com" <alessandro.strazzero@gmail.com>
wrote:

>Hi all,
>
>I'm a newbye in VHDL and I would like to submit a question. I have a
>system wich is clocked at 24MHz by
>an external oscillator. This clock is the input of a PLL internal to
>the FPGA. The outputs of the PLL are
>two clocks: one at 48MHz to clock a CPU and a custom logic called "A",
>and the other one at 24MHz to
>clock a custom logic called "B". These two clocks are produced without
>phase shifts as stated by the PLL
>megawizard plug-in manager.
>

Even with phase-shifts,

>The custom logic "A" (clocked at 48MHz) receives some input signals
>from the custom logic "B" (clocked at
>24MHz). The question is: do the custom logic "B" signals have to be
>syncronized with the 48MHz clock ?

you don't need synchronization. Timing engine knows the relative
output delays of the PLL and adjusts the paths accordingly. 

>Does the metastability issue apply also if the 24MHz clock is strictly
>derived from the 48MHz one ?

No. As long as you compensate for the phase (which is no different
from building a good clock tree) you can meet setup/hold which is all
you need for this case.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

In article <icmns0$f6j$1@news.eternal-september.org>,
 glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>alessandro.strazzero@gmail.com <alessandro.strazzero@gmail.com> wrote:
> 
>> I'm a newbye in VHDL and I would like to submit a question. I have a
>> system wich is clocked at 24MHz by an external oscillator. 
>> This clock is the input of a PLL internal to the FPGA. 
>> The outputs of the PLL are two clocks: one at 48MHz to clock 
>> a CPU and a custom logic called "A", and the other one at 24MHz to
>> clock a custom logic called "B". 
>(snip)
>
>> The question is: do the custom logic "B" signals have to be
>> syncronized with the 48MHz clock ?
>
>If you can meet the setup and hold times, then you are safe.

Right.  But there are two tricky areas.

One is that you have to include clock skew, and that includes
the skew between the two clocks.

The other is that you have to check the hold time.  Several/many
years ago, somebody reported this sort of problem on a Xilinx part.
Xilinx doesn't check hold times.  They are guaranteed-by-design.
Except something didn't work if there was a little extra clock
skew due to using two different clocks.

Does Altera check hold times?

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:
> In article <icmns0$f6j$1@news.eternal-september.org>,
(snip on two clocks generated by PLL (is that DCM?) inside
an FPGA)

>>> The question is: do the custom logic "B" signals have to be
>>> syncronized with the 48MHz clock ?

(then I wrote)
>>If you can meet the setup and hold times, then you are safe.
 
> Right.  But there are two tricky areas.
 
> One is that you have to include clock skew, and that includes
> the skew between the two clocks.

Well, you have to include clock skew more than that included
by the designers.  In TTL, you can connect a FF output directly
to a D input, and possibly not meed the hold time. 

For FPGA, the fastest you can get from one FF to the input
of the next is through at least one LUT.  (For most, anyway.)
As long as the skew is small enough that, when added to the
LUT delay, it meets hold for the following FF, then it works.
 
> The other is that you have to check the hold time.  Several/many
> years ago, somebody reported this sort of problem on a Xilinx part.
> Xilinx doesn't check hold times.  They are guaranteed-by-design.
> Except something didn't work if there was a little extra clock
> skew due to using two different clocks.

I believe that the DCM will generate two clocks, one twice the
frequncy of the other, and such that when appropriate they transition
close enough together not to cause clock skew problems.

If you bring them from the outside, and don't resynchronize one,
then you can easily have skew problems.

Then again, if you have more than one clock period delay through
the logic, then you could again fail hold (or setup).
 
> Does Altera check hold times?

-- glen

On Mon, 29 Nov 2010 20:52:08 -0600,
hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote:

>In article <icmns0$f6j$1@news.eternal-september.org>,
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>alessandro.strazzero@gmail.com <alessandro.strazzero@gmail.com> wrote:
>> 
>>> I'm a newbye in VHDL and I would like to submit a question. I have a
>>> system wich is clocked at 24MHz by an external oscillator. 
>>> This clock is the input of a PLL internal to the FPGA. 
>>> The outputs of the PLL are two clocks: one at 48MHz to clock 
>>> a CPU and a custom logic called "A", and the other one at 24MHz to
>>> clock a custom logic called "B". 
>>(snip)
>>
>>> The question is: do the custom logic "B" signals have to be
>>> syncronized with the 48MHz clock ?
>>
>>If you can meet the setup and hold times, then you are safe.
>
>Right.  But there are two tricky areas.
>
>One is that you have to include clock skew, and that includes
>the skew between the two clocks.
>
Xilinx tools (mainly PAR & TRCE which use the same timing engine) know
how to add the phase shift while calculating timing path delays. Also
clock skews of different paths are added to the source and/or target
paths too.

>The other is that you have to check the hold time.  Several/many
>years ago, somebody reported this sort of problem on a Xilinx part.
>Xilinx doesn't check hold times.  They are guaranteed-by-design.

This is no longer true. TRCE is able and willing to do a fast path
analysis correctly for single cycle paths. For multi-cycle paths there
is a big acknowledged bug in the timing engine which won't get fixed
till next gen tools.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Replaying to the question below:

> Does Altera check hold times?

Yes, Altera tools check hold times.  We check all timing constraints:
setup & hold, plus the asynchronous reset equivalents (recovery &
removal) at all timing corners (3 in our latest devices), with on-die
variation and jitter models applied at each corner.  The corners cover
large, correlated variation, while the "within corner" min/max
variation and clock uncertainty models cover less correlated variation
and timing jitter.

If TimeQuest says it works, and you have properly timing constrained
the design, it will be robust.

Regards,

Vaughn Betz
Altera

Hal Murray wrote:
> In article <icmns0$f6j$1@news.eternal-september.org>,
>  glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> >alessandro.strazzero@gmail.com <alessandro.strazzero@gmail.com> wrote:
> >
> >> I'm a newbye in VHDL and I would like to submit a question. I have a
> >> system wich is clocked at 24MHz by an external oscillator.
> >> This clock is the input of a PLL internal to the FPGA.
> >> The outputs of the PLL are two clocks: one at 48MHz to clock
> >> a CPU and a custom logic called "A", and the other one at 24MHz to
> >> clock a custom logic called "B".
> >(snip)
> >
> >> The question is: do the custom logic "B" signals have to be
> >> syncronized with the 48MHz clock ?
> >
> >If you can meet the setup and hold times, then you are safe.
>
> Right.  But there are two tricky areas.
>
> One is that you have to include clock skew, and that includes
> the skew between the two clocks.
>
> The other is that you have to check the hold time.  Several/many
> years ago, somebody reported this sort of problem on a Xilinx part.
> Xilinx doesn't check hold times.  They are guaranteed-by-design.
> Except something didn't work if there was a little extra clock
> skew due to using two different clocks.
>
> Does Altera check hold times?
>
> --
> These are my opinions, not necessarily my employer's.  I hate spam.

On Dec 8, 3:16=A0pm, Vaughn <vaughnb...@gmail.com> wrote:
> Replaying to the question below:
>
> > Does Altera check hold times?
>
> Yes, Altera tools check hold times. =A0We check all timing constraints:
> setup & hold, plus the asynchronous reset equivalents (recovery &
> removal) at all timing corners (3 in our latest devices), with on-die
> variation and jitter models applied at each corner. =A0The corners cover
> large, correlated variation, while the "within corner" min/max
> variation and clock uncertainty models cover less correlated variation
> and timing jitter.
>
> If TimeQuest says it works, and you have properly timing constrained
> the design, it will be robust.
>
> Regards,
>
> Vaughn Betz
> Altera

Not trying to pick on Altera as I think this is a problem with all
vendors' products.  But how do you verify that your timing constraints
are correct?  It is easy to say that any part of a design will be
correct if you have done your design work right.  But 90% of
engineering is making sure that it is correct.  There are many
different methods, techniques and tools to assist the process of
verification for nearly every aspect of design work.  I don't know of
any that will verify that your design is properly constrained for
timing.

I have never figured out why no one seems to see this as a problem.
Is there something I am missing?

Rick