rickman wrote:

>>> That is the common default for bits.
>> ?
>>> The *only* advantage is it covers tristate signals.

>> sure. But I don't have/need tristates.

Neither do I.
My default for I/0 bits is std_ulogic.
But this is not common.
I don't know why.

    -- Mike Treseler

Mike Treseler wrote:
> rickman wrote:
>>>> That is the common default for bits.
>>> ?
>>>> The *only* advantage is it covers tristate signals.
>>> sure. But I don't have/need tristates.
> Neither do I.
> My default for I/0 bits is std_ulogic.
it was too, for me.

I may have found that some parts of my code used
std_logic and others used std_ulogic, but then
why take the risk of not detecting conflicts
with multiple drivers AND simulating slower ?

> But this is not common.
> I don't know why.
I'm puzzled.

However I'll try to implement a small set of libraries
that implement a "common" type for all my bits and
vectors, so it's easier to switch between different types
and subtypes and watch the difference.

>    -- Mike Treseler
yg

-- 
http://ygdes.com / http://yasep.org

whygee wrote:

> I may have found that some parts of my code used
> std_logic and others used std_ulogic, but then
> why take the risk of not detecting conflicts
> with multiple drivers AND simulating slower ?

I expect there is no logical reason.
Just tradition.


        -- Mike Treseler

rickman wrote:

> After struggling with VHDL type casting for some time, I finally
> settled on using signed/unsigned for the majority of the vectors I
> use.  I seldom use integers other than perhaps memory where it
> simulates much faster with a lot less memory.  But nothing is
> absolute.  I just try to be consistent within a given design.

I use integer/natural ranges for small numbers
and signed/unsigned for large.

> I have
> never used bit types, but the discussion here about the advantages of
> ulogic over logic is interesting.  I certainly like to speed up my
> simulations.  But it is such a PITA to get away from std_logic. 

Vectors, require some compromise.
I only use std_logic_vector for non-numeric variables
and for the device pins.

For std_ulogic bits, there is no pain.
However the advantages are not overwhelming either.

Simulators are now very well optimized for standard types,
and I would not expect much run-time speed up.

Detecting multiple drivers at compile time is very useful
for new users using many processes,
but these errors can also be found at elaboration time.



       -- Mike Treseler

Mike Treseler wrote:
> whygee wrote:
> 
>> I may have found that some parts of my code used
>> std_logic and others used std_ulogic, but then
>> why take the risk of not detecting conflicts
>> with multiple drivers AND simulating slower ?
> I expect there is no logical reason. Just tradition.
There is probably a little of that,
but knowing VHDL as I know it,
it is certainly backed by an excellent,
compelling reason. It becomes tradition
when we forget it :-/

Furthermore, my code was primarily meant
for synthesis (and works), so the ulogic vs logic
choice was not an issue, being a one-time,
few seconds of synthesis cost.

OK now I should stop ranting and start coding ;-)


>         -- Mike Treseler
yg

-- 
http://ygdes.com / http://yasep.org

On Jan 19, 1:51=A0pm, Mike Treseler
<mtrese...@gmail.com> wrote:
> rickman wrote:
> > After struggling with VHDL type casting for some time, I finally
> > settled on using signed/unsigned for the majority of the vectors I
> > use. =A0I seldom use integers other than perhaps memory where it
> > simulates much faster with a lot less memory. =A0But nothing is
> > absolute. =A0I just try to be consistent within a given design.
>
> I use integer/natural ranges for small numbers
> and signed/unsigned for large.

Can you explain the idea behind that?  Why integers for small numbers
and not large?


> > I have
> > never used bit types, but the discussion here about the advantages of
> > ulogic over logic is interesting. =A0I certainly like to speed up my
> > simulations. =A0But it is such a PITA to get away from std_logic.
>
> Vectors, require some compromise.
> I only use std_logic_vector for non-numeric variables
> and for the device pins.
>
> For std_ulogic bits, there is no pain.
> However the advantages are not overwhelming either.
>
> Simulators are now very well optimized for standard types,
> and I would not expect much run-time speed up.

As optimized as they may be, a signal that does not require resolution
will take longer than one that does.  Detecting multiple drivers is
done at compile time while the resolution is done at simulation time.
I guess if there are no multiple drivers the difference may not be
apparent though.


> Detecting multiple drivers at compile time is very useful
> for new users using many processes,
> but these errors can also be found at elaboration time.
>
> =A0 =A0 =A0 =A0-- Mike Treseler

Yeah, I can't say I have many issues with multiple drivers.  I'm
pretty sure the tools I've been using give adequate warnings when I do
make a mistake and reuse a signal name.

Rick