17 replies to this topic

[mypowlar]

HI,ALL. THE SHAREDMEM DEMO DON'T WORK ON ML403, i DON'T KNOW WHY?

The demos don't work on OPB bus for POERPC or Microblaze.

Can anyone give me a right demo for OPB or PLB on ML403?

Thanks!!!

[mypowlar]

is there anybody give me a good suggestion?

i am very eager to know answer!!

[Brett]

is there anybody give me a good suggestion?

i am very eager to know answer!!

Have your tried the memoryio example and the variants that have been posted on this forum?

[mypowlar]

yes, it also don't work.

[Brett]

yes, it also don't work.

I'm no expert (some of the dumbest posts on this forum are mine) but I've gotten a few things working. First, however:

!. what's your setup? Tools (ise/edk 7.1, 8.1, etc...)

2. What demos have you tried (I finally got memoryio working for me, but a newer release of codeveloper broke it)

3. what are the symptoms you're seeing? (e.g. hangs on first fsl write..., co_signal never received, etc...)

Brett Boren
Computer Engineering Graduate Student
University of Alabama, Huntsville

[mypowlar]

first thank you for your reply.
1. i use the hard core powerpc405 not miroblaze.
2. the symptoms is hanging on first read of the software co_signal_read never receive the hardware reponse.
3. can you send me your hole codeveloper project and edk project to me? my mail is: chengdabo@hotmail.com

[Brett]

first thank you for your reply.
1. i use the hard core powerpc405 not miroblaze.
2. the symptoms is hanging on first read of the software co_signal_read never receive the hardware reponse.
3. can you send me your hole codeveloper project and edk project to me? my mail is: chengdabo@hotmail.com

You're welcome. Some notes:

1. I use the ml401 for all of my work. Same as yours except no FX chip so I don't get to play with a PPC
2. prior to 2.20f I could get the memoryio example working(albeit inconsistenly). In 2.20f something was "fixed" which now makes it not work at all. I have a modified version that you will find attached in another thread that adds a co_stream to the mix connecting the producer to the hardware element. You can d/l this and give it a try but it means using the microblaze and not using the PPC hardcore. Try it as a sanity check.
3. I had similar problems where it seems as though te hardware element never gets initiated after the producer runs. Connecting via xdm * gdb you can dump the memory contents of the shmem block and see whether or not your hardware element ever ran correctly.

[mypowlar]

Can you test it on PPC not microblaze?

[mypowlar]

RalphBodenner: can you help me?

[etrexel]

RalphBodenner: can you help me?

Hi, Ralph has asked me to try and see if I can help.

First thing I can think of when using shared memory over the OPB in a PowerPC system, assuming that the memory you're trying to get to is on the PLB where it is usually by default, is whether there is an opb2plb bridge present. If not, you will need to add one which includes:
1) connecting the opb2plb breidge to the OPB and PLB busses (SDCR not required)
2) connect the "BGI_Trans_Abort" port of the opb2plb and plb2opb together
3) Configuring the opb2plb memory map which at minimum includes:
a) OPB Register Base/High Address, this is where the CPU finds the bridge's registers
Range 0 Base/High Address, this is the address range the bridge will map FROM the OPB bus and forward do memory requests on the PLB bus

Hope this helps,
Ed

[mypowlar]

thank you for your reply.

1.first, i don't know whether the "Xilinx Generic OPB" in Impulse can work for my job?
because i can't find "Xilinx PowerPC OPB" in Impuse,it only has "Xilinx MicroBlaze OPB".
(see my first picture1)

2.after impulse generate the pcore, i add it into edk, just see my second picture2.
is it right?

3.the third, i don't know what's the difference between "c_baseaddr:c_highaddr"
and "c_mir_baseaddr:c_mir_highaddr"? Can you tell me if i have assigned the address
right just like the pictrue3?

4.After such work above, can i do the sharedbram demo work? here, i assigned the SDRAM on OPB
bus.

Attached File(s)

•  1.JPG (126.91K)
  Number of downloads: 21
•  2.JPG (142.68K)
  Number of downloads: 17
•  3.JPG (141.44K)
  Number of downloads: 15

[etrexel]

thank you for your reply.

1.first, i don't know whether the "Xilinx Generic OPB" in Impulse can work for my job?
because i can't find "Xilinx PowerPC OPB" in Impuse,it only has "Xilinx MicroBlaze OPB".
(see my first picture1)
....
4.After such work above, can i do the sharedbram demo work? here, i assigned the SDRAM on OPB
bus.

