std_logic vs std_ulogic 
Author Message
 std_logic vs std_ulogic

Quote:

> Martin,

> You should not use std_logic for any other ports than those,
> which really will be connected to wires with multiple drivers.
> This is because this way the compiler will give you an error
> message, if you happen to connect several drivers to a single net
> by mistake (it happens!).

> The std_logic type is needed for three-state busses, wired ORs,
> pull-ups etc.  For example inside a typical ASIC, std_ulogic is
> the best choice.

> Esa

Martin:

I agree. As a design engineer I like the ability to find mistakes
(of connecting multiple drivers to an unresolved signal) and have
found it useful in several previous designs. I believe this is also
consistent with the spirit of 1164 standard.

Zia

Quote:
>>>> These are my opinions ofcourse

-----------------------------------------------------------------------
Zia Khan, Staff Engineer, PCD Design Automation  phone:  (916) 356-6635
Intel Corporation, FM5-43                        fax:    (916) 356-2219

-----------------------------------------------------------------------


Mon, 25 Jan 1999 03:00:00 GMT  
 std_logic vs std_ulogic

I was asking what the most appropriate type was for the _ports_ of
gate level components inside an ASIC...


Quote:


> > You should not use std_logic for any other ports than those,
> > which really will be connected to wires with multiple drivers.
> > This is because this way the compiler will give you an error
> > message, if you happen to connect several drivers to a single net
> > by mistake (it happens!).

> > The std_logic type is needed for three-state busses, wired ORs,
> > pull-ups etc.  For example inside a typical ASIC, std_ulogic is
> > the best choice.

> I agree. As a design engineer I like the ability to find mistakes
> (of connecting multiple drivers to an unresolved signal) and have
> found it useful in several previous designs.

As I pointed out to Esa by email, this is a commonly held view about
VHDL, but it is _wrong_.

The type of the port of a component has _no_ bearing on whether or not
it can be connected to resolved nets (tristates, pullups etc).

The thing that matters is the type of the _signal_ to which the ports
are connected.

In this code you will see two std_ulogic ports connected together in a
way that generates no warnings, and you will see two std_logic ports
connected together in a way that causes warnings about multiply driven
signals...:

architecture simple of connection_demo is

  component A
    port (Z_u : out std_ulogic);
  end component;

  component B
    port (Z : out std_logic);
  end component;

  signal unresolved_connector: std_ulogic;

  signal resolved_connector: std_logic;

begin

  A1 : A
    port map (Z_u => resolved_connector);

  A2 : A
    port map (Z_u => resolved_connector);

  B1 : B
    port map (Z => unreolved_connector);

  B2 : B
    port map (Z => unresolved_connector);

end;

Quote:
> I believe this is also consistent with the spirit of 1164 standard.

Well, here you may be right!  Certainly, since asking my question,
I've found tow coding standards put out by major organisations that
specify all ports shall be std_logic...

So this is what I plan to do!

Cheers,

Martin.

----------------------------------------------------------------------
-- Martin Gregory                            |           _--_|\

-- Motorola Australian Software Centre       |          \_.-*._/
-- Phone: +61 8 203 3612, Fax: +61 8 203 3501|                v
----------------------------------------------------------------------



Fri, 29 Jan 1999 03:00:00 GMT  
 std_logic vs std_ulogic


Quote:

>> Martin,

>> You should not use std_logic for any other ports than those,
>> which really will be connected to wires with multiple drivers.
...
>I agree. As a design engineer I like the ability to find mistakes
>(of connecting multiple drivers to an unresolved signal) and have
>found it useful in several previous designs. I believe this is also
>consistent with the spirit of 1164 standard.

In the appendix of the IEEE-1164 standard, this issue is discussed.
See page 17.

Since std_logic and std_ulogic are subtypes, it doesn't seem to matter
much which is used and both are OK.  Even with std_logic, simulators
are usually optimized to *not* call the resolution function with single
drivers.  You do have the advantage of finding shorts during
compilation with std_ulogic.

With std_logic_vector vs. std_ulogic_vector it does matter as they are
different types.  The use of std_logic_vector is recommended over
std_ulogic_vector for easier interfacing.

Personally I stick with std_logic and std_logic_vector and find
"shorts" through simulation.

Rich Hatcher



Sat, 30 Jan 1999 03:00:00 GMT  
 std_logic vs std_ulogic

<snip original removed

Quote:



<snip original removed>

Quote:
> As I pointed out to Esa by email, this is a commonly held view about
> VHDL, but it is _wrong_.

> The type of the port of a component has _no_ bearing on whether or not
> it can be connected to resolved nets (tristates, pullups etc).

> The thing that matters is the type of the _signal_ to which the ports
> are connected.

