SYNOPSYS simulation question
Eric Allen Stonehouse
of mine. Can any of you SYNOPSYS gurus tell me how to "assign" a hex value
to a signal so I can simulate my code in VHDLDBX.
I know in ViewLogic its just x"FFFF", but I cannot figure out how to do it
using SYNOPSYS.
Thanks in Advance,
Eric Stonehouse
gt7...@prism.gatech.edu
--
Eric Allen Stonehouse
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt7382f
Internet: gt7...@prism.gatech.edu
Andrew Rushton
> I am trying to simulate various VHDL entities using SYNOPSYS for a class
> of mine. Can any of you SYNOPSYS gurus tell me how to "assign" a hex value
> to a signal so I can simulate my code in VHDLDBX.
> I know in ViewLogic its just x"FFFF", but I cannot figure out how to do it
> using SYNOPSYS.
It should be the same. VHDL is VHDL regardless of the simulator (ho ho, if you
believe that, you'll believe anything :-)). If this works with one and not the
other, then one of the two simulators must have a bug. You don't provide enough
of the example for me to tell which.
Some guidelines just so you can diagnose the problem:
x"FFFF" is a "bit-string" value, so can *only* be used to assign to arrays
of bit (assuming VHDL'87) or any character type with the values '0' or
'1' (assuming VHDL'93).
this gives a 16-bit result and so can *only* be assigned to a 16-bit
signal.
Note that this excludes assignemnt to signals of integer types, for
which you would use based integers, e.g. 16#FFFF#.
Thus, if one simulator is allowing the assignment of a bit-string to an integer,
then that simulator is at fault. Alternatively, if one simuator is not allowing
you to use bit-strings with bit arrays, then it is that one which is at fault.
I hope this helps...
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- Andy Rushton #8-) email a...@transeda.demon.co.uk --
-- TransEDA Limited tel. +44-1703-255118 --
-- UK fax. +44-1703-270278 --
-- assert opinion report "mine, not TransEDA's" severity note; --
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Andrew Hana
: I am trying to simulate various VHDL entities using SYNOPSYS for a class
You don't say what type your signal is.
How about
library ieee;
use ieee.std_logic_1164.all
use ieee.std_logic_arith.all;
entity ......
architecture ....
signal integer_signal : integer;
signal vector_signal : std_logic_vector(15 downto 0);
begin
integer_signal <= 16#04FD#;
vector_signal <= CONV_STD_LOGIC_VECTOR(16#04FD#, 16);
end example;
Note that form 16#04FD# represents an integer quantity.
The CONV_STD_LOGIC_VECTOR() function is in the std_logic_arith package and
converts and integer to a std_logic_vector.
I hope this helps.
Andrew Hana
Hewlett Packard
Matthew Todd Gavin
|> On 14 Feb 1995, Eric Allen Stonehouse wrote:
|>
|> > I am trying to simulate various VHDL entities using SYNOPSYS for a class
|> > of mine. Can any of you SYNOPSYS gurus tell me how to "assign" a hex value
|> > to a signal so I can simulate my code in VHDLDBX.
I also have tried to assign hex strings such as x"ffff", and 0x"ffff",
and Synopsys doesn't like it. It only likes bit strings. (FYI, using
std_logic and std_logic_vector as types)
Please, can anyone definitively say if the Synopsys simulator accepts
hex string assugnments? I'm tired of "0101110010001000111101001"!!!!
Thanks,
Matt
--
*********************************************************
Matt Gavin BSEE U of Iowa '93
mtg...@uiuc.edu Go Iowa Hawks!!!!!
http://www.cen.uiuc.edu/~mg12861/matt.html
Andrew Rushton
> I also have tried to assign hex strings such as x"ffff", and 0x"ffff",
> and Synopsys doesn't like it. It only likes bit strings. (FYI, using
> std_logic and std_logic_vector as types)
>
> Please, can anyone definitively say if the Synopsys simulator accepts
> hex string assugnments? I'm tired of "0101110010001000111101001"!!!!
The answer was in my previous post, maybe you missed it. 8-)
These prefixed strings are known as "bit-string literals" and have three formats:
binary (B"111_000" etc - note the underscores are allowed), octal (O"1234_567")
and hex (X"FF_FF"). However, in VHDL'87 (nothing to do with Synopsys's
interpretation, but a part of the language definition LRM'87-13.7), these are
only allowed for arrays of type BIT. No other element type is supported. None!
However, in VHDL'93, any element type with '0' amd '1' values will be supported,
including any arrays of STD_LOGIC. Unfortunaly, widespread support of VHDL'93 is
not expected for quite some time - mainly because it offers almost nothing new
to synthesis users.
This means you ARE stuck with using "string literals", e.g.
"0101110010001000111101001" for the time being.
VhdlCohen
Std_Logic_Vector, you must use VHDL'93 which support the hex notation.
The other option is to use a conversion routine. Conversion will work in
VHDL, but probably not in Synopsys. I don't think that Synopsys uses
VHDL'93.
Daniel S. Barclay
-- assert opinion report "mine, not TransEDA's" severity note; --
You mean if it's _not_ option, we read "mine, not TransEDA's"? Sounds
possibly backwards. (But then most signature code can't be taken too
literally...)
Daniel
--
Daniel S. Barclay Compass Design Automation, Inc.
dan...@compass-da.com Suite 101, 5457 Twin Knolls Rd. Columbia, MD 21045 USA
"They listen hard, and act like they care.
How can they be so completely unaware
Of the truth? The answer is always denied me
So I introduce 'em to the killer inside me." - MC 900 Ft. Jesus
Sai Kennedy Vedantam
hex value (a bit vector type) to std_logic_vector type. For example:
# assign To_StdLogicVector(X"0FAB") SV
The semantics of the "assign" command are same as that of the signal/variable
assignment statements in the VHDL source code. So, if you can do something in
your VHDL code and pass the analyzer, then you can do the same for the assign
command too.
Hope that helps.
-Sai
In article <3iarpe$3...@vixen.cso.uiuc.edu>,
Matthew Todd Gavin <mg1...@eehpx21.cen.uiuc.edu> wrote:
>In article <Pine.SUN.3.90.95021...@transeda.demon.co.uk>, Andrew Rushton <a...@transeda.demon.co.uk> writes:
>|> On 14 Feb 1995, Eric Allen Stonehouse wrote:
>|>
>|> > I am trying to simulate various VHDL entities using SYNOPSYS for a class
>|> > of mine. Can any of you SYNOPSYS gurus tell me how to "assign" a hex value
>|> > to a signal so I can simulate my code in VHDLDBX.
>
>I also have tried to assign hex strings such as x"ffff", and 0x"ffff",
>and Synopsys doesn't like it. It only likes bit strings. (FYI, using
>std_logic and std_logic_vector as types)
>
>Please, can anyone definitively say if the Synopsys simulator accepts
>hex string assugnments? I'm tired of "0101110010001000111101001"!!!!
>
>Thanks,
>
> Matt
>
>--
------------------------
Std.Disclaimer: I am speaking for only myself and *NOT* for Synopsys
------------------------
--
-Sai
------------------------------------------------------------------------------
Sai Vedantam Synopsys Inc. ken...@synopsys.com
Matthew Todd Gavin
|> You can use the type conversion function To_StdLogicVector() to convert your
|> hex value (a bit vector type) to std_logic_vector type. For example:
|> # assign To_StdLogicVector(X"0FAB") SV
|> The semantics of the "assign" command are same as that of the signal/variable
|> assignment statements in the VHDL source code. So, if you can do something in
|> your VHDL code and pass the analyzer, then you can do the same for the assign
|> command too.
|> Hope that helps.
|> -Sai
|>
Thanks Sai! Yes, it works. I got some mail earlier today from someone
at Synopsys also, who also stated this.
Thanks everyone for your help!
Andrew Hana
: In article <Pine.SUN.3.90.95021...@transeda.demon.co.uk>, Andrew Rushton <a...@transeda.demon.co.uk> writes:
: |> On 14 Feb 1995, Eric Allen Stonehouse wrote:
: |>
: |> > I am trying to simulate various VHDL entities using SYNOPSYS for a class
: |> > of mine. Can any of you SYNOPSYS gurus tell me how to "assign" a hex value
: |> > to a signal so I can simulate my code in VHDLDBX.
: I also have tried to assign hex strings such as x"ffff", and 0x"ffff",
: and Synopsys doesn't like it. It only likes bit strings. (FYI, using
: std_logic and std_logic_vector as types)
How about
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
entity example is
port (A : out std_logic_vector( 16 downto 0)
);
end example;
architecture simple of example is
begin
A <= CONV_STD_LOGIC_VECTOR(16#E1D6#, 17);
end simple;
I have tried this in design analyzer and it works fine.
Andrew Hana
Hewlett Packard.
Bob Hatt
>On 20 Feb 1995, Matthew Todd Gavin wrote:
>> I also have tried to assign hex strings such as x"ffff", and 0x"ffff",
>> and Synopsys doesn't like it. It only likes bit strings. (FYI, using
>> std_logic and std_logic_vector as types)
>>
>> Please, can anyone definitively say if the Synopsys simulator accepts
>> hex string assugnments? I'm tired of "0101110010001000111101001"!!!!
>The answer was in my previous post, maybe you missed it. 8-)
>These prefixed strings are known as "bit-string literals" and have three formats:
>binary (B"111_000" etc - note the underscores are allowed), octal (O"1234_567")
>and hex (X"FF_FF"). However, in VHDL'87 (nothing to do with Synopsys's
>interpretation, but a part of the language definition LRM'87-13.7), these are
>only allowed for arrays of type BIT. No other element type is supported. None!
>However, in VHDL'93, any element type with '0' amd '1' values will be supported,
>including any arrays of STD_LOGIC. Unfortunaly, widespread support of VHDL'93 is
>not expected for quite some time - mainly because it offers almost nothing new
>to synthesis users.
>This means you ARE stuck with using "string literals", e.g.
>"0101110010001000111101001" for the time being.
Why not just pass this bit_vector (e.g. X"FFFF") to a function that
converts a bit_vector to a std_logic_vector ? This means you get something
like
a <= to_stdlogicvector(X"ffff");
where to_stdlogicvector is a function which converts a bit_vector
to a std_logic_vector. See the ieee.std_logic_1164 package.
Hope this helps.
-Bob Hatt
Summit Design Inc.
Matthew Todd Gavin
|> Andrew Rushton <a...@transeda.demon.co.uk> writes:
|> >On 20 Feb 1995, Matthew Todd Gavin wrote:
|>
|> >> I also have tried to assign hex strings such as x"ffff", and 0x"ffff",
|> >> and Synopsys doesn't like it. It only likes bit strings. (FYI, using
|> >> std_logic and std_logic_vector as types)
|> >>
|> >> Please, can anyone definitively say if the Synopsys simulator accepts
|> >> hex string assugnments? I'm tired of "0101110010001000111101001"!!!!
[snip]
|> >This means you ARE stuck with using "string literals", e.g.
|> >"0101110010001000111101001" for the time being.
|>
|>
|> Why not just pass this bit_vector (e.g. X"FFFF") to a function that
|> converts a bit_vector to a std_logic_vector ? This means you get something
|> like
|> a <= to_stdlogicvector(X"ffff");
|>
|> where to_stdlogicvector is a function which converts a bit_vector
|> to a std_logic_vector. See the ieee.std_logic_1164 package.
Yes, this works. I have been using this for a week or so with no probs.
Thanks!
Charles F. Shelor
> including any arrays of STD_LOGIC. Unfortunaly, widespread support of VHDL'93 is
> not expected for quite some time - mainly because it offers almost nothing new
> to synthesis users.
>
> This means you ARE stuck with using "string literals", e.g.
> "0101110010001000111101001" for the time being.
Personally, I am demanding that my synthesis vendor support VHDL '93!
Only 1/2 of the code that I write is for synthesis. The other is for
modeling and test benches. Am I supposed to deal with 4 language
versions? full '87, full '93, synthesizable '87 and synthesizable '93?
I am aware that some language features cannot be synthesized. As an
experienced designer I do not expect a synthesis tool to accept:
x <= y and z after 25 ns;
dynamic hardware via access types
parallel floating point division
etc, etc, etc.
However, I have a real problem with
generics not being supported
std_ulogic and std_ulogic_vector not being supported
q <= d when rising_edge(clock) else
'0' when reset = '1' else q;
not being recognized as a D-flip flop
These issues are not synthesis challenges, they are syntactic issues.
Any synthesis vendor that offers a full VHDL simulation should use
the same syntax and semantic analyzer for synthesis that they use
for simulation. Then the only features in VHDL that would not be
supported would be those items that could not be synthesized.
Listen Vendors! I will spend a lot more time trying to find a bit
error in a 32-bit or 64-bit binary vector constant than I will in
trying to shave another 1% gate count. Support of powerful language
features that enhance reusability, understanding, code reliability;
such as generics, functions, aliases, record data types, unresolved
data types, and ease of use will rank much higher than a couple of
percentage points in gate count. (Note the couple of percentage
points, I'm not advocating 25% larger gate arrays just to use an
alias!) I'm advocating full support of synthesizable features and
requesting that all vendors support VHDL '93 as quickly as they can.
OK, I'll yield the soap box to someone else.
Charles Shelor cfsh...@acm.org
SHELOR ENGINEERING (817) 467-9367
3308 Hollow Creek Rd VHDL Training, Consulting, Models
Arlington, TX 76017-5346
rouillar
|> Why not just pass this bit_vector (e.g. X"FFFF") to a function that
|> converts a bit_vector to a std_logic_vector ? This means you get
something
|> like
|> a <= to_stdlogicvector(X"ffff");
|>
|> where to_stdlogicvector is a function which converts a bit_vector
|> to a std_logic_vector. See the ieee.std_logic_1164 package.
more of the same:
type ADHOC is (B,O,X);
function "/"(left:ADHOC;right:STRING) return std_logic_vector;
-- body left as an exercise to the reader
a <= X/"ffff"; -- edit out the "/" when moving to VHDL'93
--
---------------------------------------------------------------------------
Jacques Rouillard - t(..33)91054342 f(..33)91700659 email roui...@acm.org
ECSI VHDL Technical Center - ESIM, 13451 Marseille cedex 20, France
---------------------------------------------------------------------------
My programs don't cra
---------------------------------------------------------------------------
Daniel S. Barclay
> From: roui...@ismea.imt-mrs.fr (rouillar)
> more of the same:
>
> type ADHOC is (B,O,X);
>
> function "/"(left:ADHOC;right:STRING) return std_logic_vector;
> -- body left as an exercise to the reader
>
> a <= X/"ffff"; -- edit out the "/" when moving to VHDL'93
That's an interesting trick -- and one I certainly haven't seen before.
Andrew Rushton
> Personally, I am demanding that my synthesis vendor support VHDL '93!
> Only 1/2 of the code that I write is for synthesis. The other is for
> modeling and test benches. Am I supposed to deal with 4 language
> versions? full '87, full '93, synthesizable '87 and synthesizable '93?
Well no, synthesisable VHDL happens to be a subset of VHDL'87 which happens to
be a subset of VHDL'93, so you are only dealing with one version.
> However, I have a real problem with
> generics not being supported
> std_ulogic and std_ulogic_vector not being supported
Fair comment - most tools do support these.
> q <= d when rising_edge(clock) else
> '0' when reset = '1' else q;
> not being recognized as a D-flip flop
That is because this does not model a D-type! Your clock overrides the
asynchronous reset. D-types work the other way round.
The reason that this is not recognised is that synthesisers *have to* recognise
register models as templates. These templates are determined by the synthesis
vendor. Now it may be true that your model (with the correction) would model a
d-type but it isn't one of the templates. Sure, this is because of an arbitrary
decision and it could have gone the other way, but it is a common decision by
all of the vendors. This was not a conspiracy, its just that all the vendors
came to the same conclusions, more or less, about the most effective way to
model a register.
I really don't see the problem. The templates are easy and straightforward and
you could even create a macro to produce it, so what's the beef?
> These issues are not synthesis challenges, they are syntactic issues.
> Any synthesis vendor that offers a full VHDL simulation should use
> the same syntax and semantic analyzer for synthesis that they use
> for simulation. Then the only features in VHDL that would not be
> supported would be those items that could not be synthesized.
Not true. VHDL does not have a direct hardware mapping, so synthesisers have to
try to interpret your meaning from what you've written. This means that
synthesisers have to take a global view of what you've written, whereas
simulators can work on a very localised view. Thus the kind of work done by the
tools post-syntax checking is completely different. Register templates are a classic
example. The whole process has to be scanned before it can be recognised as a
register. Then it has to be decomposed into the data part and reset part. There
are then special rules - for example not asynchronously resetting to a signal
value - which constrain the use of the reset part. And so on...
> Listen Vendors! I will spend a lot more time trying to find a bit
> error in a 32-bit or 64-bit binary vector constant than I will in
> trying to shave another 1% gate count. Support of powerful language
> features that enhance reusability, understanding, code reliability;
> such as generics, functions, aliases, record data types, unresolved
> data types, and ease of use will rank much higher than a couple of
> percentage points in gate count. (Note the couple of percentage
> points, I'm not advocating 25% larger gate arrays just to use an
> alias!) I'm advocating full support of synthesizable features and
> requesting that all vendors support VHDL '93 as quickly as they can.
Most of these features are already supported by most synthesis tools. Don't
blame the rest of us for those that don't support them!
Charles F. Shelor
>
> In article <3iu3o4$3...@news.onramp.net>, "Charles F. Shelor"
> <cfsh...@acm.org> wrote:
>
Mark, I view your comments as an endorsement of my feelings, thank you.
Current score: 1 pro, 1 con.
> > Listen Vendors! I will spend a lot more time trying to find a bit
> > error in a 32-bit or 64-bit binary vector constant than I will in
> > trying to shave another 1% gate count. Support of powerful language
> > features that enhance reusability, understanding, code reliability;
> > such as generics, functions, aliases, record data types, unresolved
> > data types, and ease of use will rank much higher than a couple of
> > percentage points in gate count. (Note the couple of percentage
> > points, I'm not advocating 25% larger gate arrays just to use an
> > alias!) I'm advocating full support of synthesizable features and
> > requesting that all vendors support VHDL '93 as quickly as they can.
>
> Why would any of these constructs cause any adverse effect on gate count???
>
The syntactical issues don't impact gate count. Someone in management
at the CAE company must decide how his (limited) engineering budget
must be spent. Does he chose to support more VHDL features, update
to VHDL-93, generate a new, 'cool' user interface, or try to squeeze
another few percent out of the gate count by additional optimization
techniques? I just want to make my opinion known that writing code
that matches the problem better is more important to me (and several
of my clients) than saving an additional 5% gate count. Understanding
and debugging non-intuitive code (that is forced by the synthesis
tool) costs much more in time to market and 'is it really going to
work' risks than the 5% gate count. (Especially in a pad ring limited
and/or routing limited sub-micron design!)
Charles
Mark A. Hilmantel
> Andrew Rushton <a...@transeda.demon.co.uk> wrote:
> I am aware that some language features cannot be synthesized. As an
> experienced designer I do not expect a synthesis tool to accept:
> x <= y and z after 25 ns;
Why not allow the "after 25 ns" to infer a timing constraint?
> dynamic hardware via access types
What about statically allocated objects defined using access types?
> parallel floating point division
> etc, etc, etc.
> However, I have a real problem with
> generics not being supported
> std_ulogic and std_ulogic_vector not being supported
> q <= d when rising_edge(clock) else
> '0' when reset = '1' else q;
> not being recognized as a D-flip flop
Add to this list:
enumeration types not supported (e.g., as index types)
predefined attribute functions not supported (e.g., t'pred)
multidimensional arrays not supported (even though arrays of arrays are!)
aggregates not supported
default values for ports and subroutine parameters not supported
function rising_edge in package std_logic_1164 not supported
assert statement not supported (but phony attributes which do some
of the same things, e.g., "one_hot" are!)
sensitivity list not supported (but you get a fatal error if you
use a subscripted signal in one)
deferred constants not suppported
etc., etc.
> These issues are not synthesis challenges, they are syntactic issues.
> Any synthesis vendor that offers a full VHDL simulation should use
> the same syntax and semantic analyzer for synthesis that they use
> for simulation. Then the only features in VHDL that would not be
> supported would be those items that could not be synthesized.
Amen to that! Note that there are very few features which cannot be given
some reasonable interpretation for synthesis. And it is especially
annoying to have to provide the same information in different forms for
simulation and synthesis, while trying to hide each from the other.
> Listen Vendors! I will spend a lot more time trying to find a bit
> error in a 32-bit or 64-bit binary vector constant than I will in
> trying to shave another 1% gate count. Support of powerful language
> features that enhance reusability, understanding, code reliability;
> such as generics, functions, aliases, record data types, unresolved
> data types, and ease of use will rank much higher than a couple of
> percentage points in gate count. (Note the couple of percentage
> points, I'm not advocating 25% larger gate arrays just to use an
> alias!) I'm advocating full support of synthesizable features and
> requesting that all vendors support VHDL '93 as quickly as they can.
Why would any of these constructs cause any adverse effect on gate count???
--
Mark A. Hilmantel
Lockheed Sanders Inc.
Nashua, New Hampshire, USA
Charles F. Shelor
>
>
> > However, I have a real problem with
> > generics not being supported
> > std_ulogic and std_ulogic_vector not being supported
>
> Fair comment - most tools do support these.
What is your meaning of most? I know of only 1 that supports generics
and although Synopsys is not MOST it is most prevalent and does not
support std_ulogic and std_ulogic_vector. Nor does it support the
IEEE.std_logic_1164 functions rising_edge and falling_edge.
>
> does not model a d flip flop.
Oops, should have been:
q <= '0' when reset = '1' else
d when rising_edge(clock) else q;
which is more concise and 'cleaner' to me than
process (reset, clock) begin
if clock'event and clock = '1' then
q <= d;
end if;
if reset = '1' then
q <= '0';
end if;
end process;
But then again, I rarely write VHDL for a standalone register, usually
my registers are inferred from substantially more code anyway.
>
> > These issues are not synthesis challenges, they are syntactic issues.
> > Any synthesis vendor that offers a full VHDL simulation should use
> > the same syntax and semantic analyzer for synthesis that they use
> > for simulation. Then the only features in VHDL that would not be
> > supported would be those items that could not be synthesized.
>
> Not true. VHDL does not have a direct hardware mapping, so synthesisers have to
> try to interpret your meaning from what you've written. This means that
> synthesisers have to take a global view of what you've written, whereas
> simulators can work on a very localised view. Thus the kind of work done by the
> tools post-syntax checking is completely different. Register templates are a classic
> example. The whole process has to be scanned before it can be recognised as a
> register. Then it has to be decomposed into the data part and reset part. There
> are then special rules - for example not asynchronously resetting to a signal
> value - which constrain the use of the reset part. And so on...
>
VHDL does not a direct mapping to machine code either. But my point
was that a common language parser could be used such that generics,
aliases, std_ulogic, record types, (things that 'disappear' or are
resolved before hardware has to be synthesized) would be treated
consistently for simulation and synthesis.
>
> Most of these features are already supported by most synthesis tools. Don't
> blame the rest of us for those that don't support them!
I apologize to the venders that support those features that were
offended by my comments. Not all of the vendors have all of the
flaws: I've only worked with SilcSyn, ViewArchitect, Synergy,
Synopsys, Exemplar, and AutoLogic. I've found all of them lacking
in more than a couple of areas. I will consider it poor standards
support for any vendor that does not SHIP a product in 1995 that
accepts VHDL-93 syntax. Eighteen months is more than enough time
to make the changes.
I've had this rebuttal from Andy. Anyone care to offer support of my
opinions or more rebuttal? This could become an interesting thread. 8-)
Charles
Mark Gonzales
>and although Synopsys is not MOST it is most prevalent and does not
>support std_ulogic and std_ulogic_vector.
I'm confused. I thought I was using std_ulogic in my Synopsys design -
obviously I was imagining it :-). Seriously, in what way does Synopsys
*not* support std_ulogic?
>Oops, should have been:
>
> q <= '0' when reset = '1' else
> d when rising_edge(clock) else q;
>
Personally, I would much rather have tool vendors concentrate on
converting VHDL to logic controllably, correctly, and quickly, rather
than figuring out ten thousand different ways to express a flip flop in
VHDL.
Mark
--
not speaking for Intel.
Charles F. Shelor
>
>
> I'm confused. I thought I was using std_ulogic in my Synopsys design -
> obviously I was imagining it :-). Seriously, in what way does Synopsys
> *not* support std_ulogic?
Well, std_ulogic will be converted to std_logic in all of the places
where needed; However, std_ulogic_vector cannot be converted to
std_logic_vector automatically. All of the operators "+", "-", ">",
that operate on std_logic_vectors will not work with std_ulogic_vectors.
The synthesis tool might ignore the distinction, VSS might even
ignore the distinction (which would make it non-compliant to -1076),
but Vantage, Model Technology, and truly compliant simulators will not
allow you to use std_ulogic_vector with the synopsis synthesis package.
Charles