System Generator pcore I/O performance results

Sorry...typo

16-bit word (not "16-byte word") > Hello all:

could start timer do 4 writes to different locations then read the elapsed value divide value by 4 manually

it would be interesting to see if the value is still 28 clocks does MB have a cache? chipscope or simulation would highlight what's going on

Newman

also, disassemble the write function to see how efficiently it compiled the instruction I would think that it should be around 1 assembly op

Newman,

Thanks for writing back.

I tried: 1. starting the timer 2. writing 8 samples 3. reading timer 4. dividing timer result by 8 -->

This gave me an average write time of 20 cc's. So it did lower it some.

It's interesting...I'm finding that it takes 21 cc's to read/write data from/to external SRAM. I would think that the FSL link should be

*much* faster since it's accessing memory on-chip. In fact, the mb_ref_guide states a latency of 2 cc's for using non-blocking "put" and "get" operations for transferring data over FSL. Blocking accesses stall until there is space available on the FSL. What I am doing is a very simple design, and there shouldn't be any blocking, at least not from the program I am implementing. There must be some way to get better performance than what I'm seeing.

I'm not implementing cache with this design.

I looked at main.s and couldn't really make much sense of the assembly code. I did searches for put, get, fsl and found nothing. I would be interested to know how the compiler is translating to machine code as well...is there some option for seeing c-code interspersed with related assembly? I set compiler options to no optimization and create symbols for assembly.

Joel

Just a couple more data points to add regarding performance of FSL...

I created a 2-processor microblaze design connected by FSL links.

With a simple program and using these functions:

microblaze_bwrite_datafsl(data[index],0); microblaze_bread_datafsl(result, 0);

from mb_interface.h to pass data from one processor to the other and back, and using the counter to measure performance, I found:

1. takes 9 cc's to write a data sample to FSL (doesn't matter if it's

1 or 99 samples and dividing count result by 99)

1. takes 10 cc's to read a data sample from FSL

I tried the "non-blocking" functions as well and found the same results.

Hi,

The actual fsl PUT or GET instruction takes 2 clock cycles in MicroBlaze v4 and 1 clock cycle in MicroBlaze v5. Where is your code and data located? The macro you are using are also reading/writing the data that you want to use for the FSL link.

Just disassemble the .elf file and look how the macro is implemented.

Göran

A while back, I stepped through code on the target using the gnu debug tool. There is an option to compile the code and libraries for single step debug that shows the mixed assembly with the C code and one can single step at either level.

As mentioned, one can disassemble the elf, but the jtag gnu debugger is more intuitive if you can suffer the pain to get it working.

Newman