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
New keyword 'orif' and its implications
Started by ●August 27, 2007
Reply by ●August 28, 20072007-08-28
"Weng Tianxiang" <wtxwtx@gmail.com> wrote in message news:1188263507.145095.110420@q3g2000prf.googlegroups.com...> 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; >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 <= (others=>'0'); OutBus1 <= (others=>'0'); OutBus2 <= (others=>'0'); OutBus3 <= (others=>'0'); OutBus4 <= (others=>'0'); OutBus5 <= (others=>'0'); elsif rising_edge(CLK) then if (E1 = '1') then OutBus1 <= Data1; else OutBus1 <= (others=>'0'); end if; if (E2 = '1') then OutBus2 <= Data2; else OutBus2 <= (others=>'0'); end if; if (E3 = '1') then OutBus3 <= Data3; else OutBus3 <= (others=>'0'); end if; if (E4 = '1') then OutBus4 <= Data4; else OutBus4 <= (others=>'0'); end if; if (E5 = '1') then OutBus5 <= Data5; else OutBus5 <= (others=>'0'); end if; OutBus <= OutBus1 or OutBus2 or OutBus3 or OutBus4 or OutBus5; end if end process; Google comp.arch.fpga for a thread subject :- Multidimensional Register in Modul Port List and read Mr. Bromley's posts. HTH., Syms.
Reply by ●August 28, 20072007-08-28
On Tue, 28 Aug 2007 01:11:47 -0000, Weng Tianxiang <wtxwtx@gmail.com> 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 jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.
Reply by ●August 28, 20072007-08-28
Weng Tianxiang <wtxwtx@gmail.com> 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)
Reply by ●August 28, 20072007-08-28
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
Reply by ●August 28, 20072007-08-28
On Aug 27, 9:11 pm, Weng Tianxiang <wtx...@gmail.com> 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
Reply by ●August 28, 20072007-08-28
On Aug 28, 3:59 am, "Symon" <symon_bre...@hotmail.com> wrote:> "Weng Tianxiang" <wtx...@gmail.com> wrote in message > > news:1188263507.145095.110420@q3g2000prf.googlegroups.com... > > > > > 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; > > 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 <= (others=>'0'); > OutBus1 <= (others=>'0'); > OutBus2 <= (others=>'0'); > OutBus3 <= (others=>'0'); > OutBus4 <= (others=>'0'); > OutBus5 <= (others=>'0'); > elsif rising_edge(CLK) then > if (E1 = '1') then OutBus1 <= Data1; else OutBus1 <= (others=>'0'); end > if; > if (E2 = '1') then OutBus2 <= Data2; else OutBus2 <= (others=>'0'); end > if; > if (E3 = '1') then OutBus3 <= Data3; else OutBus3 <= (others=>'0'); end > if; > if (E4 = '1') then OutBus4 <= Data4; else OutBus4 <= (others=>'0'); end > if; > if (E5 = '1') then OutBus5 <= Data5; else OutBus5 <= (others=>'0'); end > if; > OutBus <= OutBus1 or OutBus2 or OutBus3 or OutBus4 or OutBus5; > end if > end process; > > Google comp.arch.fpga for a thread subject :- > > Multidimensional Register in Modul Port List > > and read Mr. Bromley's posts. > HTH., Syms.- Hide quoted text - > > - Show quoted text -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
Reply by ●August 28, 20072007-08-28
> > 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 <= Data1 when (E1 = '1') else OutBus1 <= (others=>'0'); OutBus2 <= Data2 when (E1 = '1') else OutBus2 <= (others=>'0'); OutBus3 <= Data3 when (E1 = '1') else OutBus3 <= (others=>'0'); OutBus4 <= Data4 when (E1 = '1') else OutBus4 <= (others=>'0'); OutBus5 <= Data5 when (E1 = '1') else OutBus5 <= (others=>'0'); OutBus : process(RESET, CLK) begin if(RESET = '1') then OutBus <= (others=>'0'); elsif rising_edge(CLK) then OutBus <= OutBus1 or OutBus2 or OutBus3 or OutBus4 or OutBus5; end if end process; I think Mike's comment sums it up... HTH., Syms.
Reply by ●August 28, 20072007-08-28
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
Reply by ●August 28, 20072007-08-28
On Aug 28, 10:17 am, "Symon" <symon_bre...@hotmail.com> wrote:> > 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 <= Data1 when (E1 = '1') else OutBus1 <= (others=>'0'); > OutBus2 <= Data2 when (E1 = '1') else OutBus2 <= (others=>'0'); > OutBus3 <= Data3 when (E1 = '1') else OutBus3 <= (others=>'0'); > OutBus4 <= Data4 when (E1 = '1') else OutBus4 <= (others=>'0'); > OutBus5 <= Data5 when (E1 = '1') else OutBus5 <= (others=>'0'); > > OutBus : process(RESET, CLK) > begin > if(RESET = '1') then > OutBus <= (others=>'0'); > elsif rising_edge(CLK) then > OutBus <= OutBus1 or OutBus2 or OutBus3 or OutBus4 or OutBus5; > end if > end process; > > I think Mike's comment sums it up... > > HTH., Syms.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. 2. 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
