4 ms·

I wonder why not software emulated.

by throwawaylinux 5y ago

deleted 5y ago
[deleted]
mikewarot 5y ago
Because it had to be cycle accurate to work with the existing hardware, something you can't guarantee in software.
- throwawaylinux 5y ago
  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
  - froh 5y ago
    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.
    - throwawaylinux 5y ago
      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.
      - mikewarot 5y ago
        Modeling a system isn't the same as emulating it in real time. You have to match up the timing of your inputs and outputs with the exact right clock cycle that is coming with a hard deadline, and if your emulator does a garbage collect, or some other thing, you'll miss it. It seems like a super fast system would be easy to do this with, but reality is different.
        throwawaylinux 5y ago
        > Modeling a system isn't the same as emulating it in real time. You have to match up the timing of your inputs and outputs with the exact right clock cycle that is coming with a hard deadline, Sure, my point with anecdotes is that the hardware system can be modeled in software to cycle accuracy, and it can be emulated with software. Therefore it can be emulated with cycle accuracy (provided you have the CPU power to meet timing). > and if your emulator does a garbage collect, or some other thing, you'll miss it. Well if you do anything that blows your timing budget then you miss your deadline by definition on any real time system. Obviously you can use real time garbage collection (or not use it) and control other latencies. I wasn't suggesting you could just write some code and make a real time cycle accurate emulator without paying attention to real time deadlines.
  - kevin_thibedeau 5y ago
    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.
    - throwawaylinux 5y ago
      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.

I wonder why not software emulated.

deleted 5y ago

[deleted]

mikewarot 5y ago

Because it had to be cycle accurate to work with the existing hardware, something you can't guarantee in software.

throwawaylinux 5y ago
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
- froh 5y ago
  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.
  - throwawaylinux 5y ago
    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.
    - mikewarot 5y ago
      Modeling a system isn't the same as emulating it in real time. You have to match up the timing of your inputs and outputs with the exact right clock cycle that is coming with a hard deadline, and if your emulator does a garbage collect, or some other thing, you'll miss it. It seems like a super fast system would be easy to do this with, but reality is different.
      - throwawaylinux 5y ago
        > Modeling a system isn't the same as emulating it in real time. You have to match up the timing of your inputs and outputs with the exact right clock cycle that is coming with a hard deadline, Sure, my point with anecdotes is that the hardware system can be modeled in software to cycle accuracy, and it can be emulated with software. Therefore it can be emulated with cycle accuracy (provided you have the CPU power to meet timing). > and if your emulator does a garbage collect, or some other thing, you'll miss it. Well if you do anything that blows your timing budget then you miss your deadline by definition on any real time system. Obviously you can use real time garbage collection (or not use it) and control other latencies. I wasn't suggesting you could just write some code and make a real time cycle accurate emulator without paying attention to real time deadlines.
- kevin_thibedeau 5y ago
  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.
  - throwawaylinux 5y ago
    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.