Nice project! Bookmarked and will probably look into the code later
I don't know why, but somehow I fell so deeply in love with FPGAs. They are just pure fun.
There are not that many "real" applications for it (or the needed FPGAs for that get really expensive very fast), but just tinkering around, building/rebuilding CPUs and application specific processors somehow just feels magical.
The thing with FPGAs is if they do something fast, and that thing becomes actually important, they are inevitably replaced with an ASIC. So they are mostly used in the small-medium business space where you need to do serious parallel processing (video or whatever), but don't have the market or budget for a full-on ASIC.
The price thing, as I understand it, is mostly a problem for small volumes. If you're using decent quantities Xilinx will happily cut you a deal for chips at a decent price :/
Also, I guess small FPGAs can feel a bit toy-like when up to a certain point you can just do things in SW.
The reconfigurable bit is useful in military applications where you might want to adapt electronic warfare and radar equipment to a changing environment.
The competition with microcontrollers is real. People who are into retro computing get frustrated because it is unreasonable to make a mass-produced display controller out of discrete parts, even if you are targeting NTSC or VGA. Conceptually it is not that hard, mostly counters and comparators, but the data paths are pretty wide and it adds up to a lot of parts.
Second generation (post Apple ][) 8-bit computers used ASIC display controllers, but today projects like the Commander x16 use either an FPGA or microcontroller. I am quite amused that you can make a soft display controller out of an ESP32.
> The reconfigurable bit is useful in military applications where you might want to adapt electronic warfare and radar equipment to a changing environment.
It's also useful when you don't keep your bitstreams in any form of onboard non-volatile storage: a power cut and/or explosive charge will then conveniently protect your confidential IP.
It is more than cost. FPGA also have security advantages. An ASIC can be reverse-engineered. A FPGA can be 'programed' by software at boot. So someone capturing the FPGA while it is offline learns nothing. That might be why the USAF doesn't go into panic mode when a fancy fighter jet crashes somewhere. Anyone grabbing it might only find blank FPGAs, with their as-used programed layout either deleted or hidden behind strong encryption. Equip your jets with ASICs and every detail of your avionics might be at risk.
That is absolutely not necessarily the case… FPGAs are present doing various things in many, many electronic devices, and many will continue to be FPGAs with no reason to spin an ASIC.
For mass-market consumer electronics what you said broadly true, but a lot of industrial/commercial electronics the time-to-market and flexibility advantages outweigh the higher per-unit cost, because they can charge larger margins to make up for it. (The bit about volumes is correct, yes, you can negotiate good prices if you buy in large enough quantities).
The thing is, compared to an ASIC you've got a commodity product that doesn't become completely redundant if you mess something up. With ASICs, you need another tape out. FPGAs you can just recompile and reprogram the device. I've had customer spot a bug on their code and stream an update through to a satellite in orbit; can't don't that with an ASIC.
The ability to buy them off the shelf and build something with them right away, testing in hardware rather than simulation, is something that's massively undersold too I think.
I used a small FPGA when I needed to modulate a signal. Initially some people tried to use a microcontroller for the same purpose, but there was too much variance in the timing. In fact, initially even the built in silicon oscillator for the FPGA board was too inaccurate, needed to use a plug in crystal to improve the bit error rate.
I think the ability for them to be reprogrammed makes them way more valuable than an ASIC. There is a performance penalty though, something like a 10x silicon area penalty, and 10x frequency penalty. But for some applications it's worth it.
While we do want to support GCOS, it'll be GCOS-3, and that is if we can find system tapes. We are actually planning another blog post soon that will touch on this.
Now, Multics does have GTSS (GCOS Time Sharing Simulator), which Dean has helped us get working.
This facility is based on GCOS-3 4JS3, and it does work, although the software that we have available for it is minimal.
GCOS-8 is a different beast entirely. While there is the possibility that a future version of the simulator could theoretically run GCOS-8 in the future (as most of the work necessary overlaps with supporting CP-6), this is not something that we're going to support as GCOS-8 is a current commercial product.
Nice project! Bookmarked and will probably look into the code later
I don't know why, but somehow I fell so deeply in love with FPGAs. They are just pure fun. There are not that many "real" applications for it (or the needed FPGAs for that get really expensive very fast), but just tinkering around, building/rebuilding CPUs and application specific processors somehow just feels magical.
The thing with FPGAs is if they do something fast, and that thing becomes actually important, they are inevitably replaced with an ASIC. So they are mostly used in the small-medium business space where you need to do serious parallel processing (video or whatever), but don't have the market or budget for a full-on ASIC.
The price thing, as I understand it, is mostly a problem for small volumes. If you're using decent quantities Xilinx will happily cut you a deal for chips at a decent price :/
Also, I guess small FPGAs can feel a bit toy-like when up to a certain point you can just do things in SW.
The reconfigurable bit is useful in military applications where you might want to adapt electronic warfare and radar equipment to a changing environment.
The competition with microcontrollers is real. People who are into retro computing get frustrated because it is unreasonable to make a mass-produced display controller out of discrete parts, even if you are targeting NTSC or VGA. Conceptually it is not that hard, mostly counters and comparators, but the data paths are pretty wide and it adds up to a lot of parts.
Second generation (post Apple ][) 8-bit computers used ASIC display controllers, but today projects like the Commander x16 use either an FPGA or microcontroller. I am quite amused that you can make a soft display controller out of an ESP32.
> The reconfigurable bit is useful in military applications where you might want to adapt electronic warfare and radar equipment to a changing environment.
It's also useful when you don't keep your bitstreams in any form of onboard non-volatile storage: a power cut and/or explosive charge will then conveniently protect your confidential IP.
It is more than cost. FPGA also have security advantages. An ASIC can be reverse-engineered. A FPGA can be 'programed' by software at boot. So someone capturing the FPGA while it is offline learns nothing. That might be why the USAF doesn't go into panic mode when a fancy fighter jet crashes somewhere. Anyone grabbing it might only find blank FPGAs, with their as-used programed layout either deleted or hidden behind strong encryption. Equip your jets with ASICs and every detail of your avionics might be at risk.
That is absolutely not necessarily the case… FPGAs are present doing various things in many, many electronic devices, and many will continue to be FPGAs with no reason to spin an ASIC.
For mass-market consumer electronics what you said broadly true, but a lot of industrial/commercial electronics the time-to-market and flexibility advantages outweigh the higher per-unit cost, because they can charge larger margins to make up for it. (The bit about volumes is correct, yes, you can negotiate good prices if you buy in large enough quantities).
The thing is, compared to an ASIC you've got a commodity product that doesn't become completely redundant if you mess something up. With ASICs, you need another tape out. FPGAs you can just recompile and reprogram the device. I've had customer spot a bug on their code and stream an update through to a satellite in orbit; can't don't that with an ASIC.
The ability to buy them off the shelf and build something with them right away, testing in hardware rather than simulation, is something that's massively undersold too I think.
I used a small FPGA when I needed to modulate a signal. Initially some people tried to use a microcontroller for the same purpose, but there was too much variance in the timing. In fact, initially even the built in silicon oscillator for the FPGA board was too inaccurate, needed to use a plug in crystal to improve the bit error rate.
Used this board: https://digilent.com/reference/programmable-logic/basys-2/st...
I think the ability for them to be reprogrammed makes them way more valuable than an ASIC. There is a performance penalty though, something like a 10x silicon area penalty, and 10x frequency penalty. But for some applications it's worth it.
Having worked on the Honeywell DPS8 range I'm so bookmarking. Software and sourcing may be an issue, but just to play with GCOS again be nostalgic.
While we do want to support GCOS, it'll be GCOS-3, and that is if we can find system tapes. We are actually planning another blog post soon that will touch on this.
Now, Multics does have GTSS (GCOS Time Sharing Simulator), which Dean has helped us get working.
There is an general information page available: https://dps8m.gitlab.io/sb/MR12.8/documentation/info_segment...
This facility is based on GCOS-3 4JS3, and it does work, although the software that we have available for it is minimal.
GCOS-8 is a different beast entirely. While there is the possibility that a future version of the simulator could theoretically run GCOS-8 in the future (as most of the work necessary overlaps with supporting CP-6), this is not something that we're going to support as GCOS-8 is a current commercial product.
If you want to run GCOS-8, you'll have to purchase an Atos BullSequana M9600 mainframe - https://atos.net/wp-content/uploads/2020/09/BullSequana_M_Br...
This is oriented towards Multics. As i understand it GCOS is heavily encumbered with license issues so it's pretty much inaccessible.
Looks like a very clever project. Terasic makes some nice dev boards. Best of luck to you Dean!
[dead]