VHDL Standards Progress Report

[Jim Lewis]

IEEE VHDL Analysis and Standardization Group (VASG) is the
IEEE working group responsible for maintaining and extending
the VHDL standard (IEEE 1076). Currently VASG is collaborating
with the Accellera VHDL Technical Subcommittee (VHDL TSC) to
accomplish this task.

I have just updated the VASG webpage updates regarding
status of VHDL standards revisions (both within Accellera
and IEEE). For details see: http://www.eda-stds.org/vasg
The older page, http://www.eda-stds.org/vhdl-200x/
has been merged with the vasg page.
Note also that any of the following domains are aliases to
the same information: eda.org, eda-stds.org, vhdl.org


I will also summarize (or restate) the status below:


_VHDL + VHPI_
On June 28, 2006 Accellera board approved a revision of
1076 that includes VHDL + VHPI (VHDL Procedural Language
Application Interface) + minor LRM maintence. Currently
this draft is working its way through IEEE standardization.


_VHDL + VHPI + VHDL-200X/VHDL-200X-FT + additional enhancements_
At DAC 2006 the Accellera board approved an enhanced
revision of 1076 that is VHDL + VHPI + enhancements.
The IEEE VASG started the work in early 2003 as VHDL-200X.
The Accellera VHDL Technical Subcommittee took over the
work in 2005, funded its technical editing, and did
super-human work to finalize it. In the near future
an Accellera press release will announce this
accomplishment.

As an Accellera standard, this version is available
for industry adoption - so let your vendors know you
want it. In fact, the claim is that since Accellera
standards are user driven, vendors are more willing to
implement the standard features since they know the
features are things desired and requested by users.
This was demonstrated in the implementation of
SystemVerilog (which started as an Accellera
standard).

I will be presenting a paper at Mentor's MARLUG on
October 12th that details the changes. After that
date the slides will be available at:
http://www.synthworks.com/papers/

Currently there are some older papers on that webpage
that reflect the intent at the time they were written.


_Accellera VHDL 2007_
The Accellera VHDL TSC is continuing its work to
enhance VHDL. Current items being worked on include
constrained random, coverage, OO, interfaces, and
verification data structures (associative arrays,
memories, ...). When this work is completed, it
will give VHDL similar verification capability to
SystemVerilog.


Join us and help create the next VHDL standards.
Your support (either financial or participation or both)
is greatly appreciated. For details see:
http://www.eda-stds.org/vasg/#Participation


By the way, if you have not checked the Accellera webpage
recently, you will notice that VHDL is also listed
prominently on the home page. See:
http://www.accellera.org/home


Best Regards,
Jim Lewis
IEEE VASG Chair
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

 

[Hans]

Thanks Jim,

It is good to see that VHDL is still actively being worked on,

Regards,
Hans.
www.ht-lab.com

 

[Weng Tianxiang]

IEEE VHDL Analysis and Standardization Group (VASG) is the
IEEE working group responsible for maintaining and extending
the VHDL standard (IEEE 1076). Currently VASG is collaborating
with the Accellera VHDL Technical Subcommittee (VHDL TSC) to
accomplish this task.

I have just updated the VASG webpage updates regarding
status of VHDL standards revisions (both within Accellera
and IEEE). For details see: http://www.eda-stds.org/vasg
The older page, http://www.eda-stds.org/vhdl-200x/
has been merged with the vasg page.
Note also that any of the following domains are aliases to
the same information: eda.org, eda-stds.org, vhdl.org


I will also summarize (or restate) the status below:


_VHDL + VHPI_
On June 28, 2006 Accellera board approved a revision of
1076 that includes VHDL + VHPI (VHDL Procedural Language
Application Interface) + minor LRM maintence. Currently
this draft is working its way through IEEE standardization.


_VHDL + VHPI + VHDL-200X/VHDL-200X-FT + additional enhancements_
At DAC 2006 the Accellera board approved an enhanced
revision of 1076 that is VHDL + VHPI + enhancements.
The IEEE VASG started the work in early 2003 as VHDL-200X.
The Accellera VHDL Technical Subcommittee took over the
work in 2005, funded its technical editing, and did
super-human work to finalize it. In the near future
an Accellera press release will announce this
accomplishment.

