I hate VHDL!!!

[Weng Tianxiang]

OK, at last Jim and JaI admit my equation is right.

If I take the following example:
A1 <= A and B;
A2 <= C and B;

with A and C mutually exclusive. How could you pretend that A1 and A2
are mutually exclusive ?
Mutual exclusive is these both signals are never equal. It is express in
logic by the xor function (exclusive or).

Mutual exclusive relation means only one of them can be true at any
time, and they can be all false, so it /= 'XOR'.

process (DIMMNumberClear, nC_BE_R0, n, bad_pci_type)
begin
if (DIMMNumberClear) then
DIMMNumber(4 downto 0) <= (others=>'0');
elsif (bad_pci_type = '0') then
if (AD_R0(28+n*32) = '1') then
DIMMNumber (4 downto 0) <= "10000";
else
DIMMNumber (4 downto 0) <= AD_R0(28+n*32 downto 24+n*32);
endif;
endif;
end process;

Above equations are wrong. n must be a constant to let compiler to
work. It is an compiler error. If n is a dynamic signal like in my
case, you must use n as in a condition for 'if' statement. If you
don't believe, try to compile it using any VHDL compiler.

Second segment of equations is right. Thank you, JaI!!! It clearly
demonstrates how hard from current VHDL structure to get both right
and efficient code. You must rewrite total code to get efficient
code!!! It is a big problem when you have a big project. It is real,
not virtual. That is why 'I hate VHDL': it is like you bought a set of
sockets to start your business and found that 3/8" socket wasn't there
and the manufacturers say it is your problem, you can deal with it
using 1/2", why do we need to manufacture a 3/8" socket especially for
your purpose?!

That is why 'orif' is so useful in the situation: first you write
correct code, then change 'elsif' to 'orif', you get your most
efficient code without any other code and structure change.

Tomorrow I will 'attack' Achilles heel of Jim's proposal assert() to
resolve mutually exclusive relations.

Weng

 

[Jim Lewis]

Weng,

OK, at last Jim and JaI admit my equation is right.
I did not actually say I agreed it is correct.

I agreed that when you divulged there were additional
conditions that made A and C mutually exclusive that
the circuit would work the way you described.

A1 <= A and B;
C1 <= C and B;

Note that under the conditions you describe, orif and elsif
should synthesize equally well (because if the synthesis tool
understands terms are mutually exclusive, then it does
not need orif). Also note that you are relying on the
synthesis tool to derive the mutual exclusion (otherwise
the only thing it knows is that A1 and C1 are mutually
exclusive).

If you use "orif", and the synthesis tool cannot derive
the mutual exclusion, then you are back to the tool
understanding that A1 and C1 (because of the orif)
being mutually exclusive, but not A and C.

So what you have done for me is to demonstrate how difficult
it is for people (yourself included) to full comprehend
the implications of orif.

Tomorrow I will 'attack' Achilles heel of Jim's proposal assert()
to resolve mutually exclusive relations.
Bring it on. You have yet to demonstrate any limitations.

So far you have only further convinced me that assert is the
better answer.

It would also be helpful if you could post some reasonable
sized examples which use orif.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Just an Illusion]

As Jim said,

I haven't said that I am agree with you.

I don't think that your proposal can help synthesizer.


Weng Tianxiang wrote:

OK, at last Jim and JaI admit my equation is right.
snip

process (DIMMNumberClear, nC_BE_R0, n, bad_pci_type)
begin
if (DIMMNumberClear) then
DIMMNumber(4 downto 0) <= (others=>'0');
elsif (bad_pci_type = '0') then
if (AD_R0(28+n*32) = '1') then
DIMMNumber (4 downto 0) <= "10000";
else
DIMMNumber (4 downto 0) <= AD_R0(28+n*32 downto 24+n*32);
endif;
endif;
end process;



