Hardware vs Simh (and FPGA)

On Apr 26, 2013, at 12:45 PM, Mouse <mouse at Rodents-Montreal.ORG> wrote: My bad, I thought x86 was more or less banished from your domain. :-) Is the Super-H machine you're talking about a Dreamcast? Those are pretty neat machines, though I never had one myself. People are still releasing new (good) games for them, too! It's the complexity of the devices. It's not like CPU code, where everything is linearly executed; it's a lot closer to a PCB auto- router because it's a 2D search space of optimal routes. Except the problem is blown up to several hundreds of thousands of pre- routed nets to select from. The actual synthesis code (taking the HDL and turning it into a device-independent intermediate netlist) takes about as long as compiling the equivalent length of C code; it's the "fitting" process (taking the intermediate netlist, placing all the nodes, then choosing routes that will meet the timing constraints) that takes so long. Optimization on a C compiler usually involves some comparatively simple dataflow analysis and then eliminating redundancies which are revealed by said analysis. Fitting an FPGA involves making a best guess at what the optimum placement is (sometimes with "floorplan" guidance from the designer, which can help a lot) and then making many, many passes at what the optimum routes are to meet the timing constraints specified. I don't know what the exact algorithms are, since they're considered trade secrets, but I know the way at least Xilinx's software iterates looks close to a genetic algorithm (it keeps the most successful pass so far and varies it until it either closes timing or gives up). How long it takes obviously depends on the complexity of the design. If you just throw a 16-bit counter design in there, or a moderately complex design with a very slow clock, it's going to take a minute and a half to compile even on the biggest FPGA out there because it doesn't have to make many tries before it meets timing. But if you crank the clock in the timing model up to 1 GHz, it's going to try a whole lot more potential routes before it throws its hands up in disgust (within reason; if you did it with the 16-bit counter, it will very quickly converge on a "this is as fast as she goes, Cap'n" value anyway). Maybe. CAD algorithm design is a huge and active area of academic research, because there's a lot of money to be made if you can develop an algorithm that closes faster and gives higher maximum frequencies. I agree that it's incredibly dumb that the bitstream semantics are hidden. There's always an opportunity to reverse-engineer from subtly different builds, but I do think the EULAs probably prohibit that... if you did it for your own edification, though, no one would know. Alas. - Dave