FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 10-23-2003, 04:52 PM
Valentin Tihomirov
Guest
 
Posts: n/a
Default Are clock and divided clock synchronous?

Divided clock seems synchronous to original clk in terms it is stable on clk
edage. On the other hand, synchronous signals should switch simultaneusly
while divided signal is calculated on the clk egdage; hence, it switches
after Thold and the condition is not met. I understand principles of
asynchronous communication. Should I treat divided clock as an asynchronous
clock domain? Any references are appretiated.


Reply With Quote
  #2 (permalink)  
Old 10-23-2003, 08:29 PM
Peter Molesworth
Guest
 
Posts: n/a
Default Re: Are clock and divided clock synchronous?

> Divided clock seems synchronous to original clk in terms it is stable on
> clk
> edage. On the other hand, synchronous signals should switch simultaneusly
> while divided signal is calculated on the clk egdage; hence, it switches
> after Thold and the condition is not met. I understand principles of
> asynchronous communication. Should I treat divided clock as an
> asynchronous
> clock domain? Any references are appretiated.
>
>


Valentin,

For all but the simplest of designs divided clocks should be treated as
asynchronous and avoided if possible. There are several reasons for this.

1) Your divided clock will have a small delay relative to the real clock.
If you use this to clock a register which takes in a signal clocked from
the original clock domain it may be possible for the setup/hold to be
violated or data to be taken when it shouldn't have been (i.e a clock
early). I think you were implying this above.

2) If you have logic which works accross the two clock domains e.g. data
clocked from main clock domain goes through logic and is registed on
divided clock domain or vice-versa then the synthesis tool may have a hard
time performing optimization on logic in that part of the design.

3) Unless you have spare high-speed global resources in your design and
the target technology allows the connection of a register output onto
these nets (most modern fpga's are okay with this!) then the divided clock
may get routed on the normal routing nets. If you have lots of registers
driven from the divided clock the fanout may start to become significant
and hence the skew between the clock domains will get larger. If the skew
starts to become significant it then becomes more difficult to ensure that
the design will work over all temperature/voltage conditions as this will
introduce skew between registers on the divided domain aswell as between
the divided and main clock domain. To overcome this the
synthesis/place&route tools may try to insert buffers to split down the
net. This may in turn introduce more skew between some registers on your
divided net.

So to overcome these issues I would suggest trying alternative method of
coding to reduce this problem to a minimum. The way I do things if I want
a slower clock is as follows:

For example, say I want a clock that is 1/3 the system clock, I would
create a 2-bit counter that counts 0 to 2 and rolls over. When the counter
equals 2 a signal EnableDiv3 is asserted to '1' (and is '0' for all other
values). I then use this signal as a synchronous enable to the registers I
want to run a 1/3 speed but still clock the registers off the system
clock.

EnableGen : process (nReset, Clock)
begin
if (nReset = '0') then
EnableCount <= 0;
EnableDiv3 <= '0';
elsif rising_edge (Clock) then
if (EnableCount = 2) then
EnableCount <= 0;
EnableDiv3 <= '1';
else
EnableCount <= EnableCount + 1;
EnableDiv3 <= '0';
end if;
end if;
end process;

SomeRegister : process (nReset, Clock)
begin
if (nReset = '0') then
MySignalReg <= '0';
elsif rising_edge (Clock) then
if (EnableDiv3) then
MySignalReg <= MyDataValue;
else
MySignalReg <= MySignalReg;
end if;
end if;
end process;

This solves 1) and 2) above. For item 3) there is still the problem of
high fan-out on the enable signal. This will be solved by the
synthesis/place&route tool by inserting buffers. However, in this case the
registers are still clocked by the system clock so any skew on enable will
be okay so long as it dosen't violate setup/hold at the destination
registers.

I hope this is what you were asking for. If you need anything else please
let me know.

Cheers,

Pete.
Reply With Quote
  #3 (permalink)  
Old 10-23-2003, 09:47 PM
John_H
Guest
 
Posts: n/a
Default Re: Are clock and divided clock synchronous?

"Valentin Tihomirov" <[email protected]> wrote in message news:<[email protected]>...
> Divided clock seems synchronous to original clk in terms it is stable on clk
> edage. On the other hand, synchronous signals should switch simultaneusly
> while divided signal is calculated on the clk egdage; hence, it switches
> after Thold and the condition is not met. I understand principles of
> asynchronous communication. Should I treat divided clock as an asynchronous
> clock domain? Any references are appretiated.


Are you referring to a divided clock that you're generating or a
divided clock from a dedicated FPGA clocking resource?

If you're generating the clock yourself, I'd suggest generating a
one-pulse-wide enable signal every n cycles rather than a divide-by-n
clock and use
the enable for all the reduced-speed logic that would otherwise use
the divided clock. The timing tools should be able to easily apply a
multi-cycle constraint that you assiciate with the enable signal. The
only logic that needs to have short propagation delays is the enable
signal.
Reply With Quote
  #4 (permalink)  
Old 10-23-2003, 11:09 PM
Peter Molesworth
Guest
 
Posts: n/a
Default Re: Are clock and divided clock synchronous?

> if (EnableDiv3) then

Just spotted the typo! Should be (EnableDiv3 = '1').
Reply With Quote
  #5 (permalink)  
Old 10-24-2003, 10:07 AM
Matt North
Guest
 
Posts: n/a
Default Re: Are clock and divided clock synchronous?

I have always used a counter clocked on the global clk, and then used one of
the signals
that make up the counter's vector as my divided clk signal.

e.g.
signal cnt: std_logic_vector(7 downto 0);

process(...)
.....
if rising_edge(clk) then
cnt<=cnt+1;
.....
end;
--divided clk
dclk<=cnt(4);

How does the above code differ in terms of reliability or good code practice
too;

signal n: integer;

process(...)
.....
if rising_edge(clk) then
if rst='0' or n=10 then
n<=0;
else
n<=n+1;
end if;
end if;
end process;

d_clk<='0' when n<=5 else '1';
.....

Both produce divided clocks.

Matt

"Peter Molesworth" <[email protected]> wrote in message
news[email protected]
> > Divided clock seems synchronous to original clk in terms it is stable on
> > clk
> > edage. On the other hand, synchronous signals should switch

simultaneusly
> > while divided signal is calculated on the clk egdage; hence, it switches
> > after Thold and the condition is not met. I understand principles of
> > asynchronous communication. Should I treat divided clock as an
> > asynchronous
> > clock domain? Any references are appretiated.
> >
> >

