New keyword 'orif' and its implications

Hi,

I don't want to get involved in a language crusade, and I don't like to crosspost so you'll need to read this on CAF, but why not just do something like this? :-

OutBusA : process(RESET, CLK) begin if(RESET = '1') then OutBus '0'); OutBus1 '0'); OutBus2 '0'); OutBus3 '0'); OutBus4 '0'); OutBus5 '0'); elsif rising_edge(CLK) then if (E1 = '1') then OutBus1

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.

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

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

-- Mike Treseler

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.

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

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

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

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.

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

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.

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.

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.

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

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

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

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.

Does that even mean anything?

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

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

KJ

Hi Syms, Your code timing is fundamantally inferior to my code timing.

In your code, you specify 6 groups of data registers, then each bit of its output registers gets a combinational bit output.

In my code, all 5 groups of signals are combinational signals and through a carry chain structure in FPGA, the output registers get the fastest clock-to-output timing result.

Weng

I knew this would happen...

Is this 'fundamentally inferior'?

OutBus1

Weng,

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

Hi Syms,

1. Are you sure that Xilinx FPGA compiler will generate a carry chain structure to meet your design requirements? You must pray they would do so, but with new keyword 'orif' Xilinx FPGA compiler will be mandated to map 'orif' structure into a carry chain structure without doubt.

That will be the benefit everyone would enjoy.

Letting a special VHDL language structure refer to a carry chain implementation in FPGA is a wonderful thing.

1. Which writing pattern between ours is better, more concise and more impressive with the price of a new keyword 'orif' introduction?

I know that anything can be written in one way or the other in VHDL, but mutually exclusiveness is an ubiquitous phenomenon and it should be reflected in VHDL language structure. Its referring to carry chain in FPGA is really a God's gift, why don't we accept it?

Weng

Weng,

I was almost starting to agree with you, until you said this...

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.

Hi Jonathan,

1. How 'elsif' and 'orif' work together?

See the following example:

If(E0 = '1') then State_A

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

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.

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

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

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

2. 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)

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.

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

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

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

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

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

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