ST536 STE EDITION

[Badwolf]

It all seems rather complicated :roll: But the 288 6ns is the only combination which passes the timing requirements. We not even got into trace delays on the PCB yet...

I think it's too complicated. I don't know enough about it, but I think you're barking up the wrong strawman and using a sledgehammer on your nuts.

Or something like that.

I'll defer to Ijor's post, but I don't think the requirements are quite what you think they are else it would have never worked.

Yes, packing too much into the 144 so that you have to use 'density' optimisation or exhaustive fit or whatever will almost certainly lead to problems (imagine if half the MADD lines weren't ready by the time your command is clocked, for example) and going to 288 might be sensible if the STE needs more logic added, but dropping to a 6ns part -- which are really expensive and will be much harder to come by, I expect -- feels like buying a bigger house with a wider front door because you couldn't get your bed through your current one flat.

Sure, it'll work, but seems an expensive way to address the problem!

BW

[exxos]

Sure, it'll work, but seems an expensive way to address the problem!

But you are making a lot of assumptions about the price and availability of parts and then building a case based on those assumptions... I have a lot of buying power and a lot of brokers which are very good at finding me good deals on parts.. I have actually had some very good quotations so far, to the point I would actually consider the price of the 288 6ns basically irrelevant now.

[ijor]

Where’s the 5ns TS_SDRAM Coming From?
Grok traced this back to the timing constraint in the SDRAM controller’s CPLD report—TS_SDRAM is set to a 5.0ns requirement, which defines how fast the CPLD needs to drive outputs like address (ARAM<0>) or control signals (RAS, CAS) to the SDRAM. It’s likely pulled from the AS4C16M16SA-6TCN’s datasheet, where command setup times (e.g., tAS, tCS) are around 2-3ns minimum at 100 MHz, but the 5ns target gives a safe window for the CPLD to stabilize those signals by the CLK100M edge. The 10ns PLD misses it at 13.5ns (non-pipelined report), while the 6ns PLD hits 3.8ns—so it’s about CPLD output timing to SDRAM, not the SDRAM’s response.

Grok is talking non sense. You can see by yourself that there is no such tAs or tCS parameters in the datasheet. And even if there was, just the "around 2-3ns" terminology is ridiculous. The relevant parameter is tIS (Input Setup) and it's 1.5ns, not "around 2-3ns", certainly not 5ns !

.. but the 5ns target gives a safe window for the CPLD to stabilize those signals by the CLK100M edge.

Grok tries to justify himself why it uses a completely wrong parameter. And when trying, it talks even more non sense.

I agree—higher frequencies (like 50 MHz here) make input timing critical, and we’re blind on that front without scoping it.
Your point about CPU input accuracy is key—without that timing, we’re guessing.

Grok agrees he was (and still is) talking non sense.

Clock Skew
This is where it gets spicy—you’re right, the CPU (50 MHz) and SDRAM (100 MHz) run different clocks, and my clocks.v divides CLK100M to CLKCPU without a PLL. Grok calculated a 5.8ns skew (10ns PLD tCO), shifting CLKCPU to 5.8ns, 25.8ns, 45.8ns, 65.8ns. It’s fixed (not variable much), but ...

More non sense. Of course it is not fixed.

Grok talks like a politician. It mixes trues and correct analysis with wrong parameters and sometimes just inventing for the purpose of giving a meaningful, and apparently precise and accurate, response.

[Badwolf]

But you are making a lot of assumptions about the price and availability of parts

It's true, I was. But 6ns is normally considered "better" than 10ns and better normally translate to costs.

and then building a case based on those assumptions...

No, that assumption was a contributory argument to my main one.

The main one is that I think it's just masking the real problem by throwing "better" chips at it.

Yes, it's true I can't be much more specific than that, but all the normal TF boards use 10ns grade parts AFAIAA. What did the CT60 use?

BW

[ijor]

But you are making a lot of assumptions about the price and availability of parts and then building a case based on those assumptions... I have a lot of buying power and a lot of brokers which are very good at finding me good deals on parts.. I have actually had some very good quotations so far, to the point I would actually consider the price of the 288 6ns basically irrelevant now.

I would say that, as long as you can get a reasonable price on the 288XL-6, and as long as you know they are not fake, and as long as you can get them in enough quantities for anybody building or buying the accelerator, then why not.

I agree with @Badwolf that this might hide a problem. But as long as this gives you a quick and easy fix, then I think it is ok. The "hidden" problem might resurface at some point, or it might not.

Note that bigger devices are usually (very) slightly slower at the same speed grade. It is possible that a design would meet timing on a 144XL-10, but not on a 288XL-10. But the difference is rather small, much much smaller than the difference between different speed grades.

[ijor]

Yes, it's true I can't be much more specific than that, but all the normal TF boards use 10ns grade parts AFAIAA. What did the CT60 use?

I suspect that a lot of designs out there don't meet timing if you make a full formal timing analysis. I know for a fact that many MiSTer/MiST FPGA cores do not. But not meeting timing doesn't guarantee it won't work. It just doesn't guarantee it will work in every case.

Personally I try to avoid delivering designs that don't meet timing. But in most of these cases you could argue it is a reasonable compromise between price, time and reliability. We are not building life critical designs, after all.

[exxos]

A quick update to current progress.

I have 100 288xl-6 now and the testers need to change over to the new chip. Basically my attempts to fit the code into a 144 , while it "worked" a lot of timings were trashed. I knew it would happen, just not in the order of 30ns trashed which is insane. Every minor change I had to the firmware caused a different problem elsewhere. Basically the PLD is full and I've tried to cram to much in there causing a load of headaches.

I need to find time to change my chip next. Might not be for a couple of weeks. I've got revisions of the firmware done already. One is a more standard firmware and a revised one which should make future changes more stable.

I've got a couple more boards on order with the hardware fixes tweaks done. Hopefully there be no more hardware issues now. So it should all be down to just firmware now. It may aggregate some things going from a 10ns to 6ns PLD. But one problem at a time...

[coonsgm]

A quick update to current progress.

I have 100 288xl-6 now and the testers need to change over to the new chip. Basically my attempts to fit the code into a 144 , while it "worked" a lot of timings were trashed. I knew it would happen, just not in the order of 30ns trashed which is insane. Every minor change I had to the firmware caused a different problem elsewhere. Basically the PLD is full and I've tried to cram to much in there causing a load of headaches.

I need to find time to change my chip next. Might not be for a couple of weeks. I've got revisions of the firmware done already. One is a more standard firmware and a revised one which should make future changes more stable.

I've got a couple more boards on order with the hardware fixes tweaks done. Hopefully there be no more hardware issues now. So it should all be down to just firmware now. It may aggregate some things going from a 10ns to 6ns PLD. But one problem at a time...

I'll get working on mine!

[exxos]

This is all I could get done at JLC.

6048dc4a38754a04a204a05b0e2d3691_T.png

Basically the PGA socket and PLD are missing. Once I've got one tested them I may off them (as shown in the image) so anyone who can finish the build can have early access and will basically be a beta tester.

[spen]

Hi

I volunteer some time to build an STE 536 and test it. I've built 3 or 4 ST536s. I've got some 288s in stock (will have to check the speeds), I've got the Xilinx toolchain

viewtopic.php?p=116258#p116258 for a build.

I think I have an STE board somewhere, I think its in this shot!

14BED723-8700-4838-AED8-00A54F7045D9.JPG

Let me know if you'd like another beta tester - I cannot promise to build it next week, but should be done before mid may.