Prev: sdram stable clock
Next: temporal logic folding
From: Andy on 3 Aug 2010 12:04
On Aug 3, 8:40 am, KJ <kkjenni...(a)sbcglobal.net> wrote:
> 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

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
From: KJ on 4 Aug 2010 20:59
On Aug 3, 12:04 pm, Andy <jonesa...(a)comcast.net> wrote:
> On Aug 3, 8:40 am, KJ <kkjenni...(a)sbcglobal.net> 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
From: Andrew Feldhaus on 5 Aug 2010 10:41

Thank you all for your helpful responses.

Ultimately I had to write a wrapper to hide the workarounds required to
connect signals to ports of (semantically) different types.

This was after discovering that in:

U1: somedevice
port map ( DIN => std_logic_vector(x),
DOUT => U1DOUT);

Xilinx tools also do not connect 'x' to 'DIN', and fail to warn that the
line is being ignored until 'DIN' is subsequently noted as disconnected...

I must agree with KJ that correctness is defined by compliance to the
standard. Xilinx reminds me more and more of Internet Explorer 6 but
that is a rant for another day.

Thanks again,


Andrew
0xADF
First  |  Prev  | 
Pages: 1 2 3 4
Prev: sdram stable clock
Next: temporal logic folding