00:00 <sf-slack1> <cjearls> Speaking of that, is there something special that needs to be done to get antlr working? I've never had antlr work with any of the projects in symbiflow-examples

01:04 <mithro> cjearls: Do you have a github issue?

01:06 <sf-slack1> <cjearls> I haven't made one yet, it fell back to the Python script, so everything was still working. When I get the chance, I'll submit one

01:10 <mithro> cjearls: I think I got distracted with other stuff -- I was working on getting it packaged up all properly in https://github.com/SymbiFlow/fasm/pull/64

01:12 <mithro> cjearls: I forget where I got up to, I think I went yak shaving...

01:13 <mithro> cjearls: I ended up getting https://github.com/SymbiFlow/symbiflow-rr-graph/commits/master packaged and published on PyPi

01:15 <mithro> cjearls: https://github.com/SymbiFlow/actions#examples

01:31 <mithro> cjearls: Not enough hours in the day apparently....

01:32 <sf-slack1> <cjearls> I see. So is it fixed, or will it be fixed soon?

01:34 <mithro> cjearls: I think it was more "I was in the process of fixing it but got distracted and can't remember were I got too..."

01:36 <sf-slack1> <cjearls> Ok, that makes sense

01:37 <mithro> Looks like Mac + Linux were mostly working

01:37 <mithro> but Windows seems unhappy -> https://github.com/SymbiFlow/fasm/pull/64/checks?check_run_id=2055039242#step:8:3346

01:39 <mithro> cjearls: It looks like past me actually logged some github issues about various things -> https://github.com/SymbiFlow/fasm/issues

01:40 <mithro> I'm going to call it a night

01:41 <sf-slack1> <cjearls> Alright, thanks for your help

07:13 <sf-slack1> <acomodi> mithro: prjxray-db update looks fine, apart from an unrelated minor instability to the PCIE pips which is straightforward to fix, I'll open an issue about that

07:17 <_whitenotifier-3> [prjxray] acomodi opened issue #1665: PCIE interface PIPs instability - https://git.io/J3rth

12:02 <mithro> acomodi / cjearls: I reverted the PCIE PIPs file and pushed it to master

16:46 <sf-slack1> <cjearls> Ok, the issue appears to be fixed. I'm following the prjxray build instructions, but when I run settings/artix7.sh, I'm getting an error `AssertionError: Mapping file /home/cjearls/prjxray/settings/artix7/resources.yaml does not exists` . Any idea what could be going wrong?

16:48 <sf-slack1> <acomodi> @cjearls i think you need to run the database prepare step before sourcing the settings file

16:49 <sf-slack1> <cjearls> I've been following every step o fthe Quickstart Guide here https://symbiflow.readthedocs.io/en/latest/prjxray/docs/db_dev_process/readme.html Is there something I am supposed to do before this?

16:49 <tpb> Title: Project X-Ray SymbiFlow (at symbiflow.readthedocs.io)

16:50 <sf-slack1> <acomodi> Try to run step 7 and than step 6

16:51 <sf-slack1> <acomodi> I think the readme needs an update

16:52 <sf-slack1> <cjearls> It looks to be doing something, I think that was the answer

16:52 <sf-slack1> <cjearls> Thanks

16:57 <sf-slack1> <cjearls> Yep, it's working

17:11 <sf-slack1> <cjearls> How can I know if a package is fully bonded? I'm trying to add xc7a35tftg256-1, but the guide to add a new device to an existing family says to choose a fully bonded package. Is that just the package in the resources.yaml with the most pins listed under it?

23:47 <calphool> mithro -- you replied to my questions about timing analysis by mentioning that the place and route process honors SDC files, but that's not quite what I was asking, related, but not quite the same thing. In Quartus (and I assume other proprietary suites), you specify your SDC constraints, and it uses those as it's doing place and route, but then

23:47 <calphool> it *also* reports anywhere where it was unable to guarantee those constraints due to things that aren't really observable (generally we think of temperature, but I think it could be anything that the chip manufacturer wanted to put in the silicon that could cause variability). In other words, although I might say "this net must have 5ns response

23:47 <calphool> time" or whatever, only the silicon producer would know if the route selected can accomplish that across the chip's entire rated temperature range... or at least that's what I always thought -- I didn't think that that "manufacturing variability" was public. Of course you guys know a lot more about this stuff than I do, but if I was going to try

23:47 <calphool> to advocate that my team switch to the Symbiflow pipeline, I suspect that'll be one of the things that I'll get asked: "what about timing/temperature analysis after place and route?"

23:48 <mithro> calphool: For Xilinx parts we support pulling designs back into Vivado so you can double check the timing in Vivado

23:52 <calphool> Oh, okay.  So the "response" to that "concern" would be "quit worrying about timing analysis until you're closer to delivery, and then you can import your design into Quartus for final checks" or something like that.

23:52 <calphool> ...I should say timing/temperature analysis.  I get that basic timing is guaranteed by the place and route.

23:57 <calphool> I'll have to try using the tool chain a bit on my own for a while... what I would really like to see is parity between what the software guys do in their dev pipelines and what we're doing on the hardware side -- all kinds of quality checks, linters, enforced unit tests, and so on, every time they change *anything*.  The Symbiflow projects seem

23:57 <calphool> like they could take us closer to that direction.  It just feels weird that hardware engineering is so manual compared to what they do on the software side.