On 4/5/07, lingwitt@xxxxxxxxxxxxx <lingwitt@xxxxxxxxxxxxx> wrote:
I've made a BMP image format creating module for fun.
Looks like it's not so fun after all :-(
I maintain a 640x480 24-bits per pixel buffer and then write the data
out to a file.
At first I used a reg array, but came to find that each element of
such a structure
is expressed in vvp assembly as distinct reg. This made the vvp
assembly 32 MB
and unrunnable.
So, I changed the memory into a single reg vector with a gigantic
width, but the
simulation is still dog slow.
How can I do this more effectively?
In real life, you never do this in the first place. If this was to be synthesized, you would end up with
7.3M flops, which is way above what you get with a reasonable ASIC technology (I think this would be too high even for 65u).
The way to do this is to manually instanciate a vendor module of the real memory that is more efficient (sram cells or register array), and so your logic doesn't have to handle all of this.
For one specific ASIC process I worked with, I think the approximate area ratio between flops, register arrays, and embedded SRAMs is about 50:10:1 respecively. This means that instantiating the vendor's SRAM cells of the appropriate size would have taken 1/50 the area of coding this using flops.
Even with FPGAs you have embedded memory arrays that are much more efficient than manually coding this using flops (maybe some of the synthesis tools can choose these cells for you if you code your arrays correctly, but I haven't synthesized for FPGAs in years).
As for your specific question (how to handle this size of simulation) - looking at the behavioral models of embedded SRAMs we use at work, it seems we use a simple reg declaration (like you did), and it worked fine with the Synopsys VCS simulator.
It looks to me like this is an Icarus-specific problem.
Udi