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

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > VHDL

VHDL comp.lang.vhdl newsgroup / Usenet

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 10-23-2003, 03: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, 07: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, 08: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, 10: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, 09: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, 01: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, 02: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, 05: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, 10: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-24-2003, 10:07 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
  #11 (permalink)  
Old 10-25-2003, 12: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
  #12 (permalink)  
Old 10-28-2003, 01: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]ews.estpak.ee>...
: > 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
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
Deskew Clock on Synchronous Bus Bill Ngo FPGA 4 06-10-2008 05:58 PM
Generation of Divided-by-3 clock K. Sudheer Kumar FPGA 10 01-19-2007 02:14 PM
Generation of Divided-by-3 clock K. Sudheer Kumar Verilog 3 01-19-2007 02:14 PM
Are clock and divided clock synchronous? Valentin Tihomirov FPGA 24 10-29-2003 06:11 PM


All times are GMT +1. The time now is 02:34 AM.


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