Monday, 2019-04-01

*** tpb has joined #symbiflow00:00
*** _whitelogger has quit IRC01:31
*** _whitelogger has joined #symbiflow01:34
*** citypw has joined #symbiflow03:10
*** Bertl_oO is now known as Bertl_zZ04:35
*** i8hantanu has joined #symbiflow05:07
*** OmniMancer has joined #symbiflow07:10
*** i8hantanu has quit IRC07:57
*** _whitelogger has quit IRC08:37
*** _whitelogger has joined #symbiflow08:40
*** GuzTech has joined #symbiflow08:44
*** ayumis13 has joined #symbiflow09:16
*** citypw has quit IRC09:56
*** i8hantanu has joined #symbiflow10:42
*** kraiskil has joined #symbiflow11:19
*** Bertl_zZ is now known as Bertl11:41
*** kraiskil has quit IRC12:09
*** kraiskil has joined #symbiflow12:22
*** i8hantanu has quit IRC12:51
*** ayumis13 has quit IRC13:53
*** somlo has quit IRC14:52
sf-slack<acomodi> Hi everyone: I have started implementing the tile equivalence on VTR. A very early version can be seen in this PR (
tpbTitle: WIP: Equivalent tiles VTR feature by acomodi · Pull Request #36 · SymbiFlow/vtr-verilog-to-routing · GitHub (at
*** OmniMancer has quit IRC15:13
*** GuzTech has quit IRC15:14
*** kraiskil has quit IRC15:28
*** somlo has joined #symbiflow16:02
mithroduck2: So you are planning on apply to Google Summer of Code?16:10
mithromkurc: You around?16:10
litghostmithro: Yay!16:11
tpbTitle: Initial implemention of genfasm by litghost · Pull Request #510 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
duck2mithro: yes. what i currently have in mind as a gsoc project is adding 7-series support to nextpnr, but I didn't look into it thoroughly. maybe too ambitious? unnecessary?16:22
sf-slack<pgielda> @mkurc is away today16:24
sf-slack<pgielda> @mithro16:24
mithroduck2: That is probably a bit ambitious for a GSoC project16:30
litghostmithro: How so?  I think getting CLB and the interconnected into nextpnr is just about doable in the timeframe.  It would be challenging, but not impossible16:33
litghostmithro: I do agree that it is on the outside of the scope that makes sense16:34
litghostduck2: Do you have a concrete proposal, or just a vague notion?16:34
duck2it's a notion. i was "exposed" to the architecture file while messing with the rr_graph reader and i thought using it with another pnr tool should be doable. but i have no idea how much support nextpnr has for generic architectures.16:37
daveshahThere isn't much in the way of that yet, but there should be something soonish16:39
daveshahThere has been some very basic work on 7-series support using Torc16:39
daveshahI think there are plenty of subcomponents you could look at - e.g. a FASM backend16:39
litghostduck2: Oh, a FASM backend to nextpnr would probably be sharper in scope and have dividends.  @elms has been working on modifying symbiflow HLC support to FASM support.  FASM support would be needed for 7-series in nextpnr if it is too leverage the existing tool flow.16:42
litghostduck2: @elms has been working on ice40 FASM  support from symbiflow, which could be adapted to a backend from nextpnr.  Then 7-series support could leverage that backend once available16:44
daveshahIt could already be used with the very crude Torc-based 7-series support - although that wouldn't use a FOSS database, it could still use X-ray for bitgen16:45
litghostdaveshah/duck2: Starting with FASM and X-ray for bitgen, with a follow on for using X-ray for a FOSS database seems like a reasonable project16:47
mithroduck2: Another project idea is to continue your work on the I/O functionality of VPR -- our eventual goal is to make it possible to use other formats rather than XML for the rr_graph16:53
*** kraiskil has joined #symbiflow16:57
duck2litghost: i'm a bit confused. isn't fasm device specific? if i add a fasm backend to nextpnr, then shouldn't it know about 7-series architecture to create a fasm file which can be assembled by prjxray?16:57
mithroduck2: It's a bit less interesting, but reasonably important16:57
litghostduck2: A particular FASM file is device specific, but the specification is device agnostic (in theory)16:57
litghostduck2: Backend support is adding the ability for nextpnr to emit FASM for a particular design16:58
litghostduck2: To make this concrete, we added this support to VPR via metadata tags documented here:
tpbTitle: FPGA Assembly (FASM) Output Support Verilog-to-Routing 8.0.0-dev documentation (at
litghostduck2: I'm not familiar with how nextpnr FASM support should look, but the VPR model has worked pretty well for VPR in the case of both 7-series and ice4016:59
litghostduck2: The key with FASM is that it is feature based, which should have 1:1 corrispondence with PnR concepts.  For example, when nextpnr follows a graph edge belonging to a pip, that pip feature must be set17:00
litghostduck2: How to bind the nextpnr choices to FASM features is what the development of a FASM backend consists off17:00
duck2mithro: it's also a good idea. i tend to pick ambitious projects, but file formats, readers, writers etc. fit more into the theme of other gsoc projects. up to now, i could not think of a project which will fit into 12 weeks regarding IO functionality.17:02
litghostduck2: We are interested in having a fast and compact file format for VPR rr graphs.  XML does not really qualify as either :)17:03
mithroduck2: I would suggest looking at and
tpbTitle: Create a Python library for generating VtR arch.xml files · Issue #23 · SymbiFlow/ideas · GitHub (at
*** i8hantanu has joined #symbiflow17:06
duck2litghost: a fasm backend is interesting. i thought of it as a fancy spice netlist before, but didn't think much about where to put LUTs, muxes, etc. if i was generating it. will do more research on this17:09
*** celadon has quit IRC17:15
litghostduck2: I think something worth considering is how to re-use the FASM backend in nextpnr across arches.  The ice40 and ecp5 bitstream backends are fairly bespoke.17:15
duck2mithro: #4 makes sense, but as far as i know reading these files can take a lot of time in vpr. autogenerated xml parsers might be inefficient and slow down vpr noticeably. furthermore, at least the rr_graph reader does a bit of work on the structures loaded into memory from the file, so further processing will be still required after the autogener17:32
duck2ated parser. litghost has a branch of vpr using flatbuffers as rr_graph files, its reader&writer can be generated from a schema file too, but the issue with it is apparently lack of an efficient Python library to write out flatbuffers files from symbiflow-arch-defs. i think it should be possible to write a program which takes a python object of rr_17:32
duck2graph and serializes it into a flatbuffers file, but i'm not sure if this would be an appropriate project. /rabbithole17:32
litghostduck2: I think something worth exploring is whether a simple format might work well17:33
litghostduck2: Just focus on the edge list for a minute17:33
mithroduck2: I think there is enough meat here for a decent GSoC project17:33
litghostduck2: It is literally just a list of (int, int, short) tuples17:33
mithroduck2: A lot of effort would be performance improvement17:35
duck2litghost: a format in the form of competitive programming inputs would be simple, work very well and could be streamed in and out, but would take some trouble to document and would be broken easily. so the edge list could be 1334\n0 1 0\n1 2 5\n... where the first line says 1334 edges to follow and the rest are 1334 (int, int, short) tuples. it cou17:42
duck2ld even be read in with scanf :D17:42
litghostduck2: Sure, but I was just using that as an example.  The edge list is by far the most time consuming part of rrgraph writting (followed by nodes).  Nodes are more complicated data structures, but the edge list is not17:43
mithroduck2: We could also just store (unit64_t, uint64_t) pairs and then mmap the file17:54
*** m_hackerfoo has joined #symbiflow18:02
*** hackerfoo has joined #symbiflow18:02
duck2mithro: right. but that brings us back to flatbuffers. so it can be a project to polish the interface between symbiflow-arch-defs and vpr? maybe keep the arch file in XML and establish a schema-based reader/writer, and optimize rr_graph read/write for performance.18:05
mithroduck2: be back in an hour18:05
mithroGot a meeting now18:06
*** kraiskil has quit IRC18:11
litghostduck2: A schema based solution is something we've discussed, and I think could be workable.  A GSoC project focused on that would be appreciated too.  These are avenues we haven't had time to totally explore18:26
duck2thx for your time ^^ i think i should soon write draft proposals about the topics so far(arch-defs <-> vpr IO formats, nextpnr FASM), so we can see earlier if they can be properly scoped and packaged in 12 week schedules.19:25
*** i8hantanu has quit IRC19:27
*** kraiskil has joined #symbiflow20:29
mithroduck2: I would concentrate just on the vpr IO format side of things20:54
*** kraiskil has quit IRC21:21
*** sxpert has quit IRC22:33
*** Bertl is now known as Bertl_zZ23:35
*** futarisIRCcloud has joined #symbiflow23:57

Generated by 2.13.1 by Marius Gedminas - find it at!