Using EEPROM for application data

jamorton

My team is developing an application for the Logi-bone that requires having a large lookup table containing a matrix of 16 bit FP numbers. Is it possible to use the flash memory on the Logi-bone for this purpose? I think the essence of my question is how to prevent the SPI flash memory from being treating as configuration ROM which is the default behavior. 

Second discussion point is how best to approach programming the memory with the look up table. 

Thanks.

-James

mjones

Hi @jamorton  Yes you can use the spi flash to store the data.  Are you using the spi flash for configuration?  You can always use the full flash memory for data and then program the FPGA from the beaglebone.  

If you want to configure from flash you can still use the spi flash outside of the configuration area to store you own custom data.  The current flash chips are 32Mbit and the configuration data is ~3Mbit.

I believe that the configuration is stored from spi address 0 up to the length of the condiguration file, though you will need to double check the addressing locations from UG380 Ch. 5.  

http://www.xilinx.com/support/documentation/user_guides/ug380.pdf

Depending on the size of needed storage you can always increase the flash size to support the needed storage data.  You can directly write the data to the flash chip from the FPGA in your user application.

Hope this helps.

jamorton

Thanks for the information @mjones

We are configuring the FPGA from the BBB, so we essentially have all of the flash for application lookup tables. 

Another issue we are trying to understand is if there is any way to run the SPI flash and SPI interface to the BBB simultaneously? In our application we are

• Running the BBB from the onboard flash, so configuring and exchanging data with the logi-bone using SPI.
• Needing to use the spi flash to hold word-sized values that form a lookup table. 
• Flash lookups and data transfer to the BBB need to occur simultaneously. 

Thanks for your input

mjones

Hi @jamorton

The current LOGI Bone design is optimized for communication using the GPMC bus, but you can use SPI with some caveats.  

The BBB SPI used the config the FPGA.  The FPGA config pins are shared with the SPI Flash so that it can self config from SPI if needed.  Because of this the BBB SPI pins are not wired correctly to directly read/write to/from SPI using the BBB.  So you would need to write/read the SPI flash from the FPGA.

In your case you would need to use the FPGA as a buffer to hold the data that you want to read and write from the Flash.  You can setup a queue in the FPGA that can be used to access Flash data.  The process would look like this:

1) BBB uses SPI to write data to the FPGA to be stored in flash

2) BBB releases SPI lines so that the FPGA can then write data to the flash and signals FPGA to begin write with a gpio or time sequence

Reverse process for reads from flash.

Another options would be to solder a jumper for the BBB SPI SCK,MOSI to alt FPGA pins.  Then you could sumulaneously use BBB SPI->FPGA and FPGA->flash.  You could directly pass the BBB SPI fpga pins to the FPGA flash output pins to allow for direct reads/writes to flash from the BBB.  This seems like it would be optimal for your application.

Sorry this is not optimal and based on many users wanting to use the BBB emmc to run from(blocks use of GPMC) we will likely make a change to allow for easier use of SPI and Flash in the future.  

jamorton

Hi @mjones,

Thanks for your help. We are working on a test/ demo app right now that is trying to follow your outlined approach above. We are having some real trouble getting the flash to do anything. We have the flash programming/ readback and such modeled in a testbench using a vendor-provided model and see that the logic works against the model. 

On the hardware it does not. I am wondering if the clock buffer that is controlled by the GPIO expander is causing a bus contention issue when the FPGA is trying to drive the flash clock pin? I think we need to reprogram the expander to turn off the BUFF OE# pin so that the buffer goes HiZ when the FPGA is the clock SOURCE. If so, can you provide instruction on how to reprogram the GPIO expander configuration?

Thanks for all your time and help so far!

mjones

Hi @jamorton

Sorry you are having problems.   Yes clearing the BUF_OE# pin would be the easiest way to ensure that the MOSI/SCK pins of the BBB are not conflicting with the communication.

Also the FLSH_RST# pin from the GPIO expander could be holding the flash in reset dependent on the expander pin state.  

For a sanity test you can try and use xilinx ise impact to load a bistream into flash.  This process loads a flash loading architecture into the FPGA which then writes the bitstream contents to flash from the FPGA and reads back to verify (this is what you are trying to do).  Impact will tell you the status and indicate what kind of failures may be occurring.

Also There are some handy utilities in the logi_loader source which will allow you to easily change the IO state of the GPIO expander pins.  Specifically see the "i2c_set_pin" and "i2c_get_pin" functions in "i2c_loader.c" source.  

https://github.com/fpga-logi/logi-tools/tree/master/unified_loader

If needed I can test something on my side.  Also, @jpiat  may have some input too.

jamorton

@mjones,

Thanks for the information. We are working on verifying the pin states and using the code to reconfigure the expander now.

Also, we give +infinity up votes for changing the flash/ spi bus architecture on the next rev. Since SD cards are so slow, I think you will find a lot of your users (like us) are required to use the EMMC for the BBB kernel to get the performance we need. In our particular acoustic sensing app, we have a data rich environment that needs to be able to process observations in real time.