Are clock and divided clock synchronous?

Discussion in 'VHDL' started by Valentin Tihomirov, Oct 23, 2003.

  1. 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 Tihomirov, Oct 23, 2003
    #1
    1. Advertising

  2. > 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.
     
    Peter Molesworth, Oct 23, 2003
    #2
    1. Advertising

  3. Valentin Tihomirov

    John_H Guest

    "Valentin Tihomirov" <> wrote in message news:<3f97eb7a$>...
    > 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.
     
    John_H, Oct 23, 2003
    #3
  4. > if (EnableDiv3) then

    Just spotted the typo! Should be (EnableDiv3 = '1').
     
    Peter Molesworth, Oct 23, 2003
    #4
  5. Valentin Tihomirov

    Matt North Guest

    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" <> wrote in message
    news:eek:...
    > > 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.
     
    Matt North, Oct 24, 2003
    #5
  6. Thank to you and Google

    Stupid OE shows only your last message. Which newsreader do you use?
     
    Valentin Tihomirov, Oct 24, 2003
    #6
  7. Valentin Tihomirov

    MM Guest

    Re: Thank to you and Google

    "Valentin Tihomirov" <> wrote in message
    news:3f991c5a$...
    > 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
     
    MM, Oct 24, 2003
    #7
  8. Valentin Tihomirov

    Christos Guest

    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" <> wrote in message
    news:bnba40$vd0oq$-berlin.de...
    > "Valentin Tihomirov" <> wrote in message
    > news:3f991c5a$...
    > > 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
    >
    >
     
    Christos, Oct 24, 2003
    #8
  9. 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" <> wrote in message
    > news:eek:...
    >> > 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.

    >
    >
     
    Peter Molesworth, Oct 24, 2003
    #9
  10. 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" <> wrote in message
    > news:eek:...
    >> > 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.
     
    Peter Molesworth, Oct 24, 2003
    #10
  11. Valentin Tihomirov

    Peter Alfke Guest

    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" <> wrote in message
    > > news:eek:...
    > >> > 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.

    > >
    > >
     
    Peter Alfke, Oct 25, 2003
    #11
  12. Valentin Tihomirov

    louis lin Guest

    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" <> :...
    : "Valentin Tihomirov" <> wrote in message news:<3f97eb7a$>...
    : > 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.
     
    louis lin, Oct 28, 2003
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Metin Yerlikaya

    an alternative method to do divided clocks

    Metin Yerlikaya, Feb 15, 2005, in forum: VHDL
    Replies:
    4
    Views:
    642
    John_H
    Feb 15, 2005
  2. Praveen
    Replies:
    2
    Views:
    882
    Bert Cuzeau
    Apr 12, 2005
  3. Dos-Man
    Replies:
    5
    Views:
    1,263
    Augustus
    Mar 4, 2004
  4. ImpalerCore
    Replies:
    0
    Views:
    843
    ImpalerCore
    Mar 10, 2011
  5. Rickert
    Replies:
    0
    Views:
    672
    Rickert
    Oct 6, 2011
Loading...

Share This Page