Tuesday, 2019-04-02

*** tpb has joined #yosys00:00
*** mirage335 has quit IRC00:01
*** forrestv has quit IRC00:04
*** forrestv has joined #yosys00:13
*** Thorn has quit IRC00:15
*** sxpert has joined #yosys00:19
*** mirage335 has joined #yosys00:24
*** AlexDaniel has joined #yosys01:12
*** Cerpin has joined #yosys02:06
*** Cerpin has quit IRC02:14
*** Cerpin has joined #yosys02:23
*** Cerpin has quit IRC02:27
*** emeb has quit IRC02:56
*** rohitksingh has joined #yosys02:57
*** PyroPeter has quit IRC02:57
*** rohitksingh has quit IRC03:02
*** PyroPeter has joined #yosys03:11
*** citypw has joined #yosys03:20
*** analognoise has joined #yosys03:31
*** gsi__ has joined #yosys03:40
*** gsi_ has quit IRC03:43
*** analognoise has quit IRC03:46
*** rohitksingh_work has joined #yosys04:12
*** _whitelogger has quit IRC04:22
*** _whitelogger has joined #yosys04:24
*** analognoise has joined #yosys04:26
*** Thorn has joined #yosys05:07
*** kraiskil has joined #yosys05:59
*** m4ssi has joined #yosys06:07
*** Thorn has quit IRC06:33
*** kraiskil has quit IRC06:50
*** emeb_mac has quit IRC07:14
*** kraiskil has joined #yosys07:34
*** kraiskil has quit IRC08:17
*** Thorn has joined #yosys08:45
*** futarisIRCcloud has quit IRC09:17
*** kraiskil has joined #yosys09:19
*** kraiskil has quit IRC09:28
*** eightdot has quit IRC09:35
*** kraiskil has joined #yosys09:42
*** kraiskil has joined #yosys09:43
*** kraiskil has quit IRC09:51
*** citypw has quit IRC10:01
*** kraiskil has joined #yosys10:03
*** cr1901_modern has quit IRC11:43
*** analognoise has quit IRC11:47
*** cr1901_modern has joined #yosys12:02
*** togo has joined #yosys12:53
*** rohitksingh_work has quit IRC13:19
*** kraiskil has quit IRC13:34
*** kraiskil has joined #yosys13:47
*** rohitksingh has joined #yosys14:08
*** maikmerten has joined #yosys14:26
*** rohitksingh has quit IRC14:31
*** rohitksingh has joined #yosys14:34
*** kraiskil has quit IRC14:51
*** rohitksingh has quit IRC15:03
*** kraiskil has joined #yosys15:05
*** kraiskil has joined #yosys15:06
*** kraiskil has quit IRC15:29
*** gsi__ is now known as gsi_16:01
mithrodaveshah: 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
tpbTitle: Work In Progress | Probot (at probot.github.io)16:07
*** eightdot has joined #yosys16:29
*** m4ssi has quit IRC16:41
*** kraiskil has joined #yosys16:41
*** emeb_mac has joined #yosys16:43
*** cdleary has joined #yosys17:17
*** kraiskil has quit IRC17:26
*** kraiskil has joined #yosys17:27
*** cdleary has quit IRC17:33
*** rohitksingh has joined #yosys17:43
*** rohitksingh has quit IRC18:01
*** mjacob has quit IRC18:04
*** rohitksingh has joined #yosys18:12
*** dys has joined #yosys18:31
*** rohitksingh has quit IRC19:26
*** kraiskil has quit IRC19:50
*** maikmerten has quit IRC20:56
*** emeb has joined #yosys21:07
janrinzeZipCPU: the 'old' code for SDcard worked 'out of the box' :-)21:28
ZipCPUjanrinze ... was that your old code?21:29
janrinzeZipCPU: not particularly fast but plenty compatible.21:29
ZipCPUSoftware control, or HDL control?21:29
janrinzeOh, it's some bitbanging code in C that pretends to be a SPI port for the SDcard.21:29
janrinzeSoftware control.21:30
janrinzeSince that works well it should be possible to migrate that to HDL if i can find the time.21:30
ZipCPUSure!  But now, you don't need to find the time quite so fast21:31
janrinzeZipCPU: Now the flash bootloader works.. indeed. no need21:31
janrinzeMore 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 designs21:32
janrinzebumped into another one?21:33
ZipCPUNot today, no ... but thanks for asking ;)21:33
ZipCPUNo, today's current task is to see if I can't verify erasing the flash faster if I put a CPU into the FPGA21:34
ZipCPUIt was going to be using an accelerator, but programming the flash is just too slow so far21: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
janrinzeHow slow is 'slow'?21:35
ZipCPUI haven't timed it, so about all I can say is slower than my level of patience21:36
ZipCPUWatching the same value transfer across the bus over, and over, and over ...21:36
ZipCPUI know it can be much faster21:36
janrinzeDo you have it in GIThub or is it not public?21:37
ZipCPUNah, this one is quite public: https://github.com/ZipCPU/arrowzip21:37
tpbTitle: GitHub - ZipCPU/arrowzip: A ZipCPU based demonstration of the MAX1000 FPGA board (at github.com)21:37
ZipCPUjanrinze: If there's something particular you are looking for, let me know.  Perhaps I could save you the search?21:40
janrinzedualflexpress.v is the one?21:46
janrinzeWas looking into that.21:46
ZipCPUThat's the Verilog version of the flash controller, yes21:46
ZipCPUThe C++ half of it is found in sw/host/flashdrvr.cpp21:47
janrinzeThen i got that right :-)21:47
ZipCPUdualflexpress isn't really the problem.  That's not the slow part.21:47
ZipCPUThe 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 port21:48
janrinzeOkay, what baud rate?21:48
ZipCPUalthough the data's being sent in (cough) hex.  So, only 4-bits of useful data per byte21:49
janrinzeI see.. that's a tad over 60 KB /sec max21:49
janrinzeAssuming the hex coding.21:50
ZipCPUIt gets worse.  It takes me roughly 11 characters to send 32-bits of data, counting the carriage return and newline21:50
janrinzeso about 30% actual data.21:51
ZipCPUYeah, about that21:51
ZipCPUAnd ... the data gets sent about 4 times at that 30% rate21:51
janrinzestill it would only be 3 times faster if you could eliminate that at 1Mb/s21:51
ZipCPUWhile it's not optimum, it is low logic ...21:52
ZipCPUYes, that would be faster, and yes I have a project to do that, it's .... not getting much attention these days.  ;)21:52
janrinzeHave you tried FTDI parallel to USB? that can do about 20 MB/s (assuming USB2)21:53
ZipCPUI'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 devices21:54
ZipCPUNo.  I haven't tried any of the faster FTDI modes21:54
ZipCPUThere's a fast serial mode that I'd love to try to--should get up to nearly 50Mbps IIRC21:54
ZipCPU(You mean 20Mb/s, right?  or 20MB/s?)21:54
janrinzeUSB2 should be capable of 480Mb/s (bits)21:55
ZipCPUAhm, no.21:55
ZipCPUI think your best rate is 12Mb/s over USB21:55
janrinzeThat's USB 1.1 right?21:55
janrinzeUSB 3 does 5Gb/s21:55
ZipCPUThere is a 480Mb/s speed, but I think it requires USB321:55
ZipCPUIt's also out of reach of most FPGAs21:56
daveshahUSB2 HS is 480Mb/s21:56
daveshahIt's a bit of a pain for FPGAs because of clock recovery, and it's mixed single ended and diff signalling21:56
ZipCPUdaveshah: I didn't think that was until USB 3 ... did I miss that?21:56
daveshahUSB3 is 5Gbps21:57
ZipCPUNvm then21:57
daveshahMany USB2 devices only support the 12Mbps mode21:57
ZipCPUYou think the FTDI controller would handle 480Mbps?  FT2232H?21:57
daveshahIt's "high speed" devices that add 480Mbps support21:57
daveshahYes, the H is for high speed :)21:57
ZipCPUOk ...21:58
janrinzedaveshah: using a FTDI chip for USB to parallel can relieve the bit speed at the FPGA side, right?21:58
daveshahI think it's only sync fifo mode that gets close to that21:58
daveshahjanrinze: yes21:58
daveshahThere's even a FTDI USB3 to parallel21:58
janrinzeI never tried the FTDI parallel printer interface in my bottom drawer.. should be bi-directional, right?21:59
daveshahI think a lot of the FTDI parallel printer chips are 12Mbps only though22:00
janrinzeprobably, they are quite cheap.22:00
janrinzeStill, 12 times faster than the 1Mbps he has now :-D22:01
ZipCPULet's see ... 1Mbps * 30% * 1/4 ~= 75 kbps, or 9kB/s22:03
ZipCPUI might get the biggest bang for my buck by switching from this hexadecimal encoding to something smarter22:04
emebseems 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
ZipCPUemeb: That's actually the approach I'm pursuing now.22:05
emebZipCPU: validation! :)22:06
ZipCPUI'll feel better about it once it works ...22:06
emeblots of opportunity for formal!22:07
ZipCPUOk, I misunderstood you .... I'm using the CPU instead of the logic to do this22:08
ZipCPUNot nearly as many opportunities for formal as a result22:08
emebZipCPU: 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
ZipCPUOk, I'll agree with that22:09
emebEspecially if you just happen to have a CPU laying around - as you do.22:09
emebHad 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
janrinzeZipCPU: no USB device for the CPU yet, right?22:11
emebVerilog turned out to be pretty easy and used less resources!22:11
ZipCPUjanrinze: You mean like tinyfpga has been using?22:11
emeb(vs using up psedo ROM in the CPU address space)22:11
ZipCPUGot to run here .... suppertime22:12
emeb<insert Snoopy cartoon>22:12
janrinzeZipCPU: 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
emebUSB PHY is not a simple thing22:13
emebyou can tell it was designed by committee22:13
cr1901_moderndaveshah: >and it's mixed single ended and diff signalling22:29
cr1901_modernIME, 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
daveshahI don't think that works for HS22:30
cr1901_modernwell HS doesn't even have the proper voltages to interface to FPGA22:30
daveshahMaybe with a very short cable, not sure what the levels are22:30
cr1901_modern1.2V something22:30
cr1901_moderndaveshah: Actually idk the voltage offhand either22:31
cr1901_modernBut it isn't 3.322:31
daveshah1.2V is fine for FPGAs22:31
cr1901_modernAlso 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 RAM22:33
cr1901_moderntnt gave a partial solution for icetime, but up5k icetime db still exceeds 2GB of RAM and brings my pinebook to its knees22:34
cr1901_modernnextpnr takes 4 hours to compile22:34
cr1901_modern(going to swap on a USB stick)22:34
daveshahicetime might be splittable further into functions22:34
daveshahNot so sure about nextpnr22:35
daveshahIf it's creating the bbas that is slow then prebuilding is the solution22:35
cr1901_modernThen shouldn't there be daily blobs for that?22:36
daveshahThe bbas are truly arch independent, the cc/bin only depend on endianness22:36
daveshahYes, but no one has got round to setting up the infra for that22:36
cr1901_moderndaveshah: Don't remember which step is the one that takes up all that time22:36
cr1901_modernI _think_ it was the bba generation22:36
tpbTitle: GitHub - YosysHQ/nextpnr-chipdb: ChipDB builder for NextPnR project (at github.com)22:36
cr1901_modernwhat's that repo?22:37
cr1901_modernwas the chipdb stuff moved out?22:38
daveshahNo, but it's another option22:38
daveshahYou can use this repo to build a bin chipdb that is then passed to nextpnr22:38
daveshahInstead of building the bba during the main build process22:38
cr1901_modernThe chipdbs are large, correct?22:39
cr1901_moderni.e. hundreds of megs22:39
cr1901_modernlarge == "github would get pissed if they were hosted as blobs in a repo"22:39
daveshahThey compress quite nicely though22:41
daveshahIIRC about 10-20MB xz for all ice40 chipdbs22:42
cr1901_modernIf that's true, then I know a workaround to host the blobs in nextpnr-chipdb every time a travis build occurs22:42
cr1901_modernso you don't need to add a tag to each commit22:43
cr1901_modernyou can create a separate branch with just the tarballs/zip files that's automatically updated each commit :P22:45
daveshahIf you want to be fancy, only commits touching certain files (bbasm, the Python script that creates the bbas, and constids.inc) need a new db22:49
emebcr1901_modern: hmm... I just built icestorm/yosys/nextpnr on a 2GB EEE laptop. It took a few hours, but it all fit.22:56
emebOTOH It has an SSD and 2GB swap22:56
emebhow do ppl get the toolchain installed on an RPi Zero? Are there precompiled versions?22:58
*** mjacob has joined #yosys23:15
*** futarisIRCcloud has joined #yosys23:37
cr1901_modernemeb: Sure it still can be done. I just don't want it to go to swap23:47
cr1901_moderneven 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 swap23: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!