2 microblaze access same BRAM ?

Hi,

There should be no problem with this. Just add two bram blocks and connected MicroBlaze1 and MicroBlaze2 instruction LMB buses to the first bram's two ports. Then do the same for the data LMB buses for the second bram block.

This can all be done in Xilinx Platform Studio (XPS).

Göran Bilski

El> hello

hi

It is good be feasible. I found that in XPS wizard we can set maximaly

64 KB for BRAM. Subsequent question is about the size. Can we make it bigger, for example 128KB or 256 KB ?

Thankyou again

Yes, Just have multiple bram blocks and bram controllers.

Göran

El> hi

i like this 'great' flexibility in FPGA. In this context, i dare to make more 'what if' questions (to me, to others)....

What if we have 2 microblazes (uBLAZE0, uBLAZE1) with BRAM0 and BRAM1, respectively. Suppose BRAM0 ranges 0x00000000 - 0x00003ffff and BRAM1 ranges 0x00004000 - 0x00007ffff. The uBLAZE0 wanna access BRAM1 using shared variable so that programmar see 2 BRAMs as one big global memory. Then problem will be bus ( memory access ) arbitration. So we may need a special hardware. Writing an application code will be uneasy as well, because we will need only one main routine. How can we utilize xilinx-provided design resources to do those? This seems to be very hard but interesting ......

Hi,

Let see if I got this right. You have two MicroBlazes and the bram blocks. I assume that the bram blocks are shared as the original question ask about.

If the uses one port each from each BRAM there is no arbitration since each bus only have one master (one of the MicroBlazes).

They will share the whole memory range 0x00000000 - 0x00007fff.

So this is easily handled in the XPS.

Göran

El> i like this 'great' flexibility in FPGA. In this context, i dare to

hi

Well, in your construction, if two uBLAZEs try to write (or read) to shared variables at the same time, what happens?

Another interesting thing will be a programming. In XPS, each processor has its own main() routine. In case they are communicating with shared variables, how can we synchronize two program ? By the way, what we want is to do 'one' job (with two processors) ! Is it possible to run only one main() routine ? thankyou again for this 'what if' questions

That is standard multi-programming handling. I would connect two FSL between the two MicroBlazes and let them agree on who should use shared resources.

Göran

El> hi

hi

Final --: questions are about the suggestions above- multi-programming and FSL. I find FSL is a point2point link in the product specification. It seems that two approaches are totally different. Does EDK support such a multi-programming? If yes, in which way? How can we emulate the shared memory hardware and software (for example, threaded programming) in Xilinx tool?

2 microblazes with FSL and shared memory ; this looks very exotic and it seems that we still have two independent main() routines. In any case, it will be interesting that one main() routine transperently describe an algorithm and two microblazes coorperate each other.

By the way, thankyou very much, G=F6ran

Since both processors starts at address 0, they will start to execute the same initialization code. You need to use a FSL port with different constant signals for each MicroBlaze. The boot code would then read the FSL port to know which MicroBlaze it's. Using this it would jump to the right code section.

I would have all code tied on one processor and letting the other processor using this as in will start to execute the same program.

Our JTAG debug module handles concurrently up to 8 MicroBlazes in parallel so there is no problem debugging this. You will get a gdb window for each MicroBlaze.

It can all be done in the current tools, so just start and have some fun.

Göran

El> hi

Dual CPU IBM S/360 have a system for exchanging a block of low memory for another block somewhere else. That let each one have its own address 0. It is extra logic in the address path, but it might work in this case.

-- glen

Dear Mr. Bilski, sorry for the intromission. Just a question: how you can declare a FSL port with constant signals without defining a custom FSL core?

Thank you very much!

Hi,

That is simple. In the .mhs file if I want to assign a constant value of 1 to fsl port 0 and also to make it always ready, I just add this to the MicroBlaze block.

PORT FSL0_S_DATA = 0b00000000000000000000000000000001 PORT FSL0_S_CONTROL = 0b0 PORT FSL0_S_EXISTS = 0b1

Göran

TheMightyShaman wrote:

Hi,

If you don't want to express the constant value as binary, you can also do this.

PORT FSL0_S_DATA = 0x00000001

Göran

Göran Bilski wrote:

this.

That's great!

Thank you very much for the help.

Dear Goran, sorry for the disturb, another question: how can you read and differentiate the constant signals if when executing a reading with mb_interface.h primitives on fsl the value on the FSL will be put in a variable that is shader if you are working with a shared data memory? The first processor that read will put its number in it and so you can't jump to the proper code...

Any suggestion?

Thank you very much!

First,

So it's possible but no if you planning on just using plain C since the startup code (crt) that gcc uses can't handle this. A new startup sequence is needed.

The startup code would read the constant and then save it at different addresses depending on the constant value (addr = base_addr + constant value). The constant value would also create different stack pointer addresses (r1 init value) so the MB doesn't use the same stack space. The other data pointers needs also to be separate. The final part of the startup sequence would jump to different PC addresses depending on the constant value.

Göran

TheMightyShaman wrote:

Hi Goran, thanks for the clear and complete suggestions. It seems an interesting procedure but also not so easy to implement, I'll give it a try and see if I obtain results.

Thank you very much and sorry for the disturb!

No problem. I had to think a little on how to solve it. It's not a normal system.

I wished I had time to try it out.

My view of multiprocessing is more of distributed processing where each processor has it's own memory and the communication between are done with message passing using FSL. Very much like to old transputer concept.

Göran Bilski

TheMightyShaman wrote:

interesting procedure but also not so easy to implement, I'll give it a try and see if I obtain results.

No problem. I had to think a little on how to solve it. t's not a normal system.

Yeah, in fact it seems that the microblaze architecture and the available ips aren't really well suited for this type of multiprocessing (i.e. only with pools of shared memories). Much better would be to take advantage of the local memories (maybe using a shared memory too along with the FSL connections).

I wished I had time to try it out.

It seems not so easy to manage: I think that after the initialization sequence there would be anyway problems to manage the same code for both the processors... In fact, I think that it would be rather easy to "jump" to the different code for the processor rather than "branching" on the code depending on the CPU constant signal (identification). What do you think?

My view of multiprocessing is more >of distributed processing where each processor has it's own memory and >the communication between are done >with message passing using FSL. Very much like to old transputer >concept.

Yep, it seems one of the model destined to become dominant in the next years (thinking about CELL Architecture)...