«

Weng Tianxiang wrote:

> Another question is unanswered:
>
> Why unsigned/signed cannot be used in top layer? and why the signals in
> the top layer must be std_logic and std_logic_vector?

Usually synthesis creates a toplevel that has only std_logic* signals. And if
you want to simulate netlist without any extra wrappers, it's easiest to use
std_logic also at the RTL top level symbol.

In asics sometimes you still need the wrappers, because the io-pads are done during
the netlist generation in many flows. In that case RTL toplevel does not yet have
three state drivers and simulation wrapper is needed to match the netlist
functionality.

--Kim

Eric Smith wrote:
> Reto Zimmermann wrote:
>
>>The reason why not to use integer is that it is defined as a 32 bit
>>signed vector.

> No, it isn't. It is defined as an integer with a range of at least
> -2147483647 to +2147483647.

That's the spec, but a top integer port
has to default to something for synthesis,
if no range is specified.

That something is a 32 bit signed vector
for all synthesis tools I know of.

-- Mike Treseler

Reto Zimmermann wrote:
> The reason why not to use integer is that it is defined as a 32 bit
> signed vector.

I wrote:
> No, it isn't. It is defined as an integer with a range of at least
> -2147483647 to +2147483647.

Mike Treseler wrote:
> That's the spec, but a top integer port has to default to something
> for synthesis, if no range is specified.
> That something is a 32 bit signed vector for all synthesis tools I
> know of.

As soon as you start depending on using an integer type and having it
syntheisze to a 32-bit signed vector, someone somewhere will release
a synthesis tool that produced a 64-bit vector, or a 37-bit vector,
or soemthing else that meets the spec but isn't what you expect.

If you want a 32-bit vector, write it that way. Don't count on
behavior that is implementation-specific.

Eric Smith wrote:

> If you want a 32-bit vector, write it that way. Don't count on
> behavior that is implementation-specific.

I agree.
Reto was advocating not using integers.
I was explaining where the length 32 came from.

-- Mike Treseler

[janeruth]

Hi

After much googling and reading and this post in particular I was convinced I should be using IEEE.numeric_std libraries instead of std_logic_unsigned. (and am a bit mystified why I'd only ever been taught about the later :/)

But anyways, it's been working wonderfully for all my modules until it comes to connecting things to BRAM or FIFOs. Up til now I've just always used ISE's coreGen for the likes of such assuming they'll have implemented things far more optimally that I ever could considering it's their FPGA. However, as I've seen posted all over the place they don't use unsigned but slv's... Does any one know how to get around this other than writing yet another wrapper to convert everything?

I can't find a way to get coreGen to generate code using unsigned instead and can't find a way of easily extracting the relevant files from the library that coreGen pulls out to manually convert them. Can anyone tell me how they've gotten around such? Please!?