dynamic fpga instruction re-wiring in fpga, fpga-within-fpga: suggestion for hardware emulation type

[goofyseeker3]

if someone has interest, they could do the emulation of x86 processors, even current, by dynamic re-wiring of instructions, for every instruction, just-in-time, not asic instruction/ALU blocks, in the fpga, thats dynamically switching the structure of the core, or cores, whenever some new instruction is given by the program counter/unit. idea is to radically use less footprint, especially an fpga processor.

just an idea, use as you wish, its public domain idea. if someone tries to patent this, its mine, otherwise free, no cost, public domain.

edit: additionally register operations, calculation instructions, can be tabulated/pre-cached into fpga LUTs, faster execution.

[Newsdee]

Nothing new:
https://www.xilinx.com/support/document ... app388.pdf

[goofyseeker3]

unfortunately it is, because none of the major players, intel, amd, even you, in here, are using it, change my mind, even if the idea was floating around, you did not heed to it, let me re-phrase: you can have all instructions implemented in one fixed size silicon logic block, instead of giant silicon logic footprint.

this applies to both asic and fpga wiring logic design: the core blocks re-arrange/wire to DIV from MUL or ADD, in an instant, 1 cycle, assumed, for example. so I assume "small" fpga cores, only having enough space to implement the instructions needed, like x86/64 instruction set, dynamically just-in-time re-wiring. in other way: how many cores you can fit to 110K logic elements, in the cyclone V, by the usual asic way and JIT dynamic re-wiring, in logic, not in the whole fpga programming way.

was I clear enough.

all say: "we must have asic in fpga", or "we must have asic function blocks", "we must use larger foot-print in asic/fpga than we need to", "we are wasting space", "we must be stupid in our speech", "we must be idiots even if a bright idea was given, for free", I must assume stupidity and wasting of resources, then, change my mind.

let me just say this: I dont believe what you said/linked or uttered in any way, use it or lose it. or if amd/intel/others are using it, but then are lying about it in the processor core block design power point slides. they definitely are describing an asic logic block designs, when they would not need to be, using this, you had it but did not use it or mis-interpreted how to use it.

[Hackshed_Carl]

Erm, yes, ok, thanks for the brilliant idea.

Look forward to seeing you implement this over the coming months

[goofyseeker3]

just sharing the idea, I have arrow sockit, without the memory enhancement, I will do it, but someone needs to port it to the Mister DE10-nano kit.

um, really, if you have the asic parts, you mostly have the JIT implementation, already, the microcode has to be stored and loaded for the local mini core, by the instruction controller unit. its then actually a gpu core, the instruction programmer unit can act also as a branch-prediction/pre-fetch controller unit for the multiple mini-dynamic-cores, each core handling a branch of their own, ahead of the present time, pre-computed. just cpu/gpu in general, the design. also gives the opportunity to update the instruction set and feature support of a processor, if it fits in the silicon footprint, if not, can be implemented in multiple cycle instructions, with delay of the multiple cycles, instead of single cycle implementation.

[goofyseeker3]

btw, someone needs to check the sdr sdram vs ddr3 sdram speed/latency claim, by checking I found that they are practically the same, for the reads, assuming not too much different for writes, both something around 12ns, for sdram and ddr3. arrow sockit might be even better than de10 nano, because it has dedicated 1gb of ddr3 on the fpga side, as well as the hps side, 2gb total. assuming the latency does not need the sdr sdram mod.

from wikipedia sdram: "(a CAS latency of 8 with DDR3-800 is 8/(400 MHz) = 20 ns, exactly the same latency of CAS2 on PC100 SDR SDRAM)"

[Newsdee]

You can make a proof of concept in a console core.

[rhester72]

The problem, of course, is that it takes HELLA longer to 'rewire' FPGA logic than it does to follow an execution path - thus, while this approach would indeed allow for more complex design with smaller logic blocks, it will have a dramatic and inverse effect on net performance, which is why nobody does it.

Remember us when you're wealthy and famous though, would ya?

[Blitzwing]

The problem, of course, is that it takes HELLA longer to 'rewire' FPGA logic than it does to follow an execution path - thus, while this approach would indeed allow for more complex design with smaller logic blocks, it will have a dramatic and inverse effect on net performance, which is why nobody does it.

Remember us when you're wealthy and famous though, would ya?

Nail on the head right there, it is a perfect fit for a CPU not so much for an FPGA. In my extremely quick cursory glance that I took at that Xilinx paper that another poster linked to it reads like Xilinx implemented hardware that would allow this sort of on the fly modifying and therefore isn't something that can be just hammered into the Cyclone 5.

I need to go further into the paper but it certainly doesn't seem remotely like an FPGAs take on the idea of a dynarec. Seems like op found a pipe dream.

[Caldor]

I do not do FPGA code, but Robert Peip f.ex. does seem to start out writing an emulator and then making the core based on the emulators logic. Sorgelig also made the AO486 core based on QEMU code if I remember correctly, using some convert scripts or something. Which worked, but bloated the core to a pretty large size, so he and a few others have been optimizing the code afterwards, reducing the cores size a lot making it possible to add several more features later on. Robert Peip... or maybe its Piep?... is working on a PSX core these days. The progress is good, already an alpha has been released.

But I cannot comment much on the benefits or problems that might come with going this route, or how different it might be from what has already been done. I have tried seeing if I could figure out how to make changes to the core myself. I have come as far as being able to compile the core myself at least, but following the FPGA logic in the code has not worked out for me much so far.

[szt1980]

Make this rewiring controlled by tables corresponding to instructions - and voila, you've reinvented microcoded designs from the 50s.