ieee.numeric_std?

K

Kim Enkovaara

Weng said:
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
 
M

Mike Treseler

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
 
E

Eric Smith

Reto said:
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.

Mike said:
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.
 
M

Mike Treseler

Eric said:
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
 
Joined
Jul 23, 2009
Messages
9
Reaction score
0
Convinced to use numeric_std but now can't with ISE...?

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!?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,767
Messages
2,569,572
Members
45,046
Latest member
Gavizuho

Latest Threads

Top