Hi,

Here are some suggestions for the multimedia SoC architecture (http://opencores.org/?do=newsletter&2009=06#n3), from my development experience of Milkymist which faced similar problems:

* Why not use FML (http://www.milkymist.org/doc/fml.pdf) instead of WISHBONE for the local bus? Using WISHBONE with DRAM controllers is painful (because of all the corner cases with burst transfers) and inefficient (because you cannot pipeline transfers).
* You could then use HPDMC (http://www.opencores.org/?do=project&who=hpdmc) as memory controller, which has already been proven on high-bandwidth applications; and I'm happy to fix any remaining bug you might find.
* You can then bridge the FML bus to WISHBONE using the same controller as in Milkymist (http://milkymist.org/viewvc/viewvc.cgi/milkymist-core/cores/fmlbrg/) which also contains a second-level write-back direct-mapped cache that supports critical-word-first and early-restart.
* You may want to consider using a lighter CPU than OpenRISC, like AEMB (http://www.opencores.org/?do=project&who=aemb) or LatticeMico32 (http://www.latticesemi.com/products/intellectualproperty/ipcores/mico32/index.cfm). Compared to OR, they use a fraction of the FPGA resources and easily run at more than twice the clock frequency. This may well compensate for the lack of DSP instructions in my opinion.

Sébastien

Indeed, Wishbone makes it impossible to have pipelined bus transfers. However, the FML provides solution that is very customized and. It might fail to provide a good solution for SoC of such a general nature. I'm also not sure what is the nature of FML. Is it proprietary? Or is it open source (core)? I think that the architecture of the multimedia Soc will be decided first, and the buses will be chosen according to the system requirements.

I suggest separation of (at least) two different buses. One for memory access, and the other for control (cpu control over peripheral controllers)

The LatticeMico32 is proprietary core, which might be a problem.

Hi Sebastien,

I read fml specs and I have 2 comments:

1. in 2.6 the fact that 2nd master must calculate the number of cycles to wait before putting write data on the bus is a quite heavy restriction. How can you calculate this number? is the arbiter in a multimaster to have this duty?

2. if you solve 1. then it would be better to accept any number of "ack" to pipeline a number of transfers bigger than 2. Currently in fact I think you support only 2 pipelined transfers. A more performant approach would be to split address and data channels, and tag various transfers ongoing, let's say "AXI-like"

Cheers,

Federico

> However, the FML provides solution that is very customized and. It might fail to provide a good
> solution for SoC of such a general nature.

Could you elaborate?

> I'm also not sure what is the nature of FML. Is it proprietary? Or is it open source (core)?

It's open source (custom bus part of the Milkymist project). I have not really thought of a good license for it yet, maybe GNU FDL.

> I suggest separation of (at least) two different buses. One for memory access, and the other for
> control (cpu control over peripheral controllers)

Yeah, I do that too (and I also have my simple custom bus for peripherals). See http://www.milkymist.org/doc/csr.pdf

> The LatticeMico32 is proprietary core, which might be a problem.

I don't know what your definition of "proprietary" is; but in fact LM32 is released under a BSD-style license with source code.
http://milkymist.org/viewvc/viewvc.cgi/milkymist-core/LICENSE.LATTICE?view=markup

> in 2.6 the fact that 2nd master must calculate the number of cycles to wait before putting write
> data on the bus is a quite heavy restriction. How can you calculate this number? is the arbiter
> in a multimaster to have this duty?

Yes, the arbiter does this (and the slaves put write data immediately).
See http://milkymist.org/viewvc/viewvc.cgi/milkymist-core/cores/fmlarb/rtl/fmlarb.v?view=markup for an example implementation.
It not heavy or restrictive, the full arbiter is
> if you solve 1.

FYI, systems using FML work on actual FPGA boards.

> then it would be better to accept any number of "ack" to pipeline a number of transfers bigger
> than 2. Currently in fact I think you support only 2 pipelined transfers. A more performant
> approach would be to split address and data channels, and tag various transfers ongoing, let's
> say "AXI-like"

Yes, a split transaction bus would be faster, especially if the memory controller reorders transfers to maximize the page hit rate. But also more complicated and more resource-intensive. To me, having only a second transfer in the pipeline strikes a good complexity/performance compromise.

Of course!

If I correctly understands FML, it is restricted to a bXw (b-by-w) block transfers. i.e. no single clock transfers are possible, nor byte strobing (bus width granularity) are possible. It seams that it might be too restrictive (= customized).

However, on one hand, FML might be good enough (or even superb) for the multimedia Soc. AMBA AXI, on the other hand, might be adequate as well. Hence, I think that requirements and architecture should be decided first, and then, the buses sort and properties should be decided accordingly.

Yes, FML has this restriction, because SDRAM has. When you use in burst mode at least, but SDRAM is damn slow when you don't; and you usually need speed for multimedia.

FML is designed to ease the tedious task of writing a good SDRAM controller (KISS principle). If the bus has the features that you mention, then the SDRAM controller design becomes a Royal PITA; and the multiplication of corner cases makes verification a nightmare. It would also requires more hardware resources.

And using FML in practice can be actually pretty efficient:
1/ If you need frequent small transfers, it is often adequate to implement a cache inside the core which makes such transfers, whose line length matches the size of a SDRAM/FML burst. Such a cache is usually needed anyway to get a good performance out of SDRAM.
It is also an option to share the cache among several peripherals and access it through a WISHBONE bus. This saves resources and reduces cache coherency problems.
Implementing the cache inside the SDRAM controller makes a "monolithic" controller which is harder to debug and is not always efficient (see 2).

2/ If you need bulk streaming transfers (for example, for implementing a VGA framebuffer or digitizing video), a cache is a bad idea because each line will only be used once before it gets evicted. With a shared cache, the streaming core will happily evict many lines that could be re-used by other cores.
In this case, it is a better idea to connect directly to the FML bus, and use FIFOs to pack/unpack the data into bursts of the right size. This uses a lot less resources than a under-used cache.

Sébastien