| *** tpb <[email protected]> has joined #symbiflow | 00:00 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 05:57 | |
| *** TMM_ <[email protected]> has joined #symbiflow | 05:57 | |
| sf-slack | <mkurc> Hi @sdamghan. Yosys provides the `setattr` pass which allows to set / unset an attribute of cells and modules. It can be invoked from TCL. You can use that to set the "keep_hierarchy". | 07:06 |
|---|---|---|
| benreynwar | I've been looking through the 030-iob fuzzer to get an idea of how the HR I/O tiles are getting fuzzed and comparing what I see there with the xilinx UG471 SelectIO user guide. There are lots of I/O standards, primitives and attributes that are currently not being fuzzed. Presumably that's because these aren't used much, and so there has been no reason to fuzz them. Would adding some of these to the existing 030-iob fuzzer | 15:42 |
| benreynwar | be a sensible first step before starting on fuzzing the HP I/O tiles? | 15:42 |
| benreynwar | 1) Are there any particular standards, primitives or attributes that would make most sense to add? | 15:43 |
| benreynwar | 2) The 030-iob fuzzer is already pretty complicated, and adding support for additional features will make things worse. Is it worth it? Presumably it will also make the fuzzing slower. | 15:43 |
| benreynwar | 3) If I do modify this fuzzer what's the process to make sure that I don't break things that were were working previously. Are there regression tests I can run to check that the previously existing labels still map to the same bits as before? | 15:43 |
| gatecat | benreynwar: (1) the basic LVCMOS ones (LVCMOS18, LVCMOS15, LVCMOS12), LVDS for differential clocks and SSTL15/DIFF_SSTL15/SSTL135/DIFF_SSTL135 for DDR3 seem like the first targets | 15:47 |
| gatecat | (at least thinking about what's needed to get a LiteX SoC running with DRAM on a board like the Genesys 2) | 15:47 |
| gatecat | (3) should be checked by the prjrxray CI, I think, it will produce a diff you can check | 15:48 |
| gatecat | ah, sorry, I think I misread (1) - I was answering in the context of the first IO standards that need to be supported for HR IO | 15:48 |
| gatecat | I don't know if there are any pressing omissions for HP I/O | 15:48 |
| benreynwar | gatecat: Yeah. I was thinking of working on the HR I/O for a little bit just to get familiar with it before jumping into the HP I/O. | 15:49 |
| benreynwar | gatecat: Depends whether adding complexity to support features that will rarely be used is worth it. | 15:50 |
| benreynwar | gatecat: I was mostly thinking of it as a learning exercise for myself :). | 15:51 |
| gatecat | I suspect that completeness is always important, even if it adds complexity | 15:52 |
| benreynwar | Currently unsupported I/O standards are: | 15:52 |
| benreynwar | BLVDS_25, DIFF_HSTL_I, DIFF_HSTL_I_18, DIFF_HSTL_II, DIFF_HSTL_II_18, DIFF_HSUL_12, DIFF_MOBILE_DDR, | 15:52 |
| benreynwar | DIFF_SSTL135_R, DIFF_SSTL15_R, DIFF_SSTL18_I, DIFF_SSTL18_II, HSTL_I, HSTL_I_18, HSTL_II, HSTL_II_18, | 15:52 |
| benreynwar | HSUL_12, MINI_LVDS_25, MOBILE_DDR, PCI33_3, PPDS_25, RSDS_25, SSTL18_I, SSTL18_II | 15:52 |
| benreynwar | The non-differential primitives IBUF_IBUFDISABLE, IBUF_INTERMDISABLE, IBUFG, IOBUF, OBUFT are also not fuzzed there, along with a bunch of differential primitives. | 15:53 |
| gatecat | HSUL_12 could be interesting for the various LPDDRx variants | 15:54 |
| gatecat | in terms of primitives, I believe OBUFT is already supported upstream as it doesn't introduce any new bits. likewise IBUFG isn't an input buffer type per se but a split macro of a regular IBUF and a connected BUFG | 15:55 |
| benreynwar | Also how can I be confident that the fuzzing has been successful. How do you test the resulting database? | 15:59 |
| gatecat | you can use bit2fasm to convert a Vivado bitstream back to fasm and check the right bits are set and there are no unknown bits (iirc you need to use it in verbose mode for the latter) | 16:00 |
| benreynwar | Should I just do that on the specimen bitstreams? It'll basically just be checking that there were no bugs in the segmatching and database generation right? | 16:03 |
| benreynwar | Thinking about this some more, I think I will just jump into the HP I/O fuzzing. That way I don't need to worry about breaking things that are already working. | 16:10 |
| *** SaiCharan <[email protected]> has joined #symbiflow | 18:56 | |
| *** SaiCharan6 <[email protected]> has joined #symbiflow | 18:57 | |
| *** SaiCharan <[email protected]> has quit IRC (Client Quit) | 18:57 | |
| *** SaiCharan6 <[email protected]> has quit IRC (Client Quit) | 18:57 | |
| mithro | benreynwar: I would target specific designs | 22:29 |
| benreynwar | mithro: Yeah, I could take a design, run it through Vivado, then bring the bitstream back into BELS via FASM2BELs, and process it through Vivado again. If I get the same bitstream then I know the design is well handled, both in prjxray and in FASM2BELs. That kind of flow? | 22:44 |
| lkcl | hi folks, what package (repo) is the symbiflow_synth command built from? | 23:42 |
| lkcl | i can't find it with searches, nor instructions on where to get it! | 23:43 |
| lkcl | with 75 repositories here https://github.com/orgs/SymbiFlow/repositories it's extremely difficult to find | 23:44 |
| lkcl | this would be a likely candidate | 23:46 |
| lkcl | https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc/xc7/toolchain_wrappers/symbiflow_synth | 23:46 |
| lkcl | had to guess it *might* be the arch-defs repo, and use "find . -name symbiflow_synth" ! | 23:47 |
| lkcl | pure luck! | 23:47 |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 23:55 | |
| *** TMM_ <[email protected]> has joined #symbiflow | 23:55 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!