Clock Edge notation

[Amal]

Jim Lewis wrote:

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?

Jim Lewis wrote:

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

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?
Too soon yet.

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?
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:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

 

[Hans]

"Amal" <akhailtash@gmail.com> wrote in message
news:1158335334.208468.42210@i42g2000cwa.googlegroups.com...

Jim Lewis wrote:
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.

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

Jim Lewis wrote:
_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

 

[Weng Tianxiang]

David Ashley wrote:

Weng Tianxiang wrote:
How about keyword "elsor" keyword?

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

-Dave

--
David Ashley http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

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

Weng

 

[Weng Tianxiang]

Jim Lewis wrote:

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:Jim@SynthWorks.com
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]

Weng Tianxiang wrote:

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


--
David Ashley http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

 

[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:Jim@SynthWorks.com
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

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 ;

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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 Lewis wrote:

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

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 ;


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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: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 Lewis wrote:

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:Jim@SynthWorks.com
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,

"Jim Lewis" <Jim@SynthWorks.com> wrote in message
news:12gtf30dhj6ild6@corp.supernews.com...

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.

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.

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

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.

However ... or you want to do some behaviour modelling of your
system ...
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

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[cbr_929rr]

I had similar issues with opencores until now. It is working now.

Derek Simmons wrote:

Before I get spamed for this I have done a search and I see there are
references to what I'm looking for on www.opencores.org but for some
reason I'm unable to connect.

What I'm looking for is a resource like, if it existed, Numerical
Receipes in HDL (VHDL/Verilog). I have a need for the basic floating
point functions like sin( a ) and x ** y. For floating point numbers
that are only 12 to 18 bits I can use lookup tables but I was wondering
if there was another way of calculating these values. Most of the books
I have cover addition/subtraction, multiplication and division but
nothing more advance or even hints at how to go about it.

From sin( a ) and x ** y I plan on deriving cos( a ), tan( a ), cot( a
), and yth root of x.

I'm looking for any helpful or constructive suggestions.

Thanks,
Derek

 

[Aurelian Lazarut]

for integer implementations the cordic algorithm covers most of the
trigonometric functions
you need (no multipliers, but some latency)
Aurash

Derek Simmons wrote:

Before I get spamed for this I have done a search and I see there are
references to what I'm looking for on www.opencores.org but for some
reason I'm unable to connect.

What I'm looking for is a resource like, if it existed, Numerical
Receipes in HDL (VHDL/Verilog). I have a need for the basic floating
point functions like sin( a ) and x ** y. For floating point numbers
that are only 12 to 18 bits I can use lookup tables but I was wondering
if there was another way of calculating these values. Most of the books
I have cover addition/subtraction, multiplication and division but
nothing more advance or even hints at how to go about it.

From sin( a ) and x ** y I plan on deriving cos( a ), tan( a ), cot( a
), and yth root of x.

I'm looking for any helpful or constructive suggestions.

Thanks,
Derek

--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/

phone: 353 01 4032639
fax: 353 01 4640324

 

[cbr_929rr]

If www.opencores.org link does not work, try
http://www.opencores.org:8080/

cbr_929rr wrote:

I had similar issues with opencores until now. It is working now.

Derek Simmons wrote:
Before I get spamed for this I have done a search and I see there are
references to what I'm looking for on www.opencores.org but for some
reason I'm unable to connect.

What I'm looking for is a resource like, if it existed, Numerical
Receipes in HDL (VHDL/Verilog). I have a need for the basic floating
point functions like sin( a ) and x ** y. For floating point numbers
that are only 12 to 18 bits I can use lookup tables but I was wondering
if there was another way of calculating these values. Most of the books
I have cover addition/subtraction, multiplication and division but
nothing more advance or even hints at how to go about it.

From sin( a ) and x ** y I plan on deriving cos( a ), tan( a ), cot( a
), and yth root of x.

I'm looking for any helpful or constructive suggestions.

Thanks,
Derek

 

[Stephen Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Evan Lavelle wrote:

This brings me to my problem. I can make the software a lot more
sophisticated if I can generate C code, as well as (or instead of) the
VHDL or Verilog. There are some testbenchy things which are just very
difficult to do in pure VHDL or Verilog. *But*, most of the potential
users of this software will be FPGA coders with a cheap simulator that
doesn't support a C-language interface (ModelSim PE/VHDL on Windows,
for example, doesn't do this, and presumably the FPGA-specific
simulators don't do this either).

Cheap/free simulators *should* support some sort of C interface.
Icarus Verilog supports VPI and I'd be astonished if the bundled
Verilog compilers w/ FPGA vendor tools doesn't also support VPI.

- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFFQjburPt1Sc2b3ikRAlWSAJ4z5s8Hn9mQ4B0U8IevKZzmOsCkDQCg500z
EziQS9sPImvMVTE3FP0T3f0=
=tv0x
-----END PGP SIGNATURE-----

 

[Andy]

Ben,

Thanks for jogging my memory. Yes, SLV is defined as having only
natural (non-negative) indices. The fixed point package solves that,
but brings along the extra baggage of extended results ranges. For
result := a + b; result'width = max(a'width, b'width) + 1. This makes
using fixed point types for most integer arithmetic rather complicated
and verbose.

I would rather have fixed point scaler types, maybe borrowing the ada
style, converted from "digits" to "bits" of course. The arithmetic
syntax would be much cleaner, and the results just as precise
(bit-accurate) as these vectors are, without the sizing headaches.
They'd simulate much faster than vectors too, approaching the
simulation performance of integers.

Andy


Ben Jones wrote:

"Andy" <jonesandy@comcast.net> wrote in message
news:1162326837.487846.157250@i42g2000cwa.googlegroups.com...

Does ISE accept negative indices on SLV? It seems like I've heard it
has problems with the ieee candidate fixed point package for that
reason.

Unfortunately, you heard correctly.

In fact std_logic_vector is defined as an "array(natural range <&gt of
std_logic"; consequently, negative indices are not allowed for slv anyway.
However, you can define your own logic array type (using integer range <&gt
to get around this... and then XST will go ahead and barf at it.

I believe that the development team have been made aware of this (the
synthesizable fixed-point and floating-point libraries from the forthcoming
VHDL standards will certainly require support for this).

-Ben-

 

Hi Jim,

this looks very impressive!! I usually avoid IEEE/Accellera documents
because they are next to unreadable to me, but your summary at

http://www.synthworks.com/papers/vhdl_accellera_lewis_marlug_2006_color.pdf

looks really good. I advice _everybody_ on the newsgroup to check it
out.



After that, please give your EDA vendors a call



once again, nice job Accellera!
burns


Jim Lewis wrote:

Rick,
The Accellera VHDL TSC has taken over the VHDL-200X effort.
Its first revision, Accellera VHDL-2006 standard 3.0, was
approved at DAC and is available for adoption (vendors first
of course). My understanding is that simulation vendors are
currently working on these additions now.

The primary verification features added in this revision
are direct integration of PSL, generics on packages and type
generics. The generics on packages and type generics give
us the capability to build verification data structures in
standard packages. I have posted a papers on the current
revision under the title Accellera VHDL 2006 Standard 3.0 at:
http://www.synthworks.com/papers/index.htm

If you like what you see, make sure your vendor knows that
you want the features. In addition, make sure they know
which features are most important to you - like everything
else these are often implemented in a priority fashion.

For the next revision, good progress has been made on
constrained random and interface features. My guess is that
we will have this for DAC 2007.

If you want to keep a pulse on things, join the Accellera
VHDL TSC and the VHDL Extensions subgroup. Neither of these
require a paid Accellera membership. By joining you are also
expressing your interest in VHDL standards which acts as a
motivator for EDA vendors to implement the standards.
Of course for those of you that belong to larger organizations
your membership fees go to help fund the standards.
For Accellera VHDL TSC membership, goto:
http://www.accellera.org/activities/vhdl


Cheers,
Jim Lewis
VHDL Standards Advocate
Participant in both Accellera and IEEE VHDL standardization efforts.
IEEE VHDL/VASG chair http://www.eda.org/vasg

P.S.
Everything Accellera standardizes will eventually become an
IEEE standard - it is just faster to do it in Accellera first.

 

[Mike Treseler]

Rick North wrote:

The reason for asking is that there is a great pull towards
SystemVerilog at my company. The main arguments are the verification
features which SV has such as constrained
random, coverage, interfaces etc.

I would hang fire until I saw a working
example on a real design.

On the other hand for a design view
point the floating package is a great plus for VHDL and all the legacy
code that has been developed over the years inside the company.

You're preaching to the choir.

Does anybody has a feel of when vhdl has reached (or surpassed)
SystemVerilog and when the tools are ready for the new VHDL standard?
Is it 5 years from now, then I might have to give up and join the
SystemVerilog mob which seems to be most happy with SV and all the
bells and whistles.

If my FPGA tool process were stymied for lack of
constrained random variation, I might take a look.
Until then, I wait until someone in the mob completes
a project.

-- Mike Treseler

 

[Evan Lavelle]

On Tue, 31 Oct 2006 15:28:19 -0800, Jim Lewis <Jim@SynthWorks.com>
wrote:

I have posted a papers on the current
revision under the title Accellera VHDL 2006 Standard 3.0 at:
http://www.synthworks.com/papers/index.htm

A nice presentation; a couple of quick thoughts:

p6 - I can't believe it took 15-odd years to get a standard VHPI and
another 5 to formalise it. For my money, this is the one thing that
has done most to hold back VHDL over the years.

p11 - is the constant initialiser correct? It seems to have too many
bits

p12 - Would it be more usal to call the 'fraction' of a floating-point
type a 'significand'?

p13 - <pedantic> s/heirarchy/hierarchy/ </pedantic>

pp17/18 - is the only relaxation of the locally and globally static
rules (and p24)? If so, this seems to be an opportunity lost. Many of
the rules are pointless, and exist because of limited compilation
computing power in the early 80's.

p20 - presumably allowing if(cs) instead of if(cs = '1') was to handle
PSL conditionals? Have you relaxed the typing rules just in this one
case (and p29)? If so, does it really make sense to break the existing
typing rules just for this one ad-hoc exception? (And don't all those
brackets make it look rather C-like? )

p24 - signal expressions in port maps - "needed to avoid extra signal
assignments with OVL"?! Seriously? We've had to put up with globally
static expressions in port maps for all these years and finally,
you've relaxed it for *Accellera OVL*??

p25 - reading output ports - this has been on the cards for years. It
seems a bit contentious to justify it because assertions needed this
feature; the rest of us needed it long before assertions did.

p26 - "allow conditional assignments for signals and variables in
sequential code". A useful addition to clean up some verbosity? Or
just two ways to do exactly the same thing because the first way was
too verbose? Basic tenet of language design: don't give users multiple
ways to do the same thing. In particular, don't wait 20+ years then do
a partial syntactic up-sugaring exercise. If you wanted to fix the
syntax, you should have done it properly, or not at all. Sorry....

p27 - allowing selected assignments in sequential code - ditto; even
more so.

p28 - unary reduction operators. I've got a bad feeling about this.
Doesn't it cause confusion in Verilog code? Which is better - "a <=
xor b xor c", or "a <= xor_reduce(b) xor c"?

p29 - array/scalar logic operators; so we can now have built-in
overloading to, for example, AND a std_logic with a SLV4. We can
already do this without a built-in; so what's the point? VHDL is meant
to be strongly typed. Is VHDL-200x also meant to be strongly typed, or
not?

p30 - <pedantic, etc> "data read back logic" - typo?

p36 - very confusing; you need to read p37 in detail to understand it.
Even then, it's still confusing - what's the "Logic, Addition" row?
Are any of these rows meant to cover exisiting vendor-specific
std_logic_unsigneds? They don't seem to.

p38 - just my personal opinion, of course - HDLs and 'programming'
languages are *very* different. The two common HDLs are 80's dinosaurs
that can't be fixed; one of them wasn't designed, and the other was
designed by a committee. What's the point of trying to shoe-horn
'real' language features like constrained random generation and all
the rest of it into Verilog or VHDL? They're intended for something
completely different, and they're totally unable to take this extra
infrastructure. There is no point, and it makes no sense whatever,
except for the EDA vendors. If you want the extras, you can already
buy them in appropriate languages that were designed for the job.

p40 - s#"E (specman)"#'e'/Specman#

Have any vendors shown any interest in actually implementing
"Accellera VHDL-2006"?

P.S.
Everything Accellera standardizes will eventually become an
IEEE standard - it is just faster to do it in Accellera first.

If any single statement could encapsulate why the IEEE is totally
irrelevant in language standardisation, this is it. Why doesn't
Accellera have the balls to issue its own standards, instead of
pretending that they're independent IEEE standards? They're not; I
think most people appreciate this now.

Evan