Re: New keyword 'orif' and its implications

On Sep 8, 9:51 am, "KJ" <kkjenni...@xxxxxxxxxxxxx> wrote:
"Marcus Harnisch" <marcus.harni...@xxxxxxx> wrote in message

news:868x7hh2au.fsf@xxxxxxxxxxxxxxxxxxxxxx> KJ <Kevin.Jenni...@xxxxxxxxxx> writes:

I think you read more into this than was intended. What Marcus had
asked for (or at least what I thought he had asked for) was example
code showing that the conversion of an enumerated type to and from a
std_logic_vector really took 0 logic elements.

Your posting suggested (but maybe I was reading too much into it) that
some synthesis tools would be able to figure out by themselves whether
the usage of conversion functions at either end of a connection is
redundant and make everything dissolve in a puff of logic
automagically. I strongly doubt that this is true unless the
conversion is one-to-one, where this could potentially work.

See my reply from yesterday to Andy on this thread for what I believe are
the necessary conditions for the conversion functions to dissolve away....as
well the reasoning why the 'one hot -> encoded -> one hot' will never
dissolve away completely regardless of the form that one chooses to write
the equations (i.e. and/or, if/end if, case) and why 'asserts' will not help
either.

It really had nothing to do with Weng's 'orif'.

A functionality like that (if it existed) could be utilized to take
advantage of the inherent uniqueness of enum elements.

Again, from my reply yesterday, the conversion 'encoded -> one hot ->
encoded' will always dissolve away resulting in 0 logic usage. The basic
concept is that if some arbitrary collection of signals is truly 'one hot'
then there exists an encoding (whether as a vector or an enum) that those
arbitrary signals can be decoded from that is the basic underpinning of why
that collection is truly a logical 'one hot'.

KJ

KJ,

Sorry; I did not make myself clear. Yes, you did demonstrate
specifically what you were asked to, and I thank you for it. I
apologize if my response was taken as a negative critique of your
demonstration.

By "what we wanted", I meant that the subject of the thread, taken as
a whole, has to do with methods for optimally dealing with encodings
or conditions that are not by definition mutually exclusive, but are
functionally guaranteed to be so. A binary encoding is by definition
mutually exclusive, so starting with that would not demonstrate what
the thread, as a whole, seeks.

In light of the thread subject, a more useful demonstration (which you
were not asked for) would be to demonstrate a conversion from a one-
hot vector to a binary or enumeration encoding, and back, with minimal
(preferably zero) logic. As you have pointed out, that is likely not
possible.

Several options have been proposed within the existing language and
tool capabilities, but they are all limited to either data types that
include a "don't care" value understood by synthesis, or that support
an OR operation between values. It is possible that an enum value
could be treated as a don't care if nothing is done in response to it,
but I have not tried that. Methods capable of dealing with
unconstrained dimensions of input and output would be required as
well.

Thanks,

Andy

.

Relevant Pages

  • Re: utf8 vs iso8859-1 speed/responsiveness
    ... Glibc internal encoding is UTF32/UCS4, and modern toolkits, thus ... on RH9 as well. ... conversion happens everywhere on the fly. ... So regardless of RH9 or FC2, ...
    (Fedora)
  • Re: Proposal: require 7-bit source strs
    ... I'm referring to a time when there was no encoding ... It would be possible to go back and find all strings ... That's why I specified to do this after conversion to ... make the assumption that the character set is ASCII-based, ...
    (comp.lang.python)
  • Re: Proposal to extend documentation about interop
    ... > utf-8 encoding of the character FF. ... > I solved it by doing the conversion of UTF-8 to bytes and when going back to ...
    (microsoft.public.dotnet.framework.interop)
  • Re: RfD: XCHAR wordset (Version 3)
    ... The only switch of encoding that's reasonable possible is from ASCII to some ASCII-compatible encoding, but going back is not a good idea. ... If you add conversion semantics to it, you will break A LOT of code. ... In my code xc is an Unicode code point, but a sequence of utf8 bytes backed into one cell would be a valid implementation, too. ...
    (comp.lang.forth)
  • Re: New keyword orif and its implications
    ... the usage of conversion functions at either end of a connection is ... the necessary conditions for the conversion functions to dissolve away....as ... arbitrary signals can be decoded from that is the basic underpinning of why ...
    (comp.lang.vhdl)