Are RISC OS folk meanies or just poor?

Is that 100MHz ARM operation, or running the FPGA itself at 100MHz?

Both (you may feed in a different clock on a pin, but you can multiply it up to whatever your design can handle).

The guys who were paid to write the all-singing all dancing OS created something hideously unweildly in a now-dead language. Arthur was “plan B”.

I just looked up ARX on Wikipedia. That page needs an editor, stat:

According to the project Application Manager during the project, while Acorn was developing the kernel, it used C and Acorn Modula Execution Library (CAMEL) in Acorn Extended Modula-2 (AEM2) compiler (ported from Modula-2 ETH using Econet hardware), though never released externally, CAMEL was ported to use it in SUN Unix machines, in an effort to port Sun’s workstations Sun NeWS to the Archimedes, and after Olivetti bought out Acorn, developed a compiler based on AEM2 for the Modula-3 programming Language.

Oh my god! “something hideously unweildly in a now-dead language” describes that entire paragraph!

Duplicating an ARM2 or ARM3 isn’t a great idea, because you’re tied into the 3-pipeline-stage, no/limited-cache model. 68K is even worse.

Amber Core only implements the ARMv2 ISA. One version of the implementation is 5 stage pipeline, and can achieve greater than 1 instruction per cycle.

You could however implement an ARMv2 or ARMv3 core (which I think are now out of patent) using a better microarchitecture and get a much higher clock rate. You might need to relax a few things (eg exact exception behaviour) which might need some OS-level changes, and you might end up implementing a few newer instructions (carefully avoiding the patents) like synchronisation barriers, but those should be relatively minor.

Amber is already a bit better micro arch than the ARMv2/v3. At least in the five stage pipeline implementation.

On current FPGAs 100MHz is doable, 200MHz with some careful design. Next-gen FPGAs (Stratix 10 etc) might push that towards 400MHz, but those aren’t likely to be affordable any time soon.

And even at 100MHz and a well thought out archetechure, espeically if some limited simple superscalar abiltiy is designed in, it would be at least as fast as a good RISC PC.

@Theo Markettos:

This is a non-starter for numerous reasons:

Amber Core is designed around the ARM2 microarchitecture, which not optimised for small process nodes. A similar device today would be the Cortex M0 – also three pipeline stages. ASIC implementations of that go up to about 100MHz (I’m not sure what process node that comes from – the M0 exists in 180/90/40nm)

The Amber Core is available in a 5 stage pipeline version, and quite a bit better than the original ARMv2, different microarchitecture, just shares the ISA.

I am aware of the slower devices in the 180nm to 90nm process range. Though remember that there are also 1GHz CPU’s in the 180nm (or was it 90nm) process (I would have to go back to my notes to quote exactly which ones, maybe later).

To make it cheaper, you need volume – insane volume. Costs for an SoC in 7nm is circa $300m.

I do not think anyone is going for that kind of process, at least not at the lower volume count. There are a few services that will make a run of 90nm ASIC’s for an average cost of $50USD per unit, with a minum of 100 units at that price point (that would be $5000 US for the run), and that includes the package.

A sweet spot for cost per transistor is about 28nm. Looking at pricing for a prototype run for GloFo 28nm it’s EUR10200 per mm2, minimum 9mm2, price EUR91800. That gets you 50 chips, and then you need to pay for packaging on top. Full design cost for a production SoC in 28nm might be something like $30m

You are still looking at the higher end tech. As stated above there are services with lower costs and smaller runs, mostly targeted at high end hobbiests.

Also I had already said that it would require someone that has enough of a comercial interest to make it worth there money.

Cheap ASICs (350/180/130nm) will get you somewhere in between – more like ARM6 performance.

As there have been much higher performanc CPU’s implemented in 180nm, I would say that the cheap is the way to go. I think if the design is optimized correctly it would be possible to get quite a bit more performance than you would expect from a 180nm process with a 5 stage Amber Core type of implementation.

Did I mention the design tools can cost a million pounds a seat, and you need specialists to drive them?

The design tools are not as limited as you may think. There are a few hobby ASIC services that will produce a 180nm process ASIC from an HDL that will work on FPGA (usually they will tell you which FPGA’s to test on, so that you can make sure to fall within there limits). I am going to have to look up this information again, so that I can pass it back here.

As well as fab costs you need to spend a lot of money on verification, because it would be rather unfortunate if your multimillion-dollar production run didn’t work.

Again who said anything about a multi million dollar production run. I would say that a five-thousand dollar run would be enough to get started, can do larger runs later to reduce cost per unit. The cheap ASIC’s are all that is needed, at least to get started.

