Only tells the simulator that it cannot put a value outside the range of 0 to 255, inclusive, into myint. There is no authority to command that a synthesis tool implements myint as an 8 bit value, but every single synthesis tool in existence will do just that.
Taken a step further, a counter, coded with an integer, will not roll over automatically. Yet the synthesis tool understands that the definition of the integer type means that when the maximum value is incremented (and stored back to the integer!), the result is undefined (i.e. would cause an assertion in the simulator). With this information, the synthesis tool creates the circuit such that it would roll over if that ever happened, since it is free to do so because there is no simulator behavior to match in that case. The reason the synthesis tool creates such a hardware counter is that it takes less hardware to roll over than to do anything else. Again, the language did not command the synthesis tool to do it, but the language gave the synthesis tool enough information that it could make the optimization.
I have seen cases where I defined a counter with a range of 0 to 5. The synthesis tool optimized the decode function for the value 5 because it knew that 7 was not allowed (this may have also been the result of a reachability analysis on the code for the counter). There was no command to do that, it just did it, because it could do so, while preserving the behavior of the code.
Likewise, an assertion does not "command" a synthesis tool anything. But, just like ranges on integers, the assertion gives the synthesis tool information that it can use to optimize the circuit appropriately.
Declaring an array of vectors, and accessing only one or two elements (single or dual port) per clock cycle, does not "command" the synthesis tool to do anything. Yet most, if the target allows it, will implement the circuit with a RAM, because the synthesis tool recognizes that a RAM is the most efficient way to implement the behavior.
Your concept of the VHDL language "commanding" the synthesis tool to do things is not accurate. The synthesis tool simply, to the best of its ability, creates a circuit that exhibits the same behavior that the code would exhibit in a simulator. There are standardized methods of describing the behavior (e.g. clock edge specifications, etc.) so that all tools will recognize the same behavior and implement it in a similar manner, but the language is not commanding the synthesis tool to do anything except implement the behavior in a circuit.
Weng, Synthesis tools already commonly handle some form of attributes and metacomments.
Attributes (I have used flavors of the following in both Xilinx and synplicity): signal T1, T2 : std_logic; Attribute keep : boolean ; Attribute keep of T1, T2 : signal is true ;
Hi Jim, If you use Attributes to declare mutually exclusiveness, I think it is OK, no problem. Because attributes is only used for compilers. But your method is using a function whose input contents are expected to be transferred to compiler, it is unprecedented !!!
Using an attributes is certainly more natural than Jim's assertion function().
Adam, I don't dispute your claim that if mutually exclusive group is declared, they have their advantages over 'orif'. In my paper in 2002, I declared two methods, one for 'orif', another for keyword 'Exclusive' to declare not only a group of signals, but a group of state machines. At that time, I knew both had their own advantages in different situations.
Now the problems are:
Jim's method uses assertion function(); Why don't we use attribute? No precedent example can be found by using a assertion function() structure to transfer information to VHDL compiler.
Including a group mutually exclusive method shouldn't expel another on-line programming method 'orif'. That is my point !!! Get two methods and let engineers to determine what best fit their demand.
There are a lot of situations that your variable counter method fails, but 'orif' method best fits.
I will re-post my longest 'orif' code segment from my coding to show you the other alternative way to do the same things.
Please count how many conditions contained in if() and elsif() whose equations in any of your project you use loop structure to generate, and tell me the ratio.
My ratio is 95/5 in favor of on-line programming.
In my opinion, your mutually exclusive situations should be expected to have the same ratio.
Your coding has a big and fatal problem and never should be used in any situations like that: assert zero_one_hot(((TWindowLoad_E0_L_H and nC_BE_R0(3) = '0'), (TWindowLoad_E0_H_H and nC_BE_R0(7) = '0')));
Why? I will tell you later. Think of it yourselves and you should know why.
I tend to prefer one method over two, as long as the one method handles every situation that the second method does, and already exists within the syntax of the language. If I write a zero_one_hot() function today, and use it in my code, there is not a single tool out there that will fail on it. Synthesis tools may not yet know how to use it, but they'll just ignore it and go on. On the other hand, if I put 'orif' in any of my code, then every tool (editor, simulator, formal analyzer, synthesis, etc.) I use it on will have to be updated to accept it, or they will error out. That takes a lot longer to happen, and no tool can effectively support it until most/all tools do. That would be acceptable if a keyword/statement change were the only effective way to get the capability we desire, but it's not.
An assertion (psl or native vhdl) is verified during simulation and/or formal analysis. An attribute is a piece of information that is assumed to be true, but not verified. If we used attributes, then there would be no way to determine that we had correctly specified the attribute.
I think the engineers here have spoken (not that this forum is a/the standardization authority); you're just not listening. I'm not in favor of adding a statement/keyword to the language for a purpose that is better served within the bounds of the existing language, when there has been essentially no support for it from anyone except you.
I can tell.
Nope, I use arrays and loops closer to 95% of the time. I hate typing and checking long if/elsif statements to make sure I have the right suffixes matched up. If I find myself using one, I back up and figure out where I went wrong.
Look, I'm not here to play games with you, nor is anyone else. If you see a bug, tell us; we've all got better things to do that wait for you to enlighten us.
Thank you for your response. I learn something very important from you through this topics discussion.
Why? Never copy any dynamic code segment to other place. Because code is changing and you have two code copied at two different places. When you change one copy, most of time, you would forget the 2nd copy. The fatal error is a timing bomb, not now.
I really don't understand how you reach 95% ratio to use loop to write data bus.
For example, a data bus (63-0) loading, you have 5 cases, how can you use loop to implement the code? because each loading condition equations are different. It is unbelievable that you would 1) define a unsigned(4-0) in the definition area; 2) assign each condition to each bit at concurrent area; 3) then do a loop in a sequential area; 4) don't forget assert function().
That is why Verilog introduce unique keyword. Now you favors one over another, it is OK, but it doesn't guarantee that you will never use another alternative method if it is available.
All side kick signals, 1 bit each, they are very short, but very important to control data flow, most of them must be written in separate conditional equations, how can you do them in a loop? In one of my designs, there are 2,500 lines for signal definition part, there may be 500 side kick signals, their coding is very short, but most of time the loading is mutually exclusive. It would be very pain to use 3 steps to define mutually exclusive situations if only one definition is used.
Hi Kolja, This topics has two groups of people, one for how to best define mutually exclusiveness in VHDL, another who don't believe it may provide any benefits to design.
You are the one of second group.
I would like to repeat a famous English sentence from Altera I learned when I wan installing Altera software: What you can do, we can do better.
My opinion is when VHDL compilers get more information about mutually exclusive information, what you can do, the VHDL compilers can do better.
VHDL compilers can generate all coding you showed for one level of mutually exclusiveness. You may not write efficiently for code with two levels or even three levels of mutually exclusiveness. Personal power is limited and VHDL compilers can be trained to do more mechanical things than any human.
-- It is Jim's coding OutBusA : process(RESET, CLK) begin if(RESET = '1') then OutBus '0'); elsif rising_edge(CLK) then if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then OutBus
You are taking the wrong approach. Your arguments are repetitive and you keep thinking there is a win-lose situation.
At the risk of repeating myself:
"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."
To adopt any proposal into the language, this work must be done. I am not sure anyone else feels passionate enough about it to volunteer to do it. You feel passionate about it. If you do the work and work out the issues, you may be able to breathe some life into it - although I am not convinced of its value unless you can show a compelling use case as I do not know of one myself.
I would use the newsgroup to bounce your ideas off of - and listen to the advice you get.
I have quited my job since last October to devote my full energy to develop other adventure personally. Since then I have been kept in pay roll with full pay to do some maintenance work part time.
Today is my last pay day. My company was bought by another company this week.
So I don't have time to do the job you asked now. First I have to make money out of my current home project. If the project is finished (expected to finished within 3-6 months from now), I will publish them on this group to sell and stir another round of discussions. 'orif' project is my amateur project only when I have time to do it.
I know nothing about PSL and just printed VHDL-1993 and VHDL-2002 today and started reading them. I have no interest to learn PSL. I am more interested in algorithms and circuit development, not the VHDL language. For my personal use, VHDL-1993 standard plus 'orif' is enough. That I am pushing for 'orif' adoption is only for my personal use. Now I don't need it as desperately as before.
I am not qualified in any sense to write the report. I would like to have some big canon to co-sponsor the 'orif' work and I would like to provide examples and drawings, but not full report, especially English text part that is my weakest point. The reason is I am not a good English writer, not a good persuader, even though many times I have many creative ideas, but am not good at writing them systematically and quickly. All ideas about 'orif' are on this topics, I have no any ambition in my life to fight it forever.
With 'unique' keyword introduced in Verilog domain, the scientists and engineers over there have demonstrated why they were. VHDL should provide the same tool as 'unique' without doubt. Are specialists in Verilog group so stupid that they created two new tools to do the same things without a good reason? The reasons are plentiful, but none in VHDL world shows full support of it. What a pity !
The reason is what I have presented in my posting: in-line programming capability for a very important feature that was considered only after
2002.
Duplication of two fundamental tools is less a issue if they can provide convenience, no matter your personal favors are. Now persons' favor is more important than facts and become deciding factor.
'orif' cannot provide more information than what members of a mutually exclusive group are. Your method provides the message and there is no more message to provide to VHDL compilers.
The only advantages of 'orif' are a. in-line programming capability; b. mixing 'elsif' and 'orif' language structure.
No more.
The advantage of 'orif' over 'unique' is that 'orif' can be selectively used to replace 'elsif' at any place and at any levels in a 'if' statement.
Sorry for using word 'fight' in previous posting. There is no fight, just exchange ideas and I got a very special gift from the discussions.
Yes. But mutual exclusiveness is only a small, special case of input don't cares (unreachable input combinations). The tools shoul dhave ways to specify these, not only mutual exclusiveness. For example there might a vernier input that only has the valid combinations "0000", "0001", "0011", "0111", "1111". Mutual exclusiveness can not provide this hint, assertions can. Because of this the assertion based approach is allready part of VHDL2006. It is a very general approach, and of course there are special cases for which a special keyword makes live easier, but you still need to solve the general case. (Imaging how much simpler the design of a polynomial interpolation would be, if VHDL had a polynomial type and an interpolation keyword)
Because the formulation of these inputs sets can be a little cumbersome, and because there might be sequential depencies on these (and for a couple of other reasons) PSL was included as a way to specify assertion constraints.
It will be synthesized to a gated or netlist. This is very the VHDL- specific part ends. The technology mapper will than select an appropriate implementation for the or gate that might be based on a carry chain implementation.
Yes. The formulation is redundant, even without knowledge of the input don't cares.
But nothing else but that. That is not enough.
How is that? I am the one that is telling you that your approach is to limited and does not utilize the power of logic synthesis to the possible extend. Handling of input don't cares is solved since the days of ATPG based synthesis.
As far as coding style goes: I prefer prefer to explicitly code that the result is a don't care for certain input conditions as to have this as an implicit side effect of an operation.
Kolja Sulimma
P.S.: Here is another coding style, assuming the inputs and Es are in arrays:
output := (others =>'-'); -- this line allows the compiler to do the optimization, most compilers DECIDE against it for i in input'range loop if e = (i=>'1', others=>'0') then output := intput(i); end loop;
if you know the optimization and want to force it: for i in input'range loop if e(i) = '1' then output := output or intput(i); end loop;
Yes. The formulation is redundant, even without knowledge of the input don't cares.
No, Jim's coding is the best coding we can do now. The equation is never redundant !
-- It is Jim's coding OutBusA : process(RESET, CLK) begin if(RESET = '1') then OutBus '0'); elsif rising_edge(CLK) then if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then OutBus
On 2 Sep., 02:14, Weng Tianxiang wrote: > As far as "don't care" situation is concerned, VHDL compile ignores it
Finally you get my point. There is no need to change the language, you only need to change the compiler to support the existing language features: - interpretation of assertions to deduce reachability don't cares.
- honoring output observability don't cares coded as '-' during optimization
Again: The existing language features can do a lot more than mutual exclusiveness. You only need compilers that use them. Adding a keyword for a special case to the language will only delay adoption of the general case.
Hi Colin, I have difficulties to understand following segment you are talking about the name conflicts.
|[..] 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). | | | | [=2E.]" | |--------------------------------------------------------------------------= =AD|
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 ::=3D letter { [ underline ] letter_or_digit), e.g. by starting with an underline or by containing a percentage sign.
I would like to know what Jim's name conflicting mechanism is.
1=2E Here I have an old file using the following statements: assertion zero_one_hot(); -- the function was defined in an old file
Here I have another new file using the following statements: assertion zero_one_hot(); -- try to refer to Jim's function.
Those two above files must be compiled together using 2006 version. What happens?
No name conflicting?
2=2E Here is orif name conflicting.
Here I have an old file containing orif as a signal and has the following statements.
Signal orif : std_logic; .=2E. If(orif =3D ...) then
Here I have an new file containing orif as a signal and has the following statements.
Signal orif : std_logic; .=2E. If(orif =3D ...) then
When the old file is compiled by new 2006 version, what would happen with above two statements? When the new file is compiled by new 2006 version, what would happen with above two statements?
How does 2006 version know that what it deals with is an old file or a new file with your method?
Jim, here is my solution to your naming conflicting problem.
VERY SIMPLE AND COMPLETE !!!
If a 2006 version compiler uses file date to distinguish old file or new file by reading their file generation year, before 2007 and after
2007, there is no any trouble to deal with new or old files and both files can safely be compiled without error.
For 2006 compiler do the following things:
1=2E Read vhd file;
2=2E Read their last update date and get year number;
3=2E When year number =3D 2007, oris is in reserved word list.
4=2E If more accurate date is needed, it can add month and date to the check list.
It doesn't need to add any extra characters before orif. I think Verilog had used the same method as I suggested and it would guarantee that there is no naming conflict.
Jim and Colin, Here is a more flexible method that can avoid orif name conflicting problem at any situations.
For 2006 compiler do the following things:
When being installed, VHDL 2006 compiler pops up a window to allow clients to set a date after which all VHDL files will be compiled with orif feature, then writes the date into VHDL initial file with item:
2006_orif_Starting_Date = 09/02/2007;
Read vhd file;
Read its last update date;
If the file date is after the date contained in
2006_orif_Starting_Date equation of VHDL.ini, orif is in reserved word list, otherwise orif is cleared in reserved word list.
All trouble happens only at installation. If it is found later there is need to change the effective date, users can modify the date contained in 2006_orif_Starting_Date equation of the initial file.
|-----------------------------------------------------------------------------------------| |"On Aug 29, 3:13 am, Colin Paul Gloster | |wrote: | |> Jim, | |> | |> 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 | | | |Hi Colin, | |I have difficulties to understand following segment you are talking | |about the name conflicts. | | | ||[..] 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. | | | |I would like to know what Jim's name conflicting mechanism is. | | | |1. Here I have an old file using the following statements: | |assertion zero_one_hot(); -- the function was defined in an old file | | | |Here I have another new file using the following statements: | |assertion zero_one_hot(); -- try to refer to Jim's function. | | | |Those two above files must be compiled together using 2006 version. | |What happens? | | | |No name conflicting?" | |-----------------------------------------------------------------------------------------|
Weng,
Please reread news: snipped-for-privacy@corp.supernews.com in which it was confirmed that the function is not called zero_one_hot but is called onehot0 and which has already been part of the PSL standard for over a year and please reread news:slrnfddf2i.828.Colin_Paul snipped-for-privacy@mizar.iet.unipi.it in which it is pointed out that the name conflict would appear only in PSL (and that it would still be possible to use the name with a conflict) unlike introducing your keyword which would affect not only every PSL file which already had the name orif, but also every VHDL file which already had the name orif.
|-----------------------------------------------------------------------------------------| |"2. Here is orif name conflicting. | | | |Here I have an old file containing orif as a signal and has the | |following statements. | | | |Signal orif : std_logic; | |... | |If(orif = ...) then" | |-----------------------------------------------------------------------------------------|
An if statement does not need ( nor ) in this manner.
|-----------------------------------------------------------------------------------------| |"Here I have an new file containing orif as a signal and has the | |following statements. | | | |Signal orif : std_logic; | |... | |If(orif = ...) then | | | |When the old file is compiled by new 2006 version, what would happen | |with above two statements?" | |-----------------------------------------------------------------------------------------|
It would work (if you remove the parentheses).
|-----------------------------------------------------------------------------------------| |" When the new file is compiled by new 2006 | |version, what would happen with above two statements?" | |-----------------------------------------------------------------------------------------|
The contents of the new file are identical to the contents of the old file and the files will be treated identically.
|-----------------------------------------------------------------------------------------| |"How does 2006 version know that what it deals with is an old file or a | |new file with your method?" | |-----------------------------------------------------------------------------------------|
It does not need to.
|-----------------------------------------------------------------------------------------| |"Jim, here is my solution to your naming conflicting problem. | | | |VERY SIMPLE AND COMPLETE !!! | | | |If a 2006 version compiler uses file date to distinguish old file or | |new file by reading their file generation year, before 2007 and after | |2007, there is no any trouble to deal with new or old files and both | |files can safely be compiled without error. | | | |[..]" | |-----------------------------------------------------------------------------------------|
Not acceptable. Some people still code in VHDL87. Some people code in VHDL93. Setting a tool switch can be used to choose the language. When something was written (which could simply have been copied from a VHDL87 book in 2010 or could have been a ten year old file whose time stamp was changed because comments were reformatted) does not indicate what it was written for.
Hi Colin, OK, I accept your following explanation:
Not acceptable. Some people still code in VHDL87. Some people code in VHDL93. Setting a tool switch can be used to choose the language. When something was written (which could simply have been copied from a VHDL87 book in 2010 or could have been a ten year old file whose time stamp was changed because comments were reformatted) does not indicate what it was written for.
With compiler switch for different versions, why is there still orif name conflicting problem?
For 2006 version, keyword orif can be safely used, for old one, there is no keyword orif.
Hi Colin, I finally got the right answers and realized that orif is used in 2006 version for other usage.
Jim's always suggested that orif would conflict with OLD files. With version switches you mentioned, the Jim's claim has not been true since the beginning.
Now it seems to me that any new keywords can be used in a new version if there are version switches and the names are not conflicted within the new versions.
Can we use new keyword OIF or _ORIF for the mutually exclusive purpose?
OIF is better than _ORIF as a keyword. The fewer letters, the better.
How the new keyword is spelled is not essential, but it is essential to introduce a new keyword to provide in-line programming capability.
Do you have any reservations about the introduction of new keyword for the purpose? Why?
I have a better solution to your complain: "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. "
The better method to distinguish orif from elsif and that will ultimately fend off any future tough questions about it is to put the two keywords in two keyword listing tables in text editor's file and they will be shown in two different colors, one RED, another PINK, as TextPad, Emac, or any text editors do without conventional indent practise change. It is a trivial thing, but exaggerated to a disadvantage and failure at a strategic level.
I disagree with your following comment:
Now, if we are allowed to extend the standard (not the language), with the use of a synthesis-aware assertion and zero_one_hot() function, this can be greatly simplified, while also making it more functionally clear:
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
Wow....now you're suggesting color coding as a method to handle your ambiguities?
You haven't demonstrated your insight either...but that's my opinion.
I agree..almost. Sometimes you'll put in these assertions to check the code you just wrote not so much as a check on what you've just written but as a check down the road when the code gets modified for whatever reason and the modifier is maybe unaware of why their change will cause a problem down the road. A well crafted 'report' after the 'assert' will explain why it is important and more importantly it will be in 'live code' that actually gets checked, not in a comment where it is not.
In any case, the assert that was added can be considered a simulation time waster or info from a maintability standpoint.
Andy's code does not assume mutual exclusiveness it is a priority encoding to produce outbus.
That's your 2 cents about what you think compilers need. Do you have ANY references or evidence to back up that claim? If not, stop shouting it.
Personally I prefer enumerated types to express mutual exclusiveness where appropriate and sum of products formation (as shown in Jim's example that you've posted below a bit) where there are things that 'should' be mutually exclusive but can not be formally shown to be. There are other constructs besides the 'if' statement that are quite understandable; your assertion that 'if...endif' is the 'simplest and unified way' represents your opinion not some grand truth. The fact that you think that it needs to be augmented with a new 'orif' keyword suggests that the 'if' statement is not quite so unified after all.
I agree, but as mentioned before, the assert statement with a descriptive report allows for passing of obscure design information from one design time to another...sort of a 'heads up' for the designer picking up the code 1 year down the road.
And they generally do. Looking at the technology map view of synthesized code is generally enlightening. In any case, your opinioin has not yet been substantiated in fact with anything you've posted so far.
What do you mean my 'two levels' or 'three levels' of mutual exclusiveness?
I don't think so, unless you assume the various 'E' are one hot encoded. Had Jim made that assumption he would have written it without the "if (E0 or E1 or E2 or E3 or E4 or E5) = '1'" as well I'm sure. In any case, as written, Jim's handles the case where none of the 'E' happen to be set. Whether or not this is appropriate depends on what assumptions there are with 'E'; personally I would think that the condition where none is set is probably the more common case when bringing together various external signals and trying to say that they are in some sense mutually exclusive.
But you've presented nothing to indicate that 'orif' would map to anything different. In fact, you can not. The rules of boolean logic require only 'and', 'or' and 'not', they do not require 'orif'. You claim (but present no evidence) that the new 'orif' keyword could in some cases present some resource or timing improvement but you have no basis for that claim and nothing at all to back it up. Looking at source code examples and suggesting that it would improve anything is naive at best.
The only claim you could possibly make is that 'orif' is a productivity enhancer perhaps because it is fewer lines of code (but by perusing Andy, Jim and your code it would seem that 'orif' is the longest) or because it is less error prone in use (doesn't appear to be).
In case you're interested, Andy's version consumes 9 logic elements and has four levels of logic; Jim's version consumes 6 logic elements and has three levels of logic. The difference comes about because Jim's version take full advantage of the supposed knowledge that the data inputs are all mutually exclusive whereas Andy's makes no such assumption. These were benchmarked using Quartus targetting a Cyclone II which has 4 input LUTs as the logic primitive. Code I used posted at the end of this posting.
Actually that's a good thing about 'orif'. Logic should be described by logic functions not assertions. Those that are proposing using assertions to drive the synthesized code in some fashion are barking up a bad tree....what happens when the supposedly impossible happens and the asserted condition is no longer met? What will the synthesized result produce? It better be what is described in the logic description which therefore implies that the asserted statements really should be ignored during synthesis for the purposes of optomizing any logic functions.
What guarantees the exclusiveness? The engineer's code of honor? If it is reeeeeally mutually exclusive it could be described by an enumerated type.
Kind of looks like an enumerated type definition too....hmmm
Hopefully you'll present actual results to back up your so far baseless claims, it would make for a much stronger case for 'orif'. Good luck with your work.
KJ
Jim and Andy's versions implemented below. Uncomment out the one you'd like to synthesize with. By the way, Jim, Andy and Weng's code as presented in this thread are all flawed and not compilable. In some cases, 'outbus' is treated as a vector, in others it is treated as a single bit. I modified each so that 'outbus' is a single bit which appears to be the real intent here....apologies if it's not.
--------- CODE USED TO IMPLEMENT ANDY AND JIM'S VERSION ---------- library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all;
entity test is port ( clk: in std_ulogic; reset: in std_ulogic; e: in std_ulogic_vector(7 downto 0); data: in std_ulogic_vector(7 downto 0); outbus: out std_ulogic); end entity test;
In the (Jim's?) original example, the output was unchanged if no enable bits were set. Therefore the additional check on e1 or e2 or e3... is necessary to make sure that only if any enable bit is set does the output get a new value.
An initial assignment to (others => '-') only takes care of the case if no enables are set. The order of execution of the loop provides priority coding, in that the rightmost bit of enable that is set will win (in the first example), no matter how many are set.
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.