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

On Jul 26, 8:30=A0am, Andrew Feldhaus
<Re...@thread.pls> wrote:
> 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_vecto=
r
> 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. =A0E.g., where x and y are compatibly-
> sized signed signals:
>
> U1: somedevice
> =A0 port map ( =A0DIN =3D> std_logic_vector(x),
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 signed(DOUT) =3D> =A0y);
>
> 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". =A0The obvio=
us
> work-around, suggested athttp://www.xilinx.com/support/answers/18188.htm,
> is to add a signal:
>
> signal =A0U1DOUT : std_logic_vector(7 downto 0);
> ...
> y < signed(U1DOUT);
> U1: somedevice
> =A0 port map ( =A0DIN =3D> std_logic_vector(x),
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 DOUT =3D> U1DOUT);
>
> This is pretty ugly and gets uglier with dynamic widths, "generate"
> statements and so on. =A0Is the simpler approach above invalid VHDL or is
> XST just exhibiting yet more broken behaviour?
>
> Thanks in advance,
>
> 0xADF

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

  port map (  DIN =3D> std_logic_vector(x),
              DOUT =3D>  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

On Jul 26, 8:30=A0am, Andrew Feldhaus
<Re...@thread.pls> wrote:
>
> This is pretty ugly and gets uglier with dynamic widths, "generate"
> statements and so on. =A0Is the simpler approach above invalid VHDL or is
> XST just exhibiting yet more broken behaviour?
>

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

On Jul 26, 10:27=A0am, rickman
<gnu...@gmail.com> wrote:
> If it doesn't
> work, then I don't consider it to be "correct".
>

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

Andrew Feldhaus <R...@thread.pls> writes:

> 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.

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.

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

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 :)

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

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

-- 
m...@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

On 27 Jul., 09:57, Martin Thompson
<martin.j.thomp...@trw.com> wrote:
> Andrew Feldhaus <Re...@thread.pls> writes:
> > 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.

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

On Jul 27, 11:30=A0am, Kolja Sulimma
<ksuli...@googlemail.com> wrote:
>
> SIGNED and UNSIGNED are subtypes of STD_LOGIC,
Not quite...the definitions are:

  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

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