| *** tpb has joined #yosys | 00:00 | |
| *** smkz has joined #yosys | 00:01 | |
| *** srk has quit IRC | 00:07 | |
| *** srk has joined #yosys | 00:21 | |
| *** lf has quit IRC | 00:40 | |
| *** lf has joined #yosys | 00:40 | |
| *** podrian has joined #yosys | 01:04 | |
| podrian | Hello! Relatively new to Verilog... I have a design which makes use of `generate` blocks (they are named), and Yosys's write_verilog() is elaborating with names along the lines of `mod_type \genblk[0] (ports)`, I suspect the backslash is escaping the brackets, but it appears that neither iverilog nor verilator know how to handle a module with | 01:09 |
|---|---|---|
| podrian | brackets in its name (i'm driving everything with cocotb, so I guess it could be a cocotb thing). | 01:09 |
| podrian | Is there a way to modify the way the generate block module names are instantiated to something like `genblk_0_` rather than `\genblk[0]` ??? | 01:10 |
| *** podrian has left #yosys | 01:11 | |
| *** podrian has joined #yosys | 01:11 | |
| *** podrian has left #yosys | 01:12 | |
| *** podrian90 has joined #yosys | 01:21 | |
| *** podrian90 is now known as podrian | 01:23 | |
| *** podrian has quit IRC | 01:26 | |
| *** podrian has joined #yosys | 01:28 | |
| podrian | I guess it's actually something more like `\genblk[0].module(ports)` but I think it should be clear anyway :) | 01:29 |
| *** fakedad has joined #yosys | 01:35 | |
| *** podrian has quit IRC | 01:36 | |
| *** Degi_ has joined #yosys | 01:38 | |
| *** Degi has quit IRC | 01:41 | |
| *** Degi_ is now known as Degi | 01:41 | |
| *** srk has quit IRC | 02:29 | |
| *** srk has joined #yosys | 02:42 | |
| *** citypw has joined #yosys | 03:31 | |
| *** srk has quit IRC | 04:02 | |
| *** srk has joined #yosys | 04:03 | |
| *** az0re has quit IRC | 05:15 | |
| *** az0re has joined #yosys | 05:18 | |
| *** vidbina has joined #yosys | 06:30 | |
| *** emeb_mac has quit IRC | 06:34 | |
| *** awordnot has quit IRC | 06:36 | |
| *** awordnot has joined #yosys | 06:41 | |
| *** m4ssi has joined #yosys | 07:37 | |
| *** vidbina has quit IRC | 08:36 | |
| *** kristianpaul has quit IRC | 08:50 | |
| *** kristianpaul has joined #yosys | 08:51 | |
| *** xtro has quit IRC | 08:54 | |
| *** kristianpaul has quit IRC | 09:04 | |
| *** kristianpaul has joined #yosys | 09:06 | |
| *** jakobwenzel has joined #yosys | 09:39 | |
| *** peepsalot has quit IRC | 10:04 | |
| *** peepsalot has joined #yosys | 10:06 | |
| *** aep has joined #yosys | 10:25 | |
| aep | how would i figure out how pins are named in nextpnr? is there a human readable list? | 10:27 |
| daveshah | what do you mean? what pins? | 10:29 |
| aep | the pin names you assign in pins.cnf . | 10:31 |
| daveshah | cnf? | 10:32 |
| daveshah | I'm afraid I need a bit more context, I'm not even sure what a cnf file is | 10:32 |
| aep | err pcf, sorry | 10:33 |
| aep | i'm trying to port some hello world to a 40up5k board, but none of the pins exist | 10:33 |
| aep | nextpnr-ice40 --up5k --package sg48 --freq 20 --json top.json --pcf pins.pcf --asc top.asc ==> ERROR: package does not have a pin named '8A' (on line 1) | 10:33 |
| daveshah | the pins are the package pin numbers, not the board pin numbers | 10:34 |
| aep | right, where would i find them to guess what they're named? | 10:35 |
| aep | i tried pretty much all the name formats in the datasheet | 10:35 |
| daveshah | it's the physical, QFN48, pin number | 10:36 |
| aep | this is probably obvious to someone who has used the propriatary tools, but i never did | 10:36 |
| aep | oooh. weird. the example used bank names | 10:37 |
| aep | and that worked fine | 10:37 |
| daveshah | can you point me to the example? | 10:37 |
| aep | https://github.com/lawrie/tiny_usb_examples/tree/master/hello_world | 10:37 |
| daveshah | those are pin numbers too - but for a BGA package | 10:38 |
| aep | aha! | 10:38 |
| Sarayan | aep: https://www.latticesemi.com/view_document?document_id=51971 ? | 10:38 |
| Sarayan | from https://www.latticesemi.com/en/Products/FPGAandCPLD/iCE40UltraPlus#_1583858FEF1D4406B570F0CACD485268 | 10:39 |
| tpb | Title: iCE40 UltraPlus - Lattice Semiconductor (at www.latticesemi.com) | 10:39 |
| Sarayan | ice40up5k pinout being that document | 10:39 |
| aep | oh nice | 10:39 |
| Sarayan | I have a feeling that's what you need | 10:39 |
| aep | yes, thank you! | 10:40 |
| Sarayan | :-) | 10:40 |
| *** vidbina has joined #yosys | 11:09 | |
| *** strobokopp has joined #yosys | 11:19 | |
| aep | allright, next problem is i have never used lattice diamond, so im not familiar with the specific macros. like, i dunno what SB_PLL40_CORE is but nextpnr tells me to use a PAD PLL instead for which i also dont know the macro | 11:32 |
| aep | is there a document i could read that contains this stuff without going through the whole propriatary thing? | 11:33 |
| aep | lattice docs just say i should look in the ominous "iCE Technology Library" which is probably inside diamond? | 11:34 |
| daveshah | aep: http://www.latticesemi.com/~/media/LatticeSemi/Documents/TechnicalBriefs/SBTICETechnologyLibrary201608.pdfhttp://www.latticesemi.com/~/media/LatticeSemi/Documents/TechnicalBriefs/SBTICETechnologyLibrary201608.pdf | 11:36 |
| tpb | Title: Server Error (at www.latticesemi.com) | 11:36 |
| daveshah | * http://www.latticesemi.com/~/media/LatticeSemi/Documents/TechnicalBriefs/SBTICETechnologyLibrary201608.pdf | 11:36 |
| aep | yeah just found the pdf and it contains exactly what i need to know. sorry for the noise D: | 11:36 |
| *** jakobwenzel has quit IRC | 12:42 | |
| *** elGamal has quit IRC | 12:53 | |
| *** kristianpaul has quit IRC | 13:16 | |
| *** kristianpaul has joined #yosys | 13:19 | |
| *** vidbina_ has joined #yosys | 13:25 | |
| *** vidbina has quit IRC | 13:28 | |
| dkozel | daveshah: Were you working with an Alveo 250? | 13:47 |
| daveshah | I was, although I haven't had time for that recently | 13:47 |
| dkozel | Ok, it's looking like we might be able to host one with a Xilinx license on a public server if that would be helpful to anyone | 13:48 |
| dkozel | Anything that we can do to help improve FOSS support, I'd be interested in hearing. | 13:49 |
| daveshah | I can't really think of anything that's going to be particularly practical there, tbh | 13:53 |
| daveshah | working on IP is probably going to be more useful right now | 13:53 |
| dkozel | For signals DSP, that's happening. What IP are you thinking of? | 13:54 |
| fakedad | Hi, do either of you have any tips regarding how to change the naming of `generate` block arrays? | 13:56 |
| *** fakedad has left #yosys | 14:54 | |
| *** maartenBE has quit IRC | 16:04 | |
| *** maartenBE has joined #yosys | 16:07 | |
| aep | hm, im failing at doing the PLL correctly. documentation says "It is strongly recommended that the configuration of the PLL primitives be accomplished through the use of the PLL Configuration tool that is offered as part of the iCEcube2 software." | 16:16 |
| aep | is there an open source alternative? | 16:16 |
| *** emeb has joined #yosys | 16:17 | |
| *** jakobwenzel has joined #yosys | 16:17 | |
| daveshah | yes, icepll | 16:17 |
| aep | oh nice, thanks | 16:19 |
| aep | hah that actually worked out of the box. this stuff is NICE | 16:30 |
| *** citypw has quit IRC | 16:51 | |
| *** xtro has joined #yosys | 17:07 | |
| aep | oof the critical path errors are really hard to read. can i somehow make out where i'm spending too much time from the long list of error messages? https://gist.githubusercontent.com/aep/a042c92fb6e68653acc7ea6ce4efd15f/raw/9a200e97dff91916b8180639d7c021a236870d74/gistfile1.txt | 17:14 |
| aep | i mean, its clear which clock fails, but not where. | 17:14 |
| daveshah | it looks like you have a path via uart.usb_fs_pe_inst.usb_fs_out_pe_inst.ep_put_addr[0]; uart.usb_fs_pe_inst.usb_fs_out_pe_inst.ep_get_addr[0]; uart.ctrl_ep_inst.detect_pkt_end; uart.usb_uart_bridge_ep_inst.get_out_data etc | 17:16 |
| aep | thats not actually my stuff, and it works fine when i remove all of my code | 17:17 |
| daveshah | the critical path looks to be entirely within the usb core | 17:17 |
| aep | yeah that's what confuses me | 17:18 |
| daveshah | it's possible that your code is making things more congested so putting more pressure on stuff overall, or it's just random | 17:18 |
| aep | am i reading the error message correctly that the whole design is clocking at 18Mhz? | 17:18 |
| aep | ERROR: Max frequency for clock 'clk_48mhz_$glb_clk': 18.00 MHz (FAIL at 20.00 MHz) | 17:18 |
| daveshah | Yes | 17:19 |
| aep | thats extremly slow for a 48Mhz clock D: | 17:19 |
| daveshah | if you look at the bottom, you can see only a very small proportion of paths are failing (negative in the histogram) | 17:19 |
| aep | i probably did some noob mistake that made a bad layout or something | 17:19 |
| daveshah | you can't do all that much in 48MHz on an iCE40UP5K, tbf | 17:20 |
| *** m4ssi has quit IRC | 17:20 | |
| aep | i dunno, i guess i could just yolo in a higher clock, but i'm trying to learn here | 17:20 |
| aep | actually, i can't? a higher clock doesnt fix it. does that mean it's something not on the clock path? | 17:34 |
| *** vidbina_ has quit IRC | 17:36 | |
| daveshah | A _lower_ clock (below ~18MHz in this case) 'fixes' a timing failure | 17:42 |
| daveshah | Not a higher one | 17:42 |
| *** cr1901_modern has quit IRC | 17:47 | |
| *** jakobwenzel has quit IRC | 17:49 | |
| *** elGamal has joined #yosys | 17:49 | |
| *** cr1901_modern has joined #yosys | 18:00 | |
| aep | errr, i think i dont understand what clocks this is reffering to. there's a pll and there's the thing you pass to --freq | 18:02 |
| aep | i _think_ the --freq argument is actually what its checking against, and obviously lowering that will make it pass, but that's kinda bad because i need to hit some timings for usb | 18:03 |
| aep | nut nothing i do with the pll seems to have any influence on the histogram | 18:03 |
| daveshah | yeah nextpnr-ice40 doesn't derive PLL timing constraints yet (mainly because with some of the stranger modes it's surprisingly hard to get right) | 18:15 |
| daveshah | to your PCF file, add `set_frequency clk_48mhz 48` | 18:15 |
| aep | ah nice! now the output makes more sense. still failing to understand why my code wont pass tho | 18:17 |
| daveshah | is this usb core designed for the up5k? | 18:18 |
| daveshah | the critical path makes me think it probably isn't; it looks a long way away from reaching 48MHz | 18:18 |
| aep | no.didnt find any. this is for the lp8k | 18:18 |
| aep | isnt the LP slower than the UP? | 18:19 |
| daveshah | then tbh it probably isn't going to have a short enough critical path to pass timing on the up5k | 18:19 |
| daveshah | no, the UP is significantly slower | 18:19 |
| aep | ooooh | 18:20 |
| aep | funny. i bought into the marketing of "low power" versus "ultra" | 18:20 |
| daveshah | I know tnt's core works on the up5k - https://github.com/no2fpga/no2usb | 18:20 |
| daveshah | the up5k is significantly lower power too, fwiw, and a good few years newer | 18:21 |
| aep | oh nice thanks | 18:21 |
| aep | i mean, the thing i use runs fine but thats probably because USB is veeery tolerant | 18:22 |
| aep | oh wait, is it failing because i have too much stuff on fast lines? | 18:24 |
| aep | would explain why my trivial additional code makes it unhappy] | 18:25 |
| daveshah | No, the critical path is definitely in the USB core | 18:25 |
| daveshah | but moving stuff out of the 48MHz domain that doesn't need to be in it might help in general | 18:25 |
| aep | good idea. lemme just reduce stuff on that clock | 18:27 |
| *** elGamal has quit IRC | 18:27 | |
| aep | actually, i wonder why the --gui thing is just grey for me. there's nothing colored in the device view | 18:27 |
| *** elGamal has joined #yosys | 18:27 | |
| aep | i was hoping i could use it to see if i made a dumb mistake that leads to bad routing | 18:28 |
| cr1901_modern | I wonder if tnt's core fits into an ice401k... and if not, how much could be removed to hack usb into that size | 18:28 |
| cr1901_modern | hx1k* | 18:28 |
| aep | didnt get the other core working. still confused about the frequencies. is `set_frequency clk_48mhz 48` the constraint or the actual pll speed? | 19:10 |
| aep | because it keeps saying it failed 48mhz, which is uh.. yeah i know | 19:10 |
| daveshah | Its the constraint | 19:11 |
| aep | how does it know the real frequency then? | 19:22 |
| cr1901_modern | critical path determines the real frequency | 19:23 |
| aep | oooh, the error is trying to tell me the frequency i set won't work because the critical path is slower? | 19:24 |
| aep | it says 3ns tho, thats perfectly fine for 48Mhz | 19:24 |
| aep | Info: Max delay <async> -> posedge clk_48mhz_$glb_clk: 4.19 ns | 19:25 |
| aep | that means the delay to propagate the whole clock edge is 4.19 ns right? | 19:25 |
| * cr1901_modern is unfortunately afk for a bit :( | 19:26 | |
| lambda | aep: I think the limiting stat here is (posedge -> posedge) on the clock, for which the critical path sits at 55ns, i.e. 18MHz | 20:03 |
| aep | hmm but where do you see that? | 20:06 |
| daveshah | it's at the top of the long report | 20:06 |
| *** kristianpaul has quit IRC | 20:06 | |
| daveshah | 'Info: Critical path report for clock 'clk_48mhz_$glb_clk' (posedge -> posedge):' | 20:06 |
| daveshah | at the bottom is 'Info: 22.5 ns logic, 33.0 ns routing' | 20:06 |
| aep | oooh | 20:07 |
| daveshah | in this case you've blown out your 48MHz budget just on logic, with nothing at all left for routing (which is often more delay than logic particularly for larger designs) | 20:07 |
| aep | yeah i think i can live with 20Mhz | 20:08 |
| daveshah | the USB core is probably designed to run at 48MHz only | 20:08 |
| aep | this is helpful now that i understand. bit confusing output | 20:08 |
| aep | uuh yeah but how would it ever run at 48Mhz if the PLL is 48 and it does a bunch of stuff on clock | 20:08 |
| daveshah | FPGA clocks are fixed by the PLL frequency - if the PLL is set to 48MHz then it is running at 48MHz | 20:09 |
| daveshah | if it fails timing, then it might not work reliably - FPGA timing models are very conservative at room temperature, but you might start seeing failures if it warms up | 20:09 |
| cr1901_modern | Just run it and increase the frequency until it stops working. Then dial the frequency back by 20% :) (don't actually do this) | 20:10 |
| aep | yeah, i was just wondering what you mean by 'designed to run at 48MHz only'. | 20:11 |
| aep | the original makefile specified --freq 20 ... so it never validated at 48? | 20:12 |
| daveshah | the core is designed to run at 48MHz because it oversamples the 12MHz USB rate by x4 | 20:12 |
| aep | ah yes | 20:12 |
| daveshah | no, they were probably just relying on the fact that it failed timing but still worked even on the lp | 20:12 |
| *** kristianpaul has joined #yosys | 20:12 | |
| aep | thats how i got confused. it was never valid lol | 20:13 |
| daveshah | unless their PLL was actually set up to run at 20MHz, but that's a very unlikely frequency for a USB FS core which invariably pick integer multiples of 12MHz | 20:13 |
| aep | nope. was at 48 | 20:13 |
| aep | which makes sense | 20:13 |
| aep | i guess i just need to find a different fpga that can actually do this | 20:14 |
| daveshah | tbf, it probably would have got a lot closer to 48 on a lp and been a lot less marginal | 20:14 |
| aep | right | 20:14 |
| daveshah | it's definitely possible to do USB on a up5k | 20:14 |
| aep | how would i know btw? experience or can you actually know this from the spec? | 20:14 |
| daveshah | the trick is to do the fast part in the 48MHz domain and the rest in a 12MHz or 24MHz domain | 20:14 |
| daveshah | I know because people have done it (e.g. fomu, icebreaker-bitsy) | 20:14 |
| aep | uuh by domain you mean a different clock? this thing only has one | 20:15 |
| aep | oh right, i should look at fomu | 20:15 |
| daveshah | there are various ways of getting multiple clocks from the PLL | 20:15 |
| daveshah | you can either output clock and clock/2; or clock and input clock mirrored | 20:15 |
| aep | oh nice. SB_PLL40_2F_CORE i guess | 20:17 |
| daveshah | this is how tnt's usb code does it | 20:17 |
| daveshah | https://github.com/no2fpga/no2bootloader/blob/master/gateware/ice40/rtl/sysmgr.v#L31-L67 | 20:17 |
| aep | yeah i couldnt get that thing to be stable | 20:17 |
| aep | the output looks like noise | 20:18 |
| daveshah | what board are you using? | 20:18 |
| cr1901_modern | daveshah: Uhh, without thinking about it too much, why does "input clock mirrored" work to improve timing closure? | 20:18 |
| aep | the ice40 b evb (the black one) | 20:18 |
| daveshah | cr1901_modern: it's to do with the routing limitations of the iCE40 (can't use a dedicated PLL pin as a general input), not timing | 20:19 |
| daveshah | aep: should be fine, it's only the early upduinos that have broken PLL circuitry | 20:19 |
| cr1901_modern | hmmm | 20:19 |
| aep | yeah the weird core i found works perfectly despite failing timings | 20:20 |
| aep | i'll try no2fpga again. maybe i just didnt use it correctly (since there are no docs) | 20:20 |
| daveshah | I know from past experiences of people trying to get the old tinyfpga bootloader working on the up5k (which was fine on a lp8k but also failed timing badly on the up5k) it worked on some boards but not others | 20:20 |
| daveshah | because of process variations between the chips, slight vcc differences between regulators, etc | 20:21 |
| aep | yeah, i dont think i want to ship this with failing timings :D | 20:21 |
| aep | btw, since i'm asking a lot of dumb questions. does anyone know any learning material that specifically uses yosys? | 20:22 |
| daveshah | https://github.com/icebreaker-fpga/icebreaker-workshop is a good start for the very basics | 20:23 |
| aep | i'd totally pay for a course. but the ones i had usually just do a bunch of clicks in some gui and never explain anything | 20:23 |
| aep | oh neat | 20:23 |
| daveshah | as far as the more intricate side of timing analysis specific to nextpnr goes, I don't think there is a particularly good reference to that - but that is definitely something that can be improved | 20:31 |
| daveshah | the timing code in nextpnr is long overdue a substantial rewrite for better performance and functionality, so if you have any suggestions to presentation improvements, that would always be appreciated (and at some point I will do derived PLL constraints for ice40 which will make using them less confusing) | 20:32 |
| aep | oh yeah, it would very much helped if the "timing failed because this net takes 20ns" would be more obvious | 20:33 |
| daveshah | The problem is that for something like this, the failure is for a whole path rather than a single net | 20:35 |
| aep | hm yeah. i still have no idea where the problem is. | 20:37 |
| *** kristianpaul has quit IRC | 20:53 | |
| *** kristianpaul has joined #yosys | 20:54 | |
| *** emeb_mac has joined #yosys | 21:14 | |
| *** indy has quit IRC | 22:29 | |
| *** indy has joined #yosys | 22:49 | |
| *** emeb has quit IRC | 23:34 | |
| *** pepijndevos_ has quit IRC | 23:40 | |
| *** pepijndevos has joined #yosys | 23:41 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!