Call to arms | Teensy + SDRAM = true

[Dogbone06]

Sorry, I have not had enough yet and my eyes are still sort of glazed over...

But I keep wondering if your goal is 300MHz, are you not asking for trouble if you try to more or less run something at twice the speed they are rated for? Are there faster versions?

My goal is the highest speed possible. I don't think there are faster versions. But this SDRAM which is rated for 166MHz, runs smoothly on 221MHz with various capacitors. So I think a little more should work. But this is all just for fun.

 

[KurtE]

My goal is the highest speed possible. I don't think there are faster versions. But this SDRAM which is rated for 166MHz, runs smoothly on 221MHz with various capacitors. So I think a little more should work. But this is all just for fun.

Good luck... I thought I saw some up on Digikey that are rated for 200MHz, but maybe don't have the right memory configuration...

For me, I always wonder when you push components like this, if it maybe will only work on some percentage of the chips, which maybe
might change from batch to batch. Does it impact longevity?

But if you are again just doing it for fun

 

[jmarsh]

Also wondering if the same CAP will work the same on different boards? Or will it all need to be fine-tuned depending on
each actual board design and which memory chip and ...

Since it's being used to measure a delay between the clock signal and when data actually arrives from the SDRAM I think the "best" value would vary based on the board design / track lengths.

 

[Dogbone06]

Good luck... I thought I saw some up on Digikey that are rated for 200MHz, but maybe don't have the right memory configuration...

For me, I always wonder when you push components like this, if it maybe will only work on some percentage of the chips, which maybe
might change from batch to batch. Does it impact longevity?

But if you are again just doing it for fun

All your thoughts are valid. And for a real world product I would never overclock. But for fun, I'm willing to blow shit up lol

 

[Dogbone06]

Looks like your test Paul should tell which Cap is probably the best. Or atleast give an idea. No?

This is the result I get with the 1.5pF

Clock set 240.00 MHz
 clock=241, Ok

Clock set 240.00 MHz
 clock=242, Ok

Clock set 240.00 MHz
 clock=243, Ok

Clock set 240.00 MHz
 clock=244, Fail

Clock set 240.00 MHz
 clock=245, Ok

Clock set 240.00 MHz
 clock=246, Ok

Clock set 254.12 MHz
 clock=247, Fail

Clock set 254.12 MHz
 clock=248, Fail

Clock set 254.12 MHz
 clock=249, Fail

Clock set 254.12 MHz
 clock=250, Fail

Clock set 254.12 MHz
 clock=251, Fail

 

[PaulStoffregen]

Looks like your test Paul should tell which Cap is probably the best. Or atleast give an idea. No?

Again you're talking about pass vs fail. I'm afraid I'm out of energy to write yet again about capacitor testing method and rationale.

 

[Dogbone06]

Again you're talking about pass vs fail. I'm afraid I'm out of energy to write yet again about capacitor testing method and rationale.

Let me explain what I mean.

Testing each cap takes an absolute ton of time. I fully understand what you've explained before!

If you look above on what I posted, it says:

Clock set 240.00 MHz
 clock=241, Ok

Clock set 240.00 MHz
 clock=242, Ok

Clock set 240.00 MHz
 clock=243, Ok

Clock set 240.00 MHz
 clock=244, Fail

Clock set 240.00 MHz
 clock=245, Ok

Clock set 240.00 MHz
 clock=246, Ok

We have a total of 5 OK's and 1 FAIL for 240MHz. This tells me that the cap is starting to fail at that speed. It gives a croud idea of what this (1.5pF) cap can do. Doing this for each cap should give a very rough estimate. After that, the caps that worked the best can go through the deeper testing that you've explained before.

That's what I meant. Perhaps it wont work like that?

 

[defragster]

    inline float getFrequency() { return frequency; }

That change has been pushed. See post #631

Updated the CapReadSDRAM.ino to show after .begin(): Serial.printf("SDRAM speed %f Mhz ", sdram.getFrequency());

 

[PaulStoffregen]

Testing each cap takes an absolute ton of time.

That is why I suggested first testing only 2 or 3 of them, and test with no capacitor soldered. For a start, just test 0pF, 4.7pF, 10pF.

Let's talk only about number of read errors, not pass vs fail.

Please use the latest code from github, and Defragster just recently fixed an issue with the error count.

 

[Dogbone06]

That is why I suggested first testing only 2 or 3 of them, and test with no capacitor soldered. For a start, just test 4.7pF, 10pF and 15pF.

Let's talk not about pass or fail, but the number of read errors. Please use the latest code from github, and Defragster just recently fixed an issue with the error count.

Number of errors is the interesting part yes. I am only doing these tests to help your curiosity. I have no use of finding the fastest (best) capacitor. So to save time, my idea above sure feels like a great idea to rule out the majority of the caps. From there I will test number of fails.

I will do as such and once I have results I'll post about it again.

 

[PaulStoffregen]

I am only doing these tests to help your curiosity.

If you're doing it for me, please pick 1 frequency where a good number (at least 1000) of read errors occur. Do all the tests at only that frequency.

Let not talk about pass vs fail or results at different frequency.

 

[Dogbone06]

If you're doing it for me, please pick 1 frequency where a good number (at least 1000) of read errors occur. Do all the tests at only that frequency.

Sure, I'll do that!

 

[PaulStoffregen]

Good first round would test at ~5pF increments, so 0pF (no capacitor soldered), 4.7pF, 10pF, 15pF. Just those 4 should give a good picture.

 

[Dogbone06]

Test performed with the following settings. 240MHz and 254MHz:

I started by testing the 4 values you said @PaulStoffregen. I noticed that 10pF seemed to be the golden child. So I added more values above and below. And the end result speaks for itself. 10pF is the best, 12pF is also okay but almost double the amount of read errors at 254MHz.
Results:

Cap Value	Speed	Read fails
No cap	240MHz	206471504
	254.12MHz	2206300668
4.7 pF	240MHz	231
	254.12MHz	185661801
9.1 pF	240MHz	45
	254.12MHz	1157186
10 pF	240MHz	0
	254.12MHz	466254
11 pF	240MHz	0
	254.12MHz	1543059
12 pF	240MHz	0
	254.12MHz	929907
15 pF	240MHz	0
	254.12MHz	1310599
18 pF	240MHz	0
	254.12MHz	2660450

 

[defragster]

@Dogbone06 - that isn't the latest sketch copy where Error Count was made correct. Those numbers are suggestive - but they are improperly compounded so even a LOW error rate could report artificially high.

10 pF looks like a good value - for that speed - if used for near fine tuning values.

It is telling where a lower value is seen - but it could read 100X high across any test showing errors - i.e. another 10X to 44X higher.
> i.e. the count of 466,254 is probably under 5,000 depending on where the errors were located in the process - maybe even under 1,000.

If the goal is seeing under ~1,000 Errors giving useful indication of 'almost works' as a value on the edge
> The long test could be aborted when the error count goes over 100,000 as that is not a valid candidate

NOTE: Given that the speed is specified in setup() - the code could use EEPROM storage and step through a range of values unattended.

 

[Dogbone06]

@Dogbone06 - that isn't the latest sketch copy where Error Count was made correct. Those numbers are suggestive - but they are improperly compounded so even a LOW error rate could report artificially high.

10 pF looks like a good value - for that speed - if used for near fine tuning values.

It is telling where a lower value is seen - but it could read 100X high across any test showing errors - i.e. another 10X to 44X higher.
> i.e. the count of 466,254 is probably under 5,000 depending on where the errors were located in the process - maybe even under 1,000.

If the goal is seeing under ~1,000 Errors giving useful indication of 'almost works' as a value on the edge
> The long test could be aborted when the error count goes over 100,000 as that is not a valid candidate

NOTE: Given that the speed is specified in setup() - the code could use EEPROM storage and step through a range of values unattended.

Throw me the latest code so I don't pick the wrong one. And I'll run it on the 10pF to confirm.

 

[defragster]

Latest is here: https://github.com/mjs513/SDRAM_t4/tree/main/examples/CapReadSDRAM

 

[Dogbone06]

Latest is here: https://github.com/mjs513/SDRAM_t4/tree/main/examples/CapReadSDRAM

Result at 254MHz with 10pF cap with the latest sketch: 514946 read errors

With the old sketch before you posted, I ran a series of the same test. Gives very very different results. The last one is very bad, because I added a little more solder to each side of the cap. Things like that seem to affect it quite allot.

Cap Value	Speed	Read fails
10 pF	240MHz	0
	254.12MHz	466254
		742950
		689534
		776843
		968970
		1576842

 

[Dogbone06]

More tests with the 10pF cap and the latest sketch, the results are very different each restart.

Cap Value	Speed	Read fails
10 pF	240MHz	0
	254.12MHz	449297
		426547
		395068
		392256
		417701

 

[defragster]

Odd the Error Counts are in the same range - not much lower? There was clearly an issue with a per loop count transferring to the global and it was not starting at 0 for each loop repeating the read. So seeing the same number is surprising?

 

[Dogbone06]

Odd the Error Counts are in the same range - not much lower? There was clearly an issue with a per loop count transferring to the global and it was not starting at 0 for each loop repeating the read. So seeing the same number is surprising?

It's way above my league. I can only test and give you guys the results haha.

 

[defragster]

It's way above my league. I can only test and give you guys the results haha.

TRUE! If that is building with the current INO from github then that is the case.

Bummer not getting to see all the code and feedback as it goes to KNOW the code is right.

 

[Dogbone06]

TRUE! If that is building with the current INO from github then that is the case.

Bummer not getting to see all the code and feedback as it goes to KNOW the code is right.

It is the latest code and library from Git.

Tell me what to do next and I’ll do it.

 

[defragster]

Just placed Mouser order - got 5 from your list 10pF and a couple under and over. Upgraded $8 ship to 2 day for another $2 - more than 10 each of the caps. Smallest I ordered before were .1 uF and larger footprint. $2.56 for 50 caps ... should have ordered sooner

You can take a break for 3-4 days if you want and they may be here. Even if I only solder one 10 pF I can verify the results as you see them making sure there aren't other bugs.

 

[Dogbone06]

Just placed Mouser order - got 5 from your list 10pF and a couple under and over. Upgraded $8 ship to 2 day for another $2 - more than 10 each of the caps. Smallest I ordered before were .1 uF and larger footprint. $2.56 for 50 caps ... should have ordered sooner
View attachment 33094
You can take a break for 3-4 days if you want and they may be here. Even if I only solder one 10 pF I can verify the results as you see them making sure there aren't other bugs.

Let me know if I should send all
The caps so have to you. Not sure if it helps. I have the complete list Paul wrote of the caps. 10pcs of each.