Routen FPGA, SRAM en Flash

Probeer altijd extremen te vermijden, maar precies even lang is niet nodig. Je moet er rekening mee houden dat setup en hold tijden gehaald worden. Het belang is in grote mate afhankelijk van de clocksnelheid.

Voor RAM vooral belangrijk dat je clock niet eerder komt dan de rest (adres etc), iets later (dus lengte clock>=langste data/adreslijn) is geen punt. Je krijgt dan zoiets in je ontwerp:

_{voorbeeld van verlengde PCI clock}

Voor FPGA (in je topictitel) kan hetzelfde gelden, ligt natuurlijk helemaal aan de toepassing en signalen die je gebruikt. Je kunt er bij het ontwerp van je FPGA zelf rekening mee houden als je dat wilt.

En bedoel je met die Flash een seriele ofzo? Omdat je dat in 1 zin met een clocksignaal noemt...

SRAM en Flash hangen parallel aan de FPGA (pinbesparing)
alle 2 zijn ook parallele flash en sram (dus geen clock)

Je bedoel dat je een adres bus en een databus hebt en dat die alletwee naar de SRAM en de flash gaan?

Hoe snel wil je het hebben? Toen ik een kleine 20 jaar geleden bij Philips werkte, waren ze daar trots op hun 1Mbit (128k x 8) SRAM. Dat ding haalde geloof ik 28ns access time. Als je zo'n ding op 20MHz wilt aansturen (50ns) dan boeit het voor geen meter. Wil je hem op 33MHz aansturen, dan heb je maar 2ns "slack" voor looptijd verschillen en dergelijke. Dan moet je gaan uitkijken.

Wil je een moderne DDR SDRAM gaan aansturen op 400MHz, dan moet je verdomd goed weten wat je doet....

Op 7 mei 2008 12:31:31 schreef Sir_j:
de banen (data, klok)

Op 7 mei 2008 13:31:10 schreef Sir_j:
(dus geen clock)

Je bent me even kwijt, maar dat maakt niet uit, verhaal blijft hetzelfde: hoe sneller je gaat, hoe meer het gaat tellen.

hangt van de snelheid af. tot 20 MHz maakt het niet eel uit. erboven begint het snel kritish te worden. zeker als je een ram tot he tuiterste wilt drijven.

Praktisch enkele tips:

Hou je clocks een beetje kort.
Loop niet te veel van de ene naar de andere layer ( zo weinig mogelijk aantal via's).
Plaats een afsluitweerstand met C in serie op het einde van je clock ( vb 82 pf en 100 ohm naar massa).
Hou je clock signaal een beetje uit andere kritische signalen. Liever ingesloten rond de massa.

Dit zijn heel gewone regels die al heel wat helpen. Maar ga je heel hoog zoals FE aangeeft dan blijft het kritisch en moet je verder optimaliseren.

En het is zo vervelend foutzoeken als de ram 'af en toe' fout gaat. Ik zit zelf met m'n eerste 'echte' ontwerp nu op 100 MHz de SDRAM te klokken en hoewel het me verbaast hoe goed dat gaat (zelfs met uiterste timings) zit er een hardnekkige af-en-toe-fout-bug in de SW, waarvan ik me afvraag of het misschien de RAM timing is

je zou inderdaad 'borderline' kunnen zijn ...
maak de clock trace eens wat langer.

de clock moet ALTIJD de LANGSTE lijn zijn. de data en address lijnen zijn dan zeker stabiel wanneer de clock binnekomt.

je moet ze natuurlijk geen 2 meter langer maken ...

ik heb hier ram, fpga en ARM draainde op 48 MHz op een bord. no problemo. verbindingen zijn wel allemaal heel kort. ( ram staat onder de arm en de fgpa staat er knal naast der zit misschien 3 millimeter ruimte tussne de componenten. ) mijn langst spoor is 4 centimeter. kortste is 5 millimeter.

[Bericht gewijzigd door free_electron op woensdag 7 mei 2008 19:27:19 (36%)]

Op 7 mei 2008 19:25:21 schreef free_electron:
de clock moet ALTIJD de LANGSTE lijn zijn.

Op 7 mei 2008 13:23:15 schreef Jochem_S:
(dus lengte clock>=langste data/adreslijn)

dat zeg ik (ik was de TS ook niet)

Mijn clock is dan ook de langste, 9 cm naar de ene RAM, ietsje langer nog naar de andere. Heb al een delayed read met een extra clockcycle, dus eigenlijk kan het geen punt meer zijn. Misschien toch iets dat misloopt met m'n cache tijdens de interrupt, dat was de tweede verdachte.

Maar het was niet de bedoeling dit topic te kapen, ik noemde slechts een voorbeeld zodat TS weet wat 'm te wachten staat