timing ...

Discussion in 'VHDL' started by Amit, Mar 13, 2008.

  1. Amit

    Amit Guest

    Hello group,

    Is there any good resource or book to learn timing? or maybe there is
    a method that I can use.

    Your response is appreciated.

    Regards,
    Amit
     
    Amit, Mar 13, 2008
    #1
    1. Advertising

  2. Amit

    Guest

    On Mar 12, 11:48 pm, Amit <> wrote:
    > Hello group,
    >
    > Is there any good resource or book to learn timing? or maybe there is
    > a method that I can use.
    >
    > Your response is appreciated.
    >
    > Regards,
    > Amit


    You could try Einstein's "Relativity: The Special and the General
    Theory". It's cheap (available in paperback for about $15) and written
    at a fairly introductory level. It lays out the basic framework of
    time as it is understood by most modern physicicsts.

    But seriously, your question is so broad that you would best ask a
    more specific question.

    - Kenn
     
    , Mar 13, 2008
    #2
    1. Advertising

  3. Mike Treseler, Mar 13, 2008
    #3
  4. Amit

    Amit Guest

    On Mar 13, 8:40 am, Mike Treseler <> wrote:
    > Amit wrote:
    > > Is there any good resource or book to learn timing? or maybe there is
    > > a method that I can use.

    >
    > http://www.altera.com/literature/hb/qts/qts_qii53004.pdf



    Thanks to both of you for the answers. Specially to Mike. Ok, Kenn let
    me be more clear you are right. I'm in a transition from software to
    digital design field and of course I'm not that familiar with terms
    yet and I apologize for using some wrong or very general terms.

    Now, in this learning process I have given a project to read some
    music files which seemed doable and have done it by now (except some
    minor changes I have to apply). Next, step is reading the raw data
    (music) and sending them to a Wolson WM8731 CODEC and FIFO. Here is my
    nightmare; This CODEC has some timing theory which sounds very hard
    page 15 at http://www.wolfsonmicro.com/uploads/documents/en/WM8731.pdf.

    I have few days to understand this timing thing and implement it using
    VHDL in Quratus II. I have no idea how to start it. I would love to
    learn this concept and impelement it so desperately looking for a way
    to understand how these things work.

    It seems the pdf sent by Mike is helpful and I will look at it for
    sure. Once again thanks and I will appreicate it if somebody could
    help.

    Thanks!
     
    Amit, Mar 14, 2008
    #4
  5. Amit

    KJ Guest

    "Amit" <> wrote in message
    news:...
    > Now, in this learning process I have given a project to read some
    > music files which seemed doable and have done it by now (except some
    > minor changes I have to apply). Next, step is reading the raw data
    > (music) and sending them to a Wolson WM8731 CODEC and FIFO. Here is my
    > nightmare; This CODEC has some timing theory which sounds very hard
    > page 15 at http://www.wolfsonmicro.com/uploads/documents/en/WM8731.pdf.
    >
    > I have few days to understand this timing thing and implement it using
    > VHDL in Quratus II. I have no idea how to start it. I would love to
    > learn this concept and impelement it so desperately looking for a way
    > to understand how these things work.


    You have your work cut out for you then. The fundamental ideas you need to
    grasp are
    1. Nothing happens instantaneously, there will always be some delay/skew
    between any two signals
    2. No delay/skew is completely predictable so there will always be some
    uncertainty in the actual device delay
    3. In order to work properly, most parts have some timing requirements that
    need to be met.

    The spec sheets defines the parameters for a particular device. An example
    of #1 and #2 in your referenced spec is Figure 2 where the waveform and
    parameter table define Tcop as being the delay from the input signal
    'XTI/MCLK' to the output signal 'CLKOUT'. This delay has a minimum of 0 ns
    and a maximum of 10 ns. What this means is that an edge on CLKOUT will be
    skewed from an edge on XTI/MCLK by anywhere from 0 to 10 ns. Maybe you care
    about that skew, maybe you don't, it is simply saying what to expect from
    the device. This particular type of parameter is generally referred to as a
    propogation delay.

    Figure 4 shows examples of #1, #2 and #3. Parameters Tdl and Tdda define
    the skew between the outputs ADCLRC, DAD/LRC, ADCDAT relative to the falling
    edge of BCLK. Just like the Figure 15 example it is simply stating what the
    part will do and is an example of #1 and #2. Since the output delays are
    referenced to what appears to be a clock, this type of parameter is
    generally referred to as 'clock to output' delay.

    The parameters Tdst and Tdht on that same figure are an example of #3, which
    is a requirement that you must meet in order for the part to work correctly.
    That figure implies that the input DACDAT is an input that gets sampled on
    the rising edge of BCLK. Again, real parts are not able to sample things
    instantaneously, the thing that is being sampled (in this case DACDAT) must
    be stable for some period of time (in this case Tdst) before the rising edge
    of the thing that samples it (in this case BCLK) and must hold it stable for
    some period of time after that rising edge of BCLK (in this case Tdht). In
    order for the part to work correctly, whatever it is that connects to these
    inputs must meet these requirements otherwise there is (in general) no way
    to know what the part will do. Those two parameters are generally referred
    to as setup time (Tdst) and hold time (Tdht).

    It's also important to pay attention to the test conditions that are listed
    with each figure. 'Most' of the time, those conditions are similar enough
    to what you'll actually have in your design that the listed numbers will be
    applicable, but not always and strictly speaking all those timing parameters
    only apply to that test condition.

    You'll also want to guard your design somewhat and leave a few ns of margin
    so that if you have a requirement to have the signal stable 10ns before some
    clock that the signal arrives there maybe 12-15 ns or so before. There are
    a lot of electrical things that have to go on to get that signal there, and
    most of them don't make the signal look like the nice square-ish waves shown
    in a timing diagram.

    Good luck.

    Kevin Jennings
     
    KJ, Mar 14, 2008
    #5
  6. Amit wrote:

    > I have few days to understand this timing thing and implement it using
    > VHDL in Quratus II. I have no idea how to start it. I would love to
    > learn this concept and impelement it so desperately looking for a way
    > to understand how these things work.


    Start with simplified prototypes and work them
    through description and simulation. Have a look on
    the rtl viewer. Repeat. It will take a few months
    more than a few days. Good luck.

    -- Mike
     
    Mike Treseler, Mar 14, 2008
    #6
  7. Amit

    Guest

    On Mar 14, 10:46 am, Mike Treseler <> wrote:
    > Amit wrote:
    > > I have few days to understand this timing thing and implement it using
    > > VHDL in Quratus II. I have no idea how to start it. I would love to
    > > learn this concept and impelement it so desperately looking for a way
    > > to understand how these things work.

    >
    > Start with simplified prototypes and work them
    > through description and simulation. Have a look on
    > the rtl viewer. Repeat. It will take a few months
    > more than a few days. Good luck.
    >
    > -- Mike


    Mike and Kevin are bang on with their advice. But before you start
    thinking all is lost... let's assume that you're just trying to hack
    something up for your own home use, and the clock speed is fairly low.
    Then you can usually cut a few corners and not get too hung up on
    timing. For a good chunk of chips, you can look at the data sheet and
    see that the timing looks good if you either send data on rising or
    falling edge of your main clock, and you can usually latch returned
    data on the rising or falling edge of the same clock. You'll still
    need to understand prop delay out of your FPGA, but it's a simplifying
    case. As long as you keep the messy stuff (front edge/back edge
    clocks, or extra setup & hold requirements that you might apply to as
    timing constraints to the place & route tools) isolated from the core
    of your main design, you can usually separate your design into easier-
    to-manage sections. You can debug the core state machines in RTL
    through simulation, and then integrate the interface pins to the core
    logic afterwards. Of course, having a scope or an embedded logic
    analyser will help a lot, too.

    Disclaimer: if you get *paid* to design logic, you certainly deserve
    all the grief that will come your way should you cut corners on
    timing :)

    Just try it out, hopefully you'll learn something useful & have some
    fun.

    - Kenn
     
    , Mar 15, 2008
    #7
  8. Amit

    Amit Guest

    On Mar 14, 6:59 pm, wrote:
    > On Mar 14, 10:46 am, Mike Treseler <> wrote:
    >
    > > Amit wrote:
    > > > I have few days to understand this timing thing and implement it using
    > > > VHDL in Quratus II. I have no idea how to start it. I would love to
    > > > learn this concept and impelement it so desperately looking for a way
    > > > to understand how these things work.

    >
    > > Start with simplified prototypes and work them
    > > through description and simulation. Have a look on
    > > the rtl viewer. Repeat. It will take a few months
    > > more than a few days. Good luck.

    >
    > > -- Mike

    >
    > Mike and Kevin are bang on with their advice. But before you start
    > thinking all is lost... let's assume that you're just trying to hack
    > something up for your own home use, and the clock speed is fairly low.
    > Then you can usually cut a few corners and not get too hung up on
    > timing. For a good chunk of chips, you can look at the data sheet and
    > see that the timing looks good if you either send data on rising or
    > falling edge of your main clock, and you can usually latch returned
    > data on the rising or falling edge of the same clock. You'll still
    > need to understand prop delay out of your FPGA, but it's a simplifying
    > case. As long as you keep the messy stuff (front edge/back edge
    > clocks, or extra setup & hold requirements that you might apply to as
    > timing constraints to the place & route tools) isolated from the core
    > of your main design, you can usually separate your design into easier-
    > to-manage sections. You can debug the core state machines in RTL
    > through simulation, and then integrate the interface pins to the core
    > logic afterwards. Of course, having a scope or an embedded logic
    > analyser will help a lot, too.
    >
    > Disclaimer: if you get *paid* to design logic, you certainly deserve
    > all the grief that will come your way should you cut corners on
    > timing :)
    >
    > Just try it out, hopefully you'll learn something useful & have some
    > fun.
    >
    > - Kenn


    Thanks to everybody for helping me to start understanding the concept
    BUT I have questions for each one of you and will appreciate it if you
    give a response.

    __________________
    Questio for Kevin:

    It was so nice that you went thru those pages and explained them to
    me. I followed your statements as I was going thru those pages. Now, I
    think I know what I should do (after reviewig these again). My
    question for you is "What is the next step? after understanding the
    timing/delays ?" let's say I want to control the clock and get the
    output expected in those figures using VHDL.
    What should I do?
    How can I do that?
    Is there any samples? do I need to create an Entity with the same
    input/output ports and try to get an output exactly to those figures
    on page 15?


    __________________

    Questio for Mike:

    >> "Start with simplified prototypes and work them

    through description and simulation".

    What prototypes do you mean? can you give me a sample?


    __________________

    Question for Kenn:

    >> "You'll still need to understand prop delay out of your FPGA." Is there any book that it can help me?



    Thanks to all.

    Regards,
    Amit
     
    Amit, Mar 17, 2008
    #8
  9. Amit wrote:

    > What prototypes do you mean?


    I would start with a vhdl entity to write data to the
    control registers that control the volume.

    > can you give me a sample?


    My coding style is based on this synchronous process:

    ---------------------------------------------------------
    -- Process Template -- Always exactly the same:
    ---------------------------------------------------------
    begin -- process template
    if reset = '1' then
    init_regs;
    elsif rising_edge(clock) then
    update_regs;
    end if;
    update_ports;
    end process sync_template;
    end architecture synth;

    details here:
    http://home.comcast.net/~mike_treseler/
     
    Mike Treseler, Mar 17, 2008
    #9
  10. Amit

    KJ Guest

    On Mar 17, 2:54 am, Amit <> wrote:
    > Questio for Kevin:
    >
    > It was so nice that you went thru those pages and explained them to
    > me. I followed your statements as I was going thru those pages. Now, I
    > think I know what I should do (after reviewig these again). My
    > question for you is "What is the next step? after understanding the
    > timing/delays ?" let's say I want to control the clock and get the
    > output expected in those figures using VHDL.
    > What should I do?


    Well first you have to understand functionally how the part works and
    what the various input and output signals even do. As a rough guide,
    every input to the device you're trying to control (i.e. the 'Wolson
    WM8731 CODEC and FIFO') will come from an output on your FPGA.
    Similarly, every output of your device will most likely connect to an
    input to your FPGA. How the FPGA would connect to anything else in
    your system, I haven't a clue since all you said earlier is "I have
    given a project to read some
    music files..." so presumably you already know how you're getting
    those music files into whatever device it is (the FPGA?) that then
    connects to the CODEC, but maybe your design isn't worked out even
    that much. In any case, you're likely trying to move bytes of data
    from somewhere into the CODEC so you'll need to understand what format
    the CODEC wants those bytes of data and how you need to control the
    CODEC in order to accomplish that task.


    > How can I do that?


    1. Study the entire data sheet, not just the timing diagrams.
    2. Come up with a VHDL design for the FPGA that will control the
    CODEC.
    3. Come up with a VHDL model for the CODEC. Maybe you can get it from
    the supplier, maybe you'll have to write it yourself based on your
    understanding of the part that was gleaned from step #1. If you don't
    have the understanding to write such a model yourself, then you also
    most likely don't have the understanding to successfully complete step
    #2.
    4. Create a testbench that connects the FPGA to the CODEC (and
    whatever it is that will get the music files into the FPGA in the
    first place) and simulate the system. Once you can simulate correctly
    and move data from the 'music files' all the way through the system
    into the CODEC, then you're probably ready to try it out on a real
    board. Until that time, you're better off debugging in simulation
    (it's much faster to find/fix errors).

    > Is there any samples? do I need to create an Entity with the same
    > input/output ports and try to get an output exactly to those figures
    > on page 15?
    >


    You're trying to get things to meet requirements not match some
    figure. For example, if some signal has a 10ns minimum setup time
    requirement, then that does not mean you need to get the signal there
    precisely 10ns before, anything larger than 10ns would do.

    Things to consider that cause heartahces are signals that have both
    setup time and non-zero hold time requirements (I think your CODEC had
    those). One usually relatively easy to meet such requirements if the
    clock isn't running too fast is to send those signals on the opposite
    edge of the clock that the device is looking for them. That way
    you're guaranteed that the signals are stable both before and after
    the point where the device needs them since they will be there
    nominally 1/2 clock cycle both before and after the sampling edge.

    If you're asking for a completed design to do all of this though, you
    likely won't find it by posting questions in a newsgroup without a
    contract to pay for such design services.

    Kevin Jennings
     
    KJ, Mar 17, 2008
    #10
  11. KJ <> writes:

    > On Mar 17, 2:54 am, Amit <> wrote:


    >> How can I do that?

    >
    > 1. Study the entire data sheet, not just the timing diagrams.
    > 2. Come up with a VHDL design for the FPGA that will control the
    > CODEC.
    > 3. Come up with a VHDL model for the CODEC. Maybe you can get it from
    > the supplier, maybe you'll have to write it yourself based on your
    > understanding of the part that was gleaned from step #1. If you don't
    > have the understanding to write such a model yourself, then you also
    > most likely don't have the understanding to successfully complete step
    > #2.


    Of course, if you write it yourself, any *mis*understandings will be
    duplicated in the FPGA and the CODEC model, so the simulation will
    work fine. And real life won't!

    Not that I've ever had that problem, honest :)

    Cheers,
    Martin

    --

    TRW Conekt - Consultancy in Engineering, Knowledge and Technology
    http://www.conekt.net/electronics.html
     
    Martin Thompson, Mar 18, 2008
    #11
  12. Amit

    KJ Guest

    On Mar 18, 10:40 am, Martin Thompson <>
    wrote:
    > KJ <> writes:
    > > On Mar 17, 2:54 am, Amit <> wrote:
    > >> How can I do that?

    >
    > > 1. Study the entire data sheet, not just the timing diagrams.
    > > 2. Come up with a VHDL design for the FPGA that will control the
    > > CODEC.
    > > 3. Come up with a VHDL model for the CODEC.  Maybe you can get it from
    > > the supplier, maybe you'll have to write it yourself based on your
    > > understanding of the part that was gleaned from step #1.  If you don't
    > > have the understanding to write such a model yourself, then you also
    > > most likely don't have the understanding to successfully complete step
    > > #2.

    >
    > Of course, if you write it yourself, any *mis*understandings will be
    > duplicated in the FPGA and the CODEC model, so the simulation will
    > work fine.  
    >


    That can be true but I've also found that I tend to have a totally
    different mindset when I'm writing the code for the model of a
    'something' than I do when I'm writing the code for the control of
    that 'something'. That difference tends to cut down on some of the
    duplication of misunderstandings. In any case, demonstration in a
    simulation environment of correct operation as you understand the part
    to operate is a minimal first hurdle that one should clear before
    wasting time debugging real parts...unless the boss sees time spent
    simulating as not being productive (although it is) and time spent
    with scope/logic analyzer probes in hand as being productive (which
    it's not when it gets excessive).

    > And real life won't!


    That's when the learning lesson kicks in about making the effort to
    model the part sufficiently...cuz that's when the boss is ticked
    because you assured him/her that the design would work and now it
    'taint. That learning lesson will also sharpen your mind about what
    types of things to include in the model and which can be shortcut
    since modelling the complete behavior of a complex part on your own is
    time wasted as well.

    > Not that I've ever had that problem, honest :)
    >

    Me either...but I have had to dumb down my wonderful models to match
    the obviously insane, ridiculous behavior of some parts ;-)

    KJ
     
    KJ, Mar 18, 2008
    #12
  13. Amit

    Amit Guest

    On Mar 18, 8:09 am, KJ <> wrote:
    > On Mar 18, 10:40 am, Martin Thompson <>
    > wrote:
    >
    >
    >
    > > KJ <> writes:
    > > > On Mar 17, 2:54 am, Amit <> wrote:
    > > >> How can I do that?

    >
    > > > 1. Study the entire data sheet, not just the timing diagrams.
    > > > 2. Come up with a VHDL design for the FPGA that will control the
    > > > CODEC.
    > > > 3. Come up with a VHDL model for the CODEC. Maybe you can get it from
    > > > the supplier, maybe you'll have to write it yourself based on your
    > > > understanding of the part that was gleaned from step #1. If you don't
    > > > have the understanding to write such a model yourself, then you also
    > > > most likely don't have the understanding to successfully complete step
    > > > #2.

    >
    > > Of course, if you write it yourself, any *mis*understandings will be
    > > duplicated in the FPGA and the CODEC model, so the simulation will
    > > work fine.

    >
    > That can be true but I've also found that I tend to have a totally
    > different mindset when I'm writing the code for the model of a
    > 'something' than I do when I'm writing the code for the control of
    > that 'something'. That difference tends to cut down on some of the
    > duplication of misunderstandings. In any case, demonstration in a
    > simulation environment of correct operation as you understand the part
    > to operate is a minimal first hurdle that one should clear before
    > wasting time debugging real parts...unless the boss sees time spent
    > simulating as not being productive (although it is) and time spent
    > with scope/logic analyzer probes in hand as being productive (which
    > it's not when it gets excessive).
    >
    > > And real life won't!

    >
    > That's when the learning lesson kicks in about making the effort to
    > model the part sufficiently...cuz that's when the boss is ticked
    > because you assured him/her that the design would work and now it
    > 'taint. That learning lesson will also sharpen your mind about what
    > types of things to include in the model and which can be shortcut
    > since modelling the complete behavior of a complex part on your own is
    > time wasted as well.
    >
    > > Not that I've ever had that problem, honest :)

    >
    > Me either...but I have had to dumb down my wonderful models to match
    > the obviously insane, ridiculous behavior of some parts ;-)
    >
    > KJ



    No Kevin,

    That's not for money I'm still learning it. Anyway, I have one
    question for you guys. In the page 15 which explains the slave mode I
    see several signals and as far as I understand there must be two ways:

    1) simulation using counters
    2) simulation base on State Machine such as MOORE.

    Please correct me if I'm wrong.

    Now, do I need 4 counters here or should I consider BCLK (Bit Clock)
    as well?

    Thanks.
     
    Amit, Mar 19, 2008
    #13
  14. KJ <> writes:

    > On Mar 18, 10:40 am, Martin Thompson <>
    > wrote:
    >> KJ <> writes:
    >> > On Mar 17, 2:54 am, Amit <> wrote:
    >> >> How can I do that?

    >>
    >> > 1. Study the entire data sheet, not just the timing diagrams.
    >> > 2. Come up with a VHDL design for the FPGA that will control the
    >> > CODEC.
    >> > 3. Come up with a VHDL model for the CODEC.  Maybe you can get it from
    >> > the supplier, maybe you'll have to write it yourself based on your
    >> > understanding of the part that was gleaned from step #1.  If you don't
    >> > have the understanding to write such a model yourself, then you also
    >> > most likely don't have the understanding to successfully complete step
    >> > #2.

    >>
    >> Of course, if you write it yourself, any *mis*understandings will be
    >> duplicated in the FPGA and the CODEC model, so the simulation will
    >> work fine.  
    >>

    >
    > That can be true but I've also found that I tend to have a totally
    > different mindset when I'm writing the code for the model of a
    > 'something' than I do when I'm writing the code for the control of
    > that 'something'. That difference tends to cut down on some of the
    > duplication of misunderstandings.


    Yes, I think that's true, but it's something you develop over time.
    My early TB models tended to look very synthesisable, which usually
    means more like the "other end". Nowadays they're much smaller and
    full of weird software-like things, which scares traditional HDL
    people :)

    > In any case, demonstration in a simulation environment of correct
    > operation as you understand the part to operate is a minimal first
    > hurdle that one should clear before wasting time debugging real
    > parts


    Yes!

    Of course, occasionally, you think "That's a trivial piece of code,
    I'll just stick it in the hardware and off we go"... Then you go back
    and simulate it when it doesn't work and you've no idea why :)

    <snip
    >
    >> Not that I've ever had that problem, honest :)
    >>

    > Me either...but I have had to dumb down my wonderful models to match
    > the obviously insane, ridiculous behavior of some parts ;-)
    >


    :) I like that description!

    Cheers,
    Martin

    --

    TRW Conekt - Consultancy in Engineering, Knowledge and Technology
    http://www.conekt.net/electronics.html
     
    Martin Thompson, Mar 19, 2008
    #14
    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. Kieran Francisco

    Timing Diagram to HDL Translation

    Kieran Francisco, Sep 8, 2003, in forum: VHDL
    Replies:
    9
    Views:
    1,294
    VhdlCohen
    Sep 17, 2003
  2. Kload

    Strange Timing Problem

    Kload, Oct 23, 2003, in forum: VHDL
    Replies:
    2
    Views:
    594
    Kload
    Oct 23, 2003
  3. Kload
    Replies:
    1
    Views:
    555
    John_H
    Oct 23, 2003
  4. ramzi
    Replies:
    0
    Views:
    521
    ramzi
    Nov 1, 2003
  5. guille
    Replies:
    0
    Views:
    575
    guille
    Dec 19, 2003
Loading...

Share This Page