Above equations are wrong. n must be a constant to let compiler to
work. It is an compiler error. If n is a dynamic signal like in my
case, you must use n as in a condition for 'if' statement. If you
don't believe, try to compile it using any VHDL compiler.


I have demand you if pci type (32-b and 64-b) can be dynamically change,

you haven't answer.
So I give you an example where n is constant.

Reread my question.

Don't keep only some out of context part.

Second segment of equations is right. Thank you, JaI!!! It clearly
demonstrates how hard from current VHDL structure to get both right
and efficient code.

Sorry I don't understand which second segment.

You must rewrite total code to get efficient
code!!!

If the coder have badly write his first code version, don't blam the

language.
You have the same problem with any programming language.

Before write any vhdl code line, you *must* think before about what you
want to do.
Put some comment, and perhaps that can help you to find an other way to
write the same equation.

It is a big problem when you have a big project. It is real,
not virtual. That is why 'I hate VHDL': it is like you bought a set of
sockets to start your business and found that 3/8" socket wasn't there
and the manufacturers say it is your problem, you can deal with it
using 1/2", why do we need to manufacture a 3/8" socket especially for
your purpose?!

Sorry, I don't understand your joke about socket.

Propose to your manufacturer to multiply your buying price by ten, and
see it's answer.

That is why 'orif' is so useful in the situation: first you write
correct code, then change 'elsif' to 'orif', you get your most
efficient code without any other code and structure change.


I am not convinced.

Lot of exclusive section are implementation dependant; if you want
design a reusable module, then you can do these types of assertions.
Otherwise you have a _critical_ risk in your design.

Logical equation optimizations are in synthesizer perimeter, not vhdl.
If you write clear logic equation, you can help the synthesizer; but
look the resulting netlist, the equations are not exactly the same that
you have write.

For you, what is the difference between both following notations ?

c <=a and b;

and
InstAnd : And2 (A=>a, B=>b, Y=>c); -- where And2() is a
component of which behavioral fucntion is the logical and.

For behavioral functionality, or logic simulation (with zero delay),
none. But after synthesis, you can have two different circuit.
Why ? because with And2 case, you said to synthesizer that you want
explicitely use the gate And2 model.

Take following pseudo-examples:

ExampleA:
c <= a and b;

d <= e and f;

g <= c and d;


and:

ExampleB:
InstAndC: And2(a,b,c);
InstAndD: And2(e,f,d);
InstAndG: And2(c,d,g);

After synthesis, in case ExampleA you can use 1 and gate, with 4 inputs,
to generate 'g' (and 1 and-gate delay); but for ExampleB you have 3 and
gates, with 2 inputs, to generate the same 'g' (and 2 and-gate delay).
You have the same functionnality, but not the same implementation.


JaI

 

[Weng Tianxiang]

Jim,

If you use "orif", and the synthesis tool cannot derive the mutual exclusion

"orif" is used to TELL compiler that the relating conditions are
mutually exclusive, no any doubt, do it and optimize the code for me.

The most important reason why 'orif' is suggested is currently popular
VHDL compilers are not as smart as we thought. I have used: Exemplar(1
years ago) and Xilinx(6.01), neither of them can optimize code the way
my paper suggested.

So 'orif' is used as a method to tell compiler what to do.

