wishbone bus between two fpgas

[alb]

Hi everyone,

we are in the preliminary phase of the architecture definition for our
system and we estimated FPGA resources (for a particular target) to be
~80% of the target's capabilities.

Being at such level at this stage is rather risky since we can easily
find ourselves in deep troubles during implementation.

Unfortunately the target is an RTAX2000S, with the bigger sister being
nearly as 3 times more expensive with only double the resources
(RTAX4000S).

For this reason we are more incline to split the architecture into two
FPGAs but that choice is certainly not free of hassles either.

Now comes the overhead of connection between the two devices and I came
up with a very stupid idea: what if my SoC bus (possibly a wishbone)
gets extended to the other FPGA as well?

With this approach I would simply move masters and slave around the two
FPGAs without having to think too hard and they will interact as if
they were sitting on the same fabric (except maybe for some extra
latency).

Moreover, if we've been extremely good during our preliminary phase in
anticipating the needed resources we can still fit everything in one
FPGA without the need to change too much (just adding components on the
bus).

Any opinion/experience/advice on the subject?

Al

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[jt_eaton]

Hi everyone,


Now comes the overhead of connection between the two devices and I came
up with a very stupid idea: what if my SoC bus (possibly a wishbone)
gets extended to the other FPGA as well?

If you do a full bus the number of signals will be a problem so you wil
want to trim them down. You may also want to combine the read and writ
datas in a single bidirectional bus to save pins.

Do assign the slave fpga it's own memory space so that any time you move
module then it's address will change. Otherwise you have to wait for
slower out of chip response on every access.

I have seen this done using fpgas with SERDES to serialize a amba ahb.

John Eaton

---------------------------------------
Posted through http://www.FPGARelated.com

 

[alb]

Hi John,

jt_eaton <84408@embeddedrelated> wrote:
[]

Now comes the overhead of connection between the two devices and I came
up with a very stupid idea: what if my SoC bus (possibly a wishbone)
gets extended to the other FPGA as well?

If you do a full bus the number of signals will be a problem so you will
want to trim them down. You may also want to combine the read and write
datas in a single bidirectional bus to save pins.

That is an option, but considering that we meet our pin budget with one
device I guess there shouldn't be a problem with two of them. Routing
though might be an issue, therefore I do take your suggestion as a
valid one.

Do assign the slave fpga it's own memory space so that any time you move a
module then it's address will change. Otherwise you have to wait for a
slower out of chip response on every access.

I'm afraid I haven't really understood this. Could you elaborate?

FYI we have a 'memory manager' that essentially handles access to an
EEPROM and an SRAM, as well as the internal RAM. The address space is
flat from the 'users' point of view, but this will work only if the
internal memory is on one device only, otherwise we will need to split
the memory manager in two and that is not a good idea.

> I have seen this done using fpgas with SERDES to serialize a amba ahb.

Oh, I see, so essentially you have a bridge to translate the system bus
transactions into packets of some sort. This approach is certainly
interesting but it demands a bridge to be implemented, while in my
approach there shouldn't be any additional cost (unless pin reduction
is needed) to move slaves/masters around the two devices.

Al

 

[jt_eaton]

I'm afraid I haven't really understood this. Could you elaborate?

When your master fpga accesses memory it needs to know if it is on the sam
chip as the master or on the slave chip. On chip is faster than having t
send the address out to the slave and wait for a response. You shoul
create a memory space for the slave chip and all of it's memory will resid
in that address space.

John Eaton


---------------------------------------
Posted through http://www.FPGARelated.com

 

[alb]

Hi John,

jt_eaton <84408@embeddedrelated> wrote:
[]

I'm afraid I haven't really understood this. Could you elaborate?

When your master fpga accesses memory it needs to know if it is on the same
chip as the master or on the slave chip. On chip is faster than having to
send the address out to the slave and wait for a response. You should
create a memory space for the slave chip and all of it's memory will reside
in that address space.

Ok, now I understand your point. It is a valid one but it presumes two
memory controllers, one for each device and then it becomes difficult
to share an external memory since you'd need an arbiter to get access
to it and no matter how smart you are, the arbiter cannot only sit on
one of the FPGAs.

It is true though that after the arbiter has granted the access (no
matter what is the scheduling algorithm used), it certainly adds little
overhead to the memory access compared to the additional delays you
would face with an external memory on each read/write operation.

That said the idea of having two memory controllers for the two FPGAs
is against the very first idea to have the possibility to squeeze
everything into one at a certain point without needing to rewrite the
architecture.

You are right though that any memory needed on the other device will
certainly imply a decreased bandwidth.