Spartan XC2S200 - how many BlockRAMs ?

[Przemyslaw Wegrzyn]

Hi !

I'm using XST to synthesise my VHDL sources. Target device is XC2S200 in
PQ208 package. According to the Spartan II family datasheet, this device
containes 14 BlockRAMs , 4096bits each, which gives 56kbits total.

But unfrotunately XST reports only 7 blocks available in the log file ! And
of course I'm going to exceed it .

Here are parts of the log file.

---- Target Parameters
Output File Name : bitstream_cpu
Output Format : NGC
Target Device : xc2s200-6pq208

Device utilization summary:
---------------------------

Selected Device : 2s200pq208-6

Number of Slices: 396 out of 2352 16%
Number of Slice Flip Flops: 161 out of 4704 3%
Number of 4 input LUTs: 652 out of 4704 13%
Number of bonded IOBs: 86 out of 144 59%
Number of TBUFs: 64 out of 2352 2%
Number of BRAMs: 1 out of 7 14%
Number of GCLKs: 1 out of 4 25


What I do/understand incorrectly ?

Regards,
Przemyslaw Wegrzyn

 

[john jakson]

---------------------------

Selected Device : 2s200pq208-6

Number of Slices: 396 out of 2352 16%
Number of Slice Flip Flops: 161 out of 4704 3%
Number of 4 input LUTs: 652 out of 4704 13%
Number of bonded IOBs: 86 out of 144 59%
Number of TBUFs: 64 out of 2352 2%
Number of BRAMs: 1 out of 7 14%
Number of GCLKs: 1 out of 4 25


What I do/understand incorrectly ?

Regards,
Przemyslaw Wegrzyn

I see the exact same problem in WebPack 6.1 (no service pack) when
toying a cpu datapath into Spartan3-400. Datasheet says 16 blockrams,
report says 1 of 8. Hopefully the service pack v3 will fix that,
right. Also I seem to recall Webpack would allow Spartan3-1000 or was
that wishfull thinking.

Another point of note, when choosing a cpu datapath width that might
be adder or blockram cycle limited, I found that the 1st registered
output of blockram is some slower than normal pipe stage. Seems
optimal result is for 16b wide datapath that allows adds and ram
access to both hit close to 200MHz but only if bram output has extra
pipe stage. A cpu that has blockram regfile output feeding alu logic
and 32bit wide is double penalized down to 120MHz or so. This leads to
architecture decisions based on low level details that will be far
different than classic risc (MicroBlaze at 85MHz etc) but seems
otherwise justified for higher performance since I can always use
multi cycle opcodes.

johnjakson_usa_com