Using WORK in VHDL files
Srinivasan Venkataramanan
I personally don't prefer using "Library WORK" within my VHDL code. But
I am unable to find a good reasoning for the same. Can some body throw some
light on the pros and cons of this usage?
Thanks.
Srini
Geir Harris Hedemark
I never refer to "library work" in my vhdl code. I either put things
in properly named libraries, or I put them in the current working
directory, where I don't need to reference the library.
Makes for less typing once you decide to move something out in a
separate library. You only change the referring code (library mylib
needs to go in front of the use statement) since the code itself does
not put constraints on where it is put.
Geir
me...@mench.com
<venkataraman...@philips.com> wrote in article
<82vmtg$r7o$1...@news2.isdnet.net>:
> I personally don't prefer using "Library WORK" within my VHDL
> code. But I am unable to find a good reasoning for the same. Can
> some body throw some light on the pros and cons of this usage?
There's a very good reason: It's redundant. In front of every design
unit is the implicit context clause:
library Std, Work;
use Std.Standard.all;
So, an explicit "library Work;" is unnecessary.
Paul
--
Paul Menchini | me...@mench.com |"The last thing I want to do is
Cadence Design Systems | www.orcad.com | spread fear, uncertainty and
P.O. Box 71767 | 919-479-1670[v] | doubt in the users' minds."
Durham, NC 27722-1767 | 919-479-1671[f] | --Don Jones, MS's Y2K Product Mgr
Sateesh Chandramohan
If you are not comfortable using Library Work you can use specific names for the
libraries and compile accordingly specifying the right switches in the compile
script.
This is very specific to your design though as you need to include a lot of
these libraries particularly if you are running the gate level simulation.
Hope this helps
Sateesh
Srinivasan Venkataramanan wrote:
> Hi,
> I personally don't prefer using "Library WORK" within my VHDL code. But
> I am unable to find a good reasoning for the same. Can some body throw some
> light on the pros and cons of this usage?
>
> Thanks.
>
> Srini
Srinivasan Venkataramanan
The issue is not just "library WORK" statement, it gets complicated
when people start referring to packages like
USE WORK.UTILITIES.ALL ;
etc. Or even worse in "configuration declaration" or "configuration
specification" they tend to use "WORK" which is very confusing for a third
party to read the code. So I tend to propose that "to keep designs reusable
please avoid referring to WORK" - but again this might just be a personal
preference, that's why I wanted to get more views on this.
Regards,
Srini
<me...@mench.com> wrote in message news:8334tr$t5v$1...@mench.mench.com...
> On Sun, 12 Dec 1999 09:38:13 +0100, Srinivasan Venkataramanan
> <venkataraman...@philips.com> wrote in article
> <82vmtg$r7o$1...@news2.isdnet.net>:
>
> > I personally don't prefer using "Library WORK" within my VHDL
> > code. But I am unable to find a good reasoning for the same. Can
> > some body throw some light on the pros and cons of this usage?
>
Michał Rutka
Srinivasan> Paul, The issue is not just "library WORK" statement, it
LIBRARY WORK statement is redundant.
Srinivasan> gets complicated when people start referring to packages
Srinivasan> like
Srinivasan> USE WORK.UTILITIES.ALL ;
This is OK. This statement says that package UTILITIES is in CURRENT
library, no matter what is it actual name. This is much better than
using explicit library names, because it makes it possible to change
library name as whole. This can be problem, when two libraries had the
same name.
Srinivasan> etc. Or even worse in "configuration declaration" or
Srinivasan> "configuration specification" they tend to use "WORK"
Srinivasan> which is very confusing for a third party to read the
Srinivasan> code. So I tend to propose that "to keep designs reusable
Srinivasan> please avoid referring to WORK"
You make in this way designs not reusable. Consider the following:
Two design houses make IP. They call the library IPS. So in their
source files they can use:
use IPS.UTIL.ALL;
but then you will have a problem importing those two into one
project. When they use:
use WORK.UTIL.ALL;
there is no problem. During compilation/evaluation WORK refers to
current library, which can be easily set for each design unit.
Regards,
Michal
Srinivasan> - but again this might
Srinivasan> just be a personal preference, that's why I wanted to get
Srinivasan> more views on this.
Srinivasan> Regards, Srini
Srinivasan> <me...@mench.com> wrote in message
Srinivasan> news:8334tr$t5v$1...@mench.mench.com...
>> On Sun, 12 Dec 1999 09:38:13 +0100, Srinivasan Venkataramanan
>> <venkataraman...@philips.com> wrote in article
>> <82vmtg$r7o$1...@news2.isdnet.net>:
>>
>> > I personally don't prefer using "Library WORK" within my VHDL >
>> code. But I am unable to find a good reasoning for the same. Can >
>> some body throw some light on the pros and cons of this usage?
>>
>> There's a very good reason: It's redundant. In front of every
>> design unit is the implicit context clause:
>>
>> library Std, Work; use Std.Standard.all;
>>
>> So, an explicit "library Work;" is unnecessary.
>>
>> Paul
>>
>> -- Paul Menchini | me...@mench.com |"The last thing I want to do
>> is Cadence Design Systems | www.orcad.com | spread fear,
>> uncertainty and P.O. Box 71767 | 919-479-1670[v] | doubt in the
>> users' minds." Durham, NC 27722-1767 | 919-479-1671[f] | --Don
>> Jones, MS's Y2K Product
Srinivasan> Mgr
--
Dr. Ir. Michal Rutka Lucent Technologies - Huizen, The Netherlands
Senior System Engineer mailto:ru...@lucent.com
me...@mench.com
<venkataraman...@philips.com> wrote in article
<8375sv$qi$1...@news3.isdnet.net>:
> The issue is not just "library WORK" statement, it gets
> complicated when people start referring to packages like
> USE WORK.UTILITIES.ALL ;
> etc. Or even worse in "configuration declaration" or "configuration
> specification" they tend to use "WORK" which is very confusing for a
> third party to read the code. So I tend to propose that "to keep
> designs reusable please avoid referring to WORK" - but again this
> might just be a personal preference, that's why I wanted to get more
> views on this.
Ah, I misunderstood your question.
Yes, in general, it is well to avoid *references* to library Work.
"Work" is an ephemeral name--it always refers to the library being
populated, which should also have a permanent name. By making all
references to the permanent name, you avoid problems that will occur
when the denotation of "Work" changes.
Paul
--
Paul Menchini | me...@mench.com |"The last thing I want to do is
Cadence Design Systems | www.orcad.com | spread fear, uncertainty and
P.O. Box 71767 | 919-479-1670[v] | doubt in the users' minds."
Durham, NC 27722-1767 | 919-479-1671[f] | --Don Jones, MS's Y2K Product Mgr
Srinivasan Venkataramanan
Michał Rutka <ru...@lucent.com> wrote in message
news:wsmaenc...@hzsac503.nl.lucent.com...
> >>>>> "Srinivasan" == <venkataraman...@philips.com> writes:
>
> Srinivasan> Paul, The issue is not just "library WORK" statement, it
>
> LIBRARY WORK statement is redundant.
>
> Srinivasan> gets complicated when people start referring to packages
> Srinivasan> like
>
> Srinivasan> USE WORK.UTILITIES.ALL ;
>
> This is OK. This statement says that package UTILITIES is in CURRENT
> library, no matter what is it actual name. This is much better than
> using explicit library names, because it makes it possible to change
> library name as whole. This can be problem, when two libraries had the
> same name.
>
For me changing a VHDL file is more problematic than just renaming a
library, it is unlikely that we end up with 2 VHDL libraries having the same
name, especially when we try and standardise some standard "prefixes" within
our organisation for each design team.
Also I forsee a major problem in terms of "reusability", consider an
IP being delivered with
USE WORK.UTIL_PAK.ALL ;
I have no clues of where I can find this package by just looking at the
code. B'cos the whole design could be compiled from some remote directory
(where I can find a library mappings file which will say where this WORK
is!!)
> Srinivasan> etc. Or even worse in "configuration declaration" or
> Srinivasan> "configuration specification" they tend to use "WORK"
> Srinivasan> which is very confusing for a third party to read the
> Srinivasan> code. So I tend to propose that "to keep designs reusable
> Srinivasan> please avoid referring to WORK"
>
> You make in this way designs not reusable. Consider the following:
>
> Two design houses make IP. They call the library IPS. So in their
> source files they can use:
>
> use IPS.UTIL.ALL;
>
> but then you will have a problem importing those two into one
> project. When they use:
>
> use WORK.UTIL.ALL;
>
> there is no problem. During compilation/evaluation WORK refers to
> current library, which can be easily set for each design unit.
>
Again I disagree here, as it is much easier to "request" for an IP
with a different VHDL library name. This kind of "WORK.UTIL.ALL" will be
very difficult to read/understand for the users. Of-course I agree with you
that it is easier to compile.
Regards,
Srini
> Regards,
>
> Michal
pepelepew
> "Work" is an ephemeral name--it always refers to the library being
> populated, which should also have a permanent name.
Actually, I prefer to use references to WORK.
I view it as being the same thing as
using a relative pathname vs a full pathname. It says to the reader
"this unit is in the same library as this one". It is like using "."
in a relative pathname.
> By making all
> references to the permanent name, you avoid problems that will occur
> when the denotation of "Work" changes.
And using WORK will avoid problems when the denotation of "Work" DOES
change. With design reuse being the touted design methodology of the
next few years, designs (and portion thereof) will need to be moved
and copied into different libraries. Using "work" will eliminate the
need for modifying the source code if it finds itself in a different
library.
Also, library names are the ONLY global symbols in a model. What if I
already use the permanent name you are using and we need to tie our
models together? By using WORK, I only need to change to tool library
configuration and recompile. By not using WORK, you also need to
change your source code.
--
Janick Bergeron - VP of Technical Wisdom
Qualis Design Corporation
jan...@qualis.com
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
Srinivasan Venkataramanan
Thanks for the argument. Please find my comments below.
Regards,
Srini
jan...@qualis.com on 16-12-99 17:46:29
To: me...@mench.com@SMTP
bco...@west.raytheon.com@SMTP
vhdl...@aol.com@SMTP
cc: Venkataramanan Srinivasan/EHV/SC/philip-@emea3
Subject: RE: library work -- FYI
Classification: Restricted
Thank for the forwarding, Ben. I replied to the ng as well.
>Actually, I prefer to use references to WORK (Ben and I have been debating
this point for a >long time :-). I view it as being the same thing as using
a relative pathname vs a full pathname. >It says to the reader "this unit is
in the same library as this one". It is like using "." in a relative
>pathname.
=========
I appreciate your view, but I feel there is a difference in the sense
that "absolute paths" have to be chanegd in the code whereas library names
can be mapped external to the code.
=========
> By making all references to the permanent name, you avoid problems that
will occur when >the denotation of "Work" changes.
>And using WORK will avoid problems when the denotation of "Work" DOES
change. With >design reuse being the touted design methodology of the next
few years, designs (and portion >hereof) will need to be moved and copied
into different libraries. Using "work" will eliminate >the need for
modifying the source code if it finds itself in a different library.
=======
This is exactly what my focus lies as well, so we are talking
in the same paradigm! For me till today no IP is real "plug & play"
we do need to have a look at the "configurations" at the least case.
Especially to get the simulations faster, I prefer using "behavioural"
models for those modules for which I am not responsible for. This
to some extent (arguably) requires a quick look at the "configurations".
It is here that I get confused with "WORK".
========
>Also, library names are the ONLY global symbols in a model. What if I
already use the >permanent name you are using and we need to tie our models
together? By using WORK, I >only need to change to tool library
configuration and recompile. By not using WORK, you also >need to change
your source code.
======
I guess there is no real "lack" of names! Also I believe we should try and
standardise "definite prefixes" for each design team (within
each organisation). Then most of the issue is already solved. Of-course the
risk could still be from 3rd party models but I am some how convinced that
IP vendors would really like to "see" their company "name" in their models
hence this is not a major one from my point of view. Of-course I am open
to change my mind if anybody can convince me.
Regards,
Srini
--
Janick Bergeron - VP of Technical Wisdom Qualis Design Corporation
jan...@qualis.com
=== PLEASE NOTE MY NEW E-MAIL ID ====
venkataraman...@philips.com
======================================
Srinivasan Venkataramanan, M.Tech (Srini)
IC Design Engineer, Imaging Group, BATIMENT A (Room No. AS 007) PHILIPS
FRANCE
2, Rue de la Girafe, 14079 CAEN CEDEX 5, France. Ph: +33-231-452245 (ext
2729) (Off), +33-231-473347 (Res) FAX: +33-231-452179, SERI:
srin-@rtccnh1
Michał Rutka
Srinivasan> Hi, Michał Rutka <ru...@lucent.com> wrote in message
Srinivasan> news:wsmaenc...@hzsac503.nl.lucent.com...
>> >>>>> "Srinivasan" == <venkataraman...@philips.com>
>> writes:
>>
Srinivasan> Paul, The issue is not just "library WORK" statement, it
>> LIBRARY WORK statement is redundant.
>>
Srinivasan> gets complicated when people start referring to packages
Srinivasan> like
>>
Srinivasan> USE WORK.UTILITIES.ALL ;
>> This is OK. This statement says that package UTILITIES is in
>> CURRENT library, no matter what is it actual name. This is much
>> better than using explicit library names, because it makes it
>> possible to change library name as whole. This can be problem,
>> when two libraries had the same name.
>>
Srinivasan> For me changing a VHDL file is more problematic
Srinivasan> than just renaming a library, it is unlikely that we end
Srinivasan> up with 2 VHDL libraries having the same name, especially
Srinivasan> when we try and standardise some standard "prefixes"
Srinivasan> within our organisation for each design team.
For me changing a VHDL file is also more problematic. It is very
likely that you end up with two libraries with the same name. It is
enough when you make a new version and want to test it against the old
one in the same test bench (which is BTW a very good verification
strategy).
Srinivasan> Also I forsee a major problem in terms of
Srinivasan> "reusability", consider an IP being delivered with
Srinivasan> USE WORK.UTIL_PAK.ALL ;
Srinivasan> I have no clues of where I can find this package by just
Srinivasan> looking at the code. B'cos the whole design could be
Srinivasan> compiled from some remote directory (where I can find a
Srinivasan> library mappings file which will say where this WORK
Srinivasan> is!!)
The same way simulator does.
[...]
Srinivasan> Again I disagree here, as it is much easier to
Srinivasan> "request" for an IP with a different VHDL library
Srinivasan> name. This kind of "WORK.UTIL.ALL" will be very difficult
Srinivasan> to read/understand for the users. Of-course I agree with
Srinivasan> you that it is easier to compile.
You can request something, but this will probably delay the
delivery and increase the price.
Srinivasan> Regards, Srini
Regards,
Michal
--