@Gunnar

Quote:

Gunnar wrote: @cdimauro Quote: "If you repeat a lie often enough, people will believe it, and you will even come to believe it yourself." - Joseph Goebbels like your stories about "USA racing"? For sure you are an expert in this field!

Already replied here: https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=44581&forum=15&start=500&viewmode=flat&order=0#855857

"If you repeat a lie often enough, people will believe it, and you will even come to believe it yourself." - Joseph Goebbels

@Karlos

Quote:

Karlos wrote: @Gunnar Quote: As you know Amiga OS is based on a 32bit address design. If you want to run Amiga OS than 32bit address is the world in which you live. We have no desire to run Linux on 68K. We want to run AmigaOS. Therefore 64bit address makes no sense for us. Understood. This is why I'm asking about the 64-bit address register width. I'm just curious to understand the engineering reasons for it. It's not an armchair opinion on how you should design or implement it :) Quote: The Data register are for ALU operations - But also Address register can be used in ALU operations. Like for example ADD.L A0,D0 = ALU operation using A0 as source Sure but the above is a 32-bit addition, so the upper bits of A0 don't matter, right? Is there a corresponding 64 bit version of this, e.g ADD.Q A0, D0 I don't imagine, based on what you say, that you'd waste any logic space making them 64 bit wide unless there was some good engineering reason for it. That's what I'd like to understand. I just thought, the EXG instruction. That's one reason I can definitely see that would benefit from the address registers being 64 bit, especially if you are swapping them with data registers.

I can give you an answer.

First to the last part. With 32 data registers you had no need to use the address registers to temporary hold data, and using EXG when needed.

Second, the reason why Gunnar expanded the address registers to 64-bit is solely because the 68080 core implementation was easy, since you have a single and homogeneous (all 64-bit in size) register bank for all kind of registers.

It's his usual way of expanding an architecture: he needs something and he finds the solution that gives the lowest implementation cost for it at the microarchitectural level.

So, it's the microarchitecture: a single, specific, implementation that its's driving the architecture design.

If this hurts the architecture then it doesn't matter to him (see his AMMX design: crippled to 64-bit for his own decision).

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: Amiga with RTG and AmigaOnes supported little endian as data format. For obvious reasons. Which aren't obvious for you, of course. But, could AmgaOne be considered Amiga? Amiga people don't seem to like the One.

Clearly no. That's why I've written first Amiga and then AmigaOne: to distinguish / separate them.

P.S.: Karlos already replied about the RGB endianess.

If there is one thing we can be sure of is that we still have some passion, at least.

_________________
Doing stupid things for fun...

Please tell us more about this post!

Quote:

I am pleased to communicate to everyone in the forum, the start of a new all-Italian project for the creation of a new super Amiga Classic with exceptional characteristics. TiNA project official site: http://www.tinaproject.it/ Of course, I too am part of the development team like many other Amiga fans in Italy and abroad. We all believe in this project and for weeks we have been carrying it out with passion and seriousness. Each of us specifically takes care of developing and carrying out a part of the project based on their own skills. For the moment we are part of the team: - Bertocar (hardware developer) - Cdmauro (software developer) - Schiumacal (graphic and web-designer) - TheDaddy (English and house designer for clone Amiga systems) It is implied that everyone can offer their skills for the improvement of the project, so whoever wants to can come forward. Believe me when I tell you that it will absolutely not be an infinite project like Natami, but on the contrary we are often at work, even at night, precisely to ensure that TiNA can enter the homes of all Amiga fans as soon as possible. The bases are all there and much more concrete than in many other foreign projects. Below I list some of the peculiar characteristics of the project: CPU dedicate: 3 x FPGA one per core Memoria RAM: 256MB-1GB Ram Hard Disk: HDD IDE Floppy Disk: FDD controller Ingressi: PS/2 mouse and keyboard Ingressi: SDCard slot Collegamenti esterni: Ethernet Uscita video: HDMI out (or VGA) Uscita audio: AUDIO out I/O: 1 x Serial Port PRINCIPALI CARATTERISTICHE DI TiNA: - Extended AGA chipset with chunky pixel up to 32 bit and support for a FullHD (1920x1080) at 60Hz/FPS - Improved Copper and Blitter, especially the Blitter in order to manipulate up to 32bit colour - Improved Sprites (still 8) to support chunky-pixel mode up to 32 bit colour, with the possibility of horizontal and vertical flip - from 256MB to 1GB of memory (all chip-ram) with a theoretic bandwith of 3.2GB/s (roughly 450 times what OCS/ECS machines offered, and 112 times what AGA had available just for the display and sprites), later on there might be the possibility to quadruple it using DDR2 memory (reaching similar Nintendo Wii U values). - Minimum of 8 audio channels, 16 bit stereo at 48Khz (minimum). - IDE/ATA controller for legacy hard drives - SD card slot for firmware, ADF images and HDF to emulate up to 2 hard disks. - Compatible with AmigaOS3.x

Dear friend Cesare di Mauro,


Did your friends and you post these announcement in several Amiga forums?

The Cesare Di Mauro, here listed as expert who can answer all the technical project detail, is this you?

This project looks all vapor and technically impossible.
Do you agree that the project was 100% vapor and the promises were all impossible?


Quote:

Currently we have an FPGA dedicated only to the 68000 CPU but at a speed of about 400Mhz, while the other two FPGAs are dedicated to the rest of the ChipSet Amiga Classic, therefore: Copper, Blitter, etc. with direct memory management on a single very broadband channel, therefore without system conflicts for the data BUS, in other words, each dedicated Chip can manage the memory at full speed without slowing down thanks to the very wide system bandwidth. Our intention is to implement a CPU 68020 at 400mhz always via FPGA, but part of the code we should make it ourselves because in reality there is no free 68020 code around to put in FPGA. This project is born now, so the design of a motherboard is still under development, but I assure you that under Bertocar there are a series of electronic engineers who study intensely how to do it and may even succeed. Cdmauro is giving a gigantic hand in the development of the algorithms that will subsequently allow to have a real and concrete version of TiNA in beta. For the moment I can't give you the times because we are all just working to make a prototype as quickly as possible. TiNA will be compatible with AmigaOS 3.x but our aim is to load AROS 68K on it and make it the base OS for the machine. Any missing drivers or drivers to be changed will work out without problems. We can do it. For the price ... let's say that we have already made a quote based on what are the current prices of the various components, currently we are around 200/250 euros, this because initially it was thought to implement a only FPGA, but then it was realized that three FPGAs at a slightly higher cost are much better. This is the scheme of the project: Image For any technical details, register on the website: www.Tinaproject.it There is a forum in English with some posts also in Italian. Bertocar and Cdmauro can answer you on all the technical details

Dear Cesare Di Mauro,

The TINA team did post dozens of announcements like this.

Dear Cesare, how would call an announcement of clockrate of 470 MHz of the FPGA,
when the manual of the FPGA states that this model can not go over 200MHz?

Quote:

It has been said that TINA uses 3 processors called FPGAs which replace the 68k in effect and the other 2 fpgs will be the perfect and improved copies of the original chips mounted on the real amiga integrated graphics / video card! the 68k processor of fpga / tina will be a 68000 at approximately 470 MHz at the beginning

@Gunnar

The statement is a bit vague to me. Does it mean it's running at 470MHz or estimated to be equivalent to a 68000 @ 470 MHz?

It does say "will be a 68000 at approximately 470MHz". I mean the fact it's approximate doesn't sound like they're talking about the actual clock speed. Firstly it's a bit of a weird clockspeed anyway and secondly, why would that be an approximate, rather than an exact figure?

_________________
Doing stupid things for fun...

@Moderators
I believe spamming of off topic posts can now be added to Gunnars offenses. Over half of his posts are violations of the Terms of Service.

Quote:

Terms of use: ... Flame/Attacks: Do not flame! Flaming refers to derogatory, abusive, threatening, sarcastic, rude, or otherwise mean-spirited messages directed at members/users. Be cautious when using sarcasm and humour. Without facial expressions and tone of voice, they do not translate easily over the Internet in posts and may be perceived as flaming. Report the flame posts immediately to an Amigaworld Team Member so that the situation can be dealt with immediately. A warning may be issued depending on the severity of flame/attacks. Troll: Trolls show no respect for other people's opinions and deliberately crafts messages to provoke others with the intention of wasting their time and energy or just to cause anger and confrontations. There is no point in arguing with them; their minds are made up. Ignore them, and report the posts immediately to an Amigaworld Team Member. Repeat offenders may incur an instant banned. Multiple usernames: Intentionally registering more than ONE username for the purpose of using multiple usernames is NOT allowed. This includes, but is not limited to, registering a new username to avoid a ban. Using the site (for posting messages or otherwise) with more than one username is not allowed. Users that do not follow this rule will be permanently banned. Also, do not use someone else's username, even if you were given the password to it by the owner of the username. Exceptions can be made with approval of Amigaworld.net staff, for example where the username is a company name to be shared by employees. If you would like to change your username, contact the webmaster. ... Spam: Spamming the forums with senseless, inane, or empty messages to increase your post count, or simply to aggravate, will not be allowed. This includes such things as chain letters and two-word "I agree" or "me too" responses. Continually posting the same topic on a particular board, and posting the same question across several forums is also considered spamming, and is a violation of this TOS.

How far will this forum be allowed to deteriorate?

@Gunnar

Quote:

Gunnar wrote: Please tell us more about this post! Quote: I am pleased to communicate to everyone in the forum, the start of a new all-Italian project for the creation of a new super Amiga Classic with exceptional characteristics. TiNA project official site: http://www.tinaproject.it/ Of course, I too am part of the development team like many other Amiga fans in Italy and abroad. We all believe in this project and for weeks we have been carrying it out with passion and seriousness. Each of us specifically takes care of developing and carrying out a part of the project based on their own skills. For the moment we are part of the team: - Bertocar (hardware developer) - Cdmauro (software developer) - Schiumacal (graphic and web-designer) - TheDaddy (English and house designer for clone Amiga systems) It is implied that everyone can offer their skills for the improvement of the project, so whoever wants to can come forward. Believe me when I tell you that it will absolutely not be an infinite project like Natami, but on the contrary we are often at work, even at night, precisely to ensure that TiNA can enter the homes of all Amiga fans as soon as possible. The bases are all there and much more concrete than in many other foreign projects. Below I list some of the peculiar characteristics of the project: CPU dedicate: 3 x FPGA one per core Memoria RAM: 256MB-1GB Ram Hard Disk: HDD IDE Floppy Disk: FDD controller Ingressi: PS/2 mouse and keyboard Ingressi: SDCard slot Collegamenti esterni: Ethernet Uscita video: HDMI out (or VGA) Uscita audio: AUDIO out I/O: 1 x Serial Port PRINCIPALI CARATTERISTICHE DI TiNA: - Extended AGA chipset with chunky pixel up to 32 bit and support for a FullHD (1920x1080) at 60Hz/FPS - Improved Copper and Blitter, especially the Blitter in order to manipulate up to 32bit colour - Improved Sprites (still 8) to support chunky-pixel mode up to 32 bit colour, with the possibility of horizontal and vertical flip - from 256MB to 1GB of memory (all chip-ram) with a theoretic bandwith of 3.2GB/s (roughly 450 times what OCS/ECS machines offered, and 112 times what AGA had available just for the display and sprites), later on there might be the possibility to quadruple it using DDR2 memory (reaching similar Nintendo Wii U values). - Minimum of 8 audio channels, 16 bit stereo at 48Khz (minimum). - IDE/ATA controller for legacy hard drives - SD card slot for firmware, ADF images and HDF to emulate up to 2 hard disks. - Compatible with AmigaOS3.x

Sure, I call tell more just quoting 3 sentences from there:
Quote:

- Bertocar (hardware developer)

What's not clear to you about HARDWARE word?
Quote:

- Cdmauro (software developer)

What's not clear to you about SOFTWARE word?
Quote:

It is implied that everyone can offer their skills for the improvement of the project

What's not clear to you about THEIR SKILLS words?

You continue with your LIES propaganda, but even the contents that you report show that you're a LIAR!
Quote:

Gunnar wrote: Dear friend Cesare di Mauro, Did your friends and you post these announcement in several Amiga forums? The Cesare Di Mauro, here listed as expert who can answer all the technical project detail, is this you? This project looks all vapor and technically impossible. Do you agree that the project was 100% vapor and the promises were all impossible? Quote: Currently we have an FPGA dedicated only to the 68000 CPU but at a speed of about 400Mhz, while the other two FPGAs are dedicated to the rest of the ChipSet Amiga Classic, therefore: Copper, Blitter, etc. with direct memory management on a single very broadband channel, therefore without system conflicts for the data BUS, in other words, each dedicated Chip can manage the memory at full speed without slowing down thanks to the very wide system bandwidth. Our intention is to implement a CPU 68020 at 400mhz always via FPGA, but part of the code we should make it ourselves because in reality there is no free 68020 code around to put in FPGA. This project is born now, so the design of a motherboard is still under development, but I assure you that under Bertocar there are a series of electronic engineers who study intensely how to do it and may even succeed. Cdmauro is giving a gigantic hand in the development of the algorithms that will subsequently allow to have a real and concrete version of TiNA in beta. For the moment I can't give you the times because we are all just working to make a prototype as quickly as possible. TiNA will be compatible with AmigaOS 3.x but our aim is to load AROS 68K on it and make it the base OS for the machine. Any missing drivers or drivers to be changed will work out without problems. We can do it. For the price ... let's say that we have already made a quote based on what are the current prices of the various components, currently we are around 200/250 euros, this because initially it was thought to implement a only FPGA, but then it was realized that three FPGAs at a slightly higher cost are much better. This is the scheme of the project: Image For any technical details, register on the website: www.Tinaproject.it There is a forum in English with some posts also in Italian. Bertocar and Cdmauro can answer you on all the technical details

As I've said before, I will NOT answer your questions until you answer ALL mine.

But to prove that you continue report lies I just quote parts of the above text:
Quote:

under Bertocar there are a series of electronic engineers who study intensely how to do it

What's not clear to you that Bertocar, and NOT me, was leading the hardware engineers (which I was NOT part of)?
Quote:

and may even succeed

What's not clear to you about the MAY word?
Quote:

Cdmauro is giving a gigantic hand in the development of the algorithms

What's not clear to you about the ALGORITHMS word?

What's not clear to you that the guy which reported this sentence is NOT me, but the company / project / hardware engineers lead?
Quote:

Bertocar and Cdmauro can answer you on all the technical details

And here comes the mother of all lies. You reported the above sentence in bold ONLY starting from me, completely leaving out Bertocar.

So, you want that I appeared as the ONLY one answering the technical things. Which means also all the hardware related ones.

Whereas all posts clearly show that the hardware belonged to Bertocar and NOT to me.

This proves the pile of LIES that you're building against me, dear Gunnar von Goebbels: this is a perfect example of the Big Lie propaganda tactics that you're doing to confuse people and let them believe on YOUR LIES!

You're totally dishonest and liar!
Quote:

Gunnar wrote: Dear Cesare Di Mauro, The TINA team did post dozens of announcements like this. Dear Cesare, how would call an announcement of clockrate of 470 MHz of the FPGA, when the manual of the FPGA states that this model can not go over 200MHz? Quote: It has been said that TINA uses 3 processors called FPGAs which replace the 68k in effect and the other 2 fpgs will be the perfect and improved copies of the original chips mounted on the real amiga integrated graphics / video card! the 68k processor of fpga / tina will be a 68000 at approximately 470 MHz at the beginning

See above: ask Bertocar.

@matthey

Quote:

matthey wrote: @Moderators I believe spamming of off topic posts can now be added to Gunnars offenses. Over half of his posts are violations of the Terms of Service. Quote: Terms of use: ... Flame/Attacks: Do not flame! Flaming refers to derogatory, abusive, threatening, sarcastic, rude, or otherwise mean-spirited messages directed at members/users. Be cautious when using sarcasm and humour. Without facial expressions and tone of voice, they do not translate easily over the Internet in posts and may be perceived as flaming. Report the flame posts immediately to an Amigaworld Team Member so that the situation can be dealt with immediately. A warning may be issued depending on the severity of flame/attacks. Troll: Trolls show no respect for other people's opinions and deliberately crafts messages to provoke others with the intention of wasting their time and energy or just to cause anger and confrontations. There is no point in arguing with them; their minds are made up. Ignore them, and report the posts immediately to an Amigaworld Team Member. Repeat offenders may incur an instant banned. Multiple usernames: Intentionally registering more than ONE username for the purpose of using multiple usernames is NOT allowed. This includes, but is not limited to, registering a new username to avoid a ban. Using the site (for posting messages or otherwise) with more than one username is not allowed. Users that do not follow this rule will be permanently banned. Also, do not use someone else's username, even if you were given the password to it by the owner of the username. Exceptions can be made with approval of Amigaworld.net staff, for example where the username is a company name to be shared by employees. If you would like to change your username, contact the webmaster. ... Spam: Spamming the forums with senseless, inane, or empty messages to increase your post count, or simply to aggravate, will not be allowed. This includes such things as chain letters and two-word "I agree" or "me too" responses. Continually posting the same topic on a particular board, and posting the same question across several forums is also considered spamming, and is a violation of this TOS. How far will this forum be allowed to deteriorate?

I agree.

Actually Gunnar registered on this forum with the sole purpose of flaming and attacking me and you, as anyone can see by chronologically reading all his posts.

And of course continuously spamming the forum reporting and repeating lies to discredit us, as a perfect troll.

IMO this should be enough for a permanent ban of the account.

@matthey

Quote:

matthey wrote: CISC reg-mem CPUs do much better with 16 GP integer registers than load/store RISC CPUs. Rather than spilling a register to memory, they can often use variables in memory instead with a fraction of the overhead of most RISC CPUs. Some developers overlook or ignore the CISC advantages though. Some even unnecessarily bloat the code and increase encoding overhead reducing or eliminating CISC advantages. The 68060 was able to predecode most 68k instructions in a single stage/cycle of an 8 stage pipeline using a table lookup. That code is then ready for RISC like execution but has the advantage of more powerful instructions with pipelined OP+mem accesses. A similar 68k 64 bit mode could use a different table allowing optimum reencoding of the whole ISA. I would start with the field for size=8,16,32,64 bit which is a cleaner encoding scheme. The other option is to go down the x86-64 road where 64 bit ops need a REX prefix which is likely used about 40% of the time with a 64 bit OS (the average x86-64 instruction increase was ~.4 which is 40% of a 1 byte REX prefix). Maybe a 64 bit 68k would use the REX prefix less as it already has most of the integer registers it needs but the cost of a prefix is twice as much at 2 bytes and there is still a decoder overhead increase. Reencoding for 64 bit offers efficiency increases as the length of the instructions can be adjusted for the frequency of use instead of using 68000 encodings where all ops are 16 bit. A reencoded 68k 64 bit ISA could likely come very close to the same code density of the 68k 32 bit ISA and the simpler 16 bit encoding is easier to decode than the 8 bit x86-64 encoding. That's the way I see it not that anybody listens to arm chair experts.

@Karlos

Quote:

Karlos wrote: @matthey Why don't you try it then? What is stopping you from devising an optimum code-density encoding for a hypothetical 64-bit extension to 68K and implementing a basic interpreter or simple disassembler to validate it works in practise? Why should someone else have to validate the ideas of an "armchair expert"?

@Karlos

Quote:

Karlos wrote: @matthey Who said anything about real hardware? I'll ask again. If you have a vision of how to create a neat, space efficient 68K instruction set encoding for some hypothetical 64-bit extension of the 68K, why not do it? You make enormous posts about it and throw around numbers frequently while (assuming the comment is self-referential) simultaneously bemoan that nobody listens to your armchair expertise. Given that nobody else is going to do it, whether you are asking or not, you could just go right ahead and do it yourself. Define your opcode layout and write, at the very least, a basic assembler and disassembler front end or a simple interpreter for it to demonstrate it works. Show us how you would keep the code density and backwards compatibility with existing 32-bit object code of the 68K we all know and love while extending it to support 64 bit operations.

I fully agree.

Matt can also do what I've did with my architecture: disassemble and translate 68k instructions to his 68k/64 architecture and gather statistics to prove that his design is good and competitive.

Actually it's very easy to implement it with Python, by using a very nice package which derives from LLVM: Capstone. It easily allows to disassemble binaries of many architectures.

Python has also several built-in tools & types which allow to quickly collect & aggregate statistics. And some other tools to generate Excel reports, included charts.

For my NEx64T I've a Python script which disassemble tens of x86/x64 binaries, "reassemble" their instruction to my ISA, collect all statistics, generate the report, automatically open it with Excel to show me the results. And it's using all available cores to do it in parallel, shortening the time to have the results.

This allowed me to make A LOT of experiments to "adjust" / enhance / evolve the ISA according to what I've seen on the results. It allowed me to develop 10 versions of the ISA.

So, this could be a starting point, Matt. Then you can also write an assembler (derived from the above) and emulator, if you like. Or, even better, a backend for LLVM (or GCC. But it's more difficult).

@Karlos

Hello Karlos,


Quote:

Karlos wrote: @Gunnar The statement is a bit vague to me. Does it mean it's running at 470MHz or estimated to be equivalent to a 68000 @ 470 MHz? It does say "will be a 68000 at approximately 470MHz". I mean the fact it's approximate doesn't sound like they're talking about the actual clock speed. Firstly it's a bit of a weird clockspeed anyway and secondly, why would that be an approximate, rather than an exact figure?

Karlos,

if you take a look at the picture then this becomes very clear:



This TINA "fact sheet" picture clearly says the CPU would run at 400MHz with 2 instructions executed per cycle reaching 800Mips.

Do you agree they speak about real maximum clockrate?
Running a CPU with 400MHz is of course totally impossible with this FPGA
The ALTERA manual is very clear that this value is impossible.


Why do they claim the CPU would run 400-470 MHz?
If you look at the ALTERA FPGA manual, then you will also in some point find the 470 MHz number is in it.

They picked the highest number in the manual they found, without understanding what it means
and claimed their CPU would reach it.

Cesare Di Mauro,

Please tell why do you call me a liar,
when all I did was quoting a post from you and your friends?


Question:
Did you and your friends create a website advertising a vapor Amiga product,
claiming technically totally impossible values? Yes or No?

Question:
Did you and your friends post hundreds of false facts about this vapor Amiga product,
in Amiga forums? Yes or No?


Quote:

- Cdmauro (software developer) What's not clear to you about SOFTWARE word?

Cesare Di Mauro,

I hear that you said you only have software knowledge,
therefore people can not expect that the "hardware facts" that you talk about are technically correct?

What about the hardware facts that you continue to post here every day?
Shall we also not expect them to be correct?



Why do I talk about the TINA project?

No one can expect that every post a forum is correct.
Posts are often typed quickly, so misreading or mistyping is to be expected.



The TINA project was advertised for many month.
A lot of time was put into doing the website, a lot time was put into painting charts, into giving interviews, and into posting hundreds of "false TINA fact" in Amiga forums.

All KEY FACTS advertising the TINA project are wrong.

- Bus width is impossible
- memory speed is impossible
- clock rate is impossible

Please help me understand why did you ran around for month advertising a total vapor fake project?

Last edited by Gunnar on 12-Oct-2022 at 08:29 AM.
Last edited by Gunnar on 12-Oct-2022 at 07:59 AM.

@Gunnar

Quote:

if you take a look at the picture then this becomes very clear:

It would be very silly if this was stated as a fact but the wording in the picture doesn't make that claim, it states a desired goal to reach 2 in order instructions per cycle at 400-500MHz but makes it clear that they don't know (at the time) if it's possible and need to evaluate it.

I agree that they shouldn't have been throwing around hypothetical figures like this until they knew the actual specification of the FPGA they intended to use, but just perhaps, they were looking at more than one option.

_________________
Doing stupid things for fun...

@Karlos

Hello Karlos,

Quote:

I agree that they shouldn't have been throwing around hypothetical figures like this until they knew the actual specification of the FPGA they intended to use, but just perhaps, they were looking at more than one option.

I see where you com from… I
You think they were not sure which FPGA to use?



This was not the case:
Cesare and his friends were very specific which FPGA they use.
And very clearly posted false facts for it.
Please take a look at the TINA website.


They posted they use three ALTERA CYCLONE 4, 30K C8
And they very clearly claimed an impossible clockrate of 470 Mhz.
You can see the 470MHz printed in each of the 3 FPGA in the picture.
And they claimed a totally impossible 128bit memory bus.

The whole thing is technical nonsense.
Their claimed internal 128bit bus is impossible too.


The false claimed clockrate of 470 MHz, is not a small mistake.
This is about 3 times more than what is technically possible with this FPGA family.

The false claimed 128bit memory bus is not a small mistake.
This is 4 times more than what this FPGA can do in reality.



Claiming 400% more than possible is not small mistake.
This is not like you brag "my car runs 130 miles/hour"
while in reality your car does only do "120 miles/hour".

This is like bragging "my car runs 480 miles per hour"
And you give interviews claiming this.
You making a website to claiming this.
And posting hundreds of forums repeating this false claim.!

Last edited by Gunnar on 12-Oct-2022 at 10:36 AM.
Last edited by Gunnar on 12-Oct-2022 at 10:29 AM.

@Gunnar

That's definitely less ambiguous.

Quote:

They posted they use three ALTERA CYCLONE 4, 30K C8 And they very clearly claimed an impossible clockrate of 470 Mhz. And they very clearly claimed a totally impossible 128bit memory bus. The false claimed clockrate of 470 MHz, is not a small mistake. This is about 3 times more than what is technically possible with this FPGA family. The false claimed 128bit memory bus is not a small mistake. This is 4 times more than what this FPGA can do in reality.

I am in no position to disagree as this isn't my area of expertise. I found a datasheet for the SKU referenced in the diagram here https://pdf1.alldatasheet.com/datasheet-pdf/view/536410/ALTERA/EP4CE30F23C8N.html - but I'm not sure how it supports the claims of either side. There are 484 pins on the package and I assume they aren't all freely assignable. It does very clearly state the maximum DDR2 SDRAM memory interface is 200MHz though.

Last edited by Karlos on 12-Oct-2022 at 10:45 AM.

_________________
Doing stupid things for fun...

@Karlos

Hi Karlos,

an FPGA is a chip with different types of elements/units in it:
your total maximum speed can never by faster than the slowest of these units.

The units are:
a) PLL (a unit that can generate and sync to a clock)
b) LE =Logic element. With logic elements you create most of the operations in the FPGA
With a single LOGIC ELEMENT can do just a single BIT 1+1 ADD.
To create more complex operations (than a 1 bit ADDER) you need to chain more logic elements together. As more you chain together as longer to total operation will take.
This means the maximum clockrate that single bit add could at maximum reach
is significantly higher than a real world 32Bit ADD (like you want in a CPU) can ever reach.
For example for a 32bit adder you need to chain 32 LE together.

c) SRAM memory blocks. The internal SRAM blocks are needed to create internal buffers like Caches, Register or Color Palette units.
d) MULTIPLIERS - as the name says
e) Routing - routing means wiring.
Signals from one LE also need to be wired to another LE.
Or Data from the SRAM need be wired to another unit / part of the chip = ALU in the chip
The time for wiring is very significant.
f) IO, ios are data input, output pins. Also these have maximum rating, this get little complex in details as the FPGA has differen banks of different IOs and they have different performance.

If you want to make a CPU, then you need to look for the lowest number of all.
This means if your Cache memory for example can at max reach 200Mhz, then you caches, or Register or Palette units can at maximum reach 200Mhz - and this is without time taking for routing/wiring.

If your MULTIPLIER can at maximum reach 200 MHz then you will have problem building multiplier units faster than this. And in real would you also need to account for routing.

And so on and so forth

The 472 MHz max is a value from the PLL information.
That our PLL can maximum sync to 472 MHz, does not mean that your memory, your multiplier or your ADDER, or your ALU, or your decoder can ever reach this.

The maximum values for Multiplier and SRAM are clearly printed in the Manual.
They are 200/220 MHz respectively. This means you can not make a CPU clock faster than this.

And these are maximum values already, without any time included for wiring.

Last edited by Gunnar on 12-Oct-2022 at 02:59 PM.

Since it got digged in all the feces you're smearing at each other:

I wanted to run "bustest" on my AmigaOne to verify those numbers mentioned earlier here but I only found the 68k version. Can somebody please point me to the PPC build of "bustest" because I don't want to measure the performance of the emulation layer, after all I want fair and correct results.

@Karlos

Quote:

I am in no position to disagree

You can also look at it the other way:
The FPGA is from the same company and has the same speed as the one used in the MIST.
The Minimig core is the CPU that he wanted to use.

This Minimig core reaches in the Mist ~40MHz.
He promised to reach ~ 470 MHz and to improve the core to not only do 1 instruction per cycle but 2 instead.