Connecting "signed" to "std_logic_vector" ports.

Mon Jul 26, 2010 1:30 pm   

Hi,

As I understand it, good practice dictates that in a synthesis-targeted
setting, components should use ports of type std_logic or std_logic_vector
only.

Certainly Xilinx's IP generation tools provide components with this
philosophy.

My design is well-suited to the use of signed types from IEEE.Numeric_Std.

From my investigations I believe that the correct way to connect signed
signals to std_logic_vector ports is by converting the types in the
component instantiation port map. E.g., where x and y are compatibly-
sized signed signals:

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

Xilinx ISE (12.1) simulates this without problems.

Xilinx XST complains, however, with "ERROR:Xst:1539 - <VHDL file name>
line xx: Formal port in component U1 must be an identifier". The obvious
work-around, suggested at http://www.xilinx.com/support/answers/18188.htm,
is to add a signal:

signal U1DOUT : std_logic_vector(7 downto 0);
....
y < signed(U1DOUT);
U1: somedevice
port map ( DIN => std_logic_vector(x),
DOUT => U1DOUT);

This is pretty ugly and gets uglier with dynamic widths, "generate"
statements and so on. Is the simpler approach above invalid VHDL or is
XST just exhibiting yet more broken behaviour?

Thanks in advance,


0xADF

Mon Jul 26, 2010 5:27 pm   

On Jul 26, 8:30 am, Andrew Feldhaus <Re...@thread.pls> wrote:

I don't recall the syntax used for conversions in port maps. Have you
tried

port map ( DIN => std_logic_vector(x),
DOUT => std_logic_vector(y));

I just use the clunkier method you outline above since this seems to
be a sticky issue with various tools. Better to have the code work
across tools than to worry about being "pretty". BTW, you use the
term "correct" to describe the port map conversion. If it doesn't
work, then I don't consider it to be "correct".

Git 'er done!

Rick

Mon Jul 26, 2010 6:53 pm   

On Jul 26, 8:30 am, Andrew Feldhaus <Re...@thread.pls> wrote:

The code is correct, brand X tools are deficient in this instance.

One way to hide the ugliness a bit is to create a wrapper around the X
generated IP that then has the interface that you want. Then do the
work around in the architecture of the wrapper. If you're only using
a small number of such IP blocks but instantiating them several places
this may not be too bad. If you only instantiate the IP block once,
and you're married to using X and their toolset then you'll have to
live with the workaround.

KJ

Mon Jul 26, 2010 6:57 pm   

On Jul 26, 10:27 am, rickman <gnu...@gmail.com> wrote:

If 'it' is the brand X tools, then I agree.

If 'it' is standard compliant code that is not being processed
properly by brand X tools, then I disagree.

Correctness is determined by compliance to the standard, not to some
lowest common denominator implementation of that standard. The need
to get the job done though is determined by working around whatever
shortcomings come along with the tools and parts that have been
chosen.

KJ

Tue Jul 27, 2010 8:57 am   

Andrew Feldhaus <Reply_at_thread.pls> writes:


I'd disagree. I use numeric (and other) types all the time on
component ports (integers, unsigneds, records...).

Only on the topmost entity do I stick to std_logic(_vector)s
throughout - simply because it means I can drop the post-synth or
post-PAR netlist straight into my topmost testbench without having to
faff around writing a wrapper.


Hmmm, yes. They also produce use "ieee.std_logic_arith.all" clauses
by default (unless that changed in 12.1). They (vendors' example
code) are not the best place to find best-practise :)


By all means use them - I don't think XST has a problem synthesising
them.

I've snipped the rest of your, post, as I think you're better off
using the appropriate types, rather than trying to force them all to
by std_logics (But I can't see anything wrong with what you've done either.)

Cheers,
Martin

--
martin.j.thompson_at_trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

Tue Jul 27, 2010 6:30 pm   

On 27 Jul., 09:57, Martin Thompson <martin.j.thomp...@trw.com> wrote:

Why?
Todays FPGAs don't even have tristate buffers internally so STD_ULOGIC
is clearly more
appropriate than STD_LOGIC.
It simulates faster and there are bugs that can be found by the
synthesis tools earlier in the
build process (i.e. signals with multiple drivers)

SIGNED and UNSIGNED are subtypes of STD_LOGIC, so there should be no
issue whatsoever
in synthesizing them.

Some synthesis tools throw away the type information when creating
timing simulation models
and replace them with STD_LOGIC which clearly is a bug of the tools.
It is very easy to write a Perl script that puts the type information
back in so there plainly is no excuse
for the tools to do that.


Kolja

Thu Jul 29, 2010 2:05 am   

On Jul 27, 11:30 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:

I was giving consideration to using STD_ULOGIC, but I actually mostly
use signed and unsigned for vectors and I believe they are implemented
as subtypes of std_logic_vector, no? So I could use STD_ULOGIC for
the control signals, but my buses would still essentially be
STD_LOGIC. Would that really speed up my simulations much?

I do appreciate the superior bug catching of using STD_ULOGIC, that is
why I was thinking about changing my default type. But I am concerned
that the conversion routines in numeric_std won't work with STD_ULOGIC
and I would have to add yet another layer of conversion text. VHDL is
already wordy, I hate to add to that.

Rick

Thu Jul 29, 2010 2:34 am   

On Jul 27, 11:30 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:


type UNSIGNED is array (NATURAL range <>) of STD_LOGIC;
type SIGNED is array (NATURAL range <>) of STD_LOGIC;
TYPE std_logic_vector IS ARRAY ( NATURAL RANGE <>) OF std_logic;

Kevin Jennings

Thu Jul 29, 2010 2:34 am   

On Jul 28, 7:05 pm, rickman <gnu...@gmail.com> wrote:

No, they are implemented as arrays of std_logic. Signed, unsigned and
std_logic_vector have exactly the same definition...

type UNSIGNED is array (NATURAL range <>) of STD_LOGIC;
type SIGNED is array (NATURAL range <>) of STD_LOGIC;
TYPE std_logic_vector IS ARRAY ( NATURAL RANGE <>) OF std_logic;

Even though they have the same definition, because they are declared
as *type* and not *subtype* it means that you can't just assign
something of one type to something else of another. From earlier
posts, I know that this is a gripe of yours, but that's the way strong
type checking works.


There aren't any *extra* conversions caused by using std_ulogic versus
std_logic, you will have to change some existing conversions
though....

Instead of this:
Some_slv_sig <= std_logic_vector(Some_unsigned);
Do this
Some_slv_sig <= std_ulogic_vector(Some_unsigned);

Kevin Jennings

Thu Jul 29, 2010 1:43 pm   

On 29 Jul., 02:34, KJ <kkjenni...@sbcglobal.net> wrote:


a package numeric_unresolved would be nice....

Kolja

Thu Jul 29, 2010 8:15 pm   

On Jul 29, 6:43 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:

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

Fri Jul 30, 2010 7:20 pm   

On Jul 29, 6:43 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:

There is no reason why unresolved can't be added to numeric_std is
there?

Thu Aug 05, 2010 5:41 pm   

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