Clock Edge notation

Of course there are multiple functionally equivalent methods (i.e. they
synthesize to the same hardware) of describing a given architecture,
but some methods (e.g. using integers, variables and clocked processes,
while minimizing slv, signals, combinatorial processes and concurrent
assignments) simulate much more efficiently (approaching cycle based
performance) than others. The more clock cycles I can simulate, the
more bugs I can find, and the more quickly I can verify alternate
architectures. It may not make a big difference on small projects, but
on larger projects, the performance difference is huge.

Andy

KJ wrote:
Andy wrote:
Yes, but...

Assuming the signals that those concurrent assignments depend on are
driven from clocked processes, they do not update until after the
clock, which means they are the registered (delayed) values.

So what? I typically don't care about waiting a delta cycle delay,
when you put them up on a wave window to debug they all happen at the
same time.

snip
Note that both out1 and out2 have the same cycle-accurate behavior.
Note also that if both out1 and out2 exist, Synplify will combine them
and use out1 for both.

And this can be written in a functionally equivalent manner using a
process and concurrent assignments and it will synthesize to the exact
same thing....equivalent.

KJ
 
Hi Andy,
I would like to ask a question:
process (clk) is
begin
if rising_edge(clk) then
var := (var - 1) mod var_limit;
out1 <= var = 0; -- registered comparison of combinatorial var
(i.e. var - 1) with 0
end if;
out2 <= var = 0; -- combinatorial comparison of registered var with 0
end process;

In the following statement:
var := (var - 1) mod var_limit;
var is not assigned any value before it is used. var_limit is a
constant, of course.
Anything is wrong?

Weng

Andy wrote:
Yes, but...

Assuming the signals that those concurrent assignments depend on are
driven from clocked processes, they do not update until after the
clock, which means they are the registered (delayed) values.

Also, see below:

process (clk) is
begin
if rising_edge(clk) then
var := (var - 1) mod var_limit;
out1 <= var = 0; -- registered comparison of combinatorial var
(i.e. var - 1) with 0
end if;
out2 <= var = 0; -- combinatorial comparison of registered var with 0
end process;

Note that both out1 and out2 have the same cycle-accurate behavior.
Note also that if both out1 and out2 exist, Synplify will combine them
and use out1 for both.

Andy

KJ wrote:
Andy wrote:
With variables, you don't have to wait an extra clock in single process
descriptions.

With concurrent signal assignments that are outside of the process you
don't have to wait an extra clock either.

KJ
 
In article <peyp8xmjgc51.fsf@PXPL8591.amr.corp.intel.com>,
first.last@employer.domain says...
But if anyone writes a book like this it will fly off the shelves!

Care to estimate the size of the market?
I don't know about hardware books, but for a specialist
book 10,000 copies over the lifetime of the book is a
bestseller!

A first printing may be something like 1,000-2,500
books I believe. Many (probably most?) don't make it
past a first printing.


I.e. how much would the author expect to make, given typical publishing contracts?
About 15% in royalties.


(I've long wanted to write such a book, but have trouble with the
business case - i.e. persuading my wife. And, of course, I cannot
write it as an employee of Intel.)
There's no business in it. For the great majority, writing
specialist books is a losing proposition; you'd make more
money flipping burgers during the time it would take you to
write the book. You write a (specialist) book because you
have a burning need to write one.

The only way there's business in it is if the book is picked
up as a textbook at lots of universities around the world or
is on some universally interesting topic.

Knuth, Hennessy and Patterson, Foley et al, and McConnell
have probably made good money from their books, but they are
the exceptions.

--
Christer Ericson
http://realtimecollisiondetection.net/
 
Weng Tianxiang wrote:

In the following statement:
var := (var - 1) mod var_limit;
var is not assigned any value before it is used. var_limit is a
constant, of course.
Anything is wrong?
No.
For simulation, the present value is used
to calculate and save the expression value.
For synthesis, this is infers a register to save
the value for the next process loop.

-- Mike Treseler
 
Hi Mike,
Thank you for your response.
Now what is the first value after system asynchronous reset for first
loop?

Thank you.

Weng

Mike Treseler wrote:
Weng Tianxiang wrote:

In the following statement:
var := (var - 1) mod var_limit;
var is not assigned any value before it is used. var_limit is a
constant, of course.
Anything is wrong?

No.
For simulation, the present value is used
to calculate and save the expression value.
For synthesis, this is infers a register to save
the value for the next process loop.

-- Mike Treseler
 
Weng Tianxiang wrote:
Hi Mike,
Thank you for your response.
Now what is the first value after system asynchronous reset for first
loop?
Whatever the reset code says it is.
If there is no reset code, it might be a 'U'.
Check your simulation waveforms for exact answers.

-- Mike Treseler
 
You can assignee an initial value when a variable or signal is
declared, e.g.,

signal mysig: std_logic := '0';

This will be the initial value when simulation starts. According to
VHDL LRM, if there is no initial value, the first value defined in the
data type will be used. Since std_logic is defined as ('U', 'X', '0',
....) in 1164 package. The 'U' value (for uninitialized) will be the
default value.

Since the initial value cannot always be synthesized, this approach
should not be used in synthesis. It is better to use an explicit reset
mechanism to initialize a sequential circuit.

Mike G.


Weng Tianxiang wrote:
Hi Mike,
Thank you for your response.
Now what is the first value after system asynchronous reset for first
loop?

