FPGA Replay Board

[freqmax]

You mean Mips=10.30 not MFlops right?
.
.
The SysInfo tests are a joke. SysSpeed is a little better.

Mips, I read the screenshot wrong.

What method difference between Sysinfo and SysSpeed is there that makes SysSpeed benchmark so much more accurate?

[matthey]

I hope there won't be any huge list of extra instruction ISA that all Amiga now should implement. Rather a few instructions that would give a great boost.

The FPGA capacity is limited.

Bloatwarning ..

I hate bloat and the Natami guys hate bloat. The 68k bloat is in the compilers, not the CPU. The 68k has one of the most compact 16 bit word encodings of any full featured CPU. ARM came back to a 16 bit CISC encoding because it's RISC encoding was bloated and now it has support for original RISC ARM + Thumb 1 + Thumb 2. They should have come back to the 68k and added CF and a few other carefully chosen extensions instead. 68k does not have the extensions from hell problem that x86 does. Making an instruction set wider should not impact performance much as Mike pointed out about moving to 68020+ ISA. This already is a huge improvement over 68000 for power and ease of programming. Do you think this was bloat even though CALLM/RTM and pre and post indexed indirect memory addressing modes should have been left out? The CF instructions are well thought out. This is from the CFPRM...

"As the ColdFire Family grew, input from users and tool developers as well as internal performance analysis suggested a number of ISA enhancements could improve performance and code density. Accordingly, different revisions to the baseline instruction set architecture have been defined and implemented in the various ColdFire processor cores."

Improving the code density increases the CPU performance as do any gains from fewer and more powerful instructions. New instructions should be encoded and processed in a similar way to existing instructions so as not to increase complexity in the decoder but could improve overall efficiency (reduce bloat). If you would like examples of the savings and how often the CF instructions could be used, I can start another thread about ISA enhancements. There are examples and talk about ISA enhancements on the Natami forum if you search for ColdFire.

What method difference between Sysinfo and SysSpeed is there that makes SysSpeed benchmark so much more accurate?

The SysSpeed benchmark uses a more realistic set of instructions. The SysInfo MFlops test measures the performance of fnop and fmove register to register mostly. Maybe the 68881/68882 can perform nearly as well as the 68040 and 68060 at fnop but it says nothing about fp performance. Even the SysSpeed benchmarks are limited. Many benchmarks of realistic code that fits in the cache would need to be done and averaged to come up with a realistic Mips and that says nothing about how powerful the instructions are (makes RISC look good). SysSpeed does give me 99 Mips (and 40 MFlops) for my 68060@75MHz which is close to what Motorola claimed so I have to give it some credit .

[freqmax]

So SysInfo only fails at measure FPU performance accurately, not the CPU performance?

Oh and yeah.. x86 ought to be the example of how to NOT do
Especially the Pentium 4 is a pile of hodgepod that warms really good.

Maybe ARM processors will eat x86 eventually. So CPUs can process data rather than heat your living quarters.

[matthey]

So SysInfo only fails at measure FPU performance accurately, not the CPU performance?

It fails at measuring CPU performance also. My 68060@75MHz gives 55820 Dhrystones, 58.26 Mips, 41.77 MFlops, and 6.00 Chip speed vs A600. Sadly, the MFlops is the closest to reality and I know how flawed the test is. I only found the MFlops test in the code as it's easy to spot as there aren't many other fp instructions. The results speak for themselves though.

[mikej]

Can I ask people to email me (mikej@fpgaarcade.com) and not use the PM system on this forum.
I am getting throught them, but I need to wait 60s between replies and life is too short for that.
Thanks,
MikeJ

[mikej]

I have received a lot of emails!
I will respond to you all, thanks for being patient.

Hardware assembly and testing is going well.
I really want to roll out the new core with these boards, but there are a few issues remaining.
I'll keep you posted.
/MikeJ

[amigadave]

I have received a lot of emails!
I will respond to you all, thanks for being patient.

Hardware assembly and testing is going well.
I really want to roll out the new core with these boards, but there are a few issues remaining.
I'll keep you posted.
/MikeJ

I don't want to distract you from doing your work, but what are the main features you are trying to improve, or issues you are trying to fix in your new core?

[Lizard]

mike: People who mailed you before don't need to mail again, right?

[freqmax]

The video DAC/DVI interface output for analog VGA seems not to have any crowbar protection, is that changed in the final version?

[mikej]

There is a 75R source terminator and bav99 protection diode on the outputs on all card versions.
/Mike

[freqmax]

Sorry, found it now

Btw, where do you buy the CH7301C DVI-encoder chip?

[psxphill]

The CF instructions are well thought out

It's tricky.
 
On one hand a cpu that was compatible with 68000-68060 + CF software would be nice. On the other it is not actually possible to do that 100%, especially because of stack frames & MMU differences.
 
Extending the instruction set beyond what is available now is a dangerous game though. I wouldn't necessarily even add CF, I'd spend the time and gates on getting the instruction rate up.
 
In terms of AGA enhancements, higher bandwidth and chunky pixels is all you really need. Copper and blitter etc can stay register compatible.

[freqmax]

@psxphill, Good point!

[matthey]

On one hand a cpu that was compatible with 68000-68060 + CF software would be nice. On the other it is not actually possible to do that 100%, especially because of stack frames & MMU differences.

The 68000-68060 were not compatible with each other as far as stack frames and MMU differences. Adding "normal" instructions that operate in the same way as previous would not affect these. It's the user level compatibility that we want and it's quite good...

"In most cases, an instruction/addressing mode which does exist in ColdFire behaves exactly like its 680x0 equivalent, which makes it easy for experienced 680x0 programmers to understand ColdFire code. It also means that user-mode code written for ColdFire can generally run unchanged on a 680x0 processor, provided the new ColdFire-only instructions are not used.

However, there are a few subtle cases where the ColdFire instruction is not exactly the same as its 680x0 counterpart. The most important of these is that multiply instructions (MULU and MULS) do not set the overflow bit. This means that a 680x0 code sequence which checks for overflow on multiply may assemble and run under ColdFire, but give incorrect results.

ASL and ASR also differ in that they do not set the overflow bit - but this is less likely to cause problems for real programs!"

MULU/MULS/ASL/ASR will not be a compatibility problem for the 68k as they will continue to be set the 68k way. ColdFire programs would be slightly incompatible because of this but it's extremely rare for a program to use the overflow flag. It's entirely possible to make a 68k+CF CPU that's more compatible with the 68k line than the 68060 was.

Extending the instruction set beyond what is available now is a dangerous game though. I wouldn't necessarily even add CF, I'd spend the time and gates on getting the instruction rate up.

No, it's not dangerous. You would need to double the instruction rate to do the work of a mvs or mvz instruction and they would be common. You would need to at least triple the instruction rate to do the work of a byterev which is less common but used intensely in some drivers and data conversions for loaders/pictures etc. The code reduction also allows the cache to be used more effectively and reduces branch sizes improving overall efficiency. The CF instructions make the job of developers and compiler writers easier also.

In terms of AGA enhancements, higher bandwidth and chunky pixels is all you really need. Copper and blitter etc can stay register compatible.

That's true. It's easy to keep the old and add more while staying compatible. The same applies to the instruction set. Poorly written software will find a way to break no matter what. They will have to be fixed instead of the hardware held back.

[freqmax]

However, there are a few subtle cases where the ColdFire instruction is not exactly the same as its 680x0 counterpart.

Thus ColdFire and 680x0 compatibility is mutually exclusive when the same op-code is supposed to act in different ways?

Poorly written software will find a way to break no matter what. They will have to be fixed instead of the hardware held back.

Then it's no longer a re-implementation, but something completely new. I see the main goal as being able to run the existing software base independently of rotting hardware.

Instruction sequences that involves some kind of looping can be optimized to identify those in the instruction queue. And performing them directly with logic gates with way less clock cycles per operation.

[ChaosLord]

Instruction sequences that involves some kind of looping can be optimized to identify those in the instruction queue. And performing them directly with logic gates with way less clock cycles per operation.

Sadly, there is no way of actually doing that using current FPGA technology.

You could realtime analyze the instruction sequences but there is no way to reconfigure the FPGA in realtime.  In fact it cannot be reconfigured at all while it is in use.

Hopefully this will all become possible 10-20 years from now.