If 'orif' keyword is introduced, no matter how bad a VHDL compiler
code optimization technology is, you will still be guaranteed that you
get the most efficient implementation if 'orif' statements are widely
& correctly used. You may have to wait another 20 years to get all
VHDL compilers to do the smart job (at least in the last 20 years
since VHDL was introduced, you haven't met a smart VHDL compilers.
Why? it doesn't generate more money, but with risks.) After 'orif' is
introduced, you immediately get the performance advantages without
waiting for smart VHDL compilers.

I will post another message focusing on Achilles heel of Jim's
proposal assert() Monday.

Weng

 

[Weng Tianxiang]

Jim,
Now let me focus on yours assert() disadvantages.
1. Your first usage of assert() is wrong!

assert onehot(ASel & BSel & CSel & DSel) ... ;

Ex2 : process
begin
wait until Clk='1' ;
if ASel = '1' then
Y <= A ;
elsif BSel = '1' then
Y <= B ;
elsif CSel = '1' then
Y <= C ;
elsif DSel = '1' then
Y <= D;
end if ;
end process ;

It should look like this:
Ex2 : process
begin
wait until Clk='1' ;
assert onehot(ASel & BSel & CSel & DSel) <--- !!!
if ASel = '1' then
Y <= A ;
elsif BSel = '1' then
Y <= B ;
elsif CSel = '1' then
Y <= C ;
elsif DSel = '1' then
Y <= D;
end if ;
end process ;

2. You must put an assert statement after clock edge statement to
correctly detect and report an error.
3. You must put an assert statement in a process() anywhere if 'orif'
statements are used. Otherwise you cannot correctly detect and report
an error.
4. You must define a new name for any conditions in 'if' or 'elsif'
statements that contain more than one signal before any assert
statement can be called;
5. If you are trying to let simulator to detect & report error
condition without each special calling, you create an unprecedented
language element that violates the principle rule of any languages:
first declare it, then it is legally to be used.
6. Your onehot name is misleading. Why? The following example tells
that a condition can represent many states:
type nCSStateType is (nCSIdle_S,
nCS0_S, nCS1_S, nCS2_S, nCS3_S,
nCS4_S, nCS5_S, nCS6_S, nCS7_S,
nCS8_S, nCS9_S, nCS10_S, nCS11_S,
nCS12_S, nCS13_S, nCS14_S, nCS15_S,
nCS16_S, nCS17_S, nCS18_S, nCS19_S,
nCS20_S, nCS21_S, nCS22_S, nCS23_S,
nCS24_S, nCS25_S, nCS26_S, nCS27_S,
nCS28_S, nCS29_S, nCS30_S, nCS31_S
);

signal nCSState : nCSStateType;
if(nCSState /= nCSIdle_S)

nCSState /= nCSIdle_S represents 32 states in the above state machine.
it is a statement from my design.
7. I have declared a new keyword 'exclusive' that is used to declare
group of signals and state machines they are mutually exclusive. It is
declared once, and it is valid globally, but in definition area.
8. 'exclusive' and 'orif' provide two complementary methods to tell
compiler the information of mutually exclusive. One is global in an
entity, another local.
9. You are the man to first suggest to introduce 'errels' after
'orif'. I wrote your idea into my paper not because of its necessity,
but with the purpose to soothe somebody's scare that if no error
detection mechanism, my 'orif' idea may be too 'danger'. The real and
easier solution is very simple:
VHDL committee mandates 'if 'orif' or 'exclusive' statements are
called, any simulation tools must report any conflicting error
situations like the way currently commonly and widely used by any
simulators when many sources drive one bit'.
When many sources driver one bit, designers don't have to write
special code to tell simulators to tell if they are wrong.
Doing so will relieve all designers from writing all unnecessary
assert or 'errels' to detect errors.

Amy comments are welcome.

Weng

 

[Jim Lewis]

Weng,

1. Your first usage of assert() is wrong!
2. You must put an assert statement after clock edge statement to
correctly detect and report an error.

I agree. The way this circuit works, the assertion must
be re-written so that it only evaluates on the active
edge of clock. Going in a process, like you
show, is one possibility.

The other possibility is to have an assertion that only
evaluates its condition at the active edge of a particular
clock. This capability will be part of VHDL when PSL is
integrated (planned as part of VHDL-200X fast track).

3. You must put an assert statement in a process() anywhere if 'orif'
statements are used. Otherwise you cannot correctly detect and report
an error.

Disagree. See 2 above. The specification of onehot
with a PSL clocked assertion is much more like your
exclusive statement that you state below.

Also note that most signals that I have worked with are
always mutually exclusive, so checking for mutual exclusion
in a particular branch of an if statement is not necessary.

With assert, the mutual exclusion is specified once.

With orif, mutual exclusion is specified each time you
use the expression. If there are nested if statements,
the mutual exclusion must be specified multiple times
(most likely to occur in a statemachine).
If the mutual exclusion is specified correctly
9 out of 10 times in a nested if statement (accidently used
elsif instead of orif one time), how will you
detect the issue (not error because it is really only
a logic simplification)?

4. You must define a new name for any conditions in 'if' or 'elsif'
statements that contain more than one signal before any assert
statement can be called;
Exactly. Show me a relevant example that you are

concerned about. Here is one, CS is active and
both Write and Read are asserted. Note however,
this is a simple one to write with PSL.

7. I have declared a new keyword 'exclusive' that is used to declare
group of signals and state machines they are mutually exclusive. It is
declared once, and it is valid globally, but in definition area.
8. 'exclusive' and 'orif' provide two complementary methods to tell
compiler the information of mutually exclusive. One is global in an
entity, another local.
9. You are the man to first suggest to introduce 'errels' after
'orif'. I wrote your idea into my paper not because of its necessity,
but with the purpose to soothe somebody's scare that if no error
detection mechanism, my 'orif' idea may be too 'danger'. The real and
easier solution is very simple:
VHDL committee mandates 'if 'orif' or 'exclusive' statements are
called, any simulation tools must report any conflicting error
situations like the way currently commonly and widely used by any
simulators when many sources drive one bit'.
When many sources driver one bit, designers don't have to write
special code to tell simulators to tell if they are wrong.
Doing so will relieve all designers from writing all unnecessary
assert or 'errels' to detect errors.

Amy comments are welcome.

If exclusive makes errels not necessary, then "orif"
contains redundant information and hence is not
necessary.

All restrictions imposed on checking onehot also
apply to exclusive. Hence, with exclusive you must
specify a clock. This makes it a reduced form of
an assertion (what PSL provides).

Hence, my advice is for you to learn PSL. It is planned
to be integrated into VHDL in the next revision and
will provide much greater functionality than your
proposed exclusive.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Just an Illusion]