As an Accellera standard, this version is available
for industry adoption - so let your vendors know you
want it. In fact, the claim is that since Accellera
standards are user driven, vendors are more willing to
implement the standard features since they know the
features are things desired and requested by users.
This was demonstrated in the implementation of
SystemVerilog (which started as an Accellera
standard).

I will be presenting a paper at Mentor's MARLUG on
October 12th that details the changes. After that
date the slides will be available at:
http://www.synthworks.com/papers/

Currently there are some older papers on that webpage
that reflect the intent at the time they were written.


_Accellera VHDL 2007_
The Accellera VHDL TSC is continuing its work to
enhance VHDL. Current items being worked on include
constrained random, coverage, OO, interfaces, and
verification data structures (associative arrays,
memories, ...). When this work is completed, it
will give VHDL similar verification capability to
SystemVerilog.


Join us and help create the next VHDL standards.
Your support (either financial or participation or both)
is greatly appreciated. For details see:
http://www.eda-stds.org/vasg/#Participation


By the way, if you have not checked the Accellera webpage
recently, you will notice that VHDL is also listed
prominently on the home page. See:
http://www.accellera.org/home


Best Regards,
Jim Lewis
IEEE VASG Chair
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

Hi Jim,
Congraduation! Now you are chairman of the committee.

How about keyword "elsor" keyword?

At that time, you recommended me to contact a person who had the power
to do that while you were not in the committee. I didn't contacted the
person because I didn't like to do that: it would be beneficial to
every engineer in VHDL and Verilog circuit.

And last time we talked through the google about the introduction and
you nad many new ideas and we agured a lot, finally you asked me to
post most daunting design that used the technology and I posed the
design and after that I never heared your answer.

Thank you.

Weng

 

[David Ashley]

How about keyword "elsor" keyword?

How would you use it? I'm reminded of perl's "unless"
keyword .

-Dave

 

[Jim Lewis]

Weng,
What I remember is that for simple examples, elsor
works fine, however, for examples of the complexity
for which you posted it is very difficult if not
impossible to extract enough information to address your
issue.

On the other hand, an alternate consideration is to
have assertions that express mutual exclusion. For
example:

assert zero_one_hot(A_LE & B_LE & C_LE & D_LE)
report "%%%BUG: Mutual exclusion failed in design ..."
severity error ;


-- Looking forward and using new syntax introduced by
-- the Accellera VHDL 2006 revision
Reg4LeProc : process(Clk)
begin
if rising_edge(Clk) then
if A_LE then
Reg4Le <= A ;

elsif B_LE and AddrB ?= 15 then
Reg4LE <= B ;

elsif C_LE and AddrC ?= 14 then
Reg4LE <= C;

elsif D_LE then
Reg4Le <= D ;
end if ;
end if ;
end process ;


The alternate solution simplifies the expression of
the relationship between A_LE, B_LE, C_LE and D_LE.
It only requires a standardized function zero_one_hot
that is visible in the VHDL context. I will have to
do some searchin, but I think there is already something
like this in PSL (which was incorporated by reference -
however - I don't think the function is visible outside
of a PSL statement - yet).


So the steps to finializing the alternate solution are to
standardize a version of zero_one_hot (hopefully one that
is compatible with PSL) and revise 1076.6 to say vendors
should support this style of coding.

> Congratulation! Now you are chairman of the committee.

Yes, but I am chair of the group doing the administrative
work of making the revision a standard. The Accellera
VHDL TSC is doing all of the heavy lifting the next
revision (and perhaps more). In the Accellera group,
I am just an active member.


Cheers,
Jim

Hi Jim,
Congraduation! Now you are chairman of the committee.

How about keyword "elsor" keyword?

At that time, you recommended me to contact a person who had the power
to do that while you were not in the committee. I didn't contacted the
person because I didn't like to do that: it would be beneficial to
every engineer in VHDL and Verilog circuit.

And last time we talked through the google about the introduction and
you nad many new ideas and we agured a lot, finally you asked me to
post most daunting design that used the technology and I posed the
design and after that I never heared your answer.

