Resolved vs. Unresolved standard logic, and when to get away

[gsteemso]

Hi all,

I am teaching myself VHDL, and have reached the limits of Ashenden's
"Student's Guide to VHDL 2nd ed." It is good at introductory concepts
but falls short soon thereafter; now that I am trying to look up
aspects of the language to implement a real design, I keep finding that
it glosses over the details I need.

Research online has revealed that resolved logic allows you to drive a
signal from multiple sources, as with the data bus in the average
computer, and unresolved logic is considered better for simulation
because (a) it's faster and (b) it will complain about multiple drivers
when you don't want them. Is that accurate?

Unfortunately, the same research reveals that you end up with a hideous
stew of type conversions when you intermix them in the same design,
unless you have godlike powers of foresight. I see that VHDL-2008
allows them to mix more easily, but I rather suspect there must be
pitfalls to that semantic change that I have not found any discussion
of yet. Will incautiously written code silently permit conflicting
signals if some of them are declared resolved and some are not?

I have other questions about the language, but I will post them
separately so as not to muddy the waters too much.

gsteemso

 

[Robert Miles]

I suspect that resolved logic is for buses with more than one tristate driver, and unresolved logic is for signals with only one driver, not tristate type.

For ASIC or FPGA design, buses with more than one tristate driver are usually best reserved for connections off that ASIC or FPGA, and then only if they need to allow driving from multiple sources.

 

[Martin Thompson]

gsteemso <gsteemso@gmail.com> writes:

Hi all,

I am teaching myself VHDL, and have reached the limits of Ashenden's "Student's
Guide to VHDL 2nd ed." It is good at introductory concepts but falls short soon
thereafter; now that I am trying to look up aspects of the language to implement
a real design, I keep finding that it glosses over the details I need.

Really? I keep referring back to it to *find* the details I haven't used for a while!

Research online has revealed that resolved logic allows you to drive a signal
from multiple sources, as with the data bus in the average computer, and
unresolved logic is considered better for simulation because (a) it's faster and
(b) it will complain about multiple drivers when you don't want them. Is that
accurate?

Yes

Unfortunately, the same research reveals that you end up with a hideous stew of
type conversions when you intermix them in the same design, unless you have
godlike powers of foresight.

No foresight required: just use the unresolved type throughout
- except on the top-level IOs where you need to tristate the output.

Then, (IIRC) the only time it's a pain is (pre 2008) when you have to
use an IP core which uses resolved vectors. Then an intermediate signal
is required.

And if you want to do a post-synth/PAR simulation as the model they
generate will be resolved types on the IOs. A quick wrapper can fix
that easily though. Or you can choose to use resolved types throughout
your top-level as a half-way house.

I see that VHDL-2008 allows them to mix more easily, but I rather
suspect there must be pitfalls to that semantic change that I have not
found any discussion of yet. Will incautiously written code silently
permit conflicting signals if some of them are declared resolved and
some are not?

I'd be surprised, I believe all that happens is an implicit resolved
signal is formed for the connection of an unresolved signal to a
resolved one.

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

 

[KJ]

On Thursday, March 7, 2013 6:45:58 AM UTC-5, Martin Thompson wrote:

Then, (IIRC) the only time it's a pain is (pre 2008) when you have to use an
IP core which uses resolved vectors. Then an intermediate signal is required.

Minor point...You can put the conversion right in the port map without having to create any intermediate signals.

DUT : ip_core_with_slv port map(
std_logic_vector(a) => my_sulv_a,
b => std_ulogic_vector(my_sulv_b));

Kevin Jennings

 

[valtih1978]

On 7.03.2013 14:16, KJ wrote:

oint...You can put the conversion right in the port map without having to create any intermediate signals.

Thanks, it might be very important for the clock lines.

 

[Andy]

On Thursday, March 7, 2013 5:45:58 AM UTC-6, Martin Thompson wrote:
I'd be surprised, I believe all that happens is an implicit resolved signal is formed for the connection of an unresolved signal to a resolved one.

No, an implicit signal in between the two would force an additional delta-delay.

In VHDL 2008, it's no different for SULV/SLV than std_ulogic/std_logic assignments and associations have been since '87.

Andy

 

[Martin Thompson]

Andy <jonesandy@comcast.net> writes:

On Thursday, March 7, 2013 5:45:58 AM UTC-6, Martin Thompson wrote:
I'd be surprised, I believe all that happens is an implicit resolved signal is formed for the connection of an unresolved signal to a resolved one.

No, an implicit signal in between the two would force an additional delta-delay.

Indeed so, not sure what I was thinking!

In VHDL 2008, it's no different for SULV/SLV than std_ulogic/std_logic assignments and associations have been since '87.

Agreed

Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

 

[Martin Thompson]

KJ <kkjennings@sbcglobal.net> writes:

On Thursday, March 7, 2013 6:45:58 AM UTC-5, Martin Thompson wrote:
Then, (IIRC) the only time it's a pain is (pre 2008) when you have to use an
IP core which uses resolved vectors. Then an intermediate signal is required.

Minor point...You can put the conversion right in the port map without having to create any intermediate signals.

DUT : ip_core_with_slv port map(
std_logic_vector(a) => my_sulv_a,
b => std_ulogic_vector(my_sulv_b));

Can you? Pre-2008? I was under the impression you couldn't, but it's
been a long time since I've had to try, and I don't feel up to grappling
with the LRM this morning!

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

 

[Andy]

Re: conversion functions on ports

Before or after -2008, a conversion function that returns an unconstrained array type/subtype cannot be used on an unconstrained port (the component/entity cannot determine what size its port is). Also the conversion function can take only one argument, so you cannot use "to_unsigned(int, size)".

Note that non-built-in conversion functions impart a delta-cycle delay from the actual to the port (and/or vise versa when the conversion function is called on the formal).

Built-in conversion functions (not really functions) are defined for conversion between "closely related" types (e.g. arrays of elements of the same base type). Example:

-- output conversion => input conversion
unsigned(my_constrained_slv_bidi_port) => std_logic_vector(my_unsigned)


Andy