Logic Analyzer zelf maken

Op 5 maart 2020 17:08:13 schreef rew:
Ze noemen het soms "hardened", dat zou hinten naar het: softcore-ARM en dan gewoon alle config bits vastzetten en de optimizer draaien. Maar ik verwacht niet dat ze hier zo simpel te werk zijn gegaan. Gewoon een ARM ontwerp kopen en pleur-maar-neer.

Als je "goedkoop" wil experimenteren met dat spul moet je de DE0-Nano-SoC Kit/Atlas-SoC hebben. Ongeveer 100 euro voor een development bordje waar een chip op zit die al niet-of-nauwelijks goedkoper dan die 100 euro te krijgen is.

Edit: effe 'n linkje

Brilliant gebruik van een sodimm slot, had ik nog niet eerder gezien. Nu nog een toepassing vinden

Op 5 maart 2020 18:23:52 schreef Titatommeke:
[...] Nog een speciale reden waarom je met Altera werkt? of was dat gewoon kosten?

Inderdaad, kosten. Mijn keuze voor Altera stamt uit een tijd dat ik een beperkter hobby-budget had, en een USB blaster programmer kon ik zelf maken, programmers voor andere merken moest ik kopen. En ik heb een voorliefde voor dingen zelf maken, in plaats van het voorgekauwd krijgen. Daar leer je stukken minder van.

Ik kan dan ook iedereen aanbevelen om dingen zelf te maken. Op allerlei vlakken en niveaus. Maak je eigen PCB, maak je eigen ontwerp in je CPLD of FPGA, maak je eigen programma, embedded of desktop. Maak je eigen knipperend ledje, radio, meetapparaat of computercluster. Maar vooral: Maak je eigen fouten, en probeer ze zelf op te lossen. Ik word gek van mensen die van hun problemen, jouw problemen proberen te maken. Probeer eens iets zelf, en vertrouw niet te veel op andere mensen en het werk wat ze hebben gedaan. Dat is niet persé altijd goed namelijk. Ik beloof je dat je er niet stommer van zult worden.

[Bericht gewijzigd door Dweil op donderdag 5 maart 2020 19:45:38 (38%)

Update: Ik ben een GUI aan het maken voor het CoLA project.

Op en of aanmerkingen zijn welkom, want ik ben geen held in het desktop applicatie programmeren.

Ook: Ik heb een PCB van mijn CoLA prototype over. Het gaat hier om alleen de printplaat, zonder componenten. Hebben? Stuur me een berichtje. Bij de PCB krijg je uiteraard alle technische gegevens. De Cyclone 10LP wat erop hoort heeft veel I/O via level converters (1.65V - 5V), USB3 interface (FT601A) en plaats voor een ZBT SRAM (Dat werkt tot 100MHz). Vertel me waarom je deze wilt hebben en tegen verzendkosten stuur ik het naar een adres van jouw keuze.

Ter herinnering: het gaat over deze PCB:

Ik dacht dat je de gui van sigrok zou gebruiken als basis. Of is dat nog steeds de bedoeling?

Dit is de bedoeling, uiteindelijk. Het struikelblok is de driver van FTDI. Deze is closed source en dus niet compatible met de GPL licentie van Sigrok. Behulpzame mensen op het Sigrok IRC kanaal wezen op een mogelijkheid van een FTDI - Socket vertaling, wat vervolgens wel aan de Sigrok licentie zou kunnen voldoen, of (en dit is een long shot) wachten op een open source driver voor de FT60X serie. Tot die tijd dus een eigen capture tool. Let wel: Deze tool spuugt bestanden uit die voldoen aan het Sigrok formaat. Gewoon direct in Pulseview in te lezen dus.

Slim dat je eenzelfde formaat gebruikt voor je software. Geeft mij altijd een dubbel gevoel dat soort licentie issues. Heel nobel aan de ene kant en in de ideale wereld zouden bedrijven zoals ftdi gewoon een opensource driver moeten leveren, maar het kost zoveel moeite om er omheen te knutselen. Wat eigenlijk de oplossing die ze op het irc kanaal geven ook is, knutselen om de licentie heen. Ik ben niet goed in het bedenken van gui's dus kan weinig feedback geven op het user experience gedeelte.

[Bericht gewijzigd door Titatommeke op maandag 16 maart 2020 16:18:32 (12%)

Je moet de GPL eens zelf lezen, en niet 100% vertrouwen op de interpretatie van bepaalde "fanaten".

De GPL is geschreven met de gedachte dat als jij een gaaf gpl programma ziet, en daar dan een kleinbeetje bijprutst en dat zou willen gaan verkopen, dat /dat/ niet mag. Dwz. dat mag wel, maar dan moet je de source er bij leveren en iedereen die het koopt mag dan zomaar de source op het internet zetten. daar kan je dan niets aan doen. (maar JIJ HOEFT je source niet vrij te geven aan jan en alleman. Alleen aan de mensen wie je je programma verkoopt (of weggeeft)). Gewoon alles op het internet zetten is een makkelijke oplossing voor: "Als iemand die je ding gekocht heeft MOET je aan hem de source ook beschikbaar maken". Maar gewoon "op eerste verzoek een mailtje sturen" is ook prima.

Maar goed. Een andere interpretatie kwestie is: mag je linken met een closed-source library. Linus heeft een zinnige interpretatie: Als je gewoon de publieke API gebruikt en dynamisch linkt dan is het OK. Dan is het beschikbaar maken van de combinatie niet een vorm van "afgeleid werk". (want, om maar wat te noemen, je levert niet zomaar die closed source FTDI library mee, maar zegt: download hem zelf maar!). En dat maakt het HELEMAAL ok: Jij mag gerust in jou kantoortje werken aan een combinatie van een GPL ding en "eigen geheime code". Alleen als je het wilt delen met anderen gaat de GPL dingen zeggen over het beschikbaar zijn van de code. Dat is effectief ook wat iedereen die sigrok-met-jou-code gebruikt met de zelf-gedownloade-FTDI-library: ZELF een combinatie maken tussen wat proprietary code en wat GPL spullen.

De GPL puristen willen dit ontmoedigen, ze denken hiermee FTDI onder druk te zetten om hun code te publiceren. Dat heeft al 20 jaar geen effect gehad, dus zal echt niet morgen ineens effect gaan sorteren.

Ik heb ooit GPLV2 goed gelezen. GPLV3 ben ik snel afgehaakt, dus mogelijk is daar door de puristen eea "verduidelijkt" dat ik geen gelijk meer heb. Ik zag toen ik GPLV3 ging lezen snel genoeg dingen waar ik het niet mee eens was dat ik als de sodemieter alle "or any higher version" uit m'n code ben gaan halen.

Ik heb geen ervaring met dit soort licentie-kwesties, noch heb ik de motivatie om de GPL tot de letter door te lezen. In plaats daarvan heb ik contact gehad met Uwe Hermann, een van de lead software ontwikkelaars voor Sigrok.

Zijn letterlijke woorden, en ik citeer, waren: "...you cannot use any closed-source code or code that's not compatible with the libsigrok license (GPL, version 3 or later)..."

Dit was de reden tot het maken van een externe tool. Een externe tool heeft voor mij een ander voordeel: Ik kan meer mogelijkheden inbouwen dan de Sigrok UI biedt. Ik heb de Sigrok interface voor het aansturen van Logic Analyzers bekeken, maar deze is zeer beperkt.

Voorbeeld: De keuze voor sample rate bestaat uit een drop-down menu waaruit je een aantal waardes kunt kiezen. De CoLA mogelijkheden voor de sample rate zijn echter continue variabel, in 0.01Hz stappen. In de praktijk denk ik dat het gebrek van een volledige Sigrok integratie niet zo'n probleem gaat vormen.

UPDATE:

De gehele firmware van de Cola2 herzien. Dit was nodig omdat ik begonnen was aan de firmware zonder te weten waar de knelpunten zaten. Nu ik dat wél weet, kan ik de VHDL code gerichter schrijven en optimaliseren. Dit is een blok schematische weergave van de firmware:

Er is flink wat veranderd. De packer/RLE compressor engine werkt nu op 200MHz, waar deze eerst synchroon met de FT601 interface werkte (100MHz). Dit is gedaan om sample rates van boven de 100MHz toe te staan. Omdat dit de theoretische bandbreedte van de USB3.0 chip overstijgt, zitten er een aantal gotcha's aan verbonden. De uiteindelijke gemiddelde bandbreedte mag niet boven de 100MHz komen, dus het RLE compressie gedeelte moet er voor zorgen dat de data gecomprimeerd word. Dat betekend dus niet te veel verandering aan de input samples.

Grote verandering nummer 2: Ik werk nu met een sample rate opgewekt door een Fractional PLL. Dit houdt in dat deze continue variabel kan zijn tussen de (zeg) 500Hz en de 100MHz, mogelijk daarboven zelfs. De PLL wekt een frequentie op van 50-100MHz, en een 32 bit klokdeler converteert deze naar een mogelijk nog lagere sample rate.

Door al deze verschillende frequenties moeten er dual clock FIFO registers tussen al deze blokken komen. Op zich geen probleem, maar de latency van de DCFIFO is 1 meer dan de SCFIFO. De RLE compressor en de FT601 interface moest hierop aangepast worden. De Packer heeft nu een "spinup" fase waarin er een READ signaal naar de sample FIFO gestuurd is, maar de data nog niet beschikbaar is. Dit heeft consequenties voor de mate waarin de samples uitgelezen kunnen worden. Ik noem dit even de "Ingress Ratio".

Bij de 96bit/25MHz ("single") mode, gebruik ik 4 32-bit woorden op de USB interface voor 1 sample. Op het moment dat een sample beschikbaar is, gaat de State Machine in de Packer/Compressor van:

- Idle -> Spinup -> Pack3 -> Pack2 -> Pack1 -> Pack0 -> Idle...

Als er nog meer samples beschikbaar zijn, kan ik dit detecteren in de Pack1 fase, waardoor de spinup fase van de volgende sample eigenlijk de Pack0 is van de hudige sample. Van Pack0 kan ik dan gaan naar:

- Pack0 -> Pack3 -> Pack2 -> Pack1 -> Pack0...

Echter, als ik pas in de Pack0 fase een nieuwe sample heb, kan ik dus vanuit pack0 naar Spinup (ipv Pack3). Ik moet immers wachten totdat de nieuwe sample op mijn datalijnen staat:

- Pack0 -> Spinup -> Pack3 -> Pack2 -> Pack1 -> Pack0...

De Pack3 fase is interessant, want het hangt af van de vorige sample wat ik hier ga decoderen. Als bit 95-48 hetzelfde is als de vorige sample, hoef ik deze niet de coderen naar de USB interface.

- Pack3 -> Pack0...

Als daarbij bit 47-24 ook hetzelfde is, kan ik nog meer weglaten. Normaliter MOET ik bit 23-0 coderen, om een sample aan te geven, maar door de RLE compressie hoef ik zelfs dit niet te doen: In plaats daarvan verhoog ik gewoon de RLE counter (tenzij deze op 127 staan, dan MOET ik dus wel een USB data woord versturen). Ik kán dus van Pack3 terug naar Spinup. Het is zo dat ik de Packer/Compressor engine meteen weer vrij heb voor een volgend sample, maar ik moet wachten op de 1 clock latency van mijn FIFO. Vanaf Pack3 kan ik dus niet direct naar een volgende Pack3 sample, maar ik ben verplicht naar de Spinup fase te gaan:

- Pack3 -> Spinup -> Pack3...

Door al deze State Machine Hocus Pocus heb ik dus een Ingress Ratio van 25% minimaal tot 50% maximaal. Dit houdt in dat ik een theoretisch maximale sample rate heb van 25MHz tot 50MHz. Door middel van RLE echter kan dit nog hoger worden, afhankelijk of ge ingangs bitpatroon gunstig is.

In de 48bit/50MHz zit ik op een een Ingress Ratio van Fixed 50%. Dit komt omdat ik maximaal 2 USB words nodig heb om 1 sample te beschijven. Dit kan ook niet hoger worden omdat ik ook 1 clockpuls moet wachten op een volgend sample (FIFO's...) Altijd 50% dus.

Voor 24bit/100MHz heb ik 1 32-bit USB word nodig per sample. Echter, door de spinup-fase van mijn compressor kan het zijn dat ik een klokpuls moet wachten. Een Ingress Ratio van 50-100% dus.

Nóg een belangrijke verandering in de firmware: Ik heb nu een embedded MCU. Ik heb gekozen voor de NEO430, een softcore MSP430-code compatible MCU. Op deze manier heb ik een degelijke C-compiler beschikbaar, en is alles lekker open source. I like it! De NEO430 core werkt op 50MHz, omdat de &^%$&^#& (Insert PC correct wording here) PLL reconfigurator voor de Fractional PLL aan te sturen niet erg veel harder gaat. Dit wonder van IP technologie is van Intel (Altera) zelf. Ik heb gekeken hoe deze core werkt, om het misschien wat sneller te coderen:

Ja weet je wat? Laat ook maar. Ik ben tevreden met de 50MHz.

Alle communicatie van en naar de NEO430 gaat over een Wishbone interface. Deze open-source address en data bus is lekker simpel te implementeren, en al gauw had ik dan ook interfaces geschreven voor configuratie van de ingangs- en uitgangs 128x128 MUX, GPIO voor de LED aan te sturen, Packer/Compressor mode in te stellen, USB communicatie en alle 96 bits aan ingang en uitgang direct aan te spreken.

Via de USB interface kan ik een nieuw programma in de Logic Analyzer flashen, woordoor ik een digital pattern generator kan maken, of een Eprom programmer of... De mogelijkheden zijn eindeloos. (tot 48KB code/ 12KB RAM).

Over optimalisatie gesproken. Ik heb het deel dat werkt op 200MHz binnen in de FPGA zo klein mogelijk gehouden. Op die manier heb ik de grootste kans dit juist gecompiled wordt. Ook heb ik in de instellingen van Quartus gegraven, en ik ben achter een belangrijke optimalisatie instelling gestuit:

Optimize for SSN. SSN staat voor Simultaneous Switching Noise, en dat is signaal integriteits vermindering als gevolg dat heel veel transistors in je ontwerp tegelijkertijd moeten schakelen. De voeding heeft op dat moment niet genoeg capaciteit om dit betrouwbaar te doen. Optimize for SSN zorgt er (denk ik) voor dat kritieke delen van je ontwerp verdeeld worden over meerdere VCCINT pinnen van je FPGA, en dus ook over meerdere ontkoppel- en bulk capaciteiten op je print. Het gevolg hiervan is een veel betere stabiliteit van je ontwerp. Pro tip dus!

Als laatste grote wijziging is de Trigger Engine. Eerdere opmerking van Rew was dat een pre-trigger capture van een paar (honderd?) samples eigenlijk niet toereikend is. Zo veel data opslag heb ik niet in mijn FPGA!

De oplossing is dan ook: Ik laat de FPGA alleen de trigger DETECTIE doen, en de computer de opslag. De Trigger engine geeft een signaal op het moment dat een trigger event is gedetecteerd, en de Packer/Compressor zorgt er voor dat deze in de datastroom naar de computer toe wordt verwerkt. Op die manier kun je een 2 seconde capture doen, met een half uur aan pre-trigger. Zorg gewoon dat je Terabytes aan SSD opslag beschikbaar hebt. Ik kan triggeren op:

- Hoog signaalniveau (1)
- Laag signaalniveau (0)
- Opgaande flank
- Neergaande flank
- Op- of neergaande flank (Either)
- Don't care (geen trigger)

Dit voor elk van de 96 bits te selecteren. Erg geavanceerde trigger opties zijn er dus vooralsnog niet, maar je kunt er toch wel wát mee.

Een stuk "ingewikkeldere" trigger kan je eenvoudig maken;

INPUT & MASK1 == VALUE1 -> trigger1
INPUT | MASK2 == VALUE2 -> trigger2

Meestal doe je dan trigger1 & trigger2 -> trigger.

Nu kan je combinaties triggeren. Hmm. Wacht! Als jij een "AND" doet tussen alle bit-triggers dan heb je dat al. Sorry.

Sterker nog: Je kunt elk van de 96 triggers combineren tot een uiteindelijk trigger signaal middels een "AND" en "OR" functie. Zodoende kun je dus op een bepaald bitpatroon triggeren, of signaal 45=hoog of 73=laag of enige activiteit op 32 of... Je snapt me.

Een kleine update over mijn 10G-E project:

Het huidige ontwerp van mijn 10G Ethernet heeft geen toekomst. Althans, niet voor mij. Alhoewel de gebruikte 10G MAC en XAUI PHY IP van Altera/Intel voor onbeperkte tijd gebruikt kan worden, is het nog altijd beperkt. In de mate dat je het kunt gebruiken in je FPGA ZOLANG DE JTAG ADAPTER EROP ZIT. Dit betekend dat je de FPGA image niet in een flash kan zetten, en op kan starten buiten een ontwikkelomgeving. Heel slim van Altera, want dit betekend dat je kunt experimenteren met deze technologie zonder dat je IP hoeft te kopen, maar wil je daadwerkelijk een product wilt maken hiermee, moet je veel geld neertellen.

De 10G MAC en XAUI PHY zijn (denk ik) niet los te koop, maar zitten in de koop versie van Altera Prime. Deze is een niet-zo-comfortabele €2500. Ik snap dat dit geld kost, maar ik ga waarschijnlijk te weinig gebruik maken van de extra mogelijkheden van Prime boven de gratis Lite versie, dat dit me toch het geld niet waard is. De truc is dus om een 10G ethernet ontwerp te maken zonder de IP van Altera, of welk andere IP core dan ook. Of het moet gratis zijn, dan wil ik dat wel overwegen.

Na wat zoeken ben ik gekomen uit de Microsemi (Microchip) VSC8486.
Afgaande op de naam, denk ik dat dit ontwerp afkomstig is van Vitesse Semiconductor Coorporation. Dit is een SERDES waarbij je van een 10G protocol kunt gaan naar XAUI of XGMII. XAUI, zo hebben we al eerder gezien, gaat veel geld kosten aan de FPGA kant, maar XGMII is in weze gewoon een 64 bit parallel bus. Ik ga die 10(X) Gig Media Independent Interface gebruiken voor mijn nieuwe Logic Analyzer.

64 bit, plus 8 controle lijnen maakt 72 bit, unidirectioneel. Ik zou dus 144 lijnen nodig hebben naar mijn Ethernet chip. Om dit wat te beperken maakt deze XGMII bus gebruik van DDR, data dus op zowel de opgaande als de neergaande flank. In plaats van 144 heb ik dus nu nog maar 72 lijnen. Dat scheelt nogal! Ook, omdat het 72 lijnen op 156.25MHz is, maakt de VSC8486 gebruik van de HSTL standaard. Op deze manier is de signaalintegriteit op deze bus nog wel te doen.

Bijkomend voordeel is dat mijn FPGA geen gigabit transceivers meer hoeft te hebben. Dit scheelt nogal in prijs, maar heeft als nadeel dat ik meer aandacht moet gaan schenken aan ontkoppeling op de voedingen. Tientallen I/O lijnen moeten tegelijkertijd gaan schakelen, en dit heeft veel SSN tot gevolg.

De opstelling waarmee ik dit ga testen was vooralsnog mijn point-to-point verbinding naar een 10Gbase-T netwerkkaartje (Asus XG-C100C 10Gbase-T NIC) maar ik heb besloten dat mijn netwerk infrastructuur wel een update kan gebruiken. Deze apparatuur is echter niet goedkoop!

Als kleine switch bij mijn werkstation heb ik gekozen voor een Mikrotik CRS305. Dit is een 5 poort managed switch met 1 GBE-POE poort en 4 SFP+ poorten. SFP+ poorten waren tot een tijdje geleden de standaard voor 10G Ethernet aansluitingen. Ik heb dan ook een SFP+ poort op mijn Logic Analyzer gezet, omdat de 10Gbase-T gewoon heel duur is. Via een media converter van SFP+ naar 10Gbase-T kun je dan direct naar de netwerkkaart via een CAT6A of CAT7 kabeltje. Zo'n converter is echter wel prijzig, reken op 70-80 euro.

Als je geen grote lengtes hoeft te overbruggen zijn er echter goedkopere oplossingen. Glasvezel SFP+ modules zijn verassend betaalbaar, ik heb ze gebruikt al voor 15 euro gezien, maar glasvezel is best kwetsbaar. Een DAC kabel (Direct Attach Copper) is eigenlijk twee SFP+ connectors aan een Twinax kabel verbonden. Ongeveer 40-50 euro voor zo'n kabel is te doen, maar je moet ze kopen in de lengte waarin je ze gaat gebruiken.

Nu ben ik misschien een ietsiepietsie overboard gegaan met mijn zoektocht voor 10 gigabit Ethernet, want inmiddels heb ik 20 CAT7 kabels, 7 SFP+ naar 10Gbase-T converters, 3 DAC kabels, en behalve de CRS 305 heb ik ook nog een CRS309 8 poort SFP+ switch naar mijn NAS en mediacenter toe. In deze computers heb ik HP NC520 dual port SFP+ kaartjes gestopt, goedkoop tweedehands op de kop getikt voor 50 euro per stuk. De tweedehands serverboeren hebben dit soort kaartjes regelmatig in de aanbieding.

Nu nog wachten totdat ik het geld heb voor een grotere Mikrotik CRS312 switch, en alles is verbonden met 10Gbit lijnen Hoera?

Door omstandigheden heb ik nu meer tijd voor mijn hobby als anders, en dus druk bezig met de 2e revisie van mijn 10GE project. Vandaag de PCB af gemaakt. Nog steeds een 8 laags PCB, en nog steeds 160x120mm, maar de extra features zijn nu:

- Uitsparing voor een ventilator
- Uitsparingen zodat de Mini Displayport connectoren daarwerkelijk op de PCB passen. Dit was een tekortkoming van de vorige versie waardoor ik vroegtijdig wist dat er nog een volgende aan zat te komen.
- SERDES is nu een VSC8486-04
- Configuratieflash nu wel aangesloten. Dit was fout gegaan in de Rev 1, maar bleek toch nutteloos dankzij de beperking van de gebruikte IP.
- Extra user I/O met 2 Leds en schakelaar. Dit is iets wat bij mijn ontwerpen wel een terugkerende trend is: Mijn designs hebben opvallend weinig user I/O. De Logic Analyzer met de USB3.0 verbinding heeft 1 LED. Één.

Voor de rest: De VSC8486 loopt op 1.2V, maar in de datasheet staat dat dit van een lineare regelaar moet komen. Ik heb gezocht naar spanningsregelaars met een redelijke stroom op 1.2V. Uiteindelijk gekomen op de NCV565, voor 1.2A. Ik verwacht dat met een 2.5V ingang deze toch aardig warm kan worden. Vandaar, tezamen met alle andere energie verstokers, een ventilator. Deze aan een PWM regeling gezet, en een I2C temperatuursensor op de PCB moet er voor zorgen dat de temperatuur OK blijft.

Omdat de SERDES interface op de HSTL 1.5V standaard loopt, en alle LVDS op 2.5V, neemt dit alle I/O banken van mijn FPGA in beslag. Dit houdt in dat alle andere in- en uitgangen via een level shifter op de correcte I/O standaard moet worden gebracht. Ik heb 3.3V conversie met een TXS0108 gedaan, deze is bidirectioneel en de I2C en MDIO bus kunnen hierover communiceren. Ik heb 3.3V I/O nodig omdat de SFP+ module deze standaard hanteert.

Om een betere voorstelling te krijgen hoe het geheel dadelijk in de behuizing past: