| *** tpb has joined #yosys | 00:00 | |
| *** Noname_Matt has quit IRC | 00:12 | |
| *** Noname_Matt has joined #yosys | 00:30 | |
| *** PyroPeter has quit IRC | 02:45 | |
| *** PyroPeter has joined #yosys | 02:59 | |
| *** Noname_Matt has quit IRC | 03:15 | |
| *** PyroPeter has quit IRC | 03:16 | |
| *** citypw has joined #yosys | 03:26 | |
| *** PyroPeter has joined #yosys | 03:28 | |
| *** Noname_Matt has joined #yosys | 03:47 | |
| *** Noname_Matt has quit IRC | 04:14 | |
| cr1901_modern | daveshah: I want to revisit... is it possible to refactor building ice40 and ecp5 databases so it's possible to compile nextpnr/icestorm in constrained (2GB RAM) environments, so one can keep up with upstream without having to wait for blobs? | 04:27 |
|---|---|---|
| cr1901_modern | Brought to you by "I just compiled yosys on a SBC for the first time in nearly a year, and I'm dreading doing the rest" | 04:29 |
| whitequark | cr1901_modern: I use 4 GB of swap. | 04:32 |
| whitequark | it takes about a day for the entire toolchain | 04:32 |
| cr1901_modern | Odd, I've never had it take a day even with swap... 3 hours maybe? | 04:34 |
| cr1901_modern | But I didn't do an ecp5 compile | 04:34 |
| whitequark | i have an rpi3 | 04:34 |
| cr1901_modern | This is an asus tinkerboard, and I've also done it on pinebook (both have 2GB RAM) | 04:35 |
| whitequark | yeah, rpi3 is pathologically bad | 04:35 |
| cr1901_modern | A clean build of the most recent commit of yosys built in 22 minutes w/ -j4 | 04:37 |
| cr1901_modern | just now | 04:37 |
| cr1901_modern | before up5k features exploded :P, that would've been the bulk of the build lol | 04:39 |
| *** craigo has joined #yosys | 05:15 | |
| *** emeb_mac has quit IRC | 06:26 | |
| *** pie_ has joined #yosys | 08:39 | |
| *** fsasm has joined #yosys | 08:41 | |
| *** Jybz has joined #yosys | 09:10 | |
| *** citypw has quit IRC | 09:47 | |
| *** rombik_su has joined #yosys | 09:51 | |
| *** X-Scale has quit IRC | 10:04 | |
| tnt | "yosys-abc: src/map/if/ifMap.c:460: void If_ObjPerformMappingAnd(If_Man_t *, If_Obj_t *, int, int, int): Assertion `pCutSet->nCuts > 0' failed. | 10:05 |
| tnt | Damnit, I must me cursed. | 10:06 |
| ZirconiumX | Bugpoint~ | 10:11 |
| tnt | I have no clue how to use that | 10:13 |
| ZirconiumX | tnt: well, can you send me your input files? | 10:16 |
| tnt | ZirconiumX: master of https://github.com/Spritetm/hadbadge2019_fpgasoc | 10:16 |
| tpb | Title: GitHub - Spritetm/hadbadge2019_fpgasoc: FPGA SoC code and application example for Hackaday Supercon 2019 badge (at github.com) | 10:16 |
| tnt | and I'm running yosys master | 10:17 |
| ZirconiumX | And your Yosys command line? | 10:17 |
| tnt | it's in the makefile | 10:17 |
| tnt | Disabling abc9 makes it build at least. | 10:18 |
| ZirconiumX | soc or blink? | 10:20 |
| tnt | soc | 10:21 |
| tnt | (you need clone --recursive or submodule init / update) | 10:21 |
| tnt | just tried on a fresh clone and yeah, crashes too at ste 53.48.1.4. | 10:22 |
| ZirconiumX | ABC: yosys-abc: src/map/if/ifMap.c:460: void If_ObjPerformMappingAnd(If_Man_t *, If_Obj_t *, int, int, int): Assertion `pCutSet->nCuts > 0' failed. | 10:22 |
| ZirconiumX | Yep, I can reproduce | 10:22 |
| tnt | Glad I'm not alone :) | 10:23 |
| ZirconiumX | tnt: Oh goody, this is a fun bug | 10:36 |
| tnt | lol | 10:36 |
| daveshah | It's not the first time I've seen t | 10:44 |
| daveshah | *it | 10:44 |
| daveshah | I think there was an attempt to fix it in abc a while ago, but evidentally that isn't fully working | 10:44 |
| tnt | Yeah, I had a similar bug like a week ago or so and that got fixed by updating to master but ... well here we are :p | 10:45 |
| *** dys has joined #yosys | 10:49 | |
| ZirconiumX | daveshah: This is a fun one to bugpoint. I get a "used with parameters but is not parametric" error if I don't call "hierarchy -top"; and then that requires Trellis cells to be imported, and then after this it works fine | 10:52 |
| ZirconiumX | Or, well | 10:54 |
| ZirconiumX | It works under bugpoint but not when I invoke "synth_ecp5 -abc9" manually | 10:55 |
| daveshah | Yes this bug is pretty much random | 10:55 |
| daveshah | Anything that permutes the design tends to fix it | 10:55 |
| daveshah | The root cause I believe comes from uneven delays in whiteboxes | 10:59 |
| daveshah | and how abc propagates delays (setting all the numeric values in abc9_5g.box to the same thing does make it go away) | 11:00 |
| ZirconiumX | daveshah: The help for synth_ecp5 doesn't actually show the commands invoked in -abc9 mode, which is a bit annoying | 11:03 |
| daveshah | I've created https://github.com/berkeley-abc/abc/issues/55, fwiw | 11:07 |
| tpb | Title: Issues · berkeley-abc/abc · GitHub (at github.com) | 11:07 |
| *** X-Scale has joined #yosys | 11:17 | |
| *** fsasm_ has joined #yosys | 12:08 | |
| *** dys has quit IRC | 12:09 | |
| *** fsasm has quit IRC | 12:11 | |
| *** emeb_mac has joined #yosys | 12:40 | |
| *** emeb_mac has quit IRC | 12:47 | |
| *** Noname_Matt has joined #yosys | 13:08 | |
| *** dys has joined #yosys | 13:15 | |
| *** Noname_Matt has quit IRC | 14:31 | |
| tnt | ZirconiumX: daveshah: Interesting development, if I build the exact same yosys using gcc and not clang, it works. | 14:53 |
| daveshah | Yosys or Yosys and ABC? | 14:54 |
| tnt | I would guess both ... I changed yosys Makefile and set "CONFIG := gcc" at the beginning | 14:54 |
| tnt | then make clean && make | 14:54 |
| daveshah | It might not be related - the bug is very sensitive to the exact netlist, even tiny changes tend to cause it to disappear | 14:55 |
| daveshah | and it could be that something changes in Yosys because of the compiler change (it shouldn't but I've seen bugs like this before) | 14:55 |
| tnt | but why would the compiler change the netlist ?!? | 14:55 |
| daveshah | I've seen things like initialiser call order before | 14:56 |
| tnt | Mmmm right. | 14:56 |
| daveshah | It's also possible that it's inside ABC | 14:57 |
| *** davidthings has joined #yosys | 15:12 | |
| tnt | daveshah: Do you know how the ODDRX1F behaves ? The IDDRX1F is explicit saying Q0 is rising edge and Q1 is falling edge. But ODDR says D0 is 'first to be sent out' which would tell me it's falling edge ? | 15:20 |
| daveshah | I can't remember. I started looking at the Lattice sim model but it's a bit messy | 15:21 |
| daveshah | I think it's the same as Xilinx in SAME_EDGE_PIPELINED | 15:22 |
| tnt | Oh wait there is ODDRXE as well | 15:22 |
| daveshah | That's for the previous generation | 15:22 |
| *** Thorn has quit IRC | 15:23 | |
| tnt | Oh yeah right ... nm | 15:23 |
| daveshah | https://www.irccloud.com/pastebin/OHusC42b/ODDRX1F.v | 15:24 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 15:24 |
| daveshah | this is the Diamond sim model, fwiw | 15:24 |
| tnt | Ok, I'll try to figure it out, tx :) | 15:25 |
| daveshah | fwiw, this patch does seem to fix the abc assertion failure (not sure if it impacts qor): https://github.com/berkeley-abc/abc/issues/55#issuecomment-546612665 | 15:30 |
| *** craigo has quit IRC | 15:33 | |
| tnt | Heh, indeed ODDRX1F seem to be massively pipelined :/ | 15:52 |
| *** pie_ has quit IRC | 15:58 | |
| daveshah | Yeah, it certainly is | 15:59 |
| tnt | Like ... 3 clocks cycles ? | 15:59 |
| tnt | Is there no way to just have it like on the ice40 for instance ? | 15:59 |
| daveshah | Nope | 15:59 |
| *** freemint has joined #yosys | 16:01 | |
| *** Thorn has joined #yosys | 18:39 | |
| *** Duality has joined #yosys | 19:04 | |
| Duality | hi | 19:04 |
| daveshah | Hi Duality! | 19:07 |
| *** dys has quit IRC | 19:21 | |
| Duality | i am working on something where i have a clock input and a counter, and the output of the counter goes to one pin. but i have this weird output where the output would come to early or late, and i just can't figure out why. (at first i thought my logic analyzer wasn't fast enought so i put a scope on it) | 19:23 |
| Duality | would this be the place to get some help with that :)? | 19:23 |
| Duality | i am very new to fpga's | 19:23 |
| daveshah | What frequency is the counter, and where is the clock input coming from? | 19:24 |
| Duality | the internal hfosc | 19:24 |
| daveshah | and what do you mean by too early/late? by a nanosecond? by a factor of two? | 19:24 |
| Duality | daveshah: actually yes! a factor 2 | 19:25 |
| daveshah | Have you connected the HFOSC to a pin and checked its frequency is correct? | 19:25 |
| Duality | yes | 19:25 |
| Duality | one moment though going to double check that :) | 19:26 |
| daveshah | If that is OK, I would suggest posting your code | 19:27 |
| Duality | ok confirmed that clock looks fine :) | 19:45 |
| Duality | this is my code currently: https://pastebin.com/7jdJwcvT | 19:46 |
| Duality | i think i found it | 19:48 |
| Duality | i have removed the dir code and that seems to have solved it, i am just not sure why it has solved it. | 19:54 |
| rombik_su | Duality: What was the point of 'dir' in the first place? | 19:55 |
| Duality | rombik_su: i am not sure i think i tried to make a fancy counter where you could select whether it counted up or down. | 19:55 |
| rombik_su | Duality: Couple of small things: if(count == 15'b1) should be if(count == 16'b1) | 19:56 |
| rombik_su | Duality: Then it's should be input for 'counter' module perhaps | 19:56 |
| Duality | rombik_su: why? because 15:0 is 16 bits? | 19:56 |
| rombik_su | Duality: Yes. :) | 19:57 |
| Duality | ah | 19:57 |
| Duality | got to remember counting starts at 0 :) | 19:57 |
| rombik_su | Duality: Basically, dir was messing with your counter, erm, counting. Did you simulate this? | 19:58 |
| Duality | no i don't simulate maybe i should :) | 20:00 |
| Duality | currently have a dev board and a scope connected :P | 20:00 |
| rombik_su | Duality: Oh, I'm strongly suggesting you to use simulator, it'll save you a *lot* of time. Ideally, you want to get your design up and running in simulator a long before firing up any FPGA IDE. | 20:02 |
| rombik_su | *FPGA EDA. | 20:02 |
| Duality | alright :) | 20:06 |
| Duality | i am just playing around now but i understand that it's a good idea to simulate :) | 20:07 |
| Duality | thank you all for being so nice and helpfull! :) | 20:09 |
| Duality | i remember why i made the dir, because i wanted a counter that ran up and down so that i could pwm fade a led in and out :) and that worked fine! because with leds i couldn't really see what was going on | 20:13 |
| Duality | or atleast seemed to work fine. probably would have seen the issue if i simulated though :) | 20:13 |
| rombik_su | No problem. For dimming you'll probably need two counters - one for PWM generation and second to iterate over PWM taps. | 20:22 |
| Duality | rombik_su: yes that would do i think :) | 20:35 |
| Duality | rombik_su: what are taps? i think you meen the value where you select the duty? | 20:36 |
| rombik_su | Duality: Yes | 20:37 |
| Duality | alright | 20:38 |
| Duality | i'll have to leave bye! and thanks again! :) | 20:39 |
| *** Duality has quit IRC | 20:39 | |
| *** Jybz has quit IRC | 21:57 | |
| *** fsasm_ has quit IRC | 22:19 | |
| *** freemint has quit IRC | 22:54 | |
| *** rombik_su has quit IRC | 22:57 | |
| *** davidthings has quit IRC | 23:31 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!