LWN: Comments on "Resurrecting the SuperH architecture"

Added to Wikipedia article

landley — Mon, 28 Nov 2016 20:15:25 +0000

sh2+ is a decade newer than sh2, the patents on that don't expire for a while.

There's a very rough roadmap on http://j-core.org/roadmap.html.

Resurrecting the SuperH architecture

landley — Mon, 28 Nov 2016 19:57:46 +0000

The project moved to http://j-core.org in April 2016. The old 0pf website is full of stale content we no longer have access to update.

Rob

Added to Wikipedia article

moxfyre — Sat, 11 Jul 2015 04:26:20 +0000

Wow, this is a really exciting development for open source hardware! I've added a brief section on the J Core designs to the Wikipedia article on SuperH, heavily referencing this article and the 0pf.org site.

Do I have it right that the "J2+" design alluded to in the article will be an implementation of the SH-2A ISA? Will it include a MMU?

Resurrecting the SuperH architecture

stevem — Tue, 07 Jul 2015 15:02:50 +0000

Correct, 7100/7109/7105 are all SuperH based CPUs from ST. Commonly used in DVB things like set-top boxes...

Resurrecting the SuperH architecture

stevem — Tue, 07 Jul 2015 15:01:40 +0000

Has anybody fixed the missing bits in the toolchain for SuperH yet? Working on it previously, no tools would work with core dumps, and stack unwinding was a joke...

Resurrecting the SuperH architecture

granquet — Mon, 06 Jul 2015 13:37:55 +0000

Hey there ;)

stupid question ... is anyone maintaining a list of commercially available SuperH based chips?

IIRC, STi7105 is based around SH4

Resurrecting the SuperH architecture

duaneb — Wed, 01 Jul 2015 16:41:57 +0000

I believe the Harvard architecture was introduced with the SH-2A, though I could be wrong.

OpenRISC

mirabilos — Tue, 23 Jun 2015 13:56:13 +0000

> That said, the original application of this chip is realtime sensor[…]

That’s *your* original application. Other people may wish to do more fun things with it.

You had a huge chance – your slides started with the idea of *fully* opening a contemporary unixoid system. Using this as replacement for ARM (which are “dead on hitting market”, incompatible with itself, money-driven, inconsistent, not compatible in any direction, and adding stuff like trust zones, EFI and Restricted Boot, and which I never liked) and MIPS (which I liked only a bit more) could be genius. (Though I admit at being an i8088 guy first and foremost.)

Resurrecting the SuperH architecture

mirabilos — Tue, 23 Jun 2015 13:52:24 +0000

Can’t wait for the J4 with MMU. Debian will be able to run on it (cbmuser took over resurrecting sh4 port).

Resurrecting the SuperH architecture

palmer — Sat, 20 Jun 2015 17:00:51 +0000

You should come to the RISC-V retreat! We should be launching a general-purpose vector ISA extension there. We've been building vector machines that have a significantly better energy/op that GPUs do for GPGPU sorts of tasks for a while now, so we've at least got something along the same lines as a GPU. There has been lots of interest in a RISC-V GPU, I personally think the best way to go about this would be to port mesa to the vector machine and then see what needs to go faster.

This is probably a discussion better had either in person or via the RISC-V mailing lists, I don't want to hijack this thread too much :)

Resurrecting the SuperH architecture

roskegg — Sat, 20 Jun 2015 03:05:45 +0000

Thank you for that information. Do you know of anyone working on an open source GPU design? DSPs of all sorts are good especially for video and audio, but I haven't heard of anyone doing a GPU. The current state of graphics hardware scares me from a security point of view. Not necessarily because it is bad, but because in the past 10 years I haven't heard any announcements that anyone has fixed the problems on the hardware side. So, silence implies nothing has changed. I hope you have good news. Or that you know a GPU designer I can talk to offline.

Resurrecting the SuperH architecture

zslade — Fri, 19 Jun 2015 22:39:23 +0000

