Logic Analyzer zelf maken


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 honder 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/

rew, als ik het zo lees, hoef ik alleen maar op preamble A de RLE compressie toe te passen. Ik heb namelijk geen B, C en D als daar niets veranderd. Omdat ik graag wat andere preambles overhoud voor toekomstige uitbreiding, denk ik dat ik een A0-A7 maak. Het getal geeft dan aan hoeveel A gekopieerd moet worden. Mijn sample frequentie gaat toch niet boven de 200MHz komen, omdat de 74LVC16T245 level shifters niet hoger gaan.

1 electron per seconde = 16 atto ampere!

Het datasheet van dat ding wat ik gezien heb heeft het over een propagatietijd van rond de 5ns MITS je hem met 5V voedt. Dat zou een minimale pulsbreedte van 5ns impliceren, max 200MHz samples.

Maar wat het datasheet niet vermeldt is (of: ik kon het niet vinden dat...) Als een input na 3ns hoog te zijn geweest weer laag wordt, wat zie je dan aan de output? Toch een 3ns pulsje? 1ns (minder)? 5ns (meer)? Wat er dan gebeurt weet je nog niet.

Daarnaast... Wat als je aan een systeem aan het meten bent waar de RAM chips 3ns "setup" tijd hebben. Maar je LA ziet voorlopig geen verschil in het veranderen van de data en het veranderen van je enable signaal?

Als je nu op 1GHz zou samplen, ondanks dat er "max 200MHz" beperkingen in je datapad zitten, zal je de setuptijd van die 3ns nu goed moeten zien.

Met jou plan: "ik heb helemaal geen D als daar niets verandert", doe je volgens mij een 1:33 compressie. Dat dat ene extra bitje in de A-stream zit dat doet er niet toe. Mijn voorstel RLE encoding doet "max 1:64", dus dat scheelt niet zo veel.

Je data-stroom begint met max 12 bytes * 200MHz = 2.4GB/sec. Dat wil je enerzijds je RAM in kunnen duwen en liefst ook nog live naar de PC. Als je dan op wat voor manier dan ook dat weet te comprimeren naar zeg 300MB/s dan gaat dat gewoon helemaal lukken. Zo'n FPGA is flexibel: je kan altijd nog iets aan de compressie veranderen.

Ik zou het "ruwe data naar RAM stouwen" en "ruwe data naar USB" al een hele overwinning vinden als dat werkt.

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

precies mijn gedachte: Eerst maar eens iets werkend krijgen, daarna kunnen we gaan voor optimalisatie.

1 electron per seconde = 16 atto ampere!

Als ik het goed begrijp stuur je pakket A nu altijd elke cyclus, en B t/m D alleen als daar iets veranderd is. Je kunt de compressie dan verbeteren door signalen die vaak veranderen zoveel mogelijk in de set van A te houden, en signalen die samen veranderen (zoals een adres of data bus) zoveel mogelijk bij elkaar in één van de andere sets, zonder andere signalen die onafhankelijk veranderen erbij.

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

Jep! Dat heeft ie al gezegd dat ie dat van plan is.

Ik geloof dat daar die grote switch matrix van gekomen was.

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

Dweil,

Ik heb je net gemist op het #sigrok IRC kanaal. Ik heb de situatie met de FT601 eens bekeken, en het is helemaal niet zo erg als werd voorgesteld.

Linux heeft geen kernel driver aan boord voor de FT601, maar er is er wel een:

https://github.com/lambdaconcept/ft60x_driver

Maar dat is niet de beste manier om de ondersteuning in sigrok te krijgen. Het is namelijk zo dat de officiele, closed-source driver van FTDI voor Linux ook gewoon libusb gebruikt, net zoals de meeste sigrok drivers dat doen.

Tussen de kernel driver hierboven (die het FT601 protocol dus implementeert) en de wetenschap dat het zonder probleem vanuit libusb kan, is het geen probleem om gewoon via libusb een sigrok driver voor jouw logic analyzer te maken.

Ik hou dit forum niet erg in de gaten, kom anders terug naar het IRC kanaal om dit te plannen.

Maar wanneer ga je ze nou op kickstarter aanbieden? En wat zijn je kosten geweest?

Meep! Meep!

Ik denk inderdaad dat dit op Kickstarter een goede kans maakt, maar dan moet je daar wel zin in hebben natuurlijk.

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

Kickstarter heeft helaas bij mij een beetje een slechte nasmaak gekregen. Ik open source de hele boel nog liever. Dat betekend dat er volledig toegang is tot schema's, gerbers, firmware, drivers etc. Gelukkig hoef ik er, zoals al mijn andere hobby projecten, er geen geld mee te verdienen. Daar heb ik mijn werk voor.

Biot: Dank je voor de bemoedigende woorden. Na mijn "kennismaking" met een paar van de Sigrok developers, zag ik het redelijk donker in aan de software kant. Ik ben zelf geen held in desktop programmeren (ik zit veel liever embedded) en heb zeker hulp nodig op dit vlak. Ook hier zou, als ik de boel open source maak, door andere mensen veel goed werk gedaan kunnen worden. Ik ga het nogmaals proberen op de #sigrok IRC.

Wat betreft kosten: Prototypes zijn kostbaar, maar het is leuk om te experimenteren met technieken die niet over al bekend zijn. Je kunt zelf bepalen of een dergelijk project interessant is:

- Print 4 laags 147x74x1.6
- Cyclone 10CL040YF484C6G
- EPCQ64A
- FT601B
- IS61NLP25636A-200
- 6x 74LVC16T245DGGR
- 12x SP3003-08ATG
- LM2852XMXA-3.3
- LM2852XMXA-1.2
- LP2992AIM5X-2.5
- hoop passieve componenten

Ik kom op 133 euro ex voor bovenstaande componenten, plus behuizing. Ik weet niet hoeveel je er voor bereid bent te betalen, maar reken op plusminus 250 euries voor de print, onderdelen en behuizing.

1 electron per seconde = 16 atto ampere!

Heeft de FTDI niet nog een paar pinnen over dat je de FPGA in "slave" mode kan programmeren over USB? Voor V1.1 van de print denk ik.

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

Hopelijk heb je het over de twee GPIO pinnen. Deze zijn op mijn PCB uitgeroute naar soldeerbare punten. Ik heb er 2 pulldown weerstanden op zitten. Wat wilde je met deze pinnen doen? Heb je een eventueel een voorbeeld hoe deze te verbinden?

1 electron per seconde = 16 atto ampere!

Ik heb het al een kleine 20 jaar niet meer gedaan, maar je kon toen met wat pins de chip in "slave" configuratie mode zetten. Dan kan je serieel de config naar binnen klokken. Als je de config vanaf de PC kan uploaden dan kan je grappen doen met alternatieve FPGA contents afhankelijk van triggering bijvoorbeeld.

Het heet "passive serial". Ik heb nu twee datasheets bekeken en nog steeds weet ik niet welke pins daarvoor nodig zijn. Ik geef het even op.

Dus ik weet niet of die 2 GPIO pins genoeg zijn. Mijn cyclone-I ontwerp had ongeveer aan 1 GPIO genoeg omdat ik met "discrete" (LSI dus) componenten de boel voor "bedrijf" omschakelde. Ik denk dat 2 GPIO pins genoeg moet zijn: je kan de datasignalen ook naar de config pins sturen, en met de GPIO pins dan de boel in en uit config mode halen. Maar goed. Dat is een hobby van me: field upgradable en "niet brickable" maken van zoiets.

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

Ik heb net gekeken naar Passive Serial mode configuratie op de Cyclone 10 LP. Helaas gaat het niet lukken. Ik heb dezelfde pinnen al in gebruik voor de Active Serial verbinding met mijn configuratie EEPROM. Als je de FPGA opnieuw wilt programmeren: JTAG. Wil je de config EEPROM opnieuw programmeren: JIC bestand maken.

Gelukkig zijn er tegenwoordig zat USB blasters te koop op Aliexpress, voor een paar euri ben je de gelukkige bezitter.

1 electron per seconde = 16 atto ampere!

Inmiddels ben ik bezig met de FPGA functionaliteit. Ik heb een testprintje gemaakt met 96 schakelaars, om elke ingang te kunnen schakelen. Ook zitten er 96 leds op, om de pattern generator functionaliteit te testen.

1 electron per seconde = 16 atto ampere!

Ik heb een bordje met een STM32F072 er op. Dit printje heeft 64 GPIO pins op connectors uitgevoerd. Als je wilt kan ik dat voor je programmeren dat ie daar wat testpatronen op aanbiedt.

Zelf zou ik eerst op 8 of 16 kanalen "activiteit" willen zien, voordat ik de "en werken de andere 80 kanalen ook?" vraag relevant wordt....

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

rew, dank je wel voor het aanbod, maar ik denk dat deze interim oplossing nu zal volstaan. Misschien dat ik in de toekomst een beroep kan doen op je hulp?

Met dit schema wil ik aangeven hoe mijn Logic Analyzer in elkaar steekt (en waarom ik 40000 logic cells nodig heb)

Met de rode pijlen is de hoofdcommunicatie weergegeven tussen de verschillende ontwerpmodules. De blauwe pijlen zijn configuratiepaden. De zwarte pijlen zijn secundaire datapaden. Groene pijlen stellen interfaces voor die buiten de FPGA gaan, naar de blauwe blokken.

De twee rode blokken zijn de inkomende en uitgaande mux, met 128 in-, en evenveel uitgangen. Blokken in het groen stellen modules voor waarbij de functionaliteit voornamelijk in RAM zitten. Gele blokken zijn voornamelijk RTL (Register Transfer Logic) blokken. Het witte blok is.. niks.

Het voor Sigrok bedoelde datapad zijn de rode pijlen vanaf de I/O poorten links naar de FT601 aan de rechterkant, via de ZBT SRAM (ook rechts). Via de ingangs MUX, gaat deze naar de streamer (doet helemaal niets) naar de packer. Deze is verantwoordelijk voor het opdelen van de 96 bits in 4 maal 24 bits. Samen met het preamble gaat deze naar de zbt SRAM fifo, waarna deze opgevraagd kan worden door de computer via de FT601 interface.

Echter, de Logic Analyzer heeft nog mer functionaliteit in hardware. Via de trigger engine kunnen bepaalde datapatronen (geheugen adres 0x28a8243c bijvoorbeeld) gebruikt worden om de datastroom te starten. Met de capture engine kan je bepaalde adressen monitoren, bijvoorbeeld als je een aantal foutwaardes in een bepaalde adressen wilt checken. De mapper engine gebruik je om een overzicht te krijgen waar ergens in het geheugenblok de processor zit te werken. Als je bepaalde tabellen in het geheugen hebt, en je wilt weten welke waardes de CPU gebruikt is dit handig.

Aan de ingangs MUX heb je ook een LUT blok, waar je elke logische functie in kan zetten wat je wilt. Bijvoorbeeld adres blok x, maar alleen vanaf ROM geheugen waarbij alle Byte enables hoog zijn. Dit soort functionaliteit kun je maken in de LUT. Je kunt dit blok gebruiken in combinatie met de andere ingangsmodules, omdat het allemaal op de MUX zit.

Data vanaf de computer kunnen we verdelen in twee hoofdcategorieën: Configuratie data en uitgangsdata. Door de unpacker worden deze van elkaar gescheiden. De uitgangsdata kan direct via de uitgangs MUX op de I/O worden gezet. Op de uitgangs MUX zit ook een counter, als je bijvoorbeeld een in circuit EEPROM programmer wilt maken, en je niet de adreslijnen wilt bit-bangen. Via een configuratiepakket kun je de counter waarde laden, waarna elke schrijfactie vanaf de fifo zorgt voor een increment op de counter. Uiteraard kun je de uitgang van de counter ook via de MUX op elke wilekeurige I/O lijn zetten.

1 electron per seconde = 16 atto ampere!

Zeer stoer project.

Toen ik de eerste post zag dacht ik in eerste instantie dat het kopen van een 30 jaar oude 2e (of 6e) hands Logic Analyser een optie kon zijn.

Ook dacht ik even aan de Cypress FX3. Veel sneller dan de FX2, en ontwikkel bordjes beginnen bij ongeveer EUR60.

Daarna blij verrast toen ik al verwijzingen naar Sigrok / Pulseview zag. Het lijkt me logisch om naar andere Open Source projecten te kijken voor communicatie protocollen met Sigrok. Als die goed doordacht zijn helpt dat een stuk bij het schrijven van software.

Wat ik van Kickstarter denk... dat weet ik niet goed, maar ik heb het vermoeden dat ik liever iets bij Crowdsupply zal kopen. Daar staan ook relatief veel open source projecten.
https://www.crowdsupply.com/
Zelfs als je alle design files, source code enz. op internet zet is een site als crowdsupply nog steeds interessant. Veel mensen hebben er geen zin in om zelf de BOM te verzamelen en BGA's te solderen, en kopen liever een bestukte print.

Met een BOM prijs van EUR150 zou een verkoop prijs van EUR400 haalbaar moeten zijn, en als ik dan kijk naar de specificaties dan ziet dit er uit als relatief nog best wel goedkoop, en haalbaar. Je kan er waarschijnlijk niet van leven, maar een paar keer extra op vakantie is ook leuk.

Zelf werk ik met een EUR7 FX2 & Sigrok en voel wel wat behoefte aan "betere" hardware, maar meer dan 16 kanalen heb ik zelf niet nodig omdat ik alleen werk met microcontrollers en wat externe bussen en data protocollen.

USB3 / Superspeed is nogal erg kritisch voor de layout heb ik begrepen. een paar mm lengte verschil, een extra via, oid kan de boel geloof ik al verruineren...