07:27 <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:27 <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.

09:33 <_whitenotifier-3> [sv-tests] dalance opened issue #577: Undefined macro usage - https://git.io/JvLz1

12:24 <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:27 <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:48 <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:48 <daveshah> I'll have a look at the PLL naming issue later

12:49 <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:52 <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:54 <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:54 <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:55 <daveshah> It may well be when you sort out the UART it will route fine

12:59 <daveshah> Xiretza: btw, what is the arc that is failing to route?

13:02 <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:04 <Xiretza> one sec

13:06 <Xiretza> daveshah: https://misc.xiretza.xyz/repro/router2_failed_to_route.tar.gz

13:06 <daveshah> Thanks!

13:14 <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:19 <Xiretza> daveshah: ah, those are actually usually routed through OBUFDS, but I commented those out since they're not supported yet

13:19 <daveshah> I think they should be supported

13:20 <daveshah> The problem is specifically the TMDS_33 IO tyoe

13:20 <Xiretza> oh okay, I think I remember nextpnr saying it doesn't have any OBUFDS sites

13:20 <daveshah> I might be able to patch that though

13:26 <Xiretza> daveshah: FYI, there's some more mentions of _BASIC in pack_clocking_xcup.cc and README.md.

13:26 <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:40 <daveshah> Xiretza: clock routing issue is now fixed in router2 upstream

13:49 <Xiretza> daveshah: awesome, thanks! I'll try that in a bit.

14:35 <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:35 <daveshah> No, not currently

14:36 <daveshah> The timing data is still a bit ropey so I wouldn't read too much into it anyway

14:36 <Xiretza> alright, I'll just ignore it then

16:26 <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:29 <daveshah> and yes, the VPR flow is probably the better choice if you care about timing atm

16:33 <Xiretza> mithro: VPR = Verilog to Routing? I guess that would work, I can use yosys to transform VHDL to verilog

16:34 <mithro> Xiretza: are you working on microwatt or some other VHDL?

16:34 <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:35 <daveshah> You still use Yosys for synthesis

16:38 <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:43 <mithro> tmichalak: In those diagrams you shared around placement - is there a way to "color" the resource usage in a way?

16:55 <daveshah> Xiretza: in any case, nextpnr-xilinx now has basic xdc create_clock support

16:56 <Xiretza> daveshah: wow, thanks!

16:56 <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:57 <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:04 <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:13 <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:13 <mithro> tmichalak: I'm only like 30% confident

17:20 <sf-slack1> <tmichalak> mithro: I will look into that

18:38 <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:40 <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:42 <ZirconiumX> ...Are you sure that's not just, say, the global clock?

18:43 <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:44 <litghost> hackerfoo: If the runtime is the same or less, and the critical path is the same or better, sure

18:44 <hackerfoo> Okay. I'll make a PR to see how it performs on CI.

18:46 <litghost> hackerfoo: Yep

21:48 <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

22:55 <hackerfoo> `make -j picosoc_bin` (ice40) fails locally. VPR spent ~120s each on 731 & 3248 fan out nets.

23:07 <litghost> With `--router_high_fanout_threshold`?

23:12 <hackerfoo> With the flag removed. The default is 64.

23:12 <litghost> Ya

23:17 <hackerfoo> Only a few seconds with it set back to `-1`, and it routes. So it will need to remain set for ice40.