Spartan II Block Ram

Chuck Gales · Dec 21, 2003

All,
I am trying to implement a design in a Xilinx Spartan II FPGA, where I
desire to use Block Ram as internal memory. I have run my design through
simulation, where everything works fine. However, after synthesis and
programming the FPGA, the system acts as if the RAM wasn't there.
Is there something I'm missing? I've ensured that I am accessing the
memory synchronously. Other than that, I'm stumped. I wouldn't think
that timing is an issue (24Mhz main clock).
Any ideas?

Thanks,

Chuck Gales

tbx135 · Dec 22, 2003

Look at the EDF through a reader. Make sure it's not an empty component. You
should also see this in transcript.

"Chuck Gales" <cgales@_NOSPAM_nc.rr.com> wrote in message
news

an.2003.12.21.22.25.24.447595@_NOSPAM_nc.rr.com...

All,
I am trying to implement a design in a Xilinx Spartan II FPGA, where I
desire to use Block Ram as internal memory. I have run my design through
simulation, where everything works fine. However, after synthesis and
programming the FPGA, the system acts as if the RAM wasn't there.
Is there something I'm missing? I've ensured that I am accessing the
memory synchronously. Other than that, I'm stumped. I wouldn't think
that timing is an issue (24Mhz main clock).
Any ideas?

Thanks,

Chuck Gales

John Retta · Dec 22, 2003

The other respondant had the correct idea. Lots of times outputs
signals from one logic function to another might be misnamed, and
hence the source block might be optimized away. Problem is that
the offending problem may be several layers past the block which
has been eliminated, and for some reason the synthesis tools are
not as clear as they used to be where the problem is located.

The simulator is usually a good place to isolate these problems,
although it sounds like you have tracked the data paths already.

Check the .mrp report in your synthesis directory, and make sure
the number of block rams are what you expect. If I have 100
synthesis runs for a design over 2 months, I check this file
every run.

--
Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.

email : jretta@rtc-inc.com
web : www.rtc-inc.com

"Chuck Gales" <cgales@_NOSPAM_nc.rr.com> wrote in message
news

an.2003.12.21.22.25.24.447595@_NOSPAM_nc.rr.com...

All,
I am trying to implement a design in a Xilinx Spartan II FPGA, where I
desire to use Block Ram as internal memory. I have run my design through
simulation, where everything works fine. However, after synthesis and
programming the FPGA, the system acts as if the RAM wasn't there.
Is there something I'm missing? I've ensured that I am accessing the
memory synchronously. Other than that, I'm stumped. I wouldn't think
that timing is an issue (24Mhz main clock).
Any ideas?

Thanks,

Chuck Gales

Chuck Gales · Dec 22, 2003

On Mon, 22 Dec 2003 04:51:48 +0000, John Retta wrote:

The other respondant had the correct idea. Lots of times outputs signals
from one logic function to another might be misnamed, and hence the source
block might be optimized away. Problem is that the offending problem may
be several layers past the block which has been eliminated, and for some
reason the synthesis tools are not as clear as they used to be where the
problem is located.

The simulator is usually a good place to isolate these problems, although
it sounds like you have tracked the data paths already.

Check the .mrp report in your synthesis directory, and make sure the
number of block rams are what you expect. If I have 100 synthesis runs
for a design over 2 months, I check this file every run.

Looking at the .mrp report, I see the 4 block rams as expected. Also, the
post-synthesis HDL model functions correctly, so it seems that everything
is being synthesized correctly.

There doesn't seem to be any critical warnings or errors about the Block
Ram. I do receive the following warning:

WARNING:Xst:1772 - You have explicitly defined initial contents for this
RAM, which are currently ignored when the RAM is implemented with LUT
resources, leading to incorrect circuit behavior. Changing the RAM
description so that it is read synchronously will allow implementation on
block RAM resources for which we provide full initial contents support.

I am not really sure why this warning is received, since the ram is
designed with RAMB_S4 primitives and accessed synchronously.

Could this lead to something?

Chuck

tbx135 · Dec 22, 2003

WARNING:Xst:1772 - You have explicitly defined initial contents for this
RAM, which are currently ignored when the RAM is implemented with LUT
resources, leading to incorrect circuit behavior. Changing the RAM
description so that it is read synchronously will allow implementation on
block RAM resources for which we provide full initial contents support.

I am not really sure why this warning is received, since the ram is
designed with RAMB_S4 primitives and accessed synchronously.

Could this lead to something?

Chuck

The Libraries guide, page 1481 talks about the primitive RAMB4_Sn, which is
what I think you meant. According to your message, XST does not think you
are using the Block RAM resource. It is using a LUT instead. Did you use the
coregen tool to make this?

Spartan II Block Ram uses a .coe to initialize contents. Are you using this
as well?

tbx135 · Dec 22, 2003

Check this one out too.
http://toolbox.xilinx.com/docsan/xilinx4/data/docs/sim/vtex11.html

My guess is that you behaviorally changed this and XST now is instantiating
a LUT version of the memory. That would be a new one on me...

John Retta · Dec 22, 2003

Kind of a puzzle since you say that the .mrp report states there are
exactly the number of block rams that you expect, yet the warning
claims there are additional RAM cells implemented in distributed
LUTs.

Is it clear that the LUT RAMs are the intended block RAMs, or
that they are an entirely new block of logic altogether?

Other poster has good point about using coregen.

I personally avoid coregen. Not much more effort to instantiate
blockrams directly (see lib.pdf), and you get exactly what you
want.

Take another look at bottom of .mrp file. There is also a section
which describes the initialization values used for the block rams.
It sounds like you are intializing the block rams, so the values
you expect to use should show up down here.

--
Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.

email : jretta@rtc-inc.com
web : www.rtc-inc.com

"Chuck Gales" <cgales@_NOSPAM_nc.rr.com> wrote in message
news

an.2003.12.22.11.30.11.552120@_NOSPAM_nc.rr.com...

On Mon, 22 Dec 2003 04:51:48 +0000, John Retta wrote:

The other respondant had the correct idea. Lots of times outputs
signals
from one logic function to another might be misnamed, and hence the
source
block might be optimized away. Problem is that the offending problem
may
be several layers past the block which has been eliminated, and for some
reason the synthesis tools are not as clear as they used to be where the
problem is located.

The simulator is usually a good place to isolate these problems,
although
it sounds like you have tracked the data paths already.

Check the .mrp report in your synthesis directory, and make sure the
number of block rams are what you expect. If I have 100 synthesis runs
for a design over 2 months, I check this file every run.

Looking at the .mrp report, I see the 4 block rams as expected. Also, the
post-synthesis HDL model functions correctly, so it seems that everything
is being synthesized correctly.

There doesn't seem to be any critical warnings or errors about the Block
Ram. I do receive the following warning:

WARNING:Xst:1772 - You have explicitly defined initial contents for this
RAM, which are currently ignored when the RAM is implemented with LUT
resources, leading to incorrect circuit behavior. Changing the RAM
description so that it is read synchronously will allow implementation on
block RAM resources for which we provide full initial contents support.

I am not really sure why this warning is received, since the ram is
designed with RAMB_S4 primitives and accessed synchronously.

Could this lead to something?

Chuck

Chuck Gales · Dec 22, 2003

On Mon, 22 Dec 2003 16:51:42 +0000, tbx135 wrote:

Check this one out too.
http://toolbox.xilinx.com/docsan/xilinx4/data/docs/sim/vtex11.html

My guess is that you behaviorally changed this and XST now is
instantiating a LUT version of the memory. That would be a new one on
me...

Well,
Here is the SRAM module I have created:

// Spartan II SRAM based on Xilinx MemBlock Primative
//
`timescale 1ns/1ns

module spartanii_sram (
reset_n,
we_n,
ce_n,
clk,
addr,
din,
dout
);

input reset_n;
input we_n;
input ce_n;
input clk;
input [9:0] addr;
input [7:0] din;
output [7:0] dout;

RAMB4_S4 sram_low(
.EN (~ce_n ),
.RST (~reset_n ),
.WE (~we_n ),
.CLK (clk ),
.ADDR (addr ),
.DI (din[3:0] ),
.DO (dout[3:0] )
);

RAMB4_S4 sram_hi(
.EN (~ce_n ),
.RST (~reset_n ),
.WE (~we_n ),
.CLK (clk ),
.ADDR (addr ),
.DI (din[7:4] ),
.DO (dout[7:4] )
);

endmodule

There are no values assigned, yet for some reason, XST thinks that there
are??? Looking at the final report, it states that there are 4 RAM BLOCKS
generated (I include this module twice), which seems correct.

I also define a ROM module, which might be picked up as a RAM block, but
that works fine, and looking at the synthesis report, the ROM seems to be
inmplemented as LUTs.

Chuck Gales · Dec 22, 2003

On Mon, 22 Dec 2003 19:34:28 +0000, John Retta wrote:

Kind of a puzzle since you say that the .mrp report states there are
exactly the number of block rams that you expect, yet the warning claims
there are additional RAM cells implemented in distributed LUTs.

Is it clear that the LUT RAMs are the intended block RAMs, or that they
are an entirely new block of logic altogether?

Other poster has good point about using coregen.

I personally avoid coregen. Not much more effort to instantiate blockrams
directly (see lib.pdf), and you get exactly what you want.

Take another look at bottom of .mrp file. There is also a section which
describes the initialization values used for the block rams. It sounds
like you are intializing the block rams, so the values you expect to use
should show up down here.
I looked at the .mrp and see no initialization of RAM. Here is the

complete .mrp file. I see nothing which would indicate a problem.

Release 6.1.03i Map G.26
Xilinx Mapping Report File for Design 'spartanii_z80'

Design Information
------------------
Command Line : C:/Xilinx/bin/nt/map.exe -intstyle ise -p xc2s200-fg456-5 -cm
area -pr b -k 4 -c 100 -tx off -o spartanii_z80_map.ncd spartanii_z80.ngd
spartanii_z80.pcf
Target Device : x2s200
Target Package : fg456
Target Speed : -5
Mapper Version : spartan2 -- $Revision: 1.16 $
Mapped Date : Sun Dec 21 16:38:57 2003

Design Summary
--------------
Number of errors: 0
Number of warnings: 3
Logic Utilization:
Number of Slice Flip Flops: 441 out of 4,704 9%
Number of 4 input LUTs: 2,670 out of 4,704 56%
Logic Distribution:
Number of occupied Slices: 1,528 out of 2,352 64%
Number of Slices containing only related logic: 1,528 out of 1,528 100%
Number of Slices containing unrelated logic: 0 out of 1,528 0%
*See NOTES below for an explanation of the effects of unrelated logic
Total Number 4 input LUTs: 2,797 out of 4,704 59%
Number used as logic: 2,670
Number used as a route-thru: 63
Number used for Dual Port RAMs: 64
(Two LUTs used per Dual Port RAM)
Number of bonded IOBs: 18 out of 284 6%
Number of Tbufs: 8 out of 2,464 1%
Number of Block RAMs: 4 out of 14 28%
Number of GCLKs: 1 out of 4 25%
Number of GCLKIOBs: 1 out of 4 25%

Total equivalent gate count for design: 91,669
Additional JTAG gate count for IOBs: 912
Peak Memory Usage: 78 MB

NOTES:

Related logic is defined as being logic that shares connectivity -
e.g. two LUTs are "related" if they share common inputs.
When assembling slices, Map gives priority to combine logic that
is related. Doing so results in the best timing performance.

Unrelated logic shares no connectivity. Map will only begin
packing unrelated logic into a slice once 99% of the slices are
occupied through related logic packing.

Note that once logic distribution reaches the 99% level through
related logic packing, this does not mean the device is completely
utilized. Unrelated logic packing will then begin, continuing until
all usable LUTs and FFs are occupied. Depending on your timing
budget, increased levels of unrelated logic packing may adversely
affect the overall timing performance of your design.

Table of Contents
-----------------
Section 1 - Errors
Section 2 - Warnings
Section 3 - Informational
Section 4 - Removed Logic Summary
Section 5 - Removed Logic
Section 6 - IOB Properties
Section 7 - RPMs
Section 8 - Guide Report
Section 9 - Area Group Summary
Section 10 - Modular Design Summary
Section 11 - Timing Report
Section 12 - Configuration String Information
Section 13 - Additional Device Resource Counts

Section 1 - Errors
------------------

Section 2 - Warnings
--------------------
WARNING

ack:266 - The function generator z80_u0_mcode_ALU_Op<2>27 failed to
merge with F5 multiplexer z80_u0_mcode_ALU_Op<2>219. There is a conflict for
the FXMUX. The design will exhibit suboptimal timing.
WARNING

ack:249 - The following adjacent carry multiplexers occupy different
slice components. The resulting carry chain will have suboptimal timing.
z80_u0_I149_inst_cy_67
z80_u0_I149_inst_cy_68
WARNING

tbx135 · Dec 22, 2003

Did you find a .coe file?
"Chuck Gales" <cgales@_NOSPAM_nc.rr.com> wrote in message
news

an.2003.12.22.22.36.07.341609@_NOSPAM_nc.rr.com...

On Mon, 22 Dec 2003 16:51:42 +0000, tbx135 wrote:

Check this one out too.
http://toolbox.xilinx.com/docsan/xilinx4/data/docs/sim/vtex11.html

My guess is that you behaviorally changed this and XST now is
instantiating a LUT version of the memory. That would be a new one on
me...

Well,
Here is the SRAM module I have created:

// Spartan II SRAM based on Xilinx MemBlock Primative
//
`timescale 1ns/1ns

