So you are not interested in what VHDL already has, you just want to blindly add duplicative, invasive new features to the language so that you don't have to learn these existing, more powerful methods?
This is not a language issue. The language already supports communicating mutual exclusivity and many more powerful notions. Existing synthesis tools do not use the information; that is the problem. It would help them if there was "a standard way" to communicate this to them (which is possible within the existing language). Just like there is a standard way to communicate a synchronous process that implies flip flops: there are lots of ways to describe that behavior in VHDL, but only certain ones are universally accepted by synthesis tools.
I have ordered one of 3 books Colin suggested, and found that they don't contain PSL. I will print VHDL-2006 today.
Are you sure that Jim's assertion method in communicating mutually exclusivity to VHDL compiler is good enough without need for 'orif' introduction?
As I described before, if you use Jim's method and want to get the information to compiler, you must insist the 'if...end if' structure to get the benefits, otherwise it is useless, meaningless and wasting time.
When you use 'if...end if' structure, 'orif' is the best choice, no question! You can add the information line by line at any levels as you want.
My goal is to make writing VHDL for a hardware engineer as easy as writing C for a software engineer using 'if...end if' structure with mixing 'elsif' and 'orif'.
Thanks for pointing out that my example, without the assertion, assumes priority encoding, and not mutual exclusivity. This is often forgotten in sequential code.
The only problem with enumerated types is that they are not applicable to an arbitrary (i.e. parameterizable) number of values. So a uniform way of encoding a arbitrary length vector as enumerated values does not exist. However, one could choose binary encoding of a one hot value as an alternative. The trick is doing binary encoding in a way that takes advantage of mutual exclusivity. It can be done, but I have not experimented to find out if the encode/decode is able to be optimized out.
First you don't like using additional signals (one signal per conditional expression), and using the same signal in the condition as the assertion. So I demonstrate that additional signals are not necessary. I never said that using duplicate expressions to avoid additional signals/variables was a good idea, I just showed you how you could use them to avoid your dreaded extra signals (which, by the way, is almost always more self-documenting than the expression, even if it is not used in more than one place).
It really isn't hard to use arrays and loops if you think about it.
Most data bus driving circuits are based on decoding some sort of address with qualifiers (read_enable, etc.). Therefore I have as inputs either the address and enable, or I pre-decode (for timing reasons) the address into an array of strobes. Thus there are not separate lines for assigning array elements with individual signals, because I avoid the individual signals in the first place. Even if there are individual signals, they are often passed in on ports. Rather than have individual ports for the individual signals, I have an array port, with the signals bound to elements of the array port in the instantiation. No more code required to use an array than individual signals, and even less code in the entity declaration.
I used to design fpgas with a big, centralized address decode module. That leads to lots of individual signals. Now I distribute the address and enables to individual modules, along with a generic for base address, etc. and let each module decode its own enables and determine when to drive the data bus with what. I also use a lot of tri-state logic that gets converted to multiplexers automatically, simply because it lets me decentralize the data bus loading. This also has the added benefit that the synthesis tool automatically assumes that the tri-state enables are mutually exclusive (otherwise the simulation would not have worked anyway), and optimizes the multiplexers automatically.
You have to think about avoiding the individual signals in the first place, not just how to convert them into arrays.
It depends on the definition of "good enough", but there is not a single situation where an assertion could not reasonably be used, but where 'orif' could be. Conversely, there are several situations where 'orif' is not an option, but an assertion would be.
Not necessarily. There are many mutual exclusivity situations that might even span different processes. Consider two processes that both use multipliers. If both processes' uses of their multipliers are enabled by specific conditions that can be shown to be mutually exclusive, the synthesis tool has enough information to enable them to share one multiplier. Of course whether or not current synthesis tools share resources across processes is beyond the scope of this argument.
Another example is two state machines that are never both in a state that uses a multiplier (or some other expensive, shareable resource).
Both of these situations are certainly possible with if-then code structures, but they don't have to be, and can still take advantage of an assertion to verify and communicate the mutual exclusivity.
'Orif' is only an option if you can code the function in an if-ELSIF structure, which cannot be done for a parameterized loop of if-then structures.
Ouch! Then just use verilog; it is already as "easy to use as C" (and to get into trouble with). ;^)
The way I see it is thus: The barrier to new syntactical changes in VHDL, particularly those that affect the synthesizable subset of VHDL, should be quite high because of the problems that occur until every tool in the chain can even read the new syntax. Therefore, syntactical changes should only be made to allow functionality that cannot be reasonably supported within the existing syntax. Of course, that depends on the definition of "reasonably", but I just don't think 'orif' exceeds the barrier.
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.