Dinghy index concept papers
Caterpillar draft
.
This sketches what the dinghy architecture could look like.
The paper Values Palette discusses design
values around which a computer system could be built.
In this design, we will pursue these,
The Bus Is The Computer
Pure Async
No FPGAs
We turn down some performance opportunities by avoiding FPGAs. But we
strengthen on trustworthyness.
What we end up with is a novel messaging-centric system design.
Message-centric system
Its novelty,
There is no universal memory map.
There is no general-purpose CPU.
Processing work is done on "Workhorse" cards that sit off the bus.
Here are the layers,
Bus: A bus containing a 68000 and some static ram. The chip is not
general-purpose. Rather, it is there to coordinate secure messaging
between bus members (cards). It will need some bootstrapping code,
which would seek and link a baseline set of cards.
Node: IO, workhorse chips, anything else. I will refer to these below
as {Cards}, because they fill a similar role to cards you would find
on an ISA bus or similar.
Bootstrap: A special type of node that gets things going at power-on.
Any time you want to do anything, you add a node card. Want to do keyboard
IO? There is a card for that. Network? There is a card for that.
Processing? There is a card for that. Storage? Card. Video? Card.
At system startup, bootstrap instructs the bus to set up the initial
communication channels. For example, allocate a workhorse, installing a
termina process on it, and setting up channels between keyboard, terminal
and video.
To start a process, you allocate a workhorse card, tell it to reset,
stream code into it, then tell it to start. You can control its
permissions by whitelisting the types of messaging it is allowed to do at
launch.
If you had a game with malware, it would be difficult for it to do any
damage, because it has no contact with the outside world, nor with other
processes.
To make this platform successful, we will need to get the subtleties right
in the way we design the messaging architecture. Having done that, it will
be possible to reason about the operation of the system through a focus on
messages passing between nodes.
It should be straightforward to create a lightweight, single-process
operating system that would run in the bootstrap node, with a purely async
system interface to the bus.
Bus design
Current idea is that 68000 would make a strong foundation,
Memory addressing. It has a 32-bit memory bus, giving room to scale up.
Decently fast. We know that amigas and ataris ran well on this.
Modern coldfire processors go up to 300MHz. Are they similar enough to
68k chips?
It would be wire-wrap-able,
See https://news.ycombinator.com/item?id=10121758
A challenge: it is not clear that you can reliably source 68k chips. Some
places are selling them, but we don't know of anyone producing them. (If
you know more, please let us know on #dinghy.)
Node design
The only fixed design of the node will be its interface to the messaging
bus.
The initial node could be as simple as the computer demonstrated in this
video,
https://www.youtube.com/watch?v=nFIviiwPrLI
Async interaction
An earlier edit of this page posed this problem, "Problem: how to allow
seamless interaction between a core and a card running at a different
clock speed?"
Dave Park has given detailed feedback to this,
"From 000 up to 030, the 68K bus design is 100% asynchronous and speed
differences and bus width differences are very easy to accommodate.
From 040 up dynamic bus sizing goes away, and the bus becomes
synchronous, which results in 3x higher instructions per clock.
So if raw throughput isn't the highest priority, any pre-040 IC is
great."
He also has some advice about mental modeling of coldfire kit,
"If you like multiple busses including serial links like SPI/I2C, the
Dragonball CPUs run at 33 or 66MHz, have a pure 68000 core, and also
have a lot of accessories on die like UARTs, GPIO, etc.
The early Coldfire chips are fully 68K compatible, and are basically
super Dragonballs.
Coldfire V2 and onwards broke compatibility enough to be no fun.
I replied,
"That sounds quite valuable, and I can see why embedded people would
jump at it. For the dinghy project, I was really hoping to make the
system discoverable, and too much SoC gets in the way of that."
He corrected,
"Aye, but the upside is that on the Dragonballs, that is HIGHLY
configurabe, can be enirely unplugged, and is mapped HIGH in the
memory map so it is out of the way of the very desirable "large,
continuous area of flat memory" that is desirable for simple tasks."
..
"there are millions in the chain. I just bought 1,000 dragonballs last
week, new in tray. $2.25 each."
"The 33MHz ones are LQFP so easy to work with. The 66MHz ones are BGA,
so I have to fire up the pick and place machine to play with those."
He also responded to my inquiry about chip robustness,
"68SEC000s are used in cubesats with some regularity."
"The cores that are fully static are also very small. They're not
hardened as such, but they're tolerant of radiation enough that if
you're still alive they're still working."
(thanks)
Iteration Platform
Something I like about this approach is that you can start small, and then
iterate up.
Further thoughts
This design may suffer from poor IO latency. For example, video display.
Novel approaches may allow a path past this. For example, colocating a
workhorse cpu and Video Member, and then having a hardware compositor that
converts several signals into a single VGA output. In this way, you could
have a simple windowing system equivalent to workbench 1.3.