On HDL Synthesis

Discussion in 'VHDL' started by devices, Jun 25, 2007.

  1. devices

    devices Guest

    I was trying to detect a start (or stop) condition (i2c).
    A first approach consisted in "always @ (negedge isda)"
    and setting a flag accordingly. The simulation woked.
    When i wanted to check whether the module were
    synthesizable the troubles began. No error, actually.
    But the warnings were serious. The Timing Analysis
    started to blame it on Ripple Clocks, Gated Clocks
    and mostly on Clock skews. I fixed things by deploying
    the common "always @ (posedge clk)" and detecting
    the edges. I would like to know what happens behind
    the scenes when a synthesis tool comes across a case
    like the first "always" i listed.
     
    devices, Jun 25, 2007
    #1
    1. Advertising

  2. devices wrote:
    > I was trying to detect a start (or stop) condition (i2c).
    > A first approach consisted in "always @ (negedge isda)"


    That's verilog.
    You probably want a synchronous always block.
    Try comp.lang.verilog
    See also pg 6-55
    http://www.altera.com/literature/hb/qts/qts_qii51007.pdf
     
    Mike Treseler, Jun 25, 2007
    #2
    1. Advertising

  3. devices

    Peter Guest

    On 25 Juni, 02:07, "devices" <me@home> wrote:
    > I was trying to detect a start (or stop) condition (i2c).
    > A first approach consisted in "always @ (negedge isda)"
    > and setting a flag accordingly. The simulation woked.
    > When i wanted to check whether the module were
    > synthesizable the troubles began. No error, actually.
    > But the warnings were serious. The Timing Analysis
    > started to blame it on Ripple Clocks, Gated Clocks
    > and mostly on Clock skews. I fixed things by deploying
    > the common "always @ (posedge clk)" and detecting
    > the edges. I would like to know what happens behind
    > the scenes when a synthesis tool comes across a case
    > like the first "always" i listed.


    Use a common clock and sample SDA and SCL (with synchronising
    registers) as data, into a start/stop detector, instead of using SDA
    as a clock.

    /Peter
     
    Peter, Jun 25, 2007
    #3
  4. devices

    devices Guest

    Thanks for the link. I collected lots of info about coding style.
    The one you show was not in my list.

    > That's verilog.
    > Try comp.lang.verilog


    My issue was independent of the language that's why i
    simply referred to it as HDL. I guess that that kind of
    clock skew issue might arise whathever language you
    use. I saw examples where the rising or falling edge of
    SDA or a registered version of it drove a VDHL process.
    I was just wondering what was inferred in such a case.

    > You probably want a synchronous always block.

    Using "posedge clk" i've already made it synchronous.
     
    devices, Jun 25, 2007
    #4
  5. devices

    devices Guest

    "Peter" <> wrote in message
    news:...
    > On 25 Juni, 02:07, "devices" <me@home> wrote:
    > > I was trying to detect a start (or stop) condition (i2c).
    > > A first approach consisted in "always @ (negedge isda)"
    > > and setting a flag accordingly. The simulation woked.
    > > When i wanted to check whether the module were
    > > synthesizable the troubles began. No error, actually.
    > > But the warnings were serious. The Timing Analysis
    > > started to blame it on Ripple Clocks, Gated Clocks
    > > and mostly on Clock skews. I fixed things by deploying
    > > the common "always @ (posedge clk)" and detecting
    > > the edges. I would like to know what happens behind
    > > the scenes when a synthesis tool comes across a case
    > > like the first "always" i listed.

    >
    > Use a common clock and sample SDA and SCL (with synchronising
    > registers) as data, into a start/stop detector, instead of using SDA
    > as a clock.


    That's what i did when i used the "posedge clk".
    It behaves more or less like: "process(clk)" plus
    "if (clk='1' and clk'event) ..." or "if rising_edge(clk) ..."
     
    devices, Jun 25, 2007
    #5
  6. "devices" <me@home> wrote in message
    news:467fd623$0$10620$...
    >
    > "Peter" <> wrote in message
    > news:...
    >> On 25 Juni, 02:07, "devices" <me@home> wrote:
    >> > I was trying to detect a start (or stop) condition (i2c).
    >> > A first approach consisted in "always @ (negedge isda)"
    >> > and setting a flag accordingly. The simulation woked.
    >> > When i wanted to check whether the module were
    >> > synthesizable the troubles began. No error, actually.
    >> > But the warnings were serious. The Timing Analysis
    >> > started to blame it on Ripple Clocks, Gated Clocks
    >> > and mostly on Clock skews. I fixed things by deploying
    >> > the common "always @ (posedge clk)" and detecting
    >> > the edges. I would like to know what happens behind
    >> > the scenes when a synthesis tool comes across a case
    >> > like the first "always" i listed.

    >>
    >> Use a common clock and sample SDA and SCL (with synchronising
    >> registers) as data, into a start/stop detector, instead of using SDA
    >> as a clock.

    >
    > That's what i did when i used the "posedge clk".
    > It behaves more or less like: "process(clk)" plus
    > "if (clk='1' and clk'event) ..." or "if rising_edge(clk) ..."


    Yes, but 'posedge clk' in Verilog and "process(clk)" plus "if (clk='1' and
    clk'event) ..." or "if rising_edge(clk) ..." in VHDL should be apply only to
    clock signals. It is not the way u can detect the change of signal level. As
    Peter said u should sample this signal.

    --
    Maciek Wojtynski
     
    Macias Wojtas, Jun 25, 2007
    #6
  7. devices

    devices Guest

    "Macias Wojtas" <> wrote in message
    news:f5ot8n$as$...
    >
    > "devices" <me@home> wrote in message
    > news:467fd623$0$10620$...
    > >
    > > "Peter" <> wrote in message
    > > news:...
    > >> On 25 Juni, 02:07, "devices" <me@home> wrote:
    > >> > I was trying to detect a start (or stop) condition (i2c).
    > >> > A first approach consisted in "always @ (negedge isda)"
    > >> > and setting a flag accordingly. The simulation woked.
    > >> > When i wanted to check whether the module were
    > >> > synthesizable the troubles began. No error, actually.
    > >> > But the warnings were serious. The Timing Analysis
    > >> > started to blame it on Ripple Clocks, Gated Clocks
    > >> > and mostly on Clock skews. I fixed things by deploying
    > >> > the common "always @ (posedge clk)" and detecting
    > >> > the edges. I would like to know what happens behind
    > >> > the scenes when a synthesis tool comes across a case
    > >> > like the first "always" i listed.
    > >>
    > >> Use a common clock and sample SDA and SCL (with synchronising
    > >> registers) as data, into a start/stop detector, instead of using SDA
    > >> as a clock.

    > >
    > > That's what i did when i used the "posedge clk".
    > > It behaves more or less like: "process(clk)" plus
    > > "if (clk='1' and clk'event) ..." or "if rising_edge(clk) ..."

    >
    > Yes, but 'posedge clk' in Verilog and "process(clk)" plus "if (clk='1' and
    > clk'event) ..." or "if rising_edge(clk) ..." in VHDL should be apply only

    to
    > clock signals. It is not the way u can detect the change of signal level.

    As
    > Peter said u should sample this signal.
    >
    > --
    > Maciek Wojtynski


    When did i say that CLK is the same as ISDA?

    I stated two cases:

    1) always @ (negedge isda)
    which gave warnings

    2) always @ (posedge clk)
    which, as i said, fixed the issue.

    in the second case i did the detection by
    comparing the new and old sample.
     
    devices, Jun 26, 2007
    #7
  8. > When did i say that CLK is the same as ISDA?
    >
    > I stated two cases:
    >
    > 1) always @ (negedge isda)
    > which gave warnings
    >
    > 2) always @ (posedge clk)
    > which, as i said, fixed the issue.
    >
    > in the second case i did the detection by
    > comparing the new and old sample.


    U didn't said that isda was a the same as clk. I said that u can apply
    'always @ (negedge xxx)' only to clock signal. Usually in FPGAs there is
    only one dedicated clock line that's why when u try to use more then one
    clock synthesis gives u warnings.

    When in the same project u use always @ (posedge signal1) and always @
    (posedge signal2) this require 2 clock lines - maybe this is your problem.



    Best regards

    Maciek Wojtynski
     
    Macias Wojtas, Jun 27, 2007
    #8
  9. devices

    devices Guest

    > U didn't said that isda was a the same as clk. I said that u can apply
    > 'always @ (negedge xxx)' only to clock signal. Usually in FPGAs there is
    > only one dedicated clock line that's why when u try to use more then one
    > clock synthesis gives u warnings.
    >
    > When in the same project u use always @ (posedge signal1) and always @
    > (posedge signal2) this require 2 clock lines - maybe this is your problem.
    >
    >
    >
    > Best regards
    >
    > Maciek Wojtynski
    >


    With both clk and isda as clocking signals, the timing
    analyzer computed the shortest and longest path, the
    shortest and longest delay and, as a warning, concluded
    that the circuit may not operate.

    Here's an explanation (though it has nothing to do with
    the edge detection)

    http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/03639c3b868fb8d6/6e1f8e28a059f3d3
     
    devices, Jun 28, 2007
    #9
  10. devices

    Andy Peters Guest

    On Jun 27, 7:41 am, "Macias Wojtas" <> wrote:

    > U didn't said that isda was a the same as clk. I said that u can apply
    > 'always @ (negedge xxx)' only to clock signal. Usually in FPGAs there is
    > only one dedicated clock line that's why when u try to use more then one
    > clock synthesis gives u warnings.


    What's this "u" thing??

    Your information about "only one dedicated clock line" in FPGAs is
    waaaaay out of date.

    -a
     
    Andy Peters, Jul 3, 2007
    #10
  11. devices

    Andy Peters Guest

    On Jun 28, 3:04 am, "devices" <me@home> wrote:
    > > U didn't said that isda was a the same as clk. I said that u can apply
    > > 'always @ (negedge xxx)' only to clock signal. Usually in FPGAs there is
    > > only one dedicated clock line that's why when u try to use more then one
    > > clock synthesis gives u warnings.

    >
    > > When in the same project u use always @ (posedge signal1) and always @
    > > (posedge signal2) this require 2 clock lines - maybe this is your problem.

    >
    > > Best regards

    >
    > > Maciek Wojtynski

    >
    > With both clk and isda as clocking signals, the timing
    > analyzer computed the shortest and longest path, the
    > shortest and longest delay and, as a warning, concluded
    > that the circuit may not operate.


    Why two clocks?

    -a
     
    Andy Peters, Jul 3, 2007
    #11
  12. devices

    devices Guest

    "Andy Peters" <> wrote in message
    news:...

    > > With both clk and isda as clocking signals, the timing
    > > analyzer computed the shortest and longest path, the
    > > shortest and longest delay and, as a warning, concluded
    > > that the circuit may not operate.

    >
    > Why two clocks?
    >
    > -a


    ISDA is used locally to drive a flip flop clock. I
    needed to detect its edges. Well, a flip flop clock
    input would do that. The falling and rising edges of
    SDA, in i2c, trigger the start and end conditions while
    SCL holds high. So once the always block is triggered,
    to detected the condition is just a matter of checking
    SCL. I didn't invent anything. I had an application note
    where the edges of SDA and mostly SCL were used
    like that. I don't remember the AppNote case, but in
    my case ISDA is internally generated (that's why
    I-SDA) by my humble i2c master. I'm using the
    Quartus II timing analyzer and i guess the ISDA's way
    of driving the flip flop is what Altera calls a Registered
    Clock and the analyzer might complain with warnings.

    I'm not really interested in the ISDA thing now (as
    i said i ended up in using a synchronous edge detector),
    but i find that with Quartus' timing analyzer this kind of
    issues arises frequently, even with clock dividers. Altera
    explains why:

    http://www.altera.com/literature/wp/wp_timingAnalysis.pdf

    The key concept of the document is that the analyzer
    does its best to check every possible issue in timing.
    I guess that some of the warnings might be ignored or
    you could instruct the analyzer on what you are doing
    by setting up the analysis with detailed contraints. I'll
    have to find out a way (or a way out :) to set a threshold
    above or under which i can shrug my shoulder.

    --
     
    devices, Jul 3, 2007
    #12
  13. devices

    devices Guest

    "devices" <me@home> wrote in message
    news:468a5de0$0$36441$...

    > I'm not really interested in the ISDA thing now (as
    > i said i ended up in using a synchronous edge detector),
    > but i find that with Quartus' timing analyzer this kind of
    > issues arises frequently, even with clock dividers. Altera
    > explains why:
    >
    > http://www.altera.com/literature/wp/wp_timingAnalysis.pdf
    >
    > The key concept of the document is that the analyzer
    > does its best to check every possible issue in timing.
    > I guess that some of the warnings might be ignored or
    > you could instruct the analyzer on what you are doing
    > by setting up the analysis with detailed contraints. I'll
    > have to find out a way (or a way out :) to set a threshold
    > above or under which i can shrug my shoulder.



    I've finally managed to make the Analyzer smile.
    As i said, either you ignore the warnings or you declare
    all the clocks and their operating points in the setup.

    I decided to provide the details to Analizer's setup.

    1) system clk
    2) pll clk (i don't need it right now. Just a test)
    3) baud rate generator (baud*16)

    That's ok.

    In this case if i had ignored the warnings it would have
    been the same, but i wanted to gain some knowledge.

    NOTES

    1) I had already specified the details for the system clk.

    2) The pll clk doesn't drive anything at the moment (no
    warning anyway).

    3) The baud rate generator used to give me warnings.
    Working like a clock divider it was detected as a Ripple
    Clock. The Analizer detected it as a clock but had no info
    about it, so according to its own calculation it reported some
    hold time violation. Now that i provided its parameters i get
    no more warnings.
     
    devices, Jul 4, 2007
    #13
    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. walala
    Replies:
    4
    Views:
    2,175
    Ralf Hildebrandt
    Sep 8, 2003
  2. walala
    Replies:
    4
    Views:
    1,269
    Technology Consultant
    Sep 9, 2003
  3. bxbxb3

    mixed hdl synthesis

    bxbxb3, Mar 23, 2005, in forum: VHDL
    Replies:
    2
    Views:
    518
    bxbxb3
    Mar 29, 2005
  4. Replies:
    1
    Views:
    611
    Ralf Hildebrandt
    Nov 7, 2007
  5. digital pig

    HDL - simulation vs synthesis

    digital pig, May 28, 2008, in forum: VHDL
    Replies:
    1
    Views:
    568
    digital pig
    May 29, 2008
Loading...

Share This Page