Basically if you’re going down the ASIC route you need something that looks like a Cortex A, and I’m sure ARM would sell you a licence for one of those. But you’d need a few million dollars to begin with.

So why are you so apposed to 180nm, a process that can produce reasonably high enough end products. Or is it that you have a grudge against the hobbiest ASIC vendors?

Two examples of 180nm CPU’s that run at greater than 1GHz:
PowerPC 7445
Athlon Thunderbird

We really have not gained any clock speed since the 90nm days. The only reason that CISC CPU’s are getting better performance out of the newer processes is that they can fit more transisters on the die with short path lengths. This allows them to use dirty tricks to decode the Complesx instructions, as well as to implement out of order execution with an instruction set that is not well suited to pipelining or out of order execution. Then there is the space used by the cache. Not to mention fitting more cores on the die.

With the ARMv2 ISA we could easily have space for implementing good out of order execution (at least in a limited way), large 16 way L1 cache (in the order of 32KB or 512 cache lines), and even add a few instructions for things like atomic syncronization, and still have most of the die space left over for other components (like the PMMU, a simple GPU tuned for RISC OS, the most important I/O controllers [IIC, SPI, Floppy, PS/2-KB, PS/2 Mouse, parallel GPIO, etc], and a memory controller)

So why are you so apposed to 180nm, a process that can produce reasonably high enough end products. Or is it that you have a grudge against the hobbiest ASIC vendors?

Because the demand was for something better than you can buy today. A Raspberry Pi BCM2835 is 40nm, so is a lot faster than anything on 180nm (a lot more cache per mm2 for starters – chips like Athlon were enormous). Why would you do a $20K small-batch production run with say $50K of NRE (packaging, boards, assembly, IP macros for I/O) when you could just buy one of the millions of used Raspberry Pis out there for circa $20?

Because the demand was for something better than you can buy today. A Raspberry Pi BCM2835 is 40nm, so is a lot faster than anything on 180nm (a lot more cache per mm2 for starters – chips like Athlon were enormous). Why would you do a $20K small-batch production run with say $50K of NRE (packaging, boards, assembly, IP macros for I/O) when you could just buy one of the millions of used Raspberry Pis out there for circa $20?

To quite myself, in regards to 180nm process (could do better with a 90nm, or even just a 130nm):

With the ARMv2 ISA we could easily have space for implementing good out of order execution (at least in a limited way), large 16 way L1 cache (in the order of 32KB or 512 cache lines), and even add a few instructions for things like atomic syncronization, and still have most of the die space left over for other components (like the PMMU, a simple GPU tuned for RISC OS, the most important I/O controllers [IIC, SPI, Floppy, PS/2-KB, PS/2 Mouse, parallel GPIO, etc], and a memory controller)

And add to that the fact that we are starting with a five stage pipeline design, before any modification to add performence.

Also not sure how you are calculating $50K for 100 units, with $5K for the 100 ASIC’s of the SoC, and using only open HW designs I think your mark is a little high. Even with the RDAC’s (for VGA and Sound) capacitors, voltage regulators, power distribution, and connectors on a small board you are shooting way high.

So you believe that a $25 BCM2835 will outperform that, running RISC OS?

Remember that most of the die on the BCM2835 is VideoCoreIV, not ARM. That said there is a reason that they need so many transistors, in such a tight space, and it has nothing to do with ARM.

So you believe that a $25 BCM2835 will outperform that, running RISC OS?

Yes, substantially. What you have outlined is roughly a 1987 Archimedes in terms of functionality. The Raspberry Pi 1 is more or less a 2007 smartphone, and the Raspberry Pi 3 is a 2013 smartphone.

Questions:

• How much cache did you expect to provide in an acceptable transistor budget in 180nm? As a ballpark, a random paper I found cites 14 to 59 square microns per bit. For comparison, Pi1 has 1Mbit of cache.
• What off-chip memory technology are you planning to use? In 180nm you’re likely limited to SDRAM or DDR1. Those don’t come in large chips – say 128MB of 133MHz SDRAM?
• What about USB, networking, storage? The IP for those is large (in terms of area) and expensive (there are some open source cores, but nothing of quality that I’ve seen – the verification is the tricky bit). The PHYs are also not qualified for large process nodes. You might just about get USB 2.0 in 180nm, but you won’t get gigabit anything (so no SATA or PCIe). SD card should be OK, and ethernet can be an external chip like the Pi.
• If you don’t want USB, can you even buy PS/2 mice today? It also rules out external mass storage
• What about display? If you want to drive HDMI, you need gigabit signals again. You could add an external chip but that costs. VGA ports are a dying breed.

Again, it’s a lot of trouble to reproduce something worse than what you can buy today for pocket change.

This is a topic that I have been doing a lot of research into ever since 2012 .

