#symbiflow on 2021-03-23 — irc logs at freenode.irclog.whitequark.org

11:52 <sf-slack> <nils.albartus> Following up on my question yesterday, we went hunting down the missing bits in the zedboard database. As suggested I tried to locate the tile / column with the help of the `tilegrid.json` . Here is what I did: ```{ unknown_bit = "0042001a_16_7", unknown_segment = "0x00420000", unknown_segbit = "26_519" }``` First we checked `INT_L` , since the base address matched. The given seg_bits are `26_519` (or rather

11:52 <sf-slack> `26_07` ) which are not responsible for the tile anymore ((https://symbiflow.github.io/prjxray-db/zynq7/tile_int_l.html). so, this is not what we are looking for. is this correct so far? so we had a look at what else is starting at the baseaddr `0x00420000` and found `HCLK_IOI3_X1Y26` . looking at the database file `segbits_hclk_ioi3.db` we found a bunch of entries with segbits `26_XY` , but not `26_07` . So we currently

11:52 <sf-slack> assume that the missing bits are related to `HCLK_IOI3` . Is our assumption correct this far? if our assumption is correct, what would the next step be? i guess we need to look at fuzzer `047-hclk-ioi-pips` ? any tips on how to go on from here?

11:52 <tpb> Title: X-Ray ZYNQ7 Database: INT_L (at symbiflow.github.io)

12:04 <sf-slack> <acomodi> nils1994: So, I think that it is not the HCLK_IOI3 tile as that one is found at word offset == 50. In this case, your unknown bit is at word 16 (`0042001a_16_7` where `0042001a` is the base_address + frame in hex, 16 is the word in the frame, and 7 is the bit in the word)

12:06 <sf-slack> <acomodi> There are many different tiles found at that base address though, which include IOBs and IOIs

12:10 <sf-slack> <acomodi> If I were to guess, those unknowns might be related to those tiles

13:26 <sf-slack> <nils.albartus> mh okay. i guess than i am quite lost on how to start…

13:28 <sf-slack> <acomodi> So, the idea here is to be able first to identify what is causing these unknown bits. We know that they are in the area of the IOB/IOI/INT_L tiles in the bottom left clock region.

13:30 <sf-slack> <acomodi> Given that the same unknown bits appear in different words (as per in the snippet above) may be a hint that these are corresponding to a configuration parameter (this may be untrue, but it is just a hint)

14:34 <litghost> If that is near the IO column, it could just be IO standard stuff

14:34 <litghost> What IO standards are you using?

16:27 <_whitenotifier-4> [sv-tests] tgorochowik opened issue #1411: Kokoro doesn't always start - https://git.io/JmjDi

17:51 <mithro> I wonder how we do something like https://developers.redhat.com/blog/2019/10/14/introducing-debuginfod-the-elfutils-debuginfo-server/ for FPGA bitstreams...

17:51 <mithro> umarcor: thoughts -^

17:56 <umarcor> until now we have avoided debug symbols (not added them explicitly, unless created by default) because the main use case is CI. size matters because it has direct impact on startup and traffic.

17:57 <umarcor> however, we have full control of the build procedure for each tool, and we do already publish some 'pkg' images which contain artifacts. therefore, we might "easily" generate build symbols and distribute them there or elsewhere.

17:59 <umarcor> is debuginfod just a tool or also a service? i.e. do we need to setup our own debuginfod server?

18:04 <mithro> umarcor: Well there are two seperate things, running debuginfod for the FPGA tooling

18:04 <mithro> umarcor: Creating something like debuginfod for FPGA bitstreams

18:05 <umarcor> oh, sorry. I completely overlooked the "for FPGA bitstreams" part!

18:06 <mithro> umarcor: debuginfod is a protocol / server which takes basically locals debug symbols and then publishes them as a HTTP server

18:10 <mithro> umarcor: So it would be good if the FPGA tooling was build with "split debug symbols" and then the split debug symbols are saved somewhere and then published in a debuginfod compatible form.

19:00 <mithro> This is super cool -> https://aafigure.readthedocs.io/en/latest/sphinxext.html#quick-example

19:00 <tpb> Title: Sphinx aafigure 0.5 documentation (at aafigure.readthedocs.io)

19:06 <sf-slack> <mgielda> yeah, it's cool. pondered id for diagrams until I had to redraw one ;)

19:06 <sf-slack> <mgielda> *it

20:44 <mithro> litghost: I just discovered https://github.com/olsner/jobclient

20:48 <litghost> Huh, might be handy

21:01 <mithro> Also, rust implementation if anyone is interested -- https://docs.rs/jobserver/0.1.21/jobserver/

21:01 <tpb> Title: jobserver - Rust (at docs.rs)

21:50 <umarcor> mgielda: https://asciiflow.com is quite nice for text representation of diagrams

21:50 <tpb> Title: ASCIIFlow (at asciiflow.com)