Hi,
The SharedBRAM example is actually fairly obsolete, it was done before global arrays existed. You could make it work using the "Xilinx Generic OPB", and from your images it looks like the connections are correct, but it would require a few more steps and code that is otherwise automatically generated being the "generic" interface. For instance, the MIR (Module Identification Register) is used to identify the module (user supplied code) versus non-generic code would automatically use the base address. Also, the lack of a "PowerPC OPB" is partly due to the PLB being the primary interface to the PowerPC which doesn't stop you from using the OPB, just that there isn't currently a PSP that is specifically for the PowerPC to use it.

To create an Impulse C process that accesses shared memory with the PowerPC, the best example would be the 'ImageFilterDMA' found in "Examples\Xilinx\VirtexIIPro\ImageFilterDMA". It uses the not-so-obvious "Xilinx Virtex-4 PLB (VHDL)" PSP which puts streams, signals, etc. on the PLB bus, however, it uses the OPB for co_memory interfaces (PLB version is to be added later). There is some reference to this example in the PSP help file (Help->"Platform Support Package Help", choose "PSP_Xilinx_Virtex_II_Pro.chm" and see the section "Shared Memory Features".
To implement the ImageFilterDMA example in EDK:
1) Add the resulting IP (plb_img_arch) in EDK as you have been doing
2) Connect the MOPB and SPLB busses
3) Set the SPLB's c_baseaddr/"Base Adddress" to an unused, uncached, memory space such as 0xFFFE0000 and then set the "Size" to "64K"

Software-wise, assuming your software is being exported into the EDK directory via a "Export Generated Software" in CoDeveloper, all the code necessary for an application (co_init.c, img_sw.c, and img.h) is located in the "code" directory and the source code under "drivers" will be compiled into a library as part of doing the EDK's Software->"Generate Libraries and BSP" operation and linked in when you build the application.

*As long as your memory controller is already on the OPB bus, please disregard my notes on using the opb2plb bridge. This is only necessary when the memory controller is on the PLB.

Ed

[mypowlar]

thank you very much.
i have tested ImageFilterDMA example ok. it does well.
but there is a problem here:

if i use the run the program once just like the followed, it is ok.
my_arch = co_initialize(NULL);
co_execute(my_arch);

problem is that if i rerun it, it can't work right and it's blocking.

so i had to re-down the *.bit file, then rerun the *.elf, it work ok again.
so program like followed can does only once right!
my_arch = co_initialize(NULL);
for(i=0; i<1000; i++)
{
co_execute(my_arch);
}

Can you help me to solve the problem to let the filter operation do any times?

[etrexel]

Good to hear that worked for you.

Looking at the code, apparently much of it is setup to only run once. It would also only run once under software simulation.

In order to make it run each time "called" by your for-loop around co_exectue():

1) Hardware processes should have a main loop and shouldn't break out of it. If they do, the state machine implementing them will go to a final state and remain there until reset and/or reloading the bitstream. In software simulation, the processes need to exit at some point, this is where the macros IF_SIM() and IF_NSIM() come in handy. Looking at each of the four processes in the example, to_stream(), prep_run(), filter_run(), and from_stream(), none of them have a main loop. Putting a do-while around the code that includes the co_stream_open() and co_stream_close(), should create the loop necessary.

2) The filter needs to be called more than once. Your for-loop does this by calling co_execute() multiple times. An alternative would be to put a loop in call_fpga() around the co_signal_post() and co_signal_wait(). Typically you would change the input data before calling co_signal_post().

Ed

*Attached is code from the example that has been modified ad run under software simulation. There is a constant MAX_LOOPs in "img.h" to control how many times software simulation will run and exit gracefully.

Attached File(s)

•  ImageFilterDMA_multiloops.zip (4.66K)
  Number of downloads: 18

[mypowlar]

thank you very much. I have tested them ok.

[etrexel]

thank you very much. I have tested them ok.

You're welcom and good to hear it's working,
Ed

[mypowlar]

First thing I can think of when using shared memory over the OPB in a PowerPC system, assuming that the memory you're trying to get to is on the PLB where it is usually by default, is whether there is an opb2plb bridge present. If not, you will need to add one which includes:
1) connecting the opb2plb breidge to the OPB and PLB busses (SDCR not required)
2) connect the "BGI_Trans_Abort" port of the opb2plb and plb2opb together
3) Configuring the opb2plb memory map which at minimum includes:
a) OPB Register Base/High Address, this is where the CPU finds the bridge's registers
Range 0 Base/High Address, this is the address range the bridge will map FROM the OPB bus and forward do memory requests on the PLB bus


Can you tell me more detailed?

[mypowlar]

I have implemeted the opb2plb breidge to do imagefilter ok.
But the program's performance is reduced. I think the opb2plb bridge may influent the bus performace,
expectially, when i ofen operate the PLB's SDRAM such as memcpy opertion on PLB's SDRAM.

is my point right? if it is true, how can i improve my performace?