Hi Weng,

Weng Tianxiang wrote:
<snip>

When many sources driver one bit, designers don't have to write
special code to tell simulators to tell if they are wrong.

In case of multidriving signal, you must be sure that only one value is

given at a time (possible by many drivers, but the same).
If not, a warning (possible an error) must be given, because if compiler
conclude that two differents values can be set at same time, that can be
because you have an error.

If your proposal hide this, you can recover this problem in a later step
of developpement; and in this case, it can be very hard to find the true
origin. It is time consuming, and money cost.

Doing so will relieve all designers from writing all unnecessary
assert or 'errels' to detect errors.

Amy comments are welcome.

Weng

 

[Just an Illusion]

Hi Jim, Weng,

Hence, my advice is for you to learn PSL. It is planned
to be integrated into VHDL in the next revision and
will provide much greater functionality than your
proposed exclusive.

psl is an assertion language to define formal properties.
I don't think that psl can be use to drive simulation or synthesis. The
psl must drive formal validation engines.

Why psl can't be use for simulation ?
In psl, you can write what is must be, but what you mustn't too.
Simulation test only what the design can do, not more.
If you put an assert (generally to trace an unexpected behavior), and if
you find the trace in your simulation. It is because you have an error.
Some time, you have no assert generation, because your test cases are
not enough.

Take the following example: you have a fifo of 1k element, this fifo
have an error because it erase the begining of fifo data when the fifo
is full, and an input is add.
You use this fifo into a system, which require only 512 elements from
the fifo. You can do all your simulations without any error (and any
assert).
Formal validation can point you the weak of the fifo, not simulation.

