I build a system which has a MicroBlaze, a LMB
connect BRAM for local
instruction/data memory (8KB) and an OPB connected BRAM(64K) which will
be used as a shared memory for the Microblaze my user defined
coprocessor.

I connected my coprocessor with the MicroBlaze through FSL by using the
tool edit/import peripherals, but how can I make it to access the OPB
connected BRAM(64K). Do I have to write all the OPB ports manually in
the VHDL file in my coprocessor?

Thank you very much for your help.

FSL links are connected to MB core and can not
access the OPB
the OPB_MCH_SDRAM IP core has slave FSL ports so external FSL (XCL)
master can access the SDRAM over FSL (but not the rest of OPB bus)

so you have options
1) MB software will read FSL and translate it to OPB transaction in
software
2) you write your own FSL 2 OPB (master) bridge
3) if you want to access BRAM then you can access the second port of
the BRAMs but its rew BRAM port not FSL

Antti

FSL links are connected to MB core and can not
access the OPB
the OPB_MCH_SDRAM IP core has slave FSL ports so external FSL (XCL)
master can access the SDRAM over FSL (but not the rest of OPB bus)

so you have options
1) MB software will read FSL and translate it to OPB transaction in
software
2) you write your own FSL 2 OPB (master) bridge
3) if you want to access BRAM then you can access the second port of
the BRAMs but its rew BRAM port not FSL

Antti

Hi,

another option is to develop a FSL coprocessor with OPB Master interface 
(or an OPB Master IP with FSL interface) , isn't it?

Regards,

Ivan

Antti wrote:
> FSL links are connected to MB core and can not access the OPB
> the OPB_MCH_SDRAM IP core has slave FSL ports so external FSL (XCL)
> master can access the SDRAM over FSL (but not the rest of OPB bus)
> 
> so you have options
> 1) MB software will read FSL and translate it to OPB transaction in
> software
> 2) you write your own FSL 2 OPB (master) bridge
> 3) if you want to access BRAM then you can access the second port of
> the BRAMs but its rew BRAM port not FSL
> 
> Antti
> 

I want my coprocessor can access the BRAM diretly
because there is a
lot data transfer between them. It will be very unefficient to send
these data back to MB through FSL and then put them into OPB RAM or
vise verso.
I don't want to put connected my coprocessor to the sceond port of the
BRAM either because the BRAM(64K) is shared between the MB and my
coprocessor and I want the OPB arbitrator to solve the contension
problem for me. Then I needn't program my own.
For the second choice, write my own FSL2OPB bridge, or as said by ivan:
"develop a FSL coprocessor with OPB Master interface" will be quite
time consuming because I need to take care of my customized circuit to
the OPB bus  signals? But it seems the only choice I have.
Did I understand this correct?

Thank you very much for all the replies.

yes.
if you want to use EDK OPB arbiter then you need your own IP that has
OPB master port, and that may be time consumint to develop/troubleshoot

Antti

Hi again,

another possibility (that I have implemented sometime ago) is to use a 
BRAM memory in the coprocessor. The MB write/read data from this memory 
through the FSL interface, being accessible for the coprocessor too.

An schematic:

MB <--- FSL interface ---> BRAM <--- custom interface ---> Coprocessor

I hope that it is useful for you.

Ivan


fpga wrote:
> I want my coprocessor can access the BRAM diretly because there is a
> lot data transfer between them. It will be very unefficient to send
> these data back to MB through FSL and then put them into OPB RAM or
> vise verso.
> I don't want to put connected my coprocessor to the sceond port of the
> BRAM either because the BRAM(64K) is shared between the MB and my
> coprocessor and I want the OPB arbitrator to solve the contension
> problem for me. Then I needn't program my own.
> For the second choice, write my own FSL2OPB bridge, or as said by ivan:
> "develop a FSL coprocessor with OPB Master interface" will be quite
> time consuming because I need to take care of my customized circuit to
> the OPB bus  signals? But it seems the only choice I have.
> Did I understand this correct?
> 
> Thank you very much for all the replies.
> 

Hello, Ivan:

In your case, how do you deal with the contension when MB and the
Coprocessor to the BRAM?
And I don't understand why do you use FSL interface to connect the BRAM
but not OPB?
Thank you very much for your help.
I want to build a system as the following. So the OPB arbitrator can
deal with the contension when both MB and Coprocessor access the same
address in BRAM at same time.
MB(M1)<--->FSL Interface<--->Coprocessor(M2)
|                                          |
|                                          |
|---OPB(with arbitrator)-----------|----------------->BRAM

fpga wrote:
> Hello, Ivan:

Hi,

> In your case, how do you deal with the contension when MB and the
> Coprocessor to the BRAM?

I used one "BRAM memory" to write data from MB (PORT A) to coprocessor 
(PORT B) and another to write data from the coprocessor (PORT A) to MB 
(PORT B).

> And I don't understand why do you use FSL interface to connect the BRAM
> but not OPB?

If you need to share data from BRAM, you can use the OPB bus (as you 
propose). However, FSL is faster than OPB, and if you only need to share 
data between the MB and the coprocessor, this solution is more 
efficient. Of course, you need to develop the "FSL-BRAM interfaces" and 
the "BRAM-Coprocessor interfaces".

Each approach is correct, it depends of your performance/operation 
requirements.

> Thank you very much for your help.
> I want to build a system as the following. So the OPB arbitrator can
> deal with the contension when both MB and Coprocessor access the same
> address in BRAM at same time.
> MB(M1)<--->FSL Interface<--->Coprocessor(M2)
> |                                          |
> |                                          |
> |---OPB(with arbitrator)-----------|----------------->BRAM
> 

Regards,

Ivan

Thanks a lot.