VHDL newbie: building sequential circuits with basic gates

Discussion in 'VHDL' started by GomoX, May 17, 2007.

  1. GomoX

    GomoX Guest

    Hey everyone,

    As an assignment for a course in my CS degree, I have to build a D
    latch, a D flip flop and a 1 bit register with VHDL. I have been given
    the "process" versions of those and I have to rewrite them using
    elementary gates and feedback connections.

    My teachers are not really profficient in the topic (sadly) but we are
    going through hoops to get stuff working. I have read on several pages
    that because of limitations in VHDL simulations, basic sequential
    circuits such as the latch/ff should not be implemented with gates but
    using processes instead.

    We are sure that the circuits we described using the component-based
    approach in VHDL correctly mimic the hardware versions of those.
    Still, behaviours are erratic and GHDL is giving away cryptic "stop-
    delta" compilation errors that we can't fix.

    This appears to be somewhat confirmed by the fact that this page (the
    only one I've been able to find that provides a gate-based
    implementation of latches and ffs) does it with some obscure library
    reference that I have not available (lsi_10k) and a complicated
    definitions instead of usual signaling and port mapping with and's and
    not's.
    http://esd.cs.ucr.edu/labs/tutorial/dff_gate.vhd

    Feel free to browse through the code by checking out with anonymous
    SVN:
    $ svn checkout http://orga1-2007.googlecode.com/svn/trunk/tp1/
    orga1-2007
    You can then run "make tb_reg1bit" and examine the resulting VCD to
    see what's going on.

    I am using this version at home, but the same problems arise with the
    debian etch versions at my college:
    GHDL 0.26 (20070408) [Sokcho edition]
    Compiled with GNAT Version: 4.1.220061115prerelease

    My knowledge of VHDL is very close to nil and documentation appears
    very sparse on the web. I could really use some help, so thanks in
    advance for reading.

    Gonzalo
     
    GomoX, May 17, 2007
    #1
    1. Advertising

  2. GomoX

    KJ Guest

    "GomoX" <> wrote in message
    news:...
    > Hey everyone,
    >
    > As an assignment for a course in my CS degree, I have to build a D
    > latch, a D flip flop and a 1 bit register with VHDL. I have been given
    > the "process" versions of those and I have to rewrite them using
    > elementary gates and feedback connections.
    >
    > My teachers are not really profficient in the topic (sadly)

    Which topic? Boolean logic or VHDL?

    > but we are
    > going through hoops to get stuff working.

    Does 'working' mean that the simulation is correct or does it mean that
    actual hardware has been built and tested? The advice that you'll get kind
    of depends on that (more on that later).

    > I have read on several pages
    > that because of limitations in VHDL simulations, basic sequential
    > circuits such as the latch/ff should not be implemented with gates but
    > using processes instead.

    The limitation comes about because of the interaction of two things:
    1. Simulation allows for zero propogation delays through logic
    2. The logic type most commonly used (i.e. std_logic) allows signals to be
    'unknown'.

    Neither of these two things model the real world behaviour of anything at
    all....and yet they are both powerful aids for designing logic properly and
    are 'good' things from a design perspective.

    Try simulating the simplest feedback element available, the oscillator. The
    logic to describe it is
    x <= not(x);

    If you use std_logic type for 'x' then it will get initialized to unknown at
    the start of the simulation. The 'not' of an unknown is also unknown so x
    will never change. This is a result of #2.

    If you try to use type boolean instead which only has TRUE and FALSE and no
    'unknowns' then x will keep toggling back and forth between TRUE and FALSE
    but the simulation time will never advance. This is a result of #1.

    >
    > We are sure that the circuits we described using the component-based
    > approach in VHDL correctly mimic the hardware versions of those.
    > Still, behaviours are erratic and GHDL is giving away cryptic "stop-
    > delta" compilation errors that we can't fix.

    See above discussion for the likely cause of the error.
    >
    > This appears to be somewhat confirmed by the fact that this page (the
    > only one I've been able to find that provides a gate-based
    > implementation of latches and ffs) does it with some obscure library
    > reference that I have not available (lsi_10k) and a complicated
    > definitions instead of usual signaling and port mapping with and's and
    > not's.

    Nothing complicated is needed. If this is a simulation only type of
    assignment that you're doing then you simply need to avoid #1 and #2. To
    get around #1 you make sure that every logical operation has a non zero
    propogation delay (or at least somewhere in your feedback loop there is a
    non-zero delay for every possible path). To get around #2 you need to not
    use std_logic type, use a logic type that only has two states.

    If this is intended to be built into real hardware though, don't do either
    of those two things. Designing a feedback loop of anything without a proper
    storage element will always result in flaky behaviour at best. How you
    implement it is also be a function of which target technology you're
    planning on implementing it in (hence all the postings that you've seen
    discouraging building flops out of gates). Since you didn't mention
    anything about a target device I'm guessing that this might be a simulation
    only assignment but in case it's not I added this caution.

    Kevin Jennings
     
    KJ, May 17, 2007
    #2
    1. Advertising

  3. On 16 May 2007 22:16:41 -0700, GomoX <> wrote:

    >Hey everyone,
    >
    >As an assignment for a course in my CS degree, I have to build a D
    >latch, a D flip flop and a 1 bit register with VHDL. I have been given
    >the "process" versions of those and I have to rewrite them using
    >elementary gates and feedback connections.
    >
    >My teachers are not really profficient in the topic (sadly) but we are
    >going through hoops to get stuff working.


    Back to basics ... so look at the source materials from when those were
    the basic building blocks.

    If you have access to a university library (or even a decently stocked
    engineer's bookshelf) you could do a lot worse than looking at the
    original Texas Instruments TTL Data Book.

    Or maybe you can find the 7474 or 74LS74 datasheets online?
    Google is your friend...

    http://www.datasheetcatalog.com/datasheets_pdf/7/4/L/S/74LS74.shtml
    and look at the Motorola one for example

    - Brian
     
    Brian Drummond, May 17, 2007
    #3
  4. In news:hWW2i.1605$ timestamped Thu,
    17 May 2007 07:22:50 -0400, "KJ" <> posted:
    "[..]

    [..]
    1. Simulation allows for zero propogation delays through logic
    2. The logic type most commonly used (i.e. std_logic) allows signals to be
    'unknown'.

    Neither of these two things model the real world behaviour of anything at
    all....and yet they are both powerful aids for designing logic properly and
    are 'good' things from a design perspective.

    [..]"


    Hi,

    How can zero delays or std_logic be useful?

    Regards,
    Colin Paul Gloster
     
    Colin Paul Gloster, May 17, 2007
    #4
  5. On 17 May 2007 12:15:24 GMT, Colin Paul Gloster
    <> wrote:

    >How can zero delays or std_logic be useful?


    I'm stumped.

    That question might be just plain stupid, but given
    your posting history that seems extremely unlikely.

    It might be a look-how-smart-I-am meta-question,
    in which case it deserves a meta-answer such as
    "because the world would be less enriched without
    them".

    It might be provocative, from someone who knows
    a lot about computer science and software but somehow
    sees hardware design in its current mainstream form
    as being irrelevant, misguided and beneath his dignity.
    If that's the case, then I decline to answer.

    If it were a question from someone who was trying
    to get to grips with digital simulation for the very
    first time, I would answer something like this:
    because zero delays and specialised logic-modelling
    data types provide part of the large and complex
    framework that we use to get event-driven simulators
    to model digital systems with reasonable efficiency
    and with a level of approximation to reality that is
    adequate for many practical design problems
    and then I would be obliged to tell the querant to
    go away, read a book and try some stuff, and come back
    again when they had enough concrete experience to be
    able to ask questions that help to move things forward.

    Or perhaps it's a troll.

    Who knows? The world will continue to rotate, and I will
    continue to do realistic and useful digital simulation with
    zero delays and std_logic, whether or not people ask such
    unanswerable questions.
    --
    Jonathan Bromley, Consultant

    DOULOS - Developing Design Know-how
    VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

    Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK

    http://www.MYCOMPANY.com

    The contents of this message may contain personal views which
    are not the views of Doulos Ltd., unless specifically stated.
     
    Jonathan Bromley, May 17, 2007
    #5
  6. GomoX

    Guest

    On May 17, 12:16 am, GomoX <> wrote:
    > Hey everyone,
    >
    > As an assignment for a course in my CS degree, I have to build a D
    > latch, a D flip flop and a 1 bit register with VHDL. I have been given
    > the "process" versions of those and I have to rewrite them using
    > elementary gates and feedback connections.
    >
    > My teachers are not really profficient in the topic (sadly) but we are
    > going through hoops to get stuff working. I have read on several pages
    > that because of limitations in VHDL simulations, basic sequential
    > circuits such as the latch/ff should not be implemented with gates but
    > using processes instead.


    Yes, you really don't want to do that. Looping back a combinatorial
    output makes a sort of infinite loop of dependencies for the simulator
    to try to make sense of. In the real world it works because of delay
    and capacitance and stuff like that, but an HDL simulator it's not
    designed to do physical modeling of actual devices! Instead it's
    designed to simulate the application-level behaviour of devices that
    can be reasonably represented with just a few paramaters (like
    propogation delay), and having just a few states, (like 1, 0,
    undriven, and unkown)

    If you want to do something like what you are talking about, try
    playing with software that's designed to simulate the analog behaviour
    of real devices, which is to say spice. Get yourself some simple
    logic gate circuits to put in a spice deck and play with graphing how
    that responds over time to "digital" inputs.
     
    , May 17, 2007
    #6
  7. In news: timestamped Thu, 17
    May 2007 13:44:38 +0100, Jonathan Bromley
    <> posted:
    "On 17 May 2007 12:15:24 GMT, Colin Paul Gloster
    <> wrote:

    >How can zero delays or std_logic be useful?


    I'm stumped.

    That question might be just plain stupid, but given
    your posting history that seems extremely unlikely.

    [..]"

    Thank you.

    Jonathan Bromley wrote in a post timestamped Thu, 17
    May 2007 13:44:38 +0100:

    "It might be a look-how-smart-I-am meta-question,
    [..]

    It might be provocative, [..]

    [..]

    Or perhaps it's a troll."

    No, I am genuinely trying to learn why they would be useful. I really
    do appreciate your responses to posts I make as you make much more of
    an effort to teach me than anyone in the university I currently
    attend. Unfortunately you do not receive money for this, and I feel
    bad about that.

    Kevin Jennings said in
    news:hWW2i.1605$
    that they are useful but aside from that, everything he said about
    them in that post was a claim that they are unlike real hardware and
    contributed to Gonzalo's problem (but I accept that something can
    contribute to a problem but be useful in other situations). Furthermore,
    he advocated not using std_logic in
    news:eLUEh.2278$
    in February 2007:
    "[..]

    [..] Your other signals are probably std_logic types which can have
    multiple
    drivers so the compiler doesn't complain but if you could simulate
    you'd
    probably find that all of your std_logic signals are always 'X' and
    then
    have to debug down to why that is. That's why it's better to use
    std_ulogic
    since the compiler will again immediately complain (like it is doing
    for
    you
    with type 'integer') about having more than one process driving a
    signal
    of
    that type."


    Jonathan Bromley wrote in a post timestamped Thu, 17
    May 2007 13:44:38 +0100:

    "If it were a question from someone who was trying
    to get to grips with digital simulation for the very
    first time, I would answer something like this:
    because zero delays and specialised logic-modelling
    data types provide part of the large and complex
    framework that we use to get event-driven simulators
    to model digital systems with reasonable efficiency
    and with a level of approximation to reality that is
    adequate for many practical design problems"

    I can appreciate that this may be relevant to zero delays but I would
    like to know more about that, and it does not seem to help me with
    determining why someone who advised against std_logic would write
    that std_logic is "powerful" and "'good'".

    Jonathan Bromley wrote in a post timestamped Thu, 17
    May 2007 13:44:38 +0100:

    "and then I would be obliged to tell the querant to
    go away, read a book and try some stuff, and come back
    again when they had enough concrete experience to be
    able to ask questions that help to move things forward.

    [..]"

    In news: in a different
    thread Jonathan Bromley did not express much fondness of books so
    which book or books would be good for learning about this? Thank you
    for your time and suggestions.

    Jonathan Bromley wrote in a post timestamped Thu, 17
    May 2007 13:44:38 +0100:

    "Who knows? [..]"

    It would seem that you do.

    Jonathan Bromley wrote in a post timestamped Thu, 17
    May 2007 13:44:38 +0100:

    "[..]

    It might be provocative, from someone who knows
    a lot about computer science and software but somehow
    sees hardware design in its current mainstream form
    as being irrelevant, misguided and beneath his dignity.
    If that's the case, then I decline to answer.

    [..]"

    No matter how good I think I am at anything, there will always be a
    lot of room for improvement. Though a casual glance at my posts re
    software (e.g. the terms Ada; UML; C; and C++ would be helpful in
    checking how I think about that) would give the correct impression
    that I believe that people involved in mainstream software design are
    misguided. Neither computer science nor software is intrinsically
    better than hardware design.

    Sincerely,
    Colin Paul Gloster
     
    Colin Paul Gloster, May 17, 2007
    #7
  8. wrote:
    > On May 17, 12:16 am, GomoX <> wrote:
    >> Hey everyone,
    >>
    >> As an assignment for a course in my CS degree, I have to build a D
    >> latch, a D flip flop and a 1 bit register with VHDL. I have been given
    >> the "process" versions of those and I have to rewrite them using
    >> elementary gates and feedback connections.
    >>
    >> My teachers are not really profficient in the topic (sadly) but we are
    >> going through hoops to get stuff working. I have read on several pages
    >> that because of limitations in VHDL simulations, basic sequential
    >> circuits such as the latch/ff should not be implemented with gates but
    >> using processes instead.

    >
    > Yes, you really don't want to do that. Looping back a combinatorial
    > output makes a sort of infinite loop of dependencies for the simulator
    > to try to make sense of. In the real world it works because of delay
    > and capacitance and stuff like that, but an HDL simulator it's not
    > designed to do physical modeling of actual devices! Instead it's
    > designed to simulate the application-level behaviour of devices that
    > can be reasonably represented with just a few paramaters (like
    > propogation delay), and having just a few states, (like 1, 0,
    > undriven, and unkown)
    >
    > If you want to do something like what you are talking about, try
    > playing with software that's designed to simulate the analog behaviour
    > of real devices, which is to say spice. Get yourself some simple
    > logic gate circuits to put in a spice deck and play with graphing how
    > that responds over time to "digital" inputs.
    >
    >

    If you *must* build gate models in VHDL, be sure to include a delay in
    your gate, eg OUT <= not(IN1 and IN2) after 2 ns;
     
    David R Brooks, May 17, 2007
    #8
  9. GomoX

    jtw Guest

    Zero delay: a useful approximation for many portions of many design
    implementations. It significantly speeds up simulation, and is often
    appropriate for synchronous designs.

    std_logic: a previous poster mentioned that the values may be unknown.
    True. But they may also be explicitly initialized; it is often useful to do
    that in simulation. You can also use appropriate reset signals to force the
    issue.

    I would suppose that there are least two reasons for the homework problem:
    1. Make the student think about the underlying architecture.
    2. Realize how painful it can be to not use simplifying assumptions.
    3. Eventually, learn when to make the trade-off between accuracy and
    speed.

    An additional note: delays in VHDL can be inertial or transport. For your
    gate-level model, you need to consider which is appropriate for your use.
    See http://www.gmvhdl.com/delay.htm [google(inertial delay vhdl)] for a
    description of their usage.

    JTW

    "Colin Paul Gloster" <> wrote in message
    news:f2hoij$v4e$...
    > In news: timestamped Thu, 17
    > May 2007 13:44:38 +0100, Jonathan Bromley
    > <> posted:
    > "On 17 May 2007 12:15:24 GMT, Colin Paul Gloster
    > <> wrote:
    >
    >>How can zero delays or std_logic be useful?

    >
    > I'm stumped.
    >
    > That question might be just plain stupid, but given
    > your posting history that seems extremely unlikely.
    >
    > [..]"
    >
    > Thank you.
    >
    > Jonathan Bromley wrote in a post timestamped Thu, 17
    > May 2007 13:44:38 +0100:
    >
    > "It might be a look-how-smart-I-am meta-question,
    > [..]
    >
    > It might be provocative, [..]
    >
    > [..]
    >
    > Or perhaps it's a troll."
    >
    > No, I am genuinely trying to learn why they would be useful. I really
    > do appreciate your responses to posts I make as you make much more of
    > an effort to teach me than anyone in the university I currently
    > attend. Unfortunately you do not receive money for this, and I feel
    > bad about that.
    >
    > Kevin Jennings said in
    > news:hWW2i.1605$
    > that they are useful but aside from that, everything he said about
    > them in that post was a claim that they are unlike real hardware and
    > contributed to Gonzalo's problem (but I accept that something can
    > contribute to a problem but be useful in other situations). Furthermore,
    > he advocated not using std_logic in
    > news:eLUEh.2278$
    > in February 2007:
    > "[..]
    >
    > [..] Your other signals are probably std_logic types which can have
    > multiple
    > drivers so the compiler doesn't complain but if you could simulate
    > you'd
    > probably find that all of your std_logic signals are always 'X' and
    > then
    > have to debug down to why that is. That's why it's better to use
    > std_ulogic
    > since the compiler will again immediately complain (like it is doing
    > for
    > you
    > with type 'integer') about having more than one process driving a
    > signal
    > of
    > that type."
    >
    >
    > Jonathan Bromley wrote in a post timestamped Thu, 17
    > May 2007 13:44:38 +0100:
    >
    > "If it were a question from someone who was trying
    > to get to grips with digital simulation for the very
    > first time, I would answer something like this:
    > because zero delays and specialised logic-modelling
    > data types provide part of the large and complex
    > framework that we use to get event-driven simulators
    > to model digital systems with reasonable efficiency
    > and with a level of approximation to reality that is
    > adequate for many practical design problems"
    >
    > I can appreciate that this may be relevant to zero delays but I would
    > like to know more about that, and it does not seem to help me with
    > determining why someone who advised against std_logic would write
    > that std_logic is "powerful" and "'good'".
    >
    > Jonathan Bromley wrote in a post timestamped Thu, 17
    > May 2007 13:44:38 +0100:
    >
    > "and then I would be obliged to tell the querant to
    > go away, read a book and try some stuff, and come back
    > again when they had enough concrete experience to be
    > able to ask questions that help to move things forward.
    >
    > [..]"
    >
    > In news: in a different
    > thread Jonathan Bromley did not express much fondness of books so
    > which book or books would be good for learning about this? Thank you
    > for your time and suggestions.
    >
    > Jonathan Bromley wrote in a post timestamped Thu, 17
    > May 2007 13:44:38 +0100:
    >
    > "Who knows? [..]"
    >
    > It would seem that you do.
    >
    > Jonathan Bromley wrote in a post timestamped Thu, 17
    > May 2007 13:44:38 +0100:
    >
    > "[..]
    >
    > It might be provocative, from someone who knows
    > a lot about computer science and software but somehow
    > sees hardware design in its current mainstream form
    > as being irrelevant, misguided and beneath his dignity.
    > If that's the case, then I decline to answer.
    >
    > [..]"
    >
    > No matter how good I think I am at anything, there will always be a
    > lot of room for improvement. Though a casual glance at my posts re
    > software (e.g. the terms Ada; UML; C; and C++ would be helpful in
    > checking how I think about that) would give the correct impression
    > that I believe that people involved in mainstream software design are
    > misguided. Neither computer science nor software is intrinsically
    > better than hardware design.
    >
    > Sincerely,
    > Colin Paul Gloster
     
    jtw, May 18, 2007
    #9
  10. Colin Paul Gloster <> writes:

    > In news:hWW2i.1605$ timestamped Thu,
    > 17 May 2007 07:22:50 -0400, "KJ" <> posted:
    > "[..]
    >
    > [..]
    > 1. Simulation allows for zero propogation delays through logic
    > 2. The logic type most commonly used (i.e. std_logic) allows signals to be
    > 'unknown'.
    >
    > Neither of these two things model the real world behaviour of anything at
    > all....and yet they are both powerful aids for designing logic properly and
    > are 'good' things from a design perspective.
    >
    > [..]"
    >
    >
    > Hi,
    >
    > How can zero delays or std_logic be useful?
    >


    Because they allow you to create a simulation of your circuit at a
    level of abstraction removed from those details. If you follow a
    standard synchronous design template, you can then use a synthesiser
    to get a netlist that does the same thing as your simulations.

    Lots of us do it all the time :)

    Cheers,
    Martin

    --

    TRW Conekt - Consultancy in Engineering, Knowledge and Technology
    http://www.conekt.net/electronics.html
     
    Martin Thompson, May 18, 2007
    #10
  11. GomoX

    KJ Guest

    "Colin Paul Gloster" <> wrote in message
    news:f2hh0s$na5$...
    > In news:hWW2i.1605$ timestamped Thu,
    > 17 May 2007 07:22:50 -0400, "KJ" <> posted:
    > "[..]
    >
    > [..]
    > 1. Simulation allows for zero propogation delays through logic
    > 2. The logic type most commonly used (i.e. std_logic) allows signals to be
    > 'unknown'.
    >
    > Neither of these two things model the real world behaviour of anything at
    > all....and yet they are both powerful aids for designing logic properly
    > and
    > are 'good' things from a design perspective.
    >
    > [..]"
    >
    >
    > Hi,
    >
    > How can zero delays or std_logic be useful?
    >
    > Regards,
    > Colin Paul Gloster


    As to how zero delays can be useful, I'd say that from the perspective of
    designing logic to implement a particular function the delay used is usually
    irrelevant so zero delay is just as useful as 1 ns, 1 ps, or any other
    delay. If there was some 'default' non-zero delay built into the design
    language or the simulator then no doubt that default time will just get in
    the way of somebody trying to create some new design at some point because
    they are trying to design something that needs to run at or near a speed
    that is comparable to this 'default' time. The definition of 'delta time'
    which is infintesimally small and simply represents extra churns by the
    simulation engine that are still completed in 'zero time' permanently gets
    around this issue. The fact that zero delay is not physically possible in
    the real world just never gets in the way of designing whatever it is that
    you're designing.

    std_logic (and std_ulogic) are useful because of the meta-logical values
    like 'Z', 'U', and 'X' even though in the real world, logical signals will
    never be 'U' or 'X', they will always be at a voltage/current level that
    corresponds to a logical '0' or '1' or tri-stated. The 'unknowns' are great
    because when you're testing your design in simulation those unknown values
    will propogate through the logic and allow for very rapid determination of
    logic holes in the design. Using a type such as 'boolean' or 'bit' to do
    your design would result in these signals getting assigned default values
    that may or may not correspond to what a real device would do and yet by
    virtue of whatever value happened to get assigned, this may cause downstream
    logic to appear to behave properly in simulation but fail in the real world.
    This is the types of thing that the 'unknowns' flush out quite quickly

    From a modelling perspective, when you're trying to create a behavioural
    model of some existing thing the opposite can usually apply. 'Zero' delays
    and 'unknowns' for logic don't have much value. Since the original poster
    was querying about constructing storage elements from basic logic gates,
    this would fall into the 'modelling side' rather than the 'design side' of
    things so I put my 2 cents in with that in mind and added the caution about
    not trying to use that advice if you're doing design.

    Kevin Jennings
     
    KJ, May 20, 2007
    #11
  12. In news:rzN3i.3708$ timestamped Sat,
    19 May 2007 21:33:08 -0400, "KJ" <> posted:
    "[..]

    As to how zero delays can be useful, I'd say that from the perspective of
    designing logic to implement a particular function the delay used is usually
    irrelevant so zero delay is just as useful as 1 ns, 1 ps, or any other
    delay. [..]"

    Thank you for the insightful answer re zero delays.


    "std_logic (and std_ulogic) are useful because of the meta-logical values
    like 'Z', 'U', and 'X' even though in the real world, logical signals will
    never be 'U' or 'X', they will always be at a voltage/current level that
    corresponds to a logical '0' or '1' or tri-stated. The 'unknowns' are great
    because when you're testing your design in simulation those unknown values
    will propogate through the logic and allow for very rapid determination of
    logic holes in the design. Using a type such as 'boolean' or 'bit' to do
    your design would result in these signals getting assigned default values
    [..]

    [..]"

    This is more an explanation of how std_logic is better than Boolean or
    bit instead of an explanation of how std_logic could be considered to
    be useful, as all of those advantages apply to std_ulogic as well and
    std_ulogic seems to be better, which you stated in
    news:eLUEh.2278$
    in February 2007.

    Regards,
    Colin Paul Gloster
     
    Colin Paul Gloster, May 20, 2007
    #12
  13. GomoX

    KJ Guest


    > "std_logic (and std_ulogic) are useful because of the meta-logical values
    > like 'Z', 'U', and 'X' even though in the real world, logical signals will
    > never be 'U' or 'X', they will always be at a voltage/current level that
    > corresponds to a logical '0' or '1' or tri-stated. The 'unknowns' are
    > great
    > because when you're testing your design in simulation those unknown values
    > will propogate through the logic and allow for very rapid determination of
    > logic holes in the design. Using a type such as 'boolean' or 'bit' to do
    > your design would result in these signals getting assigned default values
    > [..]
    >
    > [..]"
    >
    > This is more an explanation of how std_logic is better than Boolean or
    > bit instead of an explanation of how std_logic could be considered to
    > be useful, as all of those advantages apply to std_ulogic as well and
    > std_ulogic seems to be better, which you stated in
    > news:eLUEh.2278$
    > in February 2007.
    >

    I guess I'm not sure what you're getting at. It sounds like you accept my
    explanation of how std_logic is better than boolean or bit in the particular
    context that I've described but are not accepting that as being evidence of
    std_logic being 'useful'.

    std_logic and std_ulogic share all of the same advantages and disadvantages
    as they relate to the particular point of propagating 'unknown' logic
    levels. I didn't distinguish between the two here since the essential
    element was that the original poster had questions related to modelling and
    by necessity was going to be creating combinatorial feedback paths in order
    to create those models just like how it is done in an actual part. The
    question seemed to be about how their are 'issues' in doing this and all I
    was doing was clarifying those issues as they related to the particular
    context of modelling storage elements as the poster was instructed to do.

    The earlier discussion about std_ulogic having advantages over std_logic
    that you referenced was in a totally different context, that of design.
    While all of those advantages and disadvantages also apply to most
    situations when modelling device behaviour, one particular situation where
    they have a huge disadvantage is when modelling a combinatorial feedback
    path as the original poster was trying to do.

    Another example of such a difference between when a particular type is good
    to use or not would be between the use of type 'unsigned' or type 'natural'
    when creating a counter (or adder). In the hands of the more skilled
    designer, type 'natural' is usually preferred; in the hands of the less
    skilled the use of type 'natural' can cause problems because signals of type
    natural will always magically initialize to 0 in simulation. In a real
    device that might not happen to guarantee such behaviour and for which the
    less skilled designer has forgotten to design in a path to reset the counter
    they can run into issues when trying to get their stuff working on a real
    board. Had that less skilled designer instead used an 'unsigned' type for
    the counter they would have cleared up the design issues during simulation
    because the forgotten reset path would have caused them to have 'unknowns'
    that need to be cleared up. Here the difference in context is not the
    design itself, it's not design versus modelling.it is simply the skill of
    the designer. So which is the 'better' choice? You could say it's
    'unsigned' but there is a simulation performance penalty to be paid in using
    'unsigned' over 'natural'. So is that performance penalty a 'good' thing if
    you have a skilled designer? Maybe not.

    The bottom line is each data type is 'useful' and probably in some sense
    'better' than any other data type in a particular context, but may fall flat
    when used in a different context.

    Kevin Jennings
     
    KJ, May 20, 2007
    #13
  14. In news:XX24i.1173$ timestamped Sun,
    20 May 2007 17:19:47 -0400, "KJ" <> posted:
    "[..]
    I guess I'm not sure what you're getting at. It sounds like you accept my
    explanation of how std_logic is better than boolean or bit in the particular
    context that I've described but are not accepting that as being evidence of
    std_logic being 'useful'."

    Yes.

    "std_logic and std_ulogic share all of the same advantages and disadvantages
    as they relate to the particular point of propagating 'unknown' logic
    levels. I didn't distinguish between the two here since the essential
    element was that the original poster had questions related to modelling and
    by necessity was going to be creating combinatorial feedback paths in order
    to create those models just like how it is done in an actual part. The
    question seemed to be about how their are 'issues' in doing this and all I
    was doing was clarifying those issues as they related to the particular
    context of modelling storage elements as the poster was instructed to do.

    The earlier discussion about std_ulogic having advantages over std_logic
    that you referenced was in a totally different context, that of design."


    Ah, I had not realized that std_ulogic is better than std_logic for
    design but not modelling.



    "While all of those advantages and disadvantages also apply to most
    situations when modelling device behaviour, one particular situation where
    they have a huge disadvantage is when modelling a combinatorial feedback
    path as the original poster was trying to do."

    Just to clarify: does std_ulogic have a huge disadvantage in contrast
    to std_logic when modelling combinatorial feedback?



    "[..] In the hands of the more skilled
    designer, type 'natural' is usually preferred; in the hands of the less
    skilled the use of type 'natural' can cause problems because signals of type
    natural will always magically initialize to 0 in simulation. In a real
    device that might not happen to guarantee such behaviour and for which the
    less skilled designer has forgotten to design in a path to reset the counter
    they can run into issues when trying to get their stuff working on a real
    board. Had that less skilled designer instead used an 'unsigned' type for
    the counter they would have cleared up the design issues during simulation
    because the forgotten reset path would have caused them to have 'unknowns'
    that need to be cleared up. Here the difference in context is not the
    design itself, it's not design versus modelling.it is simply the skill of
    the designer."

    I understand and may agree with this point but I disagree with the
    particular example as being an issue of skill... I would classify this
    as more of an issue of whether the designers know what their tools do.

    "[..]

    The bottom line is each data type is 'useful' and probably in some sense
    'better' than any other data type in a particular context, but may fall flat
    when used in a different context."

    Understood.

    Thanks,
    Colin Paul Gloster
     
    Colin Paul Gloster, May 21, 2007
    #14
  15. GomoX

    KJ Guest

    "Colin Paul Gloster" <> wrote in message
    news:f2rh0u$kh6$...
    > In news:XX24i.1173$ timestamped Sun,
    > 20 May 2007 17:19:47 -0400, "KJ" <> posted:
    > "[..]
    >
    > Just to clarify: does std_ulogic have a huge disadvantage in contrast
    > to std_logic when modelling combinatorial feedback?
    >

    No disadvantages that I can think of.

    <snip> I understand and may agree with this point but I disagree with the
    > particular example as being an issue of skill... I would classify this
    > as more of an issue of whether the designers know what their tools do.
    >

    Knowledge of what the tools do and how best to use those tools is part of
    what I would classify as 'skill', others may feel differently.

    KJ
     
    KJ, May 21, 2007
    #15
  16. GomoX

    Jim Lewis Guest

    KJ,
    > Another example of such a difference between when a particular type is good
    > to use or not would be between the use of type 'unsigned' or type 'natural'
    > when creating a counter (or adder). In the hands of the more skilled
    > designer, type 'natural' is usually preferred; in the hands of the less
    > skilled the use of type 'natural' can cause problems because signals of type
    > natural will always magically initialize to 0 in simulation.


    Do you find that you are getting good usage of carry out in
    place of zero detection with natural?

    For example, with unsigned, I can explicitly code the carry out
    by adding one bit to my decrement resource (variable Count17)
    as shown below. As a result, the zero detect is implemented as
    a single carry/borrow cell (one LUT) for any size of counter.
    If you do a test, make sure to use at least 16 bits so you can
    notice the difference.

    signal EndDetect : std_logic ;
    signal Count16Reg : unsigned(15 downto 0) ;
    ....

    process (...)
    variable count17 : unsigned(16 downto 0) ;
    begin
    ....
    Count17 := Count17 - 1 ;
    EndDetect <= Count17(16) ; -- carry bit.
    Count16Reg <= Count17 (15 downto 0) ;
    ....

    Now if the current generation of synthesis tools can always
    extract this information from the following, then there is no
    point in working to create the result with unsigned.

    signal EndDetect : std_logic ;
    signal CountReg : natural range 0 to 2**16 - 1 ;

    ....
    CountReg <= CountReg - 1 ;
    ....
    EndDetect <= '1' when CountReg = 0 else '0' ;


    WRT initialzation, you will always find that in gate sims,
    however, it is not a nice time to find it if a rookie forgets
    to reset many registers.


    Cheers,
    Jim
     
    Jim Lewis, May 21, 2007
    #16
  17. GomoX

    Andy Guest

    On May 21, 11:42 am, Jim Lewis <> wrote:
    > KJ,
    >
    > > Another example of such a difference between when a particular type is good
    > > to use or not would be between the use of type 'unsigned' or type 'natural'
    > > when creating a counter (or adder). In the hands of the more skilled
    > > designer, type 'natural' is usually preferred; in the hands of the less
    > > skilled the use of type 'natural' can cause problems because signals of type
    > > natural will always magically initialize to 0 in simulation.

    >
    > Do you find that you are getting good usage of carry out in
    > place of zero detection with natural?
    >
    > For example, with unsigned, I can explicitly code the carry out
    > by adding one bit to my decrement resource (variable Count17)
    > as shown below. As a result, the zero detect is implemented as
    > a single carry/borrow cell (one LUT) for any size of counter.
    > If you do a test, make sure to use at least 16 bits so you can
    > notice the difference.
    >
    > signal EndDetect : std_logic ;
    > signal Count16Reg : unsigned(15 downto 0) ;
    > ...
    >
    > process (...)
    > variable count17 : unsigned(16 downto 0) ;
    > begin
    > ...
    > Count17 := Count17 - 1 ;
    > EndDetect <= Count17(16) ; -- carry bit.
    > Count16Reg <= Count17 (15 downto 0) ;
    > ...
    >
    > Now if the current generation of synthesis tools can always
    > extract this information from the following, then there is no
    > point in working to create the result with unsigned.
    >
    > signal EndDetect : std_logic ;
    > signal CountReg : natural range 0 to 2**16 - 1 ;
    >
    > ...
    > CountReg <= CountReg - 1 ;
    > ...
    > EndDetect <= '1' when CountReg = 0 else '0' ;
    >
    > WRT initialzation, you will always find that in gate sims,
    > however, it is not a nice time to find it if a rookie forgets
    > to reset many registers.
    >
    > Cheers,
    > Jim


    Here's how I do it with natural types:

    signal count : natural range 0 to 2**numbits - 1;

    ....

    if count - 1 < 0 then
    do_end_of_count_stuff_here;
    else
    count <= count - 1;
    end if;

    The important thing to remember is integer expressions are independent
    on the "width" of the operands, and are always 32 bit signed. The
    reduction (and bounds checking) is done only upon assignment to a
    constrained subtype of integer. Thus even though count cannot be less
    than zero, count - 1, as an integer expression can be. DO NOT TRY THIS
    WITH UNSIGNED!

    This also works for 2**n-1 bit rollovers in up counters.

    The synthesis tools recognize the common expression and share the
    adder between them, adding an extra bit for the sign only in the
    comparison, not in storage. More specifically, the synthesis tools
    discard all the extra bits from the 32 bit expression except for the
    result and the sign.


    Andy
     
    Andy, May 21, 2007
    #17
  18. GomoX

    Jim Lewis Guest

    Andy,
    > Here's how I do it with natural types:
    >
    > signal count : natural range 0 to 2**numbits - 1;
    >
    > ...
    >
    > if count - 1 < 0 then
    > do_end_of_count_stuff_here;
    > else
    > count <= count - 1;
    > end if;
    >
    > The important thing to remember is integer expressions are independent
    > on the "width" of the operands, and are always 32 bit signed. The
    > reduction (and bounds checking) is done only upon assignment to a
    > constrained subtype of integer. Thus even though count cannot be less
    > than zero, count - 1, as an integer expression can be. DO NOT TRY THIS
    > WITH UNSIGNED!
    >
    > This also works for 2**n-1 bit rollovers in up counters.
    >
    > The synthesis tools recognize the common expression and share the
    > adder between them, adding an extra bit for the sign only in the
    > comparison, not in storage. More specifically, the synthesis tools
    > discard all the extra bits from the 32 bit expression except for the
    > result and the sign.
    >
    >
    > Andy
    >


    Which tools have you verified that the synthesis tools give
    you a good implementation?

    Cheers,
    Jim
     
    Jim Lewis, May 21, 2007
    #18
  19. Andy wrote:

    > This also works for 2**n-1 bit rollovers in up counters.


    Yes.
    For a related rollover example using unsigned,
    see the carry chain map for the
    "Clk Enabled Counters" example here:

    http://home.comcast.net/~mike_treseler/

    -- Mike Treseler
     
    Mike Treseler, May 21, 2007
    #19
  20. GomoX

    Andy Guest

    On May 21, 1:50 pm, Jim Lewis <> wrote:
    > Andy,
    >
    >
    >
    > > Here's how I do it with natural types:

    >
    > > signal count : natural range 0 to 2**numbits - 1;

    >
    > > ...

    >
    > > if count - 1 < 0 then
    > > do_end_of_count_stuff_here;
    > > else
    > > count <= count - 1;
    > > end if;

    >
    > > The important thing to remember is integer expressions are independent
    > > on the "width" of the operands, and are always 32 bit signed. The
    > > reduction (and bounds checking) is done only upon assignment to a
    > > constrained subtype of integer. Thus even though count cannot be less
    > > than zero, count - 1, as an integer expression can be. DO NOT TRY THIS
    > > WITH UNSIGNED!

    >
    > > This also works for 2**n-1 bit rollovers in up counters.

    >
    > > The synthesis tools recognize the common expression and share the
    > > adder between them, adding an extra bit for the sign only in the
    > > comparison, not in storage. More specifically, the synthesis tools
    > > discard all the extra bits from the 32 bit expression except for the
    > > result and the sign.

    >
    > > Andy

    >
    > Which tools have you verified that the synthesis tools give
    > you a good implementation?
    >
    > Cheers,
    > Jim


    Symplify, XST, and even the old Synopsys FC2 would handle it
    appropriately. I'm pretty sure Precision and Quartus handle it as
    well.

    Oh yeah, I meant to say it works with n-bit rollovers (if count + 1 >
    2**n-1 then...) for up counters... Mike knew what I meant!

    Andy
     
    Andy, May 22, 2007
    #20
    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. boki
    Replies:
    0
    Views:
    476
  2. SanSaurus
    Replies:
    2
    Views:
    782
    Jeroen
    Aug 13, 2004
  3. john
    Replies:
    7
    Views:
    719
  4. JSreeniv

    vhdl testbench sequential

    JSreeniv, Nov 15, 2009, in forum: VHDL
    Replies:
    4
    Views:
    2,200
    JimLewis
    Nov 17, 2009
  5. Jonathan Ross
    Replies:
    0
    Views:
    1,238
    Jonathan Ross
    Oct 7, 2010
Loading...

Share This Page