module spartanii_sram (
reset_n,
we_n,
ce_n,
clk,
addr,
din,
dout
);

input reset_n;
input we_n;
input ce_n;
input clk;
input [9:0] addr;
input [7:0] din;
output [7:0] dout;

RAMB4_S4 sram_low(
.EN (~ce_n ),
.RST (~reset_n ),
.WE (~we_n ),
.CLK (clk ),
.ADDR (addr ),
.DI (din[3:0] ),
.DO (dout[3:0] )
);

RAMB4_S4 sram_hi(
.EN (~ce_n ),
.RST (~reset_n ),
.WE (~we_n ),
.CLK (clk ),
.ADDR (addr ),
.DI (din[7:4] ),
.DO (dout[7:4] )
);

endmodule

There are no values assigned, yet for some reason, XST thinks that there
are??? Looking at the final report, it states that there are 4 RAM BLOCKS
generated (I include this module twice), which seems correct.

I also define a ROM module, which might be picked up as a RAM block, but
that works fine, and looking at the synthesis report, the ROM seems to be
inmplemented as LUTs.

John Retta · Dec 22, 2003

You need the -d option in map .... then take a look at
section 12 of the map .rpt.

So if you did the addition on the number of block rams,
and it totaled 4, and that what was in the map file, then
you have dual ports elsewhere implemented with LUTs.

--
Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.

email : jretta@rtc-inc.com
web : www.rtc-inc.com

"Chuck Gales" <cgales@_NOSPAM_nc.rr.com> wrote in message
news

an.2003.12.22.22.41.18.876240@_NOSPAM_nc.rr.com...

On Mon, 22 Dec 2003 19:34:28 +0000, John Retta wrote:

Kind of a puzzle since you say that the .mrp report states there are
exactly the number of block rams that you expect, yet the warning claims
there are additional RAM cells implemented in distributed LUTs.

Is it clear that the LUT RAMs are the intended block RAMs, or that they
are an entirely new block of logic altogether?

Other poster has good point about using coregen.

I personally avoid coregen. Not much more effort to instantiate
blockrams
directly (see lib.pdf), and you get exactly what you want.

Take another look at bottom of .mrp file. There is also a section which
describes the initialization values used for the block rams. It sounds
like you are intializing the block rams, so the values you expect to use
should show up down here.
I looked at the .mrp and see no initialization of RAM. Here is the
complete .mrp file. I see nothing which would indicate a problem.

Release 6.1.03i Map G.26
Xilinx Mapping Report File for Design 'spartanii_z80'

Design Information
------------------
Command Line : C:/Xilinx/bin/nt/map.exe -intstyle ise -p
xc2s200-fg456-5 -cm
area -pr b -k 4 -c 100 -tx off -o spartanii_z80_map.ncd spartanii_z80.ngd
spartanii_z80.pcf
Target Device : x2s200
Target Package : fg456
Target Speed : -5
Mapper Version : spartan2 -- $Revision: 1.16 $
Mapped Date : Sun Dec 21 16:38:57 2003

Design Summary
--------------
Number of errors: 0
Number of warnings: 3
Logic Utilization:
Number of Slice Flip Flops: 441 out of 4,704 9%
Number of 4 input LUTs: 2,670 out of 4,704 56%
Logic Distribution:
Number of occupied Slices: 1,528 out of 2,352
64%
Number of Slices containing only related logic: 1,528 out of 1,528
100%
Number of Slices containing unrelated logic: 0 out of 1,528
0%
*See NOTES below for an explanation of the effects of unrelated
logic
Total Number 4 input LUTs: 2,797 out of 4,704 59%
Number used as logic: 2,670
Number used as a route-thru: 63
Number used for Dual Port RAMs: 64
(Two LUTs used per Dual Port RAM)
Number of bonded IOBs: 18 out of 284 6%
Number of Tbufs: 8 out of 2,464 1%
Number of Block RAMs: 4 out of 14 28%
Number of GCLKs: 1 out of 4 25%
Number of GCLKIOBs: 1 out of 4 25%

Total equivalent gate count for design: 91,669
Additional JTAG gate count for IOBs: 912
Peak Memory Usage: 78 MB

NOTES:

Related logic is defined as being logic that shares connectivity -
e.g. two LUTs are "related" if they share common inputs.
When assembling slices, Map gives priority to combine logic that
is related. Doing so results in the best timing performance.

Unrelated logic shares no connectivity. Map will only begin
packing unrelated logic into a slice once 99% of the slices are
occupied through related logic packing.

Note that once logic distribution reaches the 99% level through
related logic packing, this does not mean the device is completely
utilized. Unrelated logic packing will then begin, continuing until
all usable LUTs and FFs are occupied. Depending on your timing
budget, increased levels of unrelated logic packing may adversely
affect the overall timing performance of your design.

Table of Contents
-----------------
Section 1 - Errors
Section 2 - Warnings
Section 3 - Informational
Section 4 - Removed Logic Summary
Section 5 - Removed Logic
Section 6 - IOB Properties
Section 7 - RPMs
Section 8 - Guide Report
Section 9 - Area Group Summary
Section 10 - Modular Design Summary
Section 11 - Timing Report
Section 12 - Configuration String Information
Section 13 - Additional Device Resource Counts

Section 1 - Errors
------------------

Section 2 - Warnings
--------------------
WARNINGack:266 - The function generator z80_u0_mcode_ALU_Op<2>27 failed
to
merge with F5 multiplexer z80_u0_mcode_ALU_Op<2>219. There is a
conflict for
the FXMUX. The design will exhibit suboptimal timing.
WARNINGack:249 - The following adjacent carry multiplexers occupy
different
slice components. The resulting carry chain will have suboptimal
timing.
z80_u0_I149_inst_cy_67
z80_u0_I149_inst_cy_68
WARNINGack:249 - The following adjacent carry multiplexers occupy
different
slice components. The resulting carry chain will have suboptimal
timing.
z80_u0_I149_inst_cy_68
z80_u0_I149_inst_cy_69

Section 3 - Informational
-------------------------
INFO:LIT:95 - All of the external outputs in this design are using slew
rate
limited output drivers. The delay on speed critical outputs can be
dramatically reduced by designating them as fast outputs in the
schematic.
INFO:MapLib:562 - No environment variables are currently set.

Section 4 - Removed Logic Summary
---------------------------------
2 block(s) optimized away

Section 5 - Removed Logic
-------------------------

Optimized Block(s):
TYPE BLOCK
GND XST_GND
VCC XST_VCC

To enable printing of redundant blocks removed and signals merged, set the
detailed map report option and rerun map.

Section 6 - IOB Properties
--------------------------

+---------------------------------------------------------------------------

---------------------------------------------+

| IOB Name | Type | Direction | IO Standard |
Drive | Slew | Reg (s) | Resistor | IOB |
| | | | |
Strength | Rate | | | Delay |

+---------------------------------------------------------------------------

---------------------------------------------+

| CLK | GCLKIOB | INPUT | LVTTL |
| | | | |
| DISP_1A | IOB | OUTPUT | LVTTL |
12 | SLOW | | | |
| DISP_1B | IOB | OUTPUT | LVTTL |
12 | SLOW | | | |
| DISP_1C | IOB | OUTPUT | LVTTL |
12 | SLOW | | | |
| DISP_1D | IOB | OUTPUT | LVTTL |
12 | SLOW | | | |
| DISP_1E | IOB | OUTPUT | LVTTL |
12 | SLOW | | | |
| DISP_1F | IOB | OUTPUT | LVTTL |
12 | SLOW | | | |
| DISP_1G | IOB | OUTPUT | LVTTL |
12 | SLOW | | | |
| DISP_2A | IOB | OUTPUT | LVTTL |
12 | SLOW | | | |
| DISP_2B | IOB | OUTPUT | LVTTL |
12 | SLOW | | | |
| DISP_2C | IOB | OUTPUT | LVTTL |
12 | SLOW | | | |
| DISP_2D | IOB | OUTPUT | LVTTL |
12 | SLOW | | | |
| DISP_2E | IOB | OUTPUT | LVTTL |
12 | SLOW | | | |
| DISP_2F | IOB | OUTPUT | LVTTL |
12 | SLOW | | | |
| DISP_2G | IOB | OUTPUT | LVTTL |
12 | SLOW | | | |
| LED | IOB | OUTPUT | LVTTL |
12 | SLOW | | | |
| RESET_n | IOB | INPUT | LVTTL |
| | | | |
| RXD | IOB | INPUT | LVTTL |
| | | | |
| TXD | IOB | OUTPUT | LVTTL |
12 | SLOW | | | |