Why psl can't be use for synthesis ?
Some psl properties can be help for reduce a little some logic
equations, but in general you describe some 'trace' or 'scenario' and
that is not usefull for synthesis.
Example:
If you have a handshake protocol: {REQ,*,ACK} => after a request you
must have an acknowledge

Could you tell me how you can use this property to drive synthesizer ?

Rgrds,
JaI

 

[Jim Lewis]

Hence, my advice is for you to learn PSL. It is planned
to be integrated into VHDL in the next revision and
will provide much greater functionality than your
proposed exclusive.


psl is an assertion language to define formal properties.
I don't think that psl can be use to drive simulation or synthesis. The
psl must drive formal validation engines.
Deja PSL.

It is already part of simulators and some synthesis
tools. It is not about what you can't do with
something, it is about what you can do and the motivation
for doing so.

In simulation, PSL is being used both to signal when
an error condition has occurred and help indicate
where the issue is (ie: the agreed upon interface
spec has been violated).

In synthesis, we have attributes that
allow us to express when two signals are mutually
exclusive. This is nice, but the real problem
is that nothing validates this claim. By making
a limited number of assertions synthesizable
(perhaps it is only onehot), then the claim can be
verified in the simulator. I agree this has the
limitation if I write incomplete tests, however,
it is better than no testing at all. In addition,
given a formal tool with enough capacity, by using
PSL I can also prove it to be correct. If we make
it so that all tools understand the same language
(such as PSL) then we can minimize the chance
of an error sneaking through.

Why psl can't be use for simulation ?
In psl, you can write what is must be, but what you mustn't too.
Simulation test only what the design can do, not more.
If you put an assert (generally to trace an unexpected behavior), and if
you find the trace in your simulation. It is because you have an error.
Some time, you have no assert generation, because your test cases are
not enough.
And if you don't put in an assertion and the error never

propagates to the outputs during the lifetime of your
test, then what? If you check your simulation
coverage you will probably find that you covered the
case you were worried about.

Take the following example: you have a fifo of 1k element, this fifo
have an error because it erase the begining of fifo data when the fifo
is full, and an input is add.
You use this fifo into a system, which require only 512 elements from
the fifo. You can do all your simulations without any error (and any
assert).
Formal validation can point you the weak of the fifo, not simulation.
Agreed. Some things are difficult to find in simulation.

Hence the motivation to do formal.

Why psl can't be use for synthesis ?
Some psl properties can be help for reduce a little some logic
equations, but in general you describe some 'trace' or 'scenario' and
that is not usefull for synthesis.
Example:
If you have a handshake protocol: {REQ,*,ACK} => after a request you
must have an acknowledge
Using your reasoning, no HDL can be used for synthesis

because I can write some HDL code that is not
synthesizable. However, this is not the case because we
have defined "coding styles" that translate to the
appropriate hardware structure.

Priority vs. mutual exclusion is a problem encountered
by any programming language when trying to describe/
implement hardware. Using language elements or assertions
to convey that code written with if then elsif, elsif, ...
is really mutually exclusive can be result in a hardware
savings with greater readability than code written otherwise.

My expectation is that most assertions will be ignored by
synthesis, but a few, such as one that conveys mutual
exclusion will be synthesizable.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Ken Smith]

In article <10e309llhjf87fa@corp.supernews.com>,
Jim Lewis <Jim@SynthWorks.com> wrote:
[...]

is that nothing validates this claim. By making
a limited number of assertions synthesizable
(perhaps it is only onehot), then the claim can be
verified in the simulator. I agree this has the
limitation if I write incomplete tests, however,

I'm joining this argument late and am far from an expert but it seems to
me that this is the hard way to get where we want to go. It seems simpler
to me to be able to do something like this:

process (SomeStd_logic_vector) begin
if 1 = HowManyHigh(SomeStd_logic_vector) then
-- prehaps nothing here
else
assert-it-is-broken;
end if;
end process;


