New keyword 'orif' and its implications

Discussion in 'VHDL' started by Weng Tianxiang, Aug 28, 2007.

  1. Hi,
    I open a new topics from previous one to try to stir another round to
    introduce a new keyword 'orif'.

    > > Hi Mike,
    > > "None of the VHDL
    > > synthesizers I've tried completely implement any version of the
    > > standard. Instead, they implement odd hybrids of the different
    > > versions of the standard"

    >
    > > Your comments are interesting and funny !!!

    >
    > > There are a lot of definitions I have difficulty to learn so that I
    > > have never used them and have never tried them.

    >
    > > For example, sharing a signal, block concept and the latest ones that
    > > do formal verification are a few features I have never used and tried.

    >
    > > I prefer using a very small set of the definitions and the strategy
    > > works well.

    >
    > > One thing I miss a lot is 'orif' keyword compared to 'elsif'.

    >
    > > 'orif' introduces a group of conditions that are mutually exclusive.

    >
    > > On any output buses or input buses, all data running on the buses are
    > > mutually exclusive.

    >
    > > I couldn't persuade James to change his mind.

    >
    > > Weng

    >
    > Weng,
    >
    > What would happen in a simulator if the "orif" conditions were not
    > actually mutually exclusive? How would you allow the user to define
    > said behavior? Is zero-hot and option, or is one-hot guaranteed? How
    > would the user define that?
    >
    > The existing language allows for mutually exclusive conditions, but
    > said conditions must be statically verifiable as mutex and complete
    > (case statements). For dynamic mutex inputs, verification is best
    > handled in an assertion. If a standardized one_hot() or zero_one_hot()
    > function could be created (to operate on an unconstrained vector of
    > booleans, for example), then synthesis could recognize their use in an
    > assertion, and make the appropriate optimizations automatically,
    > without affecting the syntax or structure of the language. The
    > assertion (or other code) could also control what happens when, in
    > fact, the conditions are not mutually exclusive (the same way the
    > language handles indices out of bounds, etc.). In other words, in
    > order to gain that level of control over what happens if mutex is not
    > true, you'd have to use the same amount of code for either solution,
    > and the latter solution does not require a change to the language.
    > Additionally, the use of an assertion is such an application allows
    > the code more flexibility in describing the resulting behavior,
    > without resulting to a single if-orif tree. Simply tell the synthesis
    > tool that, by the way, x and y are one_hot, and it can make
    > optimizations (like sharing resources) efficiently, independent of the
    > rest of the structure.
    >
    > Finally, "orif" would be a very poor choice for such a keyword, even
    > if the feature were a good idea. "Orif" by name implies that multiple
    > conditions are potentially true (logical 'OR' function), and all
    > statements associated with all true conditions would be executed,
    > which is precisely the opposite of what you described. This behavior
    > is equivalent to multiple, non-nested if-then statements.
    >
    > Andy- Hide quoted text -
    >
    > - Show quoted text -


    Hi Andy,
    A group of signals is defined as mutually exclusive if either no
    signal or only one signal in the group is asserted on any cycle.

    Keyword 'orif' has the same language grammar definition as 'elsif'
    with one exception: conditional signal contained in leading 'if' or
    'elsif' segment and conditional signals contained in the subsequent
    and contiguous 'orif' segment in an 'if' statement are mutually
    exclusive. Where keyword 'elsif' can be used in a VHDL code, there
    keyword 'orif' can be used.

    Here is an example on how to use keyword 'orif':

    If(E0 = '1') then
    State_A <= E0_S;
    Orif(E1 = '1') then
    State_A <= E_S;
    Orif(E2 = '1') then
    State_A <= E2_S;
    elsIf(E3 = '1') then
    State_A <= E3_S;
    Orif(E4 = '1') then
    State_A <= E4_S;
    Orif(E5 = '1') then
    State_A <= E5_S;
    elsIf(E6 = '1') then
    ....

    It has two mutually exclusive signal groups: signals E0, E1 and E2 are
    mutually exclusive. So are signals E3, E4 and E5.

    The implementation benefits with FPGA are huge !!!

    For example:

    OutBus has 64-bit width.

    OutBusA : process(RESET, CLK)
    begin
    if(RESET = '1') then
    OutBus <= (others=>'0');
    elsif(CLK'event and CLK = '1') then
    If(E0 = '1') then
    OutBus <= Data0;
    orif(E1 = '1') then
    OutBus <= Data1;
    orif(E2 = '1') then
    OutBus <= Data2;
    orif(E3 = '1') then
    OutBus <= Data3;
    orif(E4 = '1') then
    OutBus <= Data4;
    orif(E5 = '1') then
    OutBus <= Data5;
    end if;
    end if
    end process;

    1. If the keyword 'orif' is adopted as a VHDL standard, the above
    equation would be executed in FPGA chips not by mux, not by case
    statement implementation method, but by the most efficient method:
    carry chain in Xilinx chips !!!

    It would be executed like a sum of products: In assembly language for
    shortness:
    OutBus = E0*Data0 + E1*Data1 + ... + E5*Data5;

    The new keyword 'orif' is most beneficial to FPGA users !!!

    Please check Xilinx application note about how to implement sum of the
    products (I failed to find it)

    In other words, if keyword 'orif' is introduced into VHDL standard,
    Xilinx carry chain structure would become part of VHDL standard in a
    natural way. 'orif' will be refered to carry chain in FPGA
    structure !!!

    Xilinx Peter, what your idea is about the keyword 'orif'?

    2. If the keyword 'orif' is adopted as a VHDL standard, it can specify
    that during simulation, if a simulator detects two signals being
    active in a mutually exclusive group on current cycle, simulator
    issues a fatal error and stops without any user's interference !!!

    Simple and reliable !!!

    3. I expect Xilinx would be the first company to implement the new
    keyword 'orif', because its fastest carry chain feature would be best
    used in the situations without users' efforts to change its writing
    patterns. You may imagine 64-bit data bus would occupy a lot of space
    and resources if not the best carry chains are referenced. And the
    routine timing will be hugely saved and running frequency will hugely
    boosted.

    4. 'orif' name is very appropriate. It means if above conditional
    equation is not met, or try this one, or try next, or try the
    last, ... it meets the equation above in assembly.

    5. Most of programmers never use mutually exclusive property in their
    designs and they fear the property would be violated some times. But
    here are some hints the violation situation will never happen if it is
    appropriate.

    a. Data buses are always mutually exclusive !!!

    If two data conditions on a data bus may be active at the same cycle,
    add minimum additional conditions to make them mutually exclusive.

    b. Count loadings are always mutually exclusive !!!

    c. All group of register's loadings are always mutually exclusive !!!

    d. All FIFO input data loadings are mutually exclusive !!!

    6. Keyword 'orif' is useless for IC chip design. Because IC compilers
    do their best to optimize them.

    7. Mutually exclusiveness is ubiquitout in logic design and I am very
    sorry for VHDL without a special keyword to deal with it.

    Any comments are welcome.

    Weng
     
    Weng Tianxiang, Aug 28, 2007
    #1
    1. Advertising

  2. On Tue, 28 Aug 2007 01:11:47 -0000,
    Weng Tianxiang <> wrote:

    >I open a new topics from previous one to try to stir another round to
    >introduce a new keyword 'orif'.


    Weng,

    It seems to me that what you are trying to do is very similar
    to SystemVerilog's "unique" and "priority" keywords. It is
    not completely clear from your posts exactly what the semantics
    of "orif" should be, but as I understand it you intend that
    "orif" should have exactly the same behaviour as "elsif",
    together with a mutual-exclusivity check so that it is an
    error if more than one of the "if" conditions is true.
    I agree that this is a desirable thing to be able to say.

    I do not fully understand how your combinations of "orif"
    and "elsif" are intended to work.

    It is also desirable to be able to specify that *at least*
    one of the conditions is true. And then you can combine
    the "at-least-one" and "at-most-one" tests to guarantee
    that there is EXACTLY one condition true. Note that
    SystemVerilog got this wrong, in my opinion: "unique"
    enforces exactly-one, and "priority" enforces at-least-one,
    so there is no easy way to specify at-most-one.

    It is easier in VHDL than Verilog, because the test
    expressions cannot have side-effects.
    --
    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, Aug 28, 2007
    #2
    1. Advertising

  3. Weng Tianxiang <> writes:
    [lots of stuff]

    What you are looking for seems to be more or less equivalent to
    SystemVerilog's `unique if' statement. It could have been written
    using a case statement instead but I was trying to stay close to the
    proposed VHDL syntax.

    Synthesis and formal tools *may* use that information. Simulation
    gives you a run-time error in case of a violation.

    ,----
    | module unique_if;
    | bit clk, reset;
    |
    | logic E0, E1, E2, E3, E4, E5;
    | logic [0:5] E;
    |
    | logic [7:0] OutBus;
    | logic [7:0] Data [0:5] = '{ 0, 1, 2, 3, 4, 5 };
    |
    |
    | initial begin
    | clk <= 0;
    | reset <= 1;
    | #20ns;
    | reset <= 0;
    | end
    |
    | always clk = #5ns ~clk;
    |
    | always @(posedge clk, posedge reset) begin
    | if(reset)
    | OutBus <= 0;
    | else begin
    | void'(randomize(E) with {
    | E inside { 1, 2, 4, 8, 16, 32, 10 }; // note the occurence of 10
    | });
    |
    | {E0, E1, E2, E3, E4, E5} = E;
    |
    | unique if(E0) OutBus <= Data[0];
    | else if(E1) OutBus <= Data[1];
    | else if(E2) OutBus <= Data[2];
    | else if(E3) OutBus <= Data[3];
    | else if(E4) OutBus <= Data[4];
    | else if(E5) OutBus <= Data[5];
    | end
    | end
    |
    | endmodule : unique_if
    `----

    Regards,
    Marcus

    --
    note that "property" can also be used as syntaxtic sugar to reference
    a property, breaking the clean design of verilog; [...]

    (seen on http://www.veripool.com/verilog-mode_news.html)
     
    Marcus Harnisch, Aug 28, 2007
    #3
  4. Weng Tianxiang wrote:

    > I open a new topics from previous one to try to stir another round to
    > introduce a new keyword 'orif'.


    The old bait and switch.
    I've been trolled again.

    -- Mike Treseler
     
    Mike Treseler, Aug 28, 2007
    #4
  5. Weng Tianxiang

    KJ Guest

    On Aug 27, 9:11 pm, Weng Tianxiang <> wrote:
    > Hi,
    > I open a new topics from previous one to try to stir another round to
    > introduce a new keyword 'orif'.
    >
    >
    > > > One thing I miss a lot is 'orif' keyword compared to 'elsif'.

    >
    > > > 'orif' introduces a group of conditions that are mutually exclusive.

    >
    > > > On any output buses or input buses, all data running on the buses are
    > > > mutually exclusive.

    >
    > > > I couldn't persuade James to change his mind.

    >

    Jim Lewis doesn't own the VHDL language standard nor is he a
    gatekeeper that prevents suggestions from being submitted. His clout
    kicks in more after the submission....but that's off on a tangent.

    > Keyword 'orif' has the same language grammar definition as 'elsif'
    > with one exception: conditional signal contained in leading 'if' or
    > 'elsif' segment and conditional signals contained in the subsequent
    > and contiguous 'orif' segment in an 'if' statement are mutually
    > exclusive. Where keyword 'elsif' can be used in a VHDL code, there
    > keyword 'orif' can be used.
    >
    > Here is an example on how to use keyword 'orif':
    >
    > If(E0 = '1') then
    > State_A <= E0_S;
    > Orif(E1 = '1') then
    > State_A <= E_S;
    > Orif(E2 = '1') then
    > State_A <= E2_S;
    > elsIf(E3 = '1') then
    > State_A <= E3_S;
    > Orif(E4 = '1') then
    > State_A <= E4_S;
    > Orif(E5 = '1') then
    > State_A <= E5_S;
    > elsIf(E6 = '1') then
    > ...
    >

    Doesn't grab me much but I don't find it offensive either, just
    different.

    > It has two mutually exclusive signal groups: signals E0, E1 and E2 are
    > mutually exclusive. So are signals E3, E4 and E5.

    Only because you say they are mutually exclusive though. I can
    guarantee exclusivity by using existing VHDL enumerated types and a
    single signal.

    >
    > The implementation benefits with FPGA are huge !!!
    >

    Might want to consider less use of the exclamation point in the
    future.

    > For example:
    >
    > OutBus has 64-bit width.
    >
    > OutBusA : process(RESET, CLK)
    > begin
    > if(RESET = '1') then
    > OutBus <= (others=>'0');
    > elsif(CLK'event and CLK = '1') then
    > If(E0 = '1') then
    > OutBus <= Data0;
    > orif(E1 = '1') then
    > OutBus <= Data1;
    > orif(E2 = '1') then
    > OutBus <= Data2;
    > orif(E3 = '1') then
    > OutBus <= Data3;
    > orif(E4 = '1') then
    > OutBus <= Data4;
    > orif(E5 = '1') then
    > OutBus <= Data5;
    > end if;
    > end if
    > end process;
    >
    > 1. If the keyword 'orif' is adopted as a VHDL standard, the above
    > equation would be executed in FPGA chips not by mux, not by case
    > statement implementation method, but by the most efficient method:
    > carry chain in Xilinx chips !!!
    >
    > It would be executed like a sum of products: In assembly language for
    > shortness:
    > OutBus = E0*Data0 + E1*Data1 + ... + E5*Data5;


    You seem to be forgetting the multiply operation in your above
    equation it's not 'just' adding Data0, Data1, etc. Also, if I were
    faced with this situation and today's syntax I would probably code it
    as...

    OutBus = F(E0, Data0) + F(E1, Data1) + ... + F(E5, Data5);

    where F() is a function that returned either the second argument or 0
    based on how the first argument is set...in other words a simple
    couple line function that accomplishes a specific task. If the number
    of 'Data' elements was parameterized I might decide to embed that into
    the function as well and pass in an array of 'Data' instead of
    'Data0'...'Data5'....but that's just me.

    > Please check Xilinx application note about how to implement sum of the
    > products (I failed to find it)

    Hmmm....don't think you gain much credibility with that statement.

    >
    > In other words, if keyword 'orif' is introduced into VHDL standard,
    > Xilinx carry chain structure would become part of VHDL standard in a
    > natural way. 'orif' will be refered to carry chain in FPGA
    > structure !!!

    You seem to be forgetting something very basic....if it can be
    implemented with a carry chain at all, it can be done with today's
    syntax as well.

    > 2. If the keyword 'orif' is adopted as a VHDL standard, it can specify
    > that during simulation, if a simulator detects two signals being
    > active in a mutually exclusive group on current cycle, simulator
    > issues a fatal error and stops without any user's interference !!!

    Hmmm....but you said that they were mutually exclusive but now you're
    alluding to the possibility that they might not. So what would happen
    in the implemented hardware? No assertions there, just logic
    implemented as LUT (FPGA), and/or (CPLD), gates (ASIC). The hardware
    will do something and it probably will do something inappropriate
    without a language guarantee that the collection is mutually exclusive
    as it is supposed to be....which is precisely what enumerated types do
    for you.

    >
    > Simple and reliable !!!

    You haven't sold me on the 'reliable' part. The 'simple' part is OK,
    but it's not much simpler than what can be done today so the relative
    measure of 'simple' is pretty low in this case in my opinion. Having
    to wonder about how exclusivity is guaranteed, how can I mess it up
    and things like that don't excite me.

    >
    > 3. I expect Xilinx would be the first company to implement the new
    > keyword 'orif', because its fastest carry chain feature would be best
    > used in the situations without users' efforts to change its writing
    > patterns.

    Gosh I hope not....implement the language standard not somebody's
    extensions.

    > You may imagine 64-bit data bus would occupy a lot of space
    > and resources if not the best carry chains are referenced. And the
    > routine timing will be hugely saved and running frequency will hugely
    > boosted.

    Got anything to back up those claims? The language extension that
    you're proposing will do absolutely nothing to the final hardware,
    there will be no savings of any kind. What you're proposing is (at
    best) a designer productivity improvement (i.e. lines of working code
    per unit of time). To suggest that a new language keyword would
    result in better resource usage is suspect. Have you benchmarked
    exactly how things get implemented today using functionally equivalent
    logic? Boolean logic does not require language keywords beyond 'and',
    'or' and 'not'. Designer productivity increases with higher level
    abstractions but I'm not seeing much, if any, improvement to be gained
    by 'orif'.

    >
    > 4. 'orif' name is very appropriate. It means if above conditional
    > equation is not met, or try this one, or try next, or try the
    > last, ... it meets the equation above in assembly.

    'elsif' on an enumerated type signal does that as well and is just as
    descriptive as 'orif'.

    >
    > 5. Most of programmers never use mutually exclusive property in their
    > designs and they fear the property would be violated some times.

    Got any basis for that statement? Programmers? Doing VHDL? I'd
    guess that they would catch on to either enumerated types or functions
    pretty quickly though.

    > But
    > here are some hints the violation situation will never happen if it is
    > appropriate.
    >
    > a. Data buses are always mutually exclusive !!!

    Does that even mean anything?
    >
    > If two data conditions on a data bus may be active at the same cycle,
    > add minimum additional conditions to make them mutually exclusive.

    And how do those conditions get satisfied and guaranteed? Hmmm...

    >
    > 7. Mutually exclusiveness is ubiquitout in logic design and I am very
    > sorry for VHDL without a special keyword to deal with it.

    What is it about enumerated types in VHDL that you find so hard?

    KJ
     
    KJ, Aug 28, 2007
    #5
  6. Weng Tianxiang

    Jim Lewis Guest

    Weng,
    > Hi,
    > I open a new topics from previous one to try to stir another round to
    > introduce a new keyword 'orif'.


    My conclusion from our numerous previous discussions
    on this topic are that for simple cases it looks
    intuitive and makes the syntax look deceptively
    attractive, however, for more interesting conditions,
    it becomes difficult if not impossible to identify the
    mutually exclusive items and, hence, you will get
    little to no benefit from it. So I was tickled to see
    that SystemVerilog decided to implement something similar
    to this, however, I would suspect that they do not give
    you quite the flexibility that you want.

    On the other hand, as I mentioned previously and Andy
    pointed out in the thread you quoted (repeated below):
    "For dynamic mutex inputs, verification is best
    handled in an assertion. If a standardized one_hot() or zero_one_hot()
    function could be created (to operate on an unconstrained vector of
    booleans, for example), then synthesis could recognize their use in an
    assertion, and make the appropriate optimizations automatically,
    without affecting the syntax or structure of the language. The
    assertion (or other code) could also control what happens when, in
    fact, the conditions are not mutually exclusive (the same way the
    language handles indices out of bounds, etc.). In other words, in
    order to gain that level of control over what happens if mutex is not
    true, you'd have to use the same amount of code for either solution,
    and the latter solution does not require a change to the language."

    I also note that some synthesis tools have started to support assertions
    in synthesis. Synthesis support is a separate topic and is similar
    whether it is an assertion or a built-in language feature.

    For your code of the form:
    If(E0 = '1') then
    State_A <= E0_S;
    Orif(E1 = '1') then
    State_A <= E_S;
    Orif(E2 = '1') then
    State_A <= E2_S;

    The assertion that would allow this code to be written with only elsif is:
    assert zero_one_hot (E0, E1, E2) ;

    I noted that in your code you mixed orif mixed with elsif (copied below),
    was this intentional? One hand, these could convey exactly what I want
    (because there are many cases like this), OTOH, it could be a mistake.
    Hence the intent is ambiguous and during a design review, one would have
    to pay particular attention to this and ask questions about your intent
    and its validation. A copy of your code is below.

    If(E0 = '1') then
    State_A <= E0_S;
    Orif(E1 = '1') then
    State_A <= E_S;
    Orif(E2 = '1') then
    State_A <= E2_S;
    elsIf(E3 = '1') then
    State_A <= E3_S;
    Orif(E4 = '1') then
    State_A <= E4_S;
    Orif(E5 = '1') then
    State_A <= E5_S;
    elsIf(E6 = '1') then

    On the other hand, with assertions, the following assertions
    allow the above code to be written using elsif. In addition,
    in this case, it is very clear about which I want to be
    mutually exclusive.
    assert zero_one_hot (E0, E1, E2) ;
    assert zero_one_hot (E3, E4, E5) ;

    Also note that if you are using std_logic or bit types, with the
    Accellera VHDL-2006 revision you can write:
    OutBusA : process(RESET, CLK)
    begin
    if(RESET = '1') then
    OutBus <= (others=>'0');
    elsif rising_edge(CLK) then
    if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then
    OutBus <=
    (E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
    (E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
    end if ;
    end if ;
    end process;

    You can also leave out the = '1' in VHDL-2006:
    if E0 or E1 or E2 or E3 or E4 or E5 then

    I also note that SystemVerilog added the keywords priority and
    unique. The danger in adding new keywords is that they may
    conflict with a name (signal, ...) already used in someone's design
    and cause an old design to be a syntax error in the new language
    revision. This generally does not please people and means they
    have to add special handling for the file (compile flags).

    What we need in the future revisions of the language is capability.
    This does not necessarily mean adding new keywords.


    > 7. Mutually exclusiveness is ubiquitout in logic design ...

    I agree with this part. The language needs a capability to effectively
    handle mutual exclusion.

    The PSL extension brings us one_hot and zero_one_hot functions.
    These functions are visible within a PSL assert statement (but not
    a VHDL assert statement). As a result as long as you used a form
    of assert that is compatible with PSL, you can do this with any
    simulator or synthesis tool that supports Accellera VHDL-2006.
    If the tool does not support it, you can file a bug and/or
    enhancement against it to get the feature added.


    If you wish to continue this discussion, please re-post (from 1 year
    ago?) that show your more complex examples, identify the conditions
    that you want to be mutually exclusive, and explain how you think
    a tool should extract/determine those conditions.


    Best,
    Jim
     
    Jim Lewis, Aug 28, 2007
    #6
  7. On Aug 28, 4:15 am, Jonathan Bromley <>
    wrote:
    > On Tue, 28 Aug 2007 01:11:47 -0000,
    >
    > Weng Tianxiang <> wrote:
    > >I open a new topics from previous one to try to stir another round to
    > >introduce a new keyword 'orif'.

    >
    > Weng,
    >
    > It seems to me that what you are trying to do is very similar
    > to SystemVerilog's "unique" and "priority" keywords. It is
    > not completely clear from your posts exactly what the semantics
    > of "orif" should be, but as I understand it you intend that
    > "orif" should have exactly the same behaviour as "elsif",
    > together with a mutual-exclusivity check so that it is an
    > error if more than one of the "if" conditions is true.
    > I agree that this is a desirable thing to be able to say.
    >
    > I do not fully understand how your combinations of "orif"
    > and "elsif" are intended to work.
    >
    > It is also desirable to be able to specify that *at least*
    > one of the conditions is true. And then you can combine
    > the "at-least-one" and "at-most-one" tests to guarantee
    > that there is EXACTLY one condition true. Note that
    > SystemVerilog got this wrong, in my opinion: "unique"
    > enforces exactly-one, and "priority" enforces at-least-one,
    > so there is no easy way to specify at-most-one.
    >
    > It is easier in VHDL than Verilog, because the test
    > expressions cannot have side-effects.
    > --
    > 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
    > ://www.MYCOMPANY.com
    >
    > The contents of this message may contain personal views which
    > are not the views of Doulos Ltd., unless specifically stated.


    Hi Jonathan,
    1. How 'elsif' and 'orif' work together?

    See the following example:

    If(E0 = '1') then
    State_A <= E0_S;
    Orif(E1 = '1') then
    State_A <= E_S;
    Orif(E2 = '1') then
    State_A <= E2_S;

    elsIf(E3 = '1') then
    State_A <= E3_S;
    Orif(E4 = '1') then
    State_A <= E4_S;
    Orif(E5 = '1') then
    State_A <= E5_S;
    elsIf(E6 = '1') then

    'if', 'elsif' and 'else' play a role like brackets, putting together a
    group of signals that are grouped with 'orif' between them to specify
    mutually exclusiveness : there are two groups: (E0, E1, E2), (E3, E4,
    E5) and signals in each group are mutually exclusive. Other grammar
    meanings remain unchanged: It also means that if one of (E0, E1, E2)
    is true, then 'if' statement is finished, otherwise try to test (E3,
    E4, E5), like an usual 'if' statement.

    The keyword 'orif' only adds the meaning that all signals in the group
    are mutually exclusive, no more meaning is added. But it is enough for
    compiler to do a smart job with the extra information.

    For example, in the above example, two parallel carry chains can be
    generated, then another LUT to put them together or more efficient LUT
    allocations.

    What I want is to transfer to a VHDL compiler the information that
    there is mutually exclusive information about them and use them in
    best interest of timing.

    3. "It is also desirable to be able to specify that *at least*
    one of the conditions is true. "

    No such requirement is needed based on the fact that any 'if'
    statement is complete: it means there is at least one hit, no more
    than 2.
    For example, the following example :
    if(..) then
    ...
    orif(...)
    ...
    orif(...)
    ...
    else
    ... <--- default hit
    end if;

    if(..) then
    ...
    orif(...)
    ...
    orif(...)
    ...
    end if;

    Above example is logically equivalent to the following one:
    if(..) then
    ...
    orif(...)
    ...
    orif(...)
    ...
    else
    null; <--- default hit
    end if;

    It likes the following example with 'elsif'
    if(..) then
    ...
    elsif(...)
    ...
    elsif(...)
    ...
    else
    null; <--- default hit
    end if;

    3. I am not fimiliar with Verilog, but from Marcus posting, I know
    there is a definitive advantage of my method over Verilog's:
    You have never to specify "at-least-one" and "at-most-one" tests. No.
    'if' statement structure in sequential process has already null
    statement as its default value as following examples show.

    A2 : process(RESET, CLK)
    begin
    if(RESET = '1') then
    State_A <= State_0_S;
    elsif(CLK'event and CLK = '1') then
    case State_A is
    when State_0_S =>
    if(A = '1') then
    State_A <= State_1_S;
    else
    null;
    end if;
    ...
    ...
    end case;
    end if;
    end process;


    A3 : process(RESET, CLK)
    begin
    if(RESET = '1') then
    State_A <= State_0_S;
    elsif(CLK'event and CLK = '1') then
    case State_A is
    when State_0_S =>
    if(A = '1') then
    State_A <= State_1_S;
    end if;
    ...
    ...
    end case;
    end if;
    end process;


    Jonathan, I would like to address any concern you will rise.

    Thank you.

    Weng
     
    Weng Tianxiang, Aug 28, 2007
    #7
  8. (Restricting this to comp.arch.vhdl only)

    On Tue, 28 Aug 2007 11:30:44 -0700,
    Weng Tianxiang <> wrote:

    >1. How 'elsif' and 'orif' work together?
    >
    >See the following example:
    >
    >If(E0 = '1') then
    > State_A <= E0_S;
    >Orif(E1 = '1') then
    > State_A <= E_S;
    >Orif(E2 = '1') then
    > State_A <= E2_S;
    >
    >elsIf(E3 = '1') then
    > State_A <= E3_S;
    >Orif(E4 = '1') then
    > State_A <= E4_S;
    >Orif(E5 = '1') then
    > State_A <= E5_S;
    >elsIf(E6 = '1') then
    >
    >'if', 'elsif' and 'else' play a role like brackets, putting together a
    >group of signals that are grouped with 'orif' between them to specify
    >mutually exclusiveness : there are two groups: (E0, E1, E2), (E3, E4,
    >E5) and signals in each group are mutually exclusive. Other grammar
    >meanings remain unchanged: It also means that if one of (E0, E1, E2)
    >is true, then 'if' statement is finished, otherwise try to test (E3,
    >E4, E5), like an usual 'if' statement.
    >
    >The keyword 'orif' only adds the meaning that all signals in the group
    >are mutually exclusive, no more meaning is added.


    OK, so to try to put this a little more precisely:

    'orif' has exactly the same execution semantics as 'elsif',
    EXCEPT THAT
    any group of branch tests, starting with if or elsif and
    continuing through any number of orif with no intervening
    elsif, are evaluated together and if more than one of those
    tests evaluates to TRUE then it shall be an error.

    Note that this mandates the evaluation of ALL tests in the
    set before any decision is made, whereas regular VHDL
    executes them one by one, only moving on to the next if
    the current test is false.

    Question: In the following example Tn are Boolean expressions,
    and Sn are statement blocks.

    if T1 S1
    orif T2 S2
    orif T3 S3 --- T1, T2, T3 are mutually exclusive
    elsif T4 S4
    orif T5 S5 --- T4, T5 are mutually exclusive
    else S6

    If (T1 OR T2 OR T3) is true, do we then also check T4/T5 for
    mutual exclusivity? Both answers (yes, no) have potential
    disadvantages.

    There are some VERY tricky problems with language definition
    if any of the Tn tests calls an impure function that may influence
    the results of another Tn test - SystemVerilog has already had
    trouble with that one.

    I still don't understand how you intend to deal with the
    practically-common "exactly one" requirement. A final else
    doesn't do what I want, because it simply provides an execution
    path when all the Tn are false; it does not provide me with a
    check that exactly one of the Tn is true.

    >What I want is to transfer to a VHDL compiler the information that
    >there is mutually exclusive information about them and use them in
    >best interest of timing.


    As I've already said, this is a worthy objective. Jim Lewis has
    suggested it could be done with assertions. I suspect, though,
    that a specialized language construct might be a more satisfactory
    solution; the use of assertions means that a synthesis tool must
    tie together two distinct language constructs, with a wide variety
    of possible coding styles and the risk of very wide separation of
    the two constructs (conditional and assertion). SystemVerilog
    synthesis tools are gaining real practical benefit from the
    "unique" and "priority" keywords today, but I know of no
    synthesis tool that exploits explicit assertions to
    improve its optimization.

    >3. I am not fimiliar with Verilog, but from Marcus posting, I know
    >there is a definitive advantage of my method over Verilog's:
    >You have never to specify "at-least-one" and "at-most-one" tests.


    This is not a convincing point. SystemVerilog simply has two
    new keywords that can be used as a prefix to 'if' or 'case'.
    That is surely no worse than the need to remember a new
    'orif' keyword. It's a difference of detail only, and at
    present your approach is weaker because it has no way to
    specify exactly-one or at-least-one among a set of tests.
    (As Marcus and I have both said already, SystemVerilog
    has probably got this slightly wrong - but it *does*
    offer all the possibilities, which your 'orif' does not).

    Keep provoking the community with good ideas - you're doing
    a great job - but this one needs more work, I'm afraid.
    --
    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, 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, Aug 28, 2007
    #8
  9. Weng Tianxiang

    Andy Guest

    On Aug 28, 12:21 pm, Jim Lewis <> wrote:
    >
    > I noted that in your code you mixed orif mixed with elsif (copied below),
    > was this intentional? One hand, these could convey exactly what I want
    > (because there are many cases like this), OTOH, it could be a mistake.
    > Hence the intent is ambiguous and during a design review, one would have
    > to pay particular attention to this and ask questions about your intent
    > and its validation. A copy of your code is below.
    >
    > If(E0 = '1') then
    > State_A <= E0_S;
    > Orif(E1 = '1') then
    > State_A <= E_S;
    > Orif(E2 = '1') then
    > State_A <= E2_S;
    > elsIf(E3 = '1') then
    > State_A <= E3_S;
    > Orif(E4 = '1') then
    > State_A <= E4_S;
    > Orif(E5 = '1') then
    > State_A <= E5_S;
    > elsIf(E6 = '1') then
    >
    > On the other hand, with assertions, the following assertions
    > allow the above code to be written using elsif. In addition,
    > in this case, it is very clear about which I want to be
    > mutually exclusive.
    > assert zero_one_hot (E0, E1, E2) ;
    > assert zero_one_hot (E3, E4, E5) ;


    I would have (perhaps mistakenly?) interpreted the orif/elsif syntax
    as:
    also meaning:

    assert zero_one_hot(E0, E1, E2, E4, E5);

    My point (and Jim's) is that this is one very good reason why such a
    seemingly simple language change is not a good idea when you look
    under the hood.

    Actually, would the correct syntax be:

    assert zero_one_hot((e0, e1, e2, e4, e5)); -- one array argument

    or does the psl zero_one_hot() function actually accept a variable
    number of arguments?

    I would really like to see one_hot() and zero_one_hot() as standard
    vhdl (not just psl) functions, usable in an assert statement for this
    purpose. The reason is that I don't see synthesis vendors using PSL at
    any point in the future (there's just way too much there that would
    never be relevant to synthesis). But they could easily parse simple
    vhdl assertions with specific, standard functions to extract
    meaningful information about the description.

    As to the use of enumerated types, that works fine, as long as you
    have access to the source of the signals, where you can re-create them
    as an enumerated type. If they are primary (chip level) inputs, you do
    not have a choice. And you cannot "translate" them into an enumerated
    type, since the translation will incorporate priority logic of some
    sort.

    There are many cases where the tools could do a better job of
    inferring mutual exclusivity:

    enable := (others => '0');
    for i in enable'range loop
    if address = i then
    enable(i) := '1';
    end if;
    end loop;

    Most synthesis tools can figure out that enable is zero_one_hot.

    Where the problem comes in is that if you want to use enable in the
    next clock cycle (or later). After all, if you only needed to use it
    immediately, you would dispense with the enable vector, and just put
    the action that "enable" enables in the if-then statement directly.

    But as soon as you want to store the enables for a clock cycle or
    more, every synthesis tool I've seen fails to realize that enable is
    still mutually exclusive. So far, the only solutions that I've seen
    include manually coding an and-or tree (unreadable), coding it as tri-
    state logic (and letting the tool convert to multiplexers; misleading,
    and does not handle zero_hot), or coding it in the same clock cycle,
    and using register retiming to spread it back out (not entirely
    reliable, and not generally extensible past one clock cycle).


    Andy
     
    Andy, Aug 28, 2007
    #9
  10. On Aug 28, 10:21 am, Jim Lewis <> wrote:
    > Weng,
    >
    > > Hi,
    > > I open a new topics from previous one to try to stir another round to
    > > introduce a new keyword 'orif'.

    >
    > My conclusion from our numerous previous discussions
    > on this topic are that for simple cases it looks
    > intuitive and makes the syntax look deceptively
    > attractive, however, for more interesting conditions,
    > it becomes difficult if not impossible to identify the
    > mutually exclusive items and, hence, you will get
    > little to no benefit from it. So I was tickled to see
    > that SystemVerilog decided to implement something similar
    > to this, however, I would suspect that they do not give
    > you quite the flexibility that you want.
    >
    > On the other hand, as I mentioned previously and Andy
    > pointed out in the thread you quoted (repeated below):
    > "For dynamic mutex inputs, verification is best
    > handled in an assertion. If a standardized one_hot() or zero_one_hot()
    > function could be created (to operate on an unconstrained vector of
    > booleans, for example), then synthesis could recognize their use in an
    > assertion, and make the appropriate optimizations automatically,
    > without affecting the syntax or structure of the language. The
    > assertion (or other code) could also control what happens when, in
    > fact, the conditions are not mutually exclusive (the same way the
    > language handles indices out of bounds, etc.). In other words, in
    > order to gain that level of control over what happens if mutex is not
    > true, you'd have to use the same amount of code for either solution,
    > and the latter solution does not require a change to the language."
    >
    > I also note that some synthesis tools have started to support assertions
    > in synthesis. Synthesis support is a separate topic and is similar
    > whether it is an assertion or a built-in language feature.
    >
    > For your code of the form:
    > If(E0 = '1') then
    > State_A <= E0_S;
    > Orif(E1 = '1') then
    > State_A <= E_S;
    > Orif(E2 = '1') then
    > State_A <= E2_S;
    >
    > The assertion that would allow this code to be written with only elsif is:
    > assert zero_one_hot (E0, E1, E2) ;
    >
    > I noted that in your code you mixed orif mixed with elsif (copied below),
    > was this intentional? One hand, these could convey exactly what I want
    > (because there are many cases like this), OTOH, it could be a mistake.
    > Hence the intent is ambiguous and during a design review, one would have
    > to pay particular attention to this and ask questions about your intent
    > and its validation. A copy of your code is below.
    >
    > If(E0 = '1') then
    > State_A <= E0_S;
    > Orif(E1 = '1') then
    > State_A <= E_S;
    > Orif(E2 = '1') then
    > State_A <= E2_S;
    > elsIf(E3 = '1') then
    > State_A <= E3_S;
    > Orif(E4 = '1') then
    > State_A <= E4_S;
    > Orif(E5 = '1') then
    > State_A <= E5_S;
    > elsIf(E6 = '1') then
    >
    > On the other hand, with assertions, the following assertions
    > allow the above code to be written using elsif. In addition,
    > in this case, it is very clear about which I want to be
    > mutually exclusive.
    > assert zero_one_hot (E0, E1, E2) ;
    > assert zero_one_hot (E3, E4, E5) ;
    >
    > Also note that if you are using std_logic or bit types, with the
    > Accellera VHDL-2006 revision you can write:
    > OutBusA : process(RESET, CLK)
    > begin
    > if(RESET = '1') then
    > OutBus <= (others=>'0');
    > elsif rising_edge(CLK) then
    > if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then
    > OutBus <=
    > (E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
    > (E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
    > end if ;
    > end if ;
    > end process;
    >
    > You can also leave out the = '1' in VHDL-2006:
    > if E0 or E1 or E2 or E3 or E4 or E5 then
    >
    > I also note that SystemVerilog added the keywords priority and
    > unique. The danger in adding new keywords is that they may
    > conflict with a name (signal, ...) already used in someone's design
    > and cause an old design to be a syntax error in the new language
    > revision. This generally does not please people and means they
    > have to add special handling for the file (compile flags).
    >
    > What we need in the future revisions of the language is capability.
    > This does not necessarily mean adding new keywords.
    >
    > > 7. Mutually exclusiveness is ubiquitout in logic design ...

    > I agree with this part. The language needs a capability to effectively
    > handle mutual exclusion.
    >
    > The PSL extension brings us one_hot and zero_one_hot functions.
    > These functions are visible within a PSL assert statement (but not
    > a VHDL assert statement). As a result as long as you used a form
    > of assert that is compatible with PSL, you can do this with any
    > simulator or synthesis tool that supports Accellera VHDL-2006.
    > If the tool does not support it, you can file a bug and/or
    > enhancement against it to get the feature added.
    >
    > If you wish to continue this discussion, please re-post (from 1 year
    > ago?) that show your more complex examples, identify the conditions
    > that you want to be mutually exclusive, and explain how you think
    > a tool should extract/determine those conditions.
    >
    > Best,
    > Jim


    Hi Jim,
    "I agree with this part. The language needs a capability to
    effectively
    handle mutual exclusion."

    1. This is a step forward from my point of view.

    2. We have to admit that there are many ways to do it.

    3. My example is right and intend to do that. See my answer to
    Jonathan Bromley.

    4. Keyword 'orif' can be inserted in any places in a 'if' statement to
    specify any group of conditions having mutually exclusiveness.

    5. Your method using
    assert zero_one_hot (E0, E1, E2) ;
    assert zero_one_hot (E3, E4, E5) ;
    is OK.

    Here is an example that shows your method's drawback you have to
    admit:
    if(TWindowLoad_E0_L_H and nC_BE_R0(3) = '0') then
    TWindow_3(10 downto 8) <= AD_R0(26 downto 24);

    orif(TWindowLoad_E0_H_H and nC_BE_R0(7) = '0') then
    TWindow_3(10 downto 8) <= AD_R0(58 downto 56);
    end if;

    You have to write 5 more statements than mine:

    signal A1 : boolean;
    signal A2 : boolean;
    assert zero_one_hot (A1, A2) ;

    A1 <= TWindowLoad_E0_L_H and nC_BE_R0(3) = '0';
    A2 <= TWindowLoad_E0_H_H and nC_BE_R0(7) = '0';

    if(A1) then
    TWindow_3(10 downto 8) <= AD_R0(26 downto 24);

    elsif(A2) then
    TWindow_3(10 downto 8) <= AD_R0(58 downto 56);
    end if;

    The more signals are invovled, the more statements are added, and more
    likely it is possible to be wrong or missing something.

    6. The keyword 'orif' is defined to refer to carry chain structure in
    FPGA to get essential timing advantages over other competing methods.

    if(E0 = '1') then
    OutBus(63 downto 0) <= Data0(63 downto 0);
    orif(E1 = '1') then
    OutBus(63 downto 0) <= Data1(63 downto 0);
    orif(E2 = '1') then
    OutBus(63 downto 0) <= Data2(63 downto 0);
    end if;

    Its implementation equation should look like this:
    OutBus = E0*Data0 + E1*Data1 + E2*Data2 + OutBus;

    Because 'else' and its null statement are defaulted.

    Its carry chain bottom initial input data should be OutBus(i).

    if(E0 = '1') then
    OutBus(63 downto 0) <= Data0(63 downto 0);
    orif(E1 = '1') then
    OutBus(63 downto 0) <= Data1(63 downto 0);
    orif(E2 = '1') then
    OutBus(63 downto 0) <= Data2(63 downto 0);
    else
    OutBus(63 downto 0) <= Zero_64;
    end if;

    It is logically defined as the following:
    if(E0 = '1' or E1 = '1' or E2 = '1') then
    if(E0 = '1') then
    OutBus(63 downto 0) <= Data0(63 downto 0);
    orif(E1 = '1') then
    OutBus(63 downto 0) <= Data1(63 downto 0);
    orif(E2 = '1') then
    OutBus(63 downto 0) <= Data2(63 downto 0);
    end if;
    else
    OutBus(63 downto 0) <= Zero_64;
    end if;

    Its implementation equation should look like this:
    OutBus = E0*Data0 + E1*Data1 + E2*Data2;

    Its carry chain bottom initial input data should be '0'.

    How efficient it is to refer to carry chain in FPGA.

    Weng
     
    Weng Tianxiang, Aug 28, 2007
    #10
  11. Weng Tianxiang

    Jim Lewis Guest

    Andy,
    > On Aug 28, 12:21 pm, Jim Lewis <> wrote:
    >> I noted that in your code you mixed orif mixed with elsif (copied below),
    >> was this intentional? One hand, these could convey exactly what I want
    >> (because there are many cases like this), OTOH, it could be a mistake.
    >> Hence the intent is ambiguous and during a design review, one would have
    >> to pay particular attention to this and ask questions about your intent
    >> and its validation. A copy of your code is below.
    >>
    >> If(E0 = '1') then
    >> State_A <= E0_S;
    >> Orif(E1 = '1') then
    >> State_A <= E_S;
    >> Orif(E2 = '1') then
    >> State_A <= E2_S;
    >> elsIf(E3 = '1') then
    >> State_A <= E3_S;
    >> Orif(E4 = '1') then
    >> State_A <= E4_S;
    >> Orif(E5 = '1') then
    >> State_A <= E5_S;
    >> elsIf(E6 = '1') then
    >>
    >> On the other hand, with assertions, the following assertions
    >> allow the above code to be written using elsif. In addition,
    >> in this case, it is very clear about which I want to be
    >> mutually exclusive.
    >> assert zero_one_hot (E0, E1, E2) ;
    >> assert zero_one_hot (E3, E4, E5) ;

    >
    > I would have (perhaps mistakenly?) interpreted the orif/elsif syntax
    > as:
    > also meaning:
    >
    > assert zero_one_hot(E0, E1, E2, E4, E5);
    >
    > My point (and Jim's) is that this is one very good reason why such a
    > seemingly simple language change is not a good idea when you look
    > under the hood.


    Sadly he did clarify his intent in a further post and he did
    mean to split the priority as I showed. I had an unfair advantage
    as I have reviewed this with him in the past.

    > Actually, would the correct syntax be:
    >
    > assert zero_one_hot((e0, e1, e2, e4, e5)); -- one array argument
    >
    > or does the psl zero_one_hot() function actually accept a variable
    > number of arguments?
    >
    > I would really like to see one_hot() and zero_one_hot() as standard
    > vhdl (not just psl) functions, usable in an assert statement for this
    > purpose. The reason is that I don't see synthesis vendors using PSL at
    > any point in the future (there's just way too much there that would
    > never be relevant to synthesis). But they could easily parse simple
    > vhdl assertions with specific, standard functions to extract
    > meaningful information about the description.


    Probably a good idea. Technically speaking, PSL is part of VHDL and
    synthesis tools tend to pick and choose what they implement, so they
    could just implement this construct.

    Cheers,
    Jim
     
    Jim Lewis, Aug 28, 2007
    #11
  12. On Aug 28, 11:30 am, Jonathan Bromley <>
    wrote:
    > Weng,
    >
    > I was almost starting to agree with you, until you said this...
    >
    > > with new keyword 'orif' Xilinx FPGA compiler will be
    > >mandated to map 'orif' structure into a carry chain structure without
    > >doubt.
    > >...
    > >Letting a special VHDL language structure refer to a carry chain
    > >implementation in FPGA is a wonderful thing.

    >
    > This is the purest madness. If you want a language structure
    > that specifies a particular implementation, you have it already:
    > it's called a "primitive instance". I agree that a conditional
    > that is mutually-exclusive by design can readily be mapped to
    > specific hardware such as MUXCY or a tree of ORs, but the
    > precise mapping is NOT something we want in the language,
    > thanks very much. Tools must have the freedom to optimize
    > as they think best, and must compete (and succeed or fail)
    > on how effectively they do it.
    >
    > Language constructs that have built-in assertions for
    > things that are otherwise hard to describe, such as
    > mutual exclusivity, are something that is well worth
    > exploring. Especially now that we have the partially-
    > successful SystemVerilog example to study, it should be
    > possible to come up with some interesting ideas. But
    > please don't blast a hole in your own argument by
    > demanding that the language construct should have a
    > one-to-one mapping to some specific piece of technology.
    > --
    > 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
    > ://www.MYCOMPANY.com
    >
    > The contents of this message may contain personal views which
    > are not the views of Doulos Ltd., unless specifically stated.


    Hi Jonathan,
    All statement structures in VHDL are to refer to a hardware
    structures.

    A sequential process is to refer to registers.

    If a combinational process doesn't get proper assignment, it would
    refer to a latch.

    A combinational signal in concurrent area refers to a combinational
    signal.

    Why can we refer a special language structure to a carry chain in FPGA
    while it also gives a means to deal with real situation?

    "Tools must have the freedom to optimize
    as they think best, and must compete (and succeed or fail)
    on how effectively they do it. "

    In FPGA, it gets best timing with carry chain structure, why don't we
    do it? Keyword 'orif' doesn't mean you cannot use other MUX/CASE
    method to do it. But referring to a carry chain is the best way to do
    things.

    There are 4 considerations:
    1. Easy to write;
    2. Be concise in doing it;
    3. Have wider range of usage;
    4. Performance benefit.

    Maybe 'mandated' word offends you. It should be changed to other
    word.

    Weng
     
    Weng Tianxiang, Aug 28, 2007
    #12
  13. Andy wrote:

    > enable := (others => '0');
    > for i in enable'range loop
    > if address = i then
    > enable(i) := '1';
    > end if;
    > end loop;
    >
    > Most synthesis tools can figure out that enable is zero_one_hot.
    >
    > Where the problem comes in is that if you want to use enable in the
    > next clock cycle (or later). After all, if you only needed to use it
    > immediately, you would dispense with the enable vector, and just put
    > the action that "enable" enables in the if-then statement directly.
    >
    > But as soon as you want to store the enables for a clock cycle or
    > more, every synthesis tool I've seen fails to realize that enable is
    > still mutually exclusive.


    I'll bite.
    Why not describe the decode to match the way we encoded it?
    Start on one end and break on the first active bit.

    -- Mike Treseler
     
    Mike Treseler, Aug 28, 2007
    #13
  14. Weng Tianxiang

    Andy Guest

    Intermediate signals/variables can be avoided by just simply using the
    expressions in the call to zero_one_hot(); that's a non-issue.

    There are many more uses of mutual exclusivity than carry chains, and
    if mutual exclusivity's only specification is with "orif", some other
    uses are more difficult to functionally describe. Consider a circuit
    where, if accesses to an array are mutually exclusive, the array can
    be implemented as a RAM, with a multiplexer on the input. Sure you
    could code it that way, but I find it often easier to debug
    descriptions that are functionally more concise, and let the tool
    figure out the best implementation, with help (that does not detract
    from the functionality by forcing it to be re-written) from assertions
    if necessary.

    A similar occurrence is when trying to determine if expensive
    resources can be shared. Coding it such that mutual exclusivity is
    explicit (with or without "orif") is often less functionally clear to
    the reader, and therefore more likely to harbor functional errors.

    Andy
     
    Andy, Aug 28, 2007
    #14
  15. Jim,

    On 2007-08-28, Jim Lewis <> wrote:

    |--------------------------------------------------------------------------|
    |"Weng, |
    |[..] |
    | |
    |[..] |
    | |
    |I noted that in your code you mixed orif mixed with elsif (copied below), |
    |was this intentional? One hand, these could convey exactly what I want |
    |(because there are many cases like this), OTOH, it could be a mistake. |
    |Hence the intent is ambiguous and during a design review, one would have |
    |to pay particular attention to this and ask questions about your intent |
    |and its validation. A copy of your code is below. |
    | |
    |If(E0 = '1') then |
    |State_A <= E0_S; |
    |Orif(E1 = '1') then |
    |State_A <= E_S; |
    |Orif(E2 = '1') then |
    |State_A <= E2_S; |
    |elsIf(E3 = '1') then |
    |State_A <= E3_S; |
    |Orif(E4 = '1') then |
    |State_A <= E4_S; |
    |Orif(E5 = '1') then |
    |State_A <= E5_S; |
    |elsIf(E6 = '1') then |
    |" |
    |--------------------------------------------------------------------------|

    Yes,

    Weng really did intend to have both orif branches and elsif branches
    in a single if statement (see
    news:
    ). I think the intention would be clearer with different
    indentation. E.g.
    If(E0 = '1') then
    State_A <= E0_S;
    Orif(E1 = '1') then
    State_A <= E_S;
    Orif(E2 = '1') then
    State_A <= E2_S;

    elsIf(E3 = '1') then
    State_A <= E3_S;
    Orif(E4 = '1') then
    State_A <= E4_S;
    Orif(E5 = '1') then
    State_A <= E5_S;
    elsIf(E6 = '1') then
    --...

    |--------------------------------------------------------------------------|
    |"[..] |
    | |
    |[..] The danger in adding new keywords is that they may |
    |conflict with a name (signal, ...) already used in someone's design |
    |and cause an old design to be a syntax error in the new language |
    |revision. This generally does not please people and means they |
    |have to add special handling for the file (compile flags). |
    | |
    |[..]" |
    |--------------------------------------------------------------------------|

    A newly introduced reserved word would be guaranteed to not conflict
    with old code by not being possible to misinterpret as a basic
    identifier (basic_identifier ::= letter { [ underline ]
    letter_or_digit), e.g. by starting with an underline or by containing
    a percentage sign.

    Best regards,
    Colin Paul
     
    Colin Paul Gloster, Aug 29, 2007
    #15
  16. Folks,

    the functionality you are talking about is available in VHDL 2006 via
    the use of PSL in assertions.

    Essentially it is not about describing a function, but about
    restricting the domain of that function.
    This should not be mixed with the specification of the functions
    behaviour, especially if you take
    formal verification into account.

    Kolja Sulimma
     
    comp.arch.fpga, Aug 29, 2007
    #16
  17. On Aug 29, 3:13 am, Colin Paul Gloster <>
    wrote:
    > Jim,
    >
    > On 2007-08-28, Jim Lewis <> wrote:
    >
    > |--------------------------------------------------------------------------­|
    > |"Weng, |
    > |[..] |
    > | |
    > |[..] |
    > | |
    > |I noted that in your code you mixed orif mixed with elsif (copied below), |
    > |was this intentional? One hand, these could convey exactly what I want |
    > |(because there are many cases like this), OTOH, it could be a mistake. |
    > |Hence the intent is ambiguous and during a design review, one would have |
    > |to pay particular attention to this and ask questions about your intent |
    > |and its validation. A copy of your code is below. |
    > | |
    > |If(E0 = '1') then |
    > |State_A <= E0_S; |
    > |Orif(E1 = '1') then |
    > |State_A <= E_S; |
    > |Orif(E2 = '1') then |
    > |State_A <= E2_S; |
    > |elsIf(E3 = '1') then |
    > |State_A <= E3_S; |
    > |Orif(E4 = '1') then |
    > |State_A <= E4_S; |
    > |Orif(E5 = '1') then |
    > |State_A <= E5_S; |
    > |elsIf(E6 = '1') then |
    > |" |
    > |--------------------------------------------------------------------------­|
    >
    > Yes,
    >
    > Weng really did intend to have both orif branches and elsif branches
    > in a single if statement (seenews:
    > ). I think the intention would be clearer with different
    > indentation. E.g.
    > If(E0 = '1') then
    > State_A <= E0_S;
    > Orif(E1 = '1') then
    > State_A <= E_S;
    > Orif(E2 = '1') then
    > State_A <= E2_S;
    >
    > elsIf(E3 = '1') then
    > State_A <= E3_S;
    > Orif(E4 = '1') then
    > State_A <= E4_S;
    > Orif(E5 = '1') then
    > State_A <= E5_S;
    > elsIf(E6 = '1') then
    > --...
    >
    > |--------------------------------------------------------------------------­|
    > |"[..] |
    > | |
    > |[..] The danger in adding new keywords is that they may |
    > |conflict with a name (signal, ...) already used in someone's design |
    > |and cause an old design to be a syntax error in the new language |
    > |revision. This generally does not please people and means they |
    > |have to add special handling for the file (compile flags). |
    > | |
    > |[..]" |
    > |--------------------------------------------------------------------------­|
    >
    > A newly introduced reserved word would be guaranteed to not conflict
    > with old code by not being possible to misinterpret as a basic
    > identifier (basic_identifier ::= letter { [ underline ]
    > letter_or_digit), e.g. by starting with an underline or by containing
    > a percentage sign.
    >
    > Best regards,
    > Colin Paul


    Hi Colin,
    Thank you for your support.

    You are the first big canon who gave full support behind the keyword
    'orif' and gets full understanding of its meaning.

    My fighting for 'orif' recognition is not for my personal purpose, it
    is in the interest of HDL industry and academic world.

    You help clear up 3 things:
    1. Indent two separate mutually exclusive groups to avoid confusion.
    I have never thought about it.

    2. "Weng really did intend to have both orif branches and elsif
    branches
    in a single if statement "

    I have really done it in 'orif' definition:
    "Where keyword 'elsif' can be used in a VHDL code, there keyword
    'orif' can be used.", but failed to mention that directly. It seems to
    me that it is a reality and may never be mentioned specifically.

    I thought that "if...elsif..." statement structure was created by IBM
    in 1953 when designing Fortran language to meet software requirements:
    sequential comparison, one after another.

    In hardware world, HDL language must have a similar mainstream
    language structure to meet the 0-1 out of N selections in parallel.
    That was where keyword 'orif' came from.

    In my experiences, 'orif' is much easier than zero_one_hot() to use in
    practise in the same way as engineers rarely use single signal names
    to replace equations in if() or elsif().

    3. "A newly introduced reserved word would be guaranteed to not
    conflict
    with old code"

    Jim's opinion is that if you introduce a new keyword 'orif', then even
    though 'orif' doesn't conflict with 'elsif', but it certainly would
    conflict with old signal name orif. This can never be avoided. But his
    new function name zero_one_hot() still has the same possibility to
    conflict with old signal function name zero_one_hot() if someone had
    used it before, but he never mentioned his same possibility.

    I would like to add more information.
    1. 'case' statement is a special case with keyword 'orif', in other
    words, all 'case' statement can be written using keyword 'if...orif'
    structure.

    Example:

    case two_bits is
    when "00" =>
    ...
    when "01" =>
    ...
    when "10" =>
    ...
    when others =>
    ...
    end case;

    if(two_bits = "00") then
    ...
    orif(two_bits = "01") then
    ...
    orif(two_bits = "10") then
    ...
    else <-- equivalent to "when others =>"
    ...
    end if;

    2. Andy mentioned that he may be able to find something that is beyond
    the capability of 'orif', but within capability of zero_one_hot().

    Andy, you never have a chance to do so with signals.
    Reason: you have to implement an assign statement to reflect their
    mutually exclusive property, then you must use one of two conditional
    branch statements: case statement or if statement that are within
    'orif' range.

    Mutually exclusiveness is not used for combinational signals.

    I don't have any idea if mutually exclusive property applies to
    variables.

    3. As keyword 'orif' definition says, 'orif' only provides information
    about mutually exclusive property among a group of conditions.
    Compilers can do what they think is the best strategy as they want.
    But for FPGA, the 'orif' perfectly refers to carry chain structure in
    both Xilinx and Altera (I am not familiar with other FPGA products),
    it is a wonderful thing, but should not be a burden or a blame, as
    Jonathan indicated.

    Weng
     
    Weng Tianxiang, Aug 29, 2007
    #17
  18. KJ wrote:

    >> 7. Mutually exclusiveness is ubiquitout in logic design and I am very
    >> sorry for VHDL without a special keyword to deal with it.


    > What is it about enumerated types in VHDL that you find so hard?


    I agree with KJ.
    Enumerated types and values cover
    designs with mutual exclusion very well
    and are easy to read and to testbench.

    Synthesis does a good job of encoding and
    decoding enumerated values.

    How hard should I work and what
    risks should I take to save a LUT
    by enforcing and verifying my own encoding?

    -- Mike Treseler
     
    Mike Treseler, Aug 29, 2007
    #18
  19. Weng Tianxiang

    Andy Guest

    On Aug 29, 11:46 am, Weng Tianxiang <> wrote:
    > On Aug 29, 3:13 am, Colin Paul Gloster <>
    > wrote:
    >
    >
    >
    > > Jim,

    >
    > > On 2007-08-28, Jim Lewis <> wrote:

    >
    > > |--------------------------------------------------------------------------­|
    > > |"Weng, |
    > > |[..] |
    > > | |
    > > |[..] |
    > > | |
    > > |I noted that in your code you mixed orif mixed with elsif (copied below), |
    > > |was this intentional? One hand, these could convey exactly what I want |
    > > |(because there are many cases like this), OTOH, it could be a mistake. |
    > > |Hence the intent is ambiguous and during a design review, one would have |
    > > |to pay particular attention to this and ask questions about your intent |
    > > |and its validation. A copy of your code is below. |
    > > | |
    > > |If(E0 = '1') then |
    > > |State_A <= E0_S; |
    > > |Orif(E1 = '1') then |
    > > |State_A <= E_S; |
    > > |Orif(E2 = '1') then |
    > > |State_A <= E2_S; |
    > > |elsIf(E3 = '1') then |
    > > |State_A <= E3_S; |
    > > |Orif(E4 = '1') then |
    > > |State_A <= E4_S; |
    > > |Orif(E5 = '1') then |
    > > |State_A <= E5_S; |
    > > |elsIf(E6 = '1') then |
    > > |" |
    > > |--------------------------------------------------------------------------­|

    >
    > > Yes,

    >
    > > Weng really did intend to have both orif branches and elsif branches
    > > in a single if statement (seenews:
    > > ). I think the intention would be clearer with different
    > > indentation. E.g.
    > > If(E0 = '1') then
    > > State_A <= E0_S;
    > > Orif(E1 = '1') then
    > > State_A <= E_S;
    > > Orif(E2 = '1') then
    > > State_A <= E2_S;

    >
    > > elsIf(E3 = '1') then
    > > State_A <= E3_S;
    > > Orif(E4 = '1') then
    > > State_A <= E4_S;
    > > Orif(E5 = '1') then
    > > State_A <= E5_S;
    > > elsIf(E6 = '1') then
    > > --...

    >
    > > |--------------------------------------------------------------------------­|
    > > |"[..] |
    > > | |
    > > |[..] The danger in adding new keywords is that they may |
    > > |conflict with a name (signal, ...) already used in someone's design |
    > > |and cause an old design to be a syntax error in the new language |
    > > |revision. This generally does not please people and means they |
    > > |have to add special handling for the file (compile flags). |
    > > | |
    > > |[..]" |
    > > |--------------------------------------------------------------------------­|

    >
    > > A newly introduced reserved word would be guaranteed to not conflict
    > > with old code by not being possible to misinterpret as a basic
    > > identifier (basic_identifier ::= letter { [ underline ]
    > > letter_or_digit), e.g. by starting with an underline or by containing
    > > a percentage sign.

    >
    > > Best regards,
    > > Colin Paul

    >
    > Hi Colin,
    > Thank you for your support.
    >
    > You are the first big canon who gave full support behind the keyword
    > 'orif' and gets full understanding of its meaning.
    >
    > My fighting for 'orif' recognition is not for my personal purpose, it
    > is in the interest of HDL industry and academic world.
    >
    > You help clear up 3 things:
    > 1. Indent two separate mutually exclusive groups to avoid confusion.
    > I have never thought about it.
    >
    > 2. "Weng really did intend to have both orif branches and elsif
    > branches
    > in a single if statement "
    >
    > I have really done it in 'orif' definition:
    > "Where keyword 'elsif' can be used in a VHDL code, there keyword
    > 'orif' can be used.", but failed to mention that directly. It seems to
    > me that it is a reality and may never be mentioned specifically.
    >
    > I thought that "if...elsif..." statement structure was created by IBM
    > in 1953 when designing Fortran language to meet software requirements:
    > sequential comparison, one after another.
    >
    > In hardware world, HDL language must have a similar mainstream
    > language structure to meet the 0-1 out of N selections in parallel.
    > That was where keyword 'orif' came from.
    >
    > In my experiences, 'orif' is much easier than zero_one_hot() to use in
    > practise in the same way as engineers rarely use single signal names
    > to replace equations in if() or elsif().
    >
    > 3. "A newly introduced reserved word would be guaranteed to not
    > conflict
    > with old code"
    >
    > Jim's opinion is that if you introduce a new keyword 'orif', then even
    > though 'orif' doesn't conflict with 'elsif', but it certainly would
    > conflict with old signal name orif. This can never be avoided. But his
    > new function name zero_one_hot() still has the same possibility to
    > conflict with old signal function name zero_one_hot() if someone had
    > used it before, but he never mentioned his same possibility.
    >
    > I would like to add more information.
    > 1. 'case' statement is a special case with keyword 'orif', in other
    > words, all 'case' statement can be written using keyword 'if...orif'
    > structure.
    >
    > Example:
    >
    > case two_bits is
    > when "00" =>
    > ...
    > when "01" =>
    > ...
    > when "10" =>
    > ...
    > when others =>
    > ...
    > end case;
    >
    > if(two_bits = "00") then
    > ...
    > orif(two_bits = "01") then
    > ...
    > orif(two_bits = "10") then
    > ...
    > else <-- equivalent to "when others =>"
    > ...
    > end if;
    >
    > 2. Andy mentioned that he may be able to find something that is beyond
    > the capability of 'orif', but within capability of zero_one_hot().
    >
    > Andy, you never have a chance to do so with signals.
    > Reason: you have to implement an assign statement to reflect their
    > mutually exclusive property, then you must use one of two conditional
    > branch statements: case statement or if statement that are within
    > 'orif' range.
    >
    > Mutually exclusiveness is not used for combinational signals.
    >
    > I don't have any idea if mutually exclusive property applies to
    > variables.
    >
    > 3. As keyword 'orif' definition says, 'orif' only provides information
    > about mutually exclusive property among a group of conditions.
    > Compilers can do what they think is the best strategy as they want.
    > But for FPGA, the 'orif' perfectly refers to carry chain structure in
    > both Xilinx and Altera (I am not familiar with other FPGA products),
    > it is a wonderful thing, but should not be a burden or a blame, as
    > Jonathan indicated.
    >
    > Weng


    Weng,

    The fact that orif must be indented from elsif, is a very poor way to
    indicate functional structure of code. That should be the first key
    that orif is a very weak bandaid on a problem that has much better
    solutions that have repeatedly been suggested for a variety of
    reasons.

    Even your explanation of the indentation ("Indent two separate
    mutually exclusive groups to avoid confusion") remains ambiguous: are
    the groups mutually exclusive, or are the members of each group
    mutually exclusive only amongst those group members, or both?
    Indentation may look prettier (and help avoid missing an "elsif"), but
    it adds nothing to the clarity of purpose.

    "In my experiences, 'orif' is much easier than zero_one_hot() to use
    in practise in the same way as engineers rarely use single signal
    names to replace equations in if() or elsif()."

    I've already told you that you do not need to use single signal names
    with zero_one_hot() arguments anymore than you have to use them with
    if/elsif/orif conditions; expressions can be used in both instances.
    Nor are you limited to using expressions in either place; you can
    assign a signal or variable, which will often be more readable in both
    instances anyway. What "engineers rarely [or commonly] use" is not the
    definition of good coding practice.

    zero_one_hot() can always be prefixed with the standard package name
    in which it is defined. Keywords, on the other hand cannot. I believe
    that tricks like '_' and '%' on the front of new keywords are a
    hideous hack, nevertheless befitting this whole orif concept.

    Any synthesis tool that cannot figure out the code below (rewritten
    from your example, but in standard vhdl with elsif) indicates mutually
    exclusive conditions should be immediately uninstalled and returned to
    the vendor for a full refund!

    if(two_bits = "00") then
    ...
    elsif(two_bits = "01") then
    ...
    elsif(two_bits = "10") then
    ...
    else <-- equivalent to "when others =>"
    ...
    end if;

    As for mutual exclusivity of combinatorial signals or variables, why
    do you think mutual exclusivity should be limited to registers only?
    Even in your own code examples you have demonstrated mutual
    exclusivity of intermediate expressions, which are not registers.

    I don't understand your reference to having "to implement an assign
    statement to reflect their mutually exclusive property, then you must
    use one of two conditional branch statements: case statement or if
    statement that are within 'orif' range.

    You are completely missing the point about using an assertion: the
    assertion is completely independent of the functional code. It merely
    provides additional information to a tool that may or may not use it,
    but most importantly, it does not restrict you to a specific
    functional coding method in order to provide that information.

    Your statement: "3. As keyword 'orif' definition says, 'orif' only
    provides information about mutually exclusive property among a group
    of conditions. " is incorrect: it also provides the functional part,
    and cannot be separated from it.

    For example, how would you use orif in a loop to do the following (the
    loop is necessary because the range of enable is arbitrary):

    data <= (others => '0');
    if read = '1' then
    for i in enable'range loop
    if enable(i) = '1' then
    data <= input(i);
    exit;
    end if;
    end loop;
    assert zero_one_hot(enable);
    end if;

    The answer is: you couldn't! The use of the assertion, since it is
    independent of the functional code, places no limitations on how you
    code the functional part.

    OTOH, you can choose to combine it with the functional code to easily
    represent conditional mutual exclusivity (i.e. only if read = '1'), as
    shown above.

    OTOOH, if enable was always mutex, it could be indicated once with an
    assertion, and any logic that uses it anywhere else could be optimized
    because of the additional information.

    Andy
     
    Andy, Aug 29, 2007
    #19
  20. On Aug 29, 3:44 pm, Andy <> wrote:
    > On Aug 29, 11:46 am, Weng Tianxiang <> wrote:
    >
    >
    >
    >
    >
    > > On Aug 29, 3:13 am, Colin Paul Gloster <>
    > > wrote:

    >
    > > > Jim,

    >
    > > > On 2007-08-28, Jim Lewis <> wrote:

    >
    > > > |--------------------------------------------------------------------------­­|
    > > > |"Weng, |
    > > > |[..] |
    > > > | |
    > > > |[..] |
    > > > | |
    > > > |I noted that in your code you mixed orif mixed with elsif (copied below), |
    > > > |was this intentional? One hand, these could convey exactly what I want |
    > > > |(because there are many cases like this), OTOH, it could be a mistake. |
    > > > |Hence the intent is ambiguous and during a design review, one would have |
    > > > |to pay particular attention to this and ask questions about your intent |
    > > > |and its validation. A copy of your code is below. |
    > > > | |
    > > > |If(E0 = '1') then |
    > > > |State_A <= E0_S; |
    > > > |Orif(E1 = '1') then |
    > > > |State_A <= E_S; |
    > > > |Orif(E2 = '1') then |
    > > > |State_A <= E2_S; |
    > > > |elsIf(E3 = '1') then |
    > > > |State_A <= E3_S; |
    > > > |Orif(E4 = '1') then |
    > > > |State_A <= E4_S; |
    > > > |Orif(E5 = '1') then |
    > > > |State_A <= E5_S; |
    > > > |elsIf(E6 = '1') then |
    > > > |" |
    > > > |--------------------------------------------------------------------------­­|

    >
    > > > Yes,

    >
    > > > Weng really did intend to have both orif branches and elsif branches
    > > > in a single if statement (seenews:
    > > > ). I think the intention would be clearer with different
    > > > indentation. E.g.
    > > > If(E0 = '1') then
    > > > State_A <= E0_S;
    > > > Orif(E1 = '1') then
    > > > State_A <= E_S;
    > > > Orif(E2 = '1') then
    > > > State_A <= E2_S;

    >
    > > > elsIf(E3 = '1') then
    > > > State_A <= E3_S;
    > > > Orif(E4 = '1') then
    > > > State_A <= E4_S;
    > > > Orif(E5 = '1') then
    > > > State_A <= E5_S;
    > > > elsIf(E6 = '1') then
    > > > --...

    >
    > > > |--------------------------------------------------------------------------­­|
    > > > |"[..] |
    > > > | |
    > > > |[..] The danger in adding new keywords is that they may |
    > > > |conflict with a name (signal, ...) already used in someone's design |
    > > > |and cause an old design to be a syntax error in the new language |
    > > > |revision. This generally does not please people and means they |
    > > > |have to add special handling for the file (compile flags). |
    > > > | |
    > > > |[..]" |
    > > > |--------------------------------------------------------------------------­­|

    >
    > > > A newly introduced reserved word would be guaranteed to not conflict
    > > > with old code by not being possible to misinterpret as a basic
    > > > identifier (basic_identifier ::= letter { [ underline ]
    > > > letter_or_digit), e.g. by starting with an underline or by containing
    > > > a percentage sign.

    >
    > > > Best regards,
    > > > Colin Paul

    >
    > > Hi Colin,
    > > Thank you for your support.

    >
    > > You are the first big canon who gave full support behind the keyword
    > > 'orif' and gets full understanding of its meaning.

    >
    > > My fighting for 'orif' recognition is not for my personal purpose, it
    > > is in the interest of HDL industry and academic world.

    >
    > > You help clear up 3 things:
    > > 1. Indent two separate mutually exclusive groups to avoid confusion.
    > > I have never thought about it.

    >
    > > 2. "Weng really did intend to have both orif branches and elsif
    > > branches
    > > in a single if statement "

    >
    > > I have really done it in 'orif' definition:
    > > "Where keyword 'elsif' can be used in a VHDL code, there keyword
    > > 'orif' can be used.", but failed to mention that directly. It seems to
    > > me that it is a reality and may never be mentioned specifically.

    >
    > > I thought that "if...elsif..." statement structure was created by IBM
    > > in 1953 when designing Fortran language to meet software requirements:
    > > sequential comparison, one after another.

    >
    > > In hardware world, HDL language must have a similar mainstream
    > > language structure to meet the 0-1 out of N selections in parallel.
    > > That was where keyword 'orif' came from.

    >
    > > In my experiences, 'orif' is much easier than zero_one_hot() to use in
    > > practise in the same way as engineers rarely use single signal names
    > > to replace equations in if() or elsif().

    >
    > > 3. "A newly introduced reserved word would be guaranteed to not
    > > conflict
    > > with old code"

    >
    > > Jim's opinion is that if you introduce a new keyword 'orif', then even
    > > though 'orif' doesn't conflict with 'elsif', but it certainly would
    > > conflict with old signal name orif. This can never be avoided. But his
    > > new function name zero_one_hot() still has the same possibility to
    > > conflict with old signal function name zero_one_hot() if someone had
    > > used it before, but he never mentioned his same possibility.

    >
    > > I would like to add more information.
    > > 1. 'case' statement is a special case with keyword 'orif', in other
    > > words, all 'case' statement can be written using keyword 'if...orif'
    > > structure.

    >
    > > Example:

    >
    > > case two_bits is
    > > when "00" =>
    > > ...
    > > when "01" =>
    > > ...
    > > when "10" =>
    > > ...
    > > when others =>
    > > ...
    > > end case;

    >
    > > if(two_bits = "00") then
    > > ...
    > > orif(two_bits = "01") then
    > > ...
    > > orif(two_bits = "10") then
    > > ...
    > > else <-- equivalent to "when others =>"
    > > ...
    > > end if;

    >
    > > 2. Andy mentioned that he may be able to find something that is beyond
    > > the capability of 'orif', but within capability of zero_one_hot().

    >
    > > Andy, you never have a chance to do so with signals.
    > > Reason: you have to implement an assign statement to reflect their
    > > mutually exclusive property, then you must use one of two conditional
    > > branch statements: case statement or if statement that are within
    > > 'orif' range.

    >
    > > Mutually exclusiveness is not used for combinational signals.

    >
    > > I don't have any idea if mutually exclusive property applies to
    > > variables.

    >
    > > 3. As keyword 'orif' definition says, 'orif' only provides information
    > > about mutually exclusive property among a group of conditions.
    > > Compilers can do what they think is the best strategy as they want.
    > > But for FPGA, the 'orif' perfectly refers to carry chain structure in
    > > both Xilinx and Altera (I am not familiar with other FPGA products),
    > > it is a wonderful thing, but should not be a burden or a blame, as
    > > Jonathan indicated.

    >
    > > Weng

    >
    > Weng,
    >
    > The fact that orif must be indented from elsif, is a very poor way to
    > indicate functional structure of code. That should be the first key
    > that orif is a very weak bandaid on a problem that has much better
    > solutions that have repeatedly been suggested for a variety of
    > reasons.
    >
    > Even your explanation of the indentation ("Indent two separate
    > mutually exclusive groups to avoid confusion") remains ambiguous: are
    > the groups mutually exclusive, or are the members of each group
    > mutually exclusive only amongst those group members, or both?
    > Indentation may look prettier (and help avoid missing an "elsif"), but
    > it adds nothing to the clarity of purpose.
    >
    > "In my experiences, 'orif' is much easier than zero_one_hot() to use
    > in practise in the same way as engineers rarely use single signal
    > names to replace equations in if() or elsif()."
    >
    > I've already told you that you do not need to use single signal names
    > with zero_one_hot() arguments anymore than you have to use them with
    > if/elsif/orif conditions; expressions can be used in both instances.
    > Nor are you limited to using expressions in either place; you can
    > assign a signal or variable, which will often be more readable in both
    > instances anyway. What "engineers rarely [or commonly] use" is not the
    > definition of good coding practice.
    >
    > zero_one_hot() can always be prefixed with the standard package name
    > in which it is defined. Keywords, on the other hand cannot. I believe
    > that tricks like '_' and '%' on the front of new keywords are a
    > hideous hack, nevertheless befitting this whole orif concept.
    >
    > Any synthesis tool that cannot figure out the code below (rewritten
    > from your example, but in standard vhdl with elsif) indicates mutually
    > exclusive conditions should be immediately uninstalled and returned to
    > the vendor for a full refund!
    >
    > if(two_bits = "00") then
    > ...
    > elsif(two_bits = "01") then
    > ...
    > elsif(two_bits = "10") then
    > ...
    > else <-- equivalent to "when others =>"
    > ...
    > end if;
    >
    > As for mutual exclusivity of combinatorial signals or variables, why
    > do you think mutual exclusivity should be limited to registers only?
    > Even in your own code examples you have demonstrated mutual
    > exclusivity of intermediate ...
    >
    > read more »- Hide quoted text -
    >
    > - Show quoted text -


    Hi Andy and Jim,
    I like to discuss the issue further with you.

    I have to change my keyword 'orif' definition to make it perfect (it
    may need more fine tuning with other's help, no matter what is, I am
    not a good protocol writer, but I am learning), but the basic idea has
    been the same as before and consistent without any change since March
    2002 I published a paper with Jim as the paper's reviewer.

    Keyword 'orif' has the same language grammar definition as keyword
    'elsif' with one exception: conditional signal contained in leading
    keywords 'if()' or 'elsif()' and conditional signals contained in the
    subsequent and contiguous keyword 'orif()' at the same level in an
    'if...elsif...end if' statement are mutually exclusive. Where keyword
    'elsif' can be used in a VHDL code, there keyword 'orif' can be used.
    'orif' and 'elsif' can be mixed at any levels of 'if...elsif...end if'
    statements.

    Here is a better example to show how powerful 'orif' is.

    If(E0 = '1') then
    If(E01 = '1') then
    State_A <= E01_S;
    orif(E02 = '1') then
    State_A <= E02_S;
    orif(E03 = '1') then
    State_A <= E03_S;

    elsIf(E04 = '1') then
    State_A <= E04_S;
    end if;
    Orif(E1 = '1') then
    State_A <= E1_S;
    Orif(E2 = '1') then
    State_A <= E2_S;

    elsIf(E3 = '1') then
    State_A <= E3_S;
    Orif(E4 = '1') then
    If(E41 = '1') then
    State_A <= E41_S;
    elsif(E42 = '1') then
    State_A <= E42_S;
    orif(E43 = '1') then
    State_A <= E43_S;
    orIf(E44 = '1') then
    State_A <= E44_S;
    end if;

    Orif(E5 = '1') then
    State_A <= E5_S;

    elsIf(E6 = '1') then
    ...
    else
    ...
    end if;

    Mutually exclusive groups: (E0, E1, E2), (E3, E4, E5), (E01, E02,
    E03), (E42, E43, E44).

    I would like to add a blank line to separate two groups in order not
    to make a confusion with viewers of this post. Personnally I don't
    think the blank line is needed if you are used to it.

    I would like to tell you my experiences: when you are writing mutually
    exclusive conditions, you don't know in advance that those group of
    conditional signals that are mutually exclusive are written correctly,
    and takes a long way to make them correct. You have to fine turn to
    make them mutually exclusive finally.
    The process is a slow learning one and you cannot write it immediately
    without error. When zero_one_hot() method is used, you have two
    choices: write them separately in its defnition area and its calling
    area from start, or write them like writing a conventional
    'if...eslif...end if' statement, then copy them and call them to
    become 2 separate code after you are certain that they are right. I
    know you have the experiences to write any 'if...eslif...end if'
    statements. First of all, I don't believe you would like to write
    'if...eslif...end if' statement in 2 separate parts, one for its
    definition and assign statements, another is called in
    'if...eslif...end if' statement. Then you can imagine same things and
    more difficult things happening with the same situations as writing
    'if...eslif...end if' statement.

    I can imagine if both methods, Jim's and mine, are introduced into
    VHDL standard, I can bet with you: 99.9999% of engineers who use
    mutually exclusive method to speed up their designs would use my
    method. My basis is nobody who write 'if...eslif...end if' statements
    today uses 2 separate parts as Jim suggested for zero_one_hot() to
    write 'if...eslif...end if' statements.

    I have to point out the following code has error:

    if(E0 = '1') then
    OutBus(63 downto 0) <= Data0(63 downto 0);
    orif(E1 = '1') then
    OutBus(63 downto 0) <= Data1(63 downto 0);
    orif(E2 = '1') then
    OutBus(63 downto 0) <= Data2(63 downto 0);
    end if;

    Its implementation equation should look like this:
    OutBus = E0*Data0 + E1*Data1 + E2*Data2 + OutBus;


    The correct equation should look like this:
    OutBus = E0*Data0 + E1*Data1 + E2*Data2 + (not (E0+E1+E2))*OutBus;


    Here is Jim's equation that is wrong !
    If(E0 = '1') then
    State_A <= E0_S;
    Orif(E1 = '1') then
    State_A <= E_S;
    Orif(E2 = '1') then
    State_A <= E2_S;
    elsIf(E3 = '1') then
    State_A <= E3_S;
    Orif(E4 = '1') then
    State_A <= E4_S;
    Orif(E5 = '1') then
    State_A <= E5_S;
    elsIf(E6 = '1') then

    On the other hand, with assertions, the following assertions
    allow the above code to be written using elsif. In addition,
    in this case, it is very clear about which I want to be
    mutually exclusive.
    assert zero_one_hot (E0, E1, E2) ;
    assert zero_one_hot (E3, E4, E5) ;


    Also note that if you are using std_logic or bit types, with the
    Accellera VHDL-2006 revision you can write:
    OutBusA : process(RESET, CLK)
    begin
    if(RESET = '1') then
    OutBus <= (others=>'0');
    elsif rising_edge(CLK) then
    if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then
    OutBus <=
    (E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
    (E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
    end if ;
    end if ;
    end process;

    Jim, try this set of values: E0 = '1' and E3 = '1', you get data:
    Data0 or Data3, not Data0.

    Weng
     
    Weng Tianxiang, Aug 30, 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. Tomer Ben-David

    AOP Java its implications

    Tomer Ben-David, Jan 28, 2004, in forum: Java
    Replies:
    3
    Views:
    403
    Dale King
    Feb 5, 2004
  2. Brad Smallridge

    Orif Others

    Brad Smallridge, Aug 31, 2007, in forum: VHDL
    Replies:
    2
    Views:
    541
    Brian Drummond
    Sep 1, 2007
  3. Weng Tianxiang

    New keyword 'OIF' and its implications

    Weng Tianxiang, Sep 7, 2007, in forum: VHDL
    Replies:
    0
    Views:
    393
    Weng Tianxiang
    Sep 7, 2007
  4. thunk
    Replies:
    1
    Views:
    330
    thunk
    Mar 30, 2010
  5. thunk
    Replies:
    0
    Views:
    509
    thunk
    Apr 1, 2010
Loading...

Share This Page