|
|---|
Marcel Verdaasdonk
Netherlands
| |
Posts 3991
23 Feb 2012 17:52
| So instead of a round robin in hardware we would be shifting towards a FIFO with dynamic priority then? Sounds like the arbiter would just be a reincarnation of ANGUS.
| |
Nixus Minimax
Germany
| |
Posts 275
23 Feb 2012 18:24
| Marcel Verdaasdonk wrote:
| So instead of a round robin in hardware we would be shifting towards a FIFO with dynamic priority then?
Sounds like the arbiter would just be a reincarnation of ANGUS.
|
Sorry, I don't get what you are saying.
Memory is a resource with a limitation that only one access can be handled at a time. The arbiter has the purpose of deciding what part will get access to the memory when there are more than 1 instances trying to access memory at the same time. IIRC in the classic Amiga arbitration is simple and fixed: one memory cycle will go to the CPU, the next memory cycle to the custom chips regardless of whether the CPU or the custom chips actually need and request access or not. This rigid concept should be replaced by a more powerful one because obviously a CPU working entirely in fastmem or caches should not get chipmem slots assigned when it doesn't need them and which therefore cannot be used by the custom chips and vice versa.
Thus, arbitration rules are needed. A simple one would be that the custom chips always have to give way to the CPU. More complex ones can be devised easily, I gave some examples. I'm sorry if Angus can do all of this, I simply don't remember, my active Amiga years ended fifteen years ago.
Now if the arbitration rules can be changed to a certain degree during run-time, this would mean even more flexibility. I cannot see how this would be something like a FIFO with dynamic priority, whatever that means. I'm also not sure whether a round robin in (FPGA) hardware could be fast enough to be used for current RAM speeds.
The good thing about the FPGA implementation is that we can pass all type of additional information to the arbiter like a priority indication resulting from internals of the soft-CPU or the custom chips. E.g. a read request from the custom chips for display data would have the highest priority because obviously the data needs to be fetched in time. The CPU could request reading from a specific address with a high priority if the pipeline stalls due to the read or request the read with a low priority if it does not. In the FPGA implementation all this could be indicated to the arbiter. This would be impossible in an implementation using an existing 680x0 chip.EDIT: I just read this EXTERNAL LINK
You are right that Angus does what I imagine the arbiter would do. See the table http://en.wikipedia.org/wiki/MOS_Technology_Agnus#DMA_Channels In the comments it is said that the blitter "yields 1/4 cycles to CPU when BLTPRI not active". In my understanding this means that when the blitter is inactive, 3/4 of the blitter cycles will remain unused. IIRC all copper cycles will remain unused if the copper is inactive. So even though there is some rudimental arbitration in Angus, it can be improved on a lot. Please correct me if I'm wrong and Angus could also assign memory slots freely: a) to the CPU if the blitter/copper were inactive and the CPU requested chipmem
b) to the blitter if the CPU did not request chipmem and the custom chips needed memory access
c) to either the CPU or blitter/copper following flexible rules when both CPU and blitter/copper were active and requested access to chipmem
| |
Nixus Minimax
Germany
| |
Posts 275
23 Feb 2012 19:04
| Okay, I did some more reading. It seems my memory of bus arbitration in the classic Amiga is quite wrong. This is what I have just read:
- a maximum of 50% of the chipmem cycles can go to the custom chips
- the CPU can have the remaining 50%
- the CPU can also have unused chipmem cycles
- if the custom chips are accessing chipmem, the CPU will be put on hold by Angus
- if the custom chips (e.g. Copper) are inactive, the do not eat memory cycles
- arbitration within the 50% of the chipmem cycles where both CPU and custom chips can access chipmem is simple and fixed (I haven't figured out how it is done, though)So yes, my understanding of the arbiter would be equivalent to a super-fat-Angus.
| |
SID Hervé
France
| |
Posts 666
23 Feb 2012 19:46
| This issue is interesting.
I have already tried to submit it with other terms (my poor English ...)
But, after reading and rereading the HRM (again thank you Marcel), I wonder if there would be an obvious gain, I have no idea.
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3991
23 Feb 2012 19:51
| Nixus Minimax wrote:
|
Okay, I did some more reading. It seems my memory of bus arbitration in the classic Amiga is quite wrong. This is what I have just read:
- a maximum of 50% of the chipmem cycles can go to the custom chips
- the CPU can have the remaining 50%
- the CPU can also have unused chipmem cycles
- if the custom chips are accessing chipmem, the CPU will be put on hold by Angus
- if the custom chips (e.g. Copper) are inactive, the do not eat memory cycles
- arbitration within the 50% of the chipmem cycles where both CPU and custom chips can access chipmem is simple and fixed (I haven't figured out how it is done, though)
So yes, my understanding of the arbiter would be equivalent to a super-fat-Angus.
|
Again your off, but not by that much.
-First of all the chipset can take the whole memory bandwidth if it is required to by blocking out the CPU.
-Second the Chipset actually by design get the spare cycles to memory the CPU don't need, this was a miss conception when they shifted to the later 68K family CPU's.
-it's not a if it's a when the Chipset access the memory it locks out the CPU.
- again When inactive, this isn't programming. ;)
-in the appendix of the programmers manual there is a time line with each slice of a scan line about 280 slices IIRC. Because it is fixed i called it a hardware round robin. ;)
a FIFO like Stack is more effective if used correctly and if allowed sorting without too much trouble.
Basically i have said this idea before line up the sequential addresses and Have the most affect of bursts. ;)
| |
Rune Stensland
Norway
| | (MX-Board Owner)
Posts 871
23 Feb 2012 22:34
| Thomas relased a new chipset version today Release MXC 35.20. He fixed a bug in the diskdrive logic that caused some problems at boot. Now my natami is booting everytime with no locks. I also managed to configure and test a 128mb chipmem setup. and it seems to work. 4-5 hours without a single crash@100mhz. Amazing guys!!
| |
Evil Igel
Germany
| |
Posts 154
24 Feb 2012 18:57
| Rune Stensland wrote:
|
Thomas relased a new chipset version today Release MXC 35.20. He fixed a bug in the diskdrive logic that caused some problems at boot. Now my natami is booting everytime with no locks. I also managed to configure and test a 128mb chipmem setup. and it seems to work.
4-5 hours without a single crash@100mhz. Amazing guys!!
|
Niiiiiiiiiiice :-D
Step by Step we are heading for a something REALLY special piece of hardware the big C= never did (or dare :-))!
| |
Chris Dennett
United Kingdom
| |
Posts 135
25 Feb 2012 16:24
| Great news :) Keep it coming! :D
| |
Byte Ryder
Portugal
| |
Posts 2
26 Feb 2012 19:30
| Rune Stensland wrote:
|
I also managed to configure and test a 128mb chipmem setup. and it seems to work.
|
Did you say 128MB chipmem?! :D~~~
| |
Rune Stensland
Norway
| | (MX-Board Owner)
Posts 871
10 Mar 2012 17:58
| Gunnar is back with checkins in the svn:)) hopefully we can get some more public news on the n050 soon..
| |
Joe M
Norway
| |
Posts 500
10 Mar 2012 18:33
| That's great news!
| |
Erik Bauer
Italy
| |
Posts 301
11 Mar 2012 00:03
| Rune Stensland wrote:
|
Gunnar is back with checkins in the svn:)) hopefully we can get some more public news on the n050 soon..
|
Cool!
| |
Lord Aga
| |
Posts 129
11 Mar 2012 11:00
| Rune Stensland wrote:
|
Gunnar is back
|
Yeah baby :)
| |
Carsten Roth
Germany
| |
Posts 39
11 Mar 2012 11:07
| Very good that Gunnar is here again, i missed his posts in the forum. He had always taken a lot of time to give detailed answers to the questions here.
| |
Rune Stensland
Norway
| | (MX-Board Owner)
Posts 871
11 Mar 2012 14:06
| Gunnar is to busy to post at the forum at the moment.. I guess he found out that it's impossible to win an argument on the internet even if he was right most of the time.. I have learned alot from Gunnar on the posts on this forum, and he motivates the team with his commitment. In the demoscene I would call gunnar "Elite". Now he is spending his spare time together with Jens to create the fastest 68k cpu ever.
| |
Carsten Roth
Germany
| |
Posts 39
11 Mar 2012 14:53
| Rune Stensland wrote:
|
Now he is spending his spare time together with Jens to create the fastest 68k cpu ever.
|
I wonder what would freescale say about this work, if they observe the project ?
| |
Adrian Browne
Ireland
| |
Posts 173
11 Mar 2012 20:28
| Rune Stensland wrote:
|
Gunnar is to busy to post at the forum at the moment.. I guess he found out that it's impossible to win an argument on the internet even if he was right most of the time.. I have learned alot from Gunnar on the posts on this forum, and he motivates the team with his commitment. In the demoscene I would call gunnar "Elite".
Now he is spending his spare time together with Jens to create the fastest 68k cpu ever.
|
Good news!All hands on deck so to speak.
| |
Jakob Eriksson
Sweden
| | (Moderator)
Posts 1097
11 Mar 2012 21:01
| And not on holodeck. :-)
| |
Matt Hey
USA
| |
Posts 737
11 Mar 2012 21:42
| Carsten Roth wrote:
|
I wonder what would freescale say about this work, if they observe the project ?
|
"It is only a nice story when Gunnar tells that we had a conversation with the ColdFire/M68k Division Manager of freescale. That we asked him if a custom made MC68060 with higher speed than the classic ones could be available. When he declined we got on asking if we could at least get/license some source HDL code to use in an FPGA. He told us that the MC68060 is built in some kind of HDL source. He regrets but it is absolutely not possible to get/see/license this code for anybody in any form. The only thing he could do is to provide us contacts to companies who sell 68k IP cores. Freescale itself doesn't do this, it is not their business. Then Gunnar asked him what might happen if we wrote our own IP. He said that Freescale will not have a problem with that and that, in his opinion, we do not need any permission from Freescale even if we are about to sell it. But we can not expect any technical help or support from Freescale when we decide to do so.
This is just a story which happened some time ago. We do not need prove or evidence of that. This only (sadly) shows that this is the end of the road for the 68k. The business of this division of Freescale is to sell competitive embedded ColdFire chips, not software. These chips *must* not compete with faster PowerPC which is a different division at Freescale. As said, in the real world they would only sue us for money, not for fun. It would be money if we decide to sell 68k compatible chips running at 600MHz at a price of 1,5$ per piece. Then the discussion here might be justified. But it is not because we won't because we can't.
I just wonder why AMD is still selling x86 compatible CPUs. Ah, right, I forgot. They use a completely different opcode than intel.
Meaning that it might be worth continuing this discussion. Since we AND Freescale are not really involved because both do not have a problem with this topic I would emphasize to discuss whether an opcode is copyrightable or patentable in talk, not as an NatAmi question. For now Freescale does not have any interest in high-speed 68k. The moment this changes we are the first to get a 2GHz 68k dual core and just drop the softcore '50 (sorry Gunnar/Jens) and get the chip mounted onto a SyncZorro card. But immediately." -Thomas Hirsch
CLICK HERE
| |
Adrian Browne
Ireland
| |
Posts 173
11 Mar 2012 21:43
| Jakob Eriksson wrote:
|
And not on holodeck. :-)
|
No not on holodeck.No virtual simulations here.Mr data.Make it so.Engage!
| |
|
Welcome to the Natami lounge.