I am glad to share what I have figured out. Some of it has required consulting people that deal with HW implementation a lot more than me (I just tinker personaly).

Yes, substantially. What you have outlined is roughly a 1987 Archimedes in terms of functionality. The Raspberry Pi 1 is more or less a 2007 smartphone, and the Raspberry Pi 3 is a 2013 smartphone.

That is interesting view. The ARMv6 does not quite reach 1 instruction per cycle. For integer operations (which is the side we are talking about here) that are not SIMD the Amber Core implemented with a five stage pipeline can achive a fairly consistant 1 instruction per clock.

Also it should be possible to evolve the design to be superscalar, allowing multiple instructions per clock, with well written code it could average greater than 2 instructions per clock with a simple dumb implementation of a superscalar pipeline, and a minimal of redundant execution components.

What advantage does the ARMv6 have over that again?

How much cache did you expect to provide in an acceptable transistor budget in 180nm? As a ballpark, a random paper I found cites 14 to 59 square microns per bit. For comparison, Pi1 has 1Mbit of cache.

Fair point. Though I seriously doubt that the BCM2835 has 1MB of L1 cache (L2 cache is a different beast). Also the ARMv6 in the BCM2835 uses a harvard architechure cahce, which has its advantages in fetching data and instructions at the same time, though is not needed to go superscalar, though a wider data bus would be needed.

What off-chip memory technology are you planning to use? In 180nm you’re likely limited to SDRAM or DDR1. Those don’t come in large chips – say 128MB of 133MHz SDRAM?

HUH. It is possible to drive faster DDR than that with simple MCU’s (ok at a lower speed). I do not see your logic there, take a look at the data sheets for the RAM that is available today. While we would likely not be up to the latest, we can do better than that.

The process does not limit the off chip RAM used, the limit is non-existant.

Could you explain why you think that the process would provide such a limit, it does not take much to implement a memory controller for most modern forms of DDR, just looking at the data sheets I have on hand I can not see why you think this limit might exist.

What about USB, networking, storage? The IP for those is large (in terms of area) and expensive (there are some open source cores, but nothing of quality that I’ve seen – the verification is the tricky bit). The PHYs are also not qualified for large process nodes. You might just about get USB 2.0 in 180nm, but you won’t get gigabit anything (so no SATA or PCIe). SD card should be OK, and ethernet can be an external chip like the Pi.

USB is one that I do not see the need to have on the SoC, yes it would take a good bit to implement on die, though move it off die and make it optional. It is not that important on a Desktop OS computer. Then one of the MCU IIC or SPI to USB interface IC’s could be used if wanted, yes they are limited, though they would be able to provide an interface for the devices that make good sence for USB.

Storage is a good point, as the modern interfaces provide some challenges. I would just implement a PATA interface for using CF cards and Optical drives, and an SPI controller for Bootloader ROM and SD Cards. PATA takes very little, SPI takes very little (though a little more than PATA).

For some devices it may be worth implementing a IIC controller as well, as that would extend the range of possible devices. Including some Ethernet controllers that can be off die (and do not cost much at all, like the WizNet devices).

Actually I would say to use 2 IIC and SPI controllers, to extend the number of possible devices on expansions boards.

If you don’t want USB, can you even buy PS/2 mice today? It also rules out external mass storage

Yes you can purchase new PS/2 devices all day long. Actually the Keyboard and mouse I am using to type this have a controller that will go into PS/2 mode when plugged in to a PS/2 port through an adaptor. This is actully more common than most people know. I am using them in USB mode at this time, as I am on a Raspberry Pi B+.

How do you figure that it rules out external mass storage? CF Cards, SD Cards, CD’s & DVD’s (if you hook up a DVD/CD-ROM/RW drive to the PATA). These seem to be external mass storage to me, not to mention that you could hook up a PATA HDD (not really so external, though still off board).

What about display? If you want to drive HDMI, you need gigabit signals again. You could add an external chip but that costs. VGA ports are a dying breed.

I have not yet seen a newer TV (year 2008 or newer) that does not have at least one VGA if it does have HDMI/DVI (and I do look every time I go to a store that sells TV’s). Ok it is getting difficult to find a VGA stand alone monitor. More older TV’s did not have VGA.

So all that is needed is an RDAC externally, and some form of simple video banger at minimal to drive it. Though I would go with a simple GPU, as there would be the space for a simple fixed point GPU with a simplified graphics pipeline.

It is true that it would be difficult to drive an HDMI device, though it is definitely possible to do in 180nm, and a bit easier in 90nm, remember that that was the technology many of the early HDMI devices were implemented in.

Again, it’s a lot of trouble to reproduce something worse than what you can buy today for pocket change.

