No way of knowing until it's tried. There must also be a number of FPGA and CPLD architectures which have expired patents now so that will help.
There's
OpenFPGA ongoing, and they do have
some integration for Skywater. The mention of the Synopsys IC Compiler II pretty much kills the idea any hobbyist wanting to have a good look at SOFA (the license costs more than a decent house, and that's yearly; licenses costs are one of - if not the - most expensive part of designing a modern chip). Open-source tools are progressing, but for a decent result that could be considered for production, they still years away. But someday we might get there...
I do not know of any projects trying to recreate CPLDs instead of FPGA. They are simpler, so should be easier to do. They're also not very ineresting to hardware developers I guess :-/ Maybe it could be a university project of some sort? Rather than students doing yet another RISC-V implementation...
And for now, the "free" stuff (paid for by google) requires to be integrated in an existing framework that probably doesn't mesh well with the concept of a simple CPLD.
- A general-purpose PDS card interface which provides decoding for flash; an MCU interface (both 3v3 ARM Cortex and Arduino) at the very least.
I'm not sure that makes much sense to create such a complex ASIC, 7-series XIlinx FPGA and CB3T level shifters are much more versatile (other FPGA-based solutions exist and would likely work, but those are the ones I know), and should be less expensive than a dedicated ASIC for the foreseeable future. You needed Apple's volume in the 80s to justify NuBus-dedicated chips.
Right now the gataware I have in the *FPGA enable connecting a Mac bus ('030, '040, NuBus) to any "
Wishbone" memory-mapped device inside the FPGA. The primary issue for anything outside the FPGA is the number of I/O pins required. I'm stuck with whatever pins are broken out on the FPGA board.
- Built on (1): Classic Macduino, a simple I/O interface that allows direct access to an Arduino's I/O space, so that it's possible to port Arduino sketches to a Classic Mac as drivers (...)
I'm not sure how feasible that would be. MacOS is a really old OS, the driver model is all but non-existant except for a handful of devices. If you mean inside a custom application, then that's probably a bit easier - MacOS doesn't stop you to go and poke at the hardware directly... do you have an example of what you'd like to achieve in terms of devices?
- An encryption Co-processor
Hehe,
been there, done that. Not a very fast idea, it turns out :-/
More seriously, encryption can implemented in hardware at basically two level:
(a) instructions to speed up the process
(b) custom block that handle most of the process by itself
Most modern processor have (a). That's what my RD68891 does, add AES encryption instructions using the MC68030 co-processor support. Unfortunately, it raises some interesting points:
* the coprocessor interface relies on the bus heavily, and adds a lot of overheads
* the more state you can keep in the coprocessor, the less bus activity and overheads you get
* you can't keep state in the coprocessor unless you have some way to save/restore it on context switch... which obviously MacOS won't do for you
So the 'single register' version of the code on the RD68891 (where an instruction atomically update a register without any resident state in the copro) is not that much faster than an optimized table-based SW implemenation, while anything faster will have some 'state' (if only the keys) and that causes trouble on the software side. I don't have Ethernet in my IIsi so I haven't looked at how it could be integrated in a SSH implementation. Also, it's likely the key exchange is the primary issue (time to establish a connection) and that's a different algorithm. Accelerating AES would only help during an esyablished connection.
For (b), it's basically the same but with a massive state kept inside the encryption block, as it does things on its own.So you need a lot of software to handle that state, and probably a modern OS to make sure the userland doesn't mess things up. It's what the
crypto block I have in the SBusFPGA does, and while the hardware works, I never really finished the software, it's not really well supported in modern OSes as evey modern CPU has dedicated instructions that keep the state in existing storage (SSE registers for x86-64, NEON for Aarch64).
hackaday.com
