What's being referred to here, I believe, is the option of being able to implement all instructions directly. FPU instructions which existed on the m68881 / m68882 but not on the m68040 can be built in to the FPGA, so exception traps don't need to run (which are much slower).
Actually, what was said above was "to implement in a ROM", which can mean several things.
Seriously, transcendental functions in FPGA are no fun. Nobody sane in his mind would implement them directly in the core. The 68881/82 didn't do that either, it was rather a microcode implemented cordic algorithm which run the computation.
Whether this is the path that will be followed, or wether a software emulaton in 68K assembly will be used remained pretty much untold.
Besides, the problem is only partially the trap. The problem is that the trap and the emulation is in supervisor mode, which inhibits multitasking.
While a ROM and/or library can be loaded for trap handling (so from the OS point of view you're running as if you're on a real m68040), the code would just never get used.
Well, there is supposed to be a ROM, but whether that ROM includes an emulation in 68K assembly or microcode to implement the functions remains to me unclear at this point. If that's just 68K code, I don't see in how far this provides an advantage over the current library implementation.
You could have complete systems which could move between a real m68k processor and an FPGA emulated superset processor without any compatibility issues.
It depends on what you want. For me, this sounds satisfactory, but the point might actually be to depend precisely on the trapping. I do not know whether there is any software which uses this as a side effect. Seems a bit strange at least.
