01:13 <_whitenotifier-f> [fpga-tool-perf] HackerFoo opened issue #175: Upstream Yosys bug hit by bex_vivado-yosys_arty - https://git.io/JfjZl

12:26 <_whitenotifier-f> [symbiflow-arch-defs] kkumar23 opened issue #1553: Branch Quicklogic : The latest global clock support has issues - https://git.io/JfjPH

12:29 <_whitenotifier-f> [symbiflow-arch-defs] kkumar23 opened issue #1554: Branch Quicklogic : The no of PB-5XGMUX available shows only 1. - https://git.io/JfjPF

16:03 <_whitenotifier-f> [XilinxUnisimLibrary] mithro opened issue #1: Make the files consistently formatted - https://git.io/Jfj5d

16:04 <_whitenotifier-f> [XilinxUnisimLibrary] mithro opened issue #2: Convert the UniSim models to be compatible with Icarus Verilog - https://git.io/Jfj5b

16:05 <_whitenotifier-f> [XilinxUnisimLibrary] mithro opened issue #3: Document IP which requires secure IP that isn't included - https://git.io/Jfj5A

16:14 <tnt> kgugala: Mm, I just tried instanciating a logic_cell_macro and ... it built, but it didn't implement what I asked.

16:15 <tnt> it split it into its components (b_frag/t_frag/q_frag/f_frag/...) and placed those independently which kind of defeats the point.

17:31 <tnt> cell hold time 494513024.000 494513024.000

20:37 <tnt> Any wait to run timing analysis "a posteriori" (ie. once built alredy) and giving a regexp for the endpoint ?

20:39 <litghost> tnt: Assuming you are using a VPR toolchain, the answer to the first question is "yes", the --analysis flag

20:40 <litghost> tnt: It will by default output the worst setup/hold slacks in the the details reports

20:40 <litghost> tnt: You can control how many it outputs, I don't believe it has a filter, but the report generation is usually very fast

21:09 <tnt> litghost: ok, thanks

21:22 <tnt> I'm a bit surprised by the results though ... I ask for 2000 path and I get only 554 path. And there is definitely more unique combinations of StartPoint / EndPoint than that.

21:23 <tnt> Is there some deduplication ? Like it only shows the slowest past for a given Endpoint or something ?

21:42 <litghost> tnt: No if you ask for more paths than exist, it should provide all of them

21:43 <litghost> tnt: In this case, I believe you might be missing a timing constraint, and/or a timing model in the arch

21:43 <litghost> tnt: E.g. If you know of a timing arc that is missing, you should be able to see if the launch or capture constraint is captured

21:47 <tnt> It definitely must be constrained because it's all within one clock domain and other path are present. But like I have an adder (a + 1) whose output drives a ram block address input. Given all the LSBs a will influence the MSB (if there is carry), there should be paths from all bits of 'a' to the msb of the address.

21:47 <tnt> And there just isn't ... there is only some of them.

21:48 <litghost> tnt: If there is missing combinational annotations on the carry block, it could result in missing paths

21:49 <litghost> tnt: You can ask VPR to output the timing graph, which is usually way overkill, but you could trace the path you believe should exist, and determine where the path is "broken"

21:50 <litghost> tnt: For example, if there is a missing T_setup on a capture pin, then that arc wouldn't appear in the report

21:50 <litghost> tnt: Or as I suggested above, if there is a missing combinational delay through a box, then the arc wouldn't appear

21:51 <tnt> But there is like bit 0 of the source reg to bit [7] of the ram address ... but not bit 1 for instance ... both come from the same type of registers, I don't see why one would work and not the other.

21:52 <litghost> tnt: Is there a T_setup constraint on both bit[7] and bit[1] in the relevant pb_type?

21:53 <litghost> tnt: Or is bit[1] a constant path, in which case there is no launch to be captured?

21:54 <tnt> Nope

21:55 <tnt> I outputed the timing .dot ... but it's unreadable, way too big to load in anything.

21:56 <litghost> tnt: I wouldn't recommend visualizing it. But if you know of a timing arc that should exist, you might be able to trace the graph edges

21:56 <tnt> Also it doesn't contain net names ...

21:56 <litghost> tnt: I don't typically look at the timing graph, it is quiet a mess.

21:57 <litghost> tnt: Something you might consider is a smaller input netlist that exhibits the problem?

21:57 <litghost> tnt: So you can simply have fewer edges to trace?

22:22 <_whitenotifier-f> [conda-packages] litghost opened issue #114: uhdm-integration takes more than 1+ hr to complete? - https://git.io/JJekG

22:23 <FFY00> is there anything else that would make sense to add here? https://github.com/FFY00/symbiflow-arch-pkgs/issues/1

22:23 <tpb> Title: Add packages · Issue #1 · FFY00/symbiflow-arch-pkgs · GitHub (at github.com)

23:12 <_whitenotifier-f> [yosys-symbiflow-plugins] FFY00 opened issue #20: Build system tries to create a file on the system during the build step - https://git.io/JJeIQ

23:14 <_whitenotifier-f> [yosys-symbiflow-plugins] FFY00 opened issue #21: Build system does not respect `DESTDIR` - https://git.io/JJeIx

23:33 <_whitenotifier-f> [prjxray] FFY00 opened issue #1376: Allow building with unvendored dependencies - https://git.io/JJeLn