*** tpb has joined #symbiflow | 00:00 | |
*** tiwEllien has quit IRC | 00:11 | |
*** emily has quit IRC | 03:25 | |
*** citypw has joined #symbiflow | 03:31 | |
*** emily has joined #symbiflow | 03:34 | |
*** ZirconiumX has quit IRC | 04:30 | |
*** Vonter has quit IRC | 04:31 | |
*** ZirconiumX has joined #symbiflow | 04:32 | |
*** Vonter has joined #symbiflow | 04:34 | |
*** Bertl_oO is now known as Bertl_zZ | 04:38 | |
*** proteus-guy has joined #symbiflow | 04:58 | |
*** tpb has joined #symbiflow | 05:11 | |
*** sf-slack1 has joined #symbiflow | 05:38 | |
*** sf-slack has quit IRC | 05:43 | |
*** OmniMancer has joined #symbiflow | 07:24 | |
bunnie[m] | <Xiretza "mithro: I was asking less about "> I'm not officially affiliated with prjxray but if Xilinx came after me for the work I did documenting the bitstream encryption format and fuses, I'd view it as an opportunity to have an adult conversation with their lawyers about why they are wrong, and if they still disagree I would treat it as a solid opportunity to set a favorable legal precedent for future work like this; | 07:28 |
---|---|---|
bunnie[m] | and if that doesn't pan out, at least it will make a great awareness campaign for the need for future legal reforms to protect our rights and freedoms to learn and innovate. | 07:28 |
*** futarisIRCcloud has quit IRC | 07:41 | |
*** az0re has joined #symbiflow | 08:08 | |
*** tiwEllien has joined #symbiflow | 08:48 | |
*** az0re has quit IRC | 09:26 | |
*** rvalles_ has quit IRC | 09:34 | |
-_whitenotifier-3- [sv-tests] dalance opened issue #577: Undefined macro usage - https://git.io/JvLz1 | 09:35 | |
*** rvalles_ has joined #symbiflow | 09:48 | |
*** futarisIRCcloud has joined #symbiflow | 11:16 | |
*** Bertl_zZ is now known as Bertl | 12:06 | |
*** tiwEllien has quit IRC | 12:13 | |
Xiretza | daveshah: I think xilinx/pack_clocking_xc7.cc:39,40 should be {MMCME2,PLLE2}_BASE instead of _BASIC, no? with that changed it seems to work correctly, anyway :) | 12:25 |
Xiretza | also, I finally got to the point where my SoC gets through ghdl and yosys, but I end up with 10 global clocks - 6 of them are real, the others have cryptic clkbufmap.cc names, gotta try to find those. | 12:28 |
ZirconiumX | Yosys' naming is really not the best | 12:29 |
daveshah | Note that (with router2 anyway) both global buffer inputs and outputs will be shown as global clocks during routing - as both should be using dedicated resources | 12:49 |
daveshah | I'll have a look at the PLL naming issue later | 12:50 |
*** Bertl is now known as Bertl_oO | 12:50 | |
daveshah | 6 clock domains still seems like quite a few for the current state of nextpnr-xilinx, but that would be at the point of a useful benchmark for future development anyway | 12:50 |
Xiretza | daveshah: the Arty input clock, a core/bus clock, two graphics clocks (pixel+TMDS), two UART clocks (18.432 MHz from PLL which then gets divided down to RCLK according to UART registers) | 12:53 |
daveshah | That doesn't seem too bad - but I'd clock all the UART stuff off a single clock with enable rather than two UART clocks | 12:55 |
daveshah | I have a LiteX design with input, DDR3 memory, system, and ethernet clocks that works alright so it's not outside the realms of what may work | 12:55 |
Xiretza | daveshah: yeah, I need to rewrite the UART anyway, it was supposed to be a reproduction of the 16550, but just became a mess | 12:56 |
daveshah | It may well be when you sort out the UART it will route fine | 12:56 |
daveshah | Xiretza: btw, what is the arc that is failing to route? | 13:01 |
Xiretza | daveshah: 'Failed to route arc 82 of net 'io.clk_pixel', from SITEWIRE/BUFGCTRL_X0Y10/O to SITEWIRE/SLICE_X6Y92/CLKINV_OUT.' | 13:04 |
daveshah | Interesting, can you provide a JSON/XDC? I think what happens is that the clock placer chooses global buffer sites that conflict sometimes and it would be good to fix this | 13:05 |
Xiretza | one sec | 13:05 |
Xiretza | daveshah: https://misc.xiretza.xyz/repro/router2_failed_to_route.tar.gz | 13:07 |
daveshah | Thanks! | 13:07 |
*** freemint has joined #symbiflow | 13:12 | |
daveshah | Pushed the PLL name fix, looking at the BUFG routing now, I also note that TMDS_33 IO aren't supported yet, but might be possible if they don't require any extra config bits | 13:15 |
Xiretza | daveshah: ah, those are actually usually routed through OBUFDS, but I commented those out since they're not supported yet | 13:20 |
daveshah | I think they should be supported | 13:21 |
daveshah | The problem is specifically the TMDS_33 IO tyoe | 13:21 |
Xiretza | oh okay, I think I remember nextpnr saying it doesn't have any OBUFDS sites | 13:21 |
daveshah | I might be able to patch that though | 13:22 |
Xiretza | daveshah: FYI, there's some more mentions of _BASIC in pack_clocking_xcup.cc and README.md. | 13:27 |
daveshah | Thanks - btw I think the clocking issue is SRL related. You might be able to get further with -nosrl (generally SRL support is still experimental) | 13:28 |
daveshah | Xiretza: clock routing issue is now fixed in router2 upstream | 13:42 |
*** futarisIRCcloud has quit IRC | 13:46 | |
Xiretza | daveshah: awesome, thanks! I'll try that in a bit. | 13:50 |
*** tiwEllien has joined #symbiflow | 13:56 | |
Xiretza | daveshah: good news: the whole flow is working now! however, it still thinks some of my timings aren't met - is there a way to specify target frequencies per clock net? `create_clock` in the XDC isn't recognized (yet). | 14:36 |
daveshah | No, not currently | 14:37 |
daveshah | The timing data is still a bit ropey so I wouldn't read too much into it anyway | 14:37 |
Xiretza | alright, I'll just ignore it then | 14:37 |
*** tiwEllien has quit IRC | 15:22 | |
*** tiwEllien has joined #symbiflow | 15:25 | |
*** OmniMancer has quit IRC | 15:28 | |
mithro | Xiretza: FYI - The vpr flow supports timing + sdc but that is only Series 7 | 16:28 |
daveshah | This is series 7 (Artix-7) | 16:30 |
daveshah | and yes, the VPR flow is probably the better choice if you care about timing atm | 16:30 |
*** tiwEllien has quit IRC | 16:33 | |
Xiretza | mithro: VPR = Verilog to Routing? I guess that would work, I can use yosys to transform VHDL to verilog | 16:35 |
mithro | Xiretza: are you working on microwatt or some other VHDL? | 16:35 |
Xiretza | mithro: nope, my own, school project | 16:35 |
mithro | Xiretza: be warned that VPR is as heavy as vivado rather than nice and light like nextpnr at the moment | 16:36 |
daveshah | You still use Yosys for synthesis | 16:37 |
Xiretza | mithro: alright - maybe I'll have a look at it in the future, but I don't really need accurate timing, mostly focussed on getting stuff to work at the moment. | 16:39 |
mithro | tmichalak: In those diagrams you shared around placement - is there a way to "color" the resource usage in a way? | 16:44 |
*** freemint has quit IRC | 16:45 | |
*** freemint has joined #symbiflow | 16:46 | |
daveshah | Xiretza: in any case, nextpnr-xilinx now has basic xdc create_clock support | 16:57 |
Xiretza | daveshah: wow, thanks! | 16:57 |
daveshah | btw, it's the post-route timing numbers that matter - the pre-route timing numbers often under-estimate Fmax by a factor of 2 or so, this is a known issue | 16:58 |
daveshah | propagation of constraints across BUFGs and PLLs isn't implemented either yet, so you'll probably want to be constraining with get_nets rather than get_ports | 16:58 |
Xiretza | yeah, I've noticed that pre-route fmax are way lower - just makes post-routing feel so much better ;) | 17:00 |
sf-slack1 | <tmichalak> mithro: do you mean coloring it in a way similar to what you did in the google doc I shared today? | 17:05 |
mithro | tmichalak: Yeah, wondering if there is a way to color the litedram / vexriscv / etc parts and see if my random guesses are correct | 17:14 |
mithro | tmichalak: I'm only like 30% confident | 17:14 |
sf-slack1 | <tmichalak> mithro: I will look into that | 17:21 |
*** tiwEllien has joined #symbiflow | 17:22 | |
*** citypw has quit IRC | 17:48 | |
hackerfoo | litghost: I tried `--router_high_fanout_threshold 64`, and routing picosoc on the full 50T wasn't any slower. Should we enable this? | 18:39 |
litghost | Are there even nets with a fanout of 64? | 18:42 |
hackerfoo | Yes. The highest fanout is 993, according to route_profiling output. | 18:43 |
ZirconiumX | ...Are you sure that's not just, say, the global clock? | 18:44 |
daveshah | There's also probably a reset | 18:44 |
hackerfoo | Maybe, but I also have fanouts of 64, 65, 68, 77, 82, 83, 85-7, 153, 160, 397 & 543 | 18:45 |
litghost | hackerfoo: If the runtime is the same or less, and the critical path is the same or better, sure | 18:45 |
hackerfoo | Okay. I'll make a PR to see how it performs on CI. | 18:46 |
litghost | hackerfoo: Yep | 18:47 |
*** tiwEllien has quit IRC | 19:47 | |
*** tiwEllien has joined #symbiflow | 19:51 | |
*** tiwEllien has quit IRC | 20:07 | |
*** tiwEllien has joined #symbiflow | 20:50 | |
*** proteus-guy has quit IRC | 21:20 | |
hackerfoo | Seems like VPR fails to route picosoc on ice40 without the flag. I'm rerunning the test locally to see if I can figure out why, but it might have to be set for that architecture. | 21:49 |
litghost | hackerfoo: I'm fine with setting that on a per arch basis | 21:51 |
hackerfoo | `make -j picosoc_bin` (ice40) fails locally. VPR spent ~120s each on 731 & 3248 fan out nets. | 22:57 |
litghost | With `--router_high_fanout_threshold`? | 23:09 |
hackerfoo | With the flag removed. The default is 64. | 23:13 |
litghost | Ya | 23:13 |
*** tiwEllien has quit IRC | 23:14 | |
*** freeemint has joined #symbiflow | 23:14 | |
*** freemint has quit IRC | 23:15 | |
*** freeemint has quit IRC | 23:15 | |
*** freeemint has joined #symbiflow | 23:16 | |
*** freeemint has quit IRC | 23:17 | |
*** freeemint has joined #symbiflow | 23:17 | |
*** freemint has joined #symbiflow | 23:18 | |
hackerfoo | Only a few seconds with it set back to `-1`, and it routes. So it will need to remain set for ice40. | 23:18 |
*** freemint has quit IRC | 23:23 | |
*** freemint has joined #symbiflow | 23:24 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!