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

[Rob Landley]

On 10/16/2017 12:18 PM, Ken Phillis Jr wrote:
> I saw this thread from over a year ago, and figured I'd offer a two stage

This is really a Jeff question (and I think he's flying back from north
america to tokyo this week), but we have a working board design:

https://www.cnx-software.com/2017/03/13/turtle-board-is-a-raspberry-pi-2-like-fpga-board-for-j-core-j2-open-source-superh-sh2-soc/

None of the problems with that are technical, it's a business-side
thing. We're understaffed and everybody's gotten pulled off to put out
customer fires like _five_times_ now.

The _technoogy_ has been ready for a year, we have a dozen working
prototypes but haven't done the production run yet. (Ok, Jeff says he
wants to replace the Atmel 8-bit boot processor with an ice40 so it's
open all the way down. Basically there's a tiny proprietary bit in the
existing prototypes that stops mattering after power-on, its job is just
to load (or re-flash) the fpga from the spi ROM, but as long as we
haven't manufactured a production run yet we might as well get _all_ the
programmable logic open hardware, and ICE40 can load _itself_ from SPI,
so... That's probably only a couple days for Martin to modify one of the
prototypes and Jeff has ice40 vhdl code for this from a previous project
in a repo somewhere...)

(Blah, reading the above article I should take the twitter account back
over. I was doing it initially, but then a sales guy was doing it and he
left last year. I've got the login credentials around here somewhere...)

> Stage 1: An do it yourself Arduino-like device.
> 
> This is probably going to use either the J1, and/or J2 core. However,
> almost all of these features will probably make it into the newer cores
> in some form since there is very little reason to exclude these features.
> * 8 Channels of Analog to Digital ( ADC).

We made a high-end ADC sensor chip as our first asic (in like 2014?)
There's a 150 nanometer shuttle in March we really really really want to
get our SOC on, an that's ANOTHER thing distracting engineers from
shipping Turtle at the moment...

> * 8 Channels of Digital to Analog Conversion ( DAC). ( Should Match the
> ADC in bits).
> * Inter-Integrated Circuit (I2C) support
> * Inter-IC Sound ( I2S)
> * Serial Peripheral Interface (SPI) support
> * Universal Asynchronous Receiver-Transmitter (UART)
> * Pulse Width Modulation (PWM) support.
> * full-size USB Port or Micro USB Port. 
> * Built-in USB Programmer support
> * Built-in USB OTG Support - The example code for this will be use as
> Serial I/O.
> * support for Full size or Micro SDHC Cards.
> * 40 pin gpio header that is electrically compatible with Raspberry Pi GPIO.

There's a standard for that, it's call the HAT specification.

  https://www.raspberrypi.org/blog/introducing-raspberry-pi-hats/
  https://docs.particle.io/datasheets/raspberrypi-datasheet/

As far as I know Martin made our thing compatible with that. (The data
pins are wired straight to the FPGA, possibly with little anti-static
filter thingies. I dunno about the power an ground pins, those might be
board-level. There's a thing on it somewhere, I should dig it up and
properly post it on the website, but "complete website redo" is one of
those big can-of-worms things that needs a couple uninterrupted weeks
devoted to it. I have quite the todo list for that...)

> KickStart Idea 2: Game Console.

It's nice of archive.org to put up the Giant Rom Tarball for download,
but MAME is still a legal minefield, and emulating a saturn turns out to
be a wretched hive of timing dependencies and villainy, based on the
fact that the sh2 didn't _really_ support smp (we _added_ cmpxchg to j2)
so they just had them talk on the same bus and write over each other
with contention managed by wait states, and every game ever goes NUTS if
the timing varies even slightly (our instructions don't take the same
number of clock cycles as sh2 did, several take _less_, and that screws
stuff up...) And they did the same thing with the other custom chips on
the board for sound and video and such, and then they sprayed everything
down with DRM on top of that:

https://www.geek.com/games/sega-saturn-finally-cracked-saving-the-console-from-extinction-1661486/

So yeah.

> This is pretty much for the J3, J4 and/or J64 chips. In general mostly
> expansion of features. I also figure a lot of the features on this will
> probably take a lot of time/effort... The features for this are provided
> blow...
> 
> * EMMC Support

Per-unit license fee from a lawsuit-happy consortium managing a patent
pool, that's why we implemented the slower spec that's out of patent.

> * SATA Support
> * Memory Controller - This is either DDR3 and/or ddr4 memory support.

We implemented... lpddr2 is it? Maxes out at 256 megs (largest chip they
manufacture at that spec). Shouldn't be too hard to have 2 of them in
parallel, although the cache controller would have to dispatch (probably
an even/odd straddle by cache line? Ask Niishi-san...)

Has anybody solved rowhammer in ddr3 or ddr4 yet?

> *Audio Output - this not required, but should be helpful. The I2S
> support can probably serve to implement this.

Turtle has audio out, it's in Rasperry PI.

> * Video Output - Examples of this includes DisplayPort, DVI, HDMI, MIPI
> Display interface, and VGA ports.

Turtle has HDMI, it's in Raspberry PI. (Jeff even made a frame buffer
VHDL thing for ELC in the spring, but I didn't get it integrated into my
demo in time due to travel and my own talk the day before.)

> * 2D Graphics Process - This is mostly OpenVG 1.1

It's a frame buffer.

> * 3D Signal Processing - 3d Rendering in OpenGL ES 1.1 or 2.0 should be
> helpful.

Can 'o worms, plenty of VHDL space though. A guy came to the

> * USB Host capability

In Turtle because Raspberry PI. Our current VHDL is USB 1.1 but the hub
chip upshifts it to 2.0 for the outside world. (And I _think_ somebody
had a clever hack that could make 2.0 work in the VHDL? Ask Jeff, he
keeps finding things Japanese engineers did that never got translated
into English...)

I believe 3.0 is out though, our hub chip is 2.0 and the FPGA isn't fast
enough to do 3.0 anyway. (That I know of.)

> * Ethernet/Wireless capabilities
> * Bluetooth

Did you follow Steam's attempt to make its own game console a few years
back? (Jeri Elsworth was involved, back before CastAR.) They at least
had an existing library of games they could easily port to it. (The
"Good Old Games" people might have some similar luck, although large
chunks of that old stuff is x86 assembly code so there's nothing to port
really...)

> J-Core Instruction set expansion: Add a cpuid Function -
> This is seen on most major processors, and can save end users/developers
> a lot of problems since the code being run can ensure the rest of the
> program can road since the developer can safely detect missing features
> that are expected.

That's a Jeff question, but such a thing would probably be on the SOC
not in the processor, meaning we'd do it via device tree. (The boot rom
passes a device tree into the rest of the system, but we're starting to
hit size constraints, so may need some sort of compressed format or
something. Can we save more size than a gzip decompressor is big? Let's
find out!)

I'm all for the enthusiasm and we REALLY need to get the turtle board
out into everybody's hands. I feel terrible that we haven't already,
Jeff was meeting with somebody just yesterday about getting that going.

Rob