kgugala_ has quit [Read error: Connection reset by peer]
whitequark has left #symbiflow [#symbiflow]
kgugala has joined #symbiflow
<sf-slack4>
<olof.kindgren> I'm starting to think the best way might be to run some netlist simulations. Anyone has hints on how to do that? Icarus gives me syntax errors on the specify blocks in install/share/arch/ql-eos-s3_wlcsp/cells/ram_sim.v
<sf-slack4>
<kgugala> Verilator should be able to ignore those blocks
<sf-slack4>
<olof.kindgren> Looks like it doesn't like these kind of lines `(CLK2*>RD_b0)="";` and my knowledge of the dark corners of verilog ain't enough to figure out what it's about
<sf-slack4>
<olof.kindgren> But verilator probably won't do me any good here. I need an event-based sim
<sf-slack4>
<olof.kindgren> Or is there some verilator-usale model for the ASSP module that can give me a proper Sys_Clk0 ?
<sf-slack4>
<kgugala> the only one I know is in the toolchain repo
<sf-slack4>
<olof.kindgren> Hmm.. how do I even configure the clock frequency in the simulator model?
<sf-slack4>
<kgugala> @tpagarani may know more
<sf-slack4>
<olof.kindgren> Hmm.. looks like the ASSP model doesn't generate clocks, so I would need to do that myself. That's ok, but I still need the RAM models
<sf-slack4>
<olof.kindgren> I killed off the specify blocks for now and run with -gno-specify. But which libraries should I load? There are files in conda/share/yosys/quicklogic, conda/pkgs/yosys-0.8.0_0002_gc3b38fdc-20200901_073908/share/yosys/quicklogic and install/share/arch/ql-eos-s3_wlcsp/cells. How do they all fit together?
<sf-slack4>
<kgugala> the one in arch are for post layout sim, you can use the ones from conda/pkgs/yosys-0.8.0_0002_gc3b38fdc-20200901_073908/share/yosys/quicklogic
<sf-slack4>
<olof.kindgren> gtg
OmniMancer has quit [Read error: Connection reset by peer]
OmniMancer has joined #symbiflow
OmniMancer has quit [Read error: Connection reset by peer]
<sf-slack4>
<rakeshm> @olof.kindgren For postlayout simulation you can find the models (ASSP / RAMs) at: /install/share/arch/ql-eos-s3_wlcsp/cells/ Sys_Clk0 frequency can be controlled by changing the parameter T_CYCLE_CLK_SYS_CLK0 in /install/share/arch/ql-eos-s3_wlcsp/cells/assp_bfm.sim.v file
<sf-slack4>
<rakeshm> @olof.kindgren for pre-layout sim you need to use the models at: /conda/share/yosys/quicklogic/ cells_sim.v & pp3_cells_sim.v files
kgugala_ has quit [Read error: Connection reset by peer]
kgugala has joined #symbiflow
FFY00 has quit [Ping timeout: 268 seconds]
FFY00 has joined #symbiflow
OmniMancer has quit [Quit: Leaving.]
<sf-slack4>
<olof.kindgren> @tpagarani Hmm.. does this mean the data I put in the memories during synthesis gets ignored?
<sf-slack4>
<olof.kindgren> Or to phrase it another way; After the qorc-sdk 1.4.0 release, will the memory initialization data specified during synthesis be extracted automatically from the bit file when the h file is created?
<sf-slack4>
<olof.kindgren> Or do I need to add the memory contents manually at some point?
<sf-slack4>
<olof.kindgren> If I understand the changes correctly, I need to call `load_fpga_with_mem_init` explicitly from my C code. What is my memory contents supposed to look like? Do I need to know which of the on-chip RAM to program? Can I extract this from the bit file somehow?
<sf-slack4>
<olof.kindgren> Aha! There's a `axFPGAMemInit` in the .h file already. Unfortunatley that one is empty
<sf-slack4>
<olof.kindgren> And that one is created by symbiflow_write_bitheader which is a bash script calling bitstream_to_header.py
<sf-slack4>
<olof.kindgren> And that one seems to try reading a file called ram.mem
<sf-slack4>
<olof.kindgren> ...which is empty. Now who creates ram.mem?
<sf-slack4>
<olof.kindgren> Aha!
umarcor has quit [Read error: Connection reset by peer]
<sf-slack4>
<olof.kindgren> Of course it was empty. I'm building the bitstream outside of the qorc-sdk tree and then copy it into the helloworld project. But I was using ram.mem from helloworld, which is empty
<sf-slack4>
<olof.kindgren> Want to test it now but can't find my board. Stupid miniaturization
<sf-slack4>
<coreyrsimpson> I am currently writing a fuzzer for the PCIE and GMT tiles for prjxray with the artix 7, and am having some preliminary success. I was wondering what sort of tools/methods prjxray used to validate the segbits files that were generated for each fuzzer created?
QDX45 has joined #symbiflow
<sf-slack4>
<olof.kindgren> ok, so it still didn't work. Another question. Looking at the data in ram.mem it seems to split the 32-bit data words into two 16-bit words stored at different addresses and then it looks like there's some shuffling of a few bit lines as well. Is that expected?
<sf-slack4>
<olof.kindgren> Fuck! I forgot to change the call in main.c to use load_fpga_wit_mem_init!
<sf-slack4>
<olof.kindgren> Still no luck, but I guess I'm closer at least
<litghost>
coreyrsimpson: Creating a minitest (e.g. minitests/pcie/....) and seeing how many unknown bits are left
<litghost>
coreyrsimpson: So for example, create simple PCIe design, generate the bitstream from Vivado, and then see if all bits are documented
<litghost>
coreyrsimpson: Any unknown bits are remaining work
<litghost>
coreyrsimpson: To be clear, you might solve all the bits for the PCIe hardblock, but be missing special clocking bits, or pips, or GTX bits
<litghost>
coreyrsimpson: There are also tools in prjxray to ensure that bits don't overlap in tiles overall sense
<litghost>
The root level makefile target "db-check" will do that
<sf-slack4>
<coreyrsimpson> That makes sense, I'll check that out. Thanks
<litghost>
coreyrsimpson: No matter what, it probably makes sense to open a PR with the work you've started to get the review process going