Xilinx XCL woes

OK, so I have this core I wrote which wants to read and write data to an= d =

from SDRAM in a Spartan-E3 500 Microblaze system. There will be quite a lot of data moving around, and also I want the thi= ng =

to be self-serving, not need to call the CPU to make a request to =

opb_central_dma, so I connected it to the mch_opb_sdram controller using= =

one of the MCH/XCL channels, not on the OPB bus. There will be another =

core with the same interface, the SDRAM acting like a large FIFO between= =

the two (and also storing microblaze code and data).

Anyway, it looks good in ISE simulator (simulating only my core) and the= n =

in the FPGA it fails. The SDRAM controller locks up and doen't respond =

even to the CPU. That is a small problem, I must have done something wro= ng =

;)

I'm using EDK 9.1i

With ChipScope, this is the thing trying to emit a XCL Write transaction= :

formatting link

Note that here it emits to the FIFO every 2 clock cycles. Is this a =

problem ? Can the SDRAM controller stall ?

- It emits a 32-bit address on the MCH_data lines, which is actyally =

address 0

- Control is set to 1 to indicate a write transaction

- Write is set to 1 to push it in the FIFO

- Cacheline size is set to 4 (which I hope is 4 words ?) so the core emi= ts =

4 32-bit datums, setting Control to 0 and pulsing Write each time

- The core now wants to write another burst so it emits again the addres= s =

(this time 0x10), sets Control to 1 ans pulses Write

- FIFO is full so it waits forever.

Apparently the mcb sdram controller isn't reading from the other side of= =

the FIFO...

Now this is the thing trying to emit a XCL Read transaction :

formatting link

It emits 4 read commands (address + control=3D0 + pulse Write). Thet it waits for read data that never comes.

Soooooo..... there isn't much documentation on this subject it seems ;) If anybody has information, I would be very, very happy !!!!

Thanks ;)

LOL, I found the solution.

So, in order to enable the MCH/XCL on the mch_opb_sdram controller, one= =

must *activate* the Microblaze instruction/data cache and *connect* them= =

to the mch_opb_sdram. After doing that, mch_opb_sdram realized my core w= as =

connected to it too and started responding to its calls... I wonder why = =

this is the case but since I will most likely need the caches anyway, I = =

probably won't investigate this.

When googling I found questions on the list about the XCL (the Xilinx =

docs are pretty brief) here is how I did it :

- Everything is registered on the clock edge as usual

- It's two FIFOs, so - Read Fifo : - If ReadData_Exists =3D 1 you can read 1 datum and pulse Read to cons= ume =

it - Write FIFO : - To write a value, set Access_Data and Access_Control to required =

values and pulse Access_Write - if IsFull =3D 1 while you pulse Access_Write, you lose, the FIFO =

contents will be corrupted and you can reboot your board

Therefore not possible to put if(IsFull...) in a state machine, you mu= st =

wait a cycle after each write or use combinatorial logic...

The rest is as the docs say : - Write Address and Control =3D 1 - Wait - Receive N datums

- Write Address and Control =3D 0 - Write N datums

N being the Cache Line Size defined in your opb_mch_sdram parameters.

This core would be very cool to use in a CPU-less environment where you= =

just need to connect a few peripherals which will read and write to =

buffers in SDRAM.

Bandwidth is decent, too, I get about 70 MB/s from a 16-bit 50 MHz SDRA= M, =

with 4-word bursts. I would probably get a little more with longer bursts, and a lot more =

with DDR, or more bits of course ;)

An annoying thing is that the FIFO has a "I'm full" signal but not a =

"Only 1 free slot remaining" signal, which makes pipelining less =

straightforward.

Enjoy !