Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Re: Connecting "signed" to "std_logic_vector" ports.

Reply
Thread Tools

Re: Connecting "signed" to "std_logic_vector" ports.

 
 
KJ
Guest
Posts: n/a
 
      07-31-2010
On Jul 30, 12:20*pm, rickman <(E-Mail Removed)> wrote:
> On Jul 29, 6:43*am, Kolja Sulimma <(E-Mail Removed)> wrote:
>
> > On 29 Jul., 02:34, KJ <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Andy
Guest
Posts: n/a
 
      07-31-2010
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
 
Reply With Quote
 
 
 
 
KJ
Guest
Posts: n/a
 
      08-03-2010
On Jul 31, 1:50*pm, Andy <(E-Mail Removed)> 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
 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      08-03-2010
On Aug 3, 8:40*am, KJ <(E-Mail Removed)> wrote:
> On Jul 31, 1:50*pm, Andy <(E-Mail Removed)> 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


Mostly in places where I have an inout port (or procedure argument) of
a record type, and I need resolution functions to manage in and out
elements more often than I actually use a bidirectional element. My
test benches tend to have lots of procedures like read/write(bus,
address, data)

I have also used unsigned on tri-stated primary IOs of FPGAs (it is
easy enough to convert them back to SLV if I need to use the gate
level models).

Internally, I have used them with a tri-state bus description, knowing
full-well that the synthesis tool would convert them to muxes for me.
The added benefit is that the synthesis tool can assume that the tri-
state enables are mutually exclusive, which allows it to optimize the
muxes. Sometimes it is just easier to describe an interface with a
bus, than to create the mux and the plumbing for it. I don't usually
do truly bi-directional busses, but sometimes...

So, yes, I have used them in several areas.

IMHO, changes to the language or standard packages must be backwards
compatible (even though in rare cases in the past they have not been
so), so that they don't break anyone's code, regardless of how common
(or even "useful") a given usage is. The "prime directive" WRT changes
to the standards should be "do no harm". If we need a different
numeric_std-like package, so be it.

Andy
 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      08-05-2010
On Aug 3, 12:04*pm, Andy <(E-Mail Removed)> wrote:
> On Aug 3, 8:40*am, KJ <(E-Mail Removed)> wrote:
> IMHO, changes to the language or standard packages must be backwards
> compatible (even though in rare cases in the past they have not been
> so),


Backwards compatibility should not be a 'must have'...although I
certainly agree that it is something worth working for to get if you
can. Examples of changes that are definitely more onerous to 'used to
be working just fine' code were the changes to type 'FILE' and 'shared
variables'.

> so that they don't break anyone's code, regardless of how common
> (or even "useful") a given usage is.


I think the cost/benefit should be weighed although just how well one
can weigh this with actual users is a bit of a question.

> The "prime directive" WRT changes
> to the standards should be "do no harm".


'Do no harm' applies to doctors, not engineering standards. If
something needs to be improved and is 'worth it' to the users then it
should be improved. The definition of whether something is 'worth it'
or not is subjective.

> If we need a different
> numeric_std-like package, so be it.
>

Maybe just use the fixed point package. The documentation says it
uses std_logic as the base, but the actual code says std_ulogic.

Thanks for your input on how you use/need multi-driver signed/unsigned

Kevin Jennings
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Connecting a non-btvoyager adapter! =?Utf-8?B?Sm9uYXRoYW4=?= Wireless Networking 1 07-24-2004 05:07 PM
problems connecting home network Martin Fricke Wireless Networking 1 07-19-2004 07:28 PM
Trouble connecting in public hot spots Andres Perez Wireless Networking 2 07-16-2004 06:47 PM
Problem connecting when more than one network is in the area Borgholio Wireless Networking 2 07-05-2004 07:44 AM
Problems connecting to Internet with a Dlink 614+ and WinXP Bubster Wireless Networking 3 06-29-2004 04:37 PM



Advertisments