Hacker News Reader

Comment by emmelaich | Hacker News Reader

I assumed it was software pdp11, but no, it is an "FPGA implementation of PDP-11"

http://www.strobedata.com/home/ospreydx.html

My first job out of college in 2007 was building a pdp-11/70 emulator on virtex-5 fpgas to replace the control computers for CANDU nuclear reactors.

We had a punched-tape and microfiche of the xxdp diagnostic test suite to pass: http://bitsavers.org/pdf/dec/pdp11/microfiche/ftp.j-hoppe.de...

Several nuances that we replicated were probably never used by the production software. For example the order of execution of a floating point instruction trap followed by a stack pointer trap due to the pipelining of the fpu instructions, even though we weren’t executing anything out-of-order. I also produced the correct partial result for the division algorithm in the event of overflow condition.

Test vectors are the biggest secret sauce for any CPU or microcontroller. Word on the street is that the STM32Fxxx test vectors were stolen and that’s why you have perfect replicas being churned out of China, not like the typical cases where your devices fail with the fake chip installed.

I mean, with a list of all test input vectors and expected outputs, you could derive the entire chip right? It’s just logic gates.

Not even close. The STM32Fxxx is a series of microcontrollers. They have tons of internal state which isn't exhaustively covered by test vectors. (For example, a basic 16-bit timer peripheral has roughly 60 bits of internal state, and there certainly aren't going to be 2^60 test vectors to cover that.)

You can for some things, but that wouldn’t be a very efficient result (it’s basically going to give you a massive lookup table). It’s also not that simple since we are not talking about stateless behavior - think more along the lines of interrupts, counters, events, dma, analog input/output, etc. none of which really map into a straightforward input:output relationship, most of which can be used together to some extent to form a gestalt. Even with the test vectors it is a Herculean task.

No, there's too much complexity. What you can do is reverse engineer it more manually using data sheets etc., and then use the test vectors to ensure that you got it right. They're likely to be designed to cover all the interesting corner cases that might cause problems.

Not in a unique nor meaningful way. For example, a valid "derivation" would hold a list of all input/output pairs and give zero otherwise.

I did some security work for a bank that was running a software-emulated HP3000 for their core banking platform to run on. They were so scared of us breaking something that they had us write in the contract we wouldn't touch the production unit whatsoever. In retrospect it was a good idea because we killed one of their dev boxes with a scan and it took a couple of days for them to get it back online.

Strobe Data's site reminds me of Berkshire Hathaway's:

https://www.berkshirehathaway.com/

I think neither business needs to convince anybody of anything. If you need what Strobe is selling and can afford it, they probably made the sale.

Ok the web page looks old but maybe not that old

A subset of the content could be that old.

The oldest I found was from 1977 - https://www.berkshirehathaway.com/letters/1977.html .

Here's the 'Chairman's Letters To The Shareholders (Historical Compilation)' from the 1997 version of their site - https://web.archive.org/web/19970530212045/http://www.berksh... , with yearly publication.

Could be auto-generated.

I wonder why not software emulated.

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.

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.

> 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.

Thanks!

Reply on news.ycombinator.com