Subject: RE: [sv-bc] Amendment to the compilation unit definition
From: David W. Smith (david.smith@synopsys.com)
Date: Mon Dec 08 2003 - 10:38:40 PST
Hi Adam,
I believe it was just passed in the committee. See my comments below.
Regards
David
David W. Smith
Synopsys Scientist
Synopsys, Inc.
Synopsys Technology Park
2025 NW Cornelius Pass Road
Hillsboro, OR 97124
Voice: 503.547.6467
Main: 503.547.6000
FAX: 503.547.6906
Email: david.smith@synopsys.com
http://www.synopsys.com
-----Original Message-----
From: Adam Krolnik [mailto:krolnik@lsil.com]
Sent: Friday, December 05, 2003 7:15 AM
To: David.Smith@Synopsys.COM
Cc: sv-bc@eda.org
Subject: Re: [sv-bc] Amendment to the compilation unit definition
Hi David;
2 questions on the last two points.
>4. Another change is to make a requirement that every tool shall
>provide a tool specific mechanism (command line option?) that specifies
that >all of the files compiled together are a single compilation unit.
This >provides a backward compatible mechanism for 3.0 (and was in the
original >proposal that was approved).
Why are we defining how a tool shall compile files into a compilation unit?
Why require that a tool make a option to compile all files into a unit. It
seems this is as arbitrary as requiring an option to make all files compiled
separately? 1364-2001 language only recommended such options.
DWS: The problem here is that each vendor needs to support both versions so
that users can migrate designs from one vendor to another.
Instead of this kind of language, why not tie it to 1364-2001
configurations. The configuration chapter defines several use models without
requiring specific options and defaults. Also it would be good to define an
extension to the library mapping files so that one can define where a
compiled form of a library (compilation
unit) can be obtained.
DWS: There was some discussion of using the library mechanism and
configurations. The original wording was left sufficiently vague that the
library mechanism could be used. The problem was that this was overkill for
what was required and was being tied to library/configuration which,
according to some implementors I have talked with, still has definitional
problems.
>5. The final change is to indicate that, while other mappings of files
>to compilation units are possible, they are neither required nor portable.
This last statement does not seem useful or necessary. Compilers should be
free to build their own mechanisms. Of course, compatibility with other
compilers is definitely a positive attribute.
DWS: The issue is not compatibility with compilers. It is compatibility of
users designs across tools. I agree that , strictly speaking, this sentence
is not required. However, it does make what is compatible and what is not
explicit which is why I included it.
Thanks.
Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074
Co-author "Assertion Based Design"
This archive was generated by hypermail 2b28 : Mon Dec 08 2003 - 10:35:54 PST