| *** tpb has joined #symbiflow | 00:00 | |
| mithro | Yay, fixed https://symbiflow.github.io/prjxray-db/artix7/ | 02:34 |
|---|---|---|
| tpb | Title: X-Ray ARTIX7 Database (at symbiflow.github.io) | 02:34 |
| *** citypw has joined #symbiflow | 04:10 | |
| *** OmniMancer has joined #symbiflow | 05:38 | |
| *** proteusguy has joined #symbiflow | 05:40 | |
| *** proteusguy has quit IRC | 07:13 | |
| *** proteusguy has joined #symbiflow | 07:46 | |
| *** chrisc__ has joined #symbiflow | 08:00 | |
| *** chrisc__ has quit IRC | 08:00 | |
| *** proteusguy has quit IRC | 08:42 | |
| *** citypw has quit IRC | 10:09 | |
| sf-slack | <kgugala> awesome!! | 12:13 |
| *** OmniMancer has quit IRC | 15:28 | |
| *** citypw has joined #symbiflow | 15: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. Then | 16:18 |
| sf-slack | the 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 |
| litghost | mkurc: I had already suggested that to kgugala, acomodi and tmichalak earlier this week. | 16:30 |
| litghost | So ya, that sounds fine :) | 16:32 |
| litghost | FYI, it will not solve the carry chain issue completely, slicel versus slicem will continue to be an issue | 16:33 |
| litghost | But all slice l chains should work | 16:34 |
| *** proteusguy has joined #symbiflow | 17:37 | |
| elms | lighost: 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 |
| elms | litghost: ^ | 18:40 |
| litghost | elms: 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 code | 18:43 |
| litghost | duplication in top.py and generate.py from how trellis wrote it fuzzers would be a better use of time. | 18:43 |
| elms | litghost: 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 |
| litghost | I 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 |
| litghost | So I think it's priority is low compared with fleshing out other prjxray fuzzers to complete the part documentation | 18:47 |
| litghost | If 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 dividends | 18:48 |
| litghost | Maybe a common "FPGA fuzzer library", extracting the good ideas from prjxray and trellis | 18:48 |
| litghost | I 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 (https://github.com/SymbiFlow/fasm/blob/master/fasm/output.py#L342) requires a function called the "zero_function" that returns true if a feature is zero bits | 18:52 |
| tpb | Title: fasm/output.py at master · SymbiFlow/fasm · GitHub (at github.com) | 18:52 |
| litghost | This 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 helpful | 18:53 |
| litghost | But again, the code required to write that function per platform is low | 18:54 |
| elms | litghost: ok sounds like an area for me to explore next week | 19:07 |
| litghost | elms: 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 approach | 19:09 |
| daveshah | The current Trellis fuzzer framework is a tiny bit hacky as I had to expand it as I went along | 19:11 |
| daveshah | For example some stuff to deal with cases where one setting can only be changed while also changing another | 19:11 |
| daveshah | But I think the enum concept has worked really well | 19:11 |
| litghost | daveshah: Sure, but what we have right now in prjxray is way more adhoc and free form. There is basically no enforced structure | 19:12 |
| litghost | I think that is an advantage on more complicated fuzzers, say https://github.com/SymbiFlow/prjxray/blob/master/fuzzers/041-clk-hrow-pips/generate.py | 19:12 |
| tpb | Title: prjxray/generate.py at master · SymbiFlow/prjxray · GitHub (at github.com) | 19:12 |
| daveshah | Yeah the common framework definitely made getting high coverage of the device easy | 19:12 |
| litghost | But I think many configuration fuzzers right now could use some more structure, ala trellis | 19:13 |
| mithro | Interesting, just came across http://uccross.github.io/gsoc19.html#lgraph | 19:26 |
| tpb | Title: GSoC 2019 | uccross.github.io (at uccross.github.io) | 19:26 |
| mithro | Through lgraph stuff | 19:27 |
| mithro | Hi 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 discuss | 19: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 VPR | 19:51 |
| mithro | acomodi: What do you want to know | 20: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 |
| mithro | acomodi: 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 cluster | 20:53 |
| mithro | acomodi: When adding a molecule to a cluster it tries to find a matching primitive in any mode | 20:54 |
| mithro | acomodi: It then tries to make sure routing is valid | 20:54 |
| mithro | acomodi: 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 it | 21:02 |
| *** lopsided98_ has joined #symbiflow | 21:45 | |
| *** lopsided98 has quit IRC | 21:48 | |
| mithro | FYI - If you don't say my nick I won't respond | 22:03 |
| mithro | litghost: So, I pushed stuff based on the merge of #667, but I think there is even more stuff since then? | 22:38 |
| mithro | litghost: This is were the uart seems to be configured -> https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/scala/vexriscv/demo/Murax.scala#L114-L132 | 23:08 |
| tpb | Title: VexRiscv/Murax.scala at master · SpinalHDL/VexRiscv · GitHub (at github.com) | 23:08 |
| litghost | mithro: Ya, but the divider ratio not obvious from that. The final UART divider is 100 (20*5) | 23:09 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!