Logic Analyzer zelf maken

Naar aanleiding van mijn post in het PCB topic, wil ik wel wat uit de doeken doen over een recent project, een Logic Analyzer. Nu is een logic analyzer niet uniek, er zijn heel wat kant-en-klaar ontwerpen te vinden op Aliexpress en andere webwinkels. Het doel echter, welke ik heb voor mijn logic analyzer, is anders. Huidige ontwerpen zijn bedoeld voor vooral seriële protocols, zoals SPI, I²C, UART etc. Ik wil kijken naar een processor bus. Ik wil weten welke adressen de processor aanspreekt, en welke data erover gaat. Bijvoorbeeld van een 68000, 6502, 8088 en nog meer van dat soort oude processoren. Het gaan dan over veel I/O. een 32 bit adres bus, 32 bit databus, wat chip enables, byte enables, read, write, ga zo maar door. Mijn logic analyzer heeft de mogelijkheid tot max 96 kanalen.

https://www.picclickimg.com/d/l400/pict/162891301611_/MAN-Roland-CPU-86-Circuit-Board-New-Wohlenberg-5040538X-6.jpg
Voorbeeld van een processorsysteem.

https://hackadaycom.files.wordpress.com/2009/03/cover1.jpg?w=640
Goedkope analyzers hebben te weinig I/O voor mijn toepassing.

https://www.electronicdesign.com/sites/electronicdesign.com/files/styles/article_featured_standard/public/EE_LogicAnalyzers_Promo.jpg?itok=T3Lu1zjP
Analyzers met meer I/O vallen net buiten mijn budget.

Veel I/O zorgt voor veel data. Meer dan dat een USB2 verbinding aan kan. De gebruikelijke oplossingen, zoals een FTDI 2232H of een Cypress USBFX2 zijn helaas niet bruikbaar voor mijn doel. Nu kan ik, door buffer geheugen te gebruiken wél snel data verzamelen, die daarna traag over de USB bus gaat. Gelukkig heeft FTDI een nieuw product, de FT601B. Dit is een chip, met een makkelijke 32 bit parallel FIFO interface erop, en USB3.0 5Gbps snelheid. Ik heb ervaring met de FT245, en de FT601 interface beloofd een soortgelijk protocol.

De manier om 96 bits op een 32 bits bus te krijgen, is een multiplexer. Nu is 100MHz, welke de FT601 geeft, een beetje snel voor reguliere TTL logica, dus een FPGA lijkt me op zijn plaats. Nu we toch een FPGA gebruiken, kunnen we meteen een heleboel meer logica inbouwen. Ik zou, omdat de I/O pins op een FPGA bidirectioneel zijn, ook een pattern generator functie kunnen inbouwen. Uitgebreidere trigger mogelijkheden, een crosspoint switch, nog meer toeters en bellen?

Uiteindelijk ben ik op mijn ontwerpkeuzes gekomen:
- USB3 interface naar de PC.
- Compact ontwerp
- Kan werken met een bereik aan ingangsspanning, dus niet alleen 3.3V en 5V.

Hierop heb ik met een FT601B dev kit gespeeld. Je kunt deze evaluation modules kopen van RS, Farnell, Digikey en andere groothandels. Ze zijn te krijgen voor de expansieconnectors van Altera (Intel) en Xilinx FPGA borden. Een Terasic C5G was voor mij nog redelijk goedkoop.

https://www.ftdichip.com/Images/UMFT601X.jpg

Na een tijdje met deze combinatie gespeeld te hebben, viel het mij op dat de overdrachtssnelheid naar de PC niet echt super is. Aangezien wel het Super Speed protocol wordt gebruikt was dit wel vreemd voor mij. Wat speuren in de voorbeelden die FTDI geeft, kwam ik er achter de de D3XX driver, die te downloaden is en bedoeld voor de FT600/FT601, nogal wat tijd gebruikt om de overdracht te initiëren. Door meer data in 1 keer over te sturen, gaat het aanmerkelijk sneller. Nu heb ik het dus over (veel) meer dan de 4KB buffer van de chip zelf. Pas bij 256KB pakketten, kwam er wat snelheid uit (zeg 300MB/s).

Ik moet dus aardig wat data klaar hebben staan. Dat betekend meer geheugen. Zoveel zelfs, dat ik ben gaan zoeken naar een externe geheugenchip. DDR2, LPDDR2, en andere vormen van dynamisch ram zijn wel snel, maar hebben redelijk wat overhead in de vorm initialisatie en arbitrage. Traditioneel SRAM is traag. Synchroon SRAM heeft een klok, en kan dus snel werken. Een nadeel van dit Zero-Bus-Turnaround of No-Bus-Latency SRAM is dat de data pas 2 klokpulsen volgt nadat je het adres hebt opgegeven. Geen probleem, hier kan ik wel wat op verzinnen.

Al met al wordt het me duidelijk wat voor een I/O ik moest hebben op mijn FPGA:
- ongeveer 50 I/O voor naar mijn FT601.
- 96 I/O voor mijn UUT interface, met 6 tristate lijnen om mijn buffer IC's om te zetten van ingang naar uitgang (pattern generator!).
- ongeveer 55 lijnen naar mijn SRAM.
Dit is geen job meer voor een QFP, en dus gaat het een BGA worden. Nu heb ik nog nooit met BGA's gespeeld in de hobbysfeer, wel op het werk. Nu we toch beland zijn op een BGA, kunnen we meteen de SRAM kiezen in BGA. Dat scheelt plaats op mijn PCB, en het rijmt met het compacte ontwerp welke ik wil maken.

https://www.distrelec.nl/Web/WebShopImages/landscape_large/30/3f/hammond-1553dtbubkbat-02.jpg
De gekozen behuizing is een blauw semi-transparante handbehuizing van Hammond. 1553DTBUBKBAT Heeft een uitsparing voor een 9V blok. Daar gaan mooi die I/O connectoren in!

Printje.

Hoe krijgen we een Cyclone 10 op een PCB? Ik zeg Verfstripper. Eerst alle pads vertinnen, schoonmaken, gelflux erop en maar heet stoken.

Hoera, hij zit erop!

Hoe gaan we dit testen? Ik moet natuurlijk alle spanningen toevoeren. 3.3V met mijn voeding, 2.5V LDO op de PCB, en 1.2V buck converter moet er ook op. Een hoop superkleine 0402 condensatoren op de onderkant, bulk condensatoren ook. Uren aan soldeerwerk. Dan kan ik met de programmer beurtelings een pulsje zetten op elke I/O pin. Zie ik een puls met mijn scoop -> I/O pin werkt. Geen puls? Niet verbonden. 2 pulsen betekend dat ik sluiting heb.

ALLES werkt! Gesterkt met dit feit, kan ik nu alle andere componenten plaatsen.

1 electron per seconde = 16 atto ampere!

respect. Leuk ook dat het solderen van die BGA gelukt is :)! dat geeft de burger moed!

Super gaaf project, hoe lees je dit nu weer uit op de pc?

Ik vraag me wel af of die chip zo'n verfstripper wel fijn gaat vinden...
Temperatuur komt waarschijnlijk ver boven wat is toegestaan. (meestal iets van 260 graden voor xx seconden)

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Als je stopt met "verfbranden" zodra de boel vast gaat zitten dan is de chip niet-of-nauwelijks boven de 260 geweest. Ik de-soldeer ook m'n spullen met de "hot air" op 450. Zo gaat het redelijk snel en krijg ik de boel er "heel" af. Zet ik hem lager, duurt het veel langer en gaan de chips kapot.

Farnell is kennelijk een paar generaties terug gestopt met Altera (Intel) FPGAs doorverkopen. De nieuwste die ik zie is de cyclone IV.

Mouser heeft wel Cyclone 10 chips, De kleinste voor 8 euro, een 3x grotere voor onder de 20. Ik heb zitten kijken naar de TQFP variant.

Ik had zelf met een kleinere versie van dit project begonnen. Kleinere FPGA, en dan met een "highspeed" FTDI naar de PC. Als je toch al RAM moet hebben om te bufferen, dan maar zo.

De goedkope Saleae clonen zijn zo goedkoop omdat ze de data "live" naar de PC sturen. De PC moet dan maar in software de triggering e.d. doen. Als je in je device gaat bufferen dan hoeft de data niet "live" naar de PC.

Bij een scoop wil je "live" meekijken naar een veranderend springend signaaltje. Bij een logic analyser zit ik eigenlijk altijd naar een stilstaand plaatje te kijken. Als je bij het oversturen de adreslijnen achterstevoren gebruikt, dan kan je ook van zeg "1Gb data" na 1/16e van de tijd 64Mb hebben overgestuurd en dat is dan precies iedere 16e sample. Kans dat de gebruiker zo ver ingezoomd is dat het 'm kan schelen is klein. Als de software kan "vragen" om bepaalde ranges met bepaalde stap-groottes dan is het helemaal te verbergen voor de gebruiker dat een deel van de capture nog niet naar de PC is gedownload: Dat downloaden kan met 30Mb/s (op USB2) en zo snel kan jij geen data bekijken.

Anyway, met 100+ MHz samplen is prima te doen als je een beetje FPGA met RAM in je LA hebt zitten. Ik zou kleiner begonnen zijn, maar als het zo lukt, dan is dit een prachtig project! Chapeau!

Wat voor taaltje schrijf je de FPGA code?

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

Dapper hoor, zo'n BGA op een eigen print met beperkte middelen! Leuk contrast ook, een FPGA in BGA package tegenover een board met CPU, RAM, en logica allemaal in DIP packages in IC voeten.

Zou het niet gemakkelijker zijn geweest om een paar losse logic analysers te gebruiken, met gedeelde trigger signalen, en de data aan de PC kant op een hoop te gooien? Nu moet je de PC software tenslotte ook zelf schrijven. Met zo'n constructie had je natuurlijk geen patroon generator gekregen, maar ik krijg de indruk dat die er vooral bij gekomen is omdat het kan.

Was het niet gemakkelijker geweest om een FPGA te gebruiken met genoeg RAM aan boord, of zou dat veel duurder zijn geworden? Ik weet niet wat de maximale latency is van die USB controller, en dus hoeveel buffercapaciteit je nodig hebt, maar de grootste Cyclone 10 (10CL120) is bij Mouser al ~160 euro, maar dan krijg je 3888 kB aan RAM.

Voor zover ik weet loopt een 68000 op maximaal 20MHz, dus als je de logic analyser synchroon daarmee laat lopen, heb je die 100MHz niet nodig. Als je toch een FPGA gebruikt, kun je wellicht ook RLE (run-length encoding) gebruiken, of op een slimmere manier data comprimeren.

[Bericht gewijzigd door SparkyGSX op 16 maart 2019 16:45:17 (36%)]

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

Mooi project zeg. En veel respect voor je BGA knutselarij.

Maar usb draadjes blijven een flessenhals. In de oude tijd zou ik zeggen gebruik een firewire verbinding. Alleen is dat ver ingehaald door de tijd en is usb nu een stuk sneller. Andere mogelijkheid was ooit de scsi bus maar ook dat is obsolete.

Zou je niets kunnen met de nieuwste sata standaard? Ik denk dat je dat momenteel toch wel een beetje tot de snelste vorm van intern data transport kunt rekenen.

ex-fietser: USB-3 gebruikt zo'n beetje het SATA-lowlevel protocol, dus ik verwacht niet dat je nog meer snelheid daaruit gaat halen. En USB is precies voor dit soort dingen bedoeld. Dus bepaalde voordelen ga je gewoon op meeliften.

De throughput is m.i. niet essentieel.

Over software: D'r is een open source pakket die tegenwoordig ook met de goedkope saleae dingen moet kunnen werken. Daar moet je een input-module voor schrijven voor je eigen spul en dan zou je direct een nette gui moeten hebben.

Maar ik zou het al een overwinning vinden om een klein programma te hebben wat de boel "effe" in een file dumpt. :-)

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