Thank you.

Weng

Mike Treseler wrote:
Weng Tianxiang wrote:

In the following statement:
var := (var - 1) mod var_limit;
var is not assigned any value before it is used. var_limit is a
constant, of course.
Anything is wrong?

No.
For simulation, the present value is used
to calculate and save the expression value.
For synthesis, this is infers a register to save
the value for the next process loop.

-- Mike Treseler
 
Hi Mike,
Thank you.

Weng



mikegurche@yahoo.com wrote:
You can assignee an initial value when a variable or signal is
declared, e.g.,

signal mysig: std_logic := '0';

This will be the initial value when simulation starts. According to
VHDL LRM, if there is no initial value, the first value defined in the
data type will be used. Since std_logic is defined as ('U', 'X', '0',
...) in 1164 package. The 'U' value (for uninitialized) will be the
default value.

Since the initial value cannot always be synthesized, this approach
should not be used in synthesis. It is better to use an explicit reset
mechanism to initialize a sequential circuit.

Mike G.


Weng Tianxiang wrote:
Hi Mike,
Thank you for your response.
Now what is the first value after system asynchronous reset for first
loop?

Thank you.

Weng

Mike Treseler wrote:
Weng Tianxiang wrote:

In the following statement:
var := (var - 1) mod var_limit;
var is not assigned any value before it is used. var_limit is a
constant, of course.
Anything is wrong?

No.
For simulation, the present value is used
to calculate and save the expression value.
For synthesis, this is infers a register to save
the value for the next process loop.

-- Mike Treseler
 
I almost always use integer subtypes for counters, so it would not
simulate as 'U'. I used a simple example to show a point about
combinatorial vs registered logic, not about reset; you can code async
or sync reset for registers using variables the same way you do for
signals.

Andy


mikegurche@yahoo.com wrote:
You can assignee an initial value when a variable or signal is
declared, e.g.,

signal mysig: std_logic := '0';

This will be the initial value when simulation starts. According to
VHDL LRM, if there is no initial value, the first value defined in the
data type will be used. Since std_logic is defined as ('U', 'X', '0',
...) in 1164 package. The 'U' value (for uninitialized) will be the
default value.

Since the initial value cannot always be synthesized, this approach
should not be used in synthesis. It is better to use an explicit reset
mechanism to initialize a sequential circuit.

Mike G.


Weng Tianxiang wrote:
Hi Mike,
Thank you for your response.
Now what is the first value after system asynchronous reset for first
loop?

Thank you.

Weng

Mike Treseler wrote:
Weng Tianxiang wrote:

In the following statement:
var := (var - 1) mod var_limit;
var is not assigned any value before it is used. var_limit is a
constant, of course.
Anything is wrong?

No.
For simulation, the present value is used
to calculate and save the expression value.
For synthesis, this is infers a register to save
the value for the next process loop.

-- Mike Treseler
 
Andy wrote:
I almost always use integer subtypes for counters, so it would not
simulate as 'U'.
I prefer integers for counters also.
Up to 31 bits, that is :)

-- Mike Treseler
 
Mike,

What's the advantage of the coding style you demonstrated in this example
with procedures instead of direct assignments in the process?

Thanks,
/Mikhail



"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:4kejgsFbq463U1@individual.net...
Frank Buss wrote:

Is this synthesizable?

If you add a few declarations it is.

http://home.comcast.net/~mike_treseler/irr.vhd
http://home.comcast.net/~mike_treseler/irr.pdf

-- Mike Treseler
 
MM wrote:

What's the advantage of the coding style you demonstrated in this example
with procedures instead of direct assignments in the process?
Since the template is always the same,
I can write synth code quickly and it
often works the first time.

The template separates the tasks of
initialization, update, and output wiring.
The procedure "update_regs" becomes a distilled
functional description without any
wires or boilerplate spoiling the view.

I can simulate simple variable updates
in my head because the description uses
present values only. There are no signals.

-- Mike Treseler
 
Mark P wrote:
Weng Tianxiang wrote:
Hi,
I want to buy some books on algoirthms in graph.

Of the following 5 books, which one is best on descriptions algorithms
in graph:


[...]

I don't know any of the books but perhaps you could be more specific
about what you want to know about graph algorithms. If it's only basic
algorithms (shortest path, min. spanning tree, network flows, etc.) then
there are many general algorithm texts that would cover these. For more
specialized applications we need to know more about your intentions.
Hi Mark,
I am a hardware FPGA designer. What I want to do is to try to design a
new hardware circuit to tackle the most difficult and very famous
algorithms in graph.
1. The algorithms in graph are very commonly used;
2. The algorithms computing complexity is high, for example, O(N**m), m
= 2;
I would like to learn the algorithms, then try to find a hardware
solution for them.

I found the maximum matching problem for bipartite in graph is an
interesting problem:
it has computing complexity of O(N**2.5) and very famous. I am doing
research on it now.
I would like to find more similar situations like the maximum matching
problem in graphs.

Thank you.

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

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
Thanks Jim,

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

Regards,
Hans.
www.ht-lab.com


"Jim Lewis" <Jim@SynthWorks.com> wrote in message
news:12gh7gm6qv5gb6c@corp.supernews.com...
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:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
Jim Lewis wrote:
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:Jim@SynthWorks.com
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
 
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
 
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
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.

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


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

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

Welcome to EDABoard.com

Sponsor

Back
Top