Method 1: Create ROMs in your FPGA design
Because you have the same data in every board, one option is to use block RAMs in the FPGA, configured as ROM. To do this you instantiate a block RAM, but don't connect to the write pins. Use a synthesis directive in your HDL code or UCF file to specify the initial contents of the RAM. Read the Spartan-3 Generation User's Guide (Chapter 4) to see how to instantiate the RAM and how to access the data from the RAM. If you use Xilinx ISE, there is probably also a "wizard" to generate the RAM block and set up the initial contents for you.
Unfortunately, the Spartan-3E you are using has only 350 kbits of block RAM, not 8 Mbits like you require. For this to work then, you'll have to work out a scheme to compress your data to fit in 350 kbits. The details of how to do this depend on what kind of data you have. If your data is especially random, it might not be reasonable to get this much compression.
Method 2: Store data in external memory
You say you have a 128 Mbit parallel flash and a 16 Mbit SPI flash. You will need to read the datasheets for these parts and understand how they work. Then write a state machine into your FPGA that can access these devices. But this is your job as the FPGA designer. Some random strangers on the internet are not going to design your FPGA for you.
To store the data onto the flash initially you have two choices. First would be, if you are building these boards in volume, you can have your board assembly shop pre-program the flash devices before assembling them onto the boards. Typically you give them a data file in some format they request, and they charge you some small extra fee to have the data flashed in before assembly.
Second option: Read the datasheet for the flash device. Write an FPGA design that allows you to send data from some other interface available on your board (Ethernet, USB, SPI, I2C, whatever), and load it into the flash. At manufacturing time, you load this design temporarily into your FPGA and program your flash; then you store a different "run-time" FPGA design into the on-board configuration PROM, that doesn't have the ability to modify the FLASH, and your users won't have the ability to mess up the data.
Best Answer
The code you showed has a few problems:
You don't show how
error_count
is declared in the top-level module. Iferror_count
is just declared aswire error_count;
, you only have a single bit of your counter connected between the counter module and the lcd module.You don't show how the counter is updated in the counter module. You could have a bug there that results in the counter never updating. Since it is initialized to 0, you'd always have a 0 output from the counter module.
You don't show any clock input to the counter module. If clock is not connected, error_counter will never be updated.
You say that lcd has a clock input, but you don't show that it actually does, and you don't show any code where it matters.
You don't show how your clock is generated. If there's no clock, the counter won't updated.
You don't show the complete input and output ports to either module. With your coding style it's easy to connect a wrong input to a wrong port. I much prefer to intantiate modules with the syntax like
counter counter1 ( .clk( clock ) , .error_count( error_count ) );
With this style, the order of naming the in's and out's in the instantiation doesn't matter.
You haven't shown any reset signal, but you probably have one. If the reset is stuck in the active state, probably the error_count won't ever increment.