Yeah it’s admittedly gonna be more of a trainwreck than I intended for the next couple months, but I intend on sorting everything into a new, more organized thread once I’ve got the design settled into a platform I can actually do some sustainable development on. Until then, I’d just consider this thread more of a brainstorming dump as interesting things come up. Not the sort of thing that’s a great fit for Devember but I figured someone might find it entertaining haha
Another interesting piece of information: the 1SBL, or 1st Stage BootLoader, or so I’m calling it:
sample.txt (8.6 KB)
In English, this is what it’s doing:
- Clear core registers.
- Check for the DIAG_BOOT flag, taken from an onboard jumper. If set, immediately jump to the DIAG_BOOT subroutine (not implemented yet) where the 2SBL/‘BIOS’ I2C interface can be controlled directly by the root serial port, allowing for that EEPROM to be written/read over serial.
- If not, start reading from the 2SBL EEPROM at address 4095 (4K words) and transfer each word to the same address in main system memory. More simply, mirror the BIOS into memory.
- Decrement the address and repeat until reached address 0.
- Reboot into main memory with the BOOTMODE = 0 instruction. The 2SBL payload which was loaded into memory will now execute.
Or,
{CORE RESETS INTO MEMORY REGION = 0b01, 1SBL BOOT ROM.}
{INITIALIZE ALL CORE REGISTERS TO ZERO.}
IF (STATUS.DIAG_BOOT = 1)
{ENTER DIAGNOSTIC BOOT MODE UNTIL RESET.}
ELSE
FOR (I = 4095; I >= 0; I--)
$R.1 = MEMORY(REGION = 0b10 (LPB Bus), DEVADDR = 0x03 (2SBL), ADDR = I);
MEMORY(REGION = 0b00 (Main Memory), ADDR = I) = $R.1;
END FOR;
REBOOT, REGION = 0b00 (Main Memory).
END IF;
It’s formatted that way because it’s basically VHDL syntax - I can just drop that into a .vhd file and it will synthesize.
Writing machine code by hand also makes you realize things that need adjusted:
- Replaced LIT.H and LIT.L targets with a single 2-cycle instruction to do a full width load of the immediately following 16-bit word into LIT.Y.
- Add BRANCH.N0 (Branch if non-zero)
Here’s some sauce for anyone with the willpower to read a wall of someone else’s HDL:
execution_core.txt (35.5 KB)
interrupt_controller.txt (8.7 KB)
memory_interface.txt (22.4 KB)
There are several dozen more source files (27 right now and counting) for things like all the bus devices, clock/reset management, I/O buffers, etc. I suspect nobody cares about the eight bytes of ROM that’s just the CPUID and revision hanging off the system bus.
Looking at the project. I see many domains of knowledge: board design, electronics, processor theory.
Out of interest, If I’ve never worked with HDL or fpga, how long did it take to learn the skills to take on a project like this?
3 Likes
Just saw Wendell discuss the Devember entries. This is super cool and Kudos for the entry. Maybe you can get this slapped on opencores.org ?
Been sidetracked by finishing a bathroom remodel, but I’m doing a huge update to get everything compiled into an actually readable blob of information - work on the project is picking back up now, so more to follow. I’m going to link an entirely new thread with everything nicely laid out and let this one die once that happens.
To anyone wondering what happened to the Dev Log that Wendell mentioned, the site is parked right now since I ran out of Linode credit, but I’m putting together a small system right now (it’s… well, it’s a cash register running Arch) to host it under my own power for anyone interested in it.
Hmm… I could, I’ll have to look into it. I didn’t really think of that one. 
I’ll definitely want to get a v1.0 of the architecture finalized and tested in hardware first with A) an actual memory management unit, and B) a formalized system bus interface, so that the core itself can evolve without completely obsoleting the entire rest of the system. It’s very much in a proof-of-concept state right now, which the good part is that I think it’s going great, it just has a long way to go before it’s at that point.
I hope to make that happen within the near future so that next Devember’s project can be writing an assembler and then compiler for this monstrosity. 
1 Like
Thanks for the update! I did wonder what had happened to the website so looking forward to something being put up again. I also ran fowl of FPGA’s going bye-bye at some point last year. Mouser is sitting on about $400 of my cash for some Intel/Altera parts that were slated for a software defined radio. Ticket still says delivery unknown and they’re not taking new orders 
Oh well. Keep up the good work!
Yep, it’s all
Hahaha yeah, good luck with that one.
Another big hold-up has been this:
I only had two Altera Flex III FPGAs. But, I’ve found and bought a NOS case of Xilinx XC3000A-series FPGAs. These are between 3000 and 5000 gates, and around 300 registers/bits per FPGA. I think they were released sometime around 1996 nope, 1992, based on the original XC3000 from 1988. I’m planning on actually using them.
It’s been a nightmare to just track down the last software to support these, and then to get it running on literally anything. I seem to have it working as designed on Windows 2000, which is surprising given that it’s a native DOS program with support for Win95 at max. For anyone interested, it’s Xilinx Foundation, versions up to 2.1i. Any version of Foundation 2.1i use a software license key… XACTStep (only supports DOS/Win3.1) supports the XC3000A, but only with a hardware license dongle which simply no longer exists.
It’ll take ten of these things instead of one modern gate array to get the whole thing working, but I think it’s going to work, and I’ve got so many (and they’re just socketed, and configure from an external EEPROM) that quantity is kinda moot.
2 Likes
Here’s an option. Look up Altera MAX UP2 edu kit on eBay. They are super reasonably priced and have a pretty darn large FPGA and CPLD on it. I have half a dozen of these boards.
Kudos getting the ancient Xilinx tools working 
Wait. I just looked on eBay and the boards have gone up in price by a factor of 5. Yikes. I shoulda known!
Yep, there’s problem #2 hahaha
https://www.mouser.com/ProductDetail/Lattice/LCMXO2-7000HE-B-EVN?qs=DBbQ3l7BldNJuSVNFnSpPw%3D%3D
These are awesome. They used to be like $30, now they’re $90. I really like Lattice parts, but they’re just nonexistent right now.
Same here, I think like $35, and now they’re $75.
I actually really like these ancient little FPGAs. They just need something that resembles +5V, and configure from anything that even remotely functions as an 8-bit parallel storage device… the tsetup requirement is two thousand nanoseconds. You can even chain an arbitrary number of them together and they will configure each other as long as the configuration ROM has enough storage. The logic is just… smol.
Xilinx Foundation 1.5 (what I have) does technically support VHDL and ABEL (Hah, remember that one? 'Cause I don’t, it predates me), but the best way to build a design is realistically just to use the schematic entry tools. And man, does it feel unnatural when I’ve used VHDL for my entire professional career.
1 Like
Getting the project back on track, big update coming Soon™ - have been learning about hosting a wiki on MediaWiki to present all of the information being generated by the project in a searchable manner, and I think it’s turning out pretty well.
It’s looking pretty good, but I need to do some more work on the general content and then getting it securely internet-facing before it’s ready for showtime. Wiki setup/configuration be interesting content for some of Wendell’s ‘Preserving Knowledge’ threads, too.
just make sure you get a secure wiki version.
FWIW for documentation and searchability I prefer UDO
https://man.udo-open-source.org/en/cmd_code_source.htm
https://www.udo-open-source.org/
Looking forward to the new thread and website. Luckily there is enough material in this thread to satiate the apitite in the meantime.
Glad you are still pushing ahead, even against the tide “unobtainium” and “gougepocket”.
Cheers
Paul