Comment by mikewarot
5 years ago
Because it had to be cycle accurate to work with the existing hardware, something you can't guarantee in software.
5 years ago
Because it had to be cycle accurate to work with the existing hardware, something you can't guarantee in software.
You definitely can, we use cycle accurate simulators to model logic. These models can be tied in to emulators to give them cycle accurate timing information.
In terms of expressiveness, digital logic can't "do" anything that software can not (including drive real electrical / analog IOs provided the software and the digital logic have interfaces for). Whether you implement the pdp11 in software or logic, either way you still have to create it to take into account all the timing details of the original hardware.
It's just some operations can be done much faster in hardware, but I doubt any part of the pdp11 can't easily be emulated in software on modern CPUs with a lot of timing margin to achieve real-time cycle accuracy. I could be wrong because pdp11 I don't know much about, but for an early simple RISC pipeline of similar performance it is certainly possible.
I assume this is just a solution that works and is supported and they've been using for a long time. It would
As soon as you try to interact with real hardware you'll hit latencies that your simulator can't deal with. Modern processors of the sort you'd use for such a system are designed around intermediary busses that don't provide the sort of timing guarantees legacy hardware needs.
Most hard realtime control systems don't use FPGAs but hard processors. I don't relaly believe those can't achieve as good timing control as a pdp11.
EDIT: From the FPGA vendor:
> Double+ speed Osprey Co-Processor. Occupies one ISA/EISA PC slot. Writable control store, FPGA implementation of PDP-11 architecture with 4 MBytes of tightly coupled, zero wait-state memory. Includes FPJ11® compatible hardware floating point. Performance equivalent twice the DCJ-11® and 100%; of FPJ-11. On-card x86 microprocessor rapidly processes "virtual" I/O instructions. This card is used for Osprey/PC applications where all applicable I/O devices are emulated on the PC by Osprey software. Includes standard environment support for MS-DOS® V6.2.2. Windows/NT® environment support available.
So, highly unlikely that such a system using standard x86 PCs with all their SMBIOS traps and other garbage is able to emulate IO could possibly drive external IOs with better precision and accuracy than a proper real time SOC.
Cycle accuracy may be a requirement in the processor such that legacy software is guaranteed to run the same, but they almost certainly are not doing cycle accurate IOs if they're going across an ISA bus to a DOS or NT PC to be emulated there.
And this works in real time?
In simulation it's sufficient to compute accurate cycle information, yet slower than real time, or with jitter.
In contrast to that "cycle accurate modelling" the goal here was to replace a pdp11 in operation.
Not on the software I'm involved with, but that models a vast modern system running at GHz rather than a system with some tens of thousands of transistors running at 10-20MHz.
2 replies →