ex-fietser: USB-3 gebruikt zo'n beetje het SATA-lowlevel protocol, dus ik verwacht niet dat je nog meer snelheid daaruit gaat halen

@REW

Dat wist ik niet. En dan kun je dus inderdaad niet sneller. Weer wat geleerd.

Misschien dat dan alleen de ouderwetse DMA technologie zoals dat vroeger ging nog overblijft. Maar ik meen uit het verhaal van de TS te begrijpen dat hij al zoiets geprobeerd had. En dat ook dat geen soelaas geboden heeft.

[Bericht gewijzigd door Ex-fietser op 16 maart 2019 16:49:42 (32%)]

rew: Je haalt de woorden uit mijn euhh, toetsenbord. De bedoeling is om Sigrok's Pulseview te gebruiken. Daar moet een driver voor gemaakt worden. Daarnaast een apart programmaatje om alle andere mogelijkheden te kunnen benutten. En dus ook een fast capture mogelijkheid. Met 300MB/s heb je al een goede SSD nodig om al die data kwijt te kunnen.

Mijn Cyclone 10 heb ik van Digikey. En het is eigenlijk een ge-rebatchte Cyclone 3 of 4. Dat zegt althans de JTAG ID. Programmeren van die FPGA doe ik in VHDL. Verilog ligt me minder.

Leuk detail: Ik heb met de evaluation kit gezocht naar de snelste manier om de data te verwerken. C(++), dotnet, Python. Je gaat het niet geloven maar uiteindelijk wist 64 bit Python het snelst om te gaan met de D3XX driver, geheel tegen mijn verwachting in.

1 electron per seconde = 16 atto ampere!

De truc met het voor vertinnen werkt goed, je kan ook een heel klein beetje pasta aanbrengen en de BGA direct solderen. Gaat bij mij eigenlijk altijd goed.

Mooi projectje, zo zie ja maar weer dat ook SMD prima te verwerken valt voor hobby projecten.

This is the world we know best, the world of madness

Op 16 maart 2019 16:55:30 schreef Dweil:
Verilog ligt me minder.

Oh, da's bij mij precies andersom. :-)

...
maar uiteindelijk wist 64 bit Python het snelst om te gaan met de D3XX driver, geheel tegen mijn verwachting in.

Inderdaad, dat wil ik niet geloven. :-)

Python is ook maar gewoon een C-programma wat een ander taaltje interpreteert. Dus in theorie kan het niet sneller zijn dan een goed C-programma.

Dat neemt niet weg dat "een optimaal geimplementeerde library" misschien makkelijker te vinden is voor Python, zodat de keuze voor python uiteindelijk gewoon prima verdedigbaar is.

Sigrok, ja. Kon even niet op de naam komen.

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

Golden Member

Kun je die BGA's er ook in China op laten zetten ? Ik lees daar regelmatig over "Assembly Services".

De jongere generatie loopt veel te vaak zijn PIC achterna.

De driver voor de FT601 heet FTD3XX, en is voor alle programmeertalen hetzelfde. Dit is ongetwijfeld een stukje supersnel C. Als je wilt communiceren vanuit Visual Studio Express, moet dat met een andere DLL: FTD3XX_NET. Hierin zitten alle routines in om te gebruiken. Je communiceert dus niet direct met de D3XX interface. In Python heb je een andere interface, libftd3xx en die werkt zowaar 20% sneller dus. Ik heb geprobeerd alles nog sneller te krijgen in Python, maar Numpy en Cython werken beide trager.

Om 96 bits te versturen met een 32 bit brede 100MHz bus heb ik (minimaal) 3 cycles nodig. Het is dus niet 100MHz, maar maximaal 33MHz welke ik kan samplen. Omdat wat protocol toch handig is over een snelle bus, heb ik 4 cycles nodig. Ik verstuur dus 128 bits om 96 bits aan informatie te krijgen. Wat ik heb gedaan is de 96 bits op te delen in 4 maal 24 bits. Per cycle heb ik dan 8 bits aan overhead om aan te geven wat ik met het pakket wil doen.

De laagste 24 bits geef ik een "preamble" A om aan te geven dat het om de laagste 24 bit gaat. Preambles B, C en D zijn dus voor bits 24-48, 49-72 en 73-96 respectievelijk. Tegelijk geeft preamble A een sample klokpuls aan. Dit bied mij de mogelijkheid om datareductie toe te passen: In een normale "full frame" pakket stuur ik dus preambles D C B A, waarna ik 96 bits heb verstuurd.

Als pakket D hetzelfde bevat als het vorige pakket D, verstuur ik hem niet. C B A heb ik dus 72 bits, waarbij D gepakt wordt van het vorige pakket waarbij D wél werd verstuurd. Als ik dus "oversample", kan ik dus volstaan met alleen preamble A, tenzij er iets veranderd, dan moet ik meer data versturen. Op deze manier kan ik ook de hoeveelheid bits aanpassen. Als ik maar 24 bits nodig heb, kan ik dus volstaan met alleen preamble A, en dus gaat mijn max sample frequentie omhoog (tot een theoretische 100MHz dus). 48 bits bij 50MHz, enz.

Dit heeft als voordeel dat ik veel minder logica nodig heb dan bijvoorbeeld RLE, en toch flexibiliteit heb in de hoeveelheid data die ik verstuur. Daarnaast heb ik minder computer CPU cycles nodig om te decoderen, een simpele bitshift volstaat na het kijken welke preamble ik heb.

Het is dus zaak om alle relevante data zoveel mogelijk te verplaatsen naar de lage bit waardes. Dat verklaart het feit dat ik een crosspoint switch wil integreren, waarbij elke ingang kan worden verbonden met elke uitgang. Voor een 96x96 supermux heb ik heel, heel veel logica nodig. Eigenlijk wil ik nog meer in- en uitgangen intern in de FPGA, voor bijvoorbeeld een geavanceerd trigger mechanisme. Een 128x128 MUX ga ik gebruiken in mijn FPGA. Twee keer: 1 voor de Logic Analyzer, 1 voor de pattern generator. Weg zijn 24000 LE's. Maar goed dat ik er meer dan 39000 heb in mijn gekozen Cyclone 10CL040.

1 electron per seconde = 16 atto ampere!

Python is ook maar gewoon een C-programma wat een ander taaltje interpreteert.

Python zit toch echt wel een level hoger dan C en word als een hogere programmeertaal dan C beschouwt.

Bij de STM32Fxxx processoren hebben ze voor de pin change interrupt een kleine beperking aangebracht: PCI0 (pin change interrupt nul) kan hangen aan PA0, PB0, PC0 ... En PCI1 aan PA1, PB1, PC1 ... enz. Zo zijn er 16 (plus een beetje) pinchange interrups, en kan je makkelijk regelen dat het "uitkomt". Het is wel luxe om alles aan alles te kunnen hangen, maar zo'n beperking als in de STM32 kan je zomaar een factor 16 in de hoeveelheid LEs schelen.

In jou geval zou ik bijvoorbeeld voor A0 positie in het datawoord P0, P8, ... P88 mogelijk maken. Zo bespaar je je waarschijnlijk een factor 8 aan logica (of meer!).

Op 16 maart 2019 18:50:08 schreef benleentje:
[...]Python zit toch echt wel een level hoger dan C en word als een hogere programmeertaal dan C beschouwt.

Python is net als C een "hogere programmeertaal". Als er python fanaten zijn die vinden dat Python "hoger" is dan C, dan wil ik dat best geloven.

Je quote mijn statement dat de Python interpreter ZELF in C geschreven is. Eigenlijk was dat kennis van heel lang geleden danwel een gok. Maar het is wel waar: https://github.com/python/cpython/tree/master/Parser

[Bericht gewijzigd door rew op 16 maart 2019 18:58:38 (32%)]

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

Op 16 maart 2019 17:42:18 schreef bprosman:
Kun je die BGA's er ook in China op laten zetten ? Ik lees daar regelmatig over "Assembly Services".

Ja, dat kan. Zeer waarschijnlijk zit er dan een Chinees kind van 9 met een verfstripper je BGA's op de print te zetten ;-)

1 electron per seconde = 16 atto ampere!

Ik bedacht net dat ik nog wel een super simpele (en daarmee efficiënte) Ethernet implementatie heb liggen in Verilog, maar die is "maar" 100Mbps (op een 100MHz Spartan-3, het is alweer een tijdje geleden dat ik die gemaakt heb), en blijkbaar kun je nu al 320Mbps halen, dus daar schiet je niets mee op. Wellicht is gigabit Ethernet nog een optie?

Een andere simpele optie lijkt me op de clock van je target wat langzamer te laten lopen, of, zoals ik al eerder opperde, de logic analyser te synchroniseren met die clock, dat scheelt flink in de sample rate die je nodig hebt.

Als je op 100MHz aan het samplen bent, en je target loopt op 20MHz of langzamer, zul je vrij vaak samples krijgen waarbij alle 96 signalen identiek zijn, lijkt me. Aangezien je maar 2 bits van je preamble nodig hebt voor het identificeren van het pakket (A/B/C/D), heb je dus 6 bits over, en dan zou je daarin op kunnen slaan dat het voorgaande pakket 1-64x herhaald moet worden. Met een dergelijke sample rate kun je nooit live meekijken, dus die verwerking kun je ook achteraf doen, dan hoef je live alleen de data op te slaan.

Nu weet je van tevoren nooit precies wanneer zoiets gaat gebeuren, maar zolang je zeker weet dat x% van samples op die manier helemaal niet verstuurt hoeven te worden, kun je daar alsnog gebruik van maken om de effectieve sample rate omhoog te krijgen.

Met zo'n logic analyser, die dus een dergelijke hoge sample rate voor onbepaalde tijd kan volhouden, heb je wel een zeer krachtige debugger gemaakt; niet alleen kun je een programma stap voor stap volgen, je kun ook terug in de tijd!

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

De Python interpreter is inderdaad in C geschreven en ook veel extension modules die functionaliteit beschikbaar stellen aan Python code zijn in C, C++ of soms zelfs in assembler geschreven. M.a.w. de Python code zelf hoeft niet snel te zijn zolang het zware werk maar uitbesteed kan worden aan een extension module die in bijv. C geïmplementeerd is.

Zelf heb ik in het verleden een vision applicatie in Python geschreven. Omdat vision een hoop number-crunching impliceert zou dit met zuivere Python code niet vooruit te branden zijn geweest, echter doordat het zware werk door OpenCV en NumPy werd gedaan (die in C en C++ geïmplementeerd zijn) performde deze applicatie toch verrassend goed.

In dit geval denk ik dat de Python driver ook gewoon in C of C++ geïmplementeerd is. Dat de .NET wrapper trager is is nog wel te verklaren, maar waarom de Python variant sneller is dan de C of C++ library kan ik niet verklaren. Er wordt gesproken over Visual Studio Express, wat een oude compiler is en die volgens mij geen optimalisatie ondersteunde. Ook debug builds kunnen aanzienlijk trager zijn dan release builds. Tegenwoordig is er eigenlijk geen reden om zo'n oude compiler te gebruiken; tegenwoordig heb je de Visual Studio Community Edition die je als hobbyist gratis mag downloaden en gebruiken, up-to-date is en vrijwel alle toeters en bellen van de Professional Edition heeft.

Python is een prima keuze om iets snel in elkaar te gooien en wanneer het zware werk uitbesteed kan worden aan een module die in C of C++ geschreven is. Op het moment dat je Python code gaat schrijven met loops die miljoenen keren doorlopen moeten worden dan kan de interpretatie overhead van Python problematisch worden.

Op 16 maart 2019 20:08:25 schreef SparkyGSX:
en blijkbaar kun je nu al 320Mbps halen, dus daar schiet je niets mee op.

Zoals ik het lees, haalt ie nu rond de 2400Mbits/s. Ik denk dat die 300 Mbytes/s zijn!

Ik laat printjes bestukken door Elecrow. Die hebben een betere reflow oven dan ik.

Ik klaag zo nu en dan over dingen die ze niet helemaal goed hebben gedaan. En dan laten ze blijken dat ze dat vervelend vinden en graag 100% werkende printjes zouden uitleveren. Ik moet alleen een "test procedure" aanleveren.

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

SparkyGSK: Nogmaals, mijn USB3 implmentatie heeft 5Gbit lijnsnelheid. dat is 5000 Mbit. Kansen om een snellere overdracht te krijgen zijn:

- 10G Ethernet (10Gbit)
- USB 3.1 Gen 2 (10Gbit)
- Thunderbolt (ook 10Gbit)
- USB 3.2 Gen 2x2 (20Gbit)
- Magie (QDR Infiniband, Interlaken, nog sneller Ethernet)

Het is dan bijna onmogelijk om een sustained datarate vol te houden. De FT601 interface is echt het kinderfietsje wat betreft snellere dataoverdracht. Met zijwieltjes. Eenvoudiger dan dit kan bijna niet. Signed driver is voorgekauwd, veel programmeervoorbeelden, multiplatform ondersteuning. De QFN76 op 0.4mm pitch is eigenlijk het meeste lastige. Ik had liever een DIP14 gezien.

Dank je Patrick voor een prima uitleg!

1 electron per seconde = 16 atto ampere!

Eh, oeps, 32bit keer 100MHz is 3200Mbps, dus 400MBps. Dat is best indrukwekkend! Je zult al met een behoorlijk snelle SSD moeten komen om dat weg te schrijven, anders ben je beperkt tot bufferen in RAM, en met zulke datarates gaat ook dat hard!

De vraag is natuurlijk wat je met al die data gaat doen; als je een capture hebt van vele gigabytes, hoe ga je daar iets in terugvinden? Je zou kunnen zoeken op specifieke adressen of, als je de data goed kunt interpreteren, zoeken naar een lees- of schrijfactie van een bepaald adres met een bepaalde waarde.

Op 16 maart 2019 21:02:48 schreef Dweil: De QFN76 op 0.4mm pitch is eigenlijk het meeste lastige. Ik had liever een DIP14 gezien.

-=proest!=- ja, USB 3 in een DIP, dat zou een leuke 1-aprilgrap zijn.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

In de jaren 90 heb ik met een HP 16500A logic analyzer gewerkt. Deze had een memory depth van 4K per kanaal. Dat betekende dat wanneer je met een snelheid van 100 Mhz (het maximale wat dat ding aan kon) je maar een tiental microseconden kon capturen. Het was altijd een hele kunst om een combinatie van triggers en acquisition rate te vinden om precies dat te capturen waar in je geïnteresseerd was.

Moraal van dit verhaal; wat Dweil voor ogen heeft is al vele malen capabeler dan wat ten tijde van de 68000, 6502...etc beschikbaar was.

Absoluut; sterker nog, het is vele malen capabeler dan wat er voor "leuk geld" te koop is.

Persoonlijk zou ik geen noodzaak hebben aan 96 kanalen, maar 16 kanalen op 400MHz zou toch leuk zijn. Een redelijke geheugendiepte is goed genoeg, maar onbeperkt lang samplen is natuurlijk geweldig.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

Dweil, laat je niet afleiden door gefilosofeer van ondergetekende. maar....

Ik denk dat ik toch RLE zou implementeren. In een FPGA moet dat goed te doen zijn.

Je hebt een stream data, die door twee opeenvolgende registertjes gaat. Daarnaast heb je een teller. Een comparator geeft aan: gelijk of niet. Gelijk -> teller ophogen. Niet gelijk OF teller op de hoogste stand: data+teller wordt aan de output stream toegevoegd.

Met jou 24+8 databits zou je dan 2 bits kanaalidentificatie en 6 bits teller kunnen hebben.

Ik zou op die manier graag ipv op 100MHz op bijvoorbeeld 2- of 3 honderd MHz samplen. Je moet dan er op vertrouwen dat dit de data voldoende reduceert dat je memory bandbreedte dat aankan.

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