<tpb>
Title: Initial implemention of genfasm by litghost · Pull Request #510 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)
<duck2>
mithro: 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?
<sf-slack>
<pgielda> @mkurc is away today
<sf-slack>
<pgielda> @mithro
<mithro>
duck2: That is probably a bit ambitious for a GSoC project
<litghost>
mithro: How so? I think getting CLB and the interconnected into nextpnr is just about doable in the timeframe. It would be challenging, but not impossible
<litghost>
*interconnect
<litghost>
mithro: I do agree that it is on the outside of the scope that makes sense
<litghost>
duck2: Do you have a concrete proposal, or just a vague notion?
<duck2>
it'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.
<daveshah>
There isn't much in the way of that yet, but there should be something soonish
<daveshah>
There has been some very basic work on 7-series support using Torc
<daveshah>
I think there are plenty of subcomponents you could look at - e.g. a FASM backend
<litghost>
duck2: 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.
<litghost>
duck2: @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 available
<daveshah>
It 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 bitgen
<litghost>
daveshah/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 project
<mithro>
duck2: 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_graph
kraiskil has joined #symbiflow
<duck2>
litghost: 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?
<mithro>
duck2: It's a bit less interesting, but reasonably important
<litghost>
duck2: A particular FASM file is device specific, but the specification is device agnostic (in theory)
<litghost>
duck2: Backend support is adding the ability for nextpnr to emit FASM for a particular design
<litghost>
duck2: 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 ice40
<litghost>
duck2: 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 set
<litghost>
duck2: How to bind the nextpnr choices to FASM features is what the development of a FASM backend consists off
<duck2>
mithro: 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.
<litghost>
duck2: We are interested in having a fast and compact file format for VPR rr graphs. XML does not really qualify as either :)
<tpb>
Title: Create a Python library for generating VtR arch.xml files · Issue #23 · SymbiFlow/ideas · GitHub (at github.com)
i8hantanu has joined #symbiflow
<duck2>
litghost: 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 this
celadon has quit [Ping timeout: 244 seconds]
<litghost>
duck2: 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.
<duck2>
mithro: #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 autogener
<duck2>
graph and serializes it into a flatbuffers file, but i'm not sure if this would be an appropriate project. /rabbithole
<duck2>
ated 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_
<litghost>
duck2: I think something worth exploring is whether a simple format might work well
<litghost>
duck2: Just focus on the edge list for a minute
<mithro>
duck2: I think there is enough meat here for a decent GSoC project
<litghost>
duck2: It is literally just a list of (int, int, short) tuples
<mithro>
duck2: A lot of effort would be performance improvement
<duck2>
litghost: 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 cou
<duck2>
ld even be read in with scanf :D
<litghost>
duck2: 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 not
<mithro>
duck2: We could also just store (unit64_t, uint64_t) pairs and then mmap the file
m_hackerfoo has joined #symbiflow
hackerfoo has joined #symbiflow
<duck2>
mithro: 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.
<mithro>
duck2: be back in an hour
<mithro>
Got a meeting now
<duck2>
ok
kraiskil has quit [Ping timeout: 255 seconds]
<litghost>
duck2: 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 explore
<duck2>
thx 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.
i8hantanu has quit [Quit: Connection closed for inactivity]
kraiskil has joined #symbiflow
<mithro>
duck2: I would concentrate just on the vpr IO format side of things