good vhdl 2002 book or website

I'm looking for a good starting point to study vhdl 2002 (protected
types ...) . Does anyboby has any experences?

antonio bergnoli

antonio bergnoli a écrit :

> I'm looking for a good starting point to study vhdl 2002 (protected
> types ...) . Does anyboby has any experences?
I tried a few examples.

Given that protected types won't be supported by synthetizer, this new
feature is almost useless.
Very very few people use or like shared variables too.
IMHO this is a feature to be forgotten.

The other vhdl 2002 features are transparent for users: the improved
default binding rule was
already present in most tool.

JD.

antonio bergnoli wrote:
> I'm looking for a good starting point to study vhdl 2002 (protected
> types ...) . Does anyboby has any experences?

Keep investigating protected types. While shared variables are not used
in synthesis, they are very useful in testbenches and in modeling
abstract data types like linked lists. Linked lists can be used to
model non-synthesisizable "sparse memories" and FIFO's.

regards,

reuven ha scritto:
> antonio bergnoli wrote:
>> I'm looking for a good starting point to study vhdl 2002 (protected
>> types ...) . Does anyboby has any experences?
>
> Keep investigating protected types. While shared variables are not used
> in synthesis, they are very useful in testbenches and in modeling
> abstract data types like linked lists. Linked lists can be used to
> model non-synthesisizable "sparse memories" and FIFO's.
>
> regards,
>

ok, but where could i study it?

john Doef wrote:
> antonio bergnoli a écrit :
>
>> I'm looking for a good starting point to study vhdl 2002 (protected
>> types ...) . Does anyboby has any experences?

Modelling the core of a memory with those types is a
'5-minute-exercise' (you just nead read and write access
functions to an array).

The current edition of Ashenden's Designer's Guide has
enough info on this to use it.

> I tried a few examples.
>
> Given that protected types won't be supported by synthetizer, this new
> feature is almost useless.
> Very very few people use or like shared variables too.
> IMHO this is a feature to be forgotten.

Not quite, in my opinion. For modelling large memories and similar
things, the protected types provide a "natural", simple, straightforward
approach. For verification and high-level modelling, such
features are urgently needed, if VHDL is to be used there.

VHDL has many other constructs which are (sometimes just due
to arbitrary limitations of the tools) not synthesizeable, but
are valuable nevertheless.

> The other vhdl 2002 features are transparent for users: the improved
> default binding rule was
> already present in most tool.
>
> JD.
>

Robert

Robert Reutemann a écrit :

> john Doef wrote:
> > antonio bergnoli a écrit :
> >
> >> I'm looking for a good starting point to study vhdl 2002 (protected
> >> types ...) . Does anyboby has any experences?
>
> Modelling the core of a memory with those types is a
> '5-minute-exercise' (you just nead read and write access
> functions to an array).
>
> The current edition of Ashenden's Designer's Guide has
> enough info on this to use it.
>
> > I tried a few examples.
> >
> > Given that protected types won't be supported by synthetizer, this new
> > feature is almost useless.
> > Very very few people use or like shared variables too.
> > IMHO this is a feature to be forgotten.
>
> Not quite, in my opinion. For modelling large memories and similar
> things, the protected types provide a "natural", simple, straightforward
> approach. For verification and high-level modelling, such
> features are urgently needed, if VHDL is to be used there.
Why do you need protected type for that ?
Hash table and linked list do the job well.

JD.

john Doef wrote:
> Robert Reutemann a écrit :
>
>> john Doef wrote:
>>> antonio bergnoli a écrit :
>>>
>>>> I'm looking for a good starting point to study vhdl 2002 (protected
>>>> types ...) . Does anyboby has any experences?
>> Modelling the core of a memory with those types is a
>> '5-minute-exercise' (you just nead read and write access
>> functions to an array).
>>
>> The current edition of Ashenden's Designer's Guide has
>> enough info on this to use it.
>>
>>> I tried a few examples.
>>>
>>> Given that protected types won't be supported by synthetizer, this new
>>> feature is almost useless.
>>> Very very few people use or like shared variables too.
>>> IMHO this is a feature to be forgotten.
>>
>> Not quite, in my opinion. For modelling large memories and similar
>> things, the protected types provide a "natural", simple, straightforward
>> approach. For verification and high-level modelling, such
>> features are urgently needed, if VHDL is to be used there.
>
> Why do you need protected type for that ?
> Hash table and linked list do the job well.
>

Because at least sometimes I want to have multiple
processes accesing the array (e.g. separate read/write, ...),
and I want to use a variable to avoid the overhead,
so I need a shared variable, and protected types provide
a clean way to access those from multiple processes without
having to explicitly care about possible conflicts.

Certainly not *the* solution in all cases, but one nice
solution in some cases, which is reason enough for me.

Robert

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

antonio bergnoli wrote:

> ok, but where could i study it?

http://users.aol.com/hdlfaq/vhdl2001-foils.pdf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFEs9pt536xjD3WmocRAsi5AJ9+C7Wnr0k7dxLfJiS3vZ zcgEwTYACfcvAu
tDvW75NqpNxRhAcTMsD9juY=
=lnmM
-----END PGP SIGNATURE-----

Robert Reutemann a écrit :
[...]
> > Why do you need protected type for that ?
> > Hash table and linked list do the job well.
> >
>
> Because at least sometimes I want to have multiple
> processes accesing the array (e.g. separate read/write, ...),
> and I want to use a variable to avoid the overhead,
> so I need a shared variable, and protected types provide
> a clean way to access those from multiple processes without
> having to explicitly care about possible conflicts.
Just to understand: what's prevent you from using only one process to
do multiple accesses ?

> Certainly not *the* solution in all cases, but one nice
> solution in some cases, which is reason enough for me.
>
> Robert