One Page Computing

Welcome to December - 31 days of leisure and struggling to find a challenging brain-expanding task.

This is an overspill from the anycpu.org site, One Page Computing, OPC, and a challenge for anyone who wants to hack with minimal hardware.

The smallest Lattice ICE40 FPGA device has just 384 Logic Elements and costs about $1.20

https://www.mouser.co.uk/datasheet/2/225/FPGA-DS-02029-3-5-iCE40-LP-HX-Family-Data-Sheet-1022803.pdf

The challenge is simple - devise a CPU that fits into 384 logic elements and communicates with serial memory.

Bit serial architecture will save a lot on logic - but with only 384 LE’s what architecture offers the best bang for buck?

5 Likes

I want a prgramable device with 5 volt I/O, a PLCC package and
Open source programming. I want to connect it my way, not fight
the software to fit things in. I have really bad luck with routing and race
conditions, some times it works and some times you need to wait a day or too for the version of software I have. Upgrading is not a option,
Also I like using AHDL, other wise I have to use ( rather rude view of) VHDL or VERLOG. Why not a real RTL languge, they had them with
puch cards.

The classic simple FPGA cpu, MPROZ.
http://www.unibwm.de/ikomi/pub/mproz/mproz_e.pdf

2 Likes

Aim at staying compatible with the small chip but start on the chapest halfway compatible iCE40 dev board one easily can find?

For getting started without needing to solder SMDs, the UpDuino seems the $-shortcut, but they are a lot “bigger” than the smallest iCE40.

…or do breakout boards for that small iCE40 sibling exist?

The goal is 384 LE’s, not really what you use. I got a spare
DE0 floating around, and might use that. Serial memory internal or external.
Does the LE’s used include I/O logic for devices?

I’ve a feeling @Revaldinho was thinking about bit-serial machines, to fit on a CPLD. But it was only at the thinking stage.

The LGP-30 might well be a good basis for a design:

Or perhaps the Bendix G-15:

Here are a couple of resources for dev boards:


When I think of open source FPGA , I mean bit fiddling at the bit stream level, or something like Niklaus Wirth’s Lola. Ben.

The icestorm open source tooling for Lattice is pretty good. It takes in HDL and outputs bitstreams, which is pretty much what’s needed.

1 Like

The ICE40 series of FPGAs has been widely adopted by the hobbyist market as a result of its low cost and open source toolchain.

Here’s an “8K LUT” hobbyist board I found for under $30

And here’s a ICE40 LP384 board from Silicon Frog

@EdS,

I have been reading up on the LGP-30 and it’s cheaper, transistorised brother the LGP-21.

The instruction set is very reminiscent iof EDSAC, single upper-case character instructions, with a strong mnemonic value.

The LGP-30 was clearly designed around the quirks and limitations of the magnetic drum memory - an approach which is commonplace with every machine design - designed around the requirements of the memory sub-system.

However, by all accounts it was an awkward machine to program as a result of having to optimise the program to the motion of the drum.

It might be an inspiration for a bit serial design, but simplified to use conventional serial SPI memory.

1 Like

Which RAM are you aiming at?
Something like the 8Mbyte PSRAM seen in the ESP32ers?

It could be any of the industry standard 8-pin SPI memories. Flash, RAM or FRAM.

These serial memories share a common pin-out and a common set of commands.

I like FRAM, because of its non-volatility, and I was proposing using an Arduino initially as the serial programming interface for this minimal machine.

Yipyip… basically only differ in the address length depending on the capacity.

FRAM needs (an internal) rewrite after read.
IIRC MRAM doen’t have this drawback.

The internal rewrite of FRAM is hidden from the User

(Highly parenthetical, but I’m reminded of Shane Gough’s TGL-6502, which uses an 8-pin ARM chip to emulate a 6502. So, in this case, perhaps the awkward to program drum machines could run an emulator of a more regular machine.)

(Edit: I now realise this is also the approach taken by the Gigatron)

Yip… but doesn’t it wear off the RAM any more? Was that only a thing with the earliest FRAMs?

I read that the characterisation has not shown any finite life. The lifetimes are ‘at least’ and not ‘on average’ and they haven’t seen failures. (Please correct me if I’m wrong about this.)

AFAICT there’s no reason to avoid FRAM on the basis of lifetime.

Still read the fine print for writes Core memory (1970) is about 10^10 cycles read/write
an hour.(.75us). Modern machines do that in a second.
The nonvoiltile memory was to hold
small ROM programs or tables or be safe from a power fail
or distruction of the universe. The fact that many machines of
that era saved a subroutine address at the start of subroutine
prevented rom being used had been avaible.
Since my TTL computer design saves the return address @ sp + 0
I plan to use EEPROM’s for a 4K BIOS at the top end of memory.
(IO is at the very top). I still can patch the bios if need be later.
FRAM would be nice but not needed.

Wikipedia still mentions it.

Maybe its life time is ™pretty-much-long-enough-for-everything™ but I get a bad feeling for wear out on read and so I avoided them up to now.

I got a free “FRAM for Dummies” from Texas Instruments a few years ago, and as I recall the booklet said that wearing out the FRAM was the one thing you didn’t have to worry about. I’ll have to go to the man cave to see if I can dig out the booklet again.