Hi Sebastien,
> (cc'ing the Milkymist list as we might be interested in adopting the
> same system, and everything discussed here is public information
> already)
Great to hear that!
> 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.
I agree that this is not tied to Wishbone specifically. Alessandro and
I noticed this a few days before the conference and we received basically
the same feedback from the OpenCores guys (+ their friends). I think we
can work on melding this effort into a more generic one that can be used
as a generic description format.
I'm not familiar with the work by Gaisler but thanks for the tip, I'll
definitely take a look!
Also for the name, I was thinking of yet another horrible acronym:
LCSD: Logic Core Self Description (I refuse to put the word IP core
into the name anywhere :D). Sounds like LSD...
DeLoCo? Descriptors for Logic Cores? Gah I'm terrible at this...
> 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.
I think Alessandro has already replied to this but I add my own too.
We want to support devices ranging from constrained to lavish and we
were thinking of providing different sized descriptors for differing
space availability. What is your opinion of such an approach?
We could do something like 64, 32, 16 bit versions of all the parts
of the spec (header, id block, device descriptors, child pointers).
And as Alessandro mentioned, we've made most of the fields optional as
we can imagine most designers wouldn't be bothered to fill this in for
every device.
> 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.
I think the pointer based system is very flexible and doesn't require
messy mappings. That being said, I think it could be implemented in
other ways as long as it provides the same information. For testing
an ADC+SPEC here in the lab, I'm using a firmware file for the descriptor
information. We will not use it in production but I see lesser now the
reason to impose this restriction of placing everything within ROM's on
everyone.
Hope to collaborate more in the coming months!
@everyone: I will write up the new ideas sometime this week (weekend?)
and push to the mailing list for feedback.
Thanks and best regards.
--
/manohar
_______________________________________________
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode
