Friday, 2019-02-22

*** tpb has joined #symbiflow00:00
mithroYay, fixed
tpbTitle: X-Ray ARTIX7 Database (at
*** citypw has joined #symbiflow04:10
*** OmniMancer has joined #symbiflow05:38
*** proteusguy has joined #symbiflow05:40
*** proteusguy has quit IRC07:13
*** proteusguy has joined #symbiflow07:46
*** chrisc__ has joined #symbiflow08:00
*** chrisc__ has quit IRC08:00
*** proteusguy has quit IRC08:42
*** citypw has quit IRC10:09
sf-slack<kgugala> awesome!!12:13
*** OmniMancer has quit IRC15:28
*** citypw has joined #symbiflow15:29
sf-slack<mkurc> @litghost We've been thinking to change the FPGA arch representation from CLB level to slice level. This would seem to resolve carry-chain packing issues (hopefully). I was thinking how to do it with as little change to the whole flow as possible. I propose to do a translation of the architecture and routing graph XML files. By doing this we can avoid modifying the database and python scripts which generate them.  Then16:18
sf-slackthe VPR will operate on slice level instead of CLB level. Once the P&R is done the output will be translated back to CLB level suitable for bitstream generation. What do you think ?16:18
litghostmkurc: I had already suggested that to kgugala, acomodi and tmichalak earlier this week.16:30
litghostSo ya, that sounds fine :)16:32
litghostFYI, it will not solve the carry chain issue completely, slicel versus slicem will continue to be an issue16:33
litghostBut all slice l chains should work16:34
*** proteusguy has joined #symbiflow17:37
elmslighost: Are you familiar with the database formats of trellis and icestorm? Wondering if it would be possible to define a common database format.18:40
elmslitghost: ^18:40
litghostelms: I've looked at trellis.  It has some interesting ideas that might be worth looking into, however it's unclear the value of making common databases as the first step.  The currently prjxray format is simple and functional.  The trellis database is significantly more complicated but featured.  To date, I haven't felt that the database format itself was blocking progress. I think some ideas on how to reduce code18:43
litghostduplication in and from how trellis wrote it fuzzers would be a better use of time.18:43
elmslitghost: ok I'll create an idea but not think more about it.  I realized for the fasm ice40 work I basically converted the icestorm db to a similar format as prjxray. Easy to look up the features and set the bits.18:46
litghostI think in the long term having a common database and FASM <-> text bits <-> bits across different parts will have value.  However I think FASM <-> text bits isn't that hard (~300 lines of python), and the number of targetted platforms is low at this time.18:47
litghostSo I think it's priority is low compared with fleshing out other prjxray fuzzers to complete the part documentation18:47
litghostIf you wanted to take a page from how trellis wrote its fuzzers and reduced code dup in the prjxray fuzzers, I think that would pay immediate dividends18:48
litghostMaybe a common "FPGA fuzzer library", extracting the good ideas from prjxray and trellis18:48
litghostI will say there are some specific features in the trellis database format that will aid in a specific feature of text bits -> FASM, which is around features that set no bits.  Currently the FASM formatter ( requires a function called the "zero_function" that returns true if a feature is zero bits18:52
tpbTitle: fasm/ at master · SymbiFlow/fasm · GitHub (at
litghostThis is important for not outputting tiles that contain no bits set (e.g. an unused CLB).  Techinically there are features "set" in the sense that all tiles have default features, however outputting "default" features for unused tiles is not helpful18:53
litghostBut again, the code required to write that function per platform is low18:54
elmslitghost: ok sounds like an area for me to explore next week19:07
litghostelms: Ya.  I think maybe a two pronged approach, where you convert an old prjxray fuzzer and write a new prjxray fuzzer would demonstrate usage of the trellis approach19:09
daveshahThe current Trellis fuzzer framework is a tiny bit hacky as I had to expand it as I went along19:11
daveshahFor example some stuff to deal with cases where one setting can only be changed while also changing another19:11
daveshahBut I think the enum concept has worked really well19:11
litghostdaveshah: Sure, but what we have right now in prjxray is way more adhoc and free form.  There is basically no enforced structure19:12
litghostI think that is an advantage on more complicated fuzzers, say
tpbTitle: prjxray/ at master · SymbiFlow/prjxray · GitHub (at
daveshahYeah the common framework definitely made getting high coverage of the device easy19:12
litghostBut I think many configuration fuzzers right now could use some more structure, ala trellis19:13
mithroInteresting, just came across
tpbTitle: GSoC 2019 | (at
mithroThrough lgraph stuff19:27
mithroHi everyone, I'll be meeting with a whole bunch of VtR developers in the next couple of days -- does anyone have things they want to discuss19:46
sf-slack<acomodi> Hi mitrho, actually yes, I have been struggling for the last couple of days with the 'modes' issue which prevents the slicem to be used. It would be great to understand how exactly the whole mode selection and assignment works in VPR19:51
mithroacomodi: What do you want to know20:42
sf-slack<acomodi> Specifically how the `mode` selection works  during the `pack` stage of VPR. For instance, the current issue is that when doing `clustering` of a carrychain that includes the Slicem there is a switch in the modes (from DRAMs to LUTs) for what regards the `DLUT`. I have been trying to track down where and how this switch in the mode happens but I still couldn't find a solution to the issue.20:48
mithroacomodi: So clusterer loops over the molecules and tries to add it existing clusters and then if it was unable to add it, it creates a new cluster20:53
mithroacomodi: When adding a molecule to a cluster it tries to find a matching primitive in any mode20:54
mithroacomodi: It then tries to make sure routing is valid20:54
mithroacomodi: If routing is invalid, then it rejects the addition...20:55
sf-slack<acomodi> Ok, thanks. It is more clear now. I think I have almost figured out how to solve it21:02
*** lopsided98_ has joined #symbiflow21:45
*** lopsided98 has quit IRC21:48
mithroFYI - If you don't say my nick I won't respond22:03
mithrolitghost: So, I pushed stuff based on the merge of #667, but I think there is even more stuff since then?22:38
mithrolitghost: This is were the uart seems to be configured ->
tpbTitle: VexRiscv/Murax.scala at master · SpinalHDL/VexRiscv · GitHub (at
litghostmithro: Ya, but the divider ratio not obvious from that.  The final UART divider is 100 (20*5)23:09

Generated by 2.13.1 by Marius Gedminas - find it at!