The Sim. can implement the real assert. The Synth can make everything a
don't care in the asserted state. The advantage is that the language
designers don't have to know about my "3.5 hot" state machine that I'm
just about to patent but I can still test that it is going to work right.

--
--
kensmith@rahul.net forging knowledge

 

[Weng Tianxiang]

Jim,

By making a limited number of assertions synthesizable (perhaps it is only onehot)

I don't really see where your assert() is simpler than my new keyword:
'exclusive' with misleading name 'onehot'.

You want to change non-synthesizable statement assert() to a statement
sometimes synthesizable, and sometimes non-synthesizable with long
typing
'assert onehot(A1, A2, A3) report "failed" severity failure ;'

and calling 'psl' language?

Tell me what advantages of your assert() is over my keyword
'exclusive'.

If I am confused, I don't know how many would be consufed.

exclusive (A1, A2, A3);

In my paper, 'exclusive' is 2nd class of new keywords I suggested than
'orif'. It is suggested to be used for among state machines and other
non-derivative mutually exclusive signals.

I will tell you why 'orif' is better than 'exclusive' in most of time
in examples next time.

Weng

 

[Jim Lewis]

Weng,

Tell me what advantages of your assert() is over my keyword
'exclusive'.

If I am confused, I don't know how many would be consufed.

exclusive (A1, A2, A3);

Semantically both are the same. Don't forget that you need

to add syntax to tell exclusive to operate only at a specific
edge of a specific clock.

From a language designer perspective, PSL (assertions)
are already being integrated (separate standard) with
VHDL. EDA vendors are starting to support it.

So it is a simple matter learning the syntax and using it
rather than adding a new language feature. Note that
anytime a new keyword is added to the language there
is the possibility that the keyword will conflict with
an identifier existing code.

I will tell you why 'orif' is better than 'exclusive'
in most of time in examples next time.
A good long example would most helpful.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Weng Tianxiang]

Jim,

Don't forget that you need to add syntax to tell exclusive to operate only at a specific edge of a specific clock.

It is not true for 'exclusive' to indicate clock and its edges.

1. When one declares that two signals are exclusive, they must be
registered at the same clock, but not necessary at the same edge. So
clock name is not needed; Under different clocks even two signals
cannot be reliably compared, not mention their exclusive conditions.
So it is a logic error if two signals registered under two different
clocks are declared as mutually exclusive in 'exclusive'.

2. If signals claimed in 'exclusive' are registered under different
edges, it is OK when they are involved in any special edge.

3. When signals claimed in 'exclusive' statements are involved in a
'if..elsif..endif', the clock and its edge is clear.

So when keyword 'exclusive' is used, clock and edge type are redundant
information. There is no any need to include them. It is like to use
'=' operator to compare two signals registered under two different
clocks, it is legal, but most of time it is wrong. VHDL specs never
prohibit '=' operator used for two 32-bit addresses registered under
two different clocks.

Note that anytime a new keyword is added to the language there is the possibility that the keyword will conflict with an
identifier existing code.

This is another wrong assumption with either 'exclusive' or 'orif'. If
you put following 'exclusive' statement at the declare area, it is an
error now! 'exclusive' equals to 'signal'!

exclusive (A1, A2, A3);

If you put 'orif' at 'elsif' places, no matter what you have declared,
it is an error now!

I would like to clear any misunderstanding of new keywords if any you
still have.

Weng

 

[Jim Lewis]

Weng,

1. When one declares that two signals are exclusive,
they must be registered at the same clock, ...

Mutually exclusive RTL signals may overlap when they
are changing if one has more delta cycles than another.
Hence, somehow an eda tool must have a way to determine
when this overlap is a failure and when this overlap
is irrelevant. An easy way to do this is for the
construct to specify the relevant edge of the
clock.

I suppose alternately you could expect the tool to
do this. Of course this would mean it would need to
trace from the logic to all the registers in the
logic cone and check the constraint there. What
if the register is in a separate logic block?

Note that anytime a new keyword is added to the language there is the possibility that the keyword will conflict with an
identifier existing code.

This is another wrong assumption with either 'exclusive' or 'orif'.

If someone currently has this in their code:
signal exclusive : std_logic ;

and I add exclusive as a keyword to the language,
then their code will no longer compile and they
must change their signal name.


Still waiting patiently for your more extensive
"orif" examples.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Weng Tianxiang]

Jim,

Mutually exclusive RTL signals may overlap when
they are changing if one has more delta cycles
than another.

Mutually exclusive case happen when
1. with different clock marks;
2. with one wire of different values;
3. derivated from 'if..elsif..end' statements;
4. with physical limit: like reading vs. writing, ...; Memory_1G vs.
Memory_2G, ...;

In my mind, there is no boundary to check for mutually exclusive. If
they have a overlap, it is not 'exclusive' error or 'orif' error, it
is other factors and you cannot blame them like you cannot blame '='
operator when your running frequency is not high enogh to cause
overlap of two signals. As you know all signals involved must be
setteld down before setup time ahead of clock edges and cannot change
until hold time after clock edge.

If someone currently has this in their code:
signal exclusive : std_logic ;

OK, no any problem for an existing design:

signal exclusive : std_logic ;
exclusive (A1, A2);

The above two statements can be co-exist without any problem.
The first 'exclusive' is declared as a signal, it can be used later as
normal signal;
The second 'exclusive' is a mutual exclusive declaration. It can be
recognized by compiler without any confusion with first one if you
have some knowledge of how compiler is built, especially when
'exclusive' is added later into VHDL:
the first one 'exclusive' is put into signal name list & see if there
are any violations, the second is searched for in the keyword list, so
they are at totally different list area, leading to two different
reaction of compiler.

Beyond declaration area, 'exclusive' will be recognized as signal name
as usual without any special treatments.

'orif' is at the same situation as above. They will be searched for in
keyword list as 'elsif'.

Weng

 

[Jim Lewis]

Weng,

Mutually exclusive RTL signals may overlap when
they are changing if one has more delta cycles
than another.


Mutually exclusive case happen when
1. with different clock marks;
2. with one wire of different values;
3. derivated from 'if..elsif..end' statements;
4. with physical limit: like reading vs. writing, ...; Memory_1G vs.
Memory_2G, ...;

In my mind, there is no boundary to check for mutually exclusive. If
they have a overlap, it is not 'exclusive' error or 'orif' error,

For: exclusive (A1, A2);
The key to the issue is when does exclusive check
for mutual exclusion:
1) On changes of A1 and A2
2) When either A1 or A2 is read?
3) At a specified condition


#2 is problematic. When either A1 or A2 is read?
What if they are read in a process that does
not include clock? Do you propagate the check
to the clock at which the cone of logic terminates?
What should happen when A1 is read,
but the cone of logic does not include A2, does
the check for mutual exclusion get executed or not?
Propagating the check can be very sophisticated and
would be a capability beyond what current simulators
do. A simplistic check (when A1 or A2 are read)
can quickly devolve to #1. Also the check could be
different for different implementations of the logic.

Note I don't think the level of sophistication here
is impossible to solve, but I do think that with
simple extensions of the notation (and a very minor
burden on the coder) that the problem can be easy
to solve. Hence, I would rather add the little
extra code myself and have the EDA vendors solve
other problems.


#1 is problematic. Consider the following example.
Are Y1 and Y3 mutually exclusive?
Y1 <= '1' when A = '1' else '0' ;
Y2 <= '1' when A /= '1' else '0' ;
Y3 <= Y2 ;

In an RTL simulation, Y1 and Y2 are aligned in time and
mutually exclusive. Y3 is delayed by a delta cycle from
Y2 and hence it will have overlay with Y1 in time.
Are Y1 and Y3 mutually exclusive? Going further, in
gate implementations, it is common for rise and fall
times to differ and as a result, it would not be
uncommon for Y1 and Y2 to overlap.

This overlap is ok when it is sampled by a clock because
if A is synchonized to the same clock, then the overlap
will not occur at the clock boundry.

This overlap is usually not ok when Y1 and Y2 are used
to drive competing tristate drivers:

In Block 1:
DataBus <= Block1Data when Y1 = '1' else (others => 'Z") ;

In Block 2:
DataBus <= Block2Data when Y2 = '1' else (others => 'Z") ;


#3 is a potential solution. Extend the syntax to permit
the condition under which to evaluate the mutual exclusion
to be specified. Typically this would be a clock.
If you were to extend exclusive to understand clock,
then I think the solution would be more workable,
however, it would be identical to capabilities
provided by PSL. Note there is also OVL that may provide
similar capabilities.


So your suggestion is not being ignored, it is just
being solved another way. This is the nature of
standards efforts, you don't always get exactly what
you had ideally wanted, but you usually get something
that solves your problem.

If someone currently has this in their code:
signal exclusive : std_logic ;


OK, no any problem for an existing design:

signal exclusive : std_logic ;
exclusive (A1, A2);

The above two statements can be co-exist without any problem.
The current VHDL language design does not permit this.

To change this violate the spirit of VHDL.

Going further, for vhdl-200x-mp effort, I will be writing
an analysis of this issue. I would be interested
to see a more extensive "orif" example as it would give
me some insight to understand why you like "orif".
Further arguments about the merits of exclusive or
arguments about orif without examples are not going
to help.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Just an Illusion]

Hi Weng

Weng Tianxiang wrote:

snip

4. with physical limit: like reading vs. writing, ...; Memory_1G vs.
Memory_2G, ...;



Sorry but example of read vs. write is not a good example, remember case

of double access ram, where you can have a read and a write access
simultaneously.
More, lot of example have 2 different lines, one for read and another
for write; even if only one must be active at a time.

Weng


JaI

 

[Weng Tianxiang]

JaI,

Sorry but example of read vs. write is not a good example, remember case
of double access ram, where you can have a read and a write access
simultaneously.

If you don't know something, it is better to keep quite and stand
aside to learn.

Tell me what kind of double access ram working in a way a read and a
write access happen simultaneously.

Weng

 

[Just an Illusion]

Hi Weng,

Weng Tianxiang wrote:

JaI,


Sorry but example of read vs. write is not a good example, remember case
of double access ram, where you can have a read and a write access
simultaneously.



If you don't know something, it is better to keep quite and stand
aside to learn.


You are not the only people which made design, so be quiet.

Tell me what kind of double access ram working in a way a read and a
write access happen simultaneously.


Fifo between two different clock domains is the most classical case.

Read and write are fully independant, and can be done simultaneously.

It is not because you don't do it that nobody does.

Weng


JaI

 

[Weng Tianxiang]

Jim,

For: exclusive (A1, A2);
The key to the issue is when does exclusive check
for mutual exclusion:
1) On changes of A1 and A2
2) When either A1 or A2 is read?
3) At a specified condition

My algorithm may not be the best, but it clears things up.
1. Find where (A1, A2) signals appear on conditions of
'if..elsif..end', record their lines like the following:
(A1, A2): line 1001, 1330, ...
2. At the last delta time, every signals are stable, test if A1, A2
are both true, if so, output error information:
(A1, A2): violates mutually exclusive conditions at line 1001, 1330,
....

exclusive (A1, A2);
1. exclusive name is seldom used;
2. it has not effects on all old design done before 'exclusive' is
introduced. It affects only later new design. New design cannot use
'exclusive' as a signal name. It doesn't violate VHDL spirit.
3. If you must include old part of design that contains 'exclusive'
name, change it. Because old version has to be changed to include any
new VHDL benefits.

Weng