| *** tpb has joined #yosys | 00:00 | |
| *** mirage335 has quit IRC | 00:01 | |
| *** forrestv has quit IRC | 00:04 | |
| *** forrestv has joined #yosys | 00:13 | |
| *** Thorn has quit IRC | 00:15 | |
| *** sxpert has joined #yosys | 00:19 | |
| *** mirage335 has joined #yosys | 00:24 | |
| *** AlexDaniel has joined #yosys | 01:12 | |
| *** Cerpin has joined #yosys | 02:06 | |
| *** Cerpin has quit IRC | 02:14 | |
| *** Cerpin has joined #yosys | 02:23 | |
| *** Cerpin has quit IRC | 02:27 | |
| *** emeb has quit IRC | 02:56 | |
| *** rohitksingh has joined #yosys | 02:57 | |
| *** PyroPeter has quit IRC | 02:57 | |
| *** rohitksingh has quit IRC | 03:02 | |
| *** PyroPeter has joined #yosys | 03:11 | |
| *** citypw has joined #yosys | 03:20 | |
| *** analognoise has joined #yosys | 03:31 | |
| *** gsi__ has joined #yosys | 03:40 | |
| *** gsi_ has quit IRC | 03:43 | |
| *** analognoise has quit IRC | 03:46 | |
| *** rohitksingh_work has joined #yosys | 04:12 | |
| *** _whitelogger has quit IRC | 04:22 | |
| *** _whitelogger has joined #yosys | 04:24 | |
| *** analognoise has joined #yosys | 04:26 | |
| *** Thorn has joined #yosys | 05:07 | |
| *** kraiskil has joined #yosys | 05:59 | |
| *** m4ssi has joined #yosys | 06:07 | |
| *** Thorn has quit IRC | 06:33 | |
| *** kraiskil has quit IRC | 06:50 | |
| *** emeb_mac has quit IRC | 07:14 | |
| *** kraiskil has joined #yosys | 07:34 | |
| *** kraiskil has quit IRC | 08:17 | |
| *** Thorn has joined #yosys | 08:45 | |
| *** futarisIRCcloud has quit IRC | 09:17 | |
| *** kraiskil has joined #yosys | 09:19 | |
| *** kraiskil has quit IRC | 09:28 | |
| *** eightdot has quit IRC | 09:35 | |
| *** kraiskil has joined #yosys | 09:42 | |
| *** kraiskil has joined #yosys | 09:43 | |
| *** kraiskil has quit IRC | 09:51 | |
| *** citypw has quit IRC | 10:01 | |
| *** kraiskil has joined #yosys | 10:03 | |
| *** cr1901_modern has quit IRC | 11:43 | |
| *** analognoise has quit IRC | 11:47 | |
| *** cr1901_modern has joined #yosys | 12:02 | |
| *** togo has joined #yosys | 12:53 | |
| *** rohitksingh_work has quit IRC | 13:19 | |
| *** kraiskil has quit IRC | 13:34 | |
| *** kraiskil has joined #yosys | 13:47 | |
| *** rohitksingh has joined #yosys | 14:08 | |
| *** maikmerten has joined #yosys | 14:26 | |
| *** rohitksingh has quit IRC | 14:31 | |
| *** rohitksingh has joined #yosys | 14:34 | |
| *** kraiskil has quit IRC | 14:51 | |
| *** rohitksingh has quit IRC | 15:03 | |
| *** kraiskil has joined #yosys | 15:05 | |
| *** kraiskil has joined #yosys | 15:06 | |
| *** kraiskil has quit IRC | 15:29 | |
| *** gsi__ is now known as gsi_ | 16:01 | |
| mithro | daveshah: I recommend enabling the WIP bot on the YosysHQ organization -> https://probot.github.io/apps/wip/ -- it just prevents accidentally merging pull requests which have WIP in the title.... | 16:07 |
|---|---|---|
| tpb | Title: Work In Progress | Probot (at probot.github.io) | 16:07 |
| *** eightdot has joined #yosys | 16:29 | |
| *** m4ssi has quit IRC | 16:41 | |
| *** kraiskil has joined #yosys | 16:41 | |
| *** emeb_mac has joined #yosys | 16:43 | |
| *** cdleary has joined #yosys | 17:17 | |
| *** kraiskil has quit IRC | 17:26 | |
| *** kraiskil has joined #yosys | 17:27 | |
| *** cdleary has quit IRC | 17:33 | |
| *** rohitksingh has joined #yosys | 17:43 | |
| *** rohitksingh has quit IRC | 18:01 | |
| *** mjacob has quit IRC | 18:04 | |
| *** rohitksingh has joined #yosys | 18:12 | |
| *** dys has joined #yosys | 18:31 | |
| *** rohitksingh has quit IRC | 19:26 | |
| *** kraiskil has quit IRC | 19:50 | |
| *** maikmerten has quit IRC | 20:56 | |
| *** emeb has joined #yosys | 21:07 | |
| janrinze | ZipCPU: the 'old' code for SDcard worked 'out of the box' :-) | 21:28 |
| ZipCPU | janrinze ... was that your old code? | 21:29 |
| janrinze | ZipCPU: not particularly fast but plenty compatible. | 21:29 |
| ZipCPU | Software control, or HDL control? | 21:29 |
| janrinze | Oh, it's some bitbanging code in C that pretends to be a SPI port for the SDcard. | 21:29 |
| janrinze | Software control. | 21:30 |
| janrinze | Since that works well it should be possible to migrate that to HDL if i can find the time. | 21:30 |
| ZipCPU | Sure! But now, you don't need to find the time quite so fast | 21:31 |
| janrinze | ZipCPU: Now the flash bootloader works.. indeed. no need | 21:31 |
| janrinze | More time to check some nasty bug in my compiler :-) | 21:32 |
| ZipCPU | "nasty bug" ... sigh... I've never seen bugs quite so nasty as those in FPGA designs | 21:32 |
| janrinze | bumped into another one? | 21:33 |
| ZipCPU | Not today, no ... but thanks for asking ;) | 21:33 |
| ZipCPU | No, today's current task is to see if I can't verify erasing the flash faster if I put a CPU into the FPGA | 21:34 |
| ZipCPU | It was going to be using an accelerator, but programming the flash is just too slow so far | 21:34 |
| ZipCPU | ... and the reason why its too slow is my own fault. The debugging bus I put into this project just ... isn't industrial strength (yet) | 21:35 |
| janrinze | How slow is 'slow'? | 21:35 |
| ZipCPU | I haven't timed it, so about all I can say is slower than my level of patience | 21:36 |
| janrinze | :-D | 21:36 |
| ZipCPU | Watching the same value transfer across the bus over, and over, and over ... | 21:36 |
| ZipCPU | I know it can be much faster | 21:36 |
| janrinze | Do you have it in GIThub or is it not public? | 21:37 |
| ZipCPU | Nah, this one is quite public: https://github.com/ZipCPU/arrowzip | 21:37 |
| tpb | Title: GitHub - ZipCPU/arrowzip: A ZipCPU based demonstration of the MAX1000 FPGA board (at github.com) | 21:37 |
| ZipCPU | janrinze: If there's something particular you are looking for, let me know. Perhaps I could save you the search? | 21:40 |
| janrinze | dualflexpress.v is the one? | 21:46 |
| janrinze | Was looking into that. | 21:46 |
| ZipCPU | That's the Verilog version of the flash controller, yes | 21:46 |
| ZipCPU | The C++ half of it is found in sw/host/flashdrvr.cpp | 21:47 |
| janrinze | Then i got that right :-) | 21:47 |
| ZipCPU | dualflexpress isn't really the problem. That's not the slow part. | 21:47 |
| ZipCPU | The slow part is sending data over the serial port interface. Once to determine if it needs to be erased, once to verify the erase, once to check if a page needs to be programmed, once again to program the page ... it's a lot of work on a serial port | 21:48 |
| janrinze | Okay, what baud rate? | 21:48 |
| ZipCPU | 1MBaud | 21:48 |
| ZipCPU | although the data's being sent in (cough) hex. So, only 4-bits of useful data per byte | 21:49 |
| janrinze | I see.. that's a tad over 60 KB /sec max | 21:49 |
| janrinze | Assuming the hex coding. | 21:50 |
| ZipCPU | It gets worse. It takes me roughly 11 characters to send 32-bits of data, counting the carriage return and newline | 21:50 |
| janrinze | so about 30% actual data. | 21:51 |
| ZipCPU | Yeah, about that | 21:51 |
| ZipCPU | And ... the data gets sent about 4 times at that 30% rate | 21:51 |
| janrinze | still it would only be 3 times faster if you could eliminate that at 1Mb/s | 21:51 |
| ZipCPU | While it's not optimum, it is low logic ... | 21:52 |
| ZipCPU | Yes, that would be faster, and yes I have a project to do that, it's .... not getting much attention these days. ;) | 21:52 |
| janrinze | Have you tried FTDI parallel to USB? that can do about 20 MB/s (assuming USB2) | 21:53 |
| ZipCPU | I've also got another routine that gets a much better compression rate, skipping newlines and carriage returns, using a codebook to repeat things, it just doesn't fit in these small devices | 21:54 |
| ZipCPU | No. I haven't tried any of the faster FTDI modes | 21:54 |
| ZipCPU | There's a fast serial mode that I'd love to try to--should get up to nearly 50Mbps IIRC | 21:54 |
| ZipCPU | (You mean 20Mb/s, right? or 20MB/s?) | 21:54 |
| janrinze | USB2 should be capable of 480Mb/s (bits) | 21:55 |
| ZipCPU | Ahm, no. | 21:55 |
| ZipCPU | I think your best rate is 12Mb/s over USB | 21:55 |
| janrinze | That's USB 1.1 right? | 21:55 |
| janrinze | USB 3 does 5Gb/s | 21:55 |
| ZipCPU | There is a 480Mb/s speed, but I think it requires USB3 | 21:55 |
| ZipCPU | It's also out of reach of most FPGAs | 21:56 |
| daveshah | USB2 HS is 480Mb/s | 21:56 |
| daveshah | It's a bit of a pain for FPGAs because of clock recovery, and it's mixed single ended and diff signalling | 21:56 |
| ZipCPU | daveshah: I didn't think that was until USB 3 ... did I miss that? | 21:56 |
| daveshah | USB3 is 5Gbps | 21:57 |
| ZipCPU | Nvm then | 21:57 |
| daveshah | Many USB2 devices only support the 12Mbps mode | 21:57 |
| ZipCPU | You think the FTDI controller would handle 480Mbps? FT2232H? | 21:57 |
| daveshah | It's "high speed" devices that add 480Mbps support | 21:57 |
| daveshah | Yes, the H is for high speed :) | 21:57 |
| ZipCPU | Ok ... | 21:58 |
| janrinze | daveshah: using a FTDI chip for USB to parallel can relieve the bit speed at the FPGA side, right? | 21:58 |
| daveshah | I think it's only sync fifo mode that gets close to that | 21:58 |
| daveshah | janrinze: yes | 21:58 |
| daveshah | There's even a FTDI USB3 to parallel | 21:58 |
| janrinze | I never tried the FTDI parallel printer interface in my bottom drawer.. should be bi-directional, right? | 21:59 |
| daveshah | Yes | 21:59 |
| daveshah | I think a lot of the FTDI parallel printer chips are 12Mbps only though | 22:00 |
| janrinze | probably, they are quite cheap. | 22:00 |
| janrinze | Still, 12 times faster than the 1Mbps he has now :-D | 22:01 |
| ZipCPU | Let's see ... 1Mbps * 30% * 1/4 ~= 75 kbps, or 9kB/s | 22:03 |
| ZipCPU | I might get the biggest bang for my buck by switching from this hexadecimal encoding to something smarter | 22:04 |
| emeb | seems like it'd be good to just send the data once, queue it in a flash-page sized RAM in the FPGA and then let local logic do the compare/erase/program/verify without resending. | 22:04 |
| ZipCPU | emeb: That's actually the approach I'm pursuing now. | 22:05 |
| emeb | ZipCPU: validation! :) | 22:06 |
| ZipCPU | I'll feel better about it once it works ... | 22:06 |
| emeb | lots of opportunity for formal! | 22:07 |
| ZipCPU | Ok, I misunderstood you .... I'm using the CPU instead of the logic to do this | 22:08 |
| ZipCPU | Not nearly as many opportunities for formal as a result | 22:08 |
| emeb | ZipCPU: no, understood me - I didn't specify cpu or logic. I'd guess a fully dedicated logic implementation would be a lot more hassle than just throwing a CPU at it. | 22:09 |
| ZipCPU | Ok, I'll agree with that | 22:09 |
| emeb | Especially if you just happen to have a CPU laying around - as you do. | 22:09 |
| ZipCPU | :D | 22:09 |
| emeb | Had the opposite situation yesterday - was doing a PS/2 keyboard receiver. Had to choose between doing the scan-code to ASCII conversion in software or in verilog. | 22:10 |
| janrinze | ZipCPU: no USB device for the CPU yet, right? | 22:11 |
| emeb | Verilog turned out to be pretty easy and used less resources! | 22:11 |
| ZipCPU | janrinze: You mean like tinyfpga has been using? | 22:11 |
| emeb | (vs using up psedo ROM in the CPU address space) | 22:11 |
| ZipCPU | Got to run here .... suppertime | 22:12 |
| emeb | <insert Snoopy cartoon> | 22:12 |
| janrinze | ZipCPU: if there is no USB hw and you need to add it in Verilog, there are a few implementations but i found them quite complicated. | 22:13 |
| emeb | USB PHY is not a simple thing | 22:13 |
| emeb | you can tell it was designed by committee | 22:13 |
| cr1901_modern | daveshah: >and it's mixed single ended and diff signalling | 22:29 |
| cr1901_modern | IME, in a pure FPGA impl, you treat both signals as single-ended all the time, and if you see a SE1, then something really really bad happened :). | 22:29 |
| daveshah | I don't think that works for HS | 22:30 |
| cr1901_modern | well HS doesn't even have the proper voltages to interface to FPGA | 22:30 |
| daveshah | Maybe with a very short cable, not sure what the levels are | 22:30 |
| cr1901_modern | 1.2V something | 22:30 |
| cr1901_modern | daveshah: Actually idk the voltage offhand either | 22:31 |
| cr1901_modern | But it isn't 3.3 | 22:31 |
| daveshah | 1.2V is fine for FPGAs | 22:31 |
| cr1901_modern | +/-400mV | 22:31 |
| cr1901_modern | sorry | 22:31 |
| cr1901_modern | Also while they are on my mind: Is it possible/feasible to break up the compilation of the nextpnr and icetime databases into smaller granularity units as a build option? This would enable me to recompile nextpnr/icetime more easily on ARM systems w/ < 4GB RAM | 22:33 |
| cr1901_modern | tnt gave a partial solution for icetime, but up5k icetime db still exceeds 2GB of RAM and brings my pinebook to its knees | 22:34 |
| cr1901_modern | nextpnr takes 4 hours to compile | 22:34 |
| cr1901_modern | (going to swap on a USB stick) | 22:34 |
| daveshah | icetime might be splittable further into functions | 22:34 |
| daveshah | Not so sure about nextpnr | 22:35 |
| daveshah | If it's creating the bbas that is slow then prebuilding is the solution | 22:35 |
| cr1901_modern | Then shouldn't there be daily blobs for that? | 22:36 |
| daveshah | The bbas are truly arch independent, the cc/bin only depend on endianness | 22:36 |
| daveshah | Yes, but no one has got round to setting up the infra for that | 22:36 |
| cr1901_modern | daveshah: Don't remember which step is the one that takes up all that time | 22:36 |
| cr1901_modern | I _think_ it was the bba generation | 22:36 |
| daveshah | https://github.com/YosysHQ/nextpnr-chipdb | 22:36 |
| tpb | Title: GitHub - YosysHQ/nextpnr-chipdb: ChipDB builder for NextPnR project (at github.com) | 22:36 |
| cr1901_modern | what's that repo? | 22:37 |
| cr1901_modern | was the chipdb stuff moved out? | 22:38 |
| daveshah | No, but it's another option | 22:38 |
| daveshah | You can use this repo to build a bin chipdb that is then passed to nextpnr | 22:38 |
| daveshah | Instead of building the bba during the main build process | 22:38 |
| cr1901_modern | The chipdbs are large, correct? | 22:39 |
| cr1901_modern | i.e. hundreds of megs | 22:39 |
| cr1901_modern | large == "github would get pissed if they were hosted as blobs in a repo" | 22:39 |
| daveshah | Yes | 22:41 |
| daveshah | They compress quite nicely though | 22:41 |
| daveshah | IIRC about 10-20MB xz for all ice40 chipdbs | 22:42 |
| cr1901_modern | If that's true, then I know a workaround to host the blobs in nextpnr-chipdb every time a travis build occurs | 22:42 |
| cr1901_modern | so you don't need to add a tag to each commit | 22:43 |
| cr1901_modern | you can create a separate branch with just the tarballs/zip files that's automatically updated each commit :P | 22:45 |
| daveshah | If you want to be fancy, only commits touching certain files (bbasm, the Python script that creates the bbas, and constids.inc) need a new db | 22:49 |
| emeb | cr1901_modern: hmm... I just built icestorm/yosys/nextpnr on a 2GB EEE laptop. It took a few hours, but it all fit. | 22:56 |
| emeb | OTOH It has an SSD and 2GB swap | 22:56 |
| emeb | how do ppl get the toolchain installed on an RPi Zero? Are there precompiled versions? | 22:58 |
| *** mjacob has joined #yosys | 23:15 | |
| *** futarisIRCcloud has joined #yosys | 23:37 | |
| cr1901_modern | emeb: Sure it still can be done. I just don't want it to go to swap | 23:47 |
| cr1901_modern | even on -j1 it goes to swap. Contrast to last year, the last time I built arachne-pnr and icetime, I could compile on 1GB RAM and a bit of swap | 23:48 |
| cr1901_modern | (without swap making the machine unusable) | 23:48 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!