As part of an academic project I'm going to be looking at the pros and cons of re-producing microprocessors in current FPGA technologies that are no longer available on the open market. This is to address the problem that occurs in some specialised areas where the lifetime of a product is very long and the cost of rewriting the software is prohibitively high (e.g. it was written in a language and/or tools that aren't supported anymore). The idea is to be able to use an FPGA implementation an either a drop-in replacement component onto a legacy board or to produce a new board but of identical functionality. Either way, no changes to the application object code stored in ROM is required.
There are many different factors that I'll have to look into before I can make any conclusions and I'm concerned that some important ones could be missed. Obviously there are:
1) Availability of the original processor HDL or equivalent.
2) How can the exact EBI timings of the original be recreated (or how close to the original is practical)?
3) Cache memory cannot be recreated on-chip.
4) How close can the internal timings be recreated?
5) Verification ?!
If anyone would like to contribute to this initial brainstorming, I'd be grateful.
Systems that were designed 20 years ago were designed with paper schematics not HDLs. If the manufacturer still exists, and most of them are long gone, the designs are going to be hidden away in a long forgotten file cabinet. The architecture manuals may be still be available some where, maybe even on the net. I've seen sites devoted to the Data General machines for example (I was one of the designers of the DG MV8000 in the late 70s which is why I've looked). The good news is that machines of that vintage were relatively simple because of the limited number of gates that we had available. The smallest FPGA has more gates that any minicomputer of the 70s and the available block RAM in a decent size FPGA exceeds the main memory sizes of many of those machines. The caches, if any, were tiny. A couple of block RAMs is enough. Also modern HDLs like Verilog vastly simplify the design task. One person using Verilog and a decent simulator can do in a few weeks what it took a team of people a couple of years to do in the 70s and early 80s.
This probably isn't practical.
Easily done on chip
4) How close can the
It would be hard to reporduce it exactly, but why would you want to? Minicomputers of the 70s had clock speeds of 5-10MHz, modern FPGAs run at over 100MHz without any work at all, and much faster if you put even modest effort into it.
5) Verification ?! If you can find the orginal diagnostics that would give you a start. In the 70s machines and early 80s machines were debugged in the lab using instruction set diagnostics. The prototype machines were built on wirewrap boards which could be fixed almost as easily as we change a line of Verilog today. The simulators that existed weren't very good and the machines that they ran on were too slow to do any serious debugging so there was no such thing as a testbench as we know it today. The real debugging was in hte lab.
While it is practical to emulate an obsolete architecture in an FPGA it's not clear that it's the right thing to do. Using a software emulator is the more cost effective way to do this. Moores law works out to a factor of 100 per decade which means that in the last 25 years the performance/price ratio has improved by a factor of 100,000. Today's desktop PC is several thousand times faster than the super minicomputers of the late 70s while being a factor of 100 cheaper. What this means is that even if took you 100 instructions to emulate a single instruction on an antique machine the emulator would still run 20-30 times faster than the original machine did. Of course a decent emulator should be able to do a lot better than this but my point is that even the crudest software emulator could do the job.
A good place to start, is to look at what is already out there. This is a good launch site
formatting link
Look at devices like 6502, 6809, & 8080 as simpler examples of cores that have a wider code base, but are not active hardware any more.
Peripheral logic is likely to be as much/more work than the core.
There is also a lot of work being done on game-machine emulation.
Someone has mentioned SW emulation, for an interesting take on that see
formatting link
[this uses a Soft CPU in a FPGA to SW Emulate a more complex CPU ! ]
Where you have spare speed, this approach can save resource.
What would be interesting research, would be a tool chain that allowed a soft-boundary and generic approach to the replacement of any core. The most flexible emulation, would be to start using a tinycore, and calling Target Opcode Sw emulation blocks. This gets the system working, but at a lower speed. Then, you analyse the blocks, and target the frequent/slow ones, to be replaced by either FPGA Logic resource, or opcode extension on the original core.
There was a time when it was common to implement instruction sets by writing microcode that ran on real hardware. The general idea on the ones I'm familiar with was to use a wide instruction word that was easy to decode and simple to implement. (and ran very fast)
It might be fun to do that in an FPGA. I wonder how much it takes to implement a 6502 or such.
--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
It only becomes interesting when you have an application that cannot be economically or practically replaced by software re-writes or a desktop PC.
I heard that the space shuttle is having a hard time sourcing 8086 chips. These were decent in the late seventies when the shuttle was developed.
Many military flight systems suffer from part obsolescence.
Concorde used many analogue computers. It was never going to be economic to upgrade those to modern technology and test them all.
In all the cases above, it is too dear to re-write code and impractical to stick in a modern PC running an emulator. A Blue Screen of Death might easily become a White Hot Screen of Death.
It is interesting to look at space craft over the years.
The early space craft looked rather like pinball machine panels.
The recent Spaceship One cockpit looked like a it had a single LCD panel and a joystick.
In another field, the wartime Colossus is said to be on a par with recent PCs, but internal workings are still quite closely guarded. Partly because the guy looking at it regards it as his project a lot, and doesn't want to give too much away. He is also under the official secrets act, so there's always the risk of having a suspicious suicide in the woods. ;-)
Even if the design was originally done in an HDL, getting the original owner to release it will be next to impossible. However, recreating an older design in an HDL form doesn't take an unreasonable amount of time if the specifications are fairly complete (and accurate, see below).
close
If you are talking nanoseconds, it's going to be time-consuming and probably not worth the effort as long as the timings are cycle-accurate.
And unless you have the time and inclination to figure out the internal timing for this kind of subsystem (a non-trivial task) you wil never be able to achieve cycle accuracy. A similar problem arises whenever you have more than one clock domain in the device, as the original synchronization strategy will be very difficult to discern.
It's actually an interesting exercise to try to figure out how the original design was implemented to come up with the original timings. I have done this twice, for the Z180 and the Z8000. I was able to match the Z180 clock cycle timing in all cases. The Z8000 was a different story, for two reasons. First, the exact timing for the case of the interrupt acknowledge was not specified except "1 to 7 clock cycles" for an aborted instruction fetch. Second, the published timing for both the multiply and divide instruction was clearly incorrect, as it did not account for the different addressing modes correctly, besides not making sense (from a clock cycle standpoint) relative to whether a bit in the divisor was set or not.
If you write your testbench properly, and cover all the boundary cases, it's possible to exercise the original chip with the same stimulus and compare the results. This was very useful in my Z8000 case, where a number of instructions are described as having "undefined" flag values. I was able to figure out what the chip was doing in these "undefined cases" and match the behavior in my implementation. It's usually a case of figuring out where the original designer used "don't cares" in his logic design.
This step is critical if you are working from a published spec. For example, the Z8000 divide instruction is completely specified, including boundary cases. This was obviously the work of the Z8000 architect, and is what I implemented. My testbench tested each of the specified boundary cases, only to find that the actual chip did not properly handle one boundary case! This was actually the hardest case to implement, and it seems that the designer decided to signal overflow rather than properly handle the case of the most-negative quotient (recall that the range of a 2's complement number is assymetric). Well, this change never made it into the published documentation for the chip.
This "specification/implementation disconnect" is one of the more difficult aspects of this process. Without detailed and accurate specifications, the task can be impossible. I would add this to your list of important factors to consider.
There are a number of cases where this avenue is the most logical or even the least expensive. (Think about the cost requalifying flight-critical software, for example.) Emulating an older design on a fast new whiz-bang chip does nothing except postpone the problem, because what happens when that chip is obsolete in 18 months (or worse, in the middle of your redesign). Having the design in a retargetable HDL format makes the obsolesense problem manageable. Emulation is also grossly inefficient in terms of power, and can't hope to be hardware compatible except at the edges of the system, if then.
Why not? Old cycle times were slow by modern standards. Just add enough delay to match the specs.
--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
Since you are an expert of Z8000, I'd like to ask you a question about Z8000, out of curiosity. I heard that Z8000 had bugs. Do you know what these bugs were, and whether they are corrected? Thank you.
Interesting, Sounds a lot of work on the Z8000, can you elaborate on the reasons/needs for this core, in particular. Could also be a good example, for the OP.
The original customer for this design makes air data computers, and projects demand to continue well beyond when the "obsolete part stock" quantities of the Z8000 will be around. Since the software for this system has to be FAA certified, changing even one line of code is horrendously expensive. I'm sure that the OP was talking about exactly these kinds of applications. There are a number of similar applications out there, because the Z8000 was the first MIL-qualified 16-bit CPU and was designed into quite a few military and mil-spec systems. These are the kinds of systems with very long lifetimes. I know that the Z8000 was used in the F-15, the F-16, the 747 and the 757, for example. All of these aircraft are still flying and are still in production as far as I know. These kinds of applications are the exact opposite of the more common "throw-it-away-in-18 months" that most people deal with today.
All of the differences between the published spec and what we found with the actual silicon are detailed there. I think that most of the bugs were back-annotated into the spec. For example, register R0 can't be used with some instructions, for no obvious reason. I think that some of the "undefined" flag settings were actually bugs that were deemed not important. The biggest one, in my opinion, had to do with divide not handling the one boundary case, as I mentioned in the previous post. And there is also the issue of cycle counts for both multiply and divide that can't be correct in the published spec.
..and industrial systems are somewhere in-between.
Did you need to get certification for the Z8000 SoftCPU ? - it seems this would need to be fully qualified as well, or have the MIL/FAA not quite caught up with the idea of SoftCPU ?
I am not sure of the specifics, because the customer took this responsibility. I suspect that the hardware certification process is easier than the software certification process. I saw a copy of the procedure used for software certification and I don't know how anyone could actually get any code written in a finite amount of time following the procedure. But then, I'm a hardware guy. I do know that the customer found my testbench to be very useful. As I mentioned in an earlier post, it checked every instruction, flag, register combination, addressing mode and boundary condition. The customer ran it with a real chip and my design and compared the results. Then I modified my design to match the chip where there was a difference. The only things I didn't match was the interrupt acknowledge timing and the execution time for multiply and divide. My design used fewer clocks, and the customer was satisfied with this result.
In article , "Kryten" writes: |> Always read the small print though. |> |> Several 6502 cores have been published but most of them come with notes |> about not being completely finished. For example, BCD instructions missing.
Next thing is, that mostly all 6502 cores I've seen so far emulate the 65C02. For quite a number of legacy stuff which exploited the NMOS 6502 illegal opcodes for timing reasons a 65C02 is plain unusable.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.