>
> Valentin,
>
> For all but the simplest of designs divided clocks should be treated as
> asynchronous and avoided if possible. There are several reasons for this.
>
> 1) Your divided clock will have a small delay relative to the real clock.
> If you use this to clock a register which takes in a signal clocked from
> the original clock domain it may be possible for the setup/hold to be
> violated or data to be taken when it shouldn't have been (i.e a clock
> early). I think you were implying this above.
>
> 2) If you have logic which works accross the two clock domains e.g. data
> clocked from main clock domain goes through logic and is registed on
> divided clock domain or vice-versa then the synthesis tool may have a hard
> time performing optimization on logic in that part of the design.
>
> 3) Unless you have spare high-speed global resources in your design and
> the target technology allows the connection of a register output onto
> these nets (most modern fpga's are okay with this!) then the divided clock
> may get routed on the normal routing nets. If you have lots of registers
> driven from the divided clock the fanout may start to become significant
> and hence the skew between the clock domains will get larger. If the skew
> starts to become significant it then becomes more difficult to ensure that
> the design will work over all temperature/voltage conditions as this will
> introduce skew between registers on the divided domain aswell as between
> the divided and main clock domain. To overcome this the
> synthesis/place&route tools may try to insert buffers to split down the
> net. This may in turn introduce more skew between some registers on your
> divided net.
>
> So to overcome these issues I would suggest trying alternative method of
> coding to reduce this problem to a minimum. The way I do things if I want
> a slower clock is as follows:
>
> For example, say I want a clock that is 1/3 the system clock, I would
> create a 2-bit counter that counts 0 to 2 and rolls over. When the counter
> equals 2 a signal EnableDiv3 is asserted to '1' (and is '0' for all other
> values). I then use this signal as a synchronous enable to the registers I
> want to run a 1/3 speed but still clock the registers off the system
> clock.
>
> EnableGen : process (nReset, Clock)
> begin
> if (nReset = '0') then
> EnableCount <= 0;
> EnableDiv3 <= '0';
> elsif rising_edge (Clock) then
> if (EnableCount = 2) then
> EnableCount <= 0;
> EnableDiv3 <= '1';
> else
> EnableCount <= EnableCount + 1;
> EnableDiv3 <= '0';
> end if;
> end if;
> end process;
>
> SomeRegister : process (nReset, Clock)
> begin
> if (nReset = '0') then
> MySignalReg <= '0';
> elsif rising_edge (Clock) then
> if (EnableDiv3) then
> MySignalReg <= MyDataValue;
> else
> MySignalReg <= MySignalReg;
> end if;
> end if;
> end process;
>
> This solves 1) and 2) above. For item 3) there is still the problem of
> high fan-out on the enable signal. This will be solved by the
> synthesis/place&route tool by inserting buffers. However, in this case the
> registers are still clocked by the system clock so any skew on enable will
> be okay so long as it dosen't violate setup/hold at the destination
> registers.
>
> I hope this is what you were asking for. If you need anything else please
> let me know.
>
> Cheers,
>
> Pete.



Reply With Quote
  #6 (permalink)  
Old 10-24-2003, 02:33 PM
Valentin Tihomirov
Guest
 
Posts: n/a
Default Thank to you and Google

Stupid OE shows only your last message. Which newsreader do you use?


Reply With Quote
  #7 (permalink)  
Old 10-24-2003, 03:42 PM
MM
Guest
 
Posts: n/a
Default Re: Thank to you and Google

"Valentin Tihomirov" <[email protected]> wrote in message
news:[email protected]
> Stupid OE shows only your last message. Which newsreader do you use?


Newsreader has nothing to do with this, it's the news server that you are
connected to. You might try talking to your IP about the issue or use one of
the free servers. A very good one is news.individual.net (someone
recommended it to me earlier on this group). The only problem with it is
that you have to register and it seems that they actually have a live person
who does the registrations, so it may take 1-2 days. Their site is
http://www.individual.net/

/Mikhail


Reply With Quote
  #8 (permalink)  
Old 10-24-2003, 06:55 PM
Christos
Guest
 
Posts: n/a
Default Re: Thank to you and Google

Hi,
Did you try to press the button "headers"?
It has worked for all the people complaining at my office.!!
I am not sure why the OE does not download all messages..
But I guess it has to do something with max headers and waste of space
settings.

Anyway, hope it helps..


"MM" <[email protected]> wrote in message
news:[email protected]
> "Valentin Tihomirov" <[email protected]> wrote in message
> news:[email protected]
> > Stupid OE shows only your last message. Which newsreader do you use?

>
> Newsreader has nothing to do with this, it's the news server that you are
> connected to. You might try talking to your IP about the issue or use one

of
> the free servers. A very good one is news.individual.net (someone
> recommended it to me earlier on this group). The only problem with it is
> that you have to register and it seems that they actually have a live

person
> who does the registrations, so it may take 1-2 days. Their site is
> http://www.individual.net/
>
> /Mikhail
>
>



Reply With Quote
  #9 (permalink)  
Old 10-24-2003, 11:04 PM
Peter Molesworth
Guest
 
Posts: n/a
Default Re: Are clock and divided clock synchronous?

Matt,

In the two examples you provide below you are generating divided clocks on
dclk and then using this to clock registers in the design. This will mean
that there will be skew introduced between registers on the main clock
domain and registers on the dclk domain. This skew may become quite large
and cause problems. Also the synthesis tool will not be able to properly
optimize any logic that crosses between the two clock domains.

In the example I gave, all registers are clocked using the main global
clock. I achive the lower "clock" rate at the registers by using the
EnableDiv3 signal as a synchronous enable to the registers. This means
that there is not any excessive skew between register as they will all be
on the same low-skew clock net. The synthesis tool will be happy about
optimizing between registers passing between the fast and slow parts of
the design and to ensure the synthesis/place&route tools only optimize as
much as is required you can specify register-register paths in the low
speed parts of the design as multi cycle paths.

Cheers,

Pete.

On Fri, 24 Oct 2003 09:07:00 +0100, Matt North
<[email protected]_SPAMrl.ac.uk> wrote:

> I have always used a counter clocked on the global clk, and then used
> one of
> the signals
> that make up the counter's vector as my divided clk signal.
>
> e.g.
> signal cnt: std_logic_vector(7 downto 0);
>
> process(...)
> ....
> if rising_edge(clk) then
> cnt<=cnt+1;
> ....
> end;
> --divided clk
> dclk<=cnt(4);
>
> How does the above code differ in terms of reliability or good code
> practice
> too;
>
> signal n: integer;
>
> process(...)
> ....
> if rising_edge(clk) then
> if rst='0' or n=10 then
> n<=0;
> else
> n<=n+1;
> end if;
> end if;
> end process;
>
> d_clk<='0' when n<=5 else '1';
> ....
>
> Both produce divided clocks.
>
> Matt
>
> "Peter Molesworth" <[email protected]> wrote in message
> news[email protected]
>> > Divided clock seems synchronous to original clk in terms it is stable

>> on
>> > clk
>> > edage. On the other hand, synchronous signals should switch

> simultaneusly
>> > while divided signal is calculated on the clk egdage; hence, it

