Hi everybody,

at the moment, I'm facing the decision wether to connect to a MicroBlaze through OPB or FSL. The scenario is as following: I have a huge parallel computing device with a 64 bit backplane (only moderate data throughput is required). This backplane has to be interfaced to a MircoBlaze being the central controller of the device. Implementing an FSL interface seems a lot easier to me but I can't find any comparisons of data rates, latency and so forth. Does anybody have any suggestions on the topic? Is it possible to trigger interrupts on arriving data with the FSL?

Best regards /Chris

-- Christian Schleiffer Communication Security (COSY) Dept. of Electr. Eng. & Information Science Ruhr-University Bochum http:// snipped-for-privacy@crypto.rub.de

Reply to
Christian Schleiffer
Loading thread data ...

The FSL is just a simple set of FIFOs . You would need some kind of state machine to read data out (and write to) these fifos. Yes, you could also have some logic generate an IRQ when the FIFO is Full, Etc.

As far as data rate, The read and write FIFO is synschrounous to your microblaze clock. I think it is a single cycle instruction to to a non-blocking write to a FSL. Could take 2 or more but I can't remember. The rest of the speed is dependent our your state machine to grab data about of the FIFO and move it elsewhere. It would have been really nice for xilinx to put in an instruction (OR EVEN A FLAG) to tell me if there is data in the read fifo.

OPB is slow 10-15 clks per transaction. It is useful though, and simple if you use the IPIF template. If you wish to do OPB master transactions from a peripheral on the bus, I would recommend just reading the OPB spec and making your own piece of IP.


Christian Schleiffer wrote:

Reply to
Eli Hughes


thanks for the answer.

The hardware interface is no problem at all and my bus connection will have a system synchronous part as well. Maybe I even don't have to worry about IRQs: the controller will be running uCLinux and I just read about an official FSL driver doing the polling job. I have to get deeper into that uCLinux stuff first, I think.

Yes, non-blocking write and read operations take 2 instruction cycles.

That's a little slow since I have additional latency in the attached bus interface and on the software side. Too bad, the memory mapped IO approach would have been quite nice...

Bye /Chris

-- Christian Schleiffer Communication Security (COSY) Dept. of Electr. Eng. & Information Science Ruhr-University Bochum, Germany http:// snipped-for-privacy@crypto.rub.de

Reply to
Christian Schleiffer

/ /\/\ Aurelian Lazarut
 Click to see the full signature
Reply to
Aurelian Lazarut

Hi Christian,

FSL is awesome, but remember that the CPU must handle every piece of data in the channel. Putting the CPU in the datapath is something high-speed designers usually try to avoid. There's no such thing as DMA to an FSL connection (though sometimes I wish there was).

You can use the DMA functionality on Xilinx's OPB IPIF, but it tends to produce massive cores. Look for example at the size difference between the ethernet MAC with and without SGDMA.

Also, there's the standalone opb_dma controller, but it's not as efficient as an IPIF-integrated controller. Choices and tradeoffs, as always.

More below:

Christian Schleiffer wrote:

I'm familiar with the uClinux driver you mention, since I wrote it. And, once again the biggest problem there is throughput because all data over the channels must be handled by the CPU.

It is possible to trigger interrupts on FSL status, but you have to do some crafty stuff in the MHS file. Basically co-opt the FSL's has_data or is_full signals and bring them into the interrupt controller.

Multithreaded operating systems or apps *must not* use blocking FSL operations, since they'll lock you up hard if you do a blocking read/write on an empty/full channel.

Instead, you have to simulate it by doing a nonblocking read, testing the status, and repeating if required. This slows things down a lot.

If you know exactly how many items should be in the channel, you might get away with a blocking op.



Reply to
John Williams

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.