Terriblefire Bug Hunt

Help & news on accelerators from TF, Amiga, Atari, CD32 etc

Moderators: terriblefire, Terriblefire Moderator

foft
Posts: 317
Joined: Mon Mar 28, 2022 12:20 pm

Re: Terriblefire Bug Hunt

Post by foft »

terriblefire wrote: Fri Nov 04, 2022 9:59 pm
foft wrote: Fri Nov 04, 2022 9:19 pm TF1260: Improved SDRAM timing, it seems a little marginal. The maximum speed seems to vary more based on the SDRAM chip than the CPU.
What is this based on? the SDRAM timings are timed to be max spec at @100Mhz.

The TF1260 timings are pretty much exactly this ..

https://github.com/terriblefire/tf1230/ ... _defines.v
By timings I meant q->clk, not the number of cycles.

Anyway its not based on much other than changing ram chips around boards and seeing a difference, which is of the sort I'd see with marginal timings on the FPGA boards I've worked on.

I don't know how the CPU->CPLD->SDRAM->CPLD->CPU works in this case and which clock you provide to SDRAM etc. In the FPGA systems (Chameleon, mist, mcc216 etc) its often clocked180 degrees out of phase, though of course you can find the theoretical optimal window and set the pin timing constraints appropriately.
dalek
Posts: 225
Joined: Thu Nov 08, 2018 11:03 am
Location: NSW Australia

Re: Terriblefire Bug Hunt

Post by dalek »

Did the TF534 ever get the backported TF536 code? I haven't used mine in ages but as I recall there were a few whdload issues with mine I never got to the bottom of. Not the greatest bug report :lol:
terriblefire
Moderator Team
Moderator Team
Posts: 5396
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK

Re: Terriblefire Bug Hunt

Post by terriblefire »

dalek wrote: Fri Nov 04, 2022 11:15 pm Did the TF534 ever get the backported TF536 code? I haven't used mine in ages but as I recall there were a few whdload issues with mine I never got to the bottom of. Not the greatest bug report :lol:
The TF534 cannot operate the same way as the TF536 unfortunately. Its a very different approach. TF536 is a backport of the TF330 to the Tf534 essentially.
———
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
terriblefire
Moderator Team
Moderator Team
Posts: 5396
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK

Re: Terriblefire Bug Hunt

Post by terriblefire »

foft wrote: Fri Nov 04, 2022 10:41 pm
terriblefire wrote: Fri Nov 04, 2022 9:59 pm

What is this based on? the SDRAM timings are timed to be max spec at @100Mhz.

The TF1260 timings are pretty much exactly this ..

https://github.com/terriblefire/tf1230/ ... _defines.v
By timings I meant q->clk, not the number of cycles.

Anyway its not based on much other than changing ram chips around boards and seeing a difference, which is of the sort I'd see with marginal timings on the FPGA boards I've worked on.

I don't know how the CPU->CPLD->SDRAM->CPLD->CPU works in this case and which clock you provide to SDRAM etc. In the FPGA systems (Chameleon, mist, mcc216 etc) its often clocked180 degrees out of phase, though of course you can find the theoretical optimal window and set the pin timing constraints appropriately.
Its the CPU clock directly. TBH the timings have been taken to marginal for the supported chips on purpose. So we get every last cycle out of them. I've tried all the combos of phases etc. Its not really meant to work on every SDRAM chip.
———
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
foft
Posts: 317
Joined: Mon Mar 28, 2022 12:20 pm

Re: Terriblefire Bug Hunt

Post by foft »

terriblefire wrote: Sun Nov 06, 2022 2:55 pm Its the CPU clock directly. TBH the timings have been taken to marginal for the supported chips on purpose. So we get every last cycle out of them. I've tried all the combos of phases etc. Its not really meant to work on every SDRAM chip.
Perhaps its because I was 'deviating from the path' slightly. I got the AS4C32M16SB-7TCN since AS4C32M16SA-7TCN (on the bom) is no longer made. The datasheet seems identical for all important measures as far as I can tell. Anyway not all of them liked 100MHz, while the CPU itself was fine at 100MHz. This time I went for the slightly higher grade AS4C32M16SB-6TIN and ... so far so good. Perhaps just binning.
terriblefire
Moderator Team
Moderator Team
Posts: 5396
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK

Re: Terriblefire Bug Hunt

Post by terriblefire »

foft wrote: Wed Nov 09, 2022 9:08 pm Perhaps its because I was 'deviating from the path' slightly. I got the AS4C32M16SB-7TCN since AS4C32M16SA-7TCN (on the bom) is no longer made. The datasheet seems identical for all important measures as far as I can tell. Anyway not all of them liked 100MHz, while the CPU itself was fine at 100MHz. This time I went for the slightly higher grade AS4C32M16SB-6TIN and ... so far so good. Perhaps just binning.
Ok this is a little strange because you'd expect those parts to be fine at 166Mhz and the CAS/RAS timings are the same. I'd be happy to have a look into this at some point. I'll add that to the TF1260 bug list
———
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
Post Reply

Return to “Terriblefire's channel”