Hello,

I've been working for over a year and a half on a software/HDL design environment that generates FPGA cores with scripts and configuration files, So far with a lot of success! I've also devised a method that allows a host computer to interrogate a connected FPGA to determine which cores are implemented along with scripts to interact with those cores.

Sorry for the commercial but I'm just about to go for a kickstarter and I can use all the help I can get ;)

Anyways, I've designed a board that I've been using to exercise my software environment. The board I've designed only has 8MB of SDRAM and I want to play audio through an I2S core I've been working on. In order to facilitate the flow of audio data I'm sending data into a double buffer in the SDRAM in 4MB chunks through a wishbone arbiter. The host then indicates the size of the write to the I2S core. The I2S core, attached to the other side of the arbiter, Fills it's local FIFOs with that data to keep a continuous flow of audio to the I2S serial writer.

I know my SDRAM works, I know my I2S core can receive data from the Memory, both in simulation and on the real FPGA but every once in awhile the system will crash when I attempt to write a lot of data to the SDRAM. I know it's not the interface to the host computer, wishbone master, memory interconnect, peripheral interconnect or the SDRAM core. I've tested those cores out countless times, so it has to be the arbiter.

I've tried quite a few different approaches to building the arbiters including the following:

1. synchronous: all signals are changed on the wishbone bus clock (works in simulation)
2. asynchronous with sensitivity list: All signals are triggered using sensitivity signals that should trigger under all possible situations (and do in simulation)
3. asynchronous with the catch all 'always @ (*)': all signals are triggered whenever there is a change (works in simulation)
4. hybrid synchronous/asynchronous: master select is chosen with a synchronous clock while the rest of the signals are chosen with the catch all 'always @ (*)' (works in simulation)

I've also tried a lot of variations of the above, so far the hybrid synchronous/asynchronous has yielded the most dependable results. The way I select a master is by "first come first serve", priority given to the lowest master (master 0, 1, 2.. etc)

Here's a link to a generated arbiter I've been recently using in the simulation for the I2S core (ignore the 'priority_select' it is a work in progress):

http://raw.github.com/CospanDesign/olympus/cospan/cbuilder/sim/wishbone/arbitrator/example_2port_arbitrator/arbitrator_2_masters.v

but after generating the FPGA image 30 some odd times while debugging the I2S core it finally stopped working. It is strange because I can always perform short reads (2 X 32-bit reads and writes) but when I attempt to fill or read the entire memory the system stops responding.

Does anyone have any insight as to why I get the sporadic failures? I'm assuming that it has to do with some timing constraint that I am not specifying in the core. Perhaps there is an attribute that I can set in order to indicate to the build tools that placement of the primitives is important but I haven't had much experience in working with attributes and so far the hdl/software is vendor independent so I'd like to avoid any vendor specific commands. I don't mind doing the legwork of researching attributes but I was hoping I could get someone to point me in the right direction.

Thanks in advance for any help anyone can offer.

Sincerely,
Dave