I don't really want to have to build a gigantic constant assignment
table,

but I also suspect that declaring an array of std_logic_vectors
as a signal and then writing them one by one in from a file would
probably take a really long time to execute.

I searched around a while last week but didn't really find any
concrete answers on this...

I don't really want to have to build a gigantic constant assignment
table,

Why not?  That's the fastest way to accomplish the task...fast both
for development as well as fast sim.

Well, the first order of business is that you won't be writing an
array of std_logic_vectors to a file in order model a ROM, you would
be reading them in from a file.

Second, your suspicions are not correct, the sim time to read in and
parse the ROM data would be negligible.  The development time to do
this however, would be considerably longer though then simply defining
the constant array.  It's up to you to decide on how to spend your
time.

You may find an already written model for the part that you'll be
using onhttp://www.freemodelfoundry.com/

Kevin Jennings

Seconded. If you need to read files created by other tools (e.g. a spreadsheet,
or a binary file like a .bmp) this is a reasonable way to do it, and more
flexible than the above approach. However ISE Simulator has some
not-well-documented obstacles(*) to reading binary files, which is more
straightforward in Modelsim.

(*) As of ISE10:
a) it is opposite-endian to Modelsim's treatment of the same file.
b) ISIM writes an undocumented header before the file contents, and expects to
see that header on any file it reads. You can convert a 3rd party file to/from
ISIM using head, tail and cat to extract/insert the header (on Linux, or the
Windows equivalent commands) but it's a bother.
c)  Xilinx have declined to document this header. However there is a Change
Request to fix these issues; I have no idea if/when it will happen.

- Brian

I don't really want to have to build a gigantic constant assignment
table,

Why not?  That's the fastest way to accomplish the task...fast both
for development as well as fast sim.

Well, because I didn't really want such a long constant table as part
of my testbench, though I suppose I can keep it in package in a
separate file where it would be out of the way.

Second, your suspicions are not correct, the sim time to read in and
parse the ROM data would be negligible.  The development time to do
this however, would be considerably longer though then simply defining
the constant array.

snip
If your ROM is *really* big (> 1M locations) you may run into simulator
difficulties if you define the contents as an array of std_logic_vector.
Defining it as an array of integer is most memory-efficient, but you have
to convert it to signed/unsigned and cast to std_logic_vector to drive the
port.

I'll just make the big array of constants, and rewrite the file
whenever I need to make changes to it.

You can also initialize a constant, variable, or signal with a
function call that returns the value to be used for initialization. So
if you have a simple enough algorithm for the contents to code in
vhdl, that might be a simpler way yet.

If you can use an integer (range constraints withstanding), it will be
smaller and more efficient. The VHDL LRM requires AT LEAST the range
-2147483647 to 2147483647 to be implemented for integer, but many
(most?) implementations handle the entire 32 bit two's complement
range.

for a reasonably large ROM, or a complex function (e.g. function calls nested 4
levels deep) XST will take an unbelievably long time to synthesise it. There's
an N^2 algorithm in there somewhere; if it takes 15 minutes for a 1000 element
array, it'll take an hour for 2000 elements, 4 hours for 4000, etc...

... snip ...

for a reasonably large ROM, or a complex function (e.g. function calls nested 4
levels deep) XST will take an unbelievably long time to synthesise it. There's
an N^2 algorithm in there somewhere; if it takes 15 minutes for a 1000 element
array, it'll take an hour for 2000 elements, 4 hours for 4000, etc...

On Oct 30, 11:14 pm, Brian Drummond <brian_drumm... at (no spam) btconnect.com
wrote:
... snip ...

for a reasonably large ROM, or a complex function (e.g. function calls nested 4
levels deep) XST will take an unbelievably long time to synthesise it. There's
an N^2 algorithm in there somewhere; if it takes 15 minutes for a 1000 element
array, it'll take an hour for 2000 elements, 4 hours for 4000, etc...

Is this *still* happening? This has been CRed so many times, and I
know it's been fixed for at least some of the test cases we came up
with internally... if you have some example code that exhibits this in
the latest ISE, and you're willing to share it, let me know and I'll
try to beat the XST team around the head with it again. :-/

On Sun, 1 Nov 2009 09:58:10 -0800 (PST), Ben Jones <benj... at (no spam) gmail.com> wrote:
On Oct 30, 11:14 pm, Brian Drummond <brian_drumm... at (no spam) btconnect.com
wrote:
... snip ...

for a reasonably large ROM, or a complex function (e.g. function calls nested 4
levels deep) XST will take an unbelievably long time to synthesise it. There's
an N^2 algorithm in there somewhere; if it takes 15 minutes for a 1000 element
array, it'll take an hour for 2000 elements, 4 hours for 4000, etc...

Is this *still* happening? This has been CRed so many times, and I
know it's been fixed for at least some of the test cases we came up
with internally... if you have some example code that exhibits this in
the latest ISE, and you're willing to share it, let me know and I'll
try to beat the XST team around the head with it again. :-/

I have been informed by a student employee it's still true in ISE11.1 but
haven't verified it myself. Will check in the next couple of days and email you
privately.

Alternatively you may be able to access a pathological testcase attached to
Webcase 717144, as used by above student.

It asserts on every LUT entry, so you can watch it slow down... (and no, the
assert is not the performance bottleneck!)

- Brian