Flashy clock buyers interests

All the good stuff hardware and software wise for the Phoenix H5 series motherboards.
User avatar
exxos
Site Admin
Site Admin
Posts: 23498
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Flashy clock buyers interests

Post by exxos »

JezC wrote: Fri May 13, 2022 11:25 am In which case, how about your older 16MHz accelerators (v1 or v1.5 etc.)?
And I was trying to avoid that discussion as well :lol:

But it is a similar problem. Is there any use in spending time on that series making it work with flashy when there is the DSTB1 in active development for people which is open source. The accelerator has to be told to run faster on alt-ram access. In previous boosters it is just not going to be possible. My current 16MHz booster just does not have enough IO for it. I was trying to keep it as a low-cost solution and struggled to mash it all into a small PLD. It actually at some multiple "hacks" on it as I was like 5 IO's short.

If enough time and money was thrown at things then sure they could all be made to work together. But I do not really want to start doing even more projects as I cannot even finish the ones I already started. My store soaks up all my time as I have said before. It leaves me very little time for development these days :(

As @Badwolf has found out, just because something works in one machine does not mean it will work in another. If you multiply this by several projects and trying to get them all to work together, you create yourself a ongoing nightmare :lol: Again it is why I simply " abandoned" doing anything with original machines anymore. Just look at all the threads of people with malfunctioning machines and then trying to get multiple add-ons to work which turns into a ongoing nightmare as well.

Point being that the DSTB1 is going to be the "low cost" accelerator for the H5 until the SEC booster gets done. Which will then be a extremely fast and also extremely expensive accelerator. But again I am not really doing this for the H5 platform as such. It is just a personal project to see what speed I can get a 68K up to. I will make a small number of boards if people want them both realistically there is not that many people who will want one. Plus like I said, the SEC is really just a stepping stone board for working out the kinks on a high-speed system for when we get back to the FPGA cores. The SEC booster will be the CPU used still, but alt-ram will be obsolete at that point anyway.

The H5 is a new platform with everything designed and tested specifically for it. If you want to add some features then you plug it in and you are done. Problem being that there is only really myself and @Icky working on the H5 addons and neither of us have a lot of time to spend on it at the moment. Plus usual parts shortages have hampered efforts as well.. But anyway getting off topic..Overall I'm just trying to " clear the decks" of all outstanding projects so I can concentrate on the FPGA cores.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
Badwolf
Posts: 2231
Joined: Tue Nov 19, 2019 12:09 pm

Re: Flashy clock buyers interests

Post by Badwolf »

As Exxos says, DSTB1 ought to be able to be made to work with anything -- the firmware's cheaply reflashable and open source.

Of course the practicalities are such that someone who genuinely wanted to do something unusual would have to tweak the firmware themselves. That means 1) know a bit of verilog 2) download the tens-of-GB ISE package 3) somehow get that which you downloaded in 2) to run 3) flash it 4) test it.

I know Frank's struggling to get just step 3) and 4) going with his DFB1 (guess what? SDRAM problems -- the acceleration's just fine). So even just reflashing needs a bit of research if you're not comfortable with that kind of thing.

BW

PS: technical diversion which probably has more effect than any of the above in real terms:-

The big issue with acclerators and AltRAM is at which speed do you address them?

Naively you might think that a nice simple SRAM AltRAM board would simply listen for its address range, activate its chip and issue DTACK the data is ready.

This will work brilliantly and reliably. But you'll never get the theoretical throughput from your RAM. You need your RAM to be even faster to make up for it.

Why? Let's look at a read cycle.

With the 68000 DTACK becomes eligible to be sampled a full one and a half CPU clock cycles after the memory access starts (AS goes low). Data, however is not latched until a further one full clock cycle has passed.

So firstly, there is a minimum of two (and a half) clock cycles per read from the point that our AltRAM can start to respond. That's fine. it's an eternity when our (normally much faster) SRAM can respond. At 8MHz it's, say, 250ns.

That is a minimum, however. That would be the best case if DTACK were lowered either immediately or on the first clock edge seen after AS.

Now let's say you have, for the sake of argument, 100ns RAM. If you wait until the RAM is ready on the databus and assert DTACK, you'll still meet the above timings at 8MHz. DTACK will go low 100ns after AS, that's one clock cycle later which is just before DTACK is sampled: perefct. You'll get your 4MB/s AltRAM and we're all happy.

But if the CPU is now running at 16MHz, 100ns later is now *two* clock cycles after AS has gone low. The first cycle that's eligible for DTACK detection, DTACK is still high as the data's not yet valid. The CPU will have one wait state added to its bus cycle. You won't get your 8MB/s AltRAM, you'd only get 6MB/s. Better than a kick in the bum, but we're wasting cycles!

After all, the data is not latched when DTACK is sampled low, it's latched one cycle later. So in order to get the best speed, we should assert DTACK one cycle earlier than when the data will actually be valid on the databus.

If we do this, we have no wait states. The CPU latches the data at the earliest moment (125ns after we notice AS goes low). 8MB/s ish.

So that's great. Problem solved.

No, it isn't. What if the CPU is now 32MHz (and bear in mind SEC has been working beyond 64)? Well at 32MHz, data will be latched by the CPU only 31ns after DTACK is sampled low. If we stuck to the timings above, that would be around 94ns after we notice AS goes low.

...but in our hypothetical model, we have 100ns RAM.

So our AltRAM, as designed, works with 100% efficiency up to about 25MHz, where it suddenly stops working.

In other words, for best speed, every AltRAM board must be tailored to the CPU's speed.

If you RAM is sufficiently fast, you can 'play safe' and assert DTACK only after data is valid on the bus and it'll be fine at slower CPU speeds. It will work at all speeds, but efficicency will drop off at higher speeds. You'll never get the theoretical max speed out of the RAM chip, but you hope that it's a fair trade off.

This is why I've got a 66MHz oscillator on DSTB1 even though it only runs at 16MHz. It's so the RAM goes as fast as it theoretically can so I don't have to second guess the processor. But as CPU speeds get nearer 32MHz, the read rate stops scaling proportionally.

Long and the short: no matter what the board, no matter what the RAM technology used, unless the RAM is really fast (and therefore expensive) you'll either be optimising for the slow end or the fast end of the accelerator curve.

...and then you have to consider DMA. :lol:
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
User avatar
exxos
Site Admin
Site Admin
Posts: 23498
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Flashy clock buyers interests

Post by exxos »

Badwolf wrote: Fri May 13, 2022 12:42 pm ...and then you have to consider DMA. :lol:
..and PLD delays :lol: :hide:
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
exxos
Site Admin
Site Admin
Posts: 23498
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Flashy clock buyers interests

Post by exxos »

sporniket wrote: Fri May 13, 2022 2:25 pm ... and PLD limited size of gateware (as "all logic element used")
Have you been reading my posts again :lol:
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
ijor
Posts: 428
Joined: Fri Nov 30, 2018 8:45 pm

Re: Flashy clock buyers interests

Post by ijor »

Badwolf wrote: Fri May 13, 2022 12:42 pm This is why I've got a 66MHz oscillator on DSTB1 even though it only runs at 16MHz. It's so the RAM goes as fast as it theoretically can so I don't have to second guess the processor. But as CPU speeds get nearer 32MHz, the read rate stops scaling proportionally.

Long and the short: no matter what the board, no matter what the RAM technology used, unless the RAM is really fast (and therefore expensive) you'll either be optimising for the slow end or the fast end of the accelerator curve.
I am probably starting to sound like a broken record. But, IMHO, the right approach is to use a faster and more powerful CPLD/FPGA. Forget the XC9500XL. Use a modern CPLD instead, and then you can easily clock the SDRAM at 133 MHz (or even faster).
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
User avatar
Badwolf
Posts: 2231
Joined: Tue Nov 19, 2019 12:09 pm

Re: Flashy clock buyers interests

Post by Badwolf »

ijor wrote: Fri May 13, 2022 3:35 pm I am probably starting to sound like a broken record. But, IMHO, the right approach is to use a faster and more powerful CPLD/FPGA. Forget the XC9500XL. Use a modern CPLD instead, and then you can easily clock the SDRAM at 133 MHz (or even faster).
Clocking it faster doesn't result in faster random access. Once you're past 66MHz you have to start adding idle states.

Even if it did, you'd just be pushing the problem further away. It doesn't actually solve it.

The problem would in theory still exist with 10ns SRAM, although you'd never see it with a 68k. Not unless you could clock an FPGA one at 200MHz or so. ;)

BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
User avatar
JezC
Posts: 2081
Joined: Mon Aug 28, 2017 11:44 pm

Re: Flashy clock buyers interests

Post by JezC »

exxos wrote: Fri May 13, 2022 11:52 am
JezC wrote: Fri May 13, 2022 11:25 am In which case, how about your older 16MHz accelerators (v1 or v1.5 etc.)?
And I was trying to avoid that discussion as well :lol:
No, again, that's fine - if we can get the DSTB1 to work in the meantime (i.e. until the SEC booster is ready) then that will be a plus.

For my personal applications, I will have to see what s/w will work with (and make use of) the additional features (68030, faster 68k, Alt RAM etc.) & that will let me decide what I keep in the different remake systems for the future.

It's not like I have enough hobby time to be held up by the arrival of these new add-ons anyway :lol: :roll:
ijor
Posts: 428
Joined: Fri Nov 30, 2018 8:45 pm

Re: Flashy clock buyers interests

Post by ijor »

Badwolf wrote: Fri May 13, 2022 3:47 pm Clocking it faster doesn't result in faster random access. Once you're past 66MHz you have to start adding idle states.
So? Even with idle cycles you can still easily service a CPU at 32 MHz. You will probably need to latch the SDRAM data in the worst case, which is not a big problem once you have a more powerful CPLD.
Even if it did, you'd just be pushing the problem further away. It doesn't actually solve it.
Well, it obviously depends on how fast you want to go. If you are going with a CPU at 64 MHz or beyond you might need a different type of approach. Probably optimizing for a non random access plus cache. I doubt it is worth to use static ram.
The problem would in theory still exist with 10ns SRAM, although you'd never see it with a 68k. Not unless you could clock an FPGA one at 200MHz or so. ;)
Why you would need a 200 MHz FPGA for 10ns SRAM?
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
User avatar
Badwolf
Posts: 2231
Joined: Tue Nov 19, 2019 12:09 pm

Re: Flashy clock buyers interests

Post by Badwolf »

ijor wrote: Fri May 13, 2022 4:31 pm
Badwolf wrote: Fri May 13, 2022 3:47 pm Clocking it faster doesn't result in faster random access. Once you're past 66MHz you have to start adding idle states.
So? Even with idle cycles you can still easily service a CPU at 32 MHz. You will probably need to latch the SDRAM data in the worst case, which is not a big problem once you have a more powerful CPLD.

Why you would need a 200 MHz FPGA for 10ns SRAM?
Ijor, I don't think you've understood what I've said. At no point have I said the SDRAM is too slow.

I've said with ANY RAM, because of the way the 68k latches data after DTACK, there will come a point where you either have to optimise for a clock speed or accept you will never achieve your theoretical ram speed. SDRAM, SRAM, DRAM, manually assembled banks of flip flops.

Also, but irrelevantly to what I said, clocking the SDRAM faster doesn't help at all with 68000. We don't have a burst mode or any kind of cache to fill!

What's the random column access time of an SDRAM chip at 133MHz versus my chip at 66MHz? I'll tell you: it's (virtually) the same. 66MHz has been chosen especially because of that.

BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
Post Reply

Return to “PHOENIX ZONE”