Re: [oc] SoC bus review

[Rudolf Usselmann <rudi@asics.ws>]

Hi John !

on 1/3/01 9:18, John Dalton at johnd@southern-poro.com wrote:
> Thanks for this document Rudi.  It made an interesting read.  Can you
> include a reference section with URLs for the relevant standards?
> 
> Comments on AMBA:  The ASB has been superseded by the AHB, thus the
> ASB should not be considered as part of a new specification.

Thanks for that info, it was not clear from the spec. they talk about
both and only state that AHB is the "new generation bus". So how are
people supposed to integrate devices that were written for the "previous
generation" bus with "new generation" bus.

Sounds to me they are spinning their wheels to keep up !

> If the IBM CoreConnect bus requires licensing from IBM, then it is not free
> in the sense of intellectual freedom.  It is only free as in free beer.

Right, neither AMBA nor CoreConnect are free. And I believe both licenses
can be revoked, which makes it tough for us as we would have to change the
interface on all cores if that would happen.

As I said, I think Wishbone is the right pass to take. I also like that I
have to learn only one set of signaling protocols and design only one bus
interface !

> The SoC busses seen to be microprocessor-centric.  How suited are they
> for point-to-point applications?  For example, connecting dedicated
> signal processing blocks, such as ADCs, DACs, FFTs, etc., together.

Good question !
Lets talk about wishbone only, as I'm getting the feeling everyone dislikes
one thing or another about the other two ....
Wishbone does support memory mapped, FIFO and cross bar infrastructures.
I guess any DSP block, would have to be able to operate as master and use
one of the above techniques to talk to the other DSP block. Control
communication could be done through message FIFOs, data could be memory
mapped.


> Along a similar vein, I've been looking at defining a module standard
> for connecting FPGAs together (in connection with a modular FPGA system).
> This work is closely connected with SoC issues, as it makes sense that any
> FPGA module system should be able to 'wrap around' the SoC bus, allowing
> the SoC bus to bridge between FPGAs.

Hmm, I see the challenge, but I wonder if it is within our scope. This is
more of a systems issue. It might apply to us when we would build FPGA
prototypes, but even then, with he new large Vertex FPGAs, I think we could
pretty well model an ASIC. I would wary more about performance (clock speed)
then splitting the cores across several FPGAs.

> So far, all I've decided is that each FPGA module should include two sets of
> JTAG
> signals.  One for configuration, one for testing and emulation.  Any more
> suggestions?  Maybe this is sufficient.  All other signals should be 'user
> defined',
> with the SoC specification forming the next level down in the FPGA module
> specification.

I think that would definitely not hurt !
Why don't you write something up !!!

> Regards
> John Dalton


Cheers !
rudi