> In this code you will see two std_ulogic ports connected together in a
> way that generates no warnings, and you will see two std_logic ports
> connected together in a way that causes warnings about multiply driven
> signals...:

<snip nice example removed>

You see how dangerous it is to use resolved logic. One can create a
multiply driven net only with resolved logic (as you've demonstrated).

By using unresolved logic inside the module A you know that
the driver conflict cannot be inside A.

So, I try to enforce(encourage) the use of resolved signals
where ever it is possible (sensible).

yours MASC ( Markus Schirmer)

Quote:
> Cheers,

> Martin.

> ----------------------------------------------------------------------
> -- Martin Gregory                            |           _--_|\

> -- Motorola Australian Software Centre       |          \_.-*._/
> -- Phone: +61 8 203 3612, Fax: +61 8 203 3501|                v
> ----------------------------------------------------------------------

-- Markus Schirmer, Tel: ++ 49 511 277 1419 ---------->> FIAWOHL <<===
-- SICAN GmbH Abt. DDF, Garbsener Landstr. 10, 30419 Hannover, Germany

-- Finest handcrafted gates since 1989


Sat, 30 Jan 1999 03:00:00 GMT  
 std_logic vs std_ulogic

Quote:


><snip original removed


><snip original removed>
>> As I pointed out to Esa by email, this is a commonly held view about
>> VHDL, but it is _wrong_.

>> The type of the port of a component has _no_ bearing on whether or not
>> it can be connected to resolved nets (tristates, pullups etc).

>> The thing that matters is the type of the _signal_ to which the ports
>> are connected.

>> In this code you will see two std_ulogic ports connected together in a
>> way that generates no warnings, and you will see two std_logic ports
>> connected together in a way that causes warnings about multiply driven
>> signals...:

><snip nice example removed>

A very nice example indeed!

Quote:

>You see how dangerous it is to use resolved logic. One can create a
>multiply driven net only with resolved logic (as you've demonstrated).

>By using unresolved logic inside the module A you know that
>the driver conflict cannot be inside A.

>So, I try to enforce(encourage) the use of resolved signals
>where ever it is possible (sensible).

The example shows that the solution of using std_ulogic is not 100%
proof in avoiding unwanted connections between outputs.

There is however a solution that works 100%: the use of mode BUFFER. An
output of mode BUFFER cannot drive a signal that is driven by another
driver. This is described most clearly in the LRM, IEEE Std 1076-1987,
paragraph 4.3.3, page 4-10:

        "Although signals of modes INOUT and BUFFER have the same
         characteristics with respect to whether they may be read or updated,
         a signal of mode INOUT may be updated by zero or more sources,
         whereas a signal of mode BUFFER must be updated by at most one
         source (see Section 1.1.1.2)."

The first time I was made aware of this was by a posting in this group
in February or so, discussing the differences about INOUT and BUFFER.

We made it a design rule to use mode BUFFER for all outputs that cannot
be tri-stated. Mode OUT is still used, for tri-statable outputs, and mode
INOUT is used for bi-directionals. This works very well.

Paul.



Mon, 01 Feb 1999 03:00:00 GMT  
 std_logic vs std_ulogic

Quote:

> I was asking what the most appropriate type was for the _ports_ of
> gate level components inside an ASIC...



> > > You should not use std_logic for any other ports than those,
> > > which really will be connected to wires with multiple drivers.
> > > This is because this way the compiler will give you an error
> > > message, if you happen to connect several drivers to a single net
> > > by mistake (it happens!).

> > > The std_logic type is needed for three-state busses, wired ORs,
> > > pull-ups etc.  For example inside a typical ASIC, std_ulogic is
> > > the best choice.

> > I agree. As a design engineer I like the ability to find mistakes
> > (of connecting multiple drivers to an unresolved signal) and have
> > found it useful in several previous designs.

> As I pointed out to Esa by email, this is a commonly held view about
> VHDL, but it is _wrong_.

This method above is totally _valid_, although it is
probably true, that the type of the *port* itself does not
offer you automatic protection against several drivers in
one net.  The way to do it is use only std_ulogic
everywhere!  Furthermore, if you have totally VHDL system,
every port *is* a signal (in the lower level sublock), so
there may not be much to gain by making theories about how
differently signals and ports should be treated...

But VITAL (VHDL Initiative Towards ASIC Libraries)
specification "Standard VITAL ASIC Modelling Specification
Draft, IEEE P1076.4, October 1995) says it this way
(http://vhdl.org/vi/vital/):

"The type mark in an entity port declaration shall denote
a type or subtype that is declared in package
Std_Logic_1164.  The type mark in the declaration of a
scalar port shall denote the subtype Std_Ulogic or a
subtype of Std_Ulogic.  The type mark in the declaration
of an array port shall denote the type Std_Logic_Vector."

They should know it.  I was a bit surprised about this
array specification.  Does anyone know why this kind of
mix?  The same idea was in the '93 version, so I don't
think it is a clerical error or anything like that...

...

Quote:
> Certainly, since asking my question,
> I've found tow coding standards put out by major organisations that
> specify all ports shall be std_logic...

Check that they were not speaking about component board
level libraries!  Std_logic suits to those wery much
better than to ASIC libraries.

Quote:
> Martin.

Esa

--

-- Esa Laaksonen

-- *** Personal opinion, not representing Nokia! ***



Tue, 02 Feb 1999 03:00:00 GMT  
 std_logic vs std_ulogic

: We made it a design rule to use mode BUFFER for all outputs that cannot
: be tri-stated. Mode OUT is still used, for tri-statable outputs, and mode
: INOUT is used for bi-directionals. This works very well.

: Paul.
I agree and is the same policy that we use.

Andrew



Tue, 09 Feb 1999 03:00:00 GMT  
 std_logic vs std_ulogic

: This method above is totally _valid_, although it is
: probably true, that the type of the *port* itself does not
: offer you automatic protection against several drivers in
: one net.  The way to do it is use only std_ulogic
: everywhere!  Furthermore, if you have totally VHDL system,
: every port *is* a signal (in the lower level sublock), so
: there may not be much to gain by making theories about how
: differently signals and ports should be treated...

The problem with using std_ulogic, is that it is not supported by synopsys.
I have just had a look at the 3.4b packages, and the + - .... overloaded
functions return STD_LOGIC_VECTOR. There is virtually no support of STD_ULOGIC.

I prefferably would like to use std_ulogic, but because of the lack of
support from synopsys, need to use std_logic.

Andrew

library usual;
use     usual.disclaimers.all;



Tue, 09 Feb 1999 03:00:00 GMT  
 std_logic vs std_ulogic

Quote:

> The problem with using std_ulogic, is that it is not supported by synopsys.
> I have just had a look at the 3.4b packages, and the + - .... overloaded
> functions return STD_LOGIC_VECTOR. There is virtually no support of STD_ULOGIC.

> I prefferably would like to use std_ulogic, but because of the lack of
> support from synopsys, need to use std_logic.

Use "install_vhdl" (I think) to create a new arithmetic package from
the usual package or modify IEEE.std_logic_arith by hand to create
a new package. Depending on your access rights, you can compile it
into the IEEE library directly or use it locally in your own libraries.
This package will simply have std_logic type in all the overloaded
functions.
--
"When I was in school, I cheated on my metaphysics exam: I looked into
the soul of the boy sitting next to me."
    -- Woody Allen


http://homepages.munich.netsurf.de/Jonathan.Connell/
Fax    : +49 (0)89 722 27544 | Tel : +49 (0)89 722 28790
Post   : Siemens AG, OeN ET D8, Postfach 700071, D-81359 Munich



Fri, 12 Feb 1999 03:00:00 GMT  
 std_logic vs std_ulogic

Quote:

> The problem with using std_ulogic, is that it is not supported by synopsys.
> I have just had a look at the 3.4b packages, and the + - .... overloaded
> functions return STD_LOGIC_VECTOR. There is virtually no support of STD_ULOGIC.

Maybe this is one reason to use STD_LOGIC_VECTOR for busses,
although STD_ULOGIC is used for single bits, as recommended by
VITAL.  I guess not much counting is done with single bits.

Quote:
> I prefferably would like to use std_ulogic, but because of the lack of
> support from synopsys, need to use std_logic.

You can always use conversion functions and integer variables or
busses etc.  

After all I think it is best to use the most convenient types
inside your own design and very dull standard type set in design
I/O seen by the external world.

Quote:
> Andrew

Esa

--

-- Esa Laaksonen

-- *** Personal opinion, not representing Nokia! ***



Sat, 13 Feb 1999 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. newbie q: std_logic vs std_ulogic

2. std_logic vs. std_ulogic

3. std_ulogic vs. std_logic

4. std_ulogic and std_logic - difference?

5. std_ulogic <-> std_logic

6. STD_LOGIC_VECTOR(0 DOWN TO 0) Vs Std_logic??

7. Resloved std_logic vs. guarded statement

8. unsigned and std_ulogic compatibility

9. "=" function on std_ulogic(_vector) types

10. BIT to std_ulogic conversion

11. Change integer to STD_ULOGIC

12. stdcall vs c vs cdecl vs pascal vs whosyerdaddy

 

 
Powered by phpBB® Forum Software