Mr B,
If you're still looking at this, a possible solution is to use an MCB core and just hook up two AXI streams to it. You would have to write a little chunk of VHDL in the MCB wrapper to generate a Read / Write interface from the 2 AXI streams, but at least you're in control of what's happening and you don't have to hunt around the web for examples which in the end will probably take up the remainder of your life and drive you nuts to boot.
I suggest (it's what I'd do: but doesn't mean it's right!):
1. using 2 AXI streaming interfaces in the microblaze, with the legacy instuctions box ticked so you can use assembler macros from FSL link. One write. One read. I do this because I don't think there's any documentation, and at least this is easy.
2. Create some really noddy user logic to just feed the AXI instructions onto a 32 bit bus with an enable. You can add a 32 bit bus for control comms with enable too, which is useful.
3. Having selected the LEGACY instruction box (in 1 above), EDK will (with any luck) add fsl.h to your Board Support Package when you open up your thing in SDK. HAve a look in there and play around with the putflsx(...) type instructions, which can be dropped into your c code directly. These will generate pretty predictable results without having to invoke any deeper magic using AXI. I have looked and still don't know where the necessary header files etc are to do this any other way!
4. Create an MCB logicore and stick on as many ports as you need. You could use a read port and a write port for your application, or one read/write (may be stating the obvious there). Add any additoinal ports you need for external processors etc...
4b) It's worth pointing out that you'll have to spend a half a day getting the clock buffering to work on the MCB, as it will probably add in it's own buffers, which is not allowed. I.e. you supply a buffered clock from an internal DCM block. The MCB logicore then creates a clock input with it's own buffers (presumably thinkin gthat you are using an external clock (? why would you?). So you'll have to do a little hacking. BEWARE. If at any point you regernate the MCB, for example to add on another port. This hack will have to be redone.
5. Then create an MCB_Wrapper to feed the write streaming data into the write port, and the read streaming data into the read port. The guts of what you do here is generating the signals to run the control inputs to the MCB. Given that you have created spearate write and read streams, it may be easier to write this logic if you create separate write and read ports on teh MCB (Which is why I mentioned it above).
6. Run it up and see what your throughput limitations are. If you write some good MCB wrapper logic, you can pipelline the write stream into bursts. HIGHLY recommended, as it stops the control fifo filling up. If you are belssed and can get ISim to work, keep an eye on the FIFOs in the MCB block etc. You may have to add some handshaking in if your application is running the MCB too hard.
7. A note on simulating DDR : When you generate your MCB, obviously selcting DDR2 or DDR3 or whatever you are using, Xilinx has provided some simulation models for some of the technologies. I know at least that the LP DDR MCB doesn't work straight out of the box. You will have to do some playing aorund with the tristate logic to get it to work. When it does, it's really useful. But don't expect it for free. You fingers will be bleeding by the time you get it to work.
Good luck. Having written this, I'm debating the logic of having done so, seeing how much there is to it. Anyhoo. It's nice to have options.
Al.
