[J-core] Pondering j-core kickstarter ideas.

[Rich Felker]

On Mon, Apr 25, 2016 at 12:26:56PM -0400, Christopher Friedt wrote:
> > This means you can make SOC's for a little under $2/chip, but what we
> > DIDN'T work out is what you'd do with those next.
> >
> > This is a tiny little chip (a couple milimeters on each side), which you
> > could stick on the end of a USB or Ethernet connector, anything that
> > provides both data and power. The question is, what would it take to
> > wire the pins on the thing to the pins on say an ethernet connector,
> > properly buffered so that passing insects don't fry your circuits? And
> > what other stuff do you need to add (similarly tiny DRAM chips that our
> > DRAM controller can talk to, etc).
> >
> > What would it take to make an actual, minimal hobbyist _device_?
> 
> Since nobody else has ponied up to give some feedback, I would
> probably say that the best features to add are are on-chip peripherals
> for short-range communication:

Hardware isn't my specialty, so forgive me if I'm mistaken on some
points, but I'll try to provide info on what I understand about the
current state of on-chip peripherals:

> * i2c

I believe i2c is in the works but I'm not sure.

> * spi

We have spi but it's pio-only right now. A new dma-capable spi
controller is in the works now; I hope to start testing it from the
software side soon.

> * (full) uart(s)

Is there a practical reason the uartlite-compatible uart we have now
is not suitable? IMO it's easier to program than an 8250/16550 but
maybe it lacks some features needed for some applications. I know we
also have vhdl for a 16550-compatible controller but I'm not sure
whether it's something that can be released as open source.

> * obvioulsy a GPIO controller

We have GPIO pins, but as far as I know you have to bitbang them, and
I'm not sure if they're setup to generate interrupts. Is there a
higher level controller interface that would be good to have?
Something like spi but for multiple pins?

> * A2D / DAC

Not sure.

> * as large a supported memory area as possible

Internal memory, or do you mean capability to support large external
memory? Right now the memory-mapped hardware is based at 0xabcd0000
which limits the amount of contiguous dram to about 2.5 GB, but now
that we're moving to device tree it's trivial to move the mappings
without breaking software that uses the mappings from the DTB, so I
think it could be expanded to nearly 4 GB.

> * naturally on-chip clocks and timers are of course very useful

The existing PIT/RTC device has single-cycle resolution for generating
a timer interrupt and reporting current time. Are there other
capabilities that would be useful to have in this area?

> For some things, e.g. ethernet, there are a number of discrete
> ethernet MAC / PHY chips available too [1][2]. Notice that SPI is a
> very common interface for ethernet & wireless comms.

The Turtle board is going to have an ethernet PHY. We have vhdl for
the MAC side, and hopefully it will be ready for release alongside the
board. I don't think there's any need to use an external MAC chip, and
my guess it that it would be more costly and harder to get good
performance that way.

Rich