01:54 <sf-slack> <nfrancque> @litghost Thanks for the advice. Is there any documentation about what all the software surrounding the fuzzers is trying to do? Especially segmaker in Python and segmatch in C++. Or is looking at those diving deeper than I need to?

04:32 <sf-slack> <ychen> Hi all, I'm new here. This is a very interesting project (and I just knew it :( ). I have some experience of VPR/VTR development, XML, FPGA (X/A, some MS), C++/Python/tcl/perl, EDA tools/algorithms, RISC-V, etc. Hope I can help.

04:37 <sf-slack> <ychen> I saw someone talked about Zynq, I think you can bypass ps7. The only thing is that you may need to manually add axi and other peripheral components (most of time, it is because of booting from SD card). If you are using USB/Jtag or QSPI, you dont need PS7.

07:44 <sf-slack> <kgugala> @heijligen ps7 is always enabled in zynq devices. It connects to fabric via PIPs - you have to enable them in bitsteam to get the connection. From PS7 point of view you have to enable level shifters after you program the bitsream. If you're using U-Boot or Linux FPGA manager on PS7 the drivers will enable the levelshifters after the bitstream is programmed

07:46 <sf-slack> <kgugala> @heijligen as for the connections there are AXI buses (both slave and masters) and a loot of other signals: PS7 GPIOs, interrupts, clocks and some peripherals signals (e.g. PTP signals from Ethernet peripheral)

07:47 <sf-slack> <kgugala> here: https://github.com/SymbiFlow/symbiflow-arch-defs/tree/master/xc7/tests/ps7/axi_lite_reg you can find a simple AXI lite peripheral connected to PS7 GP0 AXI bus

07:47 <tpb> Title: symbiflow-arch-defs/xc7/tests/ps7/axi_lite_reg at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

07:48 <sf-slack> <kgugala> in this PR https://github.com/SymbiFlow/symbiflow-arch-defs/pull/1251 you can find a little bit more complicated example - this is Linux grade Litex/VexRiscv using PS7 DDR

07:48 <tpb> Title: Zybo: Add minitest with Litex/Vex booting Linux by kgugala · Pull Request #1251 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

08:43 <_whitenotifier-5> [symbiflow-arch-defs] mkurc-ant opened issue #1258: Incorrect handling of OSERDES inputs in the techmap - https://git.io/Jexb7

11:25 <litghost> > 8:54 PM <sf-slack> <nfrancque> @litghost Thanks for the advice. Is there any documentation about what all the software surrounding the fuzzers is trying to do? Especially segmaker in Python and segmatch in C++. Or is looking at those diving deeper than I need to?

11:25 <litghost> Too deep. What you need to know is durig segmaker in python you are trying to provide 100% positive correlations along with some negative cases

11:26 <litghost> Example: In order to find write a LUT fuzzer, each bit in the LUT must be cleared and set, and segmaker should emit whether the input verilog had the LUT bit set or cleared. Segmatch will do the rest

23:18 <sf-slack> <nfrancque> Ok, and do you expect segmaker to need any modifications to get there? Or is that known good and just need to provide the cases to the fuzzer? Main reason I ask is I've messed with it to a point where I know some bits are set and unset in Vivado several times but get 0 candidates out of segmatch. So seems like either some case allowing Vivado to optimize it out or segmaker issue.

23:34 <sf-slack> <nfrancque> Put better: I know that the verilog is set, that Vivado recognizes it from the log and that the segmaker tag output shows it as I expect it. So if I understand correctly choices are 1) Because of some other parameter that bit can be safely ignored, so vivado chooses to tie it to some constant, and therefore just need to try more fuzzing or 2) Segmatch/segmaker are somehow misidentifying it. Just checking that

23:34 <sf-slack> that sounds like a rational line of thinking.

23:53 <heijligen> daveshah kgugala: thanks for the help. i've got a blinking example working :)