00:01 <mithro> jake.mercer: I would suggest looking at the DSPs that Yosys now generates on something like VexRISCV and starting with those use cases...

06:41 <sf-slack> <office_deskjet> I have a Digilent Nexy A7 board with a XC7A100T-1CSG324C. I know the part is not explicitly supported, but how hard would it be to use Symbiflow for this part?

07:04 <hackerfoo> office_deskjet: We're still working on support for the full 50T. We plan on support for a 200T at some point, but we will need to improve performance a lot before that's feasible.

07:09 <sf-slack> <office_deskjet> hackerfoo: Is there some overlap between parts that works?

07:13 <hackerfoo> It should be easy to support different parts in the same family, but the computing resources required does not scale linearly with the size of the part.

07:16 <sf-slack> <office_deskjet> I'm not too familiar with FPGA synthesis, but I would assume basic comb and seq logic will work on 100T if it works on 50T

07:58 <hackerfoo> office_deskjet: To answer your original question, I believe it will require some significant work. If you want to help out, start looking at prjxray.

13:11 <mdv29> I was wondering if implementing in NextPNR some way to set relative timing constraints would be feasible (or even exists somehow). By that I mean setting one path to have a longer/shorter path than another and letting the optimizer figure it out. I am working on a project with asynchronous logic and something like that would be veyr helpful, and if it is is feasible I would be willing to take it

13:11 <mdv29> on as a project.

17:07 <_whitenotifier-e> [ideas] spth opened issue #38: Support Xilinx XC9500XL CPLD series - https://git.io/JePjs

17:37 <_whitenotifier-e> [symbiflow-arch-defs] acomodi opened issue #1182: PLL and BUFG need to be placed in the same clock row region - https://git.io/JePjA

17:43 <_whitenotifier-e> [symbiflow-arch-defs] acomodi opened issue #1183: Add capability to import tiles with capacity - https://git.io/JeXek

21:24 <hackerfoo> I built a new branch based on master+wip and merged my changes in, and that seems to have fixed the routing failures. Murax takes ~700 seconds to route on the full 50T. I'm running picosoc now.

21:27 <hackerfoo> It's hard to tell what changed. The diff outside what I've worked on is large, and VPR still spews errors ("no fanin", "impossible to route" from ABC), so I'm not sure what the problem was, other than I probably rejected a critical wip branch because it wouldn't merge cleanly.

22:00 <hackerfoo> Here's what I have so far on picosoc: https://gist.github.com/HackerFoo/d59bde3871452b8bfb44cf2a5401c447

22:00 <tpb> Title: routing-picosoc.txt · GitHub (at gist.github.com)

22:44 <hackerfoo> Finished in 2541 seconds.

22:51 <hackerfoo> Retrying with the latest master+wip