Why VHDL is vendor-independent
Kim. Jae-Yong
Whenever I learn VHDL, it is always said that using VHDL, We can design
independently from vendor.....
but I can hardly understand ...
I think we can change library of the vendor when we design with schematic
and if we should change schematic when switch vendor, VHDL code should also be
changed... I guess..
Why does it become vendor-independent..?
Sorry for my ignorance and bad English....
I know little about vhdl....
thanks in advance
Duncan Davis
VHDL is just a Hardware Description Language.
Each different vendor will supply you with a library which you can then
synthesise to.
Keeping it simple your synthesis tool takes your VHDL code and targets a
particular vendors library.
The theory is that your VHDL can stay the same if you change vendor. All
you have to do is synthesise to that new vendors library. That way VHDL
is vendor independent. Hope that helps a little
Duncan Davis
Markus Rettinger
VHDL allows you to describe your design.
There are different views to your design:
Highest abstraction is to describe how your design should behave.
At lower views you can describe at rtl.
That is in my opinion the only change in VHDL descriptions - but there
is no vendor dependency at that point.
Vendors take place in the design flow when doing synthesis of your VHDl-
description, because then you map all functions into the library of
the vendor. This does not cause any changes in VHDL.
---
---------------------------------------------------------------------
- Lehrstuhl fuer Integrierte Schaltungen | -
- Techn. Universitaet Muenchen | -
- Dipl.-Ing Markus Rettinger | -
- Arcisstr. 21 | -
- 80290 Muenchen | -
------------------------------------------------| -
- Tel: +49 89 289 225 15 | -
- Fax: +49 89 289 283 23 | -
------------------------------------------------| -
- E-Mail: | -
- M_Ret...@lis.e-technik.tu-muenchen.de | -
---------------------------------------------------------------------
Kim. Jae-Yong
Thank you Dunkan and Markus..
You mean vendor-independency is only in synthsis of behavioral description..
now I can grasp some concept...
in fact, I had no chance to use synthesis tool...
thanks...
John Cooley
Kim. Jae-Yong <k...@widecomm.korea.ac.kr> wrote:
>
>Whenever I learn VHDL, it is always said that using VHDL, We can design
>independently from vendor.....
>
>but I can hardly understand ...
>
>I think we can change library of the vendor when we design with schematic
>and if we should change schematic when switch vendor, VHDL code should also be
>changed... I guess..
>
>Why does it become vendor-independent..?
Kim, you're right. VHDL really isn't all that independant at all because
it was implemented by each EDA company in a slightly different manner.
The biggest fights between the various flavors of VHDL simulators come
from the simulator-vendor's own private VHDL packages. That is,
ViewLogic is slightly different than Synopsys which is slighly
different than Cadence which is slightly different than Model Tech.
And nobody quite understands Mentor's QuickSim "VHDL", either! :^)
The irony here is that because VHDL was an "open language" it has
the most brand-specific dialects; while because Verilog was wholey
owned by Cadence/Gateway, Verilog is the least variant. (That is,
all the competing Verilog simulation vendors have always had to
remain compatible with what Cadence has said constitutes Verilog,
pretty much.) In other words, the "open" VHDL is less portable
than the once "closed" Verilog.
- John Cooley
Part Time EDA Consumer Advocate
Full Time ASIC, FPGA & EDA Design Consultant
P.S. Also, don't be fooled by VHDL libraries/packages that start with
"IEEE" -- even some of these are proprietary to Synopsys!
===========================================================================
Trapped trying to figure out a Synopsys bug? Want to hear how 4599 other
users dealt with it ? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jco...@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
Janick Bergeron
In article <E1ws5...@world.std.com>,
John Cooley <jco...@world.std.com> wrote:
>Kim, you're right. VHDL really isn't all that independant at all because
>it was implemented by each EDA company in a slightly different manner.
>In other words, the "open" VHDL is less portable
>than the once "closed" Verilog.
Com'on John, be fair: I have right here, under my right elbow, Chapter
6 of the VCS Version 3.1 reference manual titled "Compatibility
Considerations". They list 32 different points that VCS either does
not support or that could yield different simulation results from
Verilog-XL. And our vendor-independent Verilog class notes are
littered with footnotes highlighting discrepancies between Verilog
simulator behaviors.
At least, with VHDL, once you are past the compile-time discrepancies
(you can simply compile EDA vendor A's packages in the environment
from EDA vendor B), bug-free (yeah, right!) VHDL simulators will yield
the same results (as long as you don't use shared variables -- but
since there is only 1 truly VHDL-93 simulator out there, that's not
likely)
>P.S. Also, don't be fooled by VHDL libraries/packages that start with
>"IEEE" -- even some of these are proprietary to Synopsys!
Yes, that's one of my biggest beef. To keep all those packages straight,
I recommend you take two of our 1164 package quick reference cards
(ftp://ftp.qualis.com/pub/qrcs/1164pkg.ps) and a good night of rest.
Call me in the morning of the headaches persist... on second thought,
the WILL persist so don't call me :-)
--
Janick Bergeron Qualis Design Corporation Ph.: (503) 644-9700
Director of PO Box 4444 Fax: (503) 643-1583
Technology Beaverton, OR, USA, 97075-4444 jan...@qualis.com
VHDL - Verilog - Synthesis - Modelling - Verification - Training
John Cooley
Janick Bergeron <jan...@qualis.com> wrote:
>John Cooley <jco...@world.std.com> wrote:
>>Kim, you're right. VHDL really isn't all that independant at all because
>>it was implemented by each EDA company in a slightly different manner.
>>than the once "closed" Verilog.
>
>Com'on John, be fair: I have right here, under my right elbow, Chapter
>6 of the VCS Version 3.1 reference manual titled "Compatibility
>Considerations". They list 32 different points that VCS either does
>not support or that could yield different simulation results from
>Verilog-XL. And our vendor-independent Verilog class notes are
>littered with footnotes highlighting discrepancies between Verilog
>simulator behaviors.
Janick, that comparision (between VCS & Verilog-XL) doesn't hold
up because one's a *compiled* form of Verilog while another is
an *interpreted* form of Verilog. Believe me, I know that the
Chrono whiz kids tried to be as compatable as possible with
Cadence's Verilog-XL because they wanted to sell VCS into XL
user sites! Each time the Chrono kids had to do something that
wasn't compatible with XL, it hurt -- but they did it to
make the VCS compiled Verilog acceleratable. That is, even if
Cadence itself made a compiled Verilog, Cadence, too, would have
to diverge off of what the *interpreted* Verilog-XL did as a
standard.
And don't even *try* to compare cycle-based Verilog (or VHDL) simulators
against compiled & interpreted ones! (Can we say "Apples to Oranges
to Bicycles?") :^)
>At least, with VHDL, once you are past the compile-time discrepancies
>(you can simply compile EDA vendor A's packages in the environment
>from EDA vendor B), bug-free (yeah, right!) VHDL simulators will yield
>the same results (as long as you don't use shared variables -- but
>since there is only 1 truly VHDL-93 simulator out there, that's not
>likely)
That shows my point exactly: there's only *one* VHDL-93 compliant
simulator around -- yet this was an open stand developed *years*
ago! You can't even mix that simulator with the others -- even
though it's supposedly following a standard (Ha!) (Heck, I'll bet
you that whoever makes the second VHDL-93 compliant sim will *still*
have an nice long compatibility errata sheet for users trying to port
to the *first* VHDL-93 compliant simulator!)
And I wonder how many quirky, proprietary VHDL libs/packages will
be spawned from this new class of VHDL simulators? :^)
- John Cooley
Part Time EDA Consumer Advocate
Full Time ASIC, FPGA & EDA Design Consultant
===========================================================================
Jim Lewis
John,
You are no longer a little mouth in a big world.
Don't you feel at least a little irresponsible posting
things like this. Is this what it takes to make verilog
more accepted than VHDL?
Personally although I am heavily tied to VHDL,
I don't really care which I use - they both have
their problems - yet - they are both a heck of alot better
then gate bashing. Although, I am hopeful that something better
will come along that replaces both.
By the way, the arithmetic confusion that currently exists
in VHDL will go away once NUMERIC_STD is accepted and implemented
by the major synthesis vendors.
Cheers,
Jim
--
------------------------------------------------------------------------
Jim Lewis | http://www.teleport.com/~telejim
ASIC and VHDL Consultant | tel...@teleport.com
On-site and Off-site Design, | 503-590-4787 (W)
Problem Solving, and Training | 503-590-2490 (H)
Janick Bergeron
In article <E20Av...@world.std.com>,
John Cooley <jco...@world.std.com> wrote:
>Janick, that comparision (between VCS & Verilog-XL) doesn't hold
>up because one's a *compiled* form of Verilog while another is
>an *interpreted* form of Verilog.
implementation "detail". In the end, both perform a simulation.
I used VCS simply because I had that information handy (it WAS under
my right elbow). I can point out similar discrepancies between XL and
Viper, Veriwell, and Silos-III. All are interpreted. I'm sure Veribest,
Frontline, and the others have differences too.
> Believe me, I know that the
>Chrono whiz kids tried to be as compatable as possible with
>Cadence's Verilog-XL because they wanted to sell VCS into XL
>user sites! Each time the Chrono kids had to do something that
>wasn't compatible with XL, it hurt -- but they did it to
>make the VCS compiled Verilog acceleratable. That is, even if
>Cadence itself made a compiled Verilog, Cadence, too, would have
>to diverge off of what the *interpreted* Verilog-XL did as a
>standard.
The Chrono guys did a great job. The problem is with the semantics of
the Verilog language which allows these differences in the first
place. Even Cadence states, in the XL documentation, that the
behavior of a simulation may change from release to release, and depending
on the options you use (we have a model right here that fails if you don't use
+turbo+2 but passes otherwise). Simply because the event ordering may
change.
>And don't even *try* to compare cycle-based Verilog (or VHDL) simulators
>against compiled & interpreted ones! (Can we say "Apples to Oranges
>to Bicycles?") :^)
I would not hesitate to compare _final simulation results_, as long as
there are no timing violations in the register-to-register paths in
the CBS-accelerated models: They better match. And they better not require
change in source code either (of course, they'll require a change in the way
the design is done to take full advantage of CBS).
>That shows my point exactly: there's only *one* VHDL-93 compliant
>simulator around -- yet this was an open stand developed *years*
>ago! You can't even mix that simulator with the others -- even
>though it's supposedly following a standard (Ha!)
Sad isn't it? If you remember, that was one of the points I made at
the user's panel at the Fall VIUF in Boston. I wholeheartedly agree
with you on that one. Similar problems now occur with OVI/1364
compliance in the Verilog world. Doesn't bode well for VHDL-98 or
Verilog-2000, does it?
>And I wonder how many quirky, proprietary VHDL libs/packages will
>be spawned from this new class of VHDL simulators? :^)
Probably as many proprietary PLI routines packages as we have right now! :-)
John Cooley
Jim Lewis <jimx_...@ccm.jf.intel.com> wrote:
>John,
> You are no longer a little mouth in a big world.
>Don't you feel at least a little irresponsible posting
>things like this. Is this what it takes to make verilog
>more accepted than VHDL?
>
> Personally although I am heavily tied to VHDL,
>I don't really care which I use - they both have
>their problems - yet - they are both a heck of alot better
>then gate bashing. Although, I am hopeful that something better
>will come along that replaces both.
Jeepers-creepers, Jim, I can't say one word about the history of
the two languages and how that's shaped our EDA world today without
being accused of some sort of conspiracy! Jeez! I use *both*
languages quite regularly. If it's any conselation, the recent
project I've been working on is a 400k gate *VHDL* based ASIC.
I think I've earned the right to be able to discuss the two
languages in a knowlegable manner, no? Aaargh!
> By the way, the arithmetic confusion that currently exists
>in VHDL will go away once NUMERIC_STD is accepted and implemented
>by the major synthesis vendors.
Great! -- now *another* package to support! :^) On the serious
side, I have no idea what's in this propsed new VHDL package -- if
it does "everything", great! -- then it's only a problem of trying
to get *all* the users and *all* the EDA vendors to migrate to
this new package *plus* their getting rid of their old packages.
I see this task is somewhat simular to trying to herd cats. It
will be fun to watch.
John Cooley
Janick Bergeron <jan...@qualis.com> wrote:
>John Cooley <jco...@world.std.com> wrote:
>>Janick, that comparision (between VCS & Verilog-XL) doesn't hold
>>up because one's a *compiled* form of Verilog while another is
>>Chrono whiz kids tried to be as compatable as possible with
>>Cadence's Verilog-XL because they wanted to sell VCS into XL
>>user sites! Each time the Chrono kids had to do something that
>>wasn't compatible with XL, it hurt -- but they did it to
>>make the VCS compiled Verilog acceleratable. That is, even if
>>Cadence itself made a compiled Verilog, Cadence, too, would have
>>to diverge off of what the *interpreted* Verilog-XL did as a
>>standard.
>
>I think the comparison does hold up. Interpreted vs compiled is just an
>implementation "detail". In the end, both perform a simulation.
>I used VCS simply because I had that information handy (it WAS under
>my right elbow). I can point out similar discrepancies between XL and
>Viper, Veriwell, and Silos-III. All are interpreted. I'm sure Veribest,
>Frontline, and the others have differences too.
>
>The Chrono guys did a great job. The problem is with the semantics of
>the Verilog language which allows these differences in the first
>place. Even Cadence states, in the XL documentation, that the
>behavior of a simulation may change from release to release, and depending
>on the options you use (we have a model right here that fails if you don't use
>+turbo+2 but passes otherwise). Simply because the event ordering may
>change.
I agree, there are slight differences in the implementations of
interpreted Verilog from the varios vendors -- but this list of
differences is quite small compared to contrasting an interpreted
Verilog vs. a compiled Verilog. You hit the target right on when
you noted that "even Cadence states, in the XL docs, that the
behavior of a simulation may change from release to release." -- but
these differences *pale* in comparision to the way various VHDL
simulators behave with completely different implementations *and*
completely different VHDL libs/packages (each proprietary to a
particular EDA company.)
Let me put it another way. Because Frontline wants to sell in the
Verilog market, it makes sure it offers a simulator with the
least amount of headaches going to/from Cadence Verilog. Because
Model Tech wants to do the same, it, too, makes sure the to/from
path with Cadence Verilog is the least painful. That is, each
Verilog vendor has only to be compatible with Cadence Verilog to
be acceptable in the market. With VHDL, there is no one dominant
vendor, hence that world is a mishmash of compatiblity problems.
And I was just sighting how ironic that a supposedly "open"
language from its beginnings (VHDL) had the most compatibility
issues, while an originally "closed" language (Verilog) has the
least because all contenders must be compatible with Cadence's
Verilog. (Isn't the whole idea behind liking "open" standards
is that it'll encourage more companies to make products *compatible*
to it? That's the irony I see.)
Jim Lewis
John,
> Can't I even discuss the basic working & history of these two
> languages without being accused of some evil intent?
Let me see, perhaps I misunderstood you.
In the first paragraph are you saying not all
the tools understand the language the same way?
Or are saying that not all of the simulators
support std_logic_1164? Perhaps you are referring
the the math packages?
As a responsible "EDA consumer advocate", if you are
referring to the math packages, maybe you should also
point out that standardization of a math package
is in the works. We need people like you to help
put pressure on the EDA vendors to accept standards.
The second paragraph, cool, now you want to pursue the
path that verilog is more portable than VHDL. :^)
Perhaps just your subconsious hates VHDL.
> evil intent?
Interesting concept.
Since I consider the V vs. V fight that you just initiated "evil",
then I guess you answered your own question.
By the way, I reviewed the previuos posts, there was no intent
anywhere in comparing VHDL features with Verilog. I believe the
thread started more from a gate level perspective.
> By the way, the arithmetic confusion that currently exists
> in VHDL will go away once NUMERIC_STD is accepted and implemented
> by the major synthesis vendors.
You can check out the NUMCERIC_STD at:
ftp://vhdl.org/vi/vhdlsynth/numeric_std.vhd
http://vhdl.org/vi/vhdlsynth/vhdlsynth.html
You might also want to check out Janick's / Qualis's package
that Janick referred to:
(ftp://ftp.qualis.com/pub/qrcs/1164pkg.ps)
It will help you sort out the confusion/frustration you
may be having.
Cheers,
Jim Lewis
Dennis McCrohan
>Jim Lewis wrote:
>
> John,
>> You are no longer a little mouth in a big world.
>> Don't you feel at least a little irresponsible posting
>> things like this. Is this what it takes to make verilog
>> more accepted than VHDL?
>
>
I don't think that John is long in the mouth at all. The truth
is that the very long historical progression from VHDL-87 (with
bit and bit_vector) to 1076.3 (numeric_std) has opened up a
tremendous compatibility whole between synthesis tools that I
see users struggle with everyday. And 1076.3 requires VHDL-93,
which certain large EDA vendors show no signs of supporting this
millenium. In fact, we have probably reached the point of code
non-portability between VHDL tool vendors that it becomes an
economic advantage for those with existing market share.
Obviously NOT the opinion of my employer, which usually doesn't
know if it has one...
-dm
Bernd Paysan
John Cooley wrote:
> (Isn't the whole idea behind liking "open" standards
> is that it'll encourage more companies to make products *compatible*
> to it? That's the irony I see.)
No, the whole idea of "open" standards is to encourage many companies to
make *incompatible* products, that just look as if they were compatible.
Welcome to the Dilbert world ;-).
BTW: I don't have the experiences that Verilog can't cause compatibility
headaches. I once tried Synopsis Design Analyzer to synthesize a small
part of my design, which was perfectly synthesizable with Cadence's
Synergy. DA complained about `ifdef's (what's the use of a preprocessor
if you can't use it for synthesis?) and about mixing <= and = in one
block, although it can handle the latter situation in VHDL well (signal
and wire assignments).
--
Bernd Paysan
"Late answers are wrong answers!"
http://www.informatik.tu-muenchen.de/~paysan/
Janick Bergeron
In article <E25q9...@world.std.com>,
John Cooley <jco...@world.std.com> wrote:
>these differences *pale* in comparision to the way various VHDL
>simulators behave with completely different implementations *and*
>completely different VHDL libs/packages
I don't understand how, say Leapfrog - a native compiled VHDL
simulator, would behave differently (i.e. produce different results)
than, say VSS which is, by default, an interpreted simulator. I grant
you that if you use these tools out-of-the-box, Leapfrog will choke on
any source code using the STD_LOGIC_ARITH package from Synopsys. But
if you've nuked the Leapfrog STD_LOGIC_ARITH package and replaced it
with Synopsys's, a bug-free (ha!) simulator will not behave
differently. The difference in behavior is only transient and easily
permanently fixed.
The only thing that Cadence and Mentor did, by naming their package
the same as Synopsys, was to ensure that they would be
obliterated.
Which would you rather have in a 10,000 line HDL model: a definite
compile-time error pointing out that it cannot resolve a reference, or
a possible run-time error that *might* cause your testcase to fail
without indication of what caused it?
>Let me put it another way. Because Frontline wants to sell in the
>Verilog market, it makes sure it offers a simulator with the
>least amount of headaches going to/from Cadence Verilog. Because
>Model Tech wants to do the same, it, too, makes sure the to/from
>path with Cadence Verilog is the least painful. That is, each
>Verilog vendor has only to be compatible with Cadence Verilog to
>be acceptable in the market.
But there is absolutely NO WAY to be 100% compatible with Verilog-XL
unless you reverse engineer the algorithm it uses during simulation to
replicate *exactly* how it simulates those unspecified portion of the
language. To do that, you need an XL license which states that you
cannot reverse-engineer the product. Given Cadence's track record,
wouldn't they go after any EDA vendor who sells a simulator which is a
reverse engineering of XL?
That said, it is possible to write Verilog code that will be portable
to any simulator and will simulate with identical results. But the
onus is on the modeler who must be disciplined enough to stay without
the bounds of several guidelines. That discipline does not come easily,
nor are those guidelines immediately obvious when you learn Verilog.
That's why I groan when I hear people say that Verilog is so much
easier to learn than VHDL: as far as the syntax goes, it is true, but
the amount of learning that is required to write a "good" model (good
= correct, readable, maintainable, portable, reliable) is about the
same in either language. VHDL's learning curve is definitely steeper
but Verilog's goes on for much longer. Neither is really better than
the other.
--
Janick Bergeron Qualis Design Corporation Ph.: (503) 350-3663
Morris Jones
It seems we are confusing a language with a library. Each vendor makes what it will of the libraries, and we whine about
compatability. The VHDL LRM is very specific about what the simulator should do. If we all want packages that work the same,
we should only use "Standard" ones. Each EDA tool vendor has deficiencies, and they compensate for them with special
libraries. You only have to look at the mangling Syn*** did to the 1164 library to know what I mean
Just my $.02
Morris
David Brier
Janick Bergeron wrote:
>
> In article <E25q9...@world.std.com>,
> John Cooley <jco...@world.std.com> wrote:
> >these differences *pale* in comparision to the way various VHDL
> >simulators behave with completely different implementations *and*
> >completely different VHDL libs/packages
>
> I don't understand how, say Leapfrog - a native compiled VHDL
> simulator, would behave differently (i.e. produce different results)
> than, say VSS which is, by default, an interpreted simulator. I grant
> you that if you use these tools out-of-the-box, Leapfrog will choke on
> any source code using the STD_LOGIC_ARITH package from Synopsys. But
> if you've nuked the Leapfrog STD_LOGIC_ARITH package and replaced it
> with Synopsys's, a bug-free (ha!) simulator will not behave
> differently. The difference in behavior is only transient and easily
> permanently fixed.
>
> The only thing that Cadence and Mentor did, by naming their package
> the same as Synopsys, was to ensure that they would be
> obliterated.
>
usually the package that causes the problem. With the STD_LOGIC_ARITH
package, Mentor put the Synopsys package in the same place (IEEE) and
called it the same (STD_LOGIC_ARITH), Cadence on the other hand has
maintained thier own package in that place that has no resemblence to
the Synopsys package. Therefore Leapfrog is more difficult to use than
eithere Quickhdl (Vsystem?), or VSS.
In the models that I have been running, once the change (obliteration
Janck mentions) is accomplished, Leapfrog and Quickhdl give similar
results. With the exception of the 93 standard both simulate correctly
for my designs. Therefore I have two simulators that I feel relatively
comfortable with.
If you want to go to the Verilog comments that John has made, yes
Gateway/Cadence established the Verilog standard and everyone strives to
correlate with Verilog XL. In VHDL, most of the specific comments have
been based upon compatibility with the arithmetic packages. There is a
similar situation that has occured here. Syonpsys created the first
arithmetic package, and those simulators that have adopted that package
work well with Design Compiler. I have not seen anyone commment on a
simulator not working with std_logic_1164. Therefore if you stick with
"nuking" the arithmetic package found in Leapfrog, then I think that you
have 3 simulators that work well on the same code.
As for the future of the IEEE standards, both '93 and arithmetic, it's a
good movement, just like the standardization of the synthesizable
sub-set, but if a tree falls in the woods and no one is around to hear
it, does it make a noise, or more importantly does anyone care. What I
am getting at is Synopsys owns the synthesis market for now, if they
don't support and whole heartedly get behind these standards, no one
will use them for any designs that are going to gates, there is just too
much work involved in putting a desing together to play the game of
changing your code.
I don't know for certain, but I would guess that the STD_LOGIC_ARITH
package that Leapfrog uses probably works with Synergy (Cadence's
synthesis tool?), Mentor had a similar situation a while ago, but now
there is no problem, Autologic uses the "standard" STD_LOGIC_ARITH
package without headaches, therefore some vendors have differentiated
themselves by merging the process so that the users will not have
problems.
Chong Guan Tan
Janick Bergeron wrote:
>
> In article <E20Av...@world.std.com>,
> John Cooley <jco...@world.std.com> wrote:
> >Janick, that comparision (between VCS & Verilog-XL) doesn't hold
> >up because one's a *compiled* form of Verilog while another is
> >an *interpreted* form of Verilog.
> implementation "detail". In the end, both perform a simulation.
> I used VCS simply because I had that information handy (it WAS under
> my right elbow). I can point out similar discrepancies between XL and
> Viper, Veriwell, and Silos-III. All are interpreted. I'm sure Veribest,
> Frontline, and the others have differences too.
>
> > Believe me, I know that the
> >Chrono whiz kids tried to be as compatable as possible with
> >Cadence's Verilog-XL because they wanted to sell VCS into XL
> >user sites! Each time the Chrono kids had to do something that
> >wasn't compatible with XL, it hurt -- but they did it to
> >make the VCS compiled Verilog acceleratable. That is, even if
> >Cadence itself made a compiled Verilog, Cadence, too, would have
> >to diverge off of what the *interpreted* Verilog-XL did as a
> >standard.
> The Chrono guys did a great job. The problem is with the semantics of
> the Verilog language which allows these differences in the first
> place. Even Cadence states, in the XL documentation, that the
> behavior of a simulation may change from release to release, and depending
> on the options you use (we have a model right here that fails if you don't use
> +turbo+2 but passes otherwise). Simply because the event ordering may
> change.
>
contributed to
VCS, I have something to say:
1) Many of the incompatibility in VCS, at least until the day when I
walked out
of viewlogic, was due to behavoir we haen't quite figured out, or
Verilog-XL
did what it said it didn't, or due to something that does not make sense
in
Verilog-XL. A major class of incompatiblity is is race conditions which
already
well understood.
2) Due to the compiled code nature of VCS, some of the informations are
just
not available during simulation, therefore causing incompatibility issue
for
CLI and PLI in some area.
> >And don't even *try* to compare cycle-based Verilog (or VHDL) simulators
> >against compiled & interpreted ones! (Can we say "Apples to Oranges
> >to Bicycles?") :^)
> I would not hesitate to compare _final simulation results_, as long as
> there are no timing violations in the register-to-register paths in
> the CBS-accelerated models: They better match. And they better not require
> change in source code either (of course, they'll require a change in the way
> the design is done to take full advantage of CBS).
>
> >That shows my point exactly: there's only *one* VHDL-93 compliant
> >simulator around -- yet this was an open stand developed *years*
> >ago! You can't even mix that simulator with the others -- even
> >though it's supposedly following a standard (Ha!)
> Sad isn't it? If you remember, that was one of the points I made at
> the user's panel at the Fall VIUF in Boston. I wholeheartedly agree
> with you on that one. Similar problems now occur with OVI/1364
> compliance in the Verilog world. Doesn't bode well for VHDL-98 or
> Verilog-2000, does it?
>
> >And I wonder how many quirky, proprietary VHDL libs/packages will
> >be spawned from this new class of VHDL simulators? :^)
> Probably as many proprietary PLI routines packages as we have right now! :-)
>
I would agree with John that the Verilog simulators, not including the
cycle based one,
are more compatible than VHDL simulators, based on 2 reason:
1) all Verilog clones try they very best to make themselves compatible
to Verilog-XL.
none can be said on VHDL.
2) When you switch from one Verilog simulator to another, you have
information on what
is ahead of you. Try to switch from Synopsys VSS to model tech on your
real
world design and enjoy the fun. (please don't use some dinky toy design
as counter
example)
tan
silicon-sorcery
> --
> Janick Bergeron Qualis Design Corporation Ph.: (503) 644-9700
Erik Jessen
Chong Guan Tan,
I have to disagree with you.
1) I talked to a guy at Logic Modelling; he said that as long as they
could get VHDL code to compile, they always go the same results on all
their simulators (unless they found a bug).
2) With Verilog, they would often get different results, and have a
difficult time documenting why. Worse:
a) You couldn't make a change to be compatible with one simulator, and be
sure you weren't breaking another
b) Just because the code worked with tool A (version X) and tool B
(version Y), doesn't mean that it will work with versions X+1 or Y+1.
This is a critical issue, as soon as you start dealing with the idea of
IP reuse, and selling libraries.
Second, as a personal experience: I designed a chip using Leapfrog and
Modeltech; I simply redefined my 'IEEE' libraries locally to point to
Synopsys' code, and then all the code compiled fine in all tools. VHDL
has only a library issue (which isn't part of the spec), not a language
function issue. Plus, the library issue is easy to work around.
So, if you are a small house, and not planning to share code, and you can
stick with one simulator, then Verilog and VHDL are equivalent in this.
However, if someone offsite is going to use your code, or you are going
to run it on multiple simulators, or you are going to support it over
multiple revs of the same simulator. then you should think hard about
using Verilog.
Erik
Chong Guan Tan
Erik Jessen wrote:
>
> Chong Guan Tan,
> I have to disagree with you.
>
> 1) I talked to a guy at Logic Modelling; he said that as long as they
> could get VHDL code to compile, they always go the same results on all
> their simulators (unless they found a bug).
get
it to compile" ? I got this assignment at one time, the junk was in
model tech VHDL, the "owner" have tried hard to use other tool to no
vail,
and I have to admit I have no gut to try it on VSS. (well, I did not
take
that assignment eventually)
>
> 2) With Verilog, they would often get different results, and have a
often ? Please base your claim on solid data. Chronologic alone is
selling
more Verilog simulators than the big 3 VHDL combined, and if breaks
often,
are you claiming that VCS users are bunch of dummy ?
> difficult time documenting why. Worse:
> a) You couldn't make a change to be compatible with one simulator, and be
> sure you weren't breaking another
> b) Just because the code worked with tool A (version X) and tool B
> (version Y), doesn't mean that it will work with versions X+1 or Y+1.
for a), the simplest answer : you have gotten a HW race somewhere. For
b,
see a. If you think your original claim of "getting the design to
compile"
is a good answer, please aplly to b).
Erik Jessen
Chong,
Some notes:
1) Where I have not said "I", the person speaking is an LMC employee speaking about the difficulties in
supporting multiple VHDL and Verilog simulators.
2) As I said, with VHDL, if the code compiled, they got the same result.
3) As I said, with Verilog, even if the code compiled, they would not always get the same result.
4) I cannot give you data on (2) and (3); I don't have it, and it is proprietary to LMC in any case.
5) My comments are not on market share, sales dollars, or anything else. I am simply relaying statements made
to me, from a company that I think has experience supporting many tools, both VHDL and Verilog.
6) I am not claiming VCS users are a bunch of dummies; every person makes their own decisions on why to buy a
tool. Price, prior knowledge of the tool, compatibility with suppliers/vendors, etc. etc. all factor into the
equation.
7) I am not claiming that ALL VHDL simulators are bug-free, nor am I claiming that ALL Verilog simulators have
bugs and will never produce the same results.
Please review my statements again.
Erik
Russ Vreeland
In article <E25q9...@world.std.com> jco...@world.std.com (John Cooley) writes:
>Janick Bergeron <jan...@qualis.com> wrote:
>>John Cooley <jco...@world.std.com> wrote:
>>>Janick, that comparision (between VCS & Verilog-XL) doesn't hold
>>>up because one's a *compiled* form of Verilog while another is
>>>Chrono whiz kids tried to be as compatable as possible with
>>>Cadence's Verilog-XL because they wanted to sell VCS into XL
>>>user sites! Each time the Chrono kids had to do something that
>>>wasn't compatible with XL, it hurt -- but they did it to
>>>make the VCS compiled Verilog acceleratable. That is, even if
>>>Cadence itself made a compiled Verilog, Cadence, too, would have
>>>to diverge off of what the *interpreted* Verilog-XL did as a
>>>standard.
>>
>>I think the comparison does hold up. Interpreted vs compiled is just an
>>implementation "detail". In the end, both perform a simulation.
>>I used VCS simply because I had that information handy (it WAS under
>>my right elbow). I can point out similar discrepancies between XL and
>>Viper, Veriwell, and Silos-III. All are interpreted. I'm sure Veribest,
>>Frontline, and the others have differences too.
>>
>>The Chrono guys did a great job. The problem is with the semantics of
>>the Verilog language which allows these differences in the first
>>place. Even Cadence states, in the XL documentation, that the
>>behavior of a simulation may change from release to release, and depending
>>on the options you use (we have a model right here that fails if you don't use
>>+turbo+2 but passes otherwise). Simply because the event ordering may
>>change.
>
>interpreted Verilog from the varios vendors -- but this list of
>differences is quite small compared to contrasting an interpreted
>Verilog vs. a compiled Verilog. You hit the target right on when
>behavior of a simulation may change from release to release." -- but
>these differences *pale* in comparision to the way various VHDL
>simulators behave with completely different implementations *and*
>particular EDA company.)
>
>Verilog market, it makes sure it offers a simulator with the
>least amount of headaches going to/from Cadence Verilog. Because
>Model Tech wants to do the same, it, too, makes sure the to/from
>path with Cadence Verilog is the least painful. That is, each
>Verilog vendor has only to be compatible with Cadence Verilog to
>vendor, hence that world is a mishmash of compatiblity problems.
>And I was just sighting how ironic that a supposedly "open"
>language from its beginnings (VHDL) had the most compatibility
>issues, while an originally "closed" language (Verilog) has the
>least because all contenders must be compatible with Cadence's
>is that it'll encourage more companies to make products *compatible*
>to it? That's the irony I see.)
>
> Part Time EDA Consumer Advocate
> Full Time ASIC, FPGA & EDA Design Consultant
>
at the idea that VHDL is supposedly "incompatible" from vendor to
vendor when all the complaints about it have zeroed in on the real
incompatibility problem, the use of different packages with the same
or similar names.
True, Synopsys is the the 900-pound gorilla that sits anywhere it wants
and therefore anyone doing synthesis with IEEE 1164 data types, using
Synopsys will have to remember 3, possibly 4 facts on what won't work
when going from vendor to vendor. We've managed to steer clear of some
of the confusiong by adding a couple "dummy" packages to the bona fide
IEEE 1164 packages (std_logic_signed and std_logic_unsigned) so that
users don't have to edit their source files when going from Synopsys to
Cadence or Mentor during simulation. That and avoiding the conversion
functions that are Synopsys-unique are usually enough to keep things
compatible. Of course, during an RTL development phase, the tools are
usually fixed, and thus one set of packages ought to be used and stuck
with.
This whole problem is a package problem. VHDL has nothing to do with
these packages - they are add-ons from the IEEE and vendors. VHDL was
designed to be a high-level, "growable" language. No need for PLIs, etc.
Equally suited for stock market prediction, Denver baggage handling
simulations as for hardware design. Janick is right when he focuses in
on the question: 'will the simulation work the same between vendors when
everything is equal (including using exactly the same packages in VHDL)?
The answer for VHDL is unequivocably yes, but as far as my layman's
experience with Verilog goes, the answer is no for Verilog - the ill
defined behavior of a Verilog UDP as compared to the deterministic
behavior of a VITAL State Table is one example.
By the way, I like Verilog (it's so small and quaint!) - let a thousand
flowers bloom! Well, 2 anyway. But be accurate about the subject matter.
--
*****************************************************************
* R.E.Vreeland TRW Space & Engineering Group *
* (310) 814-6688 ru...@emu.sp.trw.com *
* TRW probably disagrees with me, if its lawyers are on the ball*
John Williams
The biggest problem I've had with verilog comes from inexperienced
users, who leave all sorts of race conditions in their code. OK, it's true,
Verilog lets you write code with race conditions up the you know what.
I suspect your friends at LMC use zero delay quite a bit, which can be very
challenging. I think they need to rethink their approach if they're running
into constant race conditions that evaluate differently under different
architectures. I've successfully written many zero delay models.
I also know that some side effects can't be counted on, in particular,
?: is a shortcut in Verilog-XL, but is not shortcut ( both are evaluated )
in VCS. Your friends at LMC most likely use lots of side effects. The only
side effect I count on is the atomic execution of a block segment between
events. I don't use a mutex unless I need to span events or time.
The problem with race conditions exists with all simulators. I have to admit
I would be happier if side effects were more consistent. What I have trouble
with concerning VHDL is the verbosity which obscures and makes more difficult
the process of writing good code. I want to get past the syntax quickly and
get straight to the algorithm.
John Williams