New keyword 'orif' and its implications
Weng Tianxiang
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
Jonathan Bromley
Weng Tianxiang <wtx...@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...@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.
Marcus Harnisch
[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; [...]
Mike Treseler
> 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
KJ
> Hi,
> I open a new topics from previous one to try to stir another round to
> introduce a new keyword 'orif'.
>
>
>
> > > '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.
>
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.
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
Jim Lewis
> 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
Weng Tianxiang
wrote:
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
Hi Jonathan,
1. How 'elsif' and 'orif' work together?
See the following example:
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
'if', 'elsif' and 'else' play a role like brackets, putting together a
group of signals that are grouped with 'orif' between them to specify
mutually exclusiveness : there are two groups: (E0, E1, E2), (E3, E4,
E5) and signals in each group are mutually exclusive. Other grammar
meanings remain unchanged: It also means that if one of (E0, E1, E2)
is true, then 'if' statement is finished, otherwise try to test (E3,
E4, E5), like an usual 'if' statement.
The keyword 'orif' only adds the meaning that all signals in the group
are mutually exclusive, no more meaning is added. But it is enough for
compiler to do a smart job with the extra information.
For example, in the above example, two parallel carry chains can be
generated, then another LUT to put them together or more efficient LUT
allocations.
What I want is to transfer to a VHDL compiler the information that
there is mutually exclusive information about them and use them in
best interest of timing.
3. "It is also desirable to be able to specify that *at least*
one of the conditions is true. "
No such requirement is needed based on the fact that any 'if'
statement is complete: it means there is at least one hit, no more
than 2.
For example, the following example :
if(..) then
...
orif(...)
...
orif(...)
...
else
... <--- default hit
end if;
if(..) then
...
orif(...)
...
orif(...)
...
end if;
Above example is logically equivalent to the following one:
if(..) then
...
orif(...)
...
orif(...)
...
else
null; <--- default hit
end if;
It likes the following example with 'elsif'
if(..) then
...
elsif(...)
...
elsif(...)
...
else
null; <--- default hit
end if;
3. I am not fimiliar with Verilog, but from Marcus posting, I know
there is a definitive advantage of my method over Verilog's:
You have never to specify "at-least-one" and "at-most-one" tests. No.
'if' statement structure in sequential process has already null
statement as its default value as following examples show.
A2 : process(RESET, CLK)
begin
if(RESET = '1') then
State_A <= State_0_S;
elsif(CLK'event and CLK = '1') then
case State_A is
when State_0_S =>
if(A = '1') then
State_A <= State_1_S;
else
null;
end if;
...
...
end case;
end if;
end process;
A3 : process(RESET, CLK)
begin
if(RESET = '1') then
State_A <= State_0_S;
elsif(CLK'event and CLK = '1') then
case State_A is
when State_0_S =>
if(A = '1') then
State_A <= State_1_S;
end if;
...
...
end case;
end if;
end process;
Jonathan, I would like to address any concern you will rise.
Thank you.
Weng
Jonathan Bromley
OK, so to try to put this a little more precisely:
'orif' has exactly the same execution semantics as 'elsif',
EXCEPT THAT
any group of branch tests, starting with if or elsif and
continuing through any number of orif with no intervening
elsif, are evaluated together and if more than one of those
tests evaluates to TRUE then it shall be an error.
Note that this mandates the evaluation of ALL tests in the
set before any decision is made, whereas regular VHDL
executes them one by one, only moving on to the next if
the current test is false.
Question: In the following example Tn are Boolean expressions,
and Sn are statement blocks.
if T1 S1
orif T2 S2
orif T3 S3 --- T1, T2, T3 are mutually exclusive
elsif T4 S4
orif T5 S5 --- T4, T5 are mutually exclusive
else S6
If (T1 OR T2 OR T3) is true, do we then also check T4/T5 for
mutual exclusivity? Both answers (yes, no) have potential
disadvantages.
There are some VERY tricky problems with language definition
if any of the Tn tests calls an impure function that may influence
the results of another Tn test - SystemVerilog has already had
trouble with that one.
I still don't understand how you intend to deal with the
practically-common "exactly one" requirement. A final else
doesn't do what I want, because it simply provides an execution
path when all the Tn are false; it does not provide me with a
check that exactly one of the Tn is true.
>What I want is to transfer to a VHDL compiler the information that
>there is mutually exclusive information about them and use them in
>best interest of timing.
As I've already said, this is a worthy objective. Jim Lewis has
suggested it could be done with assertions. I suspect, though,
that a specialized language construct might be a more satisfactory
solution; the use of assertions means that a synthesis tool must
tie together two distinct language constructs, with a wide variety
of possible coding styles and the risk of very wide separation of
the two constructs (conditional and assertion). SystemVerilog
synthesis tools are gaining real practical benefit from the
"unique" and "priority" keywords today, but I know of no
synthesis tool that exploits explicit assertions to
improve its optimization.
>3. I am not fimiliar with Verilog, but from Marcus posting, I know
>there is a definitive advantage of my method over Verilog's:
>You have never to specify "at-least-one" and "at-most-one" tests.
This is not a convincing point. SystemVerilog simply has two
new keywords that can be used as a prefix to 'if' or 'case'.
That is surely no worse than the need to remember a new
'orif' keyword. It's a difference of detail only, and at
present your approach is weaker because it has no way to
specify exactly-one or at-least-one among a set of tests.
(As Marcus and I have both said already, SystemVerilog
has probably got this slightly wrong - but it *does*
offer all the possibilities, which your 'orif' does not).
Keep provoking the community with good ideas - you're doing
a great job - but this one needs more work, I'm afraid.
--
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...@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.
--
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...@MYCOMPANY.com
Andy
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
Weng Tianxiang
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.
2. We have to admit that there are many ways to do it.
3. My example is right and intend to do that. See my answer to
Jonathan Bromley.
4. Keyword 'orif' can be inserted in any places in a 'if' statement to
specify any group of conditions having mutually exclusiveness.
5. 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) <= AD_R0(26 downto 24);
orif(TWindowLoad_E0_H_H and nC_BE_R0(7) = '0') then
TWindow_3(10 downto 8) <= AD_R0(58 downto 56);
end if;
You have to write 5 more statements than mine:
signal A1 : boolean;
signal A2 : boolean;
assert zero_one_hot (A1, A2) ;
A1 <= TWindowLoad_E0_L_H and nC_BE_R0(3) = '0';
A2 <= TWindowLoad_E0_H_H and nC_BE_R0(7) = '0';
if(A1) then
TWindow_3(10 downto 8) <= AD_R0(26 downto 24);
elsif(A2) then
TWindow_3(10 downto 8) <= AD_R0(58 downto 56);
end if;
The more signals are invovled, the more statements are added, and more
likely it is possible to be wrong or missing something.
6. The keyword 'orif' is defined to refer to carry chain structure in
FPGA to get essential timing advantages over other competing methods.
if(E0 = '1') then
OutBus(63 downto 0) <= Data0(63 downto 0);
orif(E1 = '1') then
OutBus(63 downto 0) <= Data1(63 downto 0);
orif(E2 = '1') then
OutBus(63 downto 0) <= Data2(63 downto 0);
end if;
Its implementation equation should look like this:
OutBus = E0*Data0 + E1*Data1 + E2*Data2 + OutBus;
Because 'else' and its null statement are defaulted.
Its carry chain bottom initial input data should be OutBus(i).
if(E0 = '1') then
OutBus(63 downto 0) <= Data0(63 downto 0);
orif(E1 = '1') then
OutBus(63 downto 0) <= Data1(63 downto 0);
orif(E2 = '1') then
OutBus(63 downto 0) <= Data2(63 downto 0);
else
OutBus(63 downto 0) <= Zero_64;
end if;
It is logically defined as the following:
if(E0 = '1' or E1 = '1' or E2 = '1') then
if(E0 = '1') then
OutBus(63 downto 0) <= Data0(63 downto 0);
orif(E1 = '1') then
OutBus(63 downto 0) <= Data1(63 downto 0);
orif(E2 = '1') then
OutBus(63 downto 0) <= Data2(63 downto 0);
end if;
else
OutBus(63 downto 0) <= Zero_64;
end if;
Its implementation equation should look like this:
OutBus = E0*Data0 + E1*Data1 + E2*Data2;
Its carry chain bottom initial input data should be '0'.
How efficient it is to refer to carry chain in FPGA.
Weng
Jim Lewis
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.
> 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.
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
Weng Tianxiang
wrote:
> Weng,
>
> I was almost starting to agree with you, until you said this...
>
> > with new keyword 'orif' Xilinx FPGA compiler will be
> >mandated to map 'orif' structure into a carry chain structure without
> >doubt.
> >...
> >Letting a special VHDL language structure refer to a carry chain
> >implementation in FPGA is a wonderful thing.
>
> 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.
> --
> 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
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
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
Mike Treseler
> 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.
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
Andy
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
Colin Paul Gloster
On 2007-08-28, Jim Lewis <j...@synthworks.com> wrote:
|--------------------------------------------------------------------------|
|"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 <= 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 |
|" |
|--------------------------------------------------------------------------|
Yes,
Weng really did intend to have both orif branches and elsif branches
in a single if statement (see
news:1188325844.1...@z24g2000prh.googlegroups.com
). I think the intention would be clearer with different
indentation. E.g.
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
--...
|--------------------------------------------------------------------------|
|"[..] |
| |
|[..] 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
comp.arch.fpga
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
Weng Tianxiang
wrote:
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. Indent two separate mutually exclusive groups to avoid confusion.
I have never thought about it.
2. "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. "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. '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" =>
...
when "01" =>
...
when "10" =>
...
when others =>
...
end case;
if(two_bits = "00") then
...
orif(two_bits = "01") then
...
orif(two_bits = "10") then
...
else <-- equivalent to "when others =>"
...
end if;
2. Andy mentioned that he may be able to find something that is beyond
the capability of 'orif', but within capability of zero_one_hot().
Andy, you never have a chance to do so with signals.
Reason: you have to implement an assign statement to reflect their
mutually exclusive property, then you must use one of two conditional
branch statements: case statement or if statement that are within
'orif' range.
Mutually exclusiveness is not used for combinational signals.
I don't have any idea if mutually exclusive property applies to
variables.
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.
Weng
Mike Treseler
>> 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?
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
Andy
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 = "00") then
...
elsif(two_bits = "01") then
...
elsif(two_bits = "10") then
...
else <-- equivalent to "when others =>"
...
end if;
As for mutual exclusivity of combinatorial signals or variables, why
do you think mutual exclusivity should be limited to registers only?
Even in your own code examples you have demonstrated mutual
exclusivity of intermediate expressions, which are not registers.
I don't understand your reference to having "to implement an assign
statement to reflect their mutually exclusive property, then you must
use one of two conditional branch statements: case statement or if
statement that are within 'orif' range.
You are completely missing the point about using an assertion: the
assertion is completely independent of the functional code. It merely
provides additional information to a tool that may or may not use it,
but most importantly, it does not restrict you to a specific
functional coding method in order to provide that information.
Your statement: "3. As keyword 'orif' definition says, 'orif' only
provides information about mutually exclusive property among a group
of conditions. " is incorrect: it also provides the functional part,
and cannot be separated from it.
For example, how would you use orif in a loop to do the following (the
loop is necessary because the range of enable is arbitrary):
data <= (others => '0');
if read = '1' then
for i in enable'range loop
if enable(i) = '1' then
data <= input(i);
exit;
end if;
end loop;
assert zero_one_hot(enable);
end if;
The answer is: you couldn't! The use of the assertion, since it is
independent of the functional code, places no limitations on how you
code the functional part.
OTOH, you can choose to combine it with the functional code to easily
represent conditional mutual exclusivity (i.e. only if read = '1'), as
shown above.
OTOOH, if enable was always mutex, it could be indicated once with an
assertion, and any logic that uses it anywhere else could be optimized
because of the additional information.
Andy
Weng Tianxiang
>
> read more »- Hide quoted text -
>
> - Show quoted text -
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 = '1') then
If(E01 = '1') then
State_A <= E01_S;
orif(E02 = '1') then
State_A <= E02_S;
orif(E03 = '1') then
State_A <= E03_S;
elsIf(E04 = '1') then
State_A <= E04_S;
end if;
Orif(E1 = '1') then
State_A <= E1_S;
Orif(E2 = '1') then
State_A <= E2_S;
elsIf(E3 = '1') then
State_A <= E3_S;
Orif(E4 = '1') then
If(E41 = '1') then
State_A <= E41_S;
elsif(E42 = '1') then
State_A <= E42_S;
orif(E43 = '1') then
State_A <= E43_S;
orIf(E44 = '1') then
State_A <= E44_S;
end if;
Orif(E5 = '1') then
State_A <= E5_S;
elsIf(E6 = '1') then
...
else
...
end if;
Mutually exclusive groups: (E0, E1, E2), (E3, E4, E5), (E01, E02,
E03), (E42, E43, E44).
I would like to add a blank line to separate two groups in order not
to make a confusion with viewers of this post. Personnally I don't
think the blank line is needed if you are used to it.
I would like to tell you my experiences: when you are writing mutually
exclusive conditions, you don't know in advance that those group of
conditional signals that are mutually exclusive are written correctly,
and takes a long way to make them correct. You have to fine turn to
make them mutually exclusive finally.
The process is a slow learning one and you cannot write it immediately
without error. When zero_one_hot() method is used, you have two
choices: write them separately in its defnition area and its calling
area from start, or write them like writing a conventional
'if...eslif...end if' statement, then copy them and call them to
become 2 separate code after you are certain that they are right. I
know you have the experiences to write any 'if...eslif...end if'
statements. First of all, I don't believe you would like to write
'if...eslif...end if' statement in 2 separate parts, one for its
definition and assign statements, another is called in
'if...eslif...end if' statement. Then you can imagine same things and
more difficult things happening with the same situations as writing
'if...eslif...end if' statement.
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.
I have to point out the following code has error:
if(E0 = '1') then
OutBus(63 downto 0) <= Data0(63 downto 0);
orif(E1 = '1') then
OutBus(63 downto 0) <= Data1(63 downto 0);
orif(E2 = '1') then
OutBus(63 downto 0) <= Data2(63 downto 0);
end if;
Its implementation equation should look like this:
OutBus = E0*Data0 + E1*Data1 + E2*Data2 + OutBus;
The correct equation should look like this:
OutBus = E0*Data0 + E1*Data1 + E2*Data2 + (not (E0+E1+E2))*OutBus;
Here is Jim's equation that is wrong !
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;
Jim, try this set of values: E0 = '1' and E3 = '1', you get data:
Data0 or Data3, not Data0.
Weng
Colin Paul Gloster
|---------------------------------------------------------------------------------------------|
|"On Aug 29, 3:44 pm, Andy <jonesa...@comcast.net> wrote: |
|> On Aug 29, 11:46 am, Weng Tianxiang <wtx...@gmail.com> wrote: |
|> |
|> |
|> |
|> |
|> |
|> > On Aug 29, 3:13 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org> |
|> > wrote: |
|> |
|[..] |
|> > > On 2007-08-28, Jim Lewis <j...@synthworks.com> 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
WWW.Ashenden.com.Au
, 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 <-- equivalent to "when others =>" |
|> ... |
|> 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 <j...@synthworks.com> 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:1188329351....@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.
comp.arch.fpga
> Weng Tianxiang <wtx...@gmail.com> writes:
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 <= (others => '-');
elsif E1 = '1' then
result <= input1;
elsif E2 = '1' then
result <= input2;
elsif E3 = '1' then
result <= input3;
else
result <= (others => '0');
end if;
You will however notice, that most synthesis tools will not utilize
the optimization potential available from '-'.
I am often annoyed by this. For example if you write an instruction
decoder for a CPU, you do not care about the behaviour of the ALU for
all instructions that use no ALU result. Specifying don't cares would
greatly reduce the amount of logic for the decoder. This is an
improvement that is far more versatile than your proposal and it is
allready in the language.
However most synthesis tools will replace all occurences of '-' with
'0'. The reason behind this is that verification guys hate don't
cares. For regression testing you wan't the hardware to behave the
same if the specification did not change. '-' might be synthesized
differently every time. For formal verification you definitely can't
allow the freedom of don't cares.
In most contexts verification is a far bigger problem then efficient
implementation.
If you really want the most efficient implemetation you should specify
the detailed behaviour.
assert (PSL formulation to guarentee mutual exclusiveness goes here);
result <= (input1 and (result'range => E1) or (input2 and
(result'range => E2) or (input3 and (result'range => 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?
Jim Lewis
> 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"?
> I have to point out the following code has error:
...
> Here is Jim's equation that is wrong !
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:
> 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;
>
> Jim, try this set of values: E0 = '1' and E3 = '1', you get data:
> Data0 or Data3, not Data0.
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 <= (others=>'0');
elsif rising_edge(CLK) then
OutBusB <=
(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 process ;
What compelling real hardware problems does "ORIF" solve
that either are not solved by other methods or are
cumbersome using other methods?
Cheers,
Jim
Jim Lewis
> |---------------------------------------------------------------------------------------------|
> |" 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:
> "[..]
>
> |---------------------------------------------------------------------------------------------|
> |"[..] |
> |> 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.
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
Weng Tianxiang
>
> - Show quoted text -
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.
>From the following code segment provided by Marcus,
Verilog uses new keyword 'unique' to provide on-line programming
capability to specify mutually exclusiveness.
I don't know if Verilog provides the same function zero_one_hot().
As far as 'orif' is concernd, I would like to ask why 'orif' name
conflict problem is so serious?
In my experiences, I have met more consistency problems between two
VHDL versions about unsigned, std_logic_vec, ... and very confused and
I don't know how to listen to which experts's ideas.
For example, for 200x VHDL version, a new keyword 'orif' will be
added, then you must check if your old design has the words, and
if ...
Is it not enough? Or is it troubled enough to make confusion as large
as unsigned, std_logic_vec, ...?
I will re-post my encoding with 'orif' posted two years ago as Jim
asked.
Weng
Weng Tianxiang
>
> - Show quoted text -
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.
2. Jim asked:
Can "ORIF" also construct the equivalent to the following?
OutBusBProc : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
OutBusB <=
(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 process ;
Here is the answer:
A : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if(E0 = '1') then
OutBus <= Data0;
orif(E1 = '1') then
OutBus <= Data1;
orif(E0 = '1') then
OutBus <= Data2;
orif(E0 = '1') then
OutBus <= Data3;
orif(E0 = '1') then
OutBus <= Data4;
orif(E0 = '1') then
OutBus <= Data5;
else
OutBus <= Zero_64;
end if;
end if;
end process;
"ORIF' can not only do the above as an beginner would like to do, but
also do the following equations you showed before more efficiently:
-- assert zero_one_hot (E0, E1, E2) ; -- Jim wrote
-- assert zero_one_hot (E3, E4, E5) ;
assert zero_one_hot (E0, E1, E2, E3, E4, E5) ; -- Weng adds this line
to make code correct
-- It is Jim's coding
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;
I don't know which VHDL version permits the operation: (E0 and Data0),
even though It is not a problem here
-- It is my coding
A : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) 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;
else
OutBus <= OutBus;
end if;
end if;
end process;
The above equation would be implemented in Xilinx chip with carry
chain with initial input data to the carry chain being OutBus. The
following enable equation would be eliminated from Jim's coding:
(E0 or E1 or E2 or E3 or E4 or E5) = '1'
It is not a LUT or two saving as some suggesed. For a up to 400MHz
project, every extra logic would kill a design. Because it takes more
route resources. When route resources exhausted, the running frequency
would drop dramatically and would kill a otherwise successfu design.
LUT is less than a cent in a FPGA.
The above two example show that with mixed 'elsif' and 'orif' language
branch statement structure, HDL will provide more powerful and concise
way to deal with mutually exclusiveness, especially for VHDL
beginners. VHDL beginner would need to go a long way to write the code
type Jim had written.
Weng
Jim Lewis
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
Mike Treseler
> 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 <= (others => '-');
> elsif E1 = '1' then
> result <= input1;
> elsif E2 = '1' then
> result <= input2;
> elsif E3 = '1' then
> result <= input3;
> else
> result <= (others => '0');
> end if;
This clarifies these long discussions for me.
> In most contexts verification is a far bigger problem then efficient
> implementation.
I couldn't agree more.
> If you really want the most efficient implemetation you should specify
> the detailed behaviour.
> assert (PSL formulation to guarentee mutual exclusiveness goes here);
> result <= (input1 and (result'range => E1) or (input2 and
> (result'range => E2) or (input3 and (result'range => E3);
I agree.
I should describe what I care about,
not what I don't care about.
This simplicity eliminates confusion.
> 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.
Yes.
I like to keep the logic description separate
from the device and tool options.
-- Mike Treseler
Andy
>
> read more »
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
Jim Lewis
This is correct for your "State_A" example:
> -- assert onehot0 (E0, E1, E2) ; -- Jim wrote
> -- assert onehot0 (E3, E4, E5) ;
This is correct for your "OutBus" example.
> assert onehot0 (E0, E1, E2, E3, E4, E5) ; -- Weng adds this line
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.
> The above two example show that with mixed 'elsif' and 'orif' language
> branch statement structure, HDL will provide more powerful and concise
> way to deal with mutually exclusiveness.
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.
> VHDL beginner would need to go a long way to write the code
> type Jim had written.
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
Jim Lewis
> result <=
> (input1 and (result'range => E1)) or
> (input2 and (result'range => E2)) or
> (input3 and (result'range => E3)) ;
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 <= (input1 and E1) or (input2 and E2) or (input3 and E3);
Cheers,
Jim
Andy
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 <= (others => '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 <= temp;
end if;
end if;
end process;
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 <= (others => '0');
elsif rising_edge(clk) then
for i in e'range loop
if e(i) = '1' then
outbus <= data(i);
exit;
end if;
end loop;
assert zero_one_hot(e);
end if;
end process;
However, a loop of if/then statements is not compatible with your
proposed orif keyword.
Therefore, we have a more powerful and concise example of coding this
function with zero_one_hot() than is possible with a new keyword
'orif'.
So, zero_one_hot() can do everything 'orif' can do and more, while
doing so more concisely, and not requiring a language syntax change.
Why do we need 'orif'?
Andy
Weng Tianxiang
Hi Andy,
I would like to answer your this question.
process (reset, clk) is
begin
if reset = '1' then
outbus <= (others => '0');
elsif rising_edge(clk) then
for i in e'range loop
if e(i) = '1' then
outbus <= data(i);
exit;
end if;
end loop;
assert zero_one_hot(e);
end if;
end process;
Good example !
you have claimed in other place the following:
1. define e;
2. Assign e's every bit a combinational value;
You have missed the most important things: what conditions they are !
Here is an example from my coding that shows orif usage: in-line
programming capability
if(TWindowLoad_E0_L_H and nC_BE_R0(3) = '0') then
TWindow_3(10 downto 8) <= AD_R0(26 downto 24);
orif(TWindowLoad_E0_H_H and nC_BE_R0(7) = '0') then
TWindow_3(10 downto 8) <= AD_R0(58 downto 56);
end if;
Please ask Verilog group why they introduce 'unique' keyword to
provide in-line programming tool to specify the mutually exclusiveness
if I don't misunderstand as following example shown by Marcus:
Weng
Weng Tianxiang
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
Colin Paul Gloster
In news:13ddnbc...@corp.supernews.com timestamped Thu, 30 Aug
2007 08:08:26 -0700, Jim Lewis <j...@synthworks.com> 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
Torsten Landschoff
Hi Weng,
On 31 Aug., 05:32, Weng Tianxiang <wtx...@gmail.com> wrote:
> 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'.
Render me confused. If I assert a condition in VHDL, I would expect
the synthesizer to use that information to optimize the circuit (at
least if it has severity error, which is the default). When such an
assertion is declared, it can be assumed that the following code
relies on it anyway. Adding one more instance of "undefined behaviour"
should not matter.
However, I wonder if current synthesizers do some kind of validation
if the assertion can be violated ;-)
Greetings, Torsten
Andy
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
Andy
Weng,
Your logic is completely, fatally flawed.
For example, an integer declaration like:
signal myint: integer range 0 to 255;
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.
Andy
Jim Lewis
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 ;
Metacomments:
-- pragma synthesis_off
-- pragma synthesis_on
Assertions are nothing more than a simple extension.
I thought I heard that Synplicity is already
synthesizing some assertions of their own.
Jim
Weng Tianxiang
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:
1. 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.
2. 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.
3. 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.
4. 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.
Weng
Andy
> 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.
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.
>
> Now the problems are:
> 1. 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.
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.
>
> 2. 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.
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.
>
> 3. 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.
I can tell.
>
> In my opinion, your mutually exclusive situations should be expected
> to have the same ratio.
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.
>
> 4. 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.
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.
Andy
Weng Tianxiang
Andy,
1. Thank you for your response. I learn something very important from
you through this topics discussion.
2. 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.
3. 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.
Thank you.
Weng
Weng Tianxiang
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 <= (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;
I don't know which VHDL version permits the operation: (E0 and
Data0),
even though It is not a problem here
-- It is my coding
A : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) 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;
else
OutBus <= OutBus;
end if;
end if;
end process;
The above equation would be implemented in Xilinx chip with carry
chain with initial input data to the carry chain being OutBus. The
following enable equation would be eliminated from Jim's coding:
(E0 or E1 or E2 or E3 or E4 or E5) = '1'
It is not a LUT or two saving as some suggesed. For a up to 400MHz
project, every extra logic would kill a design. Because it takes more
route resources. When route resources exhausted, the running
frequency
would drop dramatically and would kill a otherwise successfu design.
LUT is less than a cent in a FPGA.
The above two example show that with mixed 'elsif' and 'orif'
language
branch statement structure, HDL will provide more powerful and
concise
way to deal with mutually ...
You are a doubtor of the technology, Verilog has formally introduced
the technology, and VHDL will follow.
It is a trend.
I prefer writing 'if...end if' statements than your and Jim's coding.
Why? It is really not a VHDL language, but an ASM language and there
are many pains.
I am fighting for an alternative, concise and simple method to do the
same job as Jim has suggested.
Thank you.
Weng
Jim Lewis
> I am fighting for an alternative, concise and simple method to do the
> same job as Jim has suggested.
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.
Bye,
Jim
Weng Tianxiang
Jim,
1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. '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.
7. The only advantages of 'orif' are
a. in-line programming capability;
b. mixing 'elsif' and 'orif' language structure.
No more.
8. 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.
9. 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.
Thank you.
Weng
comp.arch.fpga
> Hi Kolja,
> My opinion is when VHDL compilers get more information about mutually
> exclusive information, what you can do, the VHDL compilers can do
> better.
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.
> The above equation would be implemented in Xilinx chip with carry
> chain with initial input data to the carry chain being OutBus.
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.
> The
> following enable equation would be eliminated from Jim's coding:
> (E0 or E1 or E2 or E3 or E4 or E5) = '1'
Yes. The formulation is redundant, even without knowledge of the input
don't cares.
> The above two example show that with mixed 'elsif' and 'orif'
> language branch statement structure, HDL will provide more powerful and
> concise way to deal with mutually ...
But nothing else but that. That is not enough.
> You are a doubtor of the technology,
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;
KJ
"Michael Jørgensen" <in...@ukendt.dk> wrote in message
news:46d8498b$0$903$edfa...@dread12.news.tele.dk...
>
> "Andy" <jone...@comcast.net> wrote in message
> news:1188427440.2...@r34g2000hsd.googlegroups.com...
>
> <BEGIN QUOTE>
> 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 <-- equivalent to "when others =>"
> ...
> end if;
> <END QUOTE>
>
>
> I think perhaps the above example is a bit too simple. In my designs I
> have an external CPU accessing various tables inside the FPGA. The address
> decoding leads to a number of mutually exclusive conditions, but the
> synthesis tool does not recognize them as such.
>
> The following example shows what I mean (see code at end of post).
> Basically, it is just 4-input 4-output LUT, but when synthesizing I end up
> with a long chain of MUX'es.
When I synthesized it with Quartus I got 4 LUTs for the total usage, one to
compute each of the four bits of D_OUT. The input to each of the four LUTs
are the four address inputs Addr_IN(3:0). The intermediate signal
'reg_hit(3:0)' was optomized out, the logic path for all four outputs
consisted of a single LUT delay. There was no cascading of LUTs or
anything. Bottom line is that the synthesized result is exactly what I
would have expected.
Since you synthesized it and ended up with "a long chain of MUX'es" perhaps
you should take Andy's suggestion regarding such a synthesis tool which is
that it "should be immediately uninstalled and returned to the vendor for a
full refund!".
>
> I would like the output signal in the code below to be synthesized as a
> single 8-to-1 multiplexer (i.e. in parallel), and not as seven 2-to-1
> multiplexers chained together in series.
I'm not sure how the 8->1 mux fits into the example you posted, but perhaps
you should ponder a bit on how to implement an 8->1 mux given logic
primitives that take 4 to 6 inputs only (i.e. various FPGAs). CPLDs have
much wider inputs to the logic array, but FPGAs with their LUTs don't so
maybe what you're seeing when you talk about long chains of muxes is simply
because the FPGA LUT with it's 4-6 inputs simply cannot implement an 8->1
mux in a single level of logic. Again though, the 8->1 mux you're speaking
of must be something other than for the code you posted.
>
> Others have suggested using enumerated types, but I can't see how that
> helps. This will just lead to a chain of if-statements in the address
> decoding, instead of in the output multiplexing.
Enumerated types wouldn't help in the synthesis in this particular example,
but what it can help with is readability. D_OUT(0), D_OUT(1), etc. is
probably less descriptive then D_OUT(Ram), D_OUT(Flash), etc. The mutual
exclusivity of the bits of the signal 'reg_hit' in your example was
correctly handled as it should be by Quartus.
>
> So either I'm missing something fundamental in VHDL (quite likely, since
> I'm still new in this field), or the language has a limitation that is
> causing problems for me.
>
I don't think it's a language limitation that is causing whatever problems
you're seeing. Given the synthesis results that you got (the long chain of
mux) suggests that the problems are caused by your synthesis tool.
KJ
Weng Tianxiang
Hi Kolja,
> The
> following enable equation would be eliminated from Jim's coding:
> (E0 or E1 or E2 or E3 or E4 or E5) = '1'
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 <= (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;
I write his type of coding everywhere in my design. It is really not a
high level language, but a ASM language writing at flip-flop levels in
name of high level language.
But if 'orif' is a new keyword, the situation may change, at least
from paper and theory. There is no FPGA VHDL compiler today that can
generate better code than Jim's coding.
That is the reason:
What you can do, VHDL compiler can do it better if it gets all
information about mutual exclusiveness.
As far as "don't care" situation is concerned, VHDL compile ignores it
at all. It is not a VHDL problem, it is a compiler problem. You must
distinguish VHDL language problem from compiler capability problem.
Thank you.
Weng
comp.arch.fpga
> As far as "don't care" situation is concerned, VHDL compile ignores
it
> at all. It is not a VHDL problem, it is a compiler problem. You must
> distinguish VHDL language problem from compiler capability problem.
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.
Kolja Sulimma
Weng Tianxiang
Hi Kolja,
"at all. It is not a VHDL problem, it is a compiler problem. You must
distinguish VHDL language problem from compiler capability problem. "
In above sentence, what I had refered to is the case of 'dont' care'
you mentioned in your example, not the 'orif' case.
Verilog introduction of 'unique' and other related functions has
showed that mutually exclusiveness in HDL needed to be added and
improved.
Weng
Weng Tianxiang
wrote:
> Jim,
>
> On 2007-08-28, Jim Lewis <j...@synthworks.com> wrote:
>
> |--------------------------------------------------------------------------|
> |"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 <= 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 |
> |" |
> |--------------------------------------------------------------------------|
>
> Yes,
>
> Weng really did intend to have both orif branches and elsif branches
> in a single if statement (seenews:1188325844.1...@z24g2000prh.googlegroups.com
> ). I think the intention would be clearer with different
> indentation. E.g.
> 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
> --...
>
> |--------------------------------------------------------------------------|
> |"[..] |
> | |
> |[..] 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?
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
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? 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. Read vhd file;
2. Read their last update date and get year number;
3. When year number <= 2006, orif is cleared in reserved word list;
When year number >= 2007, oris is in reserved word list.
4. 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.
Any comments?
Thank you.
Weng
Weng Tianxiang
Here is a more flexible method that can avoid orif name conflicting
problem at any situations.
For 2006 compiler do the following things:
1. 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;
2. Read vhd file;
3. Read its last update date;
4. 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.
Thank you.
Weng
Michael Jørgensen
"KJ" <kkjen...@sbcglobal.net> wrote in message
news:cdhCi.4628$JD....@newssvr21.news.prodigy.net...
[snip]
> I don't think it's a language limitation that is causing whatever problems
> you're seeing. Given the synthesis results that you got (the long chain
> of mux) suggests that the problems are caused by your synthesis tool.
>
> KJ
Thanks for your comments.
I entered this thread because I thought I recognized a problem I was having
myself, i.e. that the synthesis tool (I'm using Quartus) did not properly
utilize mutually explusiveness. Well, I was mistaken. Let me explain.
The small example in my previous post was created to describe my problem.
However, I was making the mistake of looking in the RTL viewer. Using my
example, there is indeed a chain of MUX's clearly seen in the RTL view.
However, I then checked the equation file, and that consists essentially of
four parallel ALUTs, just as you described.
That surprised me: I thought the RTL viewer was essentially a graphical
representation of the equation file, but that is clearly not the case. It
only represents something that is logically equivalent. I'm glad to have
found that out.
I tried a more complicated example where the output was to be multiplexed
from four different RAMS. Again, the selection was done in a single ALUT for
each output bit.
So it seems that Quartus is actually doing a very good job at optimizing the
design, contrary to my initial claim.
My conclusion is therefore that the problem I aluded too is non-existent.
Going back to the OP, this leads me to ask, what is actually the problem
that Weng is trying to solve?
-Michael.
Colin Paul Gloster
|-----------------------------------------------------------------------------------------|
|"On Aug 29, 3:13 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org> |
|wrote: |
|> Jim, |
|> |
|> On 2007-08-28, Jim Lewis <j...@synthworks.com> 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:13ddnbc...@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.C...@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.
Regards,
Colin Paul Gloster
Jonathan Bromley
>Going back to the OP, this leads me to ask, what is actually the problem
>that Weng is trying to solve?
The issue is well-known, and has numerous prior-art solutions
(I'll come back to them): There are many, many designs in which
the designer has private knowledge of the set of values that may
legally appear on a group of signals. If the designer cannot
express that knowledge to the synthesis tool, he will get
inferior logic optimization. If the designer cannot express
that knowledge to the simulator, he runs the risk of failing
to detect certain errors that put illegal values on to the
signals.
Here's a very simple example, for which no new solution is
needed. Suppose I wish to make an electronic die that
displays (using seven LEDs) the usual pattern of one to
six spots. My display has four "segments" made from
seven lamps:
A B
C D C 1->D, 2->A, 3->AD, 4->AB, 5->ABD, 6->ABC
B A
Now I run a binary counter over the values 1,2,3,4,5,6
to generate the values. I need a decoder:
signal count: unsigned(2 downto 0);
signal lamps: std_logic_vector(0 to 3); --- 0=A,1=B, 2=C, 3=D
...
case count is -----lamps ABCD
when "001" => lamps <= "0001";
when ....
when "110" => lamps <= "1110";
when others=> lamps <= "----";
end case;
This is a simple and effective style that allows the synth tool
full scope for optimization, and in simulation makes it very clear
to you if you mistakenly put a bad value on "count". You could
even add a simulation-only error diagnostic (assertion) in the
"others" branch. I have been able to write code that captures
my hidden design knowledge both for simulation and for synthesis.
If, in the real hardware, the count should go to 0 or 7 then I
will get some goofy pattern on the LEDs; but I don't care,
because my simulations convinced me that this will never happen.
In more complicated situations, and particularly in situations
where different signals need to be tested to choose different
branches of a conditional, it can be very difficult indeed to
capture this kind of design knowledge in the code.
Assertions provide a clear and appropriate way to expose
such design-specific knowledge to a simulator ("I promise
that signals P and Q will never be true together; I promise
that if signal P is true then exactly one of signals
R and S will also be true") but no synthesis tool that
I'm aware of can make use of this kind of information to
improve its optimizations.
Synthesis pragmas or directives, notably the full_case
and parallel_case pragmas supported by all serious Verilog
synthesis tools, provide a convenient way to flag to a
synthesis tool that certain conditions will always hold
(full_case specifies that at least one branch of a
conditional will be taken and therefore the tool does
not need to consider any other possibilities; parallel_case
specifies that no more than one branch of a conditional
will be taken, so the tool can assume mutual exclusivity).
Unfortunately, simulators completely ignore such directives
and therefore we not only risk missing important error
conditions, but also we may get mismatches between simulation
and synthesis behaviour. Most VHDL designers would rightly
choke on their coffee at such a thought.
Consequently, many people have sought some way to express
such kinds of design intent within the language itself.
Assertions are the obvious candidate, but are probably
too open-ended to be tractable for synthesis: for example,
an assertion in one part of a design might enforce
mutual exclusivity on a conditional in quite another
part of the design and it is unreasonable to expect
synthesis tools to be able to handle that sort of thing.
SystemVerilog has taken the approach of adding some new
language keywords ("unique" and "priority") that can
be used to modify the conditional statements "case"
and "if"; simulators recognise these keywords as a
special assertion, and synthesis tools recognise them
as licence to perform certain optimizations. Everyone
is happy. We get better logic, and no sim/synth mismatch.
There is absolutely no point in trying to apply anything
like full_case and parallel_case to VHDL case statements,
since they are inherently full and parallel by the language
definition. However, there *may* be some mileage in
chasing that goal for the "if" statement. That's what
Weng's "orif" keyword aims to do. I, and many others,
think it's an idea that has merit but is too flawed and
limited to be worthy of inclusion in the language.
It is *always* possible to get the desired behaviour
by writing sufficiently contorted VHDL. There is,
however, much to be said for providing a language-based
mechanism to solve these important and common problems.
Some posters to this thread have argued that enumeration
types do all they need; I totally disagree, because
enumerations specify mutual exclusivity only in cases
where the mutual exclusivity can trivially be shown
to hold statically.
The practical reality, today, is that all the common
examples of this problem (notably, many variations on
the one-hot-coded theme) have perfectly viable solutions
in standard VHDL. Consequently, language support is not
high on the list of priorities for the people that matter.
I lack the will and the stamina to try to change that
situation, so I'll now shut up even though I think I
may have some better ideas :-)
--
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...@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.
Weng Tianxiang
wrote:> |-----------------------------------------------------------------------------------------|
> |"On Aug 29, 3:13 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org> |
> |wrote: |
> |> Jim, |
> |> |
> |> On 2007-08-28, Jim Lewis <j...@synthworks.com> 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,
>
> 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
> 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.
>
> Regards,
> Colin Paul Gloster
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.
Thank you.
Weng
Weng Tianxiang
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?
Thank you.
Weng
KJ
"Jonathan Bromley" <jonathan...@MYCOMPANY.com> wrote in message
news:4sund3tnppl93cbt1...@4ax.com...
>
>>Going back to the OP, this leads me to ask, what is actually the problem
>>that Weng is trying to solve?
>
> The issue is well-known, and has numerous prior-art solutions
> (I'll come back to them): There are many, many designs in which
> the designer has private knowledge of the set of values that may
> legally appear on a group of signals. If the designer cannot
> express that knowledge to the synthesis tool, he will get
> inferior logic optimization. If the designer cannot express
> that knowledge to the simulator, he runs the risk of failing
> to detect certain errors that put illegal values on to the
> signals.
>
> Here's a very simple example, for which no new solution is
> needed.
<snip>
You did kind of the bait and switch on this one without really addressing
the question posed....what is the problem that Weng is trying to solve?
> In more complicated situations, and particularly in situations
> where different signals need to be tested to choose different
> branches of a conditional, it can be very difficult indeed to
> capture this kind of design knowledge in the code.
>
Ummm.....like what? Certainly not Weng's outbus example. That one is best
coded by writing it in a sum of products form, but Weng dismisses that as
being the equivalent of assembler whereas the 'orif' is a high level
construct which is completely wrong. Other cases that have been brought up
can be handled by properly reformulating the problem using enumerated types.
From what I can tell, the only problem that 'orif' solves is how to
structure something into an 'if' statement instead of using other clearly
understandable statements that are already part of the language. Much like
the person who owns a hammer sees every problem as a nail, Weng sees the
'if' statement as his hammer but finds it somewhat deficient in that he
needs a modified one (one with an 'orif') to tackle a problem that has no
nail.
> Assertions provide a clear and appropriate way to expose
> such design-specific knowledge to a simulator ("I promise
> that signals P and Q will never be true together; I promise
> that if signal P is true then exactly one of signals
> R and S will also be true") but no synthesis tool that
> I'm aware of can make use of this kind of information to
> improve its optimizations.
If you already have the complete logic description (which is encoded in all
of the 'non-assert' statements) the synthesis tool will not really have much
use for these unverifiable asserts that purport to give this supposedly
'higher level' information. Just what should happen if the logic
description says one thing but the assertion claim another...and the
supposedly impossible thing happens (i.e. the 'assert' fires)? The
synthesis tool generated logic will have no way to flag this and, I'm
guessing, is free to implement this case however it wants to independent of
the logic description....I think I'll pass on such a tool, the supposedly
'impossible' happens, 'specially as code gets reused in new applications.
<snip>
>
> It is *always* possible to get the desired behaviour
> by writing sufficiently contorted VHDL.
Many times with uncontorted code as well....like the sum of products
solution to the outbus example.
> There is,
> however, much to be said for providing a language-based
> mechanism to solve these important and common problems.
> Some posters to this thread have argued that enumeration
> types do all they need; I totally disagree, because
> enumerations specify mutual exclusivity only in cases
> where the mutual exclusivity can trivially be shown
> to hold statically.
So we agree that the enumeration type solves the one class of mutual
exclusiveness. But I'm still waiting for the example of this 'common'
problem for which 'orif' is the solution.
KJ
Weng Tianxiang
1. 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.
2. 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 <= (others => '0');
elsif rising_edge(clk) then
for i in e'range loop
if e(i) = '1' then
outbus <= data(i);
exit;
end if;
end loop;
assert zero_one_hot(e); <-- useless and just waisting time !!!
end if;
end process;
With your above coding, it seems to me that you don't have a deep
insight why VHDL needs a mechanism to transfer mutually exclusive
information to VHDL compiler, neither does Jim.
With your coding, it doesn't need to provide the information the
assertion provides. It is a well known popular practise before
introducing mutually exclusiveness.
VHDL COMPILERS NEED MUTUALLY EXCLUSIVE INFORMATION IN ORDER TO KEEP
'IF...END IF' STATEMENT STRUCTURE UNIQUITOUS AND MAKE IT POSSIBLE
WRITING HARDWARE IS JUST LIKE WRITING SOFTWARE C (all if statement
when writing software).
We provide EXTRA mutually exclusive information to VHDL compiler and
let the compiler do better job with the "if...end if" statement
structure than what you and we have traditionally done. Because
"if...end if" statements are the simplest and unified way to express
logic ideas. Any advantages current hardware writing style (shown as
in your code) would dissapear and become unnecessary if mutually
exclusive information is given.
Why the above statement is waistful? You have already written the code
with the knowledge how it behaves and adding the assertion statement
just let simulator waisting time to do what you and I never do it
before. No assertion statement in your code works well and nobody adds
the assertion statements to confirm it now.
3. 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 better than any human.
-- It is Jim's coding
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;
-- It is my coding
A : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) 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;
else
OutBus <= OutBus;
end if;
end if;
end process;
The above equation would be implemented in Xilinx chip with carry
chain with initial input data to the carry chain being OutBus. The
following enable equation would be eliminated from Jim's coding:
(E0 or E1 or E2 or E3 or E4 or E5) = '1'
It is not a LUT or two saving as some suggesed. For a up to 400MHz
project, every extra logic would kill a design. Because it takes more
route resources. When route resources exhausted, the running
frequency would drop dramatically and would kill a otherwise successfu
design.
LUT is less than a cent in a FPGA.
4. If you keep writing your coding style, you never need assertion
functions. If you write assertion function to declare a group of
signals are mutually exclusive, you must stick with the 'if' statement
structure to get its function working. Otherwise writing assertion,
like your code does, is just waisting time.
5. orif or other similar spelling OIF, _ORIF, is not replacable with
assertion function.
6, My another keyword method: Exclusive(or other name, no problem).
Here is an example how Exclusive is used:
signal A : unsigned(5 downto 0) ; -- to store mutually exclusive data
Exclusive : (A); -- it indicates that signal A of its bits is mutually
exclusive.
Exclusive : (StateRead, StateWrite); -- indicate two state machines
are mutually exclusive with their intial states being common. This
function extends mutually exclusive funtion to more than 2 state
machines.
If you need, I can send my paper to you: "HDL Code Inefficiency
Sources and Its Solutions".
Jim,
I am going to publish 6 articles in a batch within next 6 months in
one of three forms: websites, patent applications or international
conferences. One of them has a very good example how 'orif' is used, a
brand new usage. No special report to you is under consideration until
you are pursuaded in advance. You may have to wait for next 6 months
to get the files.
Weng
Jonathan Bromley
>> Here's a very simple example, for which no new solution is
>> needed.
><snip>
>You did kind of the bait and switch on this one without really addressing
>the question posed....what is the problem that Weng is trying to solve?
I thought/hoped that I had been fairly clear about that:
A situation in which knowledge of the dynamic, runtime
behaviour of a design is required in order to optimize
it effectively in hardware. The classic example (which,
it must be said, can easily be handled in other ways) is
the conversion of a one-hot coded bus to a binary
representation. Problems such as CPU instruction decoders
often lead to other, less straightforward examples.
>> it can be very difficult indeed to
>> capture this kind of design knowledge in the code.
>Ummm.....like what? Certainly not Weng's outbus example. That one is best
>coded by writing it in a sum of products form, but Weng dismisses that as
>being the equivalent of assembler whereas the 'orif' is a high level
>construct which is completely wrong. Other cases that have been brought up
>can be handled by properly reformulating the problem using enumerated types.
I agree. It is often rather hard to capture the problem in the
form of an easily digestible example. Consequently,
advocates for such things commonly fall back on simple
examples; this stratagem is fatally flawed, because folk
like you can easily see how the simple problem can be
solved in a more elegant way.
>From what I can tell, the only problem that 'orif' solves is how to
>structure something into an 'if' statement instead of using other clearly
>understandable statements that are already part of the language. Much like
>the person who owns a hammer sees every problem as a nail, Weng sees the
>'if' statement as his hammer but finds it somewhat deficient in that he
>needs a modified one (one with an 'orif') to tackle a problem that has no
>nail.
I have already pointed out that I regard Weng's "orif" formulation
as both flawed and inadequate. That doesn't mean that the problem
he's trying to tackle is irrelevant.
>> Assertions provide a clear and appropriate way to expose
>> such design-specific knowledge to a simulator ("I promise
>> that signals P and Q will never be true together; I promise
>> that if signal P is true then exactly one of signals
>> R and S will also be true") but no synthesis tool that
>> I'm aware of can make use of this kind of information to
>> improve its optimizations.
>
>If you already have the complete logic description (which is encoded in all
>of the 'non-assert' statements) the synthesis tool will not really have much
>use for these unverifiable asserts that purport to give this supposedly
>'higher level' information.
Sorry, this is nonsense. Synthesis tools generally cannot see
outside the boundary of the module they're currently compiling.
Suppose you have two quite independent modules, communicating
over a flat 32-bit data bus. Suppose, what's more, that there
is a "fetch" signal emitted by one module and received by the
other; and when this "fetch" signal is asserted, the source
module reliably produces an instruction code that is one-hot
coded. How can the destination (receiving) module's VHDL
code possibly capture that knowledge? - knowledge that is
very valuable for optimising the instruction decode logic.
In any case, the idea of an "unverifiable" assertion is surely
absurd. The whole point of assertions is that they continually
monitor the data whose properties they check; long after the
assertion's author has forgotten why he put it there, the
assertion continues to contribute to the verification effort.
> Just what should happen if the logic
>description says one thing but the assertion claim another...and the
>supposedly impossible thing happens (i.e. the 'assert' fires)?
Then your verification effort correctly shows that you have made
unjustified assumptions that you must review. That's the whole
point: by capturing *in a single language construct* both an
assumption that you're making about runtime behaviour, and a
permission to the synthesis tool to share that assumption,
you have a safe way to capture knowledge of a system's
expected behaviour that cannot be described any other way.
>> It is *always* possible to get the desired behaviour
>> by writing sufficiently contorted VHDL.
>
>Many times with uncontorted code as well....like the sum of products
>solution to the outbus example.
Indeed so. Often there is a simple solution that
merely needs to be revealed and added to the folklore.
>So we agree that the enumeration type solves the one class of mutual
>exclusiveness. But I'm still waiting for the example of this 'common'
>problem for which 'orif' is the solution.
OK, I promise I'll try to find some more compelling examples.
KJ
"Weng Tianxiang" <wtx...@gmail.com> wrote in message
news:1188844272.4...@k79g2000hse.googlegroups.com...
<snip>
> 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.
Wow....now you're suggesting color coding as a method to handle your
ambiguities?
<snip>
> process (reset, clk) is
> begin
> if reset = '1' then
> outbus <= (others => '0');
> elsif rising_edge(clk) then
> for i in e'range loop
> if e(i) = '1' then
> outbus <= data(i);
> exit;
> end if;
> end loop;
> assert zero_one_hot(e); <-- useless and just waisting time !!!
> end if;
> end process;
>
>
> With your above coding, it seems to me that you don't have a deep
> insight why VHDL needs a mechanism to transfer mutually exclusive
> information to VHDL compiler, neither does Jim.
You haven't demonstrated your insight either...but that's my opinion.
>
> With your coding, it doesn't need to provide the information the
> assertion provides. It is a well known popular practise before
> introducing mutually exclusiveness.
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.
>
> VHDL COMPILERS NEED MUTUALLY EXCLUSIVE INFORMATION IN ORDER TO KEEP
> 'IF...END IF' STATEMENT STRUCTURE UNIQUITOUS AND MAKE IT POSSIBLE
> WRITING HARDWARE IS JUST LIKE WRITING SOFTWARE C (all if statement
> when writing software).
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.
>
> We provide EXTRA mutually exclusive information to VHDL compiler and
> let the compiler do better job with the "if...end if" statement
> structure than what you and we have traditionally done. Because
> "if...end if" statements are the simplest and unified way to express
> logic ideas. Any advantages current hardware writing style (shown as
> in your code) would dissapear and become unnecessary if mutually
> exclusive information is given.
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.
>
> Why the above statement is waistful? You have already written the code
> with the knowledge how it behaves and adding the assertion statement
> just let simulator waisting time to do what you and I never do it
> before. No assertion statement in your code works well and nobody adds
> the assertion statements to confirm it now.
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.
>
> 3. My opinion is when VHDL compilers get more information about
> mutually
> exclusive information, what you can do, the VHDL compilers can do
> better.
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.
>
> 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 better than any human.
>
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.
>
> It is not a LUT or two saving as some suggesed. For a up to 400MHz
> project, every extra logic would kill a design. Because it takes more
> route resources. When route resources exhausted, the running
> frequency would drop dramatically and would kill a otherwise successfu
> design.
> LUT is less than a cent in a FPGA.
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.
>
> 5. orif or other similar spelling OIF, _ORIF, is not replacable with
> assertion function.
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.
>
> 6, My another keyword method: Exclusive(or other name, no problem).
>
> Here is an example how Exclusive is used:
>
> signal A : unsigned(5 downto 0) ; -- to store mutually exclusive data
>
> Exclusive : (A); -- it indicates that signal A of its bits is mutually
> exclusive.
What guarantees the exclusiveness? The engineer's code of honor? If it is
reeeeeally mutually exclusive it could be described by an enumerated type.
>
> Exclusive : (StateRead, StateWrite); -- indicate two state machines
> are mutually exclusive with their intial states being common. This
> function extends mutually exclusive funtion to more than 2 state
> machines.
Kind of looks like an enumerated type definition too....hmmm
>
> If you need, I can send my paper to you: "HDL Code Inefficiency
> Sources and Its Solutions".
>
> Jim,
>
> I am going to publish 6 articles in a batch within next 6 months in
> one of three forms: websites, patent applications or international
> conferences. One of them has a very good example how 'orif' is used, a
> brand new usage. No special report to you is under consideration until
> you are pursuaded in advance. You may have to wait for next 6 months
> to get the files.
>
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;
architecture rtl of test is
begin
-- Andy's code
-- 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 <= data(i);
-- exit;
-- end if;
-- end loop;
-- -- assert zero_one_hot(e); -- useless and just waisting time !!!
-- end if;
-- end process;
-- It is Jim's coding
OutBusA : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= '0';
elsif rising_edge(CLK) then
if (E(0) or E(1) or E(2) or E(3) or E(4) or E(5)) = '1' then
OutBus <=
(E(0) and Data(0)) or (E(1) and Data(1)) or (E(2) and Data(2)) or
(E(3) and Data(3)) or (E(4) and Data(4)) or (E(5) and Data(5)) ;
end if ;
end if ;
end process;
end architecture rtl;
--------- END CODE USED TO IMPLEMENT ANDY AND JIM'S VERSION ----------
KJ
"Jonathan Bromley" <jonathan...@MYCOMPANY.com> wrote in message
> On Mon, 3 Sep 2007 13:37:29 -0400, "KJ" wrote:
>
>>> Here's a very simple example, for which no new solution is
>>> needed.
>><snip>
>>You did kind of the bait and switch on this one without really addressing
>>the question posed....what is the problem that Weng is trying to solve?
<snip>
> I agree. It is often rather hard to capture the problem in the
> form of an easily digestible example. Consequently,
> advocates for such things commonly fall back on simple
> examples; this stratagem is fatally flawed, because folk
> like you can easily see how the simple problem can be
> solved in a more elegant way.
And we end up in the situation where one person is claiming superiority of a
new solution to an unstated problem or making unfounded claims. This thread
has droned on for a bit and Michael asked a very straightforward question
about just what problem is being solved in the OP?
>
>>From what I can tell, the only problem that 'orif' solves is how to
>>structure something into an 'if' statement instead of using other clearly
>>understandable statements that are already part of the language. Much
>>like
>>the person who owns a hammer sees every problem as a nail, Weng sees the
>>'if' statement as his hammer but finds it somewhat deficient in that he
>>needs a modified one (one with an 'orif') to tackle a problem that has no
>>nail.
>
> I have already pointed out that I regard Weng's "orif" formulation
> as both flawed and inadequate. That doesn't mean that the problem
> he's trying to tackle is irrelevant.
>
Or that it hasn't been tackled already.
>>> Assertions provide a clear and appropriate way to expose
>>> such design-specific knowledge to a simulator ("I promise
>>> that signals P and Q will never be true together; I promise
>>> that if signal P is true then exactly one of signals
>>> R and S will also be true") but no synthesis tool that
>>> I'm aware of can make use of this kind of information to
>>> improve its optimizations.
>>
>>If you already have the complete logic description (which is encoded in
>>all
>>of the 'non-assert' statements) the synthesis tool will not really have
>>much
>>use for these unverifiable asserts that purport to give this supposedly
>>'higher level' information.
>
> Sorry, this is nonsense. Synthesis tools generally cannot see
> outside the boundary of the module they're currently compiling.
Which optomization boundary are you talking about? The entity? I see cross
entity optomizations all the time. A trivial example that most here can
probably relate to is when you don't connect an entity input correctly or
don't connect the outputs to anything and you run it through and find the
whole entity has been optomized out. How do you explain that behaviour if
the entity represents any sort of actual optomization boundary.
> Suppose you have two quite independent modules, communicating
> over a flat 32-bit data bus. Suppose, what's more, that there
> is a "fetch" signal emitted by one module and received by the
> other; and when this "fetch" signal is asserted, the source
> module reliably produces an instruction code that is one-hot
> coded. How can the destination (receiving) module's VHDL
> code possibly capture that knowledge? - knowledge that is
> very valuable for optimising the instruction decode logic.
Here's two (assuming that we're living all within one FPGA/Asic design)
1. If the data bus is a point to point connection, then don't use a flat 32
bit bus, but use an enumerated type to pass the data between the modules.
2. If modules must use std_logic_vector busses to communicate (like if you
use Wishbone or Avalon, etc. as your preferred way to stitch together
modules) then an enumerated type coupled with a 'To_Std_Logic_Vector' and a
'From_Std_Logic_Vector' function.
I haven't run into any lack of optomization across the entity boundaries
when I've done either of the above and it makes for very concise and easily
maintainable code. Not only that but the mutual exclusivity (if that's a
word ;) is directly coded it's not an assumption that may or may not be
guaranteed, new things can easily be added/subtracted from the list, blah,
blah, blah....in other words enumerated types are the solution to this one.
Optomizations (or lack thereof) could be a tool dependent issue though but I
haven't run across it to be a problem with Quartus or Synplify.
If the two modules are in different physical parts and the bus is a device
I/O then I think it would be totally inappropriate to have any code that
assumes that the PCBA and the solder connections and such would feel bound
by the idea of any sort of mutual exclusion which is why my two examples are
within the constraints of being inside one physical device.
>
> In any case, the idea of an "unverifiable" assertion is surely
> absurd. The whole point of assertions is that they continually
> monitor the data whose properties they check; long after the
> assertion's author has forgotten why he put it there, the
> assertion continues to contribute to the verification effort.
In simulation yes. If the synthesized logic is somehow 'different' because
of the inclusion or not of the assert statement in the source code then how
does the physical part behave when the asserted condition fails? That was
my basic point. I would expect it to behave as defined by the the logic
description completely.
Having synthesis check assertions that are statically determined things is
appropriate. Dynamically though? Not convinced that it could or even
should attempt this.
>
>> Just what should happen if the logic
>>description says one thing but the assertion claim another...and the
>>supposedly impossible thing happens (i.e. the 'assert' fires)?
>
> Then your verification effort correctly shows that you have made
> unjustified assumptions that you must review. That's the whole
> point: by capturing *in a single language construct* both an
> assumption that you're making about runtime behaviour, and a
> permission to the synthesis tool to share that assumption,
> you have a safe way to capture knowledge of a system's
> expected behaviour that cannot be described any other way.
The logic function though is described though by the logic that is written
not by the assert. Maybe we're not understanding what the other is saying
on this particular point though..
>
>>> It is *always* possible to get the desired behaviour
>>> by writing sufficiently contorted VHDL.
>>
>>Many times with uncontorted code as well....like the sum of products
>>solution to the outbus example.
>
> Indeed so. Often there is a simple solution that
> merely needs to be revealed and added to the folklore.
>
Definitely agree...that's one good thing about newsgroups. Not every day do
you get a useful nugget, but often enough you do.
>>So we agree that the enumeration type solves the one class of mutual
>>exclusiveness. But I'm still waiting for the example of this 'common'
>>problem for which 'orif' is the solution.
>
> OK, I promise I'll try to find some more compelling examples.
Look forward to it....but I'm guessing that there may be better things to
do.
KJ
Marcus Harnisch
"KJ" <kkjen...@sbcglobal.net> writes:
> 2. If modules must use std_logic_vector busses to communicate (like if you
> use Wishbone or Avalon, etc. as your preferred way to stitch together
> modules) then an enumerated type coupled with a 'To_Std_Logic_Vector' and a
> 'From_Std_Logic_Vector' function.
That way you will shift the issue (given that there be any) to a
different stage. What about the supposed if/else construct in
'From_Std_Logic_Vector'? Again, how's synthesis to know that the input
parameter is *always* -- say -- one-hot? You could of course use an
enumerated type to work around that...
> In simulation yes. If the synthesized logic is somehow 'different' because
> of the inclusion or not of the assert statement in the source code then how
> does the physical part behave when the asserted condition fails? That was
> my basic point. I would expect it to behave as defined by the the logic
> description completely.
>
> Having synthesis check assertions that are statically determined things is
> appropriate. Dynamically though? Not convinced that it could or even
> should attempt this.
What about formal verification?
> The logic function though is described though by the logic that is written
> not by the assert. Maybe we're not understanding what the other is saying
> on this particular point though..
That's why an assertion is not appropriate for that particular
purpose. A language feature that is very similar to an assertion but
not quite the same.
What about attributes? I think these are totally underused in VHDL. I
guess the fact that their point of declaration is normally not very
close to the place where they'd be used later on, doesn't really make
them very popular. Emacs' vhdl-mode could solve that (if it doesn't
already) by displaying attribute values for the current language
construct.
Regards,
Marcus
--
note that "property" can also be used as syntaxtic sugar to reference
a property, breaking the clean design of verilog; [...]
KJ
> Hi KJ
>
> "KJ" <kkjenni...@sbcglobal.net> writes:
> > 2. If modules must use std_logic_vector busses to communicate (like if you
> > use Wishbone or Avalon, etc. as your preferred way to stitch together
> > modules) then an enumerated type coupled with a 'To_Std_Logic_Vector' and a
> > 'From_Std_Logic_Vector' function.
>
> That way you will shift the issue (given that there be any) to a
> different stage. What about the supposed if/else construct in
> 'From_Std_Logic_Vector'? Again, how's synthesis to know that the input
> parameter is *always* -- say -- one-hot? You could of course use an
> enumerated type to work around that...
The to/from std_logic_vector functions would convert the enumerated
type to/from std_logic_vectors simply for communicating over the
presumed 32 bit data bus. There would be no need for any if
statements in either of these functions. The encoding and decoding
functions can be lots of things but they could simply be a one hot
coding of the enumeration list or a binary coding or whatever.
Synthesis unrolls the functions and the net result of converting an
enumerated type to a std_logic_vector and then back to an enumerated
type on the other end is zero logic cells (as it should be since the
one function is the inverse of the other)....and yes it really does do
this with real tools, not just an academic 'well it should do this'.
KJ
Andy
> 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;
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.
Andy
Andy
> 3. 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.
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.
Andy
Weng Tianxiang
Hi Andy,
I accept your advice and will learn PSL
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?
1. 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.
2. 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.
3. 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'.
Thank you.
Weng
Andy
> If you already have the complete logic description (which is encoded in all
> of the 'non-assert' statements) the synthesis tool will not really have much
> use for these unverifiable asserts that purport to give this supposedly
> 'higher level' information. Just what should happen if the logic
> description says one thing but the assertion claim another...and the
> supposedly impossible thing happens (i.e. the 'assert' fires)? The
> synthesis tool generated logic will have no way to flag this and, I'm
> guessing, is free to implement this case however it wants to independent of
> the logic description....I think I'll pass on such a tool, the supposedly
> 'impossible' happens, 'specially as code gets reused in new applications.
If you've ever used integer types for synthesis, then you've already
used "built-in" assertions, and seen the synthesis tools' ability to
infer information from them, and optimize the logic to take advantage
of input combinations that cannot exist in the simulation:
signal my_int : integer range 0 to 255;
This is an integer, which if it's value ever exceeds the range of 0 to
255, inclusive, will cause a simulation halt, with an unrecoverable
error.
The synthesis tool recognizes this, and decides it does not need all
32 signed bits to represent all possible values of my_int, it only
needs 8 unsigned bits. What happens to the circuit if some value is
attempted to be stored that is greater than 255 (or less than 0)? It
does not matter, because the simulator will not describe it either.
So, for a counter, the most efficient implementation would be for it
to roll over, even though that would not happen in the simulation code
(nothing would happen, it would be an error). In effect, an assignment
that cannot happen in the simulator is treated as a don't care in the
circuitry.
So indeed there is precedence for synthesis tools using information
that is in the form of built-in assertions to allow optimization of
logic.
If you doubt this, consider the following code:
process (clk, reset) is
variable count : integer range 0 to 255;
begin
if reset = '1' then
count := 0;
elsif rising_edge(clk) then
if count - 1 < 0 then
count := 255;
else
count := count - 1;
end if;
end if;
end process;
Since count is an integer, it cannot take on a value of less than
zero, otherwise a simulation error would occur. However, the integer
expression (count - 1) can have a value less than zero (so long as the
result is not stored back in count), and therefore is a legitimate
comparison. This same code would not work for numeric_std.unsigned,
since a the subtraction operator with an unsigned and a natural always
returns unsigned. The synthesis tool is aware of all this, and
correctly optimizes the two subtractions into one (shares them), and
extracts the carry (borrow) bit for the comparison. The fitter may
perform additional optimizations or transformations, based on the
technology being targeted.
Andy
KJ
> > If you already have the complete logic description (which is encoded in all
> > of the 'non-assert' statements) the synthesis tool will not really have much
> > use for these unverifiable asserts that purport to give this supposedly
> > 'higher level' information. Just what should happen if the logic
> > description says one thing but the assertion claim another...and the
> > supposedly impossible thing happens (i.e. the 'assert' fires)? The
> > synthesis tool generated logic will have no way to flag this and, I'm
> > guessing, is free to implement this case however it wants to independent of
> > the logic description....I think I'll pass on such a tool, the supposedly
> > 'impossible' happens, 'specially as code gets reused in new applications.
>
> If you've ever used integer types for synthesis, then you've already
> used "built-in" assertions, and seen the synthesis tools' ability to
> infer information from them, and optimize the logic to take advantage
> of input combinations that cannot exist in the simulation:
>
> signal my_int : integer range 0 to 255;
>
> This is an integer, which if it's value ever exceeds the range of 0 to
> 255, inclusive, will cause a simulation halt, with an unrecoverable
> error.
>
> The synthesis tool recognizes this, and decides it does not need all
> 32 signed bits to represent all possible values of my_int, it only
> needs 8 unsigned bits.
Not at all. Synthesis tools key off the range definition that is
typed in as being from 0 to 255 to calculate that an 8 bit
representation is needed. Assertions have nothing to do with it.
>
> So indeed there is precedence for synthesis tools using information
> that is in the form of built-in assertions to allow optimization of
> logic.
>
And how can you say with any certainty that this is not just
precedence for using the defined range of an integer and has
absolutely nothing to do with assertions?
KJ
Andy
The way the synthesis tool recognizes it is in fact, as you say. What
gives it the permission to is the built in assertion, thus specifying
that conditions which would result in a value outside the declared
range are don't care. After all, I guarantee that the simulator
implements "integer range 0 to 512" as a 16 or 32 bit value, not a
nine bit value!
My point is that the simulator and synthesis tool have "different"
behavior. Because the simulator errors out, the synthesis tool is free
to optimize the hardware for those conditions. It would be very
difficult for a synthesis tool to come up with an error routine in
hardware, so it does not try. It assumes (rightly so) that the user is
not interested in implementing cases where the simulation does not
complete.
Andy
Andy
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.
output <= data(to_integer(unsigned(one_hot_encode(e))));
Where one_hot_encode() is a function that optimally (without priority)
converts a one_hot slv to a smaller, binary value slv.
Additional code is needed to handle the zero_hot case.
If one was willing to assume that vector lengths could be limited to
2**31 bits, then one_hot_encode() could return an integer, making its
use a little simpler:
output <- data(one_hot_encode(e));
The optimal coding of one_hot_encode() is left as an excercise for the
user. ;^)
BTW, I assumed "data" was an array of std_logic_vector in my example;
so my version worked as was with the appropriate declaration.
Andy
Andy
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.
Andy
Marcus Harnisch
> Synthesis unrolls the functions and the net result of converting an
> enumerated type to a std_logic_vector and then back to an enumerated
> type on the other end is zero logic cells (as it should be since the
> one function is the inverse of the other)....and yes it really does do
> this with real tools, not just an academic 'well it should do this'.
Care to provide a working example? This sounds really interesting.
Andy
> > In any case, the idea of an "unverifiable" assertion is surely
> > absurd. The whole point of assertions is that they continually
> > monitor the data whose properties they check; long after the
> > assertion's author has forgotten why he put it there, the
> > assertion continues to contribute to the verification effort.
>
> In simulation yes. If the synthesized logic is somehow 'different' because
> of the inclusion or not of the assert statement in the source code then how
> does the physical part behave when the asserted condition fails? That was
> my basic point. I would expect it to behave as defined by the the logic
> description completely.
The guiding principle of HDL-logic synthesis is this: The behavior
exhibited by the simulator should determine the behavior exhibited by
the hardware synthesized by the same code.
An assertion is a way to force the simulation to stop if certain
conditions occur. Since functional behavior due to those conditions is
not handled in the simulation, it is reasonable to expect that the
synthesized hardware should not have to handle them either. The "logic
description" you refer to is the sum total of the behavior of the
simulator when simulating that code, and therefore includes the
assertions.
>
> Having synthesis check assertions that are statically determined things is
> appropriate. Dynamically though? Not convinced that it could or even
> should attempt this.
This may only be a matter of semantics, but the synthesis tool would
not be "checking" assertions, but merely using the information
provided by them to identify "don't care" conditions. Assertions may
provide information like: "if more than one of these bits is set, I
don't care what the hardware does, because that won't happen (and did
not happen in simulation)." The assertion gives permission to optimize
out any additional logic related to those don't care conditions.
> >> Just what should happen if the logic
> >>description says one thing but the assertion claim another...and the
> >>supposedly impossible thing happens (i.e. the 'assert' fires)?
Again, the assertion causes the simulation to not handle the
condition, so there is no behavior related to that condition to
emulate in hardware. Since there is no behavior to emulate, the
synthesis tool is free to optimize out any additional hardware related
to the condition that would fire the assertion. The behavior of the
simulator was a "don't care," as should be the behavior of the
synthesized hardware.
The assertion IS a part of the logic description!
>
> > Then your verification effort correctly shows that you have made
> > unjustified assumptions that you must review. That's the whole
> > point: by capturing *in a single language construct* both an
> > assumption that you're making about runtime behaviour, and a
> > permission to the synthesis tool to share that assumption,
> > you have a safe way to capture knowledge of a system's
> > expected behaviour that cannot be described any other way.
>
> The logic function though is described though by the logic that is written
> not by the assert. Maybe we're not understanding what the other is saying
> on this particular point though..
Repeat after me; "The 'logic function' is determined by the
simulator's behavior, which includes the assertions."
Andy
KJ
Sure. See code below. What I've done is defined an enumerated type
('My_Type') with 8 values and To/From conversion functions that
convert this enumerated type into a std_ulogic_vector format. For
simplicity, the std_ulogic_vector is simply an unsigned binary
representation of the position within the enumerated type list. Since
I had 8 enumeration values, I need three bits to represent a signal of
that type. Other vector representations are permissable (like perhaps
an 8 bit 'one hot' representation). The vector representation itself
is not important, the key thing is that the To_Std_Ulogic_Vector()
function is the inverse of the From_Std_ULogic_Vector() function...in
other words each one 'undoes' the other.
To demonstrate cross entity optomizations I've created a 'Transmitter'
entity that takes a vector in and spits out a signal of 'My_Type'.
Similarly, I've created a 'Receiver' entity that takes a signal of
'My_Type' in and spits out a std_ulogic_vector. Lastly, I've created
the top level entity called 'Junk' which instantiates both of these
entities, creating an intermediate signal 'My_Type_Signal' that is an
enumerated type.
The expected result would be that the output of the top level maps
directly to the inputs since the two entities undo what the other has
done. Running this through Quartus and looking at the 'Technology
Map' viewer this is exactly what you'll see, so what gets implemented
is 0 logic cells (which is also was Quartus report).
Enjoy.
KJ
-- START OF CODE --
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
package pkg_My_Package is
type My_Type is (s0, s1, s2, s3, s4, s5, s6, s7);
function To_Std_ULogic_Vector(L: My_Type) return
std_ulogic_vector;
function From_Std_ULogic_Vector(L: std_ulogic_vector) return
My_Type;
end package pkg_My_Package;
package body pkg_My_Package is
function To_Std_ULogic_Vector(L: My_Type) return std_ulogic_vector
is
variable RetVal: std_ulogic_vector(2 downto 0);
begin
RetVal := std_ulogic_vector(to_unsigned(My_Type'pos(L),
RetVal'length));
return(RetVal);
end function To_Std_ULogic_Vector;
function From_Std_ULogic_Vector(L: std_ulogic_vector) return
My_Type is
variable RetVal: My_Type;
begin
RetVal := My_Type'val(to_integer(unsigned(L)));
return(RetVal);
end function From_Std_ULogic_Vector;
end package body pkg_My_Package;
library ieee;
use ieee.std_logic_1164.all;
entity Transmitter is port(
Gazinta: in std_ulogic_vector(2 downto 0);
Gazouta: out work.pkg_My_Package.My_Type);
end Transmitter;
architecture RTL of Transmitter is
begin
Gazouta <= work.pkg_My_Package.From_Std_ULogic_Vector(Gazinta);
end RTL;
library ieee;
use ieee.std_logic_1164.all;
entity Receiver is port(
Gazinta: in work.pkg_My_Package.My_Type;
Gazouta: out std_ulogic_vector(2 downto 0));
end Receiver;
architecture RTL of Receiver is
begin
Gazouta <= work.pkg_My_Package.To_Std_ULogic_Vector(Gazinta);
end RTL;
library ieee;
use ieee.std_logic_1164.all;
entity Junk is port(
Gazinta: in std_ulogic_vector(2 downto 0);
Gazouta: out std_ulogic_vector(2 downto 0));
end Junk;
architecture RTL of Junk is
signal My_Type_Signal: work.pkg_My_Package.My_Type;
begin
XMIT : entity work.Transmitter port map(Gazinta, My_Type_Signal);
RCV : entity work.Receiver port map(My_Type_Signal, Gazouta);
end RTL;
-- END OF CODE --
Andy
> Are you sure that Jim's assertion method in communicating mutually
> exclusivity to VHDL compiler is good enough without need for 'orif'
> introduction?
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.
>
> 1. 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.
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.
>
> 2. 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.
'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.
>
> 3. 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'.
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.
Thanks,
Andy
Jonathan Bromley
>On Sep 5, 8:40 am, Marcus Harnisch <marcus.harni...@gmx.net> wrote:
>> KJ <Kevin.Jenni...@Unisys.com> writes:
>> > Synthesis unrolls the functions and the net result of converting an
>> > enumerated type to a std_logic_vector and then back to an enumerated
>> > type on the other end is zero logic cells (as it should be since the
>> > one function is the inverse of the other)....and yes it really does do
>> > this with real tools, not just an academic 'well it should do this'.
>>
>> Care to provide a working example? This sounds really interesting.
>Sure. See code below.
[snip]
Sorry Kevin, this has not even slightly convinced me. Your Receiver
has statically-guaranteed mutual exclusivity because the communication
path from transmitter to receiver was an enumeration.
Rather than converting enum->SLV->enum as you claim, you're
doing SLV->enum->SLV (with the enum re-coded as SLV by the tool)
which is quite different.
I have a counter-example that multiplexes a 9-value enumeration or
an 8-bit std_logic_vector onto an 8-bit SLV bus, the enum being
one-hot-zero coded by a function, and the mux control being conveyed
on a separate std_logic. My receiver uses the mux control to
either drive the 8-bit SLV on to an 8-bit output port, or
drive the 8-bit one-hot-zero code on to the same 8-bit output
port using this bit of code:
if mode_i = '0' then -- receive an operation code
if data_i(0) = '1' then opr_o <= X"01" ;
elsif data_i(1) = '1' then opr_o <= X"02" ;
elsif data_i(2) = '1' then opr_o <= X"04" ;
elsif data_i(3) = '1' then opr_o <= X"08" ;
elsif data_i(4) = '1' then opr_o <= X"10" ;
elsif data_i(5) = '1' then opr_o <= X"20" ;
elsif data_i(6) = '1' then opr_o <= X"40" ;
elsif data_i(7) = '1' then opr_o <= X"80" ;
else opr_o <= X"00";
end if;
else -- receive an 8-bit value
opr_o <= data_i;
end if;
And, surprise surprise, NO synth tool I've yet tried can
automatically infer that the various branches of the long
if-elsif are mutually exclusive, even though I've put all
the relevant modules in a single file and, taking the
design as a whole, the mutual exclusivity can easily be
proven. I get truckloads of redundant logic.
Replace my "elsif" with Weng's hypothetical "orif" and...
(1) simulation behaviour would be identical if the
"one-hot-zero" property holds good;
(2) simulation would throw a runtime error if the
"one-hot-zero" property were false at any moment
when the if-orif is executed;
(3) synthesis would rely on (2) to justify an assumption
that the various branches of the if-orif are
mutually exclusive, and therefore the gates can be
simplified to wires exhibiting exactly the behaviour
specified in (1).
Now, I am fully aware that I could easily re-code this
no-op decoder in a different way that would give me
the wires-only hardware I desire. But any such coding
would inherently capture my knowledge of the mutual
exclusivity. What Weng is very reasonably trying to
do is to find a way to capture known mutual exclusivity
in situations that are much less self-evident than
my example, and in which no simple re-coding could
capture the required knowledge. The results of my
little synthesis experiment shows that this is worth
trying to achieve.
Note, for the avoidance of any confusion, that I am
NOT hereby advocating the "orif" proposal.
Weng Tianxiang
Hi Andy,
"Conversely, there are several situations where
'orif' is not an option, but an assertion would be. "
NEVER !
If you have an example to support your opinion, I would recall my
propose forever.
Weng
Weng Tianxiang
Now it is clear to me, if not to you,
What assertion onehot0() can do, orif can do better !
"You can NEVER use a parameterized loop of if-then structures"
It is wrong now after our long discussions.
Whenever you write a loop and try to transfer mutually exclusive
information into it, you must remember that you must clearly write
'if..elsif..." structure, then each elsif is a perfect candatate to be
replaced within your loop.
REMEMBER: if you want to use assertion onehot0() to transfer mutually
exclusive information, all signals in onehot() entries must be used
after keywords if and elsif. Other coding short cut would leave the
information useless and wastful.
Weng
Mike Treseler
> What Weng is very reasonably trying to
> do is to find a way to capture known mutual exclusivity
> in situations that are much less self-evident than
> my example, and in which no simple re-coding could
> capture the required knowledge. The results of my
> little synthesis experiment shows that this is worth
> trying to achieve.
This is interesting from a language point of view
but I am not convinced that it would make my job
any easier. I use lots of enumeration types in my code
and have not suffered (so far) with a synthesis setting
of AUTO. With quartus and ise this usually results
in a binary encoding for small enums and one-hot
for larger ones.
My point is that, until I inadvertently
set off this thread, I have not
had to invest any intellectual effort in considering
the synthesis details of enumeration encoding and decoding.
I have played with changing the AUTO setting to binary,
because this is what I used in the 22v10 days
when I had no choice but to do this by hand.
This costs a trifling amount of resources,
but since synthesis is willing to keep track
of the vector encoding, I have no good reason not
to stick with AUTO.
Does anyone have a synthesis example where
describing such enum encoding details in my code
is a big win?
> Note, for the avoidance of any confusion, that I am
> NOT hereby advocating the "orif" proposal.
So say we all.
-- Mike Treseler
KJ
wrote:
> On Wed, 05 Sep 2007 07:21:49 -0700, KJ wrote:
> >On Sep 5, 8:40 am, Marcus Harnisch <marcus.harni...@gmx.net> wrote:
> >> KJ <Kevin.Jenni...@Unisys.com> writes:
> >> > Synthesis unrolls the functions and the net result of converting an
> >> > enumerated type to a std_logic_vector and then back to an enumerated
> >> > type on the other end is zero logic cells (as it should be since the
> >> > one function is the inverse of the other)....and yes it really does do
> >> > this with real tools, not just an academic 'well it should do this'.
>
> >> Care to provide a working example? This sounds really interesting.
> >Sure. See code below.
>
> [snip]
>
> Sorry Kevin, this has not even slightly convinced me. Your Receiver
> has statically-guaranteed mutual exclusivity because the communication
> path from transmitter to receiver was an enumeration.
> Rather than converting enum->SLV->enum as you claim, you're
> doing SLV->enum->SLV (with the enum re-coded as SLV by the tool)
> which is quite different.
>
I think you read more into this than was intended. What Marcus had
asked for (or at least what I thought he had asked for) was example
code showing that the conversion of an enumerated type to and from a
std_logic_vector really took 0 logic elements.
It really had nothing to do with Weng's 'orif'. The branch that this
sub-topic was on started because you challenged me to optomize across
entity boundaries where the interface between the entities is a
std_logic_vector (or something along those lines). My sample code
conversion was slv->enum->slv, although the reverse of what I had
stated, simply because the synthesizer does not make the assumption
that I/O pins are mutually exclusive so putting an enumerated type as
pins of the FPGA can be problematic. Since I was not trying to
demonstrate optomization across FPGA boundaries, I made that change.
While that point IS relevant to Weng's 'orif' (but also likely
solvable by the sum of products), my posting was simply to show that
conversions can be made internal to a single FPGA design to and from
enumerated type using std_logic_vectors as the interface between
entities and it will incur no synthesis cost in terms of resource
usage....that's all.
Just to show that things can go the other way as well though, I've
posted code at the end that does the following conversions in separate
entities:
slv->enum->slv->enum->slv
Again, it takes 0 logic cells and reduces to wires in the technology
map viewer and there is an enum->slv->enum conversion inside the
design. Now you can again take issue with the fact that I'm starting
with slv but these enumerated type signals are all going to be
internal to the device but in order to produce example code
demonstrating the concept I had to bring signals out to pins otherwise
it will get reduced to 0 logic cells and 0 pins.
By the way, my conversion functions have never used if
statements....not saying they couldn't, or that if they did that they
might consume resources, just that I've never run across the need for
an if statement in a type conversion function yet and I'm happy with
the usage, the localization of stuff that tends to be 'bit twiddling'
types of operations to a single spot in the code, and of course the 0
logic resource cost.
Maybe you should consider my approach of constructing simple type
conversion functions to/from an enumerated type, you likely won't need
the big 'if' statement in those functions which is a likely cause of
the redundant logic you're seeing....just speculating though, you
certainly know your particular code better than I.
<snip>
> Now, I am fully aware that I could easily re-code this
> no-op decoder in a different way that would give me
> the wires-only hardware I desire. But any such coding
> would inherently capture my knowledge of the mutual
> exclusivity.
Sounds like a good approach to me.
> What Weng is very reasonably trying to
> do is to find a way to capture known mutual exclusivity
> in situations that are much less self-evident than
> my example, and in which no simple re-coding could
> capture the required knowledge. The results of my
> little synthesis experiment shows that this is worth
> trying to achieve.
Again though, your simple experiment may not really be demonstrating
what problem really can best be solved by 'orif' as opposed to
enumerated types or sum of products....which is where we were at a
couple days ago in this thread when the question was raised about just
what problem is Weng trying to solve? Or more to the point, how come
there is no actual good example of such a problem that 'orif' is a
better solution than the current forms? Fitting all control logic
into an 'if' statement (Weng's stated goal) is a solution to WHAT
problem?
>
> Note, for the avoidance of any confusion, that I am
> NOT hereby advocating the "orif" proposal.
> --
And I am neither an advocate nor a detractor of 'orif'. I rail
against the unsubstantiated claims mostly.
KJ
---- START OF UPDATED CODE ----
entity Junk is port(
Gazinta1: in std_ulogic_vector(2 downto 0);
Gazouta1: out std_ulogic_vector(2 downto 0);
Gazinta2: in std_ulogic_vector(2 downto 0);
Gazouta2: out std_ulogic_vector(2 downto 0));
end Junk;
architecture RTL of Junk is
signal My_Type_Signal: work.pkg_My_Package.My_Type;
signal My_Type_Signal2 : work.pkg_My_Package.My_Type;
signal My_Type_Signal3 : work.pkg_My_Package.My_Type;
signal my_slv : std_ulogic_vector(2 downto 0);
begin
XMIT1 : entity work.Transmitter port map(Gazinta1, My_Type_Signal);
RCV1 : entity work.Receiver port map(My_Type_Signal, Gazouta1);
RCV2A : entity work.Transmitter port map(Gazinta2,
My_Type_Signal2);
RCV2B : entity work.Receiver port map(My_Type_Signal2, my_slv);
XMIT2 : entity work.Transmitter port map(my_slv, My_Type_Signal3);
RCV2C : entity work.Receiver port map(My_Type_Signal3, Gazouta2);
end RTL;
---- END OF UPDATED CODE ----
Andy
> Hi Andy,
> Now it is clear to me, if not to you,
>
> What assertion onehot0() can do, orif can do better !
>
> "You can NEVER use a parameterized loop of if-then structures"
>
> It is wrong now after our long discussions.
>
> Whenever you write a loop and try to transfer mutually exclusive
> information into it, you must remember that you must clearly write
> 'if..elsif..." structure, then each elsif is a perfect candatate to be
> replaced within your loop.
Weng,
Neither of your statements is true.
With 'orif' you must have all of your mutually exclusive (orif)
conditions in a single if-orif tree. 'orif' statements in different if-
orif trees have no context relative to each other, and therefore
cannot indicate mutual exclusivity. For example:
if a = '1 then
z <= x;
orif b = '1' then -- a and b are mutex
z <= y;
end if;
if c = '1' then
g <= e;
orif d = '1' then -- c and d are mutex
g <= f;
end if;
Note that the above does not indicate that a and c are mutex, nor
would you want it to, because then how would you code it such that a
and c are NOT mutex, but both are executed (so you could not use
elsif). For practical reasons, the scope of the mutual exclusivity
must be limited to the same if- or elsif- tree.
You can only unroll a loop of if-then statements into a single if-orif
tree if you know the number of choices when you write it. Otherwise,
you must use a loop with an if-then statement, using a parameter to
determine the number of loop iterations. The if-then statement in the
loop unrolls during synthesis to become separate if-then statements,
so even if there was an orif in the loop's if-then statement, it would
be meaningless between the separate, unrolled if-then statements. The
parameter to control loop iterations may be related to a generic, or
to the size of an unconstrained array port, so you could not possibly
know it ahead of time and manually transform the loop into an if-orif
tree.
> REMEMBER: if you want to use assertion onehot0() to transfer mutually
> exclusive information, all signals in onehot() entries must be used
> after keywords if and elsif. Other coding short cut would leave the
> information useless and wastful.
An example of using an assertion without an associated if-then
statement:
Case state_a is
...
when multiply_a =>
x <= y * z;
...
end case.
...
case state_b is
...
when multiply_b =>
a <= b * c;
...
end case;
...
assert zero_one_hot((state_a=multiply_a, state_b=multiply_b));
The assertion could tell the synthesis tool that only one physical
multiplier is needed.
Andy
Andy
> "Conversely, there are several situations where
> 'orif' is not an option, but an assertion would be. "
>
> NEVER !
>
> If you have an example to support your opinion, I would recall my
> propose forever.
Weng,
If you can re-write the following with an if-orif tree to indicate
that every element in enable is mutually exclusive, then you win!
BTW, the range of enable is unknown, but somewhere within the range of
integer'low to integer'high, if that helps.
type data_t is array (enable'range) of std_logic_vector(output'range);
signal data: data_t; -- could be a port instead...
...
for i in enable(i) loop
if enable(i) = '1' then
output <= data(i);
exit;
end if;
end loop;
assert zero_one_hot(enable);
Andy
Andy
I understand what you are trying to demonstrate, but I don't think
that is what we're asking for.
What we want is a way to take an input slv for which we are certain
that exactly one of those bits is set at any given time (one-hot,
mutually exclusive), and convert that slv into an output integer that
is the index of the bit that is set, with no priority encoding, etc.
An integer is sufficient because integer encodings are by definition
mutually exclusive. Also enumerated types are impossible to define
with an arbitrary (parameterized) number of possible values.
Now, we know this can be done with boolean equations, but can you do
it in behavioral code without resorting to boolean operations (and,
or, etc.). I think it can be done with a case statement (and std_logic
types), but I'm not sure whether most synthesis tools will "take the
bait":
case input is
when "0001" => output <= "00";
when "0010" => output <= "01";
when "0100" => output <= "10";
when "1000" => output <= "11";
when others => output <= "--";
end case;
For a loop implementation:
variable temp : slv(input'range);
output <= (others => '-');
for i in input'range loop
temp := (others => '0');
temp(i) := '1';
if input = temp then
output <= slv(to_unsigned(i, output'length));
end if;
end loop;
Now, if I convert the integer encoding back to one hot:
result := (others => '0');
result(to_integer(unsigned(output))) := '1';
However, if this string of logic is synthesized, It will not reduce to
wires (because we had to use binary encoding because we had an
arbitrary number of inputs).
So, I would presume that, for an arbitrary number of mutually
exclusive inputs, there is no conversion from one hot to any mutually
exclusive encoding and back that reduces to wires.
Therefore, we need a method to do that.
Andy
Weng Tianxiang
Hi Andy,
Your code:
for i in enable(i) loop
if enable(i) = '1' then
output <= data(i);
exit;
end if;
end loop;
assert zero_one_hot(enable); <-- useless and wasting time in its
purpose
My code:
for i in enable(i) loop
if enable(i) = '1' then
output <= data(i);
exit;
end if;
end loop;
Why do you need to tell VHDL compiler that every element in enable is
mutually exclusive?
My coding has already told VHDL compiler that
1. all enable(i) are mutually exclusive;
2. You don't have to do anything, I have done it for you and please
take the rest.
If you really want to tell SIMULATOR the information, it has nothing
to do with orif. You may write any function following assertion
statement without any problem.
Target to transfer mutually exclusive information to VHDL compiler is
the pivotal point. VHDL compiler fails to do a better job because VHDL
language lacks elements concisely, relaibly, easily and safely to
transfer the mutually exclusive information to VHDL compiler, not to
SIMULATOR.
VHDL doesn't lack tools to transfer any information to SIMULATORS.
Assertion have already been there for the purpose since its birth.
Jim just unexpertly devised a mechanism that is almost useless in its
purpose.
I would like to thank for your discussion on this topics, because
through our discussions I realized that if one wants to transfer
mutually exclusive information to VHDL compiler, he must stick with
the 'if...end if' statement strucure. Before it, I failed to recognize
it. This is what I said you had given me as a gift.
Please declare who is the
wiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiner.
Weng
Jim Lewis
> Jim just unexpertly devised a mechanism that is almost
> useless in its purpose.
This is not going to help promote your thoughts.
Please note, I did not participate in the PSL effort, I simply
observed that PSL (with the Accellera VHDL-2006 integration)
provides a capability that seems to address a number of the
use cases you are implying you need.
> I would like to thank for your discussion on this topics, because
> through our discussions I realized that if one wants to transfer
> mutually exclusive information to VHDL compiler, he must stick with
> the 'if...end if' statement strucure. Before it, I failed to recognize
> it. This is what I said you had given me as a gift.
Yet you have failed to demonstrate anything to anyone
other than yourself.
Unfortunately, your ideas will not go anywhere unless someone
follows the steps I outlined previously. All proposals put
forward to the working group must go through these steps
of analysis of both the capability requested and the
proposed solution. At this point, I don't see anyone
as excited as yourself to handle this.
> Please declare who is the
> wiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiner.
Any volunteers :)
Cheers,
Jim
Jim Lewis
> Andy's code:
> for i in enable(i) loop
> if enable(i) = '1' then
> output <= data(i);
> exit;
> end if;
> end loop;
> assert zero_one_hot(enable); <-- useless and wasting time in its
> purpose
>
> for i in enable(i) loop
> if enable(i) = '1' then
> output <= data(i);
> exit;
> end if;
> end loop;
I note that both of these have priority built into
the logic as the exit makes only the first enable set
take effect. Hence, without additional information (such as
the assertion), a synthesis tool will be obliged to create
the priority that is in the code.
If we really want mutually exclusive logic, then perhaps
a variable will do the trick. For give me if someone else
already suggested this as I have not re-read the threads.
process (enable, data)
variable vOutput : std_logic_vector(...) ;
begin
vOutput := (others => '0') ; -- assuming combinational logic
for i in enable'range loop
if enable(i) = '1' then
vOutput := data(i) or vOutput ;
end if;
end loop;
Output <= vOutput ;
end process ;
For those that like testing code on synthesis tools, I would
be curious to know how that plays the following (which is more
hardware implementation specific):
process (enable, data)
variable vOutput : std_logic_vector(...) ;
begin
vOutput := (others => '0') ; -- assuming combinational logic
for i in enable'range loop
vOutput := (data(i) and enable(i)) or vOutput ; -- vhdl-2006 "and"
end loop;
Output <= vOutput ;
end process ;
If you are coding this in a clocked process, you can put guard on
the enable using the reduction form of or (from VHDL-2006) or replace
it with or_reduce from ieee.std_logic_misc (not a standard package and
hence not recommended by me):
process (Clk)
variable vOutput : std_logic_vector(...) ;
begin
if rising_edge(Clk) then
if OR( enable) = '1' then
vOutput := (others => '0') ; -- assuming combinational logic
for i in enable'range loop
vOutput := (data(i) and enable(i)) or vOutput ; -- vhdl-2006 "and"
end loop;
Output <= vOutput ;
end if ;
end if ;
end process ;
Cheers,
Jim
SynthWorks VHDL Training
Michael Jørgensen
"Andy" <jone...@comcast.net> wrote in message
news:1189032622....@50g2000hsm.googlegroups.com...
This is an interesting example. I tried your above example on Quartus 7.1
(see complete code below), and indeed it leads to a sub-optimal logic
design. Running a gate-level simulation shows that the circuit behaves
correctly when the input is one-hot, i.e. "0001" -> "0001", "0010" ->
"0010", etc. The most optimal implementation would be straight wires, but
the netlist generated contains a number of ALUT's. (Interestingly enough,
the input signal input[0] is not used.)
Anyway, in this simple example I would have guessed the synthesis tool to be
able to recognize that straight wires is a valid and optimal design. It
surprises me that Quartus does not recognize that.
However, this really has nothing to do with mutual exclusiveness or one-hot
encoding. This problem is more general: In a case statement, some inputs may
be specified as "don't care" behaviour. How does the synthesis tool use
those extra degress of freedom?
Returning to the OP's suggestion of using orif: In this specific example, I
don't see a need for changing the source code. It seems that all the
information necessary for the synthesis tool is already present in the
source file. Instead, this specific example shows that the synthesis tool
itself could be made smarter.
-Michael.
library ieee;
use ieee.std_logic_1164.all;
package p_test_decode is
subtype t_data is std_logic_vector(3 downto 0);
end p_test_decode;
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use work.p_test_decode.all;
entity test_decode is
port (
input : in t_data;
output : out t_data
);
end entity test_decode;
architecture rtl of test_decode is
signal val : std_logic_vector(1 downto 0);
begin
decode: process(input) is
begin
case input is
when "0001" => val <= "00";
when "0010" => val <= "01";
when "0100" => val <= "10";
when "1000" => val <= "11";
when others => val <= "--";
end case;
end process decode;
encode: process(val) is
begin
output <= (others => '0');
output(to_integer(unsigned(val))) <= '1';
end process encode;
end architecture rtl;
Brian Drummond
wrote:
>On Sep 5, 12:16 pm, Andy <jonesa...@comcast.net> wrote:
>> > "Conversely, there are several situations where
>> > 'orif' is not an option, but an assertion would be. "
>> If you can re-write the following with an if-orif tree to indicate
>> that every element in enable is mutually exclusive, then you win!
>> type data_t is array (enable'range) of std_logic_vector(output'range);
>> signal data: data_t; -- could be a port instead...
>> ...
>> Andy
>
>Hi Andy,
>
>Your code:
>for i in enable(i) loop
> if enable(i) = '1' then
> output <= data(i);
> exit;
> end if;
>end loop;
>assert zero_one_hot(enable); <-- useless and wasting time in its
>purpose
>
>My code:
>for i in enable(i) loop
> if enable(i) = '1' then
> output <= data(i);
> exit;
> end if;
>end loop;
>
>Why do you need to tell VHDL compiler that every element in enable is
>mutually exclusive?
>
>My coding has already told VHDL compiler that
>1. all enable(i) are mutually exclusive;
>2. You don't have to do anything, I have done it for you and please
>take the rest.
Unfortunately, enable was accidentally set to "00010111"
Andy's code caught the problem before synthesis, so he fixed it.
Because his synthesis tool (the 2008 version) understood the assertion,
it was free to generate fast logic instead of following the priority.
Yours did not, and if your synthesis tool believed statement (1) above,
instead of following the priority built into the loop, it enabled four
drivers onto the "output" bus at once.
While you contemplate the smoking remains of your chip, you are invited
to explain how your comment "What assertion onehot0() can do, orif can
do better !" applies to this example.
- Brian
Andy
To elaborate on what Jim and Brian have stated, In the loop, in order
for enable(n) to be considered, enable(n-1) must have been false. This
evaluation of enable(n-1) requires additional gates UNLESS there is
something else that tells the compiler (synthesis or simulation) that
the enable bits are mutually exclusive, and therefore that if
enable(n) is set, by definition enable(n-1) is not set.
It is interesting to note that the presence of the exit statement has
no effect on the synthesized gates IF enable is mutually exclusive.
However in the absence of both the exit statement and mutual
exclusivity, the last executed assignment to output wins, so enable(n)
is only used if enable(n+1) is not set, thus also requiring additional
gates.
Both of these explanations assume an index ordering of "to", not
"downto"; however, the behavior is similar (and the effect on
hardware the same) with "downto".
So, in fact your code DOES NOT demonstrate, nor optimize for, the
mutual exclusivity of the bits in enable. Contrary to your erroneous
statement, your code merely demonstrates your lack of understanding of
the significance of order of execution among sequential statements, a
fundamental concept in simulation and logic synthesis.
Jim's (and others') implementation using OR works well for data types
that support the OR operator: booleans, bits and vectors, but neither
integers, enumerated types nor other aggregate types, without a
conversion to/from an ORable data type, can use this method.
In addition, without the assertion, the (erroneous) lack of mutual
exclusivity upon which the solution depends would likely go unnoticed
in simulation. And while the ability of the simulator to use the
assertion has existed since the beginning, the ability of synthesis
tools to use the assertion (not to verify it, but to optimize
circuitry because of it) does not, to this day, exist.
Oh, and by the way, I AM THE WINNER! ;^)
Andy
Andy
Yep, I stumbled across the lack of input(0) myself when I manually
converted it. It seems that the code assumes that EXACTLY one bit of
input is set (no bits set is not an option). So absence of the three
other bits is taken as the presence of the first bit. It may be that
if an extra bit is used to indicate that no bits were set, and that
bit used to reconstruct the one hot (er... zero one hot) vector, maybe
it would actually optimize out?
Just for grins, did you try it with one process? Perhaps the
optimization on the total stream failed because parts of it are in
separate processes. Not that this would be particularly acceptable,
since the nature of the problem we are trying to solve involves
communication between different entities, let alone different
processes.
Andy
Weng Tianxiang
1. Please write target answer's name, otherwise I may miss your
comments.
2. Before 2006, we didn't have 2006/2008 VHDL compilers available, did
you see any burning?
3. The following claim is irrelative to Andy's requirement:
"Andy's code caught the problem before synthesis, so he fixed it.
Because his synthesis tool (the 2008 version) understood the
assertion"
Andy wants me to use orif to transfer mutually exclusive information
to within loop, in this respect, no orif is needed and things are done
perfectly, because mutually exclusive Information has been clearly
transfered to within the loop by coding style.
I think it is the best explanation to your question:
Nothing is better than extra.
Whatever assertion onehot0() can do in terms of mutually exclusive
information tranfer mechanism, orif can do better, faster, safer and
more reliable !
The above sentence is too long to remember, the following sentence was
used and everyone involved knows its full meaning:
What assertion onehot0() can do, orif can do better.
I have to emphasize that onehot0() function is useful in general, but
useless in terms of its introduction purpose.
Weng
Weng Tianxiang
Your following claim is false:
"...enable(n-1) must have been false.."
Only enable() is a static, a foolish case, the above situation would
happen and your assertion part plays a role for a VHDL compiler.
The static values may be all 0. So that no code would be generated for
the code segment. Are you serious enough to design a mechanims to deal
with the stupid case only?
It has nothing to do with mutually exclusive information.
Nothing is better than extra gabage.
Weng
Weng Tianxiang
Sorry for any usage of inappropriate words.
Weng
Mike Treseler
> Yep, I stumbled across the lack of input(0) myself when I manually
> converted it. It seems that the code assumes that EXACTLY one bit of
> input is set (no bits set is not an option). So absence of the three
> other bits is taken as the presence of the first bit. It may be that
> if an extra bit is used to indicate that no bits were set, and that
> bit used to reconstruct the one hot (er... zero one hot) vector, maybe
> it would actually optimize out?
This is just a logic minimization from 4 input to 3 input LUTs.
It follows directly from the "others" case.
I tried this both ways:
case input is
when "0001" => val <= "00";
when "0010" => val <= "01";
when "0100" => val <= "10";
when "1000" => val <= "11";
-- when others => val <= "00"; -- 4in LUT-OR, input(0) used
when others => val <= "--"; -- 3in LUT-OR input(0) ignored
end case;
So synthesis found an optimization,
It just didn't find the best one.
> Just for grins, did you try it with one process?
This made no difference.
-- Mike Treseler
Andy
> Andy,
> Your following claim is false:
> "...enable(n-1) must have been false.."
>
> Only enable() is a static, a foolish case, the above situation would
> happen and your assertion part plays a role for a VHDL compiler.
>
Enable() is NOT static! It is a dynamic signal/variable that is driven
from elsewhere.
Note that I said "in order for enable(n) to be considered". I did NOT
say "for enable(n) to be set"!
If enable(n-1) was set, then the loop would have exited before
evaluating enable(n). Therefore output gets data(n) only if enable(n)
= '1' AND enable(n-1) = '0' AND enable(n-2) = '0' AND... This
results in additional logic that is not necessary if it is known that
the enable bits are mutually exclusive.
If you don't believe me, compare the synthesis results of your code
with Jim's code (since the assertion in my code is not understood by
synthesis yet). Jim's code is the logical equivalent of what a
synthesis tool should implement for your code (or my code), if the
tool was aware of, and could optimize for, mutual exclusivity.
> The static values may be all 0. So that no code would be generated for
> the code segment. Are you serious enough to design a mechanims to deal
> with the stupid case only?
Since you ask, this function is intended for a clocked process, so
"doing nothing" means maintaining the previous value (i.e. a clock
enable), which is far from a "stupid case".
Andy
Andy
Wow; interesting...
Thanks,
Andy
Brian Drummond
wrote:
>Hi Brian,
>1. Please write target answer's name, otherwise I may miss your
>comments.
>
>2. Before 2006, we didn't have 2006/2008 VHDL compilers available, did
>you see any burning?
Back in the TTL days, yes.
>3. The following claim is irrelative to Andy's requirement:
>"Andy's code caught the problem before synthesis, so he fixed it.
>Because his synthesis tool (the 2008 version) understood the
>assertion"
>
>Andy wants me to use orif to transfer mutually exclusive information
>to within loop, in this respect, no orif is needed and things are done
>perfectly, because mutually exclusive Information has been clearly
>transfered to within the loop by coding style.
it's exactly relevant because in his example, the ONLY mutually
exclusive information IS the assertion. In your counterexample I don't
see any such information, despite the fact that you are free to use
"orif".
>Whatever assertion onehot0() can do in terms of mutually exclusive
>information tranfer mechanism, orif can do better, faster, safer and
>more reliable !
This has still not been demonstrated for this example.
- Brian
KJ
> KJ,
>
>> > In any case, the idea of an "unverifiable" assertion is surely
>> > absurd. The whole point of assertions is that they continually
>> > monitor the data whose properties they check; long after the
>> > assertion's author has forgotten why he put it there, the
>> > assertion continues to contribute to the verification effort.
>>
>> In simulation yes. If the synthesized logic is somehow 'different'
>> because
>> of the inclusion or not of the assert statement in the source code then
>> how
>> does the physical part behave when the asserted condition fails? That
>> was
>> my basic point. I would expect it to behave as defined by the the logic
>> description completely.
>
> The guiding principle of HDL-logic synthesis is this: The behavior
> exhibited by the simulator should determine the behavior exhibited by
> the hardware synthesized by the same code.
In fact the guiding principle of logic synthesis is that the behaviour
exhibited by the hardware should conform to the language specification not
'the simulator' (whatever that might be). Every tool that I've picked up
claims conformance to some flavor of VHDL (i.e. '87, '93, '02), I've yet to
pick one up that claims conformance to Modelsim 6.3a.
<snip>
> This may only be a matter of semantics, but the synthesis tool would
> not be "checking" assertions, but merely using the information
> provided by them to identify "don't care" conditions. Assertions may
> provide information like: "if more than one of these bits is set, I
> don't care what the hardware does, because that won't happen (and did
> not happen in simulation)." The assertion gives permission to optimize
> out any additional logic related to those don't care conditions.
>
But the logic description (i.e. everything BUT the asserts) completely
describes the logic function by definition. The asserts are:
- Generally not complete behavioural descriptions
- Unverifiable as to correctness. In fact, a formal logic checker program
would take the asserts and the logic description and formally prove (or
disprove) that the description (the non-assert statements) accurately
produce the stated behaviour (the asserts). Since formal logic checkers can
'fail' (i.e. show that incorrect behaviour can result from the given logic
description) this would tend to drive a stake completely through your claim.
>
> The assertion IS a part of the logic description!
>
No, it is a (possibly incorrect) statement of what is believed to be correct
behaviour.
>
> Repeat after me; "The 'logic function' is determined by the
> simulator's behavior, which includes the assertions."
>
On that point, we most definitely do not agree. The non-asserts completely
define the logic function, the asserts incompletely (at least in VHDL)
describe correct behaviour.
KJ