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.
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.
precies mijn gedachte: Eerst maar eens iets werkend krijgen, daarna kunnen we gaan voor optimalisatie.
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.
Jep! Dat heeft ie al gezegd dat ie dat van plan is.
Ik geloof dat daar die grote switch matrix van gekomen was.
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?
Ik denk inderdaad dat dit op Kickstarter een goede kans maakt, maar dan moet je daar wel zin in hebben natuurlijk.
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.
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.
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?
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.
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.
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.
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....
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.
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...
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.
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 zaterdag 7 december 2019 10:58:44 (65%)
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.
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?
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:
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?
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
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.