tpb has quit [Remote host closed the connection]
tpb has joined #symbiflow
QDX45 has quit [Ping timeout: 272 seconds]
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #symbiflow
OmniMancer has joined #symbiflow
epony has quit [Quit: surprise quite message, just joking.. upgrades as usual]
epony has joined #symbiflow
<sf-slack4> <tpagarani> @olof.kindgren, Looks like you were able to figure out the memory init routines. The reason data has been split and bits are shuffled is because of the internal memory organization. Our internal physical memory block is actually each 18K which can be used as single 18K or 2 independent 9K blocks. In 18K mode, it can be configured as 2048x9, 1024x18 OR 512x36. In 9K mode it can be configured as 1024x9 OR 512x18.
<sf-slack4> For Synthesis, we are only currently supporting x8, x16, x32 data widths (other bits are meant for parity which we don't support yet). That's why you would see that your data is being padded with parity bit set to 0.
QDX45 has joined #symbiflow
umarcor has joined #symbiflow
az0re has quit [Remote host closed the connection]
epony has quit [Remote host closed the connection]
az0re has joined #symbiflow
_whitelogger has joined #symbiflow
epony has joined #symbiflow
<sf-slack4> <olof.kindgren> @tpagarani Cool. I kind of guessed it had to do with internal layout but wanted to make sure it wasn't something wrong. Good to get that confirmed
<sf-slack4> <tpagarani> @olof.kindgren, Please share your project with output files as well. I will confirm if RAM init sections look okay.
<sf-slack4> <olof.kindgren> @tpagarani Here's the source and build for the .bit file. The source of the memory init data is in the file blinky.hex
<sf-slack4> <olof.kindgren> This is built outside of qorc-sdk, and after I have built the FPGA image, I copy the bit file + ram.mem into the qf_helloworldhw project and regenerate.
<sf-slack4> <olof.kindgren> So which files from the qf_helloworldhw project do you need? All of them?
<sf-slack4> <olof.kindgren> Or just the elf file and , _bit.h file ?
<sf-slack4> <olof.kindgren> Here's the whole project
<sf-slack4> <tpagarani> @olof.kindgren you should be able to generate the header file within symbiflow itself rather than taking bit + ram.mem info qf_hellowordw project. https://quicklogic-fpga-tool-docs.readthedocs.io/en/latest/tutorial/GeneratetheASCIIheaderfilef.html
<tpb> Title: Generate the ASCII header file format QuickLogic-FPGA-Toolchain (at quicklogic-fpga-tool-docs.readthedocs.io)
<sf-slack4> <olof.kindgren> Ah, cool. Then I only need to add the h file to the project. Need to chek if the edalize backend supports passing custom options to the symbiflow commands to do that
<sf-slack4> <olof.kindgren> Hm.. need to check which commands this ql_symbiflow script runs
<sf-slack4> <olof.kindgren> ah, ok. It calls the bitstream_to_header.py script eventually. That python script is a bit awkward since it relies on having files in certain directories
<sf-slack4> <olof.kindgren> So it might be easier for now to just make a modified version of that script and add it as an Edalize post_build hook for now
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #symbiflow
ssb has quit [Ping timeout: 258 seconds]
OmniMancer has quit [Quit: Leaving.]
QDX45 has joined #symbiflow
<litghost> mithro: Looks like that incorporates the expected changes
<mithro> litghost: Do you have any info on https://github.com/SymbiFlow/fpga-tool-perf/issues/262 ?
<litghost> mithro: I posted https://github.com/SymbiFlow/fpga-tool-perf/issues/262#issuecomment-721224923 and stand by the comment
<litghost> mithro: The missing bit specifically is trying to route a clock from the interconnect to the OSERDES (I believe). While the database should have that bit, it is a bad sign if the router is trying to route a clock on the interconnect at all.
<litghost> mithro: In the past that kind of routing was the result of a stray INV cell being between the clock and the Cell
<mithro> litghost: The issue at https://github.com/SymbiFlow/symbiflow-arch-defs/issues/1750 is a seperate issue too?
<litghost> mithro: ISERDES and OSERDES usually have local inverters that are strongly preferred over implementing the inversion as a INV -> LUT1 cell
<litghost> mithro: Some of those bits are "easy", per mkurc's comment here: https://github.com/SymbiFlow/symbiflow-arch-defs/issues/1750#issuecomment-721689430
<litghost> mithro: The GTP_COMMON_MID_RIGHT bits haven't been relevant to date, so no one stood up a fuzzer
<litghost> mithro: The easiest solution to both of these issues to exclude the PLL in the CMT with the GTP from being used, as it has some stranger routing.
<mithro> HackerFoo: See the above discussion
<litghost> mithro: In earlier demostrations of ibex on 200T, we used a graph limit to exclude the portion of the fabric that we were missing bits
<litghost> mithro: Given the low number of pips missing, it is likely that standing up a GTP_COMMON_MID_RIGHT fuzzer wouldn't be too bad, and updated 034b to capture the REBUF pips is also possible
<HackerFoo> mithro: Thanks
<_whitenotifier-f> [prjxray] mithro opened issue #1493: Database HTML generation output on prjxray-db push failing - https://git.io/JkOtM
FFY00 has quit [Ping timeout: 260 seconds]
<_whitenotifier-f> [symbiflow-arch-defs] HackerFoo opened issue #1773: Use VPR's RR graph node reordering and remove hilbertcurve dependency - https://git.io/JkOqi
FFY00 has joined #symbiflow
<mithro> @litghost / @mkurc: New prjxray-db pushed
az0re has quit [Ping timeout: 240 seconds]
<sf-slack4> <mkurc> @litghost I may have a solution for ISERDES/OSERDES clock inverters that come as a result of connecting clocks like `.CLK(~my_clk)` in verilog. Some time ago I wrote a Yosys plugin that integrates inverter cells into hard blocks that have invertible pins. It works in the opposite way as the built-in pass `extractinv`. If that could be helpful I can clean up the code and make a PR in the upcoming week.
<litghost> mkurc: That's what I expected. I believe yosys has a way to deal with invertable clocks already.
FFY00 has quit [Read error: Connection reset by peer]
ssb has joined #symbiflow
FFY00 has joined #symbiflow
<sf-slack4> <olof.kindgren> I'm trying to verify the contents of the first memory position by guessing each bit position and turning on a LED if it's correct. 8 done, 24 left. Sometimes I wonder if I should invest in better debugging solutions :)
<sf-slack4> <olof.kindgren> So to clarify, I rebuild the bitstream between every attempt
<sf-slack4> <olof.kindgren> It's a bit weird. I expect it to be 0x40000357, but that test fails. However, I have uncovered that the 8 LSB are 0x57, so I'm very curious to see where it goes wrong
<sf-slack4> <olof.kindgren> Doing a leap of faith now and testing 4 bits at the same time to hopefully speed up the process
<sf-slack4> <olof.kindgren> Yes! 12 bits done
az0re has joined #symbiflow
<sf-slack4> <olof.kindgren> ok, so bit 30 is not correct. Should be 1. Is 0
<sf-slack4> <olof.kindgren> I wonder if there's some bit shuffling problem in the init file generation going on. Let's see what bit 31 is
<sf-slack4> <olof.kindgren> But that's also the only 1 in the top 16 bits of the word, so theoretically, it could be that the whole upper halft is 0. Will need some further investigation
alexhw has quit [Ping timeout: 240 seconds]
<sf-slack4> <olof.kindgren> Right, so I have confirmed that 0x40000537 becomes 0x00000537 in the device. Question now is where things go wrong
<sf-slack4> <olof.kindgren> So I did an experiment where I set bit 16 as well, so that my complete word becomes 0x40010537 and compared to 0x00010537. This failed as well. Working theories now is that the top half is not working correctly or that the parity bits get messed up with the data
alexhw has joined #symbiflow
<sf-slack4> <olof.kindgren> I give up for now, but something is definitely wrong here and I guess someone else than me is better suited for figuring out what is wrong
<sf-slack4> <olof.kindgren> ok, one last result. I checked the 17 lowest bits against {1'b1,16'h0537} and that failed as well, so I'm getting increasingly convinced there's some problem with the whole upper 16 bits