Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Resolved vs. Unresolved standard logic, and when to get away with using each
1,022 views
Skip to first unread message
gsteemso
Mar 7, 2013, 1:23:55 AM3/7/13
to
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
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
Mar 7, 2013, 2:37:00 AM3/7/13
to
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.
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
Mar 7, 2013, 6:45:58 AM3/7/13
to
gsteemso <gste...@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!
> 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.
- 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?
signal is formed for the connection of an unresolved signal to a
resolved one.
Cheers,
Martin
--
martin.j...@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware
KJ
Mar 7, 2013, 7:16:41 AM3/7/13
to
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.
> 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.
DUT : ip_core_with_slv port map(
std_logic_vector(a) => my_sulv_a,
b => std_ulogic_vector(my_sulv_b));
Kevin Jennings
valtih1978
Mar 7, 2013, 1:41:40 PM3/7/13
to
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.
> oint...You can put the conversion right in the port map without having to create any intermediate signals.
Andy
Mar 7, 2013, 7:22:51 PM3/7/13
to
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.
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.
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
Mar 11, 2013, 7:59:21 AM3/11/13
to
Andy <jone...@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!
> 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.
>
Martin Thompson
Mar 11, 2013, 8:00:49 AM3/11/13
to
been a long time since I've had to try, and I don't feel up to grappling
with the LRM this morning!
Andy
Mar 18, 2013, 5:04:38 PM3/18/13
to
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
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
0 new messages