celadon_ has quit [Quit: ZNC 1.7.2+deb1 - https://znc.in]
celadon has joined #symbiflow
_whitelogger has joined #symbiflow
celadon_ has joined #symbiflow
celadon has quit [Ping timeout: 246 seconds]
Bertl_zZ is now known as Bertl
<sf-slack1>
<mkurc> The most up-to-date Yosys on Symbiflow repo does not infer BRAM (or other type of memory) correctly. It should do when defining an array in verilog and initializing it using `initial` statemets. I've created an issue: https://github.com/SymbiFlow/yosys/issues/17
<tpb>
Title: Yosys cannot infer BRAM correctly on current master+wip · Issue #17 · SymbiFlow/yosys · GitHub (at github.com)
<sxpert>
have something related, Warning: Replacing memory \hex with list of registers. See saturn_debugger.v:152
<sxpert>
hex is an array of bytes, should be a couple of 16x4 distributed rams
<tpb>
Title: Use mem2reg on memories that only have constant-index write ports by cliffordwolf · Pull Request #843 · YosysHQ/yosys · GitHub (at github.com)
<daveshah>
sxpert: in any case, a ROM will never be mapped to distributed RAM, as it is more efficient just to use LUTs
<daveshah>
sxpert: although I think it triggers this bug too, your case will always end up as LUTs
<sf-slack1>
<mkurc> Yeah, I've stumbled upon the problem while trying to place program memory for Picosoc in BRAM. I always ended up with it in LUTs.
<sf-slack1>
<mkurc> I'll check that commit
felix__ has joined #symbiflow
felix_ has quit [*.net *.split]
<sf-slack1>
<mkurc> @sxpert You are right. The PR #843 to YosysHQ changes the behavior and the memory is no longer inferred when it is a ROM.
<daveshah>
Probably best if you create a GitHub issue upstream with your testcase
<sf-slack1>
<mkurc> Posted the file again in a comment
<sxpert>
ah there
<sxpert>
guess it takes some time to replicate within github's infrastructure
<daveshah>
mkurc: if you are curious, the main purpose of #843 was to fix cases where an array was being used as an array of signals rather than a memory, rather than as an optimisation per se
<daveshah>
I think the solution will be to not apply it where the constant writes are in an initial
<sf-slack1>
<mkurc> Ok, I see.
celadon_ has quit [Quit: ZNC 1.7.2+deb1 - https://znc.in]
celadon has joined #symbiflow
<mithro>
@mkurc: Did my comment on vtr #17 make sense?
<sf-slack1>
<mkurc> @mithro Yes, it does.
<mithro>
mkurc: So the two things should be implemented without interacting with each other
citypw has quit [Ping timeout: 272 seconds]
<sf-slack1>
<mkurc> Right, now it is clear for me
<mithro>
The pip fuzzers seem to have been really flaky lately?
<mithro>
litghost: The .patch file seems to be working okay!
<litghost>
duck2: FYI, we are relatively close to no longer needing the ROI harness, maybe 1 or 2 months?
<litghost>
duck2: If you are interested in helping with removing the need for the ROI harness, I can point you at issues required to remove the harness.
<duck2>
i think i saw the issues while exploring but had a hard time understanding why is a harness needed
<duck2>
is it so we generate the bitstream for the part we know about and place it inside a "general" bitstream generated by vivado?
<litghost>
duck2: Two reasons, IOBs and CLK trees
<litghost>
duck2: We are missing some segbits for CLKs, are missing synthesis of both IOBs and CLK trees, and do not have place and route support for IOBs and CLK trees
<litghost>
duck2: The ROI harness handles these things
<mithro>
litghost: Do you have a doc which explains the dataflow with the new sqlite process? It seems like you generate the edges into the `graph_edge` table?