the memory handling with respect to efficient dual port ram was, to address it neutrally, suboptimal, so I've had to mostly hack my own memory inference rules
this is a big problem to support two of the hobby projects I would like to complete
- VDU, all-in-one
- TrMem, all-in-one
Both are "all-in-one" profiled without any external dual port ram chip.
So, the bram is the only RAM resource I have available
and it must be dual-port, two read, one write, for at least 4Kbyte
ISE has some problems when instantiating bram with 8bit databus for Spartan3
e.g. your CPU is 32bit, so you are tempted to describe the resource as 4x8bit
with four byte_enable control bits in the load/store stage.
supporting
load{8,16,32}bit <-- { byte3_en,byte2_en,byte1_en,byte0_en }(size)={ (0,0,0,1), (0,0,1,1), (1,1,1,1) }
store{8,16,32}bit <-- { byte3_en,byte2_en,byte1_en,byte0_en }(size)={ (0,0,0,1), (0,0,1,1), (1,1,1,1) }
Good idea, from the design point of view, but it's not efficient on synthesis
I found it works much better when instantiating bram with 16 databus.
This is because physically the SP3 bram resource is made exactly like this: with 16bit databus!
* * *
In order to make portable projects
I think, at worst I can describe the "dualport-ram" as a generic entity
and then write a specific VHDL module for each physical FPGA
so, with some tricks for Spartan3, etc...
Home
Help
Search
Login
Register