Thank you.

Weng

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

 

[Amal]

As an Accellera standard, this version is available
for industry adoption - so let your vendors know you
want it.

I am already anxious for vendors to start implementing it. I just feel
that there has been a lot of support on the SystemVerilog side and
pushing it faster than VHDL.

_Accellera VHDL 2007_
The Accellera VHDL TSC is continuing its work to
enhance VHDL. Current items being worked on include
constrained random, coverage, OO, interfaces, and
verification data structures (associative arrays,
memories, ...). When this work is completed, it
will give VHDL similar verification capability to
SystemVerilog.

SystemVerilog brought most features already available to VHDL to
Verilog users and a lot more with support of vendors and the industry.
As a VHDL user, I just feel left behind and overwhelmed with the amount
of support for SystemVerilog and I feel that the activities on the VHDL
front have been very slow compared to SystemVerilog.

Although I thank everyone involved for completing the standard and I
hope that vendor support is coming sooner than later.
-- Amal

 

[Jim Lewis]

Amal,

I am already anxious for vendors to start implementing it. I just feel
that there has been a lot of support on the SystemVerilog side and
pushing it faster than VHDL.

For a vendor, implementing anything is a business investment.
The more interest they get from their users, the more quickly
they will implement it.

The claim for rapid implementation of SystemVerilog is that
it was a user driven standard. This VHDL effort followed the
same process, so it should enjoy the same rapid implementation.

SystemVerilog brought most features already available to VHDL to
Verilog users and a lot more with support of vendors and the industry.
As a VHDL user, I just feel left behind and overwhelmed with the amount
of support for SystemVerilog and I feel that the activities on the VHDL
front have been very slow compared to SystemVerilog.

Some of that is marketing propaganda. Some vendors just recently
implemented the OO features of SystemVerilog. The challenge for
the Accellera VHDL TSC will be to have the OO, constrained random,
interfaces, ... features for DAC 07.

Although I thank everyone involved for completing the standard and I
hope that vendor support is coming sooner than later.

Me too. Given that it is Accellera uses user driven process,
there is no reason why vendors would not already be working on it.
However, compell them further by letting them know your interest
in the standard.

Going further, it would also be helpful to get additional
organizations to join Accellera and help fund the effort.
See http://www.accellera.org/activities/vhdl/

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

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

 

[Amal]

The challenge for the Accellera VHDL TSC will be to
have the OO, constrained random, interfaces, ...
features for DAC 07.

Do you have any insight or documents for public view on these subjects,
especially OO?

Going further, it would also be helpful to get additional
organizations to join Accellera and help fund the effort.
See http://www.accellera.org/activities/vhdl/

How can individual VHDL users help?

-- Amal

 

[Jim Lewis]

Amal

Do you have any insight or documents for public view on these subjects,
especially OO?

Too soon yet.

How can individual VHDL users help?

Join Accellera - even as a non-member. Participate
in the VHDL subgroups - particularly the requirements
group. This helps determine what is important to users.

The other groups require more experience, but if you have
it and you can contribute to writing details of enhancements or
LRM modifications. Generally things go best when someone
with a vested interest in a proposal works on it.

Best Regards,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

 

[Hans]

I am already anxious for vendors to start implementing it. I just feel
that there has been a lot of support on the SystemVerilog side and
pushing it faster than VHDL.

That is not because of the language itself but simply because
SystemVerilog/SystemC support essential verification methodologies like
Transaction Level Modelling, Constraint Random Verification and Functional
Coverage. There is absolutely no reason to abandon VHDL since it is still a
very capable RTL language. However, if you have to develop an all singing
all dancing testbench or you want to do some behaviour modelling of your
system you definitely don't want to use VHDL/Verilog but instead use a
language that support the above techniques.

It is also true that most EDA tools (at least Modelsim) can mix these
languages at any level of the hierarchy seamlessly without you having to
worry about any interface issues. Thus you can use VHDL for your DUT and say
SystemC for your testbench and SVA for your assertions.

It is questionable if the EDA industry needs an OO-VHDL given that
SystemC/SystemVerilog can be used so effectively with VHDL and have already
such a headstart. However, what is very cool of the VHDL-2006 standard is
the inclusion of PSL. This is IMHO the best addition to the language and can
make a serious impact on the quality of your verification (assuming you use
it properly , the only stumble block which is seriously hampering the
uptake of this language is the high price EDA vendors are charging for it.

Hans
www.ht-lab.com

 

[Weng Tianxiang]

How would you use it? I'm reminded of perl's "unless"
keyword .

-Dave

Hi David,
Please leave your email address, I would like to send the paper to you
through an email.

Weng

 

[Weng Tianxiang]

Weng,
What I remember is that for simple examples, elsor
works fine, however, for examples of the complexity
for which you posted it is very difficult if not
impossible to extract enough information to address your
issue.

On the other hand, an alternate consideration is to
have assertions that express mutual exclusion. For
example:

assert zero_one_hot(A_LE & B_LE & C_LE & D_LE)
report "%%%BUG: Mutual exclusion failed in design ..."
severity error ;


-- Looking forward and using new syntax introduced by
-- the Accellera VHDL 2006 revision
Reg4LeProc : process(Clk)
begin
if rising_edge(Clk) then
if A_LE then
Reg4Le <= A ;

elsif B_LE and AddrB ?= 15 then
Reg4LE <= B ;

elsif C_LE and AddrC ?= 14 then
Reg4LE <= C;

elsif D_LE then
Reg4Le <= D ;
end if ;
end if ;
end process ;


The alternate solution simplifies the expression of
the relationship between A_LE, B_LE, C_LE and D_LE.
It only requires a standardized function zero_one_hot
that is visible in the VHDL context. I will have to
do some searchin, but I think there is already something
like this in PSL (which was incorporated by reference -
however - I don't think the function is visible outside
of a PSL statement - yet).


So the steps to finializing the alternate solution are to
standardize a version of zero_one_hot (hopefully one that
is compatible with PSL) and revise 1076.6 to say vendors
should support this style of coding.


Yes, but I am chair of the group doing the administrative
work of making the revision a standard. The Accellera
VHDL TSC is doing all of the heavy lifting the next
revision (and perhaps more). In the Accellera group,
I am just an active member.


Cheers,
Jim




--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

Hi Jim,
We had argured a lot 2 years ago and you mentioned several
modifications and I indicated all shortcomings with each of your
modifications.

assert zero_one_hot(A_LE & B_LE & C_LE & D_LE)
report "%%%BUG: Mutual exclusion failed in design ..."
severity error ;

Reg4LeProc : process(Clk)
begin
if rising_edge(Clk) then
if A_LE then
Reg4Le <= A ;

elsif B_LE and AddrB ?= 15 then
Reg4LE <= B ;

elsif C_LE and AddrC ?= 14 then
Reg4LE <= C;

elsif D_LE then
Reg4Le <= D ;
end if ;
end if ;
end process ;

My version of equation will look like this way:
Reg4LeProc : process(Clk)
begin
if rising_edge(Clk) then
if A_LE then
Reg4Le <= A ;

-- this condition, no matter how complex it is, is mutually exclusive
with A_LE
ORIF( B_LE ... ) then
Reg4LE <= B ;

-- this condition is mutually exclusive with above two conditions
ORIF( C_LE ... ) then
Reg4LE <= C;

-- this conditions are as normal in grammar
elsif D_LE then
Reg4Le <= D ;
end if ;
end if ;
end process ;

As a vhdl programmer, we know well which conditions are mutually
exclusive and ORIF keyword will give a concise keyword to express the
mutually exclusive conditions.

As a rule in my paper, I indicate that all data registers or counters,
if there are more than 1 enable conditions, all those conditions are
mutually exclusive if they are programmed correctly. Do you agree with
me?

One may see how many situations will refer to mutually exclusive
situations!!!

How important it is to have a very concise keyword to express the
situations!!!

Weng

 

[David Ashley]

Please leave your email address, I would like to send the paper to you
through an email.

Weng

1 is dash
Well it's not exactly a secret since visiting my site would uncover
it pretty quickly. I'm 1@2.
2 is xdr.com

-Dave

 

[Jim Lewis]

Hans,

That is not because of the language itself but simply because
SystemVerilog/SystemC support essential verification methodologies like
Transaction Level Modelling, ...

Ironically VHDL already has Transaction Level Modeling capability.
I have done a paper on this (see http://www.synthworks.com/papers)
and a conference tutorial. We also teach a 3 day class based on
transaction based testbenches.

VHDL doesn't yet have OO, Constraint Random (CR) and Functional
Coverage (FC). The inclusion of PSL gives VHDL some coverage
capability. The plan is to have these ASAP. Probably by DAC 2007.

> However, if you have to develop an all singing
> all dancing testbench

What is a "all singing all dancing testbench"?
My point is can you enumerate what problems CR + FC is
going to solve better than other methods?
The answer is definitely not everything. For example
I would not expect to use CR + FC to test arithmetic
circuits. Algorithmic transaction based tests can generate
more useful cases faster than CR. With CR there is no
guarantee that you will every hit the interesting cases.
Going further generating the FC for arithmetic is going to
be as hard or harder than actually generating the algorithmic
test vectors.

Another example, for many bus interface chips that have a number
of control registers each with their own particular format, it
is going to be much easier to exercise the chip with a directed
transaction based testbench than constraining a CR testbench
to be able to understand it.

Many of the marketing claims compare a CR + FC + transaction
based testbench to a directed, non-transaction based testbench.
Not a very realistic comparison. Many of the actual benefits
to these approaches also comes from the transaction based
testbench.

So this comes back to my question, "Assuming that we are all
using transaction based testbenches, can you enumerate what
problems CR + FC is going to solve better than a other methods
(algorithmic or directed)?"

> However ... or you want to do some behaviour modelling of your
> system ...

VHDL has always been a good language for behavior modeling.

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

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

 

[Jim Lewis]

Weng,

> As a vhdl programmer, we know well which conditions are mutually
> exclusive and ORIF keyword will give a concise keyword to express the
> mutually exclusive conditions.

You are missing something important. With ORIF the following can
be determined to be mutually exclusive:
A_LE, (B_LE and AddrB ?= 15), (C_LE and AddrC ?= 14), D_LE

Which is ok, but not as powerful as saying that the following
are mutually exclusive:
A_LE, B_LE, C_LE, D_LE


Some of your examples nested if statements within case
statements. It is far eaiser for a designer to express
exactly what is mutually exclusive with an assertion than
it is with orif. It is also easier to read and maintain.
All I have to do is analyze the assert statement and make
sure I believe it correct. With ORIF a reviewer will have
to scrutinize every orif to make sure they understand the
relationships.

Repeating or rehashing the same argument is not going
to help.

Cheers,
Jim

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

 

[Weng Tianxiang]

Weng,

You are missing something important. With ORIF the following can
be determined to be mutually exclusive:
A_LE, (B_LE and AddrB ?= 15), (C_LE and AddrC ?= 14), D_LE

Which is ok, but not as powerful as saying that the following
are mutually exclusive:
A_LE, B_LE, C_LE, D_LE


Some of your examples nested if statements within case
statements. It is far eaiser for a designer to express
exactly what is mutually exclusive with an assertion than
it is with orif. It is also easier to read and maintain.
All I have to do is analyze the assert statement and make
sure I believe it correct. With ORIF a reviewer will have
to scrutinize every orif to make sure they understand the
relationships.

Repeating or rehashing the same argument is not going
to help.

Cheers,
Jim


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

Hi Jim,
I strongly disagree with your opinion again.

1. assert zero_one_hot(A_LE & B_LE & C_LE & D_LE)
report "%%%BUG: Mutual exclusion failed in design ..."
severity error ;
(I really don't know what library includes zero_one_hot().)

Can you guarantee that after the above assert statement a VHDL compiler
will use the mutually exclusive knowledge to generate shorter coding?
Try it with Xilinx VHDL compiler and see what logic is generated,
please. If you succeed, I will quit the argument and I will admit
losing the battle, otherwise, the fight will continue.

I expect that your assert statement claims nothing to any VHDL compiler
and VHDL compiler knows nothing to the assert statement and the same
logic as "if..elsif...elsif...end if" will be generated as usual.

Let fact teach me if I am wrong!!!

2. For VHDL compiler current status, all of them IGNORE assert()
statement during synthesizing period because it is really a debugging
statement used only in simulations, and VHDL compilers do not generate
any logic or retrieve any information from it at all. In other word,
your method introduces nothing to a VHLD compiler of latest version:
they are still generating "if...elsif...end if" logic even though you
introduce your method to tell them the mutually exclusive information.

3. You are introducing extra statements to generate mutually exclusive
information to a VHDL compiler and an extra burden to writing code. You
say your method is better than mine. I really don't understand why your
extra 3 statements are simpler and better than mine: When you write
assert() statement, you must weight which signals are mutually
exclusive, but in my opinion, my method in most cases never pays
attention to which signals are mutually exclusive, but knows well that
for any data, counter, not control signals, if there are more than 1
enable conditions, all of those enable conditions are mutually
exclusive and even there are many examples you really don't clear know
well which signals are mutually exclusive, but their conditions must be
mutually exclusive.

4. Here is the huge differences between your suggestion and mine:
if we introduce "ORIF" keyword, what will a VHDL compiler do?

A VHDL compiler must use the mutual exclusive knowledge to generate the
simplest code, no other more complex logic like
"if...elsif..elsif...end if" is generated.

5. With ORIF keyword introduced, we can enforce simulator to check if
any mutually exclusive statements are violated in VHDL language grammar
without needing an explicit declaration of any statements. This is the
right of your VHDL committee and use it!!!

6. Mutually exclusive logic are ubiquitous, inherent in hardware design
and it is a specific feather that is absent with any software
situations. VHDL doesn't include an explain keyword 'ORIF' to let VHDL
programmer to widely use it, it is not only a pity, but really a shame!

7. For Xilinx VHDL compiler, the related manual strongly recommends
that "DON'T USE 'IF...ELSIF...ELSIF...END IF' statement too deep,
otherwise it will have serious consequences in design performance. Why?
because of the loop, the accumulated delay caused by ELSIF keyword.
'ORIF' will certainly resolve the problem as my 8 projects successfully
prove that 'ORIF' should be introduced and widely used to get higher
performance with Xilinx VHDL compiler.

8. You said that my keyword is an extra thing, but in math, you must
know well the power operation: 2**5 = 2*2*2*2*2. Is the power operator
an extra operator? NO!!!
sin() and cosin(), tan() and cotan(), there are a lot of examples that
something must be repeated for easy usage.

Conclusion: your method adds nothing to improve efficiency, but extra
burden not only adding 3 statements that are ignored by any VHDL
compiler, but having to isolate the mutually exclusive signals!!!

Weng

 

[Jim Lewis]

Weng,

1. assert zero_one_hot(A_LE & B_LE & C_LE & D_LE)
report "%%%BUG: Mutual exclusion failed in design ..."
severity error ;
(I really don't know what library includes zero_one_hot().)

Can you guarantee that after the above assert statement a VHDL compiler
will use the mutually exclusive knowledge to generate shorter coding?
Try it with Xilinx VHDL compiler and see what logic is generated,
please. If you succeed, I will quit the argument and I will admit
losing the battle, otherwise, the fight will continue.

I expect that your assert statement claims nothing to any VHDL compiler
and VHDL compiler knows nothing to the assert statement and the same
logic as "if..elsif...elsif...end if" will be generated as usual.

Let fact teach me if I am wrong!!!

2. For VHDL compiler current status, all of them IGNORE assert()
statement during synthesizing period because it is really a debugging
statement used only in simulations, and VHDL compilers do not generate
any logic or retrieve any information from it at all. In other word,
your method introduces nothing to a VHLD compiler of latest version:
they are still generating "if...elsif...end if" logic even though you
introduce your method to tell them the mutually exclusive information.

Both proposals extend current capability.

This is not the place for debating this feature.
You can join Accellera and discuss this in the
VHDL TSC requirements group. Note it does not
reqiure money to join the VHDL TSC. Just follow
the directions in my previous email.

Regards,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

 

[Weng Tianxiang]

Weng,

Both proposals extend current capability.

This is not the place for debating this feature.
You can join Accellera and discuss this in the
VHDL TSC requirements group. Note it does not
reqiure money to join the VHDL TSC. Just follow
the directions in my previous email.

Regards,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

Hi Jim,
I have written an email to VHDL TSC to show my interest in pushing the
keyword "ORIF" into VHDL specification.

Thank you.

Weng

 

[Hans]

Hi Jim,

Hans,

Ironically VHDL already has Transaction Level Modeling capability.
I have done a paper on this (see http://www.synthworks.com/papers)
and a conference tutorial. We also teach a 3 day class based on
transaction based testbenches.

VHDL doesn't yet have OO, Constraint Random (CR) and Functional
Coverage (FC). The inclusion of PSL gives VHDL some coverage
capability.

I would change the some to "some very powerful"!!

Have a look at OVL and see what this has meant (means) for the verification
community. Now scale that capability up by a few factors and you have
PSL/SVA. These languages are very powerful but do have a steep learning
curve and unfortunately the associate price tag.

The plan is to have these ASAP. Probably by DAC 2007.


What is a "all singing all dancing testbench"?

A testbench that answers an additional question, "are we done verifying"?

My point is can you enumerate what problems CR + FC is
going to solve better than other methods?
The answer is definitely not everything.

Obviously otherwise we would have the perfect verification methodology

For example
I would not expect to use CR + FC to test arithmetic
circuits. Algorithmic transaction based tests can generate
more useful cases faster than CR. With CR there is no
guarantee that you will every hit the interesting cases.
Going further generating the FC for arithmetic is going to
be as hard or harder than actually generating the algorithmic
test vectors.

We are talking about different things, CR+FC is used extensively for complex
SoC based systems, I don't believe that anybody is using this methodology on
a simple arithmetic circuit for which a directed or algorithmic test might
be better. You probably also know that companies do not use CR+FC in pure
isolation, they combine it with many other types of test including directed
tests.

Another example, for many bus interface chips that have a number
of control registers each with their own particular format, it
is going to be much easier to exercise the chip with a directed
transaction based testbench than constraining a CR testbench
to be able to understand it.

Again as we say horses for courses, if the circuit can be tested using a
directed test then use that method. If the circuit becomes to complex then
CR+FC might find additional bugs. CR will enable you to randomise not just
the data and control but also time and injected errors. CR+FC is a proven
technology and I have been told that these techniques have been used long
before the big EDA companies started to support it.

Many of the marketing claims compare a CR + FC + transaction
based testbench to a directed, non-transaction based testbench.
Not a very realistic comparison.

Does anybody believes marketing

Many of the actual benefits
to these approaches also comes from the transaction based
testbench.

So this comes back to my question, "Assuming that we are all
using transaction based testbenches, can you enumerate what
problems CR + FC is going to solve better than a other methods
(algorithmic or directed)?"

System were you have a complex interaction for which a directed test is
simply to complex to write. In these cases it is easier to write a set of
constraints and let the tool generate the stimulus. You then use FC to
collect the coverage data to make sure you are addressing the specification
requirements. I believe that on most SoC systems nowadays the number of
testvectors is so large that even CR running a large computer farm needs to
be steered in the right direction (changing the seed/distributions). Just to
iterate the point, CR+FC is only part of the verification arsenal that large
companies are using. Directed and algorithmic test together with
assertions, TLM, formal, prototyping, hardware emulation, equivalence
checking, black magic, voodoo are all part of that arsenal.

VHDL has always been a good language for behavior modeling.

Yes, my mistake, I am not saying that VHDL is not capable of handling this
task. What I am saying is that for a complex modelling job you might be
better off with a modern language which was specifically developed for this
purpose.

Regards,
Hans

www.ht-lab.com

 

[Eric Smith]

I have written an email to VHDL TSC to show my interest in pushing the
keyword "ORIF" into VHDL specification.

I respectfully suggest instead using the Ada shortcut logical operators
"or else" and "and then", since VHDL syntax was originally derived
from Ada. This avoids any need to introduce new reserved words.

Eric