Connecting "signed" to "std_logic_vector" ports.
in [FPGA]
|
Prev: sdram stable clock
Next: temporal logic folding
From: KJ on 29 Jul 2010 13:15 On Jul 29, 6:43 am, Kolja Sulimma <ksuli...(a)googlemail.com> wrote: > On 29 Jul., 02:34, KJ <kkjenni...(a)sbcglobal.net> wrote: > > > Instead of this: > > Some_slv_sig <= std_logic_vector(Some_unsigned); > > Do this > > Some_slv_sig <= std_ulogic_vector(Some_unsigned); > > a package numeric_unresolved would be nice.... > > Kolja Why do you think a numeric_unresolved would help with anything? The type conversions come about because of converting to/from std_logic types, not because the conversion is to/from resolved (or not resolved) data types. KJ
From: rickman on 30 Jul 2010 12:20 On Jul 29, 6:43 am, Kolja Sulimma <ksuli...(a)googlemail.com> wrote: > On 29 Jul., 02:34, KJ <kkjenni...(a)sbcglobal.net> wrote: > > > Instead of this: > > Some_slv_sig <= std_logic_vector(Some_unsigned); > > Do this > > Some_slv_sig <= std_ulogic_vector(Some_unsigned); > > a package numeric_unresolved would be nice.... > > Kolja There is no reason why unresolved can't be added to numeric_std is there?
From: KJ on 30 Jul 2010 21:44 On Jul 30, 12:20 pm, rickman <gnu...(a)gmail.com> wrote: > On Jul 29, 6:43 am, Kolja Sulimma <ksuli...(a)googlemail.com> wrote: > > > On 29 Jul., 02:34, KJ <kkjenni...(a)sbcglobal.net> wrote: > > > > Instead of this: > > > Some_slv_sig <= std_logic_vector(Some_unsigned); > > > Do this > > > Some_slv_sig <= std_ulogic_vector(Some_unsigned); > > > a package numeric_unresolved would be nice.... > > > Kolja > > There is no reason why unresolved can't be added to numeric_std is > there? I don't think you could really *add* the unresolved types to numeric_std because to do so you would have to create new types other than 'unsigned' and 'signed' that are based on std_ulogic. Then of course you would have to get all of the synthesis and simulation vendors on board with the change before you could really use the new types. In the mean time, the 'least common denominator' rule will apply and everyone would continue to use the more supported current data types that are based on the resolved std_logic type...which would then kill all momentum for any of the vendors to support the change and the proposal would likely die quietly. If instead, numeric_std was simply changed from this... type UNSIGNED is array (NATURAL range <>) of STD_LOGIC; type SIGNED is array (NATURAL range <>) of STD_LOGIC; to this... type UNSIGNED is array (NATURAL range <>) of STD_ULOGIC; type SIGNED is array (NATURAL range <>) of STD_ULOGIC; Then the only ones the user community would have to beat on to get this implemented would be the simulation vendors. Synthesis vendors already flag multiple driver violations as a standard part of synthesis since they (for the most part) do not implement multiple net drivers. Changes to standard packages should of course not be taken lightly, but off the top of my head, I can't think of anyone that would be negatively impacted by this. I'll toss this out to the newsgroupies first to see if someone can come up with a use case where the change in the definition of 'unsigned' and 'signed' would negatively impact something. If not, then I'll submit it to the standards group for consideration...numeric_std was so close, they were only two letters short in the source code. Sooooo close. Kevin Jennings
From: Andy on 31 Jul 2010 13:50 It would break existing code that used signed/unsigned like SLV, and needed the tri-state, multi-driver logic. Also, elements of unsigned would not be SL, with the same problem. Am I just dreaming, or wasn't there an effort to change the relationship between SLV and SULV such that they would become interchangeable subtypes like SUL and SL are? E.G. subtype SLV is resolved(SULV); or similar, with a new version of resolved() to match. It seems like the gotcha was that an element of such an SLV would no longer be SL, but SUL. But I thought they got around that. Andy
From: KJ on 3 Aug 2010 09:40
On Jul 31, 1:50 pm, Andy <jonesa...(a)comcast.net> wrote: > It would break existing code that used signed/unsigned like SLV, and > needed the tri-state, multi-driver logic. Also, elements of unsigned > would not be SL, with the same problem. > Actually, I intended my question more along the lines of if signed/ unsigned were changed to be collections of std_ulogic rather than std_logic, how many would really notice/care? I understand that those who use signed/unsigned with multiple drivers would be affected...but how many of those cases are actually out there? So, do *you* use multiple drivers on signed/unsigned signals? Is that actually important to you? KJ |