>> switches
>> > after Thold and the condition is not met. I understand principles of
>> > asynchronous communication. Should I treat divided clock as an
>> > asynchronous
>> > clock domain? Any references are appretiated.
>> >
>> >

>>
>> Valentin,
>>
>> For all but the simplest of designs divided clocks should be treated as
>> asynchronous and avoided if possible. There are several reasons for
>> this.
>>
>> 1) Your divided clock will have a small delay relative to the real
>> clock.
>> If you use this to clock a register which takes in a signal clocked from
>> the original clock domain it may be possible for the setup/hold to be
>> violated or data to be taken when it shouldn't have been (i.e a clock
>> early). I think you were implying this above.
>>
>> 2) If you have logic which works accross the two clock domains e.g. data
>> clocked from main clock domain goes through logic and is registed on
>> divided clock domain or vice-versa then the synthesis tool may have a
>> hard
>> time performing optimization on logic in that part of the design.
>>
>> 3) Unless you have spare high-speed global resources in your design and
>> the target technology allows the connection of a register output onto
>> these nets (most modern fpga's are okay with this!) then the divided
>> clock
>> may get routed on the normal routing nets. If you have lots of registers
>> driven from the divided clock the fanout may start to become significant
>> and hence the skew between the clock domains will get larger. If the
>> skew
>> starts to become significant it then becomes more difficult to ensure
>> that
>> the design will work over all temperature/voltage conditions as this
>> will
>> introduce skew between registers on the divided domain aswell as between
>> the divided and main clock domain. To overcome this the
>> synthesis/place&route tools may try to insert buffers to split down the
>> net. This may in turn introduce more skew between some registers on your
>> divided net.
>>
>> So to overcome these issues I would suggest trying alternative method of
>> coding to reduce this problem to a minimum. The way I do things if I
>> want
>> a slower clock is as follows:
>>
>> For example, say I want a clock that is 1/3 the system clock, I would
>> create a 2-bit counter that counts 0 to 2 and rolls over. When the
>> counter
>> equals 2 a signal EnableDiv3 is asserted to '1' (and is '0' for all
>> other
>> values). I then use this signal as a synchronous enable to the
>> registers I
>> want to run a 1/3 speed but still clock the registers off the system
>> clock.
>>
>> EnableGen : process (nReset, Clock)
>> begin
>> if (nReset = '0') then
>> EnableCount <= 0;
>> EnableDiv3 <= '0';
>> elsif rising_edge (Clock) then
>> if (EnableCount = 2) then
>> EnableCount <= 0;
>> EnableDiv3 <= '1';
>> else
>> EnableCount <= EnableCount + 1;
>> EnableDiv3 <= '0';
>> end if;
>> end if;
>> end process;
>>
>> SomeRegister : process (nReset, Clock)
>> begin
>> if (nReset = '0') then
>> MySignalReg <= '0';
>> elsif rising_edge (Clock) then
>> if (EnableDiv3) then
>> MySignalReg <= MyDataValue;
>> else
>> MySignalReg <= MySignalReg;
>> end if;
>> end if;
>> end process;
>>
>> This solves 1) and 2) above. For item 3) there is still the problem of
>> high fan-out on the enable signal. This will be solved by the
>> synthesis/place&route tool by inserting buffers. However, in this case
>> the
>> registers are still clocked by the system clock so any skew on enable
>> will
>> be okay so long as it dosen't violate setup/hold at the destination
>> registers.
>>
>> I hope this is what you were asking for. If you need anything else
>> please
>> let me know.
>>
>> Cheers,
>>
>> Pete.

>
>

Reply With Quote
  #10 (permalink)  
Old 10-25-2003, 01:37 AM
Peter Alfke
Guest
 
Posts: n/a
Default Re: Are clock and divided clock synchronous?

I agree with the other Peter, but I might add:
If you use the Digital Clock Manager in Virtex-II or Spartan3, you have
four outputs with practically zero skew (<100ps?)between them, and they
can be fractions or multiples of the incoming clock. When you distribute
these signals on global clocks, there will not be any hold-time caused
problems. The skew is definitely less than any clock-to-Q.
The advantage of a fractional clock is of course lower power consumption.
The problem would be clock-skew and potentially unreliable operation,
unless you use the DCM for division or multiplication (or both simultaneously!).
Peter Alfke, Xilinx Applications
=====================
Peter Molesworth wrote:
>
> Matt,
>
> In the two examples you provide below you are generating divided clocks on
> dclk and then using this to clock registers in the design. This will mean
> that there will be skew introduced between registers on the main clock
> domain and registers on the dclk domain. This skew may become quite large
> and cause problems. Also the synthesis tool will not be able to properly
> optimize any logic that crosses between the two clock domains.
>
> In the example I gave, all registers are clocked using the main global
> clock. I achive the lower "clock" rate at the registers by using the
> EnableDiv3 signal as a synchronous enable to the registers. This means
> that there is not any excessive skew between register as they will all be
> on the same low-skew clock net. The synthesis tool will be happy about
> optimizing between registers passing between the fast and slow parts of
> the design and to ensure the synthesis/place&route tools only optimize as
> much as is required you can specify register-register paths in the low
> speed parts of the design as multi cycle paths.
>
> Cheers,
>
> Pete.
>
> On Fri, 24 Oct 2003 09:07:00 +0100, Matt North
> <[email protected]_SPAMrl.ac.uk> wrote:
>
> > I have always used a counter clocked on the global clk, and then used
> > one of
> > the signals
> > that make up the counter's vector as my divided clk signal.
> >
> > e.g.
> > signal cnt: std_logic_vector(7 downto 0);
> >
> > process(...)
> > ....
> > if rising_edge(clk) then
> > cnt<=cnt+1;
> > ....
> > end;
> > --divided clk
> > dclk<=cnt(4);
> >
> > How does the above code differ in terms of reliability or good code
> > practice
> > too;
> >
> > signal n: integer;
> >
> > process(...)
> > ....
> > if rising_edge(clk) then
> > if rst='0' or n=10 then
> > n<=0;
> > else
> > n<=n+1;
> > end if;
> > end if;
> > end process;
> >
> > d_clk<='0' when n<=5 else '1';
> > ....
> >
> > Both produce divided clocks.
> >
> > Matt
> >
> > "Peter Molesworth" <[email protected]> wrote in message
> > news[email protected]
> >> > Divided clock seems synchronous to original clk in terms it is stable
> >> on
> >> > clk
> >> > edage. On the other hand, synchronous signals should switch

> > simultaneusly
> >> > while divided signal is calculated on the clk egdage; hence, it
> >> switches
> >> > after Thold and the condition is not met. I understand principles of
> >> > asynchronous communication. Should I treat divided clock as an
> >> > asynchronous
> >> > clock domain? Any references are appretiated.
> >> >
> >> >
> >>
> >> Valentin,
> >>
> >> For all but the simplest of designs divided clocks should be treated as
> >> asynchronous and avoided if possible. There are several reasons for
> >> this.
> >>
> >> 1) Your divided clock will have a small delay relative to the real
> >> clock.
> >> If you use this to clock a register which takes in a signal clocked from
> >> the original clock domain it may be possible for the setup/hold to be
> >> violated or data to be taken when it shouldn't have been (i.e a clock
> >> early). I think you were implying this above.
> >>
> >> 2) If you have logic which works accross the two clock domains e.g. data
> >> clocked from main clock domain goes through logic and is registed on
> >> divided clock domain or vice-versa then the synthesis tool may have a
> >> hard
> >> time performing optimization on logic in that part of the design.
> >>
> >> 3) Unless you have spare high-speed global resources in your design and
> >> the target technology allows the connection of a register output onto
> >> these nets (most modern fpga's are okay with this!) then the divided
> >> clock
> >> may get routed on the normal routing nets. If you have lots of registers
> >> driven from the divided clock the fanout may start to become significant
> >> and hence the skew between the clock domains will get larger. If the
> >> skew
> >> starts to become significant it then becomes more difficult to ensure
> >> that
> >> the design will work over all temperature/voltage conditions as this
> >> will
> >> introduce skew between registers on the divided domain aswell as between
> >> the divided and main clock domain. To overcome this the
> >> synthesis/place&route tools may try to insert buffers to split down the
> >> net. This may in turn introduce more skew between some registers on your
> >> divided net.
> >>
> >> So to overcome these issues I would suggest trying alternative method of
> >> coding to reduce this problem to a minimum. The way I do things if I
> >> want
> >> a slower clock is as follows:
> >>
> >> For example, say I want a clock that is 1/3 the system clock, I would
> >> create a 2-bit counter that counts 0 to 2 and rolls over. When the
> >> counter
> >> equals 2 a signal EnableDiv3 is asserted to '1' (and is '0' for all
> >> other
> >> values). I then use this signal as a synchronous enable to the
> >> registers I
> >> want to run a 1/3 speed but still clock the registers off the system
> >> clock.
> >>
> >> EnableGen : process (nReset, Clock)
> >> begin
> >> if (nReset = '0') then
> >> EnableCount <= 0;
> >> EnableDiv3 <= '0';
> >> elsif rising_edge (Clock) then
> >> if (EnableCount = 2) then
> >> EnableCount <= 0;
> >> EnableDiv3 <= '1';
> >> else
> >> EnableCount <= EnableCount + 1;
> >> EnableDiv3 <= '0';
> >> end if;
> >> end if;
> >> end process;
> >>
> >> SomeRegister : process (nReset, Clock)
> >> begin
> >> if (nReset = '0') then
> >> MySignalReg <= '0';
> >> elsif rising_edge (Clock) then
> >> if (EnableDiv3) then
> >> MySignalReg <= MyDataValue;
> >> else
> >> MySignalReg <= MySignalReg;
> >> end if;
> >> end if;
> >> end process;
> >>
> >> This solves 1) and 2) above. For item 3) there is still the problem of
> >> high fan-out on the enable signal. This will be solved by the
> >> synthesis/place&route tool by inserting buffers. However, in this case
> >> the
> >> registers are still clocked by the system clock so any skew on enable
> >> will
> >> be okay so long as it dosen't violate setup/hold at the destination
> >> registers.
> >>
> >> I hope this is what you were asking for. If you need anything else
> >> please
> >> let me know.
> >>
> >> Cheers,
> >>
> >> Pete.

> >
> >

Reply With Quote
  #11 (permalink)  
Old 10-26-2003, 05:15 AM
Jeff Cunningham
Guest
 
Posts: n/a
Default Re: Are clock and divided clock synchronous?

Peter Alfke wrote:
> If you use the Digital Clock Manager in Virtex-II or Spartan3, you have
> four outputs with practically zero skew (<100ps?)between them, and they
> can be fractions or multiples of the incoming clock. When you distribute
> these signals on global clocks, there will not be any hold-time caused
> problems. The skew is definitely less than any clock-to-Q.


Just to make sure I understand, this is NOT the case with the Spartan-2
DLL is it, i.e. the skew is not so well behaved in the DLL.

Jeff

Reply With Quote
  #12 (permalink)  
Old 10-27-2003, 09:30 AM
valentin tihomirov
Guest
 
Posts: n/a
Default Re: Are clock and divided clock synchronous?

Pressing headers does not help. I know that i need sometimes to reset (clear all messages) and redownload headers in OE. That is why I've considered missing messages as another bug. Actually, the problem is bad newserver as mikhail mentioned.
Reply With Quote
  #13 (permalink)  
Old 10-27-2003, 07:53 PM
Peter Alfke
Guest
 
Posts: n/a
Default Re: Are clock and divided clock synchronous?

DLLs ain't misbehavin' !

The DLL in Spartan-2 does not have all the functionality of the
Virtex-II and Spartan-3 DCMs, but all these circuits, even the DLL,
offer extremely low ("zero") skew between their output drivers. So I
disagree with Jeff's statement.

Peter Alfke, Xilinx Applications
=================
Jeff Cunningham wrote:
>
> Peter Alfke wrote:
> > If you use the Digital Clock Manager in Virtex-II or Spartan3, you have
> > four outputs with practically zero skew (<100ps?)between them, and they
> > can be fractions or multiples of the incoming clock. When you distribute
> > these signals on global clocks, there will not be any hold-time caused
> > problems. The skew is definitely less than any clock-to-Q.

>
> Just to make sure I understand, this is NOT the case with the Spartan-2
> DLL is it, i.e. the skew is not so well behaved in the DLL.
>
> Jeff

Reply With Quote
  #14 (permalink)  
Old 10-27-2003, 11:55 PM
Bob Perlman
Guest
 
Posts: n/a
Default Re: Are clock and divided clock synchronous?

Peter -

I don't want to put words in Ray Andraka's mouth, but I distinctly
remember him posting about the dangers of using the supposedly
low-skew outputs from the DLLs of Virtex parts. As I recall, the
problem he experienced was that jitter on the clock coming into the
part resulted in jitter on the DCM output clocks, in a way that didn't
track from clock to clock. (Such jitter could be caused by the clock
generator itself, or by SSO noise from nearby FPGA outputs.) So while
the spec for output-to-output skew is indeed low, the effects of input
clock jitter could increase these numbers. (If this is wrong, Ray,
please jump in and correct me.)

For that reason, I've always treated transfers between f and Nf
domains carefully, and I assume that rising-edge-to-rising edge
transfers won't work reliably in all cases.

So, my questions:

1) To what extent does jitter on the input clock affect DLL/DCM
output-to-output skew?

2) Is there some amount of input clock jitter below which the skew
published in the data sheets dominates? For example, for a Virtex II
part, how much jitter can I tolerate on the DCM clock input before the
DCM output-to-output phase offset exceeds the +/-140ps number in the
data sheet? (The Virtex II data sheet says that the input clock
period jitter can be as high as +/-1ns; is this just the amount of
jitter we can tolerate before losing lock, or do I get the +/-140ps
clock-to-clock output skew with this much jitter?)

Thanks,
Bob Perlman
Cambrian Design Works

On Mon, 27 Oct 2003 11:53:55 -0700, Peter Alfke <[email protected]>
wrote:

>DLLs ain't misbehavin' !
>
>The DLL in Spartan-2 does not have all the functionality of the
>Virtex-II and Spartan-3 DCMs, but all these circuits, even the DLL,
>offer extremely low ("zero") skew between their output drivers. So I
>disagree with Jeff's statement.
>
>Peter Alfke, Xilinx Applications
>=================
>Jeff Cunningham wrote:
>>
>> Peter Alfke wrote:
>> > If you use the Digital Clock Manager in Virtex-II or Spartan3, you have
>> > four outputs with practically zero skew (<100ps?)between them, and they
>> > can be fractions or multiples of the incoming clock. When you distribute
>> > these signals on global clocks, there will not be any hold-time caused
>> > problems. The skew is definitely less than any clock-to-Q.

>>
>> Just to make sure I understand, this is NOT the case with the Spartan-2
>> DLL is it, i.e. the skew is not so well behaved in the DLL.
>>
>> Jeff


Reply With Quote
  #15 (permalink)  
Old 10-28-2003, 12:29 AM
Austin Lesea
Guest
 
Posts: n/a
Default Re: Are clock and divided clock synchronous?

Bob,

The DCM ICDES expert will weigh in here.

See below,

Austin

Bob Perlman wrote:

> Peter -
>
> I don't want to put words in Ray Andraka's mouth, but I distinctly
> remember him posting about the dangers of using the supposedly
> low-skew outputs from the DLLs of Virtex parts. As I recall, the
> problem he experienced was that jitter on the clock coming into the
> part resulted in jitter on the DCM output clocks, in a way that didn't
> track from clock to clock. (Such jitter could be caused by the clock
> generator itself, or by SSO noise from nearby FPGA outputs.) So while
> the spec for output-to-output skew is indeed low, the effects of input
> clock jitter could increase these numbers. (If this is wrong, Ray,
> please jump in and correct me.)


?? Yes there is added jitter, but it is added to all outputs at the same time.

>
>
> For that reason, I've always treated transfers between f and Nf
> domains carefully, and I assume that rising-edge-to-rising edge
> transfers won't work reliably in all cases.
>
> So, my questions:
>
> 1) To what extent does jitter on the input clock affect DLL/DCM
> output-to-output skew?


Not at all. All outputs are generated by matched devices in the clock generator
output block state machine that has the delay line (taps) as its inputs.

>
> 2) Is there some amount of input clock jitter below which the skew
> published in the data sheets dominates? For example, for a Virtex II
> part, how much jitter can I tolerate on the DCM clock input before the
> DCM output-to-output phase offset exceeds the +/-140ps number in the
> data sheet? (The Virtex II data sheet says that the input clock
> period jitter can be as high as +/-1ns; is this just the amount of
> jitter we can tolerate before losing lock, or do I get the +/-140ps
> clock-to-clock output skew with this much jitter?)


The latter. You get the +/- 140 offset on top of the 1 ns noise.

One can think of the offset, or skew as DC, and the jitter as AC. On any signal,
you have the AC component which varies, and the DC component which is fixed and
does not vary for any given part.

That is why the timing budget has to treat offsets different from jitter. They
are both measures of time, but one is peak to peak white AC noise (jitter), and
the other is + or - DC offset (output skew). Adding offsets is linear (1+1=2)
while adding jitter is quadratic (1+1=1.414 or sqr(2)).

Adding RMS jitter would add arithmetically (1+1=2), but the peak to peak to RMS
ratio of designs is so hard to evaluate, that the RMS to P-P conversion factor
could be guessed to be from 3 to 14 (and still not be right). Easier to keep
everything in P-P, and do the calculations that way.

Reply With Quote
  #16 (permalink)  
Old 10-28-2003, 02:18 PM
louis lin
Guest
 
Posts: n/a
Default Re: Are clock and divided clock synchronous?


I ever implemented such divided clock design.
The derived clock (A) took data from high-speed clock domain
at A's falling edge. On the other hand, the high-speed clock put
data to derived clock domain at A's rising edge.
Besides, the area constraint was needed to limit the inter-domain
module. So the routing delay was confined.


"John_H" <[email protected]> :[email protected] .
: "Valentin Tihomirov" <[email protected]> wrote in message news:<[email protected]>...
: > Divided clock seems synchronous to original clk in terms it is stable on clk
: > edage. On the other hand, synchronous signals should switch simultaneusly
: > while divided signal is calculated on the clk egdage; hence, it switches
: > after Thold and the condition is not met. I understand principles of
: > asynchronous communication. Should I treat divided clock as an asynchronous
: > clock domain? Any references are appretiated.
:
: Are you referring to a divided clock that you're generating or a
: divided clock from a dedicated FPGA clocking resource?
:
: If you're generating the clock yourself, I'd suggest generating a
: one-pulse-wide enable signal every n cycles rather than a divide-by-n
: clock and use
: the enable for all the reduced-speed logic that would otherwise use
: the divided clock. The timing tools should be able to easily apply a
: multi-cycle constraint that you assiciate with the enable signal. The
: only logic that needs to have short propagation delays is the enable
: signal.

Reply With Quote
  #17 (permalink)  
Old 10-28-2003, 06:45 PM
John_H
Guest
 
Posts: n/a
Default Re: Are clock and divided clock synchronous?

Bob, thanks for putting the question forward so well.

Xilinx Insiders, if there is input-jitter related DCM output skew in the 1x,
2x, or DIV clocks, I'd like "reassurance" that the new JITTER constraints in
6.1i will adjust for the input-jitter induced timing skew.

If the caution we've been designing against can be a non-issue with a proper
INPUT_JITTER number, I'm a happy guy. Primarily because of this caution, I
was ecstatic to see these new constraints. If the caution we've been
designing against is a non-issue because it never was a problem (despite
apparent empirical evidence otherwise) I'm still happy though a little
confused.

I never did find out if the multiple clocks were guaranteed to use the same
delay-line tap for the common edge (versus 180 or 360 degrees out of phase).

"Bob Perlman" <[email protected]> wrote in message
news:[email protected]
> Peter -
>
> I don't want to put words in Ray Andraka's mouth, but I distinctly
> remember him posting about the dangers of using the supposedly
> low-skew outputs from the DLLs of Virtex parts. As I recall, the
> problem he experienced was that jitter on the clock coming into the
> part resulted in jitter on the DCM output clocks, in a way that didn't
> track from clock to clock. (Such jitter could be caused by the clock
> generator itself, or by SSO noise from nearby FPGA outputs.) So while
> the spec for output-to-output skew is indeed low, the effects of input
> clock jitter could increase these numbers. (If this is wrong, Ray,
> please jump in and correct me.)
>
> For that reason, I've always treated transfers between f and Nf
> domains carefully, and I assume that rising-edge-to-rising edge
> transfers won't work reliably in all cases.
>
> So, my questions:
>
> 1) To what extent does jitter on the input clock affect DLL/DCM
> output-to-output skew?
>
> 2) Is there some amount of input clock jitter below which the skew
> published in the data sheets dominates? For example, for a Virtex II
> part, how much jitter can I tolerate on the DCM clock input before the
> DCM output-to-output phase offset exceeds the +/-140ps number in the
> data sheet? (The Virtex II data sheet says that the input clock
> period jitter can be as high as +/-1ns; is this just the amount of
> jitter we can tolerate before losing lock, or do I get the +/-140ps
> clock-to-clock output skew with this much jitter?)
>
> Thanks,
> Bob Perlman
> Cambrian Design Works
>
> On Mon, 27 Oct 2003 11:53:55 -0700, Peter Alfke <[email protected]>
> wrote:
>
> >DLLs ain't misbehavin' !
> >
> >The DLL in Spartan-2 does not have all the functionality of the
> >Virtex-II and Spartan-3 DCMs, but all these circuits, even the DLL,
> >offer extremely low ("zero") skew between their output drivers. So I
> >disagree with Jeff's statement.
> >
> >Peter Alfke, Xilinx Applications
> >=================
> >Jeff Cunningham wrote:
> >>
> >> Peter Alfke wrote:
> >> > If you use the Digital Clock Manager in Virtex-II or Spartan3, you

have
> >> > four outputs with practically zero skew (<100ps?)between them, and

they
> >> > can be fractions or multiples of the incoming clock. When you

distribute
> >> > these signals on global clocks, there will not be any hold-time

caused
> >> > problems. The skew is definitely less than any clock-to-Q.
> >>
> >> Just to make sure I understand, this is NOT the case with the Spartan-2
> >> DLL is it, i.e. the skew is not so well behaved in the DLL.
> >>
> >> Jeff

>



Reply With Quote
  #18 (permalink)  
Old 10-28-2003, 08:25 PM
Austin Lesea
Guest
 
Posts: n/a
Default Re: Are clock and divided clock synchronous?

John_H,

A few comments...

Austin

John_H wrote:

> Bob, thanks for putting the question forward so well.
>
> Xilinx Insiders, if there is input-jitter related DCM output skew in the 1x,
> 2x, or DIV clocks, I'd like "reassurance" that the new JITTER constraints in
> 6.1i will adjust for the input-jitter induced timing skew.


Skew is a fixed phase offset, or error, from a nominal value. Think of it aas
DC.

Jitter is variations around the "significant instant" (ie where a perfect clock
would be). Think of it as AC. Don't mix AC and DC. They don't mix well. AC
adds RMS or peak to peak root mean square. DC adds linearly (1+1=2).

6.1i has much better software prediction of both skew and jitter (kept separate)
so that you do not have to make an Excel spreadsheet to keep track of
everything.

>
>
> If the caution we've been designing against can be a non-issue with a proper
> INPUT_JITTER number, I'm a happy guy. Primarily because of this caution, I
> was ecstatic to see these new constraints. If the caution we've been
> designing against is a non-issue because it never was a problem (despite
> apparent empirical evidence otherwise) I'm still happy though a little
> confused.


If you can state your confusion to me, I will attempt to clarify (can post, or
send to me directly).

>
>
> I never did find out if the multiple clocks were guaranteed to use the same
> delay-line tap for the common edge (versus 180 or 360 degrees out of phase).


Clocks fromt he same DCM are spec'd to arrive at their destinations when using
the global clock buffers +/- 140 ps (for example) when the destinations are all
on the same H clock tree within a few CLBs or IOBs of one another (ie removing
clock skew on the global).

>
>
> "Bob Perlman" <[email protected]> wrote in message
> news:[email protected]
> > Peter -
> >
> > I don't want to put words in Ray Andraka's mouth, but I distinctly
> > remember him posting about the dangers of using the supposedly
> > low-skew outputs from the DLLs of Virtex parts. As I recall, the
> > problem he experienced was that jitter on the clock coming into the
> > part resulted in jitter on the DCM output clocks, in a way that didn't
> > track from clock to clock. (Such jitter could be caused by the clock
> > generator itself, or by SSO noise from nearby FPGA outputs.) So while
> > the spec for output-to-output skew is indeed low, the effects of input
> > clock jitter could increase these numbers. (If this is wrong, Ray,
> > please jump in and correct me.)
> >
> > For that reason, I've always treated transfers between f and Nf
> > domains carefully, and I assume that rising-edge-to-rising edge
> > transfers won't work reliably in all cases.
> >
> > So, my questions:
> >
> > 1) To what extent does jitter on the input clock affect DLL/DCM
> > output-to-output skew?
> >
> > 2) Is there some amount of input clock jitter below which the skew
> > published in the data sheets dominates? For example, for a Virtex II
> > part, how much jitter can I tolerate on the DCM clock input before the
> > DCM output-to-output phase offset exceeds the +/-140ps number in the
> > data sheet? (The Virtex II data sheet says that the input clock
> > period jitter can be as high as +/-1ns; is this just the amount of
> > jitter we can tolerate before losing lock, or do I get the +/-140ps
> > clock-to-clock output skew with this much jitter?)
> >
> > Thanks,
> > Bob Perlman
> > Cambrian Design Works
> >
> > On Mon, 27 Oct 2003 11:53:55 -0700, Peter Alfke <[email protected]>
> > wrote:
> >
> > >DLLs ain't misbehavin' !
> > >
> > >The DLL in Spartan-2 does not have all the functionality of the
> > >Virtex-II and Spartan-3 DCMs, but all these circuits, even the DLL,
> > >offer extremely low ("zero") skew between their output drivers. So I
> > >disagree with Jeff's statement.
> > >
> > >Peter Alfke, Xilinx Applications
> > >=================
> > >Jeff Cunningham wrote:
> > >>
> > >> Peter Alfke wrote:
> > >> > If you use the Digital Clock Manager in Virtex-II or Spartan3, you

> have
> > >> > four outputs with practically zero skew (<100ps?)between them, and

> they
> > >> > can be fractions or multiples of the incoming clock. When you

> distribute
> > >> > these signals on global clocks, there will not be any hold-time

> caused
> > >> > problems. The skew is definitely less than any clock-to-Q.
> > >>
> > >> Just to make sure I understand, this is NOT the case with the Spartan-2
> > >> DLL is it, i.e. the skew is not so well behaved in the DLL.
> > >>
> > >> Jeff

> >


Reply With Quote
  #19 (permalink)  
Old 10-28-2003, 10:29 PM
Peter Alfke
Guest
 
Posts: n/a
Default Re: Are clock and divided clock synchronous?

Here is something from the other stereo channel (Austin and I often
complement each other):

Each DLL or DCM takes the rising input edge and feeds it into a very
long chain of cascaded buffers. In the background, we have a complex
calculating engine that figures out which tap should feed which output,
and it gracefully adjusts the tap setting when temperature or voltage
change. (One tap is about 50 picoseconds or less).
That's the basic mechanism, quite simple, although the implementation
takes tens of thousands of transistors.

Obviously, incoming jitter is passed through to the outputs ( delayed by
more than one period), but exactly equally to all outputs. So, there is
no added skew caused by the input jitter. If you trust the global clock
lines to distribute a clock with simultaneous arrival times at all
flip-flops, you should also trust two global lines to distribute two
different (e.g. 2:1) clocks in a similar way. No race condition...

This describes the physical action. What the timing analyzer does, and
why it does it, is not my area of expertise.

Peter Alfke
==========================
Austin Lesea wrote:
>
> John_H,
>
> A few comments...
>
> Austin
>
> John_H wrote:
>
> > Bob, thanks for putting the question forward so well.
> >
> > Xilinx Insiders, if there is input-jitter related DCM output skew in the 1x,
> > 2x, or DIV clocks, I'd like "reassurance" that the new JITTER constraints in
> > 6.1i will adjust for the input-jitter induced timing skew.

>
> Skew is a fixed phase offset, or error, from a nominal value. Think of it aas
> DC.
>
> Jitter is variations around the "significant instant" (ie where a perfect clock
> would be). Think of it as AC. Don't mix AC and DC. They don't mix well. AC
> adds RMS or peak to peak root mean square. DC adds linearly (1+1=2).
>
> 6.1i has much better software prediction of both skew and jitter (kept separate)
> so that you do not have to make an Excel spreadsheet to keep track of
> everything.
>
> >
> >
> > If the caution we've been designing against can be a non-issue with a proper
> > INPUT_JITTER number, I'm a happy guy. Primarily because of this caution, I
> > was ecstatic to see these new constraints. If the caution we've been
> > designing against is a non-issue because it never was a problem (despite
> > apparent empirical evidence otherwise) I'm still happy though a little
> > confused.

>
> If you can state your confusion to me, I will attempt to clarify (can post, or
> send to me directly).
>
> >
> >
> > I never did find out if the multiple clocks were guaranteed to use the same
> > delay-line tap for the common edge (versus 180 or 360 degrees out of phase).

>
> Clocks fromt he same DCM are spec'd to arrive at their destinations when using
> the global clock buffers +/- 140 ps (for example) when the destinations are all
> on the same H clock tree within a few CLBs or IOBs of one another (ie removing
> clock skew on the global).
>
> >
> >
> > "Bob Perlman" <[email protected]> wrote in message
> > news:[email protected]
> > > Peter -
> > >
> > > I don't want to put words in Ray Andraka's mouth, but I distinctly
> > > remember him posting about the dangers of using the supposedly
> > > low-skew outputs from the DLLs of Virtex parts. As I recall, the
> > > problem he experienced was that jitter on the clock coming into the
> > > part resulted in jitter on the DCM output clocks, in a way that didn't
> > > track from clock to clock. (Such jitter could be caused by the clock
> > > generator itself, or by SSO noise from nearby FPGA outputs.) So while
> > > the spec for output-to-output skew is indeed low, the effects of input
> > > clock jitter could increase these numbers. (If this is wrong, Ray,
> > > please jump in and correct me.)
> > >
> > > For that reason, I've always treated transfers between f and Nf
> > > domains carefully, and I assume that rising-edge-to-rising edge
> > > transfers won't work reliably in all cases.
> > >
> > > So, my questions:
> > >
> > > 1) To what extent does jitter on the input clock affect DLL/DCM
> > > output-to-output skew?
> > >
> > > 2) Is there some amount of input clock jitter below which the skew
> > > published in the data sheets dominates? For example, for a Virtex II
> > > part, how much jitter can I tolerate on the DCM clock input before the
> > > DCM output-to-output phase offset exceeds the +/-140ps number in the
> > > data sheet? (The Virtex II data sheet says that the input clock
> > > period jitter can be as high as +/-1ns; is this just the amount of
> > > jitter we can tolerate before losing lock, or do I get the +/-140ps
> > > clock-to-clock output skew with this much jitter?)
> > >
> > > Thanks,
> > > Bob Perlman
> > > Cambrian Design Works
> > >
> > > On Mon, 27 Oct 2003 11:53:55 -0700, Peter Alfke <[email protected]>
> > > wrote:
> > >
> > > >DLLs ain't misbehavin' !
> > > >
> > > >The DLL in Spartan-2 does not have all the functionality of the
> > > >Virtex-II and Spartan-3 DCMs, but all these circuits, even the DLL,
> > > >offer extremely low ("zero") skew between their output drivers. So I
> > > >disagree with Jeff's statement.
> > > >
> > > >Peter Alfke, Xilinx Applications
> > > >=================
> > > >Jeff Cunningham wrote:
> > > >>
> > > >> Peter Alfke wrote:
> > > >> > If you use the Digital Clock Manager in Virtex-II or Spartan3, you

> > have
> > > >> > four outputs with practically zero skew (<100ps?)between them, and

> > they
> > > >> > can be fractions or multiples of the incoming clock. When you

> > distribute
> > > >> > these signals on global clocks, there will not be any hold-time

> > caused
> > > >> > problems. The skew is definitely less than any clock-to-Q.
> > > >>
> > > >> Just to make sure I understand, this is NOT the case with the Spartan-2
> > > >> DLL is it, i.e. the skew is not so well behaved in the DLL.
> > > >>
> > > >> Jeff
> > >

Reply With Quote
  #20 (permalink)  
Old 10-29-2003, 04:25 AM
Jim Granville
Guest
 
Posts: n/a
Default Re: Are clock and divided clock synchronous?

Peter Alfke wrote:
>
> Here is something from the other stereo channel (Austin and I often
> complement each other):
>
> Each DLL or DCM takes the rising input edge and feeds it into a very
> long chain of cascaded buffers. In the background, we have a complex
> calculating engine that figures out which tap should feed which output,
> and it gracefully adjusts the tap setting when temperature or voltage
> change. (One tap is about 50 picoseconds or less).
> That's the basic mechanism, quite simple, although the implementation
> takes tens of thousands of transistors.

<snip>

So when this 'smart tracking' has to adjust a delay step
( due to Temp, or Vcc changes ) you will get a quantized jump
in the delay ? (50ps)
Some may call that jitter, and it depends on the HW design
how often it occurs.
With Hyst in the decision, the spectrum of the jitter can
be reduced, but note that poor Vcc behaviour can cancell the
Hyst.
It does not sound like the adjust steps are an issue from
Tsu/Th viewpoint, but they _may_ affect a system with a critical
jitter budget - such as those where jitter == signal to noise
floor.

-jg
Reply With Quote
  #21 (permalink)  
Old 10-29-2003, 04:47 AM
Jeff Cunningham
Guest
 
Posts: n/a
Default Re: Are clock and divided clock synchronous?

Google dug up the following quote from Ray back on 2003-04-21.

/quote

I got nailed on an early Virtex design where the 1x and 2x clocks were
sourced by the same DLL. Several factors contributed:
- the 1x clock was very lightly loaded while the 2x clock was heavily
loaded,
- There was fair amount of jitter on the clock input (>300ps IIRC),
- There was heavy output switching on pins adjacent to the clock input
pin (adds
to jitter at DLL clock input)
- the failing nets were on direct flip-flop to flip-flop connections (no
LUT) on
FF's that were floorplanned to be adjacent.
- static timing indicated no setup or hold violations.

The combination of the jitter (which with input jitter barely in spec
plus jitter introduced by output current modulation of input thresholds
was likely out of spec), highly skewed loading (not convinced this is a
real factor), and the absolute minimum flip-flop to flip-flop delay
conspired to bite us where it counted. Since then, we have as a policy
treated the 1x and 2x clock domains with utmost care to make sure the
receiver is not sensitive around the transmitter's active edge. I
suspect that if you have no direct connects between adjacent slices at
the clock domain boundary, you won't have a problem.

/unquote

Peter & Austin, I really want to believe you. Do you think Ray's being
overly careful? Could it be a problem in the "extreme" topology Ray
describes?

Jeff

Reply With Quote
  #22 (permalink)  
Old 10-29-2003, 08:49 AM
Tim
Guest
 
Posts: n/a
Default Re: Are clock and divided clock synchronous?

Jeff Cunningham wrote:
> Google dug up the following quote from Ray back on 2003-04-21.


<big snip>

> The combination of the jitter (which with input jitter barely in spec
> plus jitter introduced by output current modulation of input
> thresholds was likely out of spec), highly skewed loading (not
> convinced this is a real factor), and the absolute minimum flip-flop
> to flip-flop delay conspired to bite us where it counted.


As I recall this discussion and various previous analyses,
the final concensus was that hugely different loads on the
two clocks is suspect #1.

If so, is this still (!) the view at Xilinx, and if it is the
view has the clock buffering changed enough on recent products
to alter matters?


Reply With Quote
  #23 (permalink)  
Old 10-29-2003, 06:44 PM
Austin Lesea
Guest
 
Posts: n/a
Default Re: Are clock and divided clock synchronous?

Jeff,

Read my techXclusive on the web "Does Your Design Have Enough Slack" which
describes how jitter takes directly away from the slack in your timing
budget.

ISE6.1 has new ways that keep track of jitter in the new products, so that
this effect can be carefully kept track of (between clocks from different
DCMs, 1X vs 2X, etc.).

I would say that if you ignore jitter totally, and expect to operate without
any problems, and are pushing any limit (frequency, time, part utilization,
SSO limits) you will be disappointed.

This is not unique to FPGAs or even to any one vendor: it is a fact of life
that with clock periods approaching 2.5 ns in some designs, 500 ps P-P of
jitter becomes 20% of the entire timing budget!

If the system clock was 10 MHz, and the design was not too exciting, then no
one would care about 500 ps of jitter.

Austin

Jeff Cunningham wrote:

> Google dug up the following quote from Ray back on 2003-04-21.
>
> /quote
>
> I got nailed on an early Virtex design where the 1x and 2x clocks were
> sourced by the same DLL. Several factors contributed:
> - the 1x clock was very lightly loaded while the 2x clock was heavily
> loaded,
> - There was fair amount of jitter on the clock input (>300ps IIRC),
> - There was heavy output switching on pins adjacent to the clock input
> pin (adds
> to jitter at DLL clock input)
> - the failing nets were on direct flip-flop to flip-flop connections (no
> LUT) on
> FF's that were floorplanned to be adjacent.
> - static timing indicated no setup or hold violations.
>
> The combination of the jitter (which with input jitter barely in spec
> plus jitter introduced by output current modulation of input thresholds
> was likely out of spec), highly skewed loading (not convinced this is a
> real factor), and the absolute minimum flip-flop to flip-flop delay
> conspired to bite us where it counted. Since then, we have as a policy
> treated the 1x and 2x clock domains with utmost care to make sure the
> receiver is not sensitive around the transmitter's active edge. I
> suspect that if you have no direct connects between adjacent slices at
> the clock domain boundary, you won't have a problem.
>
> /unquote
>
> Peter & Austin, I really want to believe you. Do you think Ray's being
> overly careful? Could it be a problem in the "extreme" topology Ray
> describes?
>
> Jeff


Reply With Quote
  #24 (permalink)  
Old 10-29-2003, 06:46 PM
Austin Lesea
Guest
 
Posts: n/a
Default Re: Are clock and divided clock synchronous?

Tim,

Since Virtex everything is fully buffered, Loads can change the timing, but
only very slightly (10s of ps MAX), and not much at all on global clock
buffers.

What gets folks in trouble is what I answered in my other post on this
thread: they fail to see what their total system jitter is, and add that
to the amount of slack they need.

Austin

Tim wrote:

> Jeff Cunningham wrote:
> > Google dug up the following quote from Ray back on 2003-04-21.

>
> <big snip>
>
> > The combination of the jitter (which with input jitter barely in spec
> > plus jitter introduced by output current modulation of input
> > thresholds was likely out of spec), highly skewed loading (not
> > convinced this is a real factor), and the absolute minimum flip-flop
> > to flip-flop delay conspired to bite us where it counted.

>
> As I recall this discussion and various previous analyses,
> the final concensus was that hugely different loads on the
> two clocks is suspect #1.
>
> If so, is this still (!) the view at Xilinx, and if it is the
> view has the clock buffering changed enough on recent products
> to alter matters?


Reply With Quote
  #25 (permalink)  
Old 10-29-2003, 07:11 PM
Peter Alfke
Guest
 
Posts: n/a
Default Re: Are clock and divided clock synchronous?



Jim Granville wrote:
> It does not sound like the adjust steps are an issue from
> Tsu/Th viewpoint, but they _may_ affect a system with a critical
> jitter budget - such as those where jitter == signal to noise
> floor.
>

Jim, if your design is sensitive to 50 ps jitter, it needs an external
clean-up PLL.
Inside a digital chip there will always be some jitter, and on-chip PLL
are not so good either. Jitter is noise in the time domain, and digital
circuits are inherently noisy...

Peter Alfke
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Single clock pulse transfer b/w clock domain himassk Verilog 3 05-18-2007 08:10 AM
Generation of Divided-by-3 clock K. Sudheer Kumar Verilog 3 01-19-2007 03:14 PM


All times are GMT +1. The time now is 07:47 PM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved