Logic Analyzer zelf maken


Na een pauze, omdat ik met andere projecten bezig was, is het tijd voor een nieuwe impuls aan dit project.

Recap: Het grote struikelblok van het vorige ontwerp was de FPGA zelf. Ik had niet gerealiseerd dat de hagelnieuwe Intel Cyclone 10 LP eigenlijk een oude Altera Cyclone III/IV was. Dit verteld niemand, totdat Quartus de JTAG ID laat zien. De limieten van deze relatief oude FPGA zijn de Fmax, en het gebrek aan geheugen.

200MHz was zo´n beetje het maximum waarop mijn FPGA betrouwbaar wilde werken. Niet niet zo´n erg probleem, maar door het gebrek aan onchip geheugen moest ik mijn ontwerp uitvoeren met een externe geheugenchip. De ZBT SRAM was weliswaar op papier geschikt voor 200MHz (1 cycle lees, 1 cycle schrijf op 100MHz naar de FT601 toe), in de praktijk bleek het geheel betrouwbaar te werken tot 100MHz.

Wat ook een leermoment was: De Signaltap functionaliteit die je in de chip kunt inbakken, bleek mijn ontwerp negatief te beïnvloeden. Een betrouwbare datatransfer op mijn USB bus bleek kapot te gaat doordat ik met de Signaltap erop wilde proben.

Eruit dus met die Cyclone 10LP. Nu ben ik niet per sé tegen Cyclone 10's, want de versie met de gigabit transceivers ingebakken ziet er machtig mooi uit. Maar ik stap over naar een Cyclone V. Ik heb al eerder mijn USB3 ontwerp mogen uitproberen met een Terasic C5G board, dus ik ben bekend met de mogelijkheden van een Cyclone V. Uitgekomen op een 5CEBA5F23C8N. Ook een FBGA484 met 1mm pitch. Toch zitten er wat boa constrictors onder het gras, vergeleken met het vorige ontwerp:

- De Cyclone V is te krijgen met allerlei extra opties, zoals een ARM HPS core en High Speed Serial Interfaces (HSSI's) Mijn FPGA heeft dat niet, en dus zijn die pinnen (wait for it...) No Connect geworden. Dank je!
- Doordat ik een maximale upgrade mogelijkheid wil behouden, valt de I/O bank van de HPS core ook weg. Ik heb nog 224 I/O's over. Maar goed dat die geheugenchip weg is.
- De I/O's die ik over heb zitten voornamelijk aan de binnenkant van de chip, en niet mooi aan de buitenkant zoals bij mijn Cyclone 10. Minder makkelijke fanout betekend -> meer print lagen.
- De Cyclone 10 werkte nog met 1.2V core voltage, waardoor ik LM2852's kon gebruiken, de nieuwe Cyclone V werkt met 1.1V core voltage, en die is niet te krijgen in LM2852. De voeding moet dus op de schop.

Om te beginnen met de voeding. Ik moet een high efficiency buck conversie hebben vanaf 5V naar 3.3V, 2.5V en 1.1V. Het moet redelijk klein zijn om op mijn print te passen, dus een hoge switching frequency is ook gewenst. Via de design guide van mijn C5G development board kwam ik uit bij de LTC3569. uitgangen van 1x 1.2A en 2x 600mA was vrijwel ideaal voor mij. Het 1.2A kanaal gaat dan naar de 1.1V, de twee andere kanalen komen op de 3.3V en 2.5V. En dat alles met een efficiency van boven de 90%. Netjes!

Vanwege de minder gunstige fanout op mijn FPGA kom ik niet meer met mijn reguliere 4 laags PCB uit. Geloof me, ik heb het geprobeerd. Mogelijkheden voor mij zijn:
- 6 laags PCB
- Blind/buried via's
- HDI lagen
Na het overwegen van de kosten heb ik heel snel voor een 6 laags PCB gekozen. Dit was de enigste optie die betaalbaar was!

Mijn pin planner, alleen de vierkant/zeskant/ronde pinnen kan ik gebruiken!

Afgezien van de FPGA zelf kan ik nagenoeg alle componenten hergebruiken op mijn nieuw ontwerp. De voltage translators, clamping diodes, USB interface, Configuratie Flash, alles zet ik over.

1 electron per seconde = 16 atto ampere!

Printje maken. In wezen blijft alles hetzelfde in vergelijking met het vorige ontwerp, maar doordat mijn FPGA aan 1 zijde, en tegenoverliggende hoek weinig bruikbare aansluitingen heeft zitten, draai ik hem 180 graden. De configuratie flash en JTAG aansluiting komen aan de andere kant van de FPGA te zitten, waardoor ik automatisch plaats krijg voor mijn triple buck converter.

De print voorzien van alle onderdelen:

Verplichte achterkant. Ik heb geprobeerd zoveel mogelijk ontkoppelcondensatoren te herbergen onder de FPGA:

Na het meten dat alle spanningen conform verwachting zijn, en dat de FPGA JTAG ID herkend word, kunnen we beginnen met het VHDL deel. Zoals eerder gezegd: Ik ben van plan om 4 frames te versturen vanaf de logic analyzer: elke frame bevat 1 byte preamble en 3 bytes aan data. Frame D (preamble 0x82) heeft data lijnen 96-72, frame C (preamble 0x81) heeft data lijnen 71-48, Frame B (0x80) data 47-24, en frame A heeft preambles 0x00-0x79, waarbij de preamble aangeeft hoeveel samples er ontvangen zijn met deze waarde, en dus de RLE compressie methode geïmplementeerd.

Dit heeft als voordeel dat er (theoretisch) 96 lijnen verstuurd kunnen worden op 25MHz sample rate, maar hetzelfde protocol laat ook 50MHz op 48 lijnen, en 100 MHz samplerate op 24 lijnen toe.

Data naar de analyzer toe is om de sample clock deler in te stellen. We kunnen een 400MHz delen om de sample clock te genereren. Die 400MHz is véél sneller dan de 200MHz die mijn vorige FPGA aankon. Heel blij dus met de keuze van de Cyclone V. Ook sturen we data om de ingangs multiplexer in te stellen, die elke fysieke ingang kan routen naar elk van de 96 ingangen op de logic analyzer. Voor de rest kunnen we de capture mode instellen. Dit is nog niet echt van toepassing nu, maar ik wil een pattern trigger mode implementeren.

[Bericht gewijzigd door Dweil op 7 december 2019 10:58:44 (65%)]

1 electron per seconde = 16 atto ampere!
bprosman

Golden Member

Vind het allereerst een prachtig board en een heel mooi project maar kun je in zo'n geval niet beter een "Cyclone V Core Board" kopen en daar op voortborduren ? Dan ben je van het tricky BGA solderen af.

De jongere generatie loopt veel te vaak zijn PIC achterna.

Zeer gaaf project! Mij zakt me de moed meestal in de schoenen als ik probeer een fpga aan de praat te krijgen, de vhdl red ik me nog wel enigszins mee, maar de hele toolchain aan de praat krijgen...

Verder vroeg ik me af, 100 MHz, krijg je dat nog een beetje netjes door zo'n lange flatcable? Of is het samplen op 100MHz maar de verwachte signalen een stuk trager? En sluit je het laagoohmig af of is dat niet nodig?

Henry Rolls (van Rolls- Royce): "The quality remains long after the price is forgotten,"

bprosman: Ik heb een Terasic C5G als dev board gebruikt. Op de HSMC connector kun je een FT601 dev board plakken, en de GPIO poort heeft 36 lijnen. Dat zijn er geen 96, en hebben ook geen level conversie. Voor mij is het makkelijker om een purpose-designed printplaat te ontwerpen, die in een behuizing past. Mijn ontwerp heet "COMPACT logic analyzer". BGA's solderen is helemaal niet tricky: je hebt een goede heteluchtbron nodig, losse flux en een beetje lef.

Gewoon Klaas: De toolchain die ik gebruik is Intel Quartus Prime 18.1. That's it. VHDL kloppen in Notepad++, programmeren, klaar. Voor andere Operating Systems dan Windows: Geen ervaring. Voor de rest ben je niet verplicht om een lange flatcable aan te sluiten. Dat kan ook een korte flatcable zijn. Mijn ontwerp heeft een simpele ingang: Er zit alleen diode clamping op, voor de rest niets.

Nog even een teaser afbeelding:

1 electron per seconde = 16 atto ampere!

Op 7 december 2019 10:42:44 schreef Gewoon Klaas:
...maar de hele toolchain aan de praat krijgen...

Toolchain??? Da's wel een heel groot woord voor "quartus installeren", of "ISE/Vivado installeren". Downloaden, installer runnen, klaar. Wat denk je allemaal te moeten installeren dan?

"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein

Op 7 december 2019 11:57:24 schreef flipflop:
[...]
Toolchain??? Da's wel een heel groot woord voor "quartus installeren", of "ISE/Vivado installeren". Downloaden, installer runnen, klaar. Wat denk je allemaal te moeten installeren dan?

Offtopic: Wss deed ik meestal wat fout, maar ik heb altijd moeite met dat soort dingen en het frustreerd me. Maar tegenwoordig houd ik me vooral bezig met analoog design dus loop ik hier niet meer tegenaan

Henry Rolls (van Rolls- Royce): "The quality remains long after the price is forgotten,"

Wat ik vermoed: Je was bezig met ARM microcontrollers, en daar heb ik inderdaad wel wat "overly complicated" procedures gezien om de boel werkend te krijgen. Ik weet dat veel mensen onder Linux de Quartus software in command line gebruiken, met makefiles om de SOF/JIC data eruit te halen. Dat is ook niet makkelijk op te zetten. Maar onder Windows is Quartus installeren inderdaad een fluitje van nog geen cent (want gratis).

Over de afbeelding: Ik heb het C5G dev board gebruikt als binaire teller. De GPIO poort van de C5G heb ik verbinden met mijn CoLA. Helaas heb ik de ground en 3V3 met dezelfde wire wrap draadjes aangesloten als alle data's, en dus zie je in het beeld op Pulseview wat spurious pulsjes, als gevolg van ground bounce. Dit heet "Simultaneous switching interference" ofwel SSI. Afijn, hoog experimentele code gepropt in mijn FPGA, Python scriptje geschreven die werkt in twee fasen:
1) Logic Analyzer wordt geconfigureerd en inputbuffer geflushed. Daarna data gecaptured en weggeschreven naar SSD. (52MB/s in dit geval)
2) Capture data wordt uitgepakt naar een formaat dat Sigrok's Pulseview begrijpt. Dat betekend dat de RLE encoding moet worden gedecodeerd, en dat de "missende" D, C, en B frames van mijn stream moet worden ingevuld. De uiteindelijke (gezipte) data is 27Mbytes voor 100ms aan data. 2,5MB op de schijf.

In fase twee van mijn Python script kan nog een hele hoop optimalisatie gebeuren. Ik zit nu op een 1:20 verhouding van tijd. 1 seconde capture is 20 seconden conversietijd. Neem 10 seconden aan data op en je computer is meer dan 3 minuten bezig. Ik denk momenteel aan multithreading.

Als ik een lege inputbus opneem, zie je alle gebruikte compressie methodes shinen. Mijn conversiescript rapporteert een compressie van ongeveer 262:1! Maar ja: wie wilt er nu een set aan lege datasamples..

Oh ja: Wist je dat Sigrok nu maar maximaal 64 kanalen ondersteund? Ik hoop dat ze deze limiet weten te verhelpen.

Trace voor een 1 seconde empty-bus capture:

code:


Captured 7326 frames, 0 overflow frames.
Captured 1135600 input bytes.
Processing................................
         546721 function calls in 3.734 seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
       32    0.000    0.000    0.000    0.000 zipfile.py:1088(_writecheck)
       32    0.001    0.000    2.001    0.063 zipfile.py:1208(writestr)
       32    0.000    0.000    0.000    0.000 zipfile.py:287(__init__)
       32    0.000    0.000    0.000    0.000 zipfile.py:329(FileHeader)
       32    0.000    0.000    0.000    0.000 zipfile.py:368(_encodeFilenameFlags)
       32    0.000    0.000    0.000    0.000 {_struct.pack}
       32    1.732    0.054    1.732    0.054 {built-in method compress}
       32    0.001    0.000    0.001    0.000 {built-in method flush}
       32    0.000    0.000    0.000    0.000 {chr}
       64    0.000    0.000    0.000    0.000 {isinstance}
        1    0.000    0.000    0.000    0.000 {iter}
      160    0.000    0.000    0.000    0.000 {len}
        1    0.022    0.022    0.022    0.022 {map}
       32    0.000    0.000    0.000    0.000 {method 'append' of 'list' objects}
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}
       32    0.000    0.000    0.000    0.000 {method 'find' of 'str' objects}
       32    0.000    0.000    0.000    0.000 {method 'flush' of 'file' objects}
       32    1.335    0.042    1.335    0.042 {method 'join' of 'str' objects}
        1    0.000    0.000    0.000    0.000 {method 'read' of 'file' objects}
       32    0.000    0.000    0.000    0.000 {method 'tell' of 'file' objects}
       96    0.008    0.000    0.008    0.000 {method 'write' of 'file' objects}
   283900    0.013    0.000    0.013    0.000 {ord}
   261919    0.172    0.000    0.172    0.000 {range}
        1    0.000    0.000    0.000    0.000 {time.clock}
       32    0.000    0.000    0.000    0.000 {time.localtime}
       32    0.000    0.000    0.000    0.000 {time.time}
        1    0.184    0.184    0.184    0.184 {zip}
       32    0.000    0.000    0.000    0.000 {zlib.compressobj}
       32    0.263    0.008    0.263    0.008 {zlib.crc32}



Output 297878607 bytes (Decompression ratio: 262.3) in 20.9 Seconds.
1 electron per seconde = 16 atto ampere!

Op 7 december 2019 13:41:15 schreef Dweil:
In fase twee van mijn Python script kan nog een hele hoop optimalisatie gebeuren.

Ik denk dat het "geinterpreteerde-taal-gebruiken" de grootste bottleneck is. Als je me dat script mailed, dan kan ik even een C-versie d'r van maken dat het voortaan 100x sneller is(*). (in je python "wrapper" moet je dan mijn ding met "system" aanroepen o.i.d.).

(*) Geen garantie, maar dat is toch echt wat ik verwacht dat mogelijk is.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

rew: Ik denk dat je de spijker op zijn kop slaat. Mijn ervaring met C op de desktop is echter vrij beperkt. Later wil ik ook een gui maken in plaats van mijn command line tooltje. Echter, het is nog in een pril stadium, en verre van hoe ik het wil hebben. Kan ik gebruik maken van je aanbod, op het moment dat dit wel zo is? Ik wil nog de klok en routing configuratie makkelijker kunnen instellen.

Ik ben serieus aan het denken om een aantal ontwikkelversies van de CoLA te maken, en die uit te geven als iemand een bijdrage wilt leveren aan dit project. Op het gebied van hardware, software, of firmware. Het probleem is namelijk dat uiteindelijk ik met de hardware zit, en dus ik alleen iets kan testen op dit moment.

De aparte tool is volgens mij de enigste manier op dit moment om mijn hardware te gebruiken. In verband met de GPL licentievorm van Sigrok waar ik niet kan aan voldoen, omdat ik met de FT601 driver zit die ontzettend closed source is. Uiteindelijk denk ik niet dat het een onoverkomelijk probleem gaat zijn, te meer omdat ik gewoon in een formaat kan wegschrijven waar Sigrok wel mee overweg kan.

Een groot struikelblok in mijn ogen is de 64 kanalen beperking van Sigrok. Ik hoop echt dat er snel verbetering komt op dit vlak, want tot die tijd kan ik maar 2/3 deel gebruiken van mijn functionaliteit.

Blijft over de feature set: Ik wil zeker in de komende tijd nog de 48ch/50MHz mode en de 24ch/100MHz mode gaan maken en testen. Ook moet ik de huidige 96ch/25MHz nog zeker meer uitproberen, om er echt zeker van te zijn dat alles het doet zoals het hoort. Ook de pattern trigger wil ik inbouwen. Als ik 3 M10K blokken hieraan besteed (de FPGA heeft er 446) heb ik een 256 sample pre-trigger capture. Is dit voldoende?

1 electron per seconde = 16 atto ampere!

Op 8 december 2019 08:39:51 schreef Dweil:
Kan ik gebruik maken van je aanbod, op het moment dat dit wel zo is?

Ik heb nu genoeg ruimte in m'n schema dat ik vind dat ik zo nu en dan een paar uurtjes kan "hobbyen". Gisteren de firmware voor de m.bouwer mini-ESC gemaakt. Die beschikbaarheid kan zomaar weer veranderen.

Op 8 december 2019 08:39:51 schreef Dweil:
Als ik 3 M10K blokken hieraan besteed (de FPGA heeft er 446) heb ik een 256 sample pre-trigger capture. Is dit voldoende?

Ik ben van mening dat dit niet het geval is.

Met moderne logic analysers en scopes is het zo dat de aquisitie eigenlijk altijd loopt en als er getriggerd wordt, dan wordt er nog een X aantal samples doorge-sampled. Door X te varieren van 0.1 tot 0.9 maal de buffergrootte kan je schuiven tussen kleine pre-trigger, grote post-trigger en andersom.

Zeker met jou grote busbreedte en samplediepte, kan het zijn dat je een trigger verzint die signaleert: "En nu zitten we in de shit". En dan wil je dus juist de pre-trigger bekijken van: "hoe zijn we hier gekomen?", "hoe is het mis gegaan".

Ik weet nog van 30 jaar geleden dat het lastig was om zolang je niet wist WAT er mis ging een trigger te verzinnen die niet steeds triggerde (zeg max na 100ms) terwijl je probleem maar 1x per minuut plaatsvind. Dan is: "detecteer dat het fout is gegaan" in je software wel eens makkelijk te maken, en dan maak je een GPIO hoog. Dat is dan de trigger die samen met een lange pre-trigger helpt om het probleem te vinden.

[Bericht gewijzigd door rew op 8 december 2019 09:35:22 (63%)]

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

rew: Ik snap je. In dat geval ga ik mijn scriptje voorzien van wat comments, en dan kan ik het je sturen. Alvast ontzettend bedankt!

1 electron per seconde = 16 atto ampere!

Op 6 december 2019 16:45:47 schreef Dweil:
Printje maken.

Petje af. Dit is nogal wat toewijding om naar de bus van een 68000 te kunnen kijken :)

Suffering from wiseass oneliner blackout

De 68000 is een... Oh wacht! 64(!) pin chip. 24 adres lijnen en 16 databus als ik het me goed herinner. 40 signalen moet je een HEEL eind mee komen. De '020 of '030 was pas een chip met meer pootjes en brede databussen. Nostalgie! Ik kon mezelf niet beheersen en heb zojuist een '68000 gekocht op Ebay.

P.S. Python code naar C vertaald, is inderdaad 100x sneller dan de python. Helaas zit er ook nog een: "en het bestandsformaat eist dat de boel gezipt wordt" in.... Het zippen duurt bijna 2 seconden, dus het geheel is maar 10x sneller dan de python code: 2 sec ipv 20 sec.

[Bericht gewijzigd door rew op 13 december 2019 11:13:28 (31%)]

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Desondanks een prima prestatie dankzij rew. De afgelopen paar dagen heb ik gespendeerd aan het VHDL ontwerp. De data aquisitie is nu perfect. Ook de 48ch/50MHz en 24ch/100MHz mode doen het nu goed. Overigens: op de sigrok wiki staat nu een CoLA pagina onder "supported hardware - planned". Hier staat in de nabije toekomst ook het volledig ontwerp (theorie, schema, layout, gerber, onderdelenlijst, firmware, en capture tool) zodat iedereen mijn logic analyzer kan maken EN VERBETEREN. Update over de dataoverdracht: het maximum getest staat nu op 120Mbyte/s over de USB3 lijn.

Ook heb ik van het sigrok IRC kanaal vernomen dat de 64 kanalen limiet binnenkort aangepakt gaat worden. Samen met de RLE ondersteuning in het bestandsformaat. Ik gok dat dit de sigrok V3 standaard gaat worden.

1 electron per seconde = 16 atto ampere!

Op 14 december 2019 06:54:51 schreef Dweil:Ook heb ik van het sigrok IRC kanaal vernomen dat de 64 kanalen limiet binnenkort aangepakt gaat worden. Samen met de RLE ondersteuning in het bestandsformaat. Ik gok dat dit de sigrok V3 standaard gaat worden.

Dat zou fantastisch zijn. Wat is de verwachte BOM?

Met wat geluk kan je je ontwerp in China "zaaien" en heeft iedereen toegang tot een goedkope, snelle multikanaals LA.

Suffering from wiseass oneliner blackout

De BOM, samen met alle andere gegevens om dit ontwerp te maken, staat op:

https://sigrok.org/wiki/CoLA

Nu dit project voor mij werkend is, is het misschien tijd om vooruit te kijken. Kunnen we een betere versie maken? Of een uitgebreidere? De bottleneck voor dit ontwerp is ongetwijfeld de USB3 implementatie gebleken. FTDI's closed source drivers, samen met de 0.4mm QFN pitch maakt de FT601 achteraf gezien een beperking. Ook de 5Gbps mag in de eerste instantie veel lijken, maar in theorie is 3200Mbps het maximaal haalbare, met in de praktijk 350MB/s. Nu is dit genoeg, maar het is geen échte high performance. 10Gbps lijkt de volgende stap.

Om die snelheid te halen, hebben we verschillende keuzes van overdrachtsprotocol. USB is er in een 10Gbps variant met USB3.1. Helaas is voor USB de protocol overhead best groot, en voor 10Gbps is er geen kant-en-klare oplossing beschikbaar. Thunderbolt is ook 10 gigabit, maar dit protocol van Intel is ook redelijk onbekend voor mij. Wat ik begrepen heb is dat het eigenlijk gewoon een soort van PCIe is. Nu heb ik me wel eens verdiept in PCIe, en er van af gezien vanwege de software.

Er is echter nóg een 10Gbps protocol, en dat is 10 gigabit Ethernet. Netwerkkaarten zijn goed verkrijgbaar, drivers zijn daar al voor gebouwd. Andere betaalbare infrastructuur is er ook al, zoals switches, maar een barebones implementatie is een directe verbinding tussen computer en apparaat. Nu is een FPGA met 10G transceivers redelijk duur, en vereist een betaalde versie van Quartus, maar we worden gered door een communicatie variant: XAUI.

XAUI is een protocol waarbij communicatie verloopt over een viertal 3.125Gbps lijnen. Deze kunnen dan extern gebundeld worden tot 1 maal 10G. Over het algemeen zijn chips voor het 10GE protocol redelijk duur, maar Texas Instruments bewijst met de TLK10031 dat het ook goedkoop kan. Deze chip kan werken als een XAUI naar 10GBASE-KR interface. Nu is dit geen RJ45 standaard, maar bedoeld voor een SFP+ poort. Dit is de poort op professionele netwerk switches waar je normaal gesproken een fibermodule in steekt. Routershop.nl heeft gelukkig ook een SFP+ module naar RJ45, en kost niet te veel. Mijn redding!

De gratis Prime Lite versie van Quartus heeft een XAUI PHY IP core beschikbaar, en deze communiceert met de eveneens aan te klikken 10G MAC. Deze accepteert een Avalon-ST bus, wat in werkelijkheid een parallel bus is met een beetje arbitrage. Als we op deze bus de data van een Ethernet packet kunnen krijgen, zijn we zo ver.

https://www.intel.com/content/dam/altera-www/global/en_US/images/products/ip/iup/images/xaui-phy.gif

Om hier mee te expirimenteren blijkt een dure aangelegenheid: Terasic verkoopt een dual XAUI naar SFP+ bordje, maar kost dik 800 euro. Dat is drie keer zoveel dan mijn C5G board waar ik hem op wil aansluiten. Dat komt natuurlijk omdat ze een dure Broadcom chip hebben gebruikt, maar het helpt mij niet. Op het internet is ook een ander ontwerp uit Rusland te vinden, maar niemand die dat verkoopt.

Om het geheel betaalbaar te houden zal ik een gok moeten gaan wagen: Zelf een print maken met alle hardware erop. Ik moet even mijn gigabit kennis gaan aanscherpen. Mijn ervaring is dat, als je je aan een paar basisregels houdt, een multigigabit lijn eigenlijk heel vergeeflijk is. Ingebouwde pre-emphasis, equalizers, en andere mechanismes zorgen ervoor dat het communicatiekanaal word geoptimaliseerd. Ik moet me bezig gaan houden met lengtes en impedanties.

1 electron per seconde = 16 atto ampere!

Goede morgen Dweil,

Mijn petje af voor zo'n ontwerp !!!!

Ik heb een praktische vraag over het solderen van de BGA. Werk je met loodhoudend soldeertin ? Wellicht gebruik je een verfschroeier met instelbare temperatuur. Verwarm je de BGA langs de onderkant ? Stel je een bepaalde temperatuur in ?

Op internet stond ooit een bijdrage van een Duitse student over het solderen van BGA's met huishoudelijke middeltjes. Dat was veel ingewikkelder dan uw methode. Hij maakte op basis van een omgekeerd strijkijzer een temperatuur geregelde voorverwarmer. Daarop werd de onderkant van de print verwarmd. Het eigenlijke solderen gebeurde met hete lucht. Die werd opgewekt door een klein ventilatortje aan de ingang van een koperen buis. In die buis zaten een reeks 12V halogeen lampjes.

Veel succes met dit knappe project,

Eduard

BGA solderen. Je hebt een aantal spulletjes nodig:

- Pincet van metaal
- Soldeertin
- Soldeerbout
- Heteluchtbron, termperatuur geregeld
- Losse flux, vloeibaar of gel
- Isopropanol Alcohol of Flux-off
- Doekjes, keukenpapier of zo
- Desoldeerlint (solderwick)
- Tandenstokers
- Print met outline van de BGA in silkscreen of koper.
- Vlakke ondergrond

De heteluchtbron heb je het liefst temperatuur geregeld en met een lage uitstroom snelheid. Gasbranders en de haarföhn van je zus werken niet. Begin met alle pads van de footprint op de print te vertinnen met de soldeerbout en de tin. Gebruik hierbij de losse flux. Als alle pads zijn vertint, gebruik het desoldeerlint en de bout om alle pads weer vrij van tin te maken. Wees voorzichtig zodat alle pads op de print blijven, en niet plots op het desoldeerlint zitten. Maak hierna je print schoon met alcohol of Flux-off, en het doekje/de doekjes.

Hou de BGA bij de hand, en bepaal hoe je deze later op de print gaat plaatsen. In het algemeen werken deze componenten veel beter als de A1 ball locatie op de PCB en het component overeenkomen. Zorg er voor dat je ondergrond vlak en stabiel is. Zet de print op je ondergrond met wat er tussen. Ik heb een paar tandenstokers gebruikt. Deze zijn ervoor dat de warmte niet in je ondergrond gaat zitten.

Begin met de print voor te verwarmen. Start met een afstand van +/- 15cm tussen je fohn, ingesteld op 400 graden Celcius, en de print. Zorg er voor dat je een groot gebied verwarmd, om vervorming van de print te voorkomen. Als je de tin vloeibaar ziet worden, stoppen en een paar seconden wachten. Doe nu een dun laagje flux op de print op de plaats waar je later je BGA wilt hebben.

Doe de BGA op de print en gebruik de outline op je silkscreen of koper om deze uit te lijnen. Het is niet erg als deze een héél klein beetje verschoven is. Sterker nog, dat is zelfs beter. Gebruik voor het uitlijnen je pincet, want alles is heel erg warm.

Als je BGA op je print is geplaatst en je bent tevreden met de uitlijning, begin met het opnieuw verwarmen. Begin, net als eerst, met een ronddraaiende beweging en zorg dat je niet één plek op je PCB of BGA blijft verwarmen, maar alles gelijkmatig opwarmt. Verklein tijdens dit proces de afstand van de print tot je heteluchtbron om de temperatuur te verhogen tot het smeltpunt van de soldeertin.

Omdat je uitlijning niet perfect was, zie je, als de tin smelt, de BGA op zijn plek springen door de cohesie van de tin. Dit proces heet "zelfregistratie". Als je dit ziet gebeuren, blijf nog een paar seconden verwarmen, maar stop daarna. Laat het geheel rustig afkoelen, gebruik geen geforceerde lucht of ijswater.

Laat de alcohol rijkelijk vloeien. Pak een bier voor jezelf, maar ook de IPA op de print in combinatie met die eerder vermeldde doekjes, om de boel schoon te maken. Flux-off gebruiken mag ook, maar dat is alléén voor de print bestemd. Klaar!

1 electron per seconde = 16 atto ampere!

Bedankt Dweil,

Het is me nog niet duidelijk of je de hete lucht onder de print of boven de BGA moet blazen. Ik ben geneigd te veronderstellen dat de lucht langs onder moet komen om daar de bolletjes te laten smelten. Langs boven moet de warmte doorheen de chip. Ik twijfel of de elektronica die behandeling overleeft.

Is een warme lucht soldeerstation toereikend om BGA te solderen ? De luchtstroom en het vermogen zijn daarbij kleiner dan bij een verfschroeier.

Vriendelijke groeten,

Eduard

Hoi Eduard,

De hete lucht moet eigenlijk overal komen, zowel onder de BGA als er bovenop. Ik hou de heteluchtbron niet haaks boven de print, dat is erg ongemakkelijk. Meestal onder een 60-70 graden hoek.

Ik heb al even aangehaald dat ik bezig ben met de ontwikkelen van een volgende versie Logic Analyzer. Omdat we nu in een gebied zitten waar het aantal kanalen afdoende is voor de meeste toepassingen, wil ik een meer flexibelere oplossing bieden. Daarnaast wil ik een betere signaalintegriteit creëren door het kort houden van de draden.

Dit kort houden kunnen we doen door aparte modules te maken, los van de analyzer zelf. Hier komen dan de signalen binnen, die daarna naar de logic analyzer gestuurd kunnen worden op een verantwoorde wijze: Differential Signaling. Hierbij heb je een positief signaal, en een negatieve versie. Op deze manier kan (door het inverteren van het negatieve signaal) storingen onderdrukt worden, en een goede overdracht meer haalbaar is.

De standaar dit ik wil aanhouden is LVDS, wat staat voor Low Voltage Differential Signaling. Dit is gelukkig alom ondersteund, door FPGA's en andere snelle IC's. De overdrachtssnelheid die ik wil bereiken is 400Mbps. Per LVDS kanaal. Vier van deze LVDS kanalen verzorgen de verbinding met de externe modules, waardoor ik een 1600Mbps ter beschikking heb. Dat is goed voor 16 kanalen op 100MHz. Of misschien 2 kanalen analoog? Er zijn meer mogelijkheden.

De volgende stap is de connector tussen de Logic Analyzer en de acquisitie modules. Het liefst geen custom connector, of een moeilijk verkrijgbaar type. Mijn keuze is gevallen op Mini Displayport. Deze bied 4 afgeschermde paren voor mijn 4 LVDS lijnen, 1 afgeschermd paar voor een referentie kloksignaal, voeding, configuratie, zeg maar alles wat ik nodig heb.

De voeding op de Mini Displayport is 3.3V op 0.5A. Nu heb ik geen problemen met de stroom, maar ik heb het liefst 5V over deze lijn. Dit zou het gevaarlijk maken om deze in een échte Displayport te stoppen. Dit kunnen we ondervangen door in de eerste instantie 3.3V aan te bieden, en na een succesvolle communicatie de voeding te verhogen naar 5V.

Acht van deze Mini Displaypoort zorgen voor een hoop data. 8 keer 4x 400Mbps om precies te zijn. De Logic Analyzer moet al deze data stoppen in een Ethernet Frame, dat naar de eerder genoemde XAUI IP core verstuurd worden, die op zijn beurt deze verstuurd over vier 3.125Gbps lijnen. Als je werkt met Multi Gigabit Tranceivers is layout cruciaal. De routing, lengte, impedantie etc moeten allemaal kloppen. Tijd om eens te kijken wat voor een PCB ik nodig ga hebben.

De bovenste en onderste laag heb ik nodig voor de gigabit lijnen. Op deze manier voorkom ik stubvorming als gevolg van de via's die ik wel ergens nodig zal moeten hebben. Deze twee buitenste lagen moeten daarbinnen voorzien zijn van een massavlak, om zo de juiste impedantie te kunnen verzorgen. Daarnaast heb ik minimaal twee lagen split power plane nodig. Als ik dan ook nog twee extra signaal lagen incalculeer kom ik op 8 lagen in mijn PCB.

De 4 XAUI lijnen moeten worden omgevormd tot een enkele 10Gbps lijn die naar de SFP+ poort gaat. De TLK10031 SERDES had ik hier voor al uitgezocht. Al met al begint het blokschema voor dit ontwerp zich te vormen.

Mijn eerste pogingen voor een routing van de FPGA vallen niet mee. Om meer plaats te krijgen onder de FPGA maak ik gebruik van het feit dat een 0402 SMD onderdeel precies past tussen twee BGA aansluitingen. Op die manier hou ik meer plek over voor het routen van andere lijnen. Desondanks valt het niet mee:

1 electron per seconde = 16 atto ampere!

Op 22 december 2019 22:23:05 schreef Dweil:
Mijn eerste pogingen voor een routing van de FPGA vallen niet mee. Om meer plaats te krijgen onder de FPGA maak ik gebruik van het feit dat een 0402 SMD onderdeel precies past tussen twee BGA aansluitingen. Op die manier hou ik meer plek over voor het routen van andere lijnen. Desondanks valt het niet mee:

Beperk je je tot vier lagen? Wat is de pitch van je BGA? En de limieten van je PCB technologie?

Hier is misschien een tip om wat ideeën te krijgen. Niet dat je het uiteindelijk zo uitvoert, het is gewoon een manier om inzichten te verwerven. Sommigen verkiezen punt 5 en verder eerst te doen, ik niet. De via's zijn het kostbaarst, een via die je kan sparen geeft je ruimte om te routen.

1. breng alle aansluitingen naar buiten (weg van de BGA, in alle vier richtingen), alsof je een breakout board aan het maken bent.
2. de eerste twee ringen is makkelijk: de buitenste rechtstreeks, en de tweede gewoon tussen de pads/balletjes door
3. de derde, vierde en vijfde ring duw je met een 45 graden offset via naar de tweede laag
4. ring 3, 4 en vijf rout je op laag 2 naar buiten

Maar nu zitten de binnenste ringen ingesloten.

5. Dus, nu verbind je VCC en GND op de eerste vijf ringen zo, zodat je via-vrije "openingen" krijgt waar je volgende binnenste ringen naar buiten kan brengen.
6. VCC en GND kan je op laag 4 doen. Je ontkoppeling doe je dan op laag 4 (de achterkant).
7. met wat geluk kan je de meeste signalen van ring 6 en 7, met wat gebruik van traces op laag 4 om bruggetjes te maken, ook op laag 2 naar buiten routen
8. hier gaat 90% van je tijd in zitten :) ... Nog 4 ringen. Maar met wat geluk is het grootste stuk van VCC en GND voornamelijk hier geconcentreerd.

Suffering from wiseass oneliner blackout

Voor "wat nu nog voor verbeteringen"...

Als je 300Mbyte/sec aan datatransfer naar de PC voor mekaar krijgt, dan kan je al 300Msps 8 kanalen naar de PC krijgen. Ruw zonder compressie.

Als je nu wat compressie (RLE) toepast, kan je met een paar kilobyte interne buffer al heel aardig > 300 Mbyte /sec aan ruwe data doorsturen. Ik zou dus op 1.2GHz willen samplen, een 1200 Mbyte/sec datastroom willen comprimeren en dan live naar de PC willen sturen. En dan dus naar keuze 8 kanalen 1.2GHz, 16 kanalen 600Mhz, enz.

Voor max flexabiliteit (en kostenbesparing) zou ik de boel zo maken dat je via de USB de configuratie van de FPGA kan aanpassen. Of eigenlijk: dat je altijd vanaf de PC de configuratie moet sturen. Saleae heeft dat ook gedaan met de "Logic 8": Een generieke chip zonder local storage die je dus via USB van firmware moet voorzien.

Maar goed, dat is mijn mening. Ik heb te weinig tijd om hier zelf in te investeren.....

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

4 lagen signaal, in totaal 8 laags (Twee voor ground en twee voor split plane). Ik zit echter met een hoop beperkingen, waardoor de (zeer goede) handleiding van Bert_mc niet altijd opgaat. Een groot gedeelte heeft te maken met de differentiële paren. Met de MultiGigabit Tranceivers wil ik op de bovenste of onderste laag zitten, in verband met de stubvorming. Ook moet de impedantie van alle diff paren redelijk kloppen. Er zijn een hoop tools op het internet te vinden, ik heb de tools op EEweb gebruikt. Klop hier de stackup en board info van je PCB boer op in. Mijn target is 50 Ohm per lijn, 100 Ohm differentieel.

De 3.125Gbps lijnen komen op de onderste laag, omdat mijn TLK10031 SERDES de paren ergens midden in de BGA heeft zitten. Ik heb dus de microstrip waardes hier voor nodig.

De andere LVDS lijnen zitten al op de binnenlagen. Het is dus een beetje dubbelop om deze eerst te routen naar een ideale BGA fanout laag. Ik probeer op dezelfde laag toch uit te komen. Hier moet ik mij dus aan de waarde houden van de stripline calculatie.

Voor de rest wil ik veel ontkoppel condensatoren hebben onder mijn BGA. Dit omdat het de signaalintegriteit binnen in de FGPA ten goede komt. De ideale situatie is dat een power supply via en GND via naast elkaar zitten. Ook dit betekend dat je soms van de ideale fanout moet afwijken. Als deze niet naast elkaar hebt zitten betekend dat je via's gaat opofferen.

Al met al krijg je dus zo'n warboel aan traces zoals op mijn plaatje.

1 electron per seconde = 16 atto ampere!

Bijna het einde van het jaar. Mijn goede voornemen: Een 10 gigabit ethernet logic analyzer maken. Ik heb een test setup besteld:

- 10GE Asus XG-C100C netwerkkaart
- Ubiquiti UF-RJ45-10G SFP+ RJ45 module
- 3m Cat6A kabel
- 3m Cat7 kabel
- HP 530SFP+ netwerkkaart

Ik heb de HP kaart gekocht zodat ik de SFP+ module kan testen voordat ik deze in mijn eigen PCB stop. Op die manier kan ik alles op functionaliteit testen.

Mijn 10GE PCB ziet er op dit moment zo uit:

Op- en/of aanmerkingen zijn welkom!

1 electron per seconde = 16 atto ampere!