So your definition of worse is:
Greater potential per core per clock processing power (for non SIMD integer operations), smaller space usage, potentially equal clock speed, more versitile, and using better interfacing tech (way better than USB).

Also remember that the VideoCoreIV GPU is of little use to us, what we use it for (a couple games, some very minimal other stuff) could be easily implemented in a more minimal GPU, that better targets the OS. And the Fixed Point GPU could double as a cooprocessor for floating point math within the fixed point precision limits (so there would be some loss of precision).

And there would likely still be enough space on a reasonably small SoC to implement a true FPU (though not SIMD, and not having the trig functions).

Also it would have the advantage of being able to implement a low end version in an FPGA, for testing, or just to play with a slower computer for whatever reason it may be of use to you.

So you can make all of these compromises, but unless you have $10K to spend on a hobby project and you’re going to do it just for fun (and a year or two of your time is free), who is going to buy this?

Greater potential per core per clock processing power (for non SIMD integer operations), smaller space usage, potentially equal clock speed, more versitile, and using better interfacing tech (way better than USB).

Can you point to me any SoC that’s achieving these things in an affordable technology? For example, SiFive’s Freedom E310 is 130nm, and is basically microcontroller class. Their Freedom U540 has an MMU and able to boot Linux (roughly equivalent to what RISC OS needs), but that’s 28nm.

@Theo Markettos:
SoC no, most SoC’s are using newer tech, because they are implementing insane things that are not really of benifit.

CPU that has much higher transister count and much higher performanc, yes I could point you that direction.

Any as this is off topic I started a new thread in the Aldershot section about this.

Also, the microcontrollers are Thumb – they don’t include the 32 bit ARM instruction set. So as well as lacking an MMU, you’re going to have to translate the assembler parts to a different instruction set.

Don’t forget the initial question: what will happen when ARM SoC will all be 64-bit only?
I bet we’ll have solutions to use in the microcontroller market.

I don’t. You’re forgetting three things:

No. I said ‘slowly’

Don’t forget the initial question: what will happen when ARM SoC will all be 64-bit only?
I bet the microcontroller market will have evolved too.

Amber Core is designed around the ARM2 microarchitecture

No. ARMv2 instruction set, not covered by patents.

And even at 100MHz and a well thought out archetechure

Today.

While Amber Core is nice, with current FPGA technology it is just too slow to be a meaningful alternative for SoCs.

Today.

Why would you do a $20K small-batch production run with say $50K of NRE (packaging, boards, assembly, IP macros for I/O) when you could just buy one of the millions of used Raspberry Pis out there for circa $20?

Don’t forget the initial question: what will happen when ARM SoC will all be 64-bit only?
I bet that when it’ll be the case, a super ARMv3 Asic will be one the possibilities.

So my global answer is unchanged: ARM64 only movement is not a reality today and not a threat for tomorrow.

As Jeffrey once put it: nobody wants to tackle the hard things. I have to agree with that.

The problem is that all people with the required knowledge to work on such things is already here at work.
IMHO, it’s not a nobody problem, but a no one problem.

That’s why I suggest work on low end computers (SoC, µC or Amber): to attract the retro community.

To the original topic of this thread:
I can only speak for myself, though with the current world health situation I imagine that many others are in a similar situation.

I am a lot poorer than before, and I was pretty poor before. I keep hoping to have enough money to buy a new DDE, donate to each bounty, and get up to date dead tree editions of the manuals. That is not going to happen any time soon, espeically with the COVID restrictions beings as I live in a medical facility.

@ DavidS

I keep hoping to have enough money to buy a new DDE

Quick reminders:

• If you need it to compile BBC BASIC apps with ABC I believe there was a free offer of a cut-down version of DDE.
• If you have a recent recent enough version you could email ROOL with your DEV code to get a discount for a new release

Not sure if this can help you, but I think it worth mentioning it, good luck in any case :)

I already had a BBC BASIC only version, lost along with everything else. So it would be wrong for me to ask the other David for another copy, better to get more people into it than using up the licenses he paid for.

The most recent version of the whole DDE I had was from 2013, and I have also lost the DEV code as I lost all of my passwords to E-Mail etc. I am glad I managed to remember the password here.

I already had a BBC BASIC only version, lost along with everything else. So it would be wrong for me to ask the other David for another copy, better to get more people into it than using up the licenses he paid for.

Just send me your old and new email, then I’ll update my database and send you a copy of the archive.

Just send me your old and new email, then I’ll update my database and send you a copy of the archive.

I have not found a new E-Mail service yet. Once I do, as I have lost all my passwords from the past and have no telephone. Unfortunately that makes finding an E-Mail service difficult. I will be getting ahold of you to reset my other account so I can update things.