RapidRoad USB starts shipping oct-20-2014

[cmsj]

Originally Posted by Daedalus

It has to be programmed to behave as a 68k CPU, so it's hardware emulation.

We're really splitting hairs, but it's not emulation. The FPGA is *configured* to be an Apollo processor, which is mostly compatible with a Motorola 68000 (and will get more compatible as the cores improve).

It's not emulation, emulation involves translating one system into another. That's not what is happening here, the logic elements inside the FPGA are being configured to be CPU hardware. For it to really be emulation, the FPGA would have to be a processor in its own right, and be translating m68k instructions into its own internal instructions. That is definitively not what is happening here.

[Daedalus]

But does it run it 100% cycle-exact in every possible case for every possible combination of instructions? And what about different FPGA implementations - what if your design is more efficient than my design, resulting in lower propagation times and therefore faster throughput? These are the differences I'm talking about. Your point about the 68020 is a strange one, and is what I was trying to say about the 68060. Yes it runs 68k code, as does the Vampire, but as you say, this doesn't mean it's 100% compatible. It can't be, otherwise there's be no advantage over a 68000. And when you're troubleshooting something as marginal as the issue that was being discussed, the fewer marginal variables like this the better.

[demolition]

An FPGA could run 68000 code 100% cycle-exact if that was what you wanted. But this is not the goal of the Apollo project since they want to make something that operates a lot faster. That the Apollo is not 100% cycle exact to a 68000 is not due to it being in an FPGA. My point with the 68020 is that it is also not cycle exact compared to a 68000 as it is a different design.

[Daedalus]

Right, it's not emulation in the sense of WinUAE or whatever, using a CPU to translate foreign instructions and what not. It is imitating a 68k CPU. Emulation has a broader meaning than software translation of CPU opcodes, and anything that changes its behaviour to mimic something else is emulating that other thing. From the Cambridge English dictionary, just for example:

"to copy something achieved by someone else and try to do it as well as they have".

Just because it's common to think of it in software terms doesn't mean that's the only meaning. But, as you say, we're splitting hairs here. The important point is that it doesn't behave 100% identically to a 68k CPU (because if it did, what would be the point?), so ruling it out of troubleshooting reduces the number of variables to consider.

[kwaku85]

Originally Posted by Daedalus

Give it a rest guys, this isn't the place for 68k bashing, Jens bashing or Vampire worship, nor Vampire bashing or 68k worship.

Excited and all as I am for the Vampire, it's getting tiring reading crap like this polluting otherwise interesting threads. Yes, it's a "real" CPU, but that doesn't mean it behaves identically to any 68k CPU. It has to be programmed to behave as a 68k CPU, so it's hardware emulation. There's no escaping that fact, and it doesn't make it inferior to a 68k, just different. Many of the differences between it and a real 68k CPU can rightly be considered improvements, but this makes it *different*, in much the same way as a 68060 is different from a 68000. And these improvements/differences will cause different behaviour in certain circumstances, again like the difference between a 68060 and a 68000. This adds extra variables to the type of troubleshooting that's going on, so it only makes sense to discount it from testing for now.

What do you hope to achieve by derailing a thread like that? Let the Vampire speak for itself, which shouldn't be a problem if it lives up to the hype.

The real problem is someone try to discourage ppl to something, because care of own bussiness. It's not fair. Most unfair is provading false informations about something about haven't any knowledge.
About your post- you can name it as emulation, even if it's not. If Apollo team will put inside Intell CPU and emulating HW to converse 68k->x86->68k instructions, it will be an emulator. FPGA is configurable hardware, you can create everything inside, it's not emulating, it's building. Real hardware building. That's all.
Apollo team just make their own 68k compatible CPU with peripherials like RTG, uSD, IDE, FastMem and many not existing before instruction inside.
How much it's stable and compatible? Time will show, today it's really good, many people work on it and many other will start for sure. Apollo team will grown and give true support. REMEMBER- SUPPORT. Someone should teach something about this little word, mayby google can help.
That's all from my side, name it emulator, simulator, refrigerator or watever you like. No one care, it works like a charm and become better and better every day.

[Daedalus]

Originally Posted by demolition

But this is not the goal of the Apollo project since they want to make something that operated a lot faster. That the Apollo is not 100% cycle exact to a 68000 is not due to it being in an FPGA. My point with the 68020 is that it is also not cycle exact compared to a 68000 as it is a different design.

And this is my point. Glad we're in agreement here. I don't care what it is, I'll probably buy one for an A1200. I'm not having a go at FPGAs, I'm just being realistic about what the Vampire is.

[demolition]

Originally Posted by Daedalus

And this is my point. Glad we're in agreement here.

Yay, a discussion on an Internet forum ended with two people agreeing.
From your dictionary quote, I can see how it can be called emulation. They are mimicking the 68k core but since they have not copied it directly (and probably don't have access to the original blueprints), it can be called emulation by that definition.
Lots of people think of emulation in terms of WinUAE and that is something very different indeed. Many people seem to think that the Vampire would be more 'genuine' if it had an ASIC instead of an FPGA but that is important to clearly state that it is the same, only the ASIC could run at a higher clock.

[Daedalus]

Originally Posted by demolition

Yay, a discussion on an Internet forum ended with two people agreeing.

Where's that dancing banana?

[demolition]

Originally Posted by Daedalus

Where's that dancing banana?

[grond]

Originally Posted by Daedalus

I'm not having a go at FPGAs, I'm just being realistic about what the Vampire is.

The one important thing missing is that you can have an ASIC made from the apollo core code without any difficulties (just lots of money required). The apollo core is developed exactly like any modern processor is (by professional processor developers, as a matter of fact) and it uses the same tools for the same ends. The VHDL code is just put through a logic synthesizer for an FPGA instead of one for a hardware library of an ASIC manufacturer. It's basically the difference between prototyping and mass production. Nobody would 3d-print mainstream computer cases but would use injection molding. However, for a market as limited as the amiga market 3d-printing may be an option. The same goes for FPGAs and ASICs: nobody would put an FPGA into a mobile phone but using FPGAs for amiga turbocards is certainly a good idea. However, in both cases the actual development work is the same: you need to design a proper 3d model (cases example) and you need to write VHDL code (processor example) REGARDLESS of the actual manufacturing method.

[Schoenfeld]

I referred to Vampire as "not a real 68k" because some months ago (over a year? can't remember) I suggested to help the project by giving it a scientific touch: Create a test suite for the target 68k CPU and actually *prove* that it is equal to a 68k. I know it can be done, and I would certainly only accept it as "real 68k" if there is a test suite, and the Apollo core passes this test suite.

When I suggested this on the A1K forum, I have been badly attacked, because everyone was convinced that this is not necessary and it would only make things too complicated and too expensive.

So let me bring this back to topic: While there is no test suite that *proves* equality over the whole instruction set, cache+MMU status, I do not consider Vampire a 68k CPU, hence there is no support for any of my products working properly with Vampire.

This support policy will change as soon as a test suite is available.

Jens

[roomeo]

How could we interpret all this from "its not a real 68k"?

However, thumbs up for the clarification.

Now..how are things going with tracking the RR issue?

[grond]

Originally Posted by Schoenfeld

I referred to Vampire as "not a real 68k" because some months ago (over a year? can't remember) I suggested to help the project by giving it a scientific touch: Create a test suite for the target 68k CPU and actually *prove* that it is equal to a 68k. I know it can be done, and I would certainly only accept it as "real 68k" if there is a test suite, and the Apollo core passes this test suite.

...

So let me bring this back to topic: While there is no test suite that *proves* equality over the whole instruction set, cache+MMU status, I do not consider Vampire a 68k CPU, hence there is no support for any of my products working properly with Vampire.

The proof of the pudding is in the eating. And even if you don't try it, it remains a very tasty pudding.

When I suggested this on the A1K forum, I have been badly attacked, because everyone was convinced that this is not necessary and it would only make things too complicated and too expensive.

Link please, I want to read those bad attacks.

[roomeo]

A lot of people will get the Vampire. So if hypotheticaly there is incompatibility with either of icomp's products how will people think? "I'll better get rid of the Vampire then"... No way..

So regardless of the criteria you set for the vampire, you should support it either way. I can agree that the goal of the Apollo-core could be a moving target and hard to support. (an uneducated statement btw) But in the end, it is likely to be the new standard.

[kwaku85]

Originally Posted by Schoenfeld

I referred to Vampire as "not a real 68k" because some months ago (over a year? can't remember) I suggested to help the project by giving it a scientific touch: Create a test suite for the target 68k CPU and actually *prove* that it is equal to a 68k. I know it can be done, and I would certainly only accept it as "real 68k" if there is a test suite, and the Apollo core passes this test suite.

When I suggested this on the A1K forum, I have been badly attacked, because everyone was convinced that this is not necessary and it would only make things too complicated and too expensive.

So let me bring this back to topic: While there is no test suite that *proves* equality over the whole instruction set, cache+MMU status, I do not consider Vampire a 68k CPU, hence there is no support for any of my products working properly with Vampire.

This support policy will change as soon as a test suite is available.

Jens

Hehe, You talk as politicians. Mayby Apollo team not need to prove anything to any one? Mayby we should change sides- mayby you should prove Apollo core is not "a real 68k"?
People like Gunnar know exactly how 68k works and how it's build. They remove any bottleneck from 68k CPU core and add new great fetures. They add 64bit architecture! So, with all this knowledge and having list of every instructions inside any 68k CPU, and then- having skills to build whole CPU inside FPGA and doing this now with many success- can they be wrong? Can they create "not real" and bad working 68k CPU inside this great "Logic Lego"? With all this knowledge and skills?
They not talk. They just do what they promised at the start, Vampire card exist and works, works pretty good. Have bugs yet, but can You imagine they can't find them and not fix them inside their own CPU? I can't. It's ridiculous.
Creating testcase. It's lot of work. Mayby too much. They test any existing software for amiga and all is working. Want see testcase result? Mayby try to write testcase by Yourself? Team will be very thankfull for this hard work I think.

[Amon_RA]

I'm really astonished that people actually expect compatibility and support on things plugged into emulated hardware (which doesn't even have a proper test suite). That's like expecting add-ons intended for real Amiga hardware to actually work on a minimig... and blame the add-on vendor if it doesn't. I'm sorry but that's beyond ridiculous. The fact that Jens even bothers to explain and even considered helping the project says a lot about his willingness to help the Amiga community further. I really don't understand the reactions of some people here, it's like they are a bunch of grumpy old men yelling at clouds... what a waste of time.

[roomeo]

I, for one, don't expect a lot of support from icomp. I'm just pointing out that whatever you want to call vampire, it can't be ignored. By doing so , many potential customers could be lost. That would just be silly.

[grond]

Sorry, but Jens explaining to a group of professional CPU developers (who did POWER8 and some ARMv8 among others) how to develop a CPU properly is like a cow explaining a dairy farmer his business. There is a "test suite", of course. There are hundreds if not thousands of asm programs that we call testcases. Some are only a few lines, some are hundreds of lines long. They are verified on real CPUs and tested in simulation. Nobody has to prove anything to Jens S. He can mind his own business and develop superexciting accelerators slower than what I had twenty years ago.

[clebin]

Originally Posted by Amon_RA

I'm really astonished that people actually expect compatibility and support on things plugged into emulated hardware (which doesn't even have a proper test suite).

I don't think anyone's said that, have they? The topic was the A3640 bug and the original mention of the Vampire was just to be helpful. To quote: "just in case the CPU type would have an impact." Jens didn't have to respond in the way he did.

[roomeo]

Can't an existing test suite for real 68k be used?