FPGA Central

I'm experiencing an error using XST during synthesis involving a type
conversion on a port instance:
http://www.xilinx.com/xlnx/xil_ans_d...PagePath=18188

Is this legal syntax in the vhdl standard?

I was told by a Xilinx applications engineer that they don't have a fix
and I have to do the workaround. What a pain... Do the other synthesis
tools support this syntax?

On 3 Aug 2005 05:59:31 -0700, "Brandon" <[email protected]> wrote:

>I'm experiencing an error using XST during synthesis involving a type
>conversion on a port instance:
>http://www.xilinx.com/xlnx/xil_ans_d...PagePath=18188
>
>Is this legal syntax in the vhdl standard?

Yes. There was a change from VHDL-87 to VHDL-93 that fixed a
silly inconsistency: VHDL-87 didn't accept array type conversions
on a port map, so for example if you have a std_logic_vector signal S
and you want to connect it to an "unsigned" input port P:

.... port map (... P => unsigned(S) ...)

is legal in VHDL-93 but was forbidden in '87.

>I was told by a Xilinx applications engineer that they don't have a fix
>and I have to do the workaround. What a pain... Do the other synthesis
>tools support this syntax?

Mostly, yes.

The workaround is hardly a big deal, though. Just tedious.
It may be cleaner to do the workaround by building a wrapper
entity, so that you can hide the type conversion and its
associated extra signal in the wrapper rather than exposing
it in the upper-level entity.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:[email protected]
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Actually, this syntax was ok:
port map (... P => unsigned(S) ...)

While this was not:
port map (... unsigned(A) => B ...)

I don't understand why they haven't fixed this... Is there any sort of
option to toggle VHDL-93 syntax? I can't find any mention of it in the
XST user guide...

If you don't mind, could you explain the wrapper workaround? I made the
changes manually myself, but that involved creating a duplicate signal
to perform the type conversion on. This is quite sloppy imo, and I
dislike having to tailor my code to a specific tool.

Thanks a bunch.

On 4 Aug 2005 13:17:10 -0700, "Brandon" <[email protected]> wrote:

>Actually, this syntax was ok:
>port map (... P => unsigned(S) ...)
>
>While this was not:
>port map (... unsigned(A) => B ...)

ok - both versions should be absolutely fine, assuming
A is an output port of course. Both forms were made
legal in VHDL-93 (in VHDL-87 it would have been necessary
to write your own function, something like "my_unsigned",
so that the conversion is a function call rather than an
array type conversion)

>I don't understand why they haven't fixed this...

Not enough people shouting about it, I guess.

> Is there any sort of
>option to toggle VHDL-93 syntax?

You must have VHDL-93 enabled already, otherwise the input-port
conversion would also have been illegal.

>If you don't mind, could you explain the wrapper workaround? I made the
>changes manually myself, but that involved creating a duplicate signal
>to perform the type conversion on. This is quite sloppy imo, and I
>dislike having to tailor my code to a specific tool.

Well... the code you end up with will work in any tool OK, it's
just that it is tiresome to do. I wasn't suggesting anything
different - just another layer of module instantiation so that
the conversion is not visible in the top-level module:

entity Original is
port (P: in unsigned(...); Q: out std_logic_vector(...));
end;

entity Wrapper is
port (P: in std_logic_vector(...); Q: out unsigned(...));
end;
architecture Hack of Wrapper is
signal QU: unsigned(...);
begin
Original_Instance: entity work.Original(arch)
port map (P => unsigned(P), Q => QU);
Q <= std_logic_vector(QU);
end;

Now, when you instantiate Wrapper in your top-level module,
no type conversion is needed. I'm sure this is exactly
what you have already done - I'm merely suggesting the
wrapper module as a way of localising the type conversion
so that it doesn't pollute the architecture of the
enclosing module.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:[email protected]
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Actually I did use functions to perform the conversion. For some reason
it only complained when the function call was on the left hand side of
the port map.

Thanks for the help.