Multiple clock domains

[alessandro.strazzero@gmai]

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

 

[glen herrmannsfeldt]

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

 

[jc]

On Nov 25, 4:18 pm, "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

 

[Chris Maryan]

On Nov 25, 4:18 pm, "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

 

[Muzaffer Kal]

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

 

[Hal Murray]

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.

 

[Muzaffer Kal]

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

 

[glen herrmannsfeldt]

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

 

[Vaughn]

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.

 

[rickman]

On Dec 8, 3:16 pm, Vaughn <vaughnb...@gmail.com> wrote:

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

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

 

[Muzaffer Kal]

On Thu, 9 Dec 2010 18:12:46 -0800 (PST), rickman <gnuarm@gmail.com>
wrote:

On Dec 8, 3:16 pm, Vaughn <vaughnb...@gmail.com> wrote:
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

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?

Maybe yes, maybe no. The simple fact is that if you design fully
synchronous systems with single clock, the only additional
constraint(s) to clock period you need are the external IO timing.
For most of the designs setting the clock period(s) is enough to
constrain all of your design (and with a DCM setting the period of the
input clock is enough most of the time too).
If, on the other hand, you have asynchronous clocks and/or resets,
multi-cycle paths, ripple clocks then you need to pay extra attention.
There are several tools which check for each of these conditions and
verify the timing constraints you set in flow but these tools are
quite expensisve and mostly (only?) used in ASIC flow. For FPGAs most
people seem to ignore these conditions and use the silicon to test
their designs. I am amazed that some people don't even simulate their
designs and go from editor to bit file directly and test on hardware.
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

 

[rickman]

On Dec 9, 10:04 pm, Muzaffer Kal <k...@dspia.com> wrote:

On Thu, 9 Dec 2010 18:12:46 -0800 (PST), rickman <gnu...@gmail.com
wrote:



On Dec 8, 3:16 pm, Vaughn <vaughnb...@gmail.com> wrote:
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

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?

Maybe yes, maybe no. The simple fact is that if you design fully
synchronous systems with single clock, the only additional
constraint(s)  to clock period  you need are the external IO timing.

That's a pretty big simplification. The fact that you have a single
clock does not mean that your entire design runs in one clock cycle.
One of the trickier parts of timing constraints is getting the right
clock timing applied to the right sections of logic in a design. In
any given design I have large amounts of logic that run at many clock
cycles multiples. If I try to spec these multi-clock sections I run
the risk of under-constraining some part of the design I didn't intend
to apply that constraint to. To the best of my knowledge there is no
way to verify that my timing constraints are correct.

For most of the designs setting the clock period(s) is enough to
constrain all of your design (and with a DCM setting the period of the
input clock is enough most of the time too).
If, on the other hand, you have asynchronous clocks and/or resets,
multi-cycle paths, ripple clocks then you need to pay extra attention.

"Pay extra attention"... that is what it is all about. I can pay tons
of attention, but I make mistakes... even when I'm not posting to
newsgroups late at night. The hard part of engineering is figuring
out ways of catching those mistakes. I am talking about the nearly
total lack of verification of timing constraints. Bad constraints can
create some of the worst intermittent bugs you have ever seen.

There are several tools which check for each of these conditions and
verify the timing constraints you set in flow but these tools are
quite expensisve and mostly (only?) used in ASIC flow. For FPGAs most
people seem to ignore these conditions and use the silicon to test
their designs. I am amazed that some people don't even simulate their
designs and go from editor to bit file directly and test on hardware.

I've never seen any of these tools, but maybe that's because I work
with FPGAs. Testing timing in silicon is not a very good way to
verify constraints. To properly test timing you would need to get
your hands on the slowest chips that meet the specs, drop the power
supply voltage to the minimum level and then heat them up to the max
operating temp. Only then can you say your timing is correct by
testing. I had to do this once when I worked with routing and timing
tools that didn't properly estimate timing... we suspected on high
fanout nets. Even when the tools said we met timing, the design could
fail on the bench and guess what made them work... cold spray! The
vendor suspected... guess what... our timing constraints! We bought a
chip heater and tested at elevated temp with a lowered Vdd and used
the worst speed chips we could find. The product shipped, but only
after many long weeks of over time!

As to not simulating, that is the lazy man carrying the heavy load.
They think it will be fewer trips, but in the end it costs dearly. I
am mostly satisfied that my designs work perfectly (except for spec
errors) when I try them on the bench. Simulation just makes life so
much easier! In fact, my simulations are as complex as the design
being tested!

Rick