ISE 11.1 - readmemh issues
in [FPGA]
|
Prev: Cheap FPGAs for tutorial
Next: PCI Interrupt
From: Philip Pemberton on 3 May 2010 14:33 Hi guys, I'm porting my LatticeMico32 SoC across to a different FPGA board which uses a Xilinx Spartan3A (XC3S700A; the board is an Enterpoint Drigmorn2). I've got most of it moved across, but the Boot ROM is being difficult. This was implemented using the Altera ROM generator and a MIF file, but obviously isn't an option on the Xilinx platform. The ROM is 32 bits wide, and stores 2048 words. What I've done is this: // Boot ROM logic reg [31:0] BOOTROM_MEM [0:2047]; reg [31:0] BOOTROM_Q; assign BOOTROM_DATA_OUT = BOOTROM_Q; // Only update DQ register on clock edge always @(posedge MCLK) begin BOOTROM_Q <= BOOTROM_MEM[BOOTROM_ADDR[12:2]]; end // Init memory array from firmware image initial $readmemh("firmware/boot0.vmem", BOOTROM_MEM, 0, 2047); // WISHBONE ACK generation logic goes here I'm using SRec to generate the VMEM file: srec_cat -Output boot0.vmem -VMem 32 boot0.bin -binary -generate 0 8192 -difference -over boot0.bin -binary -b-e-const 0x34000000 4 The first few lines of the VMEM file are: /* http://srecord.sourceforge.net/ */ @00000000 98000000 D0000000 78010000 38210000 D0E10000 F800003B 34000000 @00000007 34000000 91203800 34E70020 C0E00000 34000000 34000000 34000000 @0000000E 34000000 34000000 91203800 34E70040 C0E00000 34000000 34000000 If I try and build this code in ISE11.1, I get this error: ERROR:Xst:2354 - "lm32_soc_top.v" line 430: Value 78313372 found at line 1 is not hexadecimal in call of system task $readmemh. If I remove the starting comment from the VMEM file, I get this instead: ERROR:Xst:2352 - "lm32_soc_top.v" line 430: Address -1 found at line 1 is invalid in call of system task $readmemh. I can't see anything obviously wrong with the code, nor can I find anything on Xilinx's website or the XST manuals that explains these errors... What am I doing wrong here? Thanks, -- Phil. usenet09(a)philpem.me.uk http://www.philpem.me.uk/
From: Gabor on 3 May 2010 17:08 On May 3, 2:33 pm, Philip Pemberton <usene...(a)philpem.me.uk> wrote: > Hi guys, > > I'm porting my LatticeMico32 SoC across to a different FPGA board which > uses a Xilinx Spartan3A (XC3S700A; the board is an Enterpoint Drigmorn2). > I've got most of it moved across, but the Boot ROM is being difficult. > This was implemented using the Altera ROM generator and a MIF file, but > obviously isn't an option on the Xilinx platform. > > The ROM is 32 bits wide, and stores 2048 words. > > What I've done is this: > // Boot ROM logic > reg [31:0] BOOTROM_MEM [0:2047]; > reg [31:0] BOOTROM_Q; > assign BOOTROM_DATA_OUT = BOOTROM_Q; > > // Only update DQ register on clock edge > always @(posedge MCLK) begin > BOOTROM_Q <= BOOTROM_MEM[BOOTROM_ADDR[12:2]]; > end > > // Init memory array from firmware image > initial $readmemh("firmware/boot0.vmem", BOOTROM_MEM, 0, 2047); > // WISHBONE ACK generation logic goes here > > I'm using SRec to generate the VMEM file: > srec_cat -Output boot0.vmem -VMem 32 boot0.bin -binary -generate 0 8192 > -difference -over boot0.bin -binary -b-e-const 0x34000000 4 > > The first few lines of the VMEM file are: > /*http://srecord.sourceforge.net/*/ > @00000000 98000000 D0000000 78010000 38210000 D0E10000 F800003B 34000000 > @00000007 34000000 91203800 34E70020 C0E00000 34000000 34000000 34000000 > @0000000E 34000000 34000000 91203800 34E70040 C0E00000 34000000 34000000 > > If I try and build this code in ISE11.1, I get this error: > ERROR:Xst:2354 - "lm32_soc_top.v" line 430: Value 78313372 found at line > 1 is not hexadecimal in call of system task $readmemh. > > If I remove the starting comment from the VMEM file, I get this instead: > ERROR:Xst:2352 - "lm32_soc_top.v" line 430: Address -1 found at line 1 is > invalid in call of system task $readmemh. > > I can't see anything obviously wrong with the code, nor can I find > anything on Xilinx's website or the XST manuals that explains these > errors... What am I doing wrong here? > > Thanks, > -- > Phil. > usene...(a)philpem.me.ukhttp://www.philpem.me.uk/ Xilinx's support of $readmemh is pretty brain-dead. Here's the rules that have worked for me: 1) No addresses in the hex file. Sorry - not supported. 2) Exactly one value per line of text. 3) No comments. 4) Size of the initialization data must exactly match the size of the memory array it initializes. Partial initialization of an array results in no initialization (entire array reverts to its default of all zeroes). Xilinx does have other means of initializing instantiated memory using "init" properties, and .coe file for initializing CoreGen memories. However if you can live with the rules for initializing inferred memories it should be more portable. HTH, Gabor
From: Philip Pemberton on 3 May 2010 18:59 On Mon, 03 May 2010 14:08:30 -0700, Gabor wrote: > 1) No addresses in the hex file. Sorry - not supported. 2) Exactly one > value per line of text. 3) No comments. > 4) Size of the initialization data must exactly match the size of the > memory array it initializes. Partial initialization of an array results > in no initialization (entire array reverts to its default of all > zeroes). OK, it seems it's even more braindead than that... WARNING:Xst:1781 - Signal <BOOTROM_MEM> is used but never assigned. Tied to default value. This is despite the 'initial' block telling it what to load and from where... Does Xst log of the initial contents of inferred ROMs anywhere? That is, can I actually see what's in the ROM without either running the HDL under a simulator or using a logic analyser / data generator to test it? And for extra bonus points: INFO:Xst:738 - HDL ADVISOR - 1024 flip-flops were inferred for signal <cacheline_data>. You may be trying to describe a RAM in a way that is incompatible with block and distributed RAM resources available on Xilinx devices, or with a specific template that is not supported. Please review the Xilinx resources documentation and the XST user manual for coding guidelines. Taking advantage of RAM resources will lead to improved device usage and reduced synthesis time. Ho hum. Quartus inferred an M4K blockram for that. I did wonder why the gatecount was off in the stratosphere somewhere. Why do I suddenly get the feeling I've been catapulted back to the dark ages? -- Phil. usenet09(a)philpem.me.uk http://www.philpem.me.uk/ If mail bounces, replace "09" with the last two digits of the current year.
From: Gabor on 3 May 2010 21:56 On May 3, 6:59 pm, Philip Pemberton <usene...(a)philpem.me.uk> wrote: > On Mon, 03 May 2010 14:08:30 -0700, Gabor wrote: > > 1) No addresses in the hex file. Sorry - not supported. 2) Exactly one > > value per line of text. 3) No comments. > > 4) Size of the initialization data must exactly match the size of the > > memory array it initializes. Partial initialization of an array results > > in no initialization (entire array reverts to its default of all > > zeroes). > > OK, it seems it's even more braindead than that... > > WARNING:Xst:1781 - Signal <BOOTROM_MEM> is used but never assigned. Tied > to default value. > > This is despite the 'initial' block telling it what to load and from > where... Does Xst log of the initial contents of inferred ROMs anywhere? > That is, can I actually see what's in the ROM without either running the > HDL under a simulator or using a logic analyser / data generator to test > it? > > And for extra bonus points: > > INFO:Xst:738 - HDL ADVISOR - 1024 flip-flops were inferred for signal > <cacheline_data>. You may be trying to describe a RAM in a way that is > incompatible with block and distributed RAM resources available on Xilinx > devices, or with a specific template that is not supported. Please review > the Xilinx resources documentation and the XST user manual for coding > guidelines. Taking advantage of RAM resources will lead to improved > device usage and reduced synthesis time. > > Ho hum. Quartus inferred an M4K blockram for that. I did wonder why the > gatecount was off in the stratosphere somewhere. Why do I suddenly get > the feeling I've been catapulted back to the dark ages? > > -- > Phil. > usene...(a)philpem.me.ukhttp://www.philpem.me.uk/ > If mail bounces, replace "09" with the last two digits of the current > year. XST is pretty finicky about inferring memory. You should look at the recommended templates in the XST Manual. Also from the original topic I didn't realize you were defining a ROM rather than just initial values for a RAM. XST also has problems with block RAM used as ROM. I haven't tried this myself, but I've seen a number of threads here where the solution is to give your "ROM" a write port. I have had good luck with initializing RAM using the initial block and $readmemh once I found its limitations, though. Good Luck, Gabor
|
Pages: 1 Prev: Cheap FPGAs for tutorial Next: PCI Interrupt |