| *** tpb has joined #symbiflow | 00:00 | |
| *** hzeller has quit IRC | 00:38 | |
| *** hzeller has joined #symbiflow | 00:51 | |
| *** _whitelogger has quit IRC | 01:13 | |
| *** _whitelogger has joined #symbiflow | 01:16 | |
| mithro | Just FYI - https://github.com/YosysHQ/yosys/pull/905 | 01:33 |
|---|---|---|
| tpb | Title: WIP: Feature/python bindings by christian-krieg · Pull Request #905 · YosysHQ/yosys · GitHub (at github.com) | 01:33 |
| *** hzeller has quit IRC | 01:42 | |
| *** hzeller has joined #symbiflow | 01:51 | |
| *** hzeller has quit IRC | 02:16 | |
| *** citypw has joined #symbiflow | 03:18 | |
| *** _whitelogger has quit IRC | 03:25 | |
| *** _whitelogger has joined #symbiflow | 03:28 | |
| *** Bertl is now known as Bertl_zZ | 04:05 | |
| *** proteusguy has joined #symbiflow | 04:29 | |
| *** citypw has quit IRC | 05:03 | |
| *** citypw has joined #symbiflow | 05:13 | |
| *** _whitelogger has quit IRC | 05:49 | |
| *** proteusguy has quit IRC | 05:51 | |
| *** _whitelogger has joined #symbiflow | 05:52 | |
| *** Maya-sama has joined #symbiflow | 06:09 | |
| *** Miyu has quit IRC | 06:12 | |
| *** OmniMancer has joined #symbiflow | 06:44 | |
| *** proteusguy has joined #symbiflow | 06:53 | |
| *** kraiskil has joined #symbiflow | 07:01 | |
| *** _whitelogger has quit IRC | 07:37 | |
| *** _whitelogger has joined #symbiflow | 07:40 | |
| *** kraiskil has quit IRC | 07:54 | |
| *** kraiskil has joined #symbiflow | 08:06 | |
| *** Maya-sama is now known as Miyu | 08:48 | |
| *** kraiskil has quit IRC | 09:37 | |
| *** kraiskil has joined #symbiflow | 09:53 | |
| *** citypw has quit IRC | 10:08 | |
| *** futarisIRCcloud has quit IRC | 10:47 | |
| *** proteusguy has quit IRC | 11:30 | |
| *** citypw has joined #symbiflow | 11:42 | |
| *** ayumis13 has joined #symbiflow | 12:06 | |
| *** ayumis13 has quit IRC | 12:10 | |
| *** Bertl_zZ is now known as Bertl | 13:19 | |
| *** OmniMancer has quit IRC | 13:49 | |
| *** hzeller has joined #symbiflow | 14:05 | |
| *** proteusguy has joined #symbiflow | 14:16 | |
| sf-slack | <mkurc> elms: FYI regarding the `scalable_proc` test design: It can be implemented on ICE40 arch directly provided that you use the BRAM mode. In the BRAM mode the data is stored in an initialized Verilog array. There is also a DRAM mode in which the data is stored in explicitly instantiated Xilinx DRAMs. | 14:32 |
| *** proteusguy has quit IRC | 14:42 | |
| sf-slack | <mkurc> Status update: I am implementing a generic tile grid coordinate mapping to be used later for splitting CLBs into SLICEs. For now it will handle just arbitrary tile relocation without splitting etc. | 14:55 |
| *** hzeller has quit IRC | 14:56 | |
| sf-slack | <kgugala> @mithro I checked the git-blame-ignore-revs and to add it we actually need to commit the formatting results | 15:03 |
| *** hzeller has joined #symbiflow | 15:03 | |
| sf-slack | <kgugala> (we need to put formatting result hash into ignore file) | 15:03 |
| sf-slack | <kgugala> it is done here https://github.com/antmicro/libblifparse/commits/run-format | 15:04 |
| tpb | Title: Commits · antmicro/libblifparse · GitHub (at github.com) | 15:04 |
| sf-slack | <kgugala> shall I close this PR https://github.com/kmurray/libblifparse/pull/2 and open a new one with formatting results? | 15:04 |
| tpb | Title: Add format target for source code formatting by kgugala · Pull Request #2 · kmurray/libblifparse · GitHub (at github.com) | 15:04 |
| sf-slack | <kgugala> or maybe we'll wait for kem_ to merge the format target, run and commit formatting and then add ignore | 15:05 |
| sf-slack | <kgugala> ? | 15:05 |
| sf-slack | <acomodi> Hi everyone. I have started again the approach on the equivalent tiles as I think I was taking a wrong direction. Right now I have been able to change the XML architecture parsing and moved the top level pb_type only features and properties to the `tiles`. CI will fail because all the XML archs in `vtr_flow/archs` do not have a `tiles` top level tag. Here's the updated PR: | 15:30 |
| sf-slack | https://github.com/SymbiFlow/vtr-verilog-to-routing/pull/36 | 15:30 |
| tpb | Title: WIP: Equivalent tiles VTR feature by acomodi · Pull Request #36 · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com) | 15:30 |
| sf-slack | <acomodi> litghost, mithro: I am planning to use the same data structure present in VTR right now (probably I'll rename it) to represent the tile (currently it is the `t_type_descriptor`). This struct has everything the tile needs and it previously stored the top level pb_type information. | 15:34 |
| sf-slack | <acomodi> Moreover, previously today I have updated https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/513 with additional information | 15:35 |
| tpb | Title: Support Equivalent Placement Sites · Issue #513 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 15:35 |
| *** hzeller has quit IRC | 15:40 | |
| *** hzeller has joined #symbiflow | 15:41 | |
| *** hzeller has quit IRC | 16:04 | |
| elms | mkurc: thanks. I started looking at it yesterday but pretty late in the day. | 16:24 |
| *** citypw has quit IRC | 16:24 | |
| *** kraiskil has quit IRC | 18:07 | |
| *** hzeller has joined #symbiflow | 18:27 | |
| litghost | acomodi: Do you need help writing the comments per https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/517#issuecomment-479609302 ? | 18:47 |
| tpb | Title: Mode selection feature by acomodi · Pull Request #517 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 18:47 |
| hackerfoo | I (seriously) enjoy reading well-written hardware documentation. I wish software documentation was more like it. | 19:26 |
| duck2 | a good point. i sometimes procrastinate reading microcontroller datasheets, but not man pages or readthedocs. perhaps it's related to the difference between hw and sw projects | 19:33 |
| hackerfoo | man pages are good, but I don't like auto generated API docs. But with hardware documentation, I often learn something beyond what I need to solve my immediate problem. | 19:45 |
| hackerfoo | Especially with TI's documentation. | 19:45 |
| *** kraiskil has joined #symbiflow | 20:19 | |
| elms | hackerfoo: What exactly are you reading? | 20:22 |
| elms | There is definitely an art to good datasheets and app notes. But the variance is large in my experience. | 20:23 |
| hackerfoo | Just the Xilinx 7-series stuff right now, but it reminded me how much I prefer datasheets over software documentation, if nothing else just for the pictures to break up the text. | 20:24 |
| elms | Just listened to an amp hour podcast with Adam McCombs and they discuss that one vendor has amazing databooks on their SEM but most other manufactures are barely existent. | 20:25 |
| elms | Agree. Having a human in the loop helps with readability. Some software APIs are generated and no one ever thinks to look at them. | 20:27 |
| hackerfoo | I tried using Doxygen, but writing takes a lot of time: https://hackerfoo.github.io/startle-docs/map_8c.html | 20:30 |
| tpb | Title: Startle: map.c File Reference (at hackerfoo.github.io) | 20:30 |
| hackerfoo | At least I added some examples. | 20:30 |
| hackerfoo | I find the tests to be the best documentation for most projects. | 20:32 |
| *** kraiskil has quit IRC | 21:00 | |
| mithro | hackerfoo: The idea is to eventually use Sphinx + possibly the existing Doxiverilog style | 21:01 |
| mithro | duck2: Do you have a Google Account? if so can you send me the email address I can share a Google Doc with? | 21:05 |
| duck2 | mithro: yes. [email protected] | 21:05 |
| mithro | duck2: Also, which timezone are you in? | 21:05 |
| duck2 | gmt+3 | 21:06 |
| mithro | duck2: https://docs.google.com/document/d/17fi01DX3M3rEBLz_CkIRyOMor7Gvd1nNUrnt3Q1Rd1w/edit | 21:06 |
| tpb | Title: VPR Data Structure IO serializer library - Google Docs (at docs.google.com) | 21:06 |
| mithro | duck2: That is what I was thinking... | 21:06 |
| duck2 | looking at it now | 21:07 |
| mithro | duck2: Still could be a terrible idea :-P | 21:11 |
| elms | litghost: Is it correct to think that configuration of non-routing features are essentially decided during the place step in VPR? | 21:12 |
| elms | Maybe I start with asking if there is a one-to-one relationship with features and particular steps in pack-place-route? | 21:14 |
| litghost | elms: non-routing features (e.g. within site) are decided during *pack* | 21:14 |
| litghost | elms: And yes, there is a 1-to-1 relationship. non-routing features are determined soley during pack, and routing features are determined during route | 21:15 |
| elms | litghost: and then in place they are associated with specific sites? | 21:15 |
| litghost | elms: place determins where the clusters are located within the grid | 21:15 |
| litghost | elms: So place does change where in the grid the cluster goes, but the particular features are constant | 21:16 |
| elms | how is that different from what I said. I think I'm missing a subtle detail | 21:16 |
| litghost | elms: I believe I'm agreeing with you? | 21:16 |
| elms | ok just making sure. Thanks | 21:16 |
| duck2 | mithro: i was thinking about making an XML parser generator for the arch file(ideas/#4), and complete flatbuffers support for rr_graph while revisiting its data structures(edge metadata is stored in a map from pair to string :O) | 21:19 |
| duck2 | i think you propose a generic serializer/deserializer? so that the libraries can be used from within symbiflow-arch-defs | 21:21 |
| mithro | duck2: I'm less concerned with reusing the libraries in symbiflow-arch-defs and more with have very efficient implementations for getting the data in and out of vpr in different file formats... | 21:24 |
| duck2 | should the serializer/deserializer work with all the formats in the Required formats section? | 21:27 |
| mithro | duck2: That would be the plan | 21:28 |
| mithro | duck2: Ones in bold are the most important | 21:29 |
| mithro | litghost: FYI - https://github.com/YosysHQ/yosys/pull/914 | 21:31 |
| tpb | Title: [WIP] synth_xilinx to now infer SRL16E/SRLC32E by eddiehung · Pull Request #914 · YosysHQ/yosys · GitHub (at github.com) | 21:31 |
| duck2 | so a generic schema file defines the data structures, then we generate readers/writers for all required formats and also stubs for the internal data structures. then vpr implements the data structures. | 21:32 |
| duck2 | just to get it right, for example, should the arch file then support XML, JSON, ASCII... formats via flags? or is it the responsibility of the build process to tell the generator to make only the XML reader/writer for it, since the arch file is known as an XML file? | 21:35 |
| mithro | duck2: vpr should support all the file formats and just choose the right one? | 21:36 |
| duck2 | depending on the file. like gimp. i see. but why should vpr support all XML, JSON, flatbuffers formats for an arch file? debugging? ease of generation by other programs? ease of handwriting? | 21:45 |
| mithro | duck2: Well, it needs human readable ASCII for debugging, XML for compatibility and a more efficient binary format for speed | 21:48 |
| *** Bertl is now known as Bertl_zZ | 21:57 | |
| duck2 | i see. i think a such library would be a little too generic. the project will be a library which takes a schema and generates readers/writers for many file formats. then it would be integrated into vpr. in my opinion, a specialized solution would be better: top.net, route and place files are small and work reasonably well. the arch file is also wor | 22:04 |
| duck2 | king but lacks extensibility. that can be fixed by using a schema-generated reader/writer. but the problem with rr_graph is different: an XML rr_graph is inflated(1gb rr_graph gzips to 52mb) and the format needs to be tuned for speed&memory usage. | 22:04 |
| mithro | duck2: For larger designs the .net and .route files can get into the gigabyte sizes too | 22:10 |
| mithro | The packed .net format also makes my brain hurt every time I try and read it :-P | 22:11 |
| mithro | duck2: I agree that the rr_graph file is the most important as it is 10x to 100x the size of the other files at the moment | 22:16 |
| mithro | hackerfoo: https://github.com/ewa/doxverilog/tree/master/Doxverilog2.7 | 22:17 |
| tpb | Title: doxverilog/Doxverilog2.7 at master · ewa/doxverilog · GitHub (at github.com) | 22:17 |
| duck2 | a mmapped format makes sense for rr_graph. it also removes the need for streamed reading. but making it isn't straightforward. for instance the current rr_graph reader doesn't read segment ids for nodes before indexing the node data. i think it would be a huge improvement too. | 22:22 |
| duck2 | all in all, i think improvements for the file formats could be done without writing a generic parser generator. custom binary formats for net, place, route and rr_graph can be created and utilities to inspect and edit them or convert them to readable format&back can be made. | 22:30 |
| hackerfoo | I use __attribute__((packed)) and static asserts to precisely control in-memory formats: https://github.com/HackerFoo/poprc/blob/master/rt_types.h#L306 | 22:33 |
| tpb | Title: poprc/rt_types.h at master · HackerFoo/poprc · GitHub (at github.com) | 22:33 |
| duck2 | this also saves us the trouble of deciding what an abstract schema element means in XML, in JSON, in ASCII... and much debugging effort to see if the _generated_ readers&writers produce expected results while, say, converting xml->ascii->xml | 22:33 |
| hzeller | +1. I think focusing on some new binary representation first is good and then focus on the readable and legacy formats be generated to/from this. The binary format probably needs to have some sort of stable API to get the data in/out and it can then have its own private binary representation. | 22:33 |
| hackerfoo | You should be able to use the same approach to ensure compatibility, and it's probably safe to assume little endian architectures and just add static asserts to deal with big endian when needed. | 22:34 |
| hzeller | the endianness then can be fixed at distribution time, making a specific format relevant for one platform. Or the mmap()ed version is platform indpendent with e.g. flatbuffers. Or it can be read with ntohl() etc. I'd not worry about endianness in the first iteration. | 22:36 |
| hackerfoo | If you can avoid any conversions, then you don't have to copy, which means you can just mmap read-only and let the OS swap in and out as needed. This means you should be able to work with much more than will fit in RAM, without having to implement some sort of custom paging scheme. | 22:38 |
| hackerfoo | I haven't tried this yet, but it should work in theory. | 22:39 |
| hzeller | yes, this is the idea. I've applied this technique to very fast large read-only data in the past. | 22:43 |
| duck2 | does the flatbuffers reader mmap to a struct ptr currently? or would i have to reinvent that? | 22:46 |
| litghost | duck2: flatbuffers can operate on mmap, but it does require using the library to access the data | 22:48 |
| litghost | duck2: It does some straight forward pointer chasing in the form of offsets | 22:48 |
| mithro | I think we have decent evidence that the cost of loading a rr_graph file from disk verses programmatically generating it in memory could be important for performance | 22:54 |
| mithro | memory bandwidth >>>> disk bandwidth | 22:56 |
| duck2 | it's one thing i don't understand in vpr: if it can make a rr_graph itself, why is there a rr_graph file? and vice versa | 22:56 |
| duck2 | sorry if sounds stupid :D | 22:56 |
| mithro | duck2: The rr_graph that vpr can generate doesn't exactly match real world hardware | 22:56 |
| mithro | duck2: It's an approximation that is close enough for doing research, but doesn't really work that well for real devices | 22:57 |
| mithro | duck2: Allowing vpr to be provided a prebuilt rr_graph allows it to be used for any arbitrary routing fabric | 22:58 |
| mithro | duck2: Make sense? | 22:59 |
| mithro | elms: Great work on getting the formatting / testing stuff for arch defs going again! | 23:00 |
| duck2 | i see. then we cannot generate a rr_graph in memory if it's supplied as a file. i thought you suggested part of the graph can be generated in memory after getting some information from the disk. | 23:00 |
| mithro | duck2: We need to always support loading an arbitrary rr_graph | 23:01 |
| mithro | duck2: But a potentially new file format could allow us to describe the rr_graph using a bunch of parameters and generate it in memory | 23:02 |
| elms | mithro: Thanks. Going to try and chip away at stuff like that. Maybe one or two more next week. Plan finish up adding more tests around the rr_graph python code. | 23:02 |
| duck2 | mithro: i think that can be a project on its own | 23:04 |
| duck2 | i'm updating my draft-draft to roughly this: schema-generated parser for arch.xml, flatbuffers/custom binary for rest of file formats | 23:06 |
| *** zkms has quit IRC | 23:26 | |
| *** zkms has joined #symbiflow | 23:30 | |
| *** zkms has quit IRC | 23:33 | |
| *** zkms has joined #symbiflow | 23:38 | |
| *** zkms has quit IRC | 23:39 | |
| *** zkms has joined #symbiflow | 23:41 | |
| *** zkms has quit IRC | 23:47 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!