just don't forget to include 100W power supply ;)

If you can, then a FPGA has a decent chance of being part of a very fast x86-based, 68k-compatible Amiga accelerator. In fact the bottleneck would most likely be the CPU card interface rather than on the accelerator itself.

It is a interesting Idea to talk about but be realistic here on sane developer would get a I7 for a power up card.
This is because the power requirement cannot me met in clear way by the SZorro bus.
Furthermore there would be a issue of heat dispensation.

It would be smarter to use either e ELV or a embedded processor.(ATOM ARM you name it)

Hi Wojtek,

I don't know what gives you the authority to make such a bold statement.

EXTERNAL LINK 
From the document linked above (emphasis mine):

<i>This chapter provides an overview of the options Altera® provides to connect an external processor to an Altera FPGA or Hardcopy® device. These interface options include the PCI Express, PCI, RapidIO®, serial peripheral interface (SPI) interface or a <b>simple custom bridge that you can design yourself</b></i>.

<i>Offload pre- or post- processing of data to the external processor.</i>

In my case the post-processing data bit, seems to be the thing I'm looking for.

So conneting an external processor to a FPGA for post processing data is possible.

Really it would have astounded me that such a thing wouldn't be possible...

Cheers :)

I agree, better put 40 new dual core ARM cortext designs that would roughly consume around 30 watts and give you the same speed as the fastest consumer i7 ;) the "only" problem, real estate :D

Cheers ;)

I fail to see the benefit of this concept.

This proposal sounds:
A) definitely slower and less performance than doing the whole 68K.
B) More expensive than doing the complete CPU in the FPGA
C) A lot more work
This proposal sounds

Well the proposal of HW accelerated JIT can be implemented with the same kind of 68k decoder we use but instead of feeding a execute pipeline it has to generate machine code for another back end CPU. In the first pass this can be just as fast as the decoder. So there is no benefit yet (except for instructions like divide). If the code is executed a second time then the back end CPU can use it's cache and can execute it faster. But there is a much higher latency when jumps are mis-predicted or when fetching new code.

While B) and C) is obviously true. A) seems to be a bit more like a guess.

But there are a lot of fallacies and pitfalls to take care of. So a real estimate which one is faster is a lot of work. So I think it is better to just execute the decoder output. That is already enough work to do :-)

It reminds me a little of Transmeta's code morphing microprocessors, but the other way around.

Let's say we use a PPC CPU for this idea.
We then would have a PPC CPU card.

The FPGA would translate 68K code to PPC code.
A added advantage with the PPC would be when you need the real PPC for PPC code.

So the whole Idea is a interesting subject for CS classes.
Another one is that is no longer matter if we have access to real 68K's for CPU board.
This Idea could be applied to a real 68K CPU too to add the missing instructions we would have on the N68050 and N68070.
It would work for a dragonball or coldfire in the same manner.

So it creates a form of independence.

A.) It doesn't per default mean you get less performance it would however add to the latency.
B.) AMD sells CPU's for 30 euro's i cannot make one for that same price.
C.) This is indeed some work but if it's more then designing everything in a CPU is debatable.(now that the CPU is nearly done yes it would but if you only had a decoder...)

This first misconception here is that translating an 68K instruction to another CPU is not a simple 1 to 1 translation.

Especially handling of flags can take very many instructions.
This means your decoder will have to output not 1 instructions put sometimes 10 to the x86 or PPC backend.

A good JIT will optimise this and verify of the flags are used by the following instructions and if not it will remove the emulated instructions that would create the flags.

This means your translator can not work on single instructions - you need to "compile" big amounts of code and rewrite it - and recalculating all branch and jump address for the emulating host.

The next problem is that you need keep track of the translation.
If 68K instruction are replaced / changed you need to destroy the translated code -and flush the caches of the x86 system.

In a nutshell :
With a simple 1 to 1 instruction translation you gain nothing.
This would not perform at all.

What you want it a clever just in time compiler with code analysis.
Such a project is absolutely NOT good for doing in Hardware.
The same as you would not want to develop a C-compiler ASIC.

Speaking of Amithlon...With the advent of an open sourced kickstart replacement, I think it more possible to resurrect this concept. And all in open source of course. Use a mainstream linux kernel or maybe even something like NetBSD. And have the ability for Aros68K or original workbench. While one was at it, rewrite a 68K JIT in the manner Bernd discussed in Umilator specs (64bit w/ lookup tables). Between this little package and Natami, 68K should be around for much time to come. Bounty anyone?

The backend-frontend system has an inherent benefit, independence from the underlaying technology. But as all abstraction layers it doesn't come without penalty.

You could do a card that has the master (the FPGA/translator/JIT) with a specific interface. Then do another card with the slave (the processor) that is attached to the specific interface on the master card. So the slave card could have any processor, the "only" thing that would change is the code in the FPGA, that would have to be adapted to the slave processor. I know it's far more complicated to design such a thing than I put it and way less efficient than using the slave directly.

But for 50$ you can get a pretty fast i386 family processor.

I'm not suggesting here to do this. Just exploring possibilities.

Cheers :)

Hi Jakob,

so one would need blocks of code to gain any efficiency from a 68000 interface to i386 processor, so to say JIT territory.

With a coldfire you could implement the missing/extra instructions in the FPGA and wire the rest through? Would that also be very complicated?

Cheers :)

imo. If you need i386 support then use your PC.

As the 050/070 is faster than the Coldfire - where would be the point?