SRAM geheugen, welke snelheid nodig?

We zijn bezig met een uitbreidingsmodule voor een bestaand stuk hardware. Daar moet o.a. ook RAM geheugen op komen. Op het huidige prototype zit een IC met een snelheid van 55ns. Deze werkt prima. Maar nu willen we een andere gaan gebruiken, eentje van 70ns. Maar zal die snel genoeg zijn? Hoe bereken ik dat? De CPU die het gebruikt heeft een kloksnelheid van 22MHz.

Heeft niet veel met de clocksnelheid te doen, maar met de bus timing van die CPU. (timing van read/write/datasignalen)
Daar zal ook wel e.e.a. over in de datasheet staan.

http://www.xs4all.nl/~hneel/misc/20190222_104919_TEK00135.PNG

Dit is een meting van een write actie. Boven (geel) is CS. Onder (blauw) is WE. Breedte van onderste puls is ong 220ns.

Databus en adresbus wijzigen ongeveer tegelijkertijd met WE.

Timing lijkt me dus ruim in orde.

Als het goed is, dan kan je vrijwel altijd een snellere er in zetten. Zeker als je met "oude" spullen werkt, dan was vroeger "sneller" behoorlijk wat duurder. Dus ze zullen er niet voor niets een snelle in gezet hebben. Ik zou het niet aandurven om een 55ns ding te vervangen door een 70ns exemplaar.

Het feit DAT ze er een 55ns ding in hebben zitten kan betekenen dat ze SOMS na bijvoorbeeld 60ns de data van de RAMchip proberen te lezen. De 70ns chip heeft dan nog niet (gegarandeerd) de juiste data op de bus staan.

Als je het probeert en het werkt, dan is zonder diepgaand onderzoek niet vast te stellen of dat structureel is. Het kan zomaar zijn dat de situatie waarbij het echt nodig is dat er een 55ns chip in zit erg zeldzaam is.

Mogelijk heeft de originele fabrikant iets gehad met: "Als je continue dit programma laat draaien, dan crasht de boel na drie dagen". En een slimme (of minder slimme) ontwerper heeft geprobeerd die 55ns RAM chip er in te zetten en toen was het probleem ineens opgelost! Die hele: "het is onbetrouwbaar, maar HEEL moeilijk op te sporen wat er mis gaat" debugging die wil je niet nog een keer moeten doorlopen.

Je laat iets zien van een write actie. Als het goed is, wordt de data gelatched op een bepaald moment. Ik dacht/verwacht dat dit de opgaande flank van de WE is. Dan zal je wel een bepaalde tijd geen nieuwe transactie mogen doen of zo, maar de werkelijk kritische timing zit waarschijnlijk in het lezen.

De puls zal wel iets van 225ns zijn, dat komt overeen met 5 klok tijden.
70ns access time lijkt mij meer dan bruikbaar.

Je hebt wel wat last van 'ringing' je meet zeker met een lange ground lead?

Die 'oude' chip van 55ns zat op onze eigen hardware, niet op de originele waar het op aansluit. Om precies te zijn emuleren we een PCMCIA SRAM card. En als ik even google zie ik dat die dingen timings hebben van 120 of 150 ns.

PS, op scoop meting is momenteel geen gnd aangesloten. Het is te zeggen: de scoop is geaard en het printje is via een usb kabel met de pc verbonden, en die is ook geaard. Beetje lange omweg dus inderdaad, maar ach, het gaat hier om digitale signalen.

Formeel moet je nog steeds de specs van de interface lezen en kijken of je daaraan kan voldoen met de 70ns chip. Zomaar vanuit gaan dat als iemand hier zegt "zal wel werken", dat dit klopt is te kort door de bocht.

Ik zou op z'n minst een torture-test proberen te vinden. Misschien is het programma "Chipmunk" iets. Heb ik zo'n 25 jaar geleden geschreven. Kan je memory testen op stukjes gemapped geheugen mee draaien. Als je het niet gecompileerd krijgt, kan je me een mailtje sturen, mogelijk heb ik een jaar of 2 geleden nog wat wijzingen gedaan om het weer werkend te krijgen. Geen essentiele dingen. In het kader van: "Wordt toch niet gebruikt" heb ik niet de moeite genomen om het te publiceren.

Wij zonden altijd een 'checkerboard pattern' (0x55-0xAA-0x55-0xAA...) om te testen. Eerst een write en dan een read.
Daarna patroon omkeren (0x55 wordt 0xAA, 0xAA wordt 0x55), en weer write-read, enz...

Enige waar je duidelijkheid kunt krijgen is de datasheet van de betreffende CPU.
Daar staat in waar ergens in de cycle de read/write gebeurt, en hoe lang de data aanwezig moet zijn voor/na de read write...

[Bericht gewijzigd door Arco op (34%)]

Op 22 februari 2019 11:17:26 schreef Blackfin:
De puls zal wel iets van 225ns zijn,
.....
70ns access time lijkt mij meer dan bruikbaar.

Zelfs met lange setup- en hold-times ben je met 150 ns ook nog makkelijk binnen spec. :D
Welke CPU gebruik je nou eigenlijk?

Op 22 februari 2019 12:17:37 schreef Arco:
Wij zonden altijd een 'checkerboard pattern' (0x55-0xAA-0x55-0xAA...) om te testen. Eerst een write en dan een read.
Daarna patroon omkeren (0x55 wordt 0xAA, 0xAA wordt 0x55), en weer write-read, enz...

Ik ben afgestudeerd bij de prof die wat wist van het testen van geheugens. Je moet iets doen als:

UP: W0
UP: R0 W1
UP: R1 W0
UP: R0

Met "W0" wordt in beginsel een write-nul bedoeld. Maar als je byte-wide werkt moet je voor "0" bijvoorbeeld een 0x55 substitueren. En voor "1" een 0xAA.

Dit vind "stuck at" fouten. Een geheugencel die niet meer een andere waarde dan "0" kan bevatten. (of stuck-at-1 waarbij ie niet anders dan 1 kan zijn).

Er zijn ook andere fouten. Bijvoorbeeld: bij een 0->1 op locatie 123, verandert locatie 122 van 0 naar 1.

Deze fout zal bovenstaande test niet vinden. De 122 cel is op dat moment al 1. Om deze fout te vinden moet er een DOWN: R0 W1 in je test zitten.

Holy shit! Hij is eind jaren negentig met pensioen gegaan. Hij publiceert kennelijk nog steeds (of op z'n minst nog ver na z'n pensioen).