05-01-2009 10:03 AM - edited 05-02-2009 12:56 AM
My technology target is a Virtex4FX60 and I am using EDK10.1 sp3.
I have attached an FSL to a PowerPc in EDK using the Base system builder at first to create a basic project, then I created a default FSL peripheral using the Create Peripheral Wizard and finally I added the FSL to the design with the Configure Coprocessor tool.
So my FSL is correctly attached to the PowerPC and everything compiles fine.
So I really only have default IPCORES and setups from the tools.
The write operations from the PowerPC to the FSL FIFO are working (I checked with Chipscope).
The write operations from the peripheral to the FSL FIFO are also working.
I am meeting 2 problems right now.
The first problem I am meeting is that the write operations don't occur in burst, even if the FSL fifo is always ready to receive, I could see with chipscope that the PPC only seems to write every 32 clock cycles. And I need to burst data. All the documentation I could find talks about the Microblaze and clearly says that data can be burst on the FSL.
The second problem is relative to the read operations from the PowerPC. If I step through my READ loop,(from the debugger), then I can empty the fifo and the program terminates happily.
If I just run the program (from the debugger), it hangs after doing the first READ. (I also checked with chipscope, I can see the first Read pulse, the FSL_S_Exists is still high, but no other read occur).
The FIFO is then FULL minus 1 data.
If I stop the program because it hanged, the program Counter comes back on the read operation that I can run again, which then reads the next data from the FIFO, but then hangs again etc...
So the READs do not seem to work UNLESS I step them.
The major difference with the Microblaze seems to be that the FSL is actually working with the PowerPC APU, so is there something there that needs to be enabled?
EDK generated an software example code including a piece of assembly code to enable the APU, so I used it.
I have left everything default in EDK and here is my software code.
// Filename: C:\My_Designs\EDK_examples\Example8\drivers/fsl_v1
// Version: 1.00.a
// Date: Fri May 01 15:15:47 2009 (by Create and Import Peripheral Wizard)
* In order to run this self test, you need to modify the value of following
* micros according to the slot ID defined in xparameters.h file.
#define input_slot_id XPAR_FSL_FSL_0_INPUT_SLOT_ID
#define output_slot_id XPAR_FSL_FSL_0_OUTPUT_SLOT_ID
#define write_into_fsl(val, id) putfsl(val, id)
#define read_from_fsl(val, id) getfsl(val, id)
unsigned int input_0;
unsigned int output_0;
unsigned int i;
// Enable APU for PowerPC.
unsigned int msr_i;
msr_i = mfmsr();
msr_i = (msr_i | XREG_MSR_APU_AVAILABLE | XREG_MSR_APU_ENABLE) & ~XREG_MSR_USER_MODE;
//Initialize your input data over here:
input_0 = 12345;
input_0 = 24690;
input_0 = 37035;
input_0 = 49380;
input_0 = 61725;
input_0 = 74070;
input_0 = 86415;
input_0 = 98760;
input_0 = 111105;
input_0 = 123450;
input_0 = 135795;
input_0 = 148140;
input_0 = 160485;
input_0 = 172830;
input_0 = 185175;
input_0 = 197520;
for (i=0; i<16; i++)
for (i=0; i<16; i++)
if (output_0 != 1678920)
if (output_0 != 1678920)
Any help appreciated, I have read XAPP529, the PowerPC BSP User guide and other threads from the forum relative to the FSL, but none seem to give me any clue on what is going on here.
Solved! Go to Solution.
05-06-2009 03:20 AM
I have gone through more testing and tries and I found out that using a "usleep(1)" before the read operation makes the system work.
Then, this morning Xilinx tech support just answered me and gave me a similar work-around by using asm("nop") before the read instruction.
Magic delays strike again.
The tech support cannot guarantee the workaround will work in all situations because the FSL link isn't an interface developped for the PowerPC...
Of course, optimization level 02 is the maximum level of optimization usable, otherwise the "nop" instruction seems to be optimized out.
I also wonder what happens if I run the system at 300MHz instead of the 100MHz that I am using at the moment.
Does anyone know why a "nop" seems to do the trick.
Understanding the effect of this "nop" instruction would certainly help to identify the cases when it will work and when it won't.
Any help appreciated.
05-06-2009 03:25 AM
This issue has something to do with the PPC405 errata, at http://www.xilinx.com/support/answers/20658.htm.
It's very likely that it hits the issue mentioned in Solution 11 or 14 (or a combination of both).
05-12-2009 06:56 AM
Thank you for pointing out the errata.
It is very scary!
Yes, it looks like the blocking read operations are suffering from the bugs mentioned in Solutiion 11 to 14.
I have made different designs, and I have to vary the amount of "nops" in my applications, from 1 to 3 to get it to work.
So it's a trial and error sort of developping.
I also got an answer from Xilinx Tech support confirming that burst operations on the FSL are not supported with the PowerPC as the APU and FCB do not support Burst data.
thanks for your help,