New keyword 'orif' and its implications

--=AD|

|
|
|
|
|

, |

|
|
|
|
|
|
|
|
|
|
|
|
|
|

--=AD|

oglegroups.com

--=AD|

|
|
|
|
|
|
|
|
|

--=AD|

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=2E Indent two separate mutually exclusive groups to avoid confusion. I have never thought about it.

2=2E "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=2E "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=2E '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" =3D>

... when "01" =3D>

... when "10" =3D>

... when others =3D>

... end case;

if(two_bits =3D "00") then ... orif(two_bits =3D "01") then ... orif(two_bits =3D "10") then ... else

Reply to
Weng Tianxiang
Loading thread data ...

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

Reply to
Mike Treseler

----=AD|

|
|
|
|
|

w), |

t |

|

ve |

t |

|
|
|
|
|
|
|
|
|
|

----=AD|

googlegroups.com

----=AD|

|
|
|
|
|
|
|
|
|

----=AD|

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 =3D "00") then ... elsif(two_bits =3D "01") then ... elsif(two_bits =3D "10") then ... else

Reply to
Andy

------=AD=AD|

|
|
|
|
|

low), |

ant |

e=2E |

have |

ent |

|
|
|
|
|
|
|
|
|
|

------=AD=AD|

h=2Egooglegroups.com

------=AD=AD|

|
|
|
|
|
|
|
|
|

------=AD=AD|

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 =3D '1') then If(E01 =3D '1') then State_A

Reply to
Weng Tianxiang

On 2007-08-30, Weng Tianxiang wrote:

|---------------------------------------------------------------------------------------------| |"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: | |> | |[..] | |> > > On 2007-08-28, Jim Lewis wrote: | |[..] | |> | |> > > [..] I think the intention would be clearer with different | |> > > indentation. [..] | |[..] | |> > 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. | |---------------------------------------------------------------------------------------------|

Hello Weng,

I neither provided support for nor opposed your proposal, I simply tried to clarify for Jim whether the appearances of elsif were typos.

I am indifferent.

However, you clearly have not understood any of the responses so far in this thread. At least three alternatives not needing a new language were shown to you: a synthesis tool worth using should be able to determine how to efficiently implement a design; a case statement; and one-hot encoding or something similar using PSL instead of an attribute.

The PSL approach is the only one you have tried to respond to. If you can not prove that what you want to achieve can not be achieved well otherwise, then you will find it difficult to convince people who do not want too many ways to achieve one thing.

Your lack of appreciation for how the case statement is relevant and other things you have revealed to us indicate that your depth of understanding of VHDL needs to improve and this is also not helping people to take you seriously. Please read at least two good books with decent VHDL content, e.g. at least one of those listed on

formatting link
, and read the books you choose twice each.

|---------------------------------------------------------------------------------------------| |"> > My fighting for 'orif' recognition is not for my personal purpose, it | |> > is in the interest of HDL industry and academic world." | |[..] | |> > 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. | |---------------------------------------------------------------------------------------------|

I appreciate that you are genuinely being noble, but please understand that you should not insist that orif must be implemented as a carry chain. The designer writes in a HDL and the optimizer in the synthesis tool finds an efficient way to implement something. Something from a HDL might not always be represented the same way, depending on many issues too complicated to explain here. Please understand this example from Andy: |---------------------------------------------------------------------------------------------| |"> 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 ... | |> end if;" | |---------------------------------------------------------------------------------------------|

No matter how you improve your proposal for orif, you can not refute this point of Andy's.

Weng posted:

|---------------------------------------------------------------------------------------------| |"> > > On 2007-08-28, Jim Lewis wrote: | |[..] | |> | |> > >

|--------------------------------------------------------------------------­­| | |> > > |"[..] | | |> > > | | | |> > > |[..] 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 | |[..] | |> > 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." | |---------------------------------------------------------------------------------------------|

This can easily be avoided as I had already showed: it would be legal and easy to have a reserved word (e.g. _orif) which could never had been used as a basic_identifier.

|---------------------------------------------------------------------------------------------| |" 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. | |---------------------------------------------------------------------------------------------|

That would be true for plain VHDL without PSL, but he posted as if zero_one_hot() is now part of VHDL from PSL (but it is not in my PSL reference manual, unlike onehot0) so that would not necessarily require that a VHDL identifier be changed. From the PSL standard: "[..]

4.2.2 Keywords Keywords are reserved identifiers in PSL, so an HDL name that is a PSL keyword cannot be referenced directly, by its simple name, in an HDL expression used in a PSL property. However, such an HDL name can be referenced indirectly, using a hierarchical name or qualified name as allowed by the underlying HDL. The keywords used in PSL are shown in Table 1. [..] onehot0 [..] 5.2.3 Built-in functions PSL defines a collection of built-in functions that detect typically interesting conditions, or compute useful values, as shown in Syntax 5-20. Syntax 5-20.Built-in functions HDL_or_PSL_Expression ::= PSL_Expression PSL_Expression ::= Boolean -> Boolean | Boolean Boolean Built_In_Function_Call ::= prev (Any_Type [ , Number [ , Clock_Expression ]] ) [..] | onehot0 ( BitVector ) [..]"

|---------------------------------------------------------------------------------------------| |"> The fact that orif must be indented from elsif, is a very poor way to | |> indicate functional structure of code. [..]" | |---------------------------------------------------------------------------------------------|

Andy,

Your example enable := (others => '0'); for i in enable'range loop if address = i then enable(i) := '1'; end if; end loop; from news: snipped-for-privacy@22g2000hsm.googlegroups.com is easier to read with indentation than enable := (others => '0'); for i in enable'range loop if address = i then enable(i) := '1'; end if; end loop; and is condemning evidence against neither FOR nor IF.

|---------------------------------------------------------------------------------------------| |"[..] | |> zero_one_hot() can always be prefixed with the standard package name | |> in which it is defined." | |---------------------------------------------------------------------------------------------|

Andy,

Is zero_one_hot() defined in a package? Even if it is, Weng was complaining that Jim complained that orif would clash with a basic_identifier and Weng perceived this as hypocrisy as he thought zero_one_hot() would also clash with a basic_identifier.

|---------------------------------------------------------------------------------------------| |" Keywords, on the other hand cannot. I believe | |> that tricks like '_' and '%' on the front of new keywords are a | |> hideous hack, [..] | |---------------------------------------------------------------------------------------------|

Actually _ would need to go to the front but % could go anywhere, not that this would make you detest the ways in which new reserved words can be added to VHDL (sorry to Verilog people reading this) with a guarantee that old basic_identifiers will still be valid.

|---------------------------------------------------------------------------------------------| |"[..] | | | |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. | | | |[..]" | |---------------------------------------------------------------------------------------------|

Does the way that most reactions you have received are negative not seem to indicate that maybe 99.9999% adoption of your proposal is overly optimistic? It could be said that almost 99.9999% of people who write in VHDL write the basic_identifier for detecting a clock edge with "2 separate parts" even though a standard to use the basic_identifier only once per detection was published alongside VHDL93.

Regards, Colin Paul

P.S. This thread is taking up a lot of time, I might not post denials of mischaracterizations of me again until many days later as I need to get other work done soon.

Reply to
Colin Paul Gloster

Weng, take a step back.

First, not under all circumstances the carry chain implementation is the most efficient of the gated OR selector. For small number of inputs it fits into a single 6-LUT, for very large number of inputs the logarithmic delay of the tree will be better than the linear delay of the carry chain, even though the constants for the carry chain are better.

Second, the only thing that your orif keyword thos, is a hint to the synthesizer that the behaviour is undefined for certain input combinations. You restrict the domain of the function. The following code has the same semantics:

if E1 + E2 + E3 > 1 then -- (Lazy and incorrect VHDL type handling to shorten example, you will get the point) result '-'); elsif E1 = '1' then result E3);

Telling the synthesis tool to implement wide ORs in carry chains is simpler than to introduce a new keyboard. This way other uses of wide ORs benefit aswell, as do users of other languages.

Kolja Sulimma

P.S.: Xilinx has a patent on implementing a wide OR using carry logic. There is no explicit license that grants you the right to distribute bitstreams that use that trick. Xilinx says, they do not want to sue anybody about that. But I bet Unisys had no intent to sue GIF users in the 80ies. But intentions can change. Do you want to bet your business on an informal declaration by Austin in a newsgroup?

Reply to
comp.arch.fpga

Weng, > 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.

So you and I have had some time to discuss and ponder this.

Personally I am worn out and don't have further energy to afford this issue as I consider it a solved problem.

One of the things that shifted my mind away from "ORIF" is that there are mutual exclusion problems that it cannot solve. One you had brought up in a previous discussion (some time ago) where you had mixed conditions with some signals mutually exclusive and some not. I think this is a common case. Can you post one of the examples you shared with me previously and explain how this would be handled by "ORIF"?

...

Please use quoting properly as I can't tell your referenced text from your new thoughts. As a result, I cannot follow your line of thought at all, so I can't comment on all of it - it looks like you included too much text.

I will make an educated guess that this is the example on which you wanted to comment:

Please note that your original example for OutBus used all "orif" and did not mix elsif with orif, so yes there is no priority between E0 and E3 here and Data0 or Data3 is the correct answer.

Can "ORIF" also construct the equivalent to the following? OutBusBProc : process(RESET, CLK) begin if(RESET = '1') then OutBus '0'); elsif rising_edge(CLK) then OutBusB

Reply to
Jim Lewis

Colin Paul,

|---------------------------------------------------------------------------------------------|

|
|
|
|

|---------------------------------------------------------------------------------------------|

OOPS. I missed that. I had meant to reference the PSL function onehot0.

|---------------------------------------------------------------------------------------------|

|
|
|

|---------------------------------------------------------------------------------------------|

Reserved words have more strength than subprogram names. I would have to double check, but I think that if you re-use a subprogram name as a signal name in a design, the subprogram name becomes hidden and can only be referenced with a fully selected name. For old designs that do not use the subprogram, this is ok (or exactly the behavior you desire). In new designs, this situation is easy to avoid.

If two packages are referenced with the same subprogram name, then the subprograms are homographs and neither can be directly referenced and as a result can only be referenced with a fully selected name. So there is some concern with this, however, it is not a difficult one for a user to address.

While it is possible that syntax could be given a similar interpretation, I am not sure it would be a good thing.

Cheers, Jim

Reply to
Jim Lewis

Hi Jim, Simply say, there are several ways to specify that a group of signals is mutually exclusive.

In other words, there are several ways to do the same things. Now the question is which is best one to be chosen as part of standard of VHDL.

The differences between your way and mine are as follows:

1a. Your way advantage Your function name zero_one_hot() can be more compatible with same old function zero_one_hot(). But you admit there are still problems over there and you promise it is not a big problem.

1b. You way disadvantage: it must be done off-line with 2N+1 extra lines to do the same things: N signal declaration lines; N assign statements to new signals

1 assertion call statement.

2a. My way advantages are a. It provides on-line programming capability. b. It provides a unified language branch statement structure by mixing 'elsif' and 'orif'.

2b. Keyword 'orif' would conflict other old signal name orif users might have had used. I am not sure Colin has proved that it can be avoid or not. In this respect I would like other experts' help to determine it or resolve it.

Verilog uses new keyword 'unique' to provide on-line programming capability to specify mutually exclusiveness.

| 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

Reply to
Weng Tianxiang

Hi Jim:

  1. Your previous coding has error. "Please note that your original example for OutBus used all "orif" and did not mix elsif with orif," Please check my first posting over there and it mixes the use of 'orif' and 'elsif' starting from the first posting and it never uses keyword 'orif' only.

And your coding example is directly copied from your first post on this thread without any change.

You wrote two assertion statements to show your assertion statement ability, but coding is wrong. You never wrote a assertion that includes 6 signals from E0 to E5, but your coding was based on it. It is a little error not affecting out discussions.

  1. Jim asked: Can "ORIF" also construct the equivalent to the following? OutBusBProc : process(RESET, CLK) begin if(RESET = '1') then OutBus '0'); elsif rising_edge(CLK) then OutBusB
Reply to
Weng Tianxiang

Weng, Note the working group is staffed by volunteers. Initial proposals are ranked. If they rank high enough, they get passed to the extensions group. There if someone is interested in championing a proposal, it gets worked on. Without a champion, the proposal gets no where - even if it is something really good - ie: people do not have to work on things.

What the group tries to do first is to consider issues and not consider solutions. The person championing a proposal in fact, can either pick up the proposed solution or go in a direction that they think solves the problem.

My advice to you is to write a paper that is composed of two sections: Part 1: Identify the problem you are trying to solve. Since this is hardware centric, it would be appropriate to show schematics or block diagrams and code. With respect to the code, there should be several examples.

Part 2: Explain how your proposed solution solves the problems at hand and why it is as good as or better than other solutions. Show what it fails to do.

So far, I have not seen anything there that would warrant me investing more time in it, however, with your additional input in the form of a paper, may help.

Note, the most current revision of VHDL that is ready for vendor adoption is the Accellera draft 3.0, VHDL-2006. This revision includes PSL which includes the onehot0 built-in function (thanks to Colin Paul for the correction). So you would need to show what it does beyond what is currently available.

Cheers, Jim

Reply to
Jim Lewis

This clarifies these long discussions for me.

I couldn't agree more.

I agree. I should describe what I care about, not what I don't care about. This simplicity eliminates confusion.

Yes. I like to keep the logic description separate from the device and tool options.

-- Mike Treseler

Reply to
Mike Treseler

it

am

has

rch

a:

Colin,

My comment regarding indentation, though poorly stated on my part, was intended to support the traditional use of indentation, which is to visually indicate subordinate execution/analysis of statements. Since orif is not executed subordinately to elsif any more than additional elsif's are, it should not be indented beyond elsif.

In my informal proposal to Jim, I suggested that zero_one_hot() (or some standard function with that purpose) be defined in a VHDL- standard package as a VHDL function (i.e. in addition to, or independent of, a similar PSL function) so that it could be used with the VHDL ASSERT statement. Thus, if it were defined in a standard package, then the function name could be prefixed with the package name to make it unique from any other identifier.

Andy

Reply to
Andy

Weng, This is correct for your "State_A" example:

This is correct for your "OutBus" example.

Note I did not write an assertion for your OutBus example as although it would be nice to have for simulation, it is not needed at all to get the hardware you desire.

Not sure I am comfortable with mixing elsif with orif without other syntax to reinforce the intent. I am concerned that this would increase the design risk. Are you certain your testbench is good enough?

Without more analysis, I would rather write a separate specification for mutual exclusion (via the assertion) as this clearly states intent.

Why is a beginner too inept to write an assert statement especially for your trival code above?

You mention that the big draw back to using complex conditions is that you would have to create intermediate signals. Why is that bad? Again, I need to see compelling code cases.

Cheers, Jim

Reply to
Jim Lewis

Kolja,

This is another of the correct, but annoying pieces of code that some synthesis tools (Synopsys) did not implement the last I checked. Anyone know if they fixed this?

This is the primary reason for the new overloading on logic operations (AND, OR, ...) that allow mixing a scalar (std_ulogic) with a vector (std_logic_vector). As a result, with the new revision or old revision with supplemental overloading one can write:

result

Reply to
Jim Lewis

Weng,

I'll say this: I admire your tenacity.

The coding Jim provided was to illustrate a way, with today's standard (not including PSL), to code your orif example such that the synthesis tool would give the equivalent implementation.

Since you seem to be in favor of powerful and concise ways to implement this, an even better way to code this function would be to use arrays, particularly with more than just 6 choices involved:

process (reset, clk) is variable: temp : std_logic_vector(outbus'range); begin if reset = '1' then outbus '0'); elsif rising_edge(clk) then temp := (others => '0'); for i in e'range loop temp := temp or (e(i) and data(i)); end loop; if unsigned(e) /= 0 then outbus

Reply to
Andy

Hi Andy, I would like to answer your this question.

process (reset, clk) is begin if reset = '1' then outbus '0'); elsif rising_edge(clk) then for i in e'range loop if e(i) = '1' then outbus

Reply to
Weng Tianxiang

Hi Jim and Colin, Your assert zero_one_hot() (or any other function name) may not be the one I want.

Your zero_one_hot() tells simulator to check if all bits meet the zero or one active conditions. If it meets, return '1', otherwise return '0'.

The code doesn't have any AUTHORITY to let VHDL compiler to do any optimization, and it just has the AUTHORITY to let simulator run the function and check its correctness.

An assertion function is not authorized to transfer information to VHDL compiler !

In strict computer language meaning, any VHDL compiler has no OBLIGATION to do optimization work based on information of inputs from zero_one_hot() code even though they are designed to do so for the purpose.

What an assertion function can do is to return its value: true or false, how can it be used to transfer mutually exclusive information to VHDL compiler? IT IS ILLEGAL !

If so, that is totally different from 'orif' meaning: for 'orif' It not only gives the mutually exclusive information, but also orders:

  1. VHDL compiler to do code optimization based on the mutually exclusive information;
  2. Simulator to check if related mutually exclusiveness is met.

Because it is a keyword, it has AUTHORITY to issue two different commands to VHDL compiler and simulator, respectively, and the orders are mandated and it has no code to execute.

Finally I got my point.

Weng

Reply to
Weng Tianxiang

Jim,

In news: snipped-for-privacy@corp.supernews.com timestamped Thu, 30 Aug

2007 08:08:26 -0700, Jim Lewis posted: |-------------------------------------------------------------------------------------------------| |"Colin Paul, | |[..] | |> That would be true for plain VHDL without PSL, but he posted as if | |> zero_one_hot() is now part of VHDL from PSL (but it is not in my PSL | |> reference manual, unlike onehot0) so that would not necessarily | |> require that a VHDL identifier be changed. From the PSL standard: | |> "[..] | |> | |OOPS. I missed that. I had meant to reference the PSL function onehot0." | |-------------------------------------------------------------------------------------------------|

Muw wah hah hah, all shall bow down to my superiority.

|-------------------------------------------------------------------------------------------------| |"[..] | | | |While it is possible that syntax could be given a similar | |interpretation, I am not sure it would be a good thing. | | | |Cheers, | |Jim" | |-------------------------------------------------------------------------------------------------|

If we ever need to consider it, we can assess the pros and cons then.

Cheers, Colin Paul

Reply to
Colin Paul Gloster

Weng,

You're right, the loop code example is a good example. It beautifully illustrates the fatal flaw in 'orif': it cannot be applied to an arbitrary (parameterized) number of conditions. You still have not acknowledged this flaw.

As for "extra" declarations and assignments, I took YOUR example that had separate signals for E0, E1... E5, (which must have been declared and assigned separately somewhere else), and simply combined them into an array (with one fifth the signal declarations). Likewise I took YOUR data0, data1...data5 signals (which also must have been declared and assigned somewhere else), and combined them, with a similar SAVINGS in declarations. So, tell me again how it would take more code to use the arrays that it did the separate signals?

This is one of my biggest pet peeves when I see others' code that has signals named the same, with incrementing suffixes: Use an array, and once it is in an array, use a loop. It takes less code, not more, to use an array.

As for your later example:

assert zero_one_hot(((TWindowLoad_E0_L_H and nC_BE_R0(3) = '0'), (TWindowLoad_E0_H_H and nC_BE_R0(7) = '0')));

I simply cut and pasted the expressions that were deemed mutually exclusive from your code. Not a lot of typing going on there.

If, on the other hand I wanted your original code to be a little more readable, I might have declared/assigned a signal/variable or two, aptly named, to represent the conditions in a more human readable form. Then those same signals and variables could be used in the asserted function call as well. Yes, a little more code, but a little more readable too.

I don't know about everyone else, but I don't want VHDL to look like Verilog! Verilog does some really stupid things, and I don't want us jumping off the same cliff they just did.

Take a closer look at that (System?)Verilog code. They started out with an array (E) filled with random values, and then broke it back out into discrete signals to use in the 'if' tree (could they have just used elements of E?). All because they can't use 'unique' in a loop! That is a fantastic example of the folly of unique/orif! Thanks!

Andy

Reply to
Andy

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.