+---------------------------------------------------------------------------

---------------------------------------------+

Section 7 - RPMs
----------------

Section 8 - Guide Report
------------------------
Guide not run on this design.

Section 9 - Area Group Summary
------------------------------
No area groups were found in this design.

Section 10 - Modular Design Summary
-----------------------------------
Modular Design not used for this design.

Section 11 - Timing Report
--------------------------
This design was not run using timing mode.

Section 12 - Configuration String Details
-----------------------------------------
Use the "-detail" map option to print out Configuration Strings

Section 13 - Additional Device Resource Counts
----------------------------------------------
Number of JTAG Gates for IOBs = 19
Number of Equivalent Gates for Design = 91,669
Number of RPM Macros = 0
Number of Hard Macros = 0
PCI IOBs = 0
PCI LOGICs = 0
CAPTUREs = 0
BSCANs = 0
STARTUPs = 0
DLLs = 0
GCLKIOBs = 1
GCLKs = 1
Block RAMs = 4
TBUFs = 8
Total Registers (Flops & Latches in Slices & IOBs) not driven by LUTs =
144
IOB Latches not driven by LUTs = 0
IOB Latches = 0
IOB Flip Flops not driven by LUTs = 0
IOB Flip Flops = 0
Unbonded IOBs = 0
Bonded IOBs = 18
Shift Registers = 0
Static Shift Registers = 0
Dynamic Shift Registers = 32
16x1 ROMs = 0
16x1 RAMs = 0
32x1 RAMs = 0
Dual Port RAMs = 32
MULTANDs = 1
MUXF5s + MUXF6s = 457
4 input LUTs used as Route-Thrus = 63
4 input LUTs = 2670
Slice Latches not driven by LUTs = 0
Slice Latches = 0
Slice Flip Flops not driven by LUTs = 144
Slice Flip Flops = 441
Slices = 1528
Number of LUT signals with 4 loads = 50
Number of LUT signals with 3 loads = 87
Number of LUT signals with 2 loads = 307
Number of LUT signals with 1 load = 1983
NGM Average fanout of LUT = 2.19
NGM Maximum fanout of LUT = 77
NGM Average fanin for LUT = 3.5270
Number of LUT symbols = 2670
Number of IPAD symbols = 3
Number of IBUF symbols = 2

Chuck Gales · Dec 23, 2003

On Mon, 22 Dec 2003 22:46:26 +0000, Chuck Gales wrote:

On Mon, 22 Dec 2003 19:34:28 +0000, John Retta wrote:

Kind of a puzzle since you say that the .mrp report states there are
exactly the number of block rams that you expect, yet the warning claims
there are additional RAM cells implemented in distributed LUTs.

Is it clear that the LUT RAMs are the intended block RAMs, or that they
are an entirely new block of logic altogether?

Other poster has good point about using coregen.

I personally avoid coregen. Not much more effort to instantiate
blockrams directly (see lib.pdf), and you get exactly what you want.

Take another look at bottom of .mrp file. There is also a section which
describes the initialization values used for the block rams. It sounds
like you are intializing the block rams, so the values you expect to use
should show up down here.
OK...I re-ran with the detailed map report. As expected, the initial

values were all 0's:

Section 12 - Configuration String Details
-----------------------------------------
GCLK "CLK_BUFGP/BUFG": Configuration String is:
"DISABLE_ATTR:LOW"

BLOCKRAM "ram0_sram_hi": Configuration String is:
" CLKAMUX:1 ENAMUX:ENA RSTAMUX:RSTA_B WEAMUX:WEA PORTA_ATTR:1024X4
PORTB_ATTR:#OFF"
INIT_0f = 0000000000000000000000000000000000000000000000000000000000000000
INIT_0e = 0000000000000000000000000000000000000000000000000000000000000000
INIT_0d = 0000000000000000000000000000000000000000000000000000000000000000
INIT_0c = 0000000000000000000000000000000000000000000000000000000000000000
INIT_0b = 0000000000000000000000000000000000000000000000000000000000000000
INIT_0a = 0000000000000000000000000000000000000000000000000000000000000000
INIT_09 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_08 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_07 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_06 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_05 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_04 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_03 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_02 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_01 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_00 = 0000000000000000000000000000000000000000000000000000000000000000

