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
Spartan II Block Ram
Started by ●December 21, 2003
Reply by ●December 21, 20032003-12-21
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:pan.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
Reply by ●December 22, 20032003-12-22
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:pan.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
Reply by ●December 22, 20032003-12-22
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
Reply by ●December 22, 20032003-12-22
> 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? > > ChuckThe 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?
Reply by ●December 22, 20032003-12-22
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...
Reply by ●December 22, 20032003-12-22
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:pan.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 outputssignals> > from one logic function to another might be misnamed, and hence thesource> > block might be optimized away. Problem is that the offending problemmay> > 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
Reply by ●December 22, 20032003-12-22
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.
Reply by ●December 22, 20032003-12-22
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:Pack: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:Pack: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:Pack: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
Reply by ●December 22, 20032003-12-22
Did you find a .coe file? "Chuck Gales" <cgales@_NOSPAM_nc.rr.com> wrote in message news:pan.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.
