Hi,
(cc'ing the Milkymist list as we might be interested in adopting the
same system, and everything discussed here is public information already)
On 02/08/2012 04:51 PM, Javier Serrano wrote:
On Wed, 2012-02-08 at 17:39 +0200, Alan Langman wrote:
Javier, what are your plans to simplify the integration of cores for
boards that support multiple applications?
The integration of cores themselves in the overall HDL design is still a
manual process on our side. We have worked on a Wishbone enumeration
scheme that would help in re-using host-side software support for each
core. You can have a look at our latest developments in
http://www.ohwr.org/news/240
Here is some feedback on your spec and this FOSDEM presentation:
1) This system doesn't seem tied to Wishbone and I think it can be used
with most on-chip buses, so perhaps the name should be changed. FYI,
Gaisler Research has designed a similar system for AMBA, but I do not
know how it compares and if it can have some compatibility.
2) On-chip memory is an expensive resource, so it would make sense to
put more accent on code density rather than human readability. I believe
it is often easy to have a software routine somewhere in a system to
decode the block. So I would e.g.:
* use a 32-bit only magic word, which represents a probability of
collision of less than one in four billion if that word is chosen randomly.
* use a shorter date encoding (and I do not think we really need
32-bit alignment here)
* do without the ASCII strings, which look nice, but take a lot of space.
3) It is more expensive to have several small ROMs than one big ROM.
This is particularly true for FPGA implementations where large ROMs can
be much more efficiently mapped to block RAM resources (actually, when
block RAMs are used, point #2 becomes less valid, since the granularity
of those memories is e.g. 1 kilobyte for Spartan-6). You'll probably
want to keep the pointer-based system though, as it allows you to easily
have descriptors residing in several different chips.
4) Point #3 brings me to another reason why Migen should be used :-)
When writing Verilog/VHDL directly, you only have the options of having
a small ROM in each core (which is wasteful) or writing the main ROM
manually (which is not very productive and can lead to errors). By
contrast, it would be straightforward and elegant to have the Python
objects for cores and bus interconnect register with one central object
that builds the ROM.
Best,
Sébastien
_______________________________________________
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode
