It's always a balance.
Too low and you can't switch fast enough, too high, and the heat causes problems.

The fast chip is likely to be from a later batch (Ie smaller nodes). Later nodes ran ~3v.

There's also usually a fair bit of fat in a manufacturer voltage. They are restricted to only a couple of voltage choices by fact of the boards that exist. You can't sell a 2.5v chip into a market with 3.3v boards so you lock it at 3.3 and rate its performance based on the results at 3.3.

I guess... It's important to remember that these are analogue devices at heart, operating in a digital way. Every one is unique, but they're binned into a limited set of buckets.

pshipkov wrote on 2024-12-16, 02:53:

Not sure why it was unstable when suppling the voltage through the interposer's trimmer.

I was thinking about this while making my interposer design. Bourns trimmers are better for tolerance (+/-5%) than others, but there is a noise component as well.

So I went for inline 0.5% thin film resistors. The higher the voltage the less resistors to go through. Six options.
3.3v = 6 resistors (+/- 3% tolerance)
4.8v = 1 resistor (+/- 0.5% tolerance)

And three tantalum-polymer 3.3uf caps on the CPUs power line instead of one tantalum or ceramic 10uf. In 3.3uf, either tantalums or modern low-esr ceramics would be fine, but tantalum-polymer have the lowest ESR and don't have an explosive fail-mode.

Still yet to test the interposer. In a few weeks I need to order another socket.

myne, I'll run a few select chips at lower voltage and see what happens.

I would be surprised if the Bourns trimmer was pshipkov's previous issue. The trimmer on the buck board is much worse. Nonetheless, I need to get another one of these SXL units assembled for use with an external buck. My only SXL2-buck interposer is in a case, and with how that particular case and motherboard are layed out, I would need to remove the whole motherboard to get the CPU assembly out.

With trimmers in mind, I decided to add a mini trimmer to my stock Evergreen SXL2-66 upgrade board with a QFP CPU. Removed R10, which was 239 ohms, replaced it with the largest 0603 resistor I had (221K), and added a 12-turn 1K Bourns trim pot. While the 221K resistor isn't needed to provide electrical resistance, it was added to help hold, or sandwich, the trimmer in place.

The Evergreen interposer uses an LT1117 for voltage regulation, which according to the datasheet is an 800 mA LDO (800 mA min, 950 mA typical, 1200 mA max). I think an EZ1117A is rated for 1000 mA, so I may upgrade the VRM at some point.

I set the trimmer for 3.60 V and ran it at 85 MHz, letting Quake w/sound run in loop for 10 min. No issue so far. I plan to test it more this week. The QFP package is supposed to dissipate heat better than the PGA's, so it should be the most suitable candidate for overclocking.

To test over 85 MHz, I need to swap the motherboard. The PEM-4036YB doesn't do well above 85 MHz.

@myne
I think you are talking about something else.
These are not scoped-down derivatives from a general design, like how 486DX die with defects can be labeled and offered as 486SX.
TI 486SXL2 chips are bespoke design.

@MikeSG
Good notes.
Post a pic of what you got.

@feipoa
You have to be very careful how you handle that added trimmer to the Evergreen interposer.
Maybe Loctite it to the PCB.

pshipkov wrote on 2024-12-16, 20:25:

@myne I think you are talking about something else. These are not scoped-down derivatives from a general design, like how 486DX […]
Show full quote

@myne
I think you are talking about something else.
These are not scoped-down derivatives from a general design, like how 486DX die with defects can be labeled and offered as 486SX.
TI 486SXL2 chips are bespoke design.

Ah right. Texas instruments.
I was mostly taking in general about binning, albeit didn't realise it was Ti.
The point about voltages remains. It is definitely possible less can be more, but obviously it will have to be thoroughly tested individually.

pshipkov wrote on 2024-12-16, 20:25:

@feipoa
You have to be very careful how you handle that added trimmer to the Evergreen interposer.
Maybe Loctite it to the PCB.

Quite a bit of thought went into not damaging this rare Evergreen upgrade.

