Wednesday, 2019-04-03

*** tpb has joined #symbiflow00:00
*** hzeller has quit IRC00:38
*** hzeller has joined #symbiflow00:51
*** _whitelogger has quit IRC01:13
*** _whitelogger has joined #symbiflow01:16
mithroJust FYI -
tpbTitle: WIP: Feature/python bindings by christian-krieg · Pull Request #905 · YosysHQ/yosys · GitHub (at
*** hzeller has quit IRC01:42
*** hzeller has joined #symbiflow01:51
*** hzeller has quit IRC02:16
*** citypw has joined #symbiflow03:18
*** _whitelogger has quit IRC03:25
*** _whitelogger has joined #symbiflow03:28
*** Bertl is now known as Bertl_zZ04:05
*** proteusguy has joined #symbiflow04:29
*** citypw has quit IRC05:03
*** citypw has joined #symbiflow05:13
*** _whitelogger has quit IRC05:49
*** proteusguy has quit IRC05:51
*** _whitelogger has joined #symbiflow05:52
*** Maya-sama has joined #symbiflow06:09
*** Miyu has quit IRC06:12
*** OmniMancer has joined #symbiflow06:44
*** proteusguy has joined #symbiflow06:53
*** kraiskil has joined #symbiflow07:01
*** _whitelogger has quit IRC07:37
*** _whitelogger has joined #symbiflow07:40
*** kraiskil has quit IRC07:54
*** kraiskil has joined #symbiflow08:06
*** Maya-sama is now known as Miyu08:48
*** kraiskil has quit IRC09:37
*** kraiskil has joined #symbiflow09:53
*** citypw has quit IRC10:08
*** futarisIRCcloud has quit IRC10:47
*** proteusguy has quit IRC11:30
*** citypw has joined #symbiflow11:42
*** ayumis13 has joined #symbiflow12:06
*** ayumis13 has quit IRC12:10
*** Bertl_zZ is now known as Bertl13:19
*** OmniMancer has quit IRC13:49
*** hzeller has joined #symbiflow14:05
*** proteusguy has joined #symbiflow14: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 IRC14: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 IRC14:56
sf-slack<kgugala> @mithro I checked the git-blame-ignore-revs and to add it we actually need to commit the formatting results15:03
*** hzeller has joined #symbiflow15:03
sf-slack<kgugala> (we need to put formatting result hash into ignore file)15:03
sf-slack<kgugala> it is done here
tpbTitle: Commits · antmicro/libblifparse · GitHub (at
sf-slack<kgugala> shall I close this PR and open a new one with formatting results?15:04
tpbTitle: Add format target for source code formatting by kgugala · Pull Request #2 · kmurray/libblifparse · GitHub (at
sf-slack<kgugala> or maybe we'll wait for kem_ to merge the format target, run and commit formatting and then add ignore15: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
tpbTitle: WIP: Equivalent tiles VTR feature by acomodi · Pull Request #36 · SymbiFlow/vtr-verilog-to-routing · GitHub (at
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 with additional information15:35
tpbTitle: Support Equivalent Placement Sites · Issue #513 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
*** hzeller has quit IRC15:40
*** hzeller has joined #symbiflow15:41
*** hzeller has quit IRC16:04
elmsmkurc: thanks. I started looking at it yesterday but pretty late in the day.16:24
*** citypw has quit IRC16:24
*** kraiskil has quit IRC18:07
*** hzeller has joined #symbiflow18:27
litghostacomodi: Do you need help writing the comments per ?18:47
tpbTitle: Mode selection feature by acomodi · Pull Request #517 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
hackerfooI (seriously) enjoy reading well-written hardware documentation. I wish software documentation was more like it.19:26
duck2a 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 projects19:33
hackerfooman 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
hackerfooEspecially with TI's documentation.19:45
*** kraiskil has joined #symbiflow20:19
elmshackerfoo: What exactly are you reading?20:22
elmsThere is definitely an art to good datasheets and app notes. But the variance is large in my experience.20:23
hackerfooJust 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
elmsJust 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
elmsAgree. 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
hackerfooI tried using Doxygen, but writing takes a lot of time:
tpbTitle: Startle: map.c File Reference (at
hackerfooAt least I added some examples.20:30
hackerfooI find the tests to be the best documentation for most projects.20:32
*** kraiskil has quit IRC21:00
mithrohackerfoo: The idea is to eventually use Sphinx + possibly the existing Doxiverilog style21:01
mithroduck2: Do you have a Google Account? if so can you send me the email address I can share a Google Doc with?21:05
duck2mithro: yes. [email protected]21:05
mithroduck2: Also, which timezone are you in?21:05
tpbTitle: VPR Data Structure IO serializer library - Google Docs (at
mithroduck2: That is what I was thinking...21:06
duck2looking at it now21:07
mithroduck2: Still could be a terrible idea :-P21:11
elmslitghost: Is it correct to think that configuration of non-routing features are essentially decided during the place step in VPR?21:12
elmsMaybe I start with asking if there is a one-to-one relationship with features and particular steps in pack-place-route?21:14
litghostelms: non-routing features (e.g. within site) are decided during *pack*21:14
litghostelms: And yes, there is a 1-to-1 relationship.  non-routing features are determined soley during pack, and routing features are determined during route21:15
elmslitghost: and then in place they are associated with specific sites?21:15
litghostelms: place determins where the clusters are located within the grid21:15
litghostelms: So place does change where in the grid the cluster goes, but the particular features are constant21:16
elmshow is that different from what I said. I think I'm missing a subtle detail21:16
litghostelms: I believe I'm agreeing with you?21:16
elmsok just making sure. Thanks21:16
duck2mithro: 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
duck2i think you propose a generic serializer/deserializer? so that the libraries can be used from within symbiflow-arch-defs21:21
mithroduck2: 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
duck2should the serializer/deserializer work with all the formats in the Required formats section?21:27
mithroduck2: That would be the plan21:28
mithroduck2: Ones in bold are the most important21:29
mithrolitghost: FYI -
tpbTitle: [WIP] synth_xilinx to now infer SRL16E/SRLC32E by eddiehung · Pull Request #914 · YosysHQ/yosys · GitHub (at
duck2so 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
duck2just 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
mithroduck2: vpr should support all the file formats and just choose the right one?21:36
duck2depending 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
mithroduck2: Well, it needs human readable ASCII for debugging, XML for compatibility and a more efficient binary format for speed21:48
*** Bertl is now known as Bertl_zZ21:57
duck2i 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:, route and place files are small and work reasonably well. the arch file is also wor22:04
duck2king 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
mithroduck2: For larger designs the .net and .route files can get into the gigabyte sizes too22:10
mithroThe packed .net format also makes my brain hurt every time I try and read it :-P22:11
mithroduck2: 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 moment22:16
tpbTitle: doxverilog/Doxverilog2.7 at master · ewa/doxverilog · GitHub (at
duck2a 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
duck2all 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
hackerfooI use __attribute__((packed)) and static asserts to precisely control in-memory formats:
tpbTitle: poprc/rt_types.h at master · HackerFoo/poprc · GitHub (at
duck2this 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->xml22: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
hackerfooYou 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
hzellerthe 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
hackerfooIf 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
hackerfooI haven't tried this yet, but it should work in theory.22:39
hzelleryes, this is the idea. I've applied this technique to very fast large read-only data in the past.22:43
duck2does the flatbuffers reader mmap to a struct ptr currently? or would i have to reinvent that?22:46
litghostduck2: flatbuffers can operate on mmap, but it does require using the library to access the data22:48
litghostduck2: It does some straight forward pointer chasing in the form of offsets22:48
mithroI 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 performance22:54
mithromemory bandwidth >>>> disk bandwidth22:56
duck2it'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 versa22:56
duck2sorry if sounds stupid :D22:56
mithroduck2: The rr_graph that vpr can generate doesn't exactly match real world hardware22:56
mithroduck2: It's an approximation that is close enough for doing research, but doesn't really work that well for real devices22:57
mithroduck2: Allowing vpr to be provided a prebuilt rr_graph allows it to be used for any arbitrary routing fabric22:58
mithroduck2: Make sense?22:59
mithroelms: Great work on getting the formatting / testing stuff for arch defs going again!23:00
duck2i 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
mithroduck2: We need to always support loading an arbitrary rr_graph23:01
mithroduck2: But a potentially new file format could allow us to describe the rr_graph using a bunch of parameters and generate it in memory23:02
elmsmithro: 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
duck2mithro: i think that can be a project on its own23:04
duck2i'm updating my draft-draft to roughly this: schema-generated parser for arch.xml, flatbuffers/custom binary for rest of file formats23:06
*** zkms has quit IRC23:26
*** zkms has joined #symbiflow23:30
*** zkms has quit IRC23:33
*** zkms has joined #symbiflow23:38
*** zkms has quit IRC23:39
*** zkms has joined #symbiflow23:41
*** zkms has quit IRC23:47

Generated by 2.13.1 by Marius Gedminas - find it at!