For a modern look at functional programming as metalanguage for HDL check out Clash: http://www.clash-lang.org/.

Clash uses Haskell to generate HDL code, both verilog and vhdl. Here are some examples: http://hackage.haskell.org/package/clash-prelude-0.8/docs...

Resurrecting the SuperH architecture

travispaul — Fri, 19 Jun 2015 03:17:58 +0000

I'm glad to see an interest in SuperH again. NetBSD still has SuperH support too, I cross-compiled and booted NetbSD 7 beta on the Sega Dreamcast just a few weeks ago.

Compare to LM32

landley — Fri, 19 Jun 2015 00:13:49 +0000

Yeah, Jeff did uclinux.org but handed it off in 2003 when he moved to Japan. The people he handed it off to more or less let it rot (their CVS repository died in a hard drive crash years ago, and the page is still 404, for example), and the fact a distro and a "linux for nommu community site" got tied together meant that when the distro went stale, the community site stopped working too.

To try to address this we've recently created http://nommu.org and we're slowly populating it with content and a mailing list and wiki and such. Alas, the bitstream stuff has been eating all our time recently but once that's on its feet we'll be advancing both projects in parallel. (The purpose of nommu.org is to support all the nommu linux variants, including cortex-m and coldfire and so on. The superh revival is http://0pf.org stuff. We _don't_ want j2 to overshadow h8000 and armv7-r and such on nommu.org, but while j2 is eating our brains it means we're not posting much to nommu.org yet.)

Linux for nommu _is_ interesting, there just hasn't been a place to go to talk about it that wasn't tied to a distro full of leftover packages from the 1990's. We want to push nommu support into buildroot and openembedded and make it _not_ be a strange esoteric thing requiring unusual expertise.

Working on it...

Rob

Resurrecting the SuperH architecture

landley — Fri, 19 Jun 2015 00:04:12 +0000

Yeah, people are working on that though. http://www.isi.edu/~nsteiner/publications/soni-2013-bitst... and http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014... are just two examples.

There's a chicken and egg problem here, we need open source hardware projects that actually have participants outside a single company, and are actually used to do real things, and then that community can help fix tool issues. But booting open hardware to a shell prompt has rather a lot of prerequisites, of which a bitstream compiler is just one.

When Linux started it used closed source netscape as its browser. Later there were closed source wireless modules and 3d modules and the flash plugin and so on. It all got replaced with open stuff, but people using the projects and making them work provided the pool of developers to do that heavy lifting.

Rob

OpenRISC

landley — Thu, 18 Jun 2015 23:46:38 +0000

The mmu comes in a year or two, after the sh4 patents expire.

That said, the original application of this chip is realtime sensor data timestamped with nanosecond precision. A nommu system can actually be a benefit here because even soft page faults trigger enough latency to screw up that kind of precision. So you'll still be able to configure the bitstream to build without one even after it's added.

(Of course keeping a nanosecond-precise clock in small distributed devices is its own very hard problem... and that peripheral the company is _not_ open sourcing. :)

Rob

Resurrecting the SuperH architecture

landley — Thu, 18 Jun 2015 17:23:31 +0000

The kernel patches for this are up, and the series description has information and links on downloading and reproducing the rest of it.

http://lkml.iu.edu/hypermail/linux/kernel/1506.2/02538.html

Rob

Resurrecting the SuperH architecture

jeff@uclinux.org — Thu, 18 Jun 2015 13:18:58 +0000

The first code release is out : http://0pf.org/community.html (sorry for the delay). We had to remove the parts that are not open (this is part of a product development effort for a large signal processing engine), and audit (as much as possible) quite a body of work.

It builds for 2 target boards (Avnet Microboard and Numato Mimas V2) with a simple SoC template.

The best place (I think) to look at what we mean by VHDL being far different than Verilog (or Chisel, or MyHDL, etc) is the Multiply Accumulate unit of the processor. Have a look in components/cpu/core/mult_pkg.vhd and components/cpu/core/mult.vhm for an example.

We have not released everything we intend to yet, the S-Core DSP is still in the pipeline. That code is newer than (even) this J2 CPU. I really want to post a few code fragments to give a flavour. This code, using for instance, the IEEE fixed point library, including extensive operator overloads result in concise, clean RTL that synthesizes down to efficient logic.

SEGA Dreamcast

Darkstar — Thu, 18 Jun 2015 08:35:25 +0000

The CPU was never the problem in emulating the Saturn. It was the insane synchronization requirement between the various (sub-)CPUs and other chips that basically forced emulators to either run in lock-step (essentially killing performance) or using game-specific tweaks and short-cuts (which were considered hacks and broke all the time)

Resurrecting the SuperH architecture

tpetazzoni — Thu, 18 Jun 2015 07:16:00 +0000

Landley noted that, indeed, the latest buildroot release did remove SuperH support, "but we're trying to get them to put it back now."

Rob seems to think he can talk for the Buildroot project, but he is making invalid statements. We did not remove SuperH support at all, as can be seen at http://git.buildroot.net/buildroot/tree/arch/Config.in#n183. What is true however is that: 1/ we deprecated SuperH64 support because no useful chip of that architecture was ever released as far as we know, and 2/ there is indeed almost nobody contributing to improving the SuperH support.

And when Rob says "we're trying to get them to put it back now", I hope he is not talking about the Buildroot project, because to this date, we have not seen a single patch from Rob about SuperH support. The last patch from Rob to Buildroot was on September 2014, to propose the addition of a package for toybox. And this was his only patch to Buildroot since 2008.

Note that I'm really interested in seeing a better SuperH support, and very happy to see a project doing an open hardware platform based on this architecture. I'm just a bit pissed off by Rob making invalid claims about the Buildroot project (he did the same recently on another topic).

SuperH Buildroot support is still alive

arnout — Thu, 18 Jun 2015 06:54:25 +0000

SuperH support was not removed from Buildroot, only the 64-bit support (sh64) has been deprecated. In fact, the autobuilders test sh4a support continuously and it rarely breaks.

Generally, Buildroot only deprecates or removes architectures when the support in gcc or uClibc degrades so badly that it becomes unmaintainable. For instance, avr32 support has been deprecated in 2014, when the avr32 fork of uClibc and gcc had not been updated for several years.

Resurrecting the SuperH architecture

palmer — Wed, 17 Jun 2015 22:17:32 +0000

I'm super biased (I work on both Chisel, RISC-V, and Rocket at Berkeley), but if you're interested in hardware development then I'd suggest taking a look at Chisel, the Rocket infastructure, and RISC-V. You get some software (Linux, GCC, glibc, binutils, newlib, Python) in addition to BSD-licensed RTL for a machine that is competitive with ARM's A5 core (on the same technology, we're a bit better DMIPS/MHz, energy/op, and area). The provided RTL boots a full Linux system, including L1/L2 caches, an MMU and a floating-point unit. We regularly synthesize for some fairly inexpensive FPGA boards (and with any luck a really cheap one will be up and running soon) and have taped out 10 chips on both 28nm and 45nm, which reach 1.5GHz.

The website <http://riscv.org/> has more info, including a cookbook-style introduction <http://riscv.org/getting-started.html> and a set of slides describing the system in more detail <http://riscv.org/tutorial-hpca2015.html>. We're holding our second workshop very soon, registration is free for academics but filling up quickly.

Resurrecting the SuperH architecture

speedster1 — Wed, 17 Jun 2015 07:36:44 +0000

> Other high-level HDLs include MyHDL http://www.myhdl.org/ (python-based).

Have you actually used MyHDL yet? It has been on my list of things to try out someday for a while now...

Awesome

glaubitz — Tue, 16 Jun 2015 13:43:55 +0000

As the currently only maintainer of Debian's sh4 port, all I can say is: AWESOME!

If any of the guys from the SuperH resurrection project reads this, please join our mailing list at:

> https://lists.debian.org/debian-superh/

Here's to hoping that this project will boost our efforts to get the GNU toolchain and the kernel back into shape for the SH architecture. There are currently some issues with wrong code generation in gcc and problems with ld when linking certain C++ code. But since I started my efforts, I managed to bring the port alive again :).

Adrian

OpenRISC

wookey — Tue, 16 Jun 2015 13:28:19 +0000

If anyone is interested in improving the state of this stuff from a distro point of view, we are running weekly CI to bootstrap debian on many arches, incluing or1k and sh4 (https://jenkins.debian.net/view/rebootstrap/)

sh4 gets a lot futher than or1k does right now, which isn't much of a surprise as a load of or1k toolchain stuff is not fully upstreamed yet (AIUI). No arch gets all the way to a bootable system yet - we still have more stuff to fix for that to be working usefully, but most of the infrastructure work is done. Just the work-work now (crossbuilding, bootstrap build profiles, multiarch dependency issues).

(yes we know sh4 is already bootstrapped many years ago, it's just an example of fixing this for the general case).

It's good to see interest in these free ISAs - I hope they prosper. Upstream your stuff so it's easy for us to build :-)

Resurrecting the SuperH architecture

robert_s — Sat, 13 Jun 2015 11:35:12 +0000

Other high-level HDLs include MyHDL http://www.myhdl.org/ (python-based).

Resurrecting the SuperH architecture

lsl — Fri, 12 Jun 2015 13:10:01 +0000

Are you aware of Chisel? Chisel programs generate hardware descriptions. It's a DSL implemented on top of Scala, developed at Berkeley.

The best thing is: it works. Today. Respectable projects were done with. The Rocket designs (implementations of the RISC-V ISA) are developed in Chisel. There are also a bunch of educational cores and tutorials to get you started.

https://chisel.eecs.berkeley.edu/

Existing backends are either spitting out C++ code (for simulation purposes) or synthesizable Verilog in FPGA or ASIC flavours. All code is FLOSS, of course.

SEGA Dreamcast

flussence — Thu, 11 Jun 2015 20:56:15 +0000

I wonder if this news is interesting to the console emulation crowd. The Saturn is the last of the 90's consoles that hasn't been completely preserved via software - partly because of the insane design, but I'd guess also because SuperH was relatively obscure and proprietary compared to the MIPS architecture everyone else went with at the time.

Compare to LM32

arnd — Thu, 11 Jun 2015 19:21:16 +0000

The Linux port for LM32 sadly never made it in, and while the code was basically ready for inclusion a few years ago, interest for MMU-less Linux ports has dropped dramatically in the past few years. We merged nios2 recently, but only support the MMU-based variants of that.

Interestingly, a MMU-less systems seem to have a small revival this year, with several ARMv7-M microprocessor lines getting added, and a return of the h8300 Linux port that was removed in 2013.

Compare to LM32

NickeZ — Thu, 11 Jun 2015 13:49:50 +0000

How does it compare to LM32 [1]?

[1]: http://www.ohwr.org/projects/lm32

OpenRISC

arnd — Thu, 11 Jun 2015 13:34:52 +0000

I think for new Linux deployments, you'd find a number of options that are fully open from the start (OpenRISC, RISC-V), explicitly freed by the original creator (SPARC), or have their patents expired (ARMv3, MIPS IV, PowerPC 1.x, i486, m68k, ...).

The main advantage of SH2 over those that is listed on the 0pf.org site seems to be the availability of non-Linux OSs for it.

Resurrecting the SuperH architecture

magnuson — Thu, 11 Jun 2015 13:14:14 +0000

In many ways the future is already here. People have been pitching C/C++ design for years and it's starting to get some legs. SystemC (which is just C++ with some special headers) has existed for a long time and had been used primarily for modeling but I think some tools will accept it as input for synthesis.

In my exposure high-level source works fine as long as you aren't trying to push the envelope on density, speed, or power consumption. The trouble is that this is almost always the case in at least one aspect. These tools will only improve though. There's a reason no one really codes in assembly anymore.

Functional programming and HDLs do seem like a natural fit. I'm very curious to see where that goes.

Resurrecting the SuperH architecture

ejr — Thu, 11 Jun 2015 13:08:59 +0000

On second thought, I should point out that tools to program FPGAs are highly non-free. Often gratis for smaller sizes, but definitely proprietary. sigh.

Resurrecting the SuperH architecture

ejr — Thu, 11 Jun 2015 13:07:13 +0000

Someone else already mentioned OpenRISC, but there also is RISC-V (http://riscv.org) with 32-, 64-, and 128-bit addressing support. I believe all the RISC-V variants have MMUs. Both OpenRISC and RISC-V exist for FPGAs as well as ASICs and have full Linux-based stacks, iirc. It's a great time for free processors across a wide range of application target areas. With FPGAs becoming more available at sane prices, people can play again.

SEGA Dreamcast

tshow — Thu, 11 Jun 2015 12:43:51 +0000

Sony's consoles are the PlayStation series. Sega was the main user of the SH-series chips in consoles, with the Saturn having (IIRC) three of them; two main SH-2 CPUs and an SH-1 CPU used as a drive controller (plus an M68K to run the sound system, if memory serves...).

Resurrecting the SuperH architecture

ncm — Thu, 11 Jun 2015 04:15:32 +0000

The future might actually be in a library in C++. The language is versatile enough that a "domain-specific language"-style library is practical. Code (i.e., complete hardware specification) in C++ driving such a library would look peculiar to a regular C++ coder; running the program would produce a detailed description of the hardware to implement the algorithms, rather than the usual approach of running the algorithms directly. The power the language brings to users would free them from the caprices (or just limited attention) of the HDL language priesthood, in the same way that C++ libraries freed numerics programmers from dependence on the tiny population of Fortran compiler loop optimizer engineers.

This is not a new idea. Abelson and Sussman exposed hardware description in Scheme to freshman students decades ago, in SICP, but the type system makes C++ a more powerful language for writing libraries than Scheme, providing the tools to manage projects of the size that modern silicon enables.

Code Density

deater — Thu, 11 Jun 2015 03:27:56 +0000

There has been further code density work since that 2009 paper, and SH3 is now beaten by a few others including THUMB and THUMB2.

http://www.deater.net/weave/vmwprod/asm/ll/ll.html

That's partly because I've spent more time on ARM platforms lately; I haven't had a reason to go back and re-optimize SH3.

Resurrecting the SuperH architecture

pabs — Thu, 11 Jun 2015 03:20:00 +0000

Some links to open CPU and FPGA related things are here:

https://wiki.debian.org/FPGA

Resurrecting the SuperH architecture

magnuson — Wed, 10 Jun 2015 22:34:15 +0000

A small nit that VHDL is itself an RTL language, just as Verilog is. I did find it interesting that they actually spent several slides justifying VHDL over Verilog with some rather questionable points. e.g. The human vs. computer readable thing for one where I can't even quite guess as what they meant.

Full disclosure I use Verilog primarily over VHDL for my day job since I find the latter excessively verbose. There is a lot of typing going on to do simple things, which may be part of the reason they've resorted to some 'meta-programming' techniques. That is writing programs in other languages to write VHDL for them.

The bit about typing is fair since they're very little of that in Verilog. Things have changed somewhat with the years as Verilog gained things like structs (it's the future!) but it's fairly ad hoc as languages 'designed' over numerous iterations spanning decades tend to be.

In any case I'm looking forward to them publishing some repos to look at. Maybe I'll find I like VHDL after all.

OpenRISC

ay — Wed, 10 Jun 2015 22:28:27 +0000

OpenRISC is used in a few weird places (like on-SoC power management controllers) and NXP bought a company that made ZigBee chips based on OpenRISC cores.

Running Linux without an MMU really makes you appreciate what you get with an MMU. There's something to be said for daemonizing, protected process space, etc. unless your application is very simple (and in that case maybe a small RTOS would have been better).