If you look carefully at the image, you'll see I've notched a rectangular hole into the trimmer for a capacitor to fit inside the casing. The other side of the trimmer is pressed hard against two SMD resistors. The 3rd face of the trimmer hits the heatsink, and one leg of the trimmer is soldered directly to the 221K resistor. In terms of torque to the screw, the trimmer isn't going anywhere. The heatsink has a barrier glued to it to prevent the heatsink from sliding around (barrier not visible in photos). There's also some double sided "permanent" tape holding the trimmer down to the PCB, which I'd replace with super glue if I decide to keep the trimmer installed. I was concerned the superglue might remove some of the PCB's silkscreen if I later remove the trimmer.

It is interesting that my newly acquired Evergreen QFP SXL2-66 upgrade, noted previously here...

feipoa wrote on 2024-11-16, 14:48:

I finally managed to find another one of these Evergreen TI486SXL2-66 QFP interposers. I found it in an old beat up 386-20 system, but the interposer looks almost new, aside from the dust. It has an affixed heatsink and I was wondering if this was an original Evergreen supplied heatsink. Has anyone else found one of these Evergreen SXL2-66 QFP interposers with a pre-attached heatsink? If the heatsink is original, I'd be reluctant to remove it.

The VRM is set for 3.60 V, so overclocking will be limited. It was able to do 75 MHz at 3.6 V, but not 80 MHz. VRM adjustments will be needed for more speed.

The attachment Evergreen_SXL2-66_QFP_original_heatsink.JPG is no longer available

...could only go up to 75 MHz at 3.6 V, yet my older QFP SXL2-66 unit (new trim pot) is doing 85 MHz at 3.60 V. There appears to be a massive difference in overclock-ability.

I decided to do a few under-voltage tests. Letting Quake run in loop with sound enabled, I slowly lowered the voltage from 3.60 V until Quake crashed. It crashed at ~3.35 V. At 3.3 V and 3.5 V, the CPU wasn't stable in DOS or Windows. At 3.60 V, the system was stable.

Next is swapping motherboards for the over 85 MHz tests...

Swapped motherboards and did some tests between 85-90 MHz. Setup is shown below:

The LT1117 voltage regulator on the Evergreen has a 1 V dropout minimum, which meant I could not run the CPU over 4.0 V. This turned out to be a disappointment. The surface mount package for the LT1117 series is: SOT223-4 or TO-261-4. Upon searching on digikey, I was not able to find any alternative ultra low dropout regulator with this package type in adjustable format; they all had a 1V dropout. The closest I could find was a unit with 1 more pin, but mounting it would be ugly. That unit was LP3964EMPX-ADJ with 350 mV dropout at 800 mA.

Alas, my results weren't as impressive as I'd have hoped for. In short,

85 MHz at 3.60 V
87 MHz at 3.80 V
88 MHz at 3.90 V

I tried 89 MHz and 90 MHz at 4.0 V, but the system would eventually crash. I feel like this CPU could approach 95 MHz at higher voltages. At 88 MHz, with the ISA at 11 MHz, DOOM timedemo3 scores 22.9 fps.

If someone knows of an ultra low dropout replacement for the *1117 series LDO, please let me know a part number. Maybe there were some older adjustable options for TO-261-4 with 0.4 V dropout?

Long thread, after so much testing I’m curious your thoughts, what’s the best performing full system configuration you’ve been able to muster so far? Which cards, mobo, interposer, processor, ram, etc?

Sphere478 wrote on 2024-12-19, 16:55:

Long thread, after so much testing I’m curious your thoughts, what’s the best performing full system configuration you’ve been able to muster so far? Which cards, mobo, interposer, processor, ram, etc?

The best motherboard for the SXL2 is any motherboard based on the Symphony 82C461 / 82C362 when paired with the BIOS from the DTK PEM-4036Y. For whatever reason, the symphony chipset yields much better results with the SXL compared with other chipsets of a similar generation. The improvement is typically around 10-15% better.

The best interposer is the one from Evergreen because it contains the SXL2 in QFP format. This allows for a smaller PCB and reduces voltage requirements. This interposer is extremely rare and almost impossible to find. It took me 10 years to find two units. One was from a CPU collector exiting the hobby, the other was hidden an unmarked 386 computer case. The next best interposer is either Alpha1 or Alpha2. I do most of my testing with Alpha1 for consistency. If wanting to run the SXL2 at 5 V, then the (formerly common) Improve-It PGA168 to PGA132 interposer is also good.

