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

[Ken Phillis Jr]

I actually got a side Message in regards to this that was off list...
However I figure some of the idea is pertinent...

On Wed, Oct 18, 2017 at 3:58 PM, Rob Landley <rob at landley.net> wrote:

> 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.
>
>
Honestly, I was not thinking of an Emulation Console in my suggestion. My
actual Idea was a usable console so developers can learn how to
program/develop games in a restrained system. Actually the fact that the
base device is limited to 256mb of ram is actually useful in this regards.


> > 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.
>
>
Realistically, having SDCard/MicroSDCard support is the biggest feature.
Most end users will not be bothering with EMMC.


> > * 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
>
>

I honestly believe the current J2 Core lacks hardware Floating Point, but
that is not a major problem... I was thinking the fastest solution for this
would be to add Instructions for Fixed Point math, and have this task
broken down into four major stages/tasks...

Stage 1: Add hardware Accelerated Fixed Point math - Luckily this has two
main wikipedia articles, and some example C/C++ code exists. Either way,
this can be used to help coax the Integer unit of the device to speed up 3D
math.

Wikipedia: Fixed Point Arithmetic:
https://en.wikipedia.org/wiki/Fixed-point_arithmetic
Wikipedia: Q Number Format: https://en.wikipedia.org/wiki/Q_(number_format)
Github: Libfixmath - the fixed point math library:
https://github.com/PetteriAimonen/libfixmath
Github: LibfixMatrix - Fixed Point matrix math library:
https://github.com/PetteriAimonen/libfixmatrix


Stage 2: Add SIMD Instructions for integer math (Signed, Unsigned, and
fixed Point)

This is cloning the expanded ALU to handle running various math functions
in parallel... In general this should cover the following Functions:
* Parallel instructions for basic ALU Functions - Think Addition,
Subtraction, multiplication, division, etc.
* Vector Instructions - This is stuff like Dot Product, Cross Product, and
Linear Interpolation.
* Vector Interpolation - this is Linear interpolation between two values
with a values.

Stage 3: Implement Texture Block...
This is mainly 4 sub-Tasks...
Task 1: Implement Texture Lookup for 1D Textures, 2D Texture (U, V), 3D
Texture (U, V, W). In general this is well defined in the OpenGL
specification. The biggest change is from the addition of GL_EXT_texture3D
which is released in 1996.

Task 2: Implement basic Texture Filtering. This is mainly texture
Interpolation, and most 3D Engines make use of this in some form or
another. The filters for this are as follows....
* Nearest-neighbor interpolation
* Bilinear filtering
* Trilinear filtering
* Optional: anisotropic filtering - This is an extremely expensive
operation, which will probably need to wait until the cores support ddr3 or
ddr4.

Task 3: Implement Alpha Blending/Compositing engine - This is mostly
hardware implementation of the math functions outlined in:
https://www.w3.org/TR/compositing/

<https://www.w3.org/TR/compositing/>
Task 4: Texture data is probably going to use options that are not in the
Powers of Two.

Stage 4: Implement OpenGL ES 1.1 with this functionality. The big part is
include the GL_OES_fixed_point extension.




> > * 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
>

Actually, The CPUID Instruction is an efficient way to pass information
about the current SoC/Chip  to the Operating System, Boot loader and
software. For intel systems the modern CPUID Function contains about 2048
bits of information (see: https://en.wikipedia.org/wiki/CPUID )... If we
apply this to the current project, you can see a lot of information which
is extremely useful without wasting a lot of space... Some of the
Information provided is as follows....

* Number of CPUID Pages.
* Vendor ID
* Extended Processor Information
* Processor/SoC serial Number
* Memory Management Unit Support - If so, possible revision.
* Address Mode Support - Does the chip have 16-bit, 32-bit, 64-bit, etc
Memory Space.
* Number of CPU Cores
* CPU Core number that ran the instruction.
* Floating Point Unit Support - This is stuff Like 16-bit, 32-bit, 64-bit,
etc...
* Floating Point Unit Version/Revision
* CPU Memory Address mode - Some chips can toggle between little endian and
big endian.
* Available Instructions sets - This includes stuff like SIMD Instructions,
DSP Instructions, etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20171018/e1a21616/attachment-0001.html>