A600 now playing MP3 on vampire... yes, you read it right

[alexh]

Ask the team I am sure they would like to explain it if you ask. They have been planning / thinking / experimenting about this for many years. I am sure they are very chatty.

In the FPGA all instructions could potentially be single cycle whereas they take many cycles in the original silicon but that doesn't explain Pheonix's speed because TG68k will have also done this.

FAST-RAM memory performance with a good SDRAM controller could be incredible compared to old accelerators. But again the older Vampire core with TG68k.C core could also have had this.

The speed will probably be coming from advanced processor technologies not used at the time of the 680x0 series (maybe a little in the 680x0) such as pipelining, caches, prefetch and branch prediction?

If it has a cache or pipeline stages I imagine they could use write-back to minimize stalls and to help 68000 compatibility.

These are just "buzzwords" to me, I don't really implement any of them in my part of embedded processor design. I design ULP (ultra-low-power) and they are usually old-skool 8-bit micros clocked around 1MHz or lower which sleep most of the time

But I know that one of our guys do.

[Mrs Beanbag]

Originally Posted by pandy71

Don't know - IMHO except MMU and FPU, 68020 ISA cover all 68040/68060 instructions

I just checked my books, the only integer instructions available on 68040 and 68060 are CINV and CPUSH (to do with cache control).

Otherwise, the 68060 lacks the longword multiplies and divides.

I could live without an FPU. I could also live without 68060-specific demos not working. Demos only really exist to prove what a very specific set of hardware is capable of, so there is not really much point running them on anything else anyway.

Originally Posted by demolition

To get this speed, it must have some instruction cache despite a regular 68k does not have this? If so, won't it break running self-modifying code?

Self-modifying code is asking for trouble in any case.

Originally Posted by alexh

The speed will probably be coming from advanced processor technologies not used at the time of the 680x0 series (maybe a little in the 680x0) such as pipelining, caches, prefetch and branch prediction?

Oh all of these things were used long before the time of the 680x0 series. It's all trickled down from the supercomputers of the 1950s. They just couldn't fit it onto a chip or into the consumer price bracket until much later.

[Leffmann]

Originally Posted by demolition

To get this speed, it must have some instruction cache despite a regular 68k does not have this? If so, won't it break running self-modifying code?

Originally Posted by Mrs Beanbag

Self-modifying code is asking for trouble in any case.

It depends on the programmer. There is nothing risky, uncertain, or precarious about self-modifying code, where it may or may not work from one run of the program to another. The programmer just has to be aware of the implications of the 680x0's separate caches and the lack of cache coherency.

AmigaOS itself employs self-modifying code all the time. Loading and running a program from disk f.ex, involves self-modifying code.

[alexh]

Originally Posted by Leffmann

The programmer just has to be aware of the implications of the 680x0's separate caches and the lack of cache coherency.

Fine if it's a new program but Amiga is 99% old code. As long as they can be switched off then compatibility can be maintained?

[Mrs Beanbag]

Originally Posted by Leffmann

It depends on the programmer. There is nothing risky, uncertain, or precarious about self-modifying code, where it may or may not work from one run of the program to another. The programmer just has to be aware of the implications of the 680x0's separate caches and the lack of cache coherency.

It may or may not work from one CPU model to another. You would need to work around caching, knowing the particular cache sizes you were working with.

Also what if there is multitasking, or interrupts? The cache might not always behave in an entirely deterministic way in these cases.

AmigaOS itself employs self-modifying code all the time. Loading and running a program from disk f.ex, involves self-modifying code.

Of course! You have to make sure you invalidate the cache after loading an executable. But i feel you are getting pedantic here, if you want to class user-code as "self" of the operating system, i think you are pushing it a bit.

[matthey]

Phoenix is faster than the TG68 mostly because it has a deeper pipeline but also because of an overall more advanced design and better optimization in the fpga.

Some new versions of Phoenix now support all 68020 addressing modes, 64 bit integer MUL/DIV and some bit field instructions. Somehow they squeezed the majority of 68020 support in a Cyclone II.

Phoenix uses writethrough caching and a bus sniffer so the core is very tolerant of self-modifying code. It is more tolerant than the 68040 and 68060 and doesn't need manual cache clearing or flushing.

The 68040 and 68060 added very little of what could be considered integer instructions. MOVE16 could be considered an integer instruction or specialized co-processor instruction. I have never seen a compiler generate a MOVE16 and it is not commonly used. Most other instructions are either not used on the Amiga or are MMU or FPU instructions. For the most part on the Amiga, the integer 68020 ISA = integer 68030 ISA = integer 68040 ISA = integer 68060 ISA (which uses some traps/emulation for compatibility). Pheonix has the 64 bit MUL/DIV instructions in hardware unlike the 68060. They are used on the Amiga providing a big benefit in a few cases where they are used (picture.datatype, utility.library, ffmpeg, etc.).

[kipper2k]

Originally Posted by matthey

Some new versions of Phoenix now support all 68020 addressing modes, 64 bit integer MUL/DIV and some bit field instructions. Somehow they squeezed the majority of 68020 support in a Cyclone II.

the core is pretty well full. Gunnar keeps saying its full and people keep getting him to add more

[NovaCoder]

We'll need a bigger FPGA for the A1200 version!

[alenppc]

Originally Posted by NovaCoder

We'll need a bigger FPGA for the A1200 version!

Agreed!
This is absolutely impressive, well done guys!!
Does this design allow interfacing with a real 68882 for FPU compatibility?

[alexh]

Originally Posted by kipper2k

Gunnar keeps saying its full and people keep getting him to add more

Cool.

I am not familiar with Altera FPGA's but with Xilinx, the smallest RTL change can result in a more optimised layout with less routing giving more resources for functions. It may sound strange for hardware but coding style can have a big effect on FPGA utilisation. ASIC coding style is not always optimal for FPGA.

We have options to remove resets from registers in data-pipelines. Write inferred RAMs in such a way you can infer block-ram or distributed-ram.

Writing good constraints can also pay off. Timing-ignore added to the reset can often (for Xilinx) have a huge effect.

I doubt you have many clocks in Pheonix but using a fast clock and clock-enable instead of two different frequency clocks can make a design previously un-routable work with only minutes of work as the tool stops trying to solve hold violations.

Our new FPGA board being made now will have four XCVU440 and people here will still complain it is too small

[matthey]

The Cyclone V will be easier to fit including better 68020 support and enhancements, has a faster clock speed (~20% faster as I recall), has space for more superscalar execution including another integer unit and possibly FPU, has more memory blocks for several times larger cache than the 68060 instead of 1/2, has a built in memory controller saving some logic, etc. It should make a big difference and allow Phoenix to finally surpass even an over-clocked Rev 6 68060.

Originally Posted by alenppc

Agreed!
This is absolutely impressive, well done guys!!
Does this design allow interfacing with a real 68882 for FPU compatibility?

It is unlikely that there will ever be support for a 6888x FPU which is too slow to bother with. The Cyclone V should have room for some of a 68060 compatible FPU implementation. This may be most of a 68060 FPU if Gunnar can squeeze the logic down like he has in the Cyclone II.

[britelite]

Originally Posted by Mrs Beanbag

Demos only really exist to prove what a very specific set of hardware is capable of

I would beg to differ

[Leffmann]

Originally Posted by alexh

Fine if it's a new program but Amiga is 99% old code. As long as they can be switched off then compatibility can be maintained?

Originally Posted by Mrs Beanbag

It may or may not work from one CPU model to another. You would need to work around caching, knowing the particular cache sizes you were working with.

Sure, but that would be a problem with the program, not with the caches.

Originally Posted by Mrs Beanbag

Also what if there is multitasking, or interrupts? The cache might not always behave in an entirely deterministic way in these cases.

Multitasking and interrupts won't change the functionality of the caches, there is no way old data is going to jump back in after you have flushed and invalidated the caches.

Originally Posted by Mrs Beanbag

Of course! You have to make sure you invalidate the cache after loading an executable. But i feel you are getting pedantic here, if you want to class user-code as "self" of the operating system, i think you are pushing it a bit.

It's all the same to the CPU, it has no concept of Exec tasks, AmigaDOS processes, or programs, and it's not only the case of a program modifying its own code just ahead of the prefetch that counts, all of it falls under SMC.

Saying that SMC doesn't work on 680x0 or that it's something uncertain or unreliable is not true, the programmer just has to understand how the caches work.

[Mrs Beanbag]

Originally Posted by Leffmann

Multitasking and interrupts won't change the functionality of the caches, there is no way old data is going to jump back in after you have flushed and invalidated the caches.

If the interrupt/task switch happens after self-modifying, but before executing the modified instructions, the self-modified code will be flushed out of the cache, and read back in correctly on return to the original program. So sometimes it might work and other times not, depending on when the interrupt/task switch occurs.

Originally Posted by Leffmann

Saying that SMC doesn't work on 680x0 or that it's something uncertain or unreliable is not true, the programmer just has to understand how the caches work.

well ok, but the point is that the caches might work differently from one CPU version to the next. The operating system can deal with this because you can update it along with the CPU if you have to. Userspace code shouldn't really go there.

A lot of trouble has been caused by people writing self-modifying code on 68000 which doesn't have any caches, and of course it works fine on that every time. I don't suppose they imagined a cache might happen in the future.

ok if it's a demo, you want to get the absolute maximum out of a particular CPU and if it doesn't work on another one it doesn't really matter, it's just a demo.

[kipper2k]

Here is an update of the work in progress.

[alexh]

That looks less than other screenshots I've seen where it was around 80 MIPS?

Presumably increased compatibility has reduced peak performance?

[kipper2k]

this is 68020 and not 68000. pretty well full functionality with a couple of changes needed to the lib

[jezry]

Tis makes me want a vampire for my a600 :-)

[cgugl]

Originally Posted by alexh

That looks less than other screenshots I've seen where it was around 80 MIPS?

Presumably increased compatibility has reduced peak performance?

Gunnar removed some features like Branch Predictions and Linstack to free space in the FPGA to improve the 68020/040/060 compatibility.

He is looking for the better compromise between speed and compatibility.
But not all the speed is lost. We obtained 60 mips with a 83 mhz core, but we can go up to 90mhz !

[alexh]

What is a LINstack? Is that like GDB?