The highest stable operating frequency obtainable during a hot summer, inside a computer case, was 88.5 MHz at 5 V. Doom results were around 23 fps. Only one CPU sampled could achieve 88.5 MHz, while about 45% of PGA168 samples could handle 88 MHz at 4.9 or 5.0 V. 88 MHz is feeling like a hard limit on these SXL2 chips, analogous to the 112.5 MHz limit on BL3 chips. While 90 MHz can be achieved on some PGA chips, it wasn't completely stable in the heat of summer while cased.

More testing is needed to determine if 95 MHz can be achieved on a QFP SXL2. I could remove the LT1117 on the Evergreen and short Vin to Vout for 5 V operation, but I am reluctant to do so.

I like using the AHA-152X series of SCSI cards because I can have 2 GB partitions with ease, yet I've had issues getting them going at over 11 MHz in this system.. If you want to run IDE, pshipkov is more abreast to which IDE controllers will work best on Symphony boards w/SXL2. I know he's able to get his ISA clocked higher with IDE. You could use an XT-IDE ROM card if you want IDE partitions larger than 512 MB.

RAM? 60 ns 3-chip or 60 ns 9-chp. My unbranded Symphony 461 board only works well at 88 MHz with 9-chip using 1 ws DRAM, while my PEM-4036YB could handle certain 3-chip modules with 1 ws and 85 MHz.

other cards?
GD-5434 graphics. 3Com Etherlink III is easy to setup. ESS ES-1868 with mkarcher's Windows 3.1 driver fix. KBC PS/2 mouse mod.

After testing a brand new 168-pin press-fit socket, the connections are still hit or miss.

Tolerances of the finished holes were outside of the range +0.09/-0.06mm. PCBway claims +/- 0.08mm which would have been fine, but some holes are slightly too large.

So I'm going to check around to see what's possible with that... who can do it, and how much it would cost...

There are SMD 168-pin sockets that would fit from Preci-dip & Mill-max (SMT Receptacle) but can't find them listed anywhere.

Low melt solder might fill the edges just enough

MikeSG: Could you specify that the holes be 20 microns smaller to ensure sufficient fitment? Or are you concerned that some would then be too small to fit the press-fit socket? Or PCBWay simply doesn't have the ability to reduce the hole size by such small amounts?

What tolerances did JLCPCB spec?

One approach I've seen used on some low cost socket 3 interposers was to surface mount a regular PGA 168 socket. It adds height and doesn't look all that nice, but here it is:

Alternately, just cut off the pins on a socket and sand the cuts on a flat surface until all are level. Then surface mount the PGA168 with just the stubs remaining.

We've been discussing SXL cache invalidation in the other thread. It's a wall of text, starting at about here: Re: Register settings for various CPUs

It was determined that the cache flush scheme on that PGA132 SXL2 ribbon cable hurts performance quite a bit when sound is enabled - same result as using BARB w/hidden refresh enabled. It showed a ~20% performance hit (DOOM w/sound) compared to using FLUSH# w/out DMA SCSI controller. When using a DMA SCSI controller, the MEMW# wire needed to be connected to ISA MEMW#, which had about a 10% compared to FLUSH w/out DMA SCSI controller. Consequently, the PAL logic on the Evergreen upgrades are able to work fine w/FLUSH# and a DMA SCSI controller with no performance hit.

A mistake I've been making all this time when benchmarking DLC/SLC/SXL/DRx2 chips in DOOM was not enabling sound (pointed out by Rasz_pl). To see how well your cache invalidation scheme is working, you need to run the tests with sound.

myne wrote on 2024-12-25, 10:07:

Low melt solder might fill the edges just enough

Low melt solder paste might work, but I just want to be able to push the socket on and walk away, and not have the mess, etc.

feipoa wrote on 2024-12-25, 10:59:

MikeSG: Could you specify that the holes be 20 microns smaller to ensure sufficient fitment? Or are you concerned that some woul […]
Show full quote

MikeSG: Could you specify that the holes be 20 microns smaller to ensure sufficient fitment? Or are you concerned that some would then be too small to fit the press-fit socket? Or PCBWay simply doesn't have the ability to reduce the hole size by such small amounts?

What tolerances did JLCPCB spec?

One approach I've seen used on some low cost socket 3 interposers was to surface mount a regular PGA 168 socket. It adds height and doesn't look all that nice, but here it is:

The attachment Surface_mount_PGA.JPG is no longer available

Alternately, just cut off the pins on a socket and sand the cuts on a flat surface until all are level. Then surface mount the PGA168 with just the stubs remaining.

We've been discussing SXL cache invalidation in the other thread. It's a wall of text, starting at about here: Re: Register settings for various CPUs

It was determined that the cache flush scheme on that PGA132 SXL2 ribbon cable hurts performance quite a bit when sound is enabled - same result as using BARB w/hidden refresh enabled. It showed a ~20% performance hit (DOOM w/sound) compared to using FLUSH# w/out DMA SCSI controller. When using a DMA SCSI controller, the MEMW# wire needed to be connected to ISA MEMW#, which had about a 10% compared to FLUSH w/out DMA SCSI controller. Consequently, the PAL logic on the Evergreen upgrades are able to work fine w/FLUSH# and a DMA SCSI controller with no performance hit.

A mistake I've been making all this time when benchmarking DLC/SLC/SXL/DRx2 chips in DOOM was not enabling sound (pointed out by Rasz_pl). To see how well your cache invalidation scheme is working, you need to run the tests with sound.

I just saw that I can add 20-70 microns to the holes... thanks, didn't see that! Inexpensive too.

Didn't check out JCLPCB. Will look.

I want to have one more go with the press-fit sockets before trying a solder tail/normal PGA socket.. but will keep that in mind.

Interesting results about the cache flush. Have you tested using the DRAM.exe program to change refresh timing? I saw you mentioned it in an old post from 2018 (Re: How to get 486 SXL2-66 to clock-double w/AMI Mark V Baby Screamer motherboard).... Do you think that will make a difference when using a DMA controller? Or no difference?

MikeSG wrote on 2024-12-25, 13:01:

Interesting results about the cache flush. Have you tested using the DRAM.exe program to change refresh timing? I saw you mentioned it in an old post from 2018 (Re: How to get 486 SXL2-66 to clock-double w/AMI Mark V Baby Screamer motherboard).... Do you think that will make a difference when using a DMA controller? Or no difference?

I normally run DRAM.exe in my 386 systems, but for the tests performed last week, I had it disabled. I will see how much gain I can get using BARB with Hidden Refresh disabled and DRAM.exe in use.

From MikeSG's question, I've run a few comparative numbers for the case of:

- no FLUSH#
- no MEMW# wiring
- no slow, hidden, or decoupled refresh BIOS options
- using DMA Bus Mastering SCSI controller (AHA-1542CP)
- using BARB only

Run on a GEM MB386-40-SYM (Symphony 461 / 362) motherboard with SXL2 clocked at 85 MHz.

Default memory refresh rate (15 uS)
Disabled Decoupled Refresh
DOOM w/sound = 13.58 fps
Landmark v6 = 329 / 221 (ALU / FPU)
Cachechk v7:
L1 = 42.6 MB/s
L2 = 42.6 MB/s
RR = 24.1 MB/s
RW = 83.0 MB/s

Added DRAM.COM for 250 uS refresh rate
Disabled Decoupled Refresh
DOOM w/sound = 16.74 fps
Landmark v6 = 351 / 239
Cachechk v7:
L1 = 60.7 MB/s
L2 = 49.4 MB/s
RR = 25.2 MB/s
RW = 87.0 MB/s

Default memory refresh rate (15 uS)
Re-enabled Decoupled Refresh
DOOM w/sound = 16.80 fps
Landmark v6 = 352 / 240.5
Cachechk v7:
L1 = 70.7 MB/s
L2 = 44.5 MB/s
RR = 24.9 MB/s
RW = 85.9 MB/s

Added DRAM.COM for 250 uS refresh rate
Re-enabled Decoupled Refresh
DOOM w/sound = 17.01 fps
Landmark v6 = 352.75 / 241.0
Cachechk v7:
L1 = 70.7 MB/s
L2 = 44.5 MB/s
RR = 25.2 MB/s
RW = 87.2 MB/s

Added DRAM.COM for 40 uS refresh rate
Re-enabled Decoupled Refresh
DOOM w/sound = 16.98 fps
Landmark v6 = 352.46 / 240.9
Cachechk v7:
L1 = 70.7 MB/s
L2 = 44.5 MB/s
RR = 25.1 MB/s
RW = 86.7 MB/s

The readme for DRAM.COM states that it is normally safe to set refresh rate to 1000 uS, but noted that after about 250 uS, the gains are negligible. On my AMI Mark V Baby Screamer, I use DRAM 40, or 40 uS, because I was finding floppy drive access slowed down noticeably when altering this refresh rate.

Notice how the L1 cache read speed doesn't pickup to the levels when using hidden refresh, even with DRAM.COM at 250 uS.

Conclusion
From the DOOM results, all is not lost when using BARB if your system doesn't support hidden/decoupled or slow refresh. We can obtain almost identical results using DRAM.COM, that is 16.74 fps compared to 16.80 fps. However, without slowing down the refresh (no DRAM.COM), and without using hidden refresh, the results are a mere 13.58 fps. If your system supports hidden refresh and you slow the DRAM refresh rates to 250 uS, you can achieve up to 17.01 fps with BARB. Using FLUSH with MEMW#, these results go up to 18.26 fps. Skipping the bus mastering SCSI controller in favour of AHA-1522B, results go up to 20.25 fps. Or you can still use the bus mastering SCSI controller if you are using an Evergreen upgrade with some clever logic in the PAL chip to achieve 20.25 fps. My preferred approach is to skip the bus mastering SCSI controller; I don't find the system noticeably faster.

Interesting results... So basically 17.0 versus 18.26..

17.0 = BARB, with slow refresh/hidden refresh/DRAM.com 40us(+)
or
18.26 = CPU MEMW# connected to ISA MEMW#

I understood the 20.25 score was from enabling FLUSH but not having anything connected on the MEMW or FLUSH pin.. ?

One of my original designs was to convert MEMW & an Inverted HLDA to make FLUSH# (the same as the SXL2 CPU does),... so with an external FLUSH you could connect it straight to either SXL2 or 486SX/DX CPU... I deleted that somewhere along the line but need to add that back. I have just about everything else for the 486 SX/DX CPUs... clock divider, FPU disconnect jumpers.

MikeSG wrote on 2024-12-26, 14:55:

I understood the 20.25 score was from enabling FLUSH but not having anything connected on the MEMW or FLUSH pin.. ?

Correct.

One of the uncertainties from the other thread was - why doesn't multiple floppy read accesses crash the system w/AHA-1522B when FLUSH# goes nowhere, MEMW# isn't connected, and BARB isn't used.

Whatever logic the Evergreen PAL uses to invalidate cache could be helpful to implement. The details may be in one of their patent filings?

MikeSG wrote on 2024-12-26, 14:55:

One of my original designs was to convert MEMW & an Inverted HLDA to make FLUSH# (the same as the SXL2 CPU does),... so with an external FLUSH you could connect it straight to either SXL2 or 486SX/DX CPU... I deleted that somewhere along the line but need to add that back. I have just about everything else for the 486 SX/DX CPUs... clock divider, FPU disconnect jumpers.

Looking forward to 486SX CPUs working. If 486SX and SX2 CPUs end up working, I'll assemble one of your units, albeit without the push-to-connect sockets.

BTW I wonder that DRAM can run with more than magnitude slower refresh without any error? Why would they run std. refresh so often 15us when not necessary? Maybe you have some modern drams with some kind of self-refresh that doesn't care?

The thing is that the refresh period of 15µs you find in most datasheets is specced so that there's guaranteed data integrity at +85ºC. At room temperature, the refresh period can be much longer before data corruption begins.