BLOCKRAM "ram1_sram_low": Configuration String is:
" CLKAMUX:1 ENAMUX:ENA RSTAMUX:RSTA_B WEAMUX:WEA PORTA_ATTR:1024X4
PORTB_ATTR:#OFF"
INIT_0f = 0000000000000000000000000000000000000000000000000000000000000000
INIT_0e = 0000000000000000000000000000000000000000000000000000000000000000
INIT_0d = 0000000000000000000000000000000000000000000000000000000000000000
INIT_0c = 0000000000000000000000000000000000000000000000000000000000000000
INIT_0b = 0000000000000000000000000000000000000000000000000000000000000000
INIT_0a = 0000000000000000000000000000000000000000000000000000000000000000
INIT_09 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_08 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_07 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_06 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_05 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_04 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_03 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_02 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_01 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_00 = 0000000000000000000000000000000000000000000000000000000000000000

BLOCKRAM "ram1_sram_hi": Configuration String is:
" CLKAMUX:1 ENAMUX:ENA RSTAMUX:RSTA_B WEAMUX:WEA PORTA_ATTR:1024X4
PORTB_ATTR:#OFF"
INIT_0f = 0000000000000000000000000000000000000000000000000000000000000000
INIT_0e = 0000000000000000000000000000000000000000000000000000000000000000
INIT_0d = 0000000000000000000000000000000000000000000000000000000000000000
INIT_0c = 0000000000000000000000000000000000000000000000000000000000000000
INIT_0b = 0000000000000000000000000000000000000000000000000000000000000000
INIT_0a = 0000000000000000000000000000000000000000000000000000000000000000
INIT_09 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_08 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_07 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_06 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_05 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_04 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_03 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_02 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_01 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_00 = 0000000000000000000000000000000000000000000000000000000000000000

BLOCKRAM "ram0_sram_low": Configuration String is:
" CLKAMUX:1 ENAMUX:ENA RSTAMUX:RSTA_B WEAMUX:WEA PORTA_ATTR:1024X4
PORTB_ATTR:#OFF"
INIT_0f = 0000000000000000000000000000000000000000000000000000000000000000
INIT_0e = 0000000000000000000000000000000000000000000000000000000000000000
INIT_0d = 0000000000000000000000000000000000000000000000000000000000000000
INIT_0c = 0000000000000000000000000000000000000000000000000000000000000000
INIT_0b = 0000000000000000000000000000000000000000000000000000000000000000
INIT_0a = 0000000000000000000000000000000000000000000000000000000000000000
INIT_09 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_08 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_07 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_06 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_05 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_04 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_03 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_02 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_01 = 0000000000000000000000000000000000000000000000000000000000000000
INIT_00 = 0000000000000000000000000000000000000000000000000000000000000000

This seems to show that indeed there were SRAMs implemented as Block Rams,
with all 0's as initial.

Any other ideas???

Chuck

John Retta · Dec 23, 2003

Well ... it looks like the memory is there. You might want to bring
some signals to test points to verify control operation .....

I guess the original thread was that the memory appeared not to
be present. So add signals to track data flow/control signal
generation to determine problem.

Simulation is terrific. But is not the end-all. There might be
constraint problems/synchronization between time domains
problems, etc .. etc .... Judicious use of tracking testpoints
to track correct operation, until error tracked is best step.

Good luck.

--
Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.

email : jretta@rtc-inc.com
web : www.rtc-inc.com

"Chuck Gales" <cgales@_NOSPAM_nc.rr.com> wrote in message
news

an.2003.12.23.00.56.56.474091@_NOSPAM_nc.rr.com...

On Mon, 22 Dec 2003 22:46:26 +0000, Chuck Gales wrote:

On Mon, 22 Dec 2003 19:34:28 +0000, John Retta wrote:

Kind of a puzzle since you say that the .mrp report states there are
exactly the number of block rams that you expect, yet the warning
claims
there are additional RAM cells implemented in distributed LUTs.

Is it clear that the LUT RAMs are the intended block RAMs, or that they
are an entirely new block of logic altogether?

Other poster has good point about using coregen.

I personally avoid coregen. Not much more effort to instantiate
blockrams directly (see lib.pdf), and you get exactly what you want.

Take another look at bottom of .mrp file. There is also a section
which
describes the initialization values used for the block rams. It sounds
like you are intializing the block rams, so the values you expect to
use
should show up down here.
OK...I re-ran with the detailed map report. As expected, the initial
values were all 0's:

Section 12 - Configuration String Details
-----------------------------------------
GCLK "CLK_BUFGP/BUFG": Configuration String is:
"DISABLE_ATTR:LOW"

BLOCKRAM "ram0_sram_hi": Configuration String is:
" CLKAMUX:1 ENAMUX:ENA RSTAMUX:RSTA_B WEAMUX:WEA PORTA_ATTR:1024X4
PORTB_ATTR:#OFF"
INIT_0f =
0000000000000000000000000000000000000000000000000000000000000000
INIT_0e =
0000000000000000000000000000000000000000000000000000000000000000
INIT_0d =
0000000000000000000000000000000000000000000000000000000000000000
INIT_0c =
0000000000000000000000000000000000000000000000000000000000000000
INIT_0b =
0000000000000000000000000000000000000000000000000000000000000000
INIT_0a =
0000000000000000000000000000000000000000000000000000000000000000
INIT_09 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_08 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_07 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_06 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_05 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_04 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_03 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_02 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_01 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_00 =
0000000000000000000000000000000000000000000000000000000000000000

BLOCKRAM "ram1_sram_low": Configuration String is:
" CLKAMUX:1 ENAMUX:ENA RSTAMUX:RSTA_B WEAMUX:WEA PORTA_ATTR:1024X4
PORTB_ATTR:#OFF"
INIT_0f =
0000000000000000000000000000000000000000000000000000000000000000
INIT_0e =
0000000000000000000000000000000000000000000000000000000000000000
INIT_0d =
0000000000000000000000000000000000000000000000000000000000000000
INIT_0c =
0000000000000000000000000000000000000000000000000000000000000000
INIT_0b =
0000000000000000000000000000000000000000000000000000000000000000
INIT_0a =
0000000000000000000000000000000000000000000000000000000000000000
INIT_09 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_08 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_07 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_06 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_05 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_04 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_03 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_02 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_01 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_00 =
0000000000000000000000000000000000000000000000000000000000000000

BLOCKRAM "ram1_sram_hi": Configuration String is:
" CLKAMUX:1 ENAMUX:ENA RSTAMUX:RSTA_B WEAMUX:WEA PORTA_ATTR:1024X4
PORTB_ATTR:#OFF"
INIT_0f =
0000000000000000000000000000000000000000000000000000000000000000
INIT_0e =
0000000000000000000000000000000000000000000000000000000000000000
INIT_0d =
0000000000000000000000000000000000000000000000000000000000000000
INIT_0c =
0000000000000000000000000000000000000000000000000000000000000000
INIT_0b =
0000000000000000000000000000000000000000000000000000000000000000
INIT_0a =
0000000000000000000000000000000000000000000000000000000000000000
INIT_09 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_08 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_07 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_06 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_05 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_04 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_03 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_02 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_01 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_00 =
0000000000000000000000000000000000000000000000000000000000000000

BLOCKRAM "ram0_sram_low": Configuration String is:
" CLKAMUX:1 ENAMUX:ENA RSTAMUX:RSTA_B WEAMUX:WEA PORTA_ATTR:1024X4
PORTB_ATTR:#OFF"
INIT_0f =
0000000000000000000000000000000000000000000000000000000000000000
INIT_0e =
0000000000000000000000000000000000000000000000000000000000000000
INIT_0d =
0000000000000000000000000000000000000000000000000000000000000000
INIT_0c =
0000000000000000000000000000000000000000000000000000000000000000
INIT_0b =
0000000000000000000000000000000000000000000000000000000000000000
INIT_0a =
0000000000000000000000000000000000000000000000000000000000000000
INIT_09 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_08 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_07 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_06 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_05 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_04 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_03 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_02 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_01 =
0000000000000000000000000000000000000000000000000000000000000000
INIT_00 =
0000000000000000000000000000000000000000000000000000000000000000

This seems to show that indeed there were SRAMs implemented as Block Rams,
with all 0's as initial.

Any other ideas???

Chuck

Spartan II Block Ram

Chuck Gales

Guest

tbx135

Guest

John Retta

Guest

Chuck Gales

Guest

tbx135

Guest

tbx135

Guest

John Retta

Guest

Chuck Gales

Guest

Chuck Gales

Guest

tbx135

Guest

John Retta

Guest

Chuck Gales

Guest

John Retta

Guest

Welcome to EDABoard.com

Sponsor

Online statistics

Forum statistics

Spartan II Block Ram

Chuck Gales

Guest

tbx135

Guest

John Retta

Guest

Chuck Gales

Guest

tbx135

Guest

tbx135

Guest

John Retta

Guest

Chuck Gales

Guest

Chuck Gales

Guest

tbx135

Guest

John Retta

Guest

Chuck Gales

Guest

John Retta

Guest

Log in

Welcome to EDABoard.com

Sponsor