TF4060 Beta Program

[terriblefire]

I guess the question i have is where else to put the 128Mb? i liked having it contiguous and i liked not having it as a logical Z3 card for various reasons. Logical Z3 card would have the same issues in any case

[Oliver_A]

We all too easily forget that the 32-bit Amiga memory map dates back to 1990, a time when 128 MB, let alone 1.5 GB of Zorro III address space, was a sheer unthinkable amount of memory space. I could remember that Windows 98 on PC had issues with 128 MB of memory… ;-)

Anyway, it‘s not a matter of Z3 „seeing“ the 68030 bus transaction, but the memory slave sitting on the 68030 side seeing the Z3 bus transaction.

My interpretation of the spec is that the slave sitting on the 68030 side of the bus can not partake in any Z3<>Z3 transactions, which is the case when the A4091 targets memory located in that space. The location and range of that space is hard-coded in U714.

Sadly, I couldn‘t find the GAL sources to confirm my observation that the whole TF4060 memory is NOT in Z3 range, and thus, Buster correctly translates the ReA4091 DMA transactions, making them visible on the 68030 side of the bus.

But since it works, I don‘t question it any further. ;-)

Thanks for your intention to investigate this though!

[terriblefire]

We all too easily forget that the 32-bit Amiga memory map dates back to 1990, a time when 128 MB, let alone 1.5 GB of Zorro III address space, was a sheer unthinkable amount of memory space. I could remember that Windows 98 on PC had issues with 128 MB of memory… ;-)

Anyway, it‘s not a matter of Z3 „seeing“ the 68030 bus transaction, but the memory slave sitting on the 68030 side seeing the Z3 bus transaction.

But the spec says DMA cycles are excluded from that. i.e. whenever BGACK is low. Its not super clear i'll give you that but thats what i think it says. Otherwise how would the CPU bus snoop the cycle?

My interpretation of the spec is that the slave sitting on the 68030 side of the bus can not partake in any Z3<>Z3 transactions, which is the case when the A4091 targets memory located in that space. The location and range of that space is hard-coded in U714.

Sadly, I couldn‘t find the GAL sources to confirm my observation that the whole TF4060 memory is NOT in Z3 range, and thus, Buster correctly translates the ReA4091 DMA transactions, making them visible on the 68030 side of the bus.

But since it works, I don‘t question it any further. ;-)

I've checked the AA3000+ for this already (using address 0x12100000/ I'll check the Z3 Fastlane next).

[terriblefire]

And confirmed with the Z3 Fastlane on a 4000CR. I can DMA to/from it to both halves of the 128Mb range.

The TF memory is inside the Z3 Mem range.. I have those sources.

Code: Select all

ADRZ3   =  A31 &  A30 &  A29 &  A28 &  
           A27 &  A26 &  A25 &  A24 &
          !A23 & !A22 & !A21 & !A20 & 
          !A19 & !A18                           /* ff000000-ff03ffff */
	# !A31 & !(!A31 & !A30 & !A29 & !A28);  /* 10000000-7fffffff */

For reference the TF Memory is 0x08000000 to 0x17ffffff

[Oliver_A]

Interesting, thanks for digging that up.

So it seems that, even in case a Z3 bus master targets Z3 memory space:

* /BR is asserted by Buster on 68030 side. So even a Z3<>Z3 local transfer stalls the CPU
* Adresses and data are demultiplexed - so that the 68030 side can see them
* Buster allows the cycle to finish via STERM signal on 68030 side, in addition to DTACK on Zorro III side

Hmm, but what purpose does the ADRZ3 signal serve then??

What concerns me now is:

- What happens if a Z3 memory slave occupies $10000000 memory space?
- Will Autoconfig prevent this situation and avoid the memory space allocated by TF4060

Again, thanks for you thorough investigation!

[terriblefire]

Hmm, but what purpose does the ADRZ3 signal serve then??

It will determine whether to run the cycle out to the Z3 cards i guess. Internal cycles will not do that.

What concerns me now is:

- What happens if a Z3 memory slave occupies $10000000 memory space?
- Will Autoconfig prevent this situation and avoid the memory space allocated by TF4060

We will patch expansion.library to stop this. i'm working on this with erique. So long as the OS never allocates addresses there it will be fine. Technically its a bug if the OS does that because its already in the system pool by the time autoconfig runs. But it would not surprise me if it had completely different behaviour on 3.0/3.1/3.2/3.9

A card cannot be at that address unless the OS tells it to be. You will need a lot of cards to hit that address a the moment.

[terriblefire]

But more digging. Even though the hardware docs say the upper 128Mb of my card is in ZIII area..

Code: Select all

#define EZ3_CONFIGAREA          0x40000000      /* Zorro III space */
#define EZ3_CONFIGAREAEND       0x7FFFFFFF      /* Zorro III space */
#define EZ3_SIZEGRANULARITY     0x00080000      /* 512K increments */

If something is allocated outside this area is actually a bug.

But i guess.. Show me a system that has an issue and i'll devise a fix.

[Oliver_A]

Since it seems that the operating system only uses $40000000 upwards to assign Zorro III resources, I suppose that there are no issues with having 256MB local CPU memory. Heck, it could even be up to 896MB, if someone can find a suitable use-case for that.

So far, I am positively surprised by the stability of the TF4060. Great job! :)

What remains are (after clarifying the root cause of the A3000T instabilities - I will assist Christoph by debugging the issue with an Oscilloscope and Logic Analyzer):

* Chip-Ram Read and Write Performance could and should be improved to 7MB/s at some point (makes a significant difference for AGA games and Demos). Somewhere, there is a redundant wait-state lurking in the 060<>030 bus translator.... ;)
* Since the MEMCTRL is an FPGA, one could entertain the idea to implement a bank buffer to further cut-down first access penalties. I attempted to do this on the BFG, but the Xilinx XC95288 is not suitable for that, since it requires extra resources to implement comparators (lack of xor), easily leading to timing violations.

[terriblefire]

Since it seems that the operating system only uses $40000000 upwards to assign Zorro III resources, I suppose that there are no issues with having 256MB local CPU memory. Heck, it could even be up to 896MB, if someone can find a suitable use-case for that.

Indeed. Possibly Amix has an issue. but i had to make a decision of where to put the extra 128Mb and this seemed the least worst option.

What remains are (after clarifying the root cause of the A3000T instabilities - I will assist Christoph by debugging the issue with an Oscilloscope and Logic Analyzer):

Thanks. If i had an actual 3000T to use for a few days i'd nail it fast. it only took a week or so to nail the 4000T and that was a real PITA. Does the 3000T use the same roms as the 3000? If so i can provide a "debug" rom that spits out CBM info.

* Chip-Ram Read and Write Performance could and should be improved to 7MB/s at some point (makes a significant difference for AGA games and Demos). Somewhere, there is a redundant wait-state lurking in the 060<>030 bus translator.... ;)

This i am aware of but i want everything else rock solid before i tackle it. Oddly the code is identical to TF1260 but we have this issue. I didnt think the chipram speed issue was enough to stop the beta shipping.

* Since the MEMCTRL is an FPGA, one could entertain the idea to implement a bank buffer to further cut-down first access penalties. I attempted to do this on the BFG, but the Xilinx XC95288 is not suitable for that, since it requires extra resources to implement comparators (lack of xor), easily leading to timing violations.

Not sure what you mean by this. Do you mean keep an SDRAM row open unless we change? if so that can be problematic with the refresh cycles. 80Mb/s is not fast enough?

EDIT: This can also add a extra cycle every cycle to check if the row is open. Its not worth it IMHO.

[Oliver_A]

Indeed. Possibly Amix has an issue. but i had to make a decision of where to put the extra 128Mb and this seemed the least worst option.

Hmm, isn't Amix 68030 only? But maybe that's a rare use-case, although i might be wrong about that.

Thanks. If i had an actual 3000T to use for a few days i'd nail it fast. it only took a week or so to nail the 4000T and that was a real PITA. Does the 3000T use the same roms as the 3000? If so i can provide a "debug" rom that spits out CBM info.

An A3000T is big and heavy and can easily break your foot, so no shipping from Germany to Glasgow feasible (I suppose). ;)
Do the Lattice FPGAs provide the possibility to instantiate a logic analyzer (similar to SignalTap in Altera FPGAs) ?
Using the debug ROM might help us to track down the issue more easily, thanks! :)

I might emphasize the fact that the TF4060 is actually WORKING in an A3000T is already a big win.

This i am aware of but i want everything else rock solid before i tackle it. Oddly the code is identical to TF1260 but we have this issue. I didnt think the chipram speed issue was enough to stop the beta shipping.

Prioritizing stability first over performance is a sensible choice.

Not sure what you mean by this. Do you mean keep an SDRAM row open unless we change?

Yes exactly. You need a small buffer for that to keep track of this, and if a subsequent memory access hits an open row, you can reduce the first access penalty. It's a bit more complicated, but I think doable on the Lattice FPGA.

if so that can be problematic with the refresh cycles.

Yes, but that is not unusual. A 100MHz 060 is capable to do many consecutive memory accesses within that time frame. You can postpone a certain number of refreshes in a case when the CPU is in a state where it issues a lot of consecutive bursts (<----------ACCESS-------->REF REF REF REF<-------ACCESS---------->)

I expect that this change can push the memory access performance past 90MB/s.

80Mb/s is not fast enough?

Well, somebody needs to show all those Vampires and Emulator-Pretenders what a real, hard-earned 68060 Rev6 CPU can REALLY do. ;)
Keep up the great work!