00:22 <mithro> Looks like we currently need a zybo harness in prjxray-db ?

00:31 <litghost> mithro: I actually thought we already had one.

00:32 <litghost> mithro: I'd hate to gate merging a patch because we don't have autoformatting

00:32 <mithro> No harness directory in https://github.com/SymbiFlow/prjxray-db/tree/master/zynq7

00:32 <tpb> Title: prjxray-db/zynq7 at master · SymbiFlow/prjxray-db · GitHub (at github.com)

00:32 <litghost> mithro: Ya, I saw that too

00:32 <mithro> litghost: Doing that now

00:33 <mithro> (Generating the harness that is)

00:33 <litghost> right

00:33 <litghost> You might need to shrink the harness away from the IOB tiles

00:33 <litghost> But try it and see if the harness still generates

00:36 <mithro> https://github.com/SymbiFlow/prjxray/issues/703

00:36 <tpb> Title: Building roi_harness for zybo fails · Issue #703 · SymbiFlow/prjxray · GitHub (at github.com)

00:38 <litghost> Ya, move the grid away from the IOB's

00:39 <litghost> Nvm, that isn't the issue

00:39 <litghost> Are you generating the harness with the zync db populated?

00:40 <mithro> I did it with whatever is the latest content in the published db

00:40 <litghost> Which unknown bit is in that base address?

00:40 <litghost> Ah

00:40 <litghost> Any change the BUFG drivers are in the ROI?

00:41 <litghost> Or the near the ROI, like 1 or 2 columns?

00:41 <litghost> chance*

00:41 <litghost> Because that error is saying that the ROI address range contains some unknown features, and in some cases symbiflow might zero them

00:42 <litghost> That address range corrisponds with the clock column

00:43 <litghost> Just double checked tilegrid, that base address does not contain a BUFG

00:43 <litghost> So there must be a bit in either the BUFG_REBUF or CLK_HROW_TOP_R we don't understand

00:45 <litghost> mithro: Attach the design.fasm or copy/paste the unknown features

00:45 <litghost> To https://github.com/SymbiFlow/prjxray/issues/703

00:45 <tpb> Title: Building roi_harness for zybo fails · Issue #703 · SymbiFlow/prjxray · GitHub (at github.com)

00:59 <mithro> litghost: Attached

01:00 <mithro> litghost: Took me a while to figure out how to copy the file to a computer I could upload on and then figure out a file format github would accept

01:01 <litghost> mithro: Opps

01:04 <mithro> litghost: Do you know if the "WARNING: [Vivado 12-3286] Net, clk, could not be marked fixed. The net is either fully contained within a site or is unrouted." are normal?

01:05 <litghost> I do not know

01:07 <mithro> litghost: I have discovered an issue in the way I'm doing the Info.md -- it is hard to tell when the zynq db was last updated....

01:08 <litghost> mithro: I'm pretty certain it isn't an old DB. The relevant bit is just missing, meaning a problem with the fuzzer

01:09 <mithro> litghost: Looks like I get that warning with the artix7 harness too

01:16 <mithro> litghost: I think I just fail at using github...

01:18 <mithro> litghost: Looks like there are no CLK_HROW_CK_IN_L5 lines in the zynq7 at all...

01:18 <litghost> I noticed that too

01:18 <litghost> Like I said, probably a fuzzer bug.

01:20 <litghost> I think I disabled the IN_L5 fuzzing on zync because there were no MMCM or PLL's on that side of the chip, which was how I was fuzzing the L side pips. If we need the L side pips, then we'll have to use IOB's on the left side

01:20 <litghost> which is annoying

01:25 <litghost> Ya, I disabled the L side pips in https://github.com/SymbiFlow/prjxray/commit/bd42b809a4bd205814366f089dca33864cfc5c16

01:25 <tpb> Title: Limit target pips on zync to avoid unsolvable bits. · SymbiFlow/prjxray@bd42b80 · GitHub (at github.com)

01:25 <litghost> Maybe that was a mistake

01:26 <mithro> litghost: btw it looks like you always mispell zynq as zync :-P

01:30 <mithro> litghost: Removing that filter and the fuzzer still seems to run?

01:33 <mithro> litghost: Doesn't look like it solves any more bits however...

02:04 <mithro> litghost: How did you generate the "# In frame 0x0000139a 3 bits were not converted." bit?

02:31 <mithro> litghost: Adding the bits from the artix7 into zynq7 doesn't seem to solve the missing bits in the design

16:19 <mithro> kgugala / acomodi: What is the status of stuff on zynq? It seems I can't generate a harness at the moment?

16:24 <mithro> https://github.com/SymbiFlow/prjxray/issues/703

16:24 <tpb> Title: Building roi_harness for zybo fails · Issue #703 · SymbiFlow/prjxray · GitHub (at github.com)

16:32 <sf-slack1> <acomodi> Hi mithro: we are still working on the ROI harness minitest for the zynq that will enable UART through a PMOD and the leds

17:19 <sf-slack1> <acomodi> litghost: quick question about DRAMS: if a SLICEM is in DRAM mode some of its LUTs (except for LUTD) can operate in LUT mode right? This because I have seen that when using SLICEMs for carry chain, they do operate in `DRAMs` mode, but all the LUTs in SLICEM operate in `LUT` mode and none of them is actually a DRAM. I tried to remove the `LUT` mode from `ntemplate.N_dram.pb_type.xml` and SLICEM's were correctly

17:19 <sf-slack1> packed. This is not the solution, but at least I am sure of what is happening there now.

17:22 <litghost> acomodi: Correct. It appears the only requirement the hardware imposses is if any DRAM, D-LUT must be in RAM mode. Other 3 can be in any mode.

17:42 <sf-slack1> <kgugala> initial BEL timing fuzzer https://github.com/SymbiFlow/prjxray/pull/706

17:42 <tpb> Title: WIP: fuzzers: timings: add bel timing fuzzer by kgugala · Pull Request #706 · SymbiFlow/prjxray · GitHub (at github.com)

18:37 <litghost> mithro: I've formatted the SQL queries in https://github.com/SymbiFlow/symbiflow-arch-defs/pull/445

18:37 <tpb> Title: Initial SQLite3 XC7 routing graph implementation. by litghost · Pull Request #445 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

21:55 <mithro> litghost: 3,632,632 kB == 3.6 gigabytes?

21:56 <mithro> litghost: IE you might want to use better units :-P

23:20 <litghost> mithro: Ya, GB. That is the output from /usr/bin/time, not the best units.