20:13 <litghost> dan.ravensloft: About the constraints, I'm sure you are right, but I'm unclear how to express additional constraints on ABC9 via yosys. Is there documentation I missed around this?

20:15 <sf-slack4> <dan.ravensloft> The carry chain is integrated with the LUTs, right?

20:15 <litghost> Not sure what you mean by "integrated" in this context?

20:17 <sf-slack4> <dan.ravensloft> I'll try a different approach then: ABC9 thinks it can reduce delay by pruning the carry chain

20:17 <litghost> Sure, but by re-merging the LUT's/CARRY, it causes site congestion

20:18 <litghost> Especially in the case of a top of carry COUT

20:18 <litghost> Where the top of carry is effictively free if the CO[0] -> CIN -> O[0] path is used

20:18 <litghost> But from ABC9's perspective it is better to reduce the number of carry cells

20:20 <litghost> It does appear that https://github.com/SymbiFlow/symbiflow-arch-defs/pull/2082 is green, so ABC might be not doing anything bad anymore

20:20 <sf-slack4> <dan.ravensloft> If you look at iCE40, there's `$__ICE40_CARRY_WRAPPER` which joins carry cells and LUTs together into a single cell to represent to ABC9 that it must sweep *both* together.

20:20 <litghost> Ok, your suggestion is to form larger cells and not let ABC9 treat them as seperate cells

20:21 <sf-slack4> <dan.ravensloft> Because a box is an atomic "thing" to be removed

20:21 <litghost> Sure

20:21 <litghost> In this case, I think that isn't what we want. Let me try to explain

20:25 <litghost> So after the first synth_xilinx call, there is a valid carry chain and all it's LUTs, but on some levels of the chain, the CO/O outputs may be congested, depending on what is going on with output registration. The "fix_carry.py" applies a handful of transformations to ensure that the site outputs are never congested, but this sometimes means that a LUT is emitted where the CARRY4 block was. Ideally, theses

20:25 <litghost> post-carry LUTs would be eligible to be split/merged. Consider a path that looks like add chain (e.g. LUTs into CARRY4) followed by some LUTs and then into sequential logic. After the decongestion, the new path would be LUT -> CARRY4 -> LUT -> LUT. It's the stuff after the CARRY4 I'd like to eligible for analysis and potential merge/split.

20:43 <litghost> pingkan.wewengkang: Depends on what focus you want to have (E.g. part class and design types). We want some help around the new FPGA interchange format (see https://github.com/orgs/SymbiFlow/projects/22) and we are currently doing work on standing up PCIe on 7-series (

20:45 <litghost> pingkan.wewengkang: The 7-series DSP and XADC also need some help if either of those are interesting to you

21:51 <sf-slack4> <georgedanielmangum> Hey folks! Does anyone have experience with the linux-on-litex-vexriscv flow? I am having OpenSBI hang for me during boot and wanted to see if anyone would have insight to troubleshoot :)

23:12 <sf-slack4> <dan.ravensloft> @pingkan.wewengkang Alternatively, I could use a hand getting the Intel flow up and running.

23:13 <litghost> I didn't realize there was an intel database?

23:13 <litghost> Routing or bitstream

23:14 <sf-slack4> <dan.ravensloft> Bitstream

23:14 <sf-slack4> <dan.ravensloft> Including all routing pips

23:14 <sf-slack4> <dan.ravensloft> https://github.com/Ravenslofty/mistral