Are clock and divided clock synchronous?

V

Valentin Tihomirov

Guest
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.
 
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.
Click to expand...
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.
 
"Valentin Tihomirov" <valentin@abelectron.com> wrote in message news:<3f97eb7a$1_1@news.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.
Click to expand...
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.
 
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" <noemail@anonymous.net> wrote in message
news:eek:prxidmzi40ve4v7@news.tiscali.co.uk...
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.
Click to expand...
 
Stupid OE shows only your last message. Which newsreader do you use?
 
"Valentin Tihomirov" <valentin@abelectron.com> wrote in message
news:3f991c5a$1_1@news.estpak.ee...
Stupid OE shows only your last message. Which newsreader do you use?
Click to expand...
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
 
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" <mbmsv@yahoo.com> wrote in message
news:bnba40$vd0oq$1@ID-204311.news.uni-berlin.de...
"Valentin Tihomirov" <valentin@abelectron.com> wrote in message
news:3f991c5a$1_1@news.estpak.ee...
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
Click to expand...
 
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
<m.r.w.north@NO_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" <noemail@anonymous.net> wrote in message
news:eek:prxidmzi40ve4v7@news.tiscali.co.uk...
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.
Click to expand...
 
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
<m.r.w.north@NO_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" <noemail@anonymous.net> wrote in message
news:eek:prxidmzi40ve4v7@news.tiscali.co.uk...
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.
Click to expand...
 
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
m.r.w.north@NO_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" <noemail@anonymous.net> wrote in message
news:eek:prxidmzi40ve4v7@news.tiscali.co.uk...
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.
Click to expand...
 
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" <johnhandwork@mail.com> :6c803f5f.0310231147.7e129cbe@posting.google.com...
: "Valentin Tihomirov" <valentin@abelectron.com> wrote in message news:<3f97eb7a$1_1@news.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.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top