<tpb>
Title: GitHub - enjoy-digital/litescope: Small footprint and configurable embedded FPGA logic analyzer (at github.com)
alexhw has quit [Ping timeout: 246 seconds]
alexhw has joined #symbiflow
hzeller_ has quit [Ping timeout: 248 seconds]
hzeller_ has joined #symbiflow
OmniMancer has joined #symbiflow
proteusguy has joined #symbiflow
proteusguy has quit [Ping timeout: 246 seconds]
hzeller_ has quit [Ping timeout: 252 seconds]
proteusguy has joined #symbiflow
adjtm has quit [Ping timeout: 244 seconds]
adjtm has joined #symbiflow
GuzTech has joined #symbiflow
<sf-slack2>
<acomodi> I think it would be good to rebase upstream VTR master on Symbiflow VTR fork, I am going to open a PR with all the (possible) conflicts solved. In addition I would say that we should do this regularly to keep everything updated and reduce the number of possible conflicts
<mithro>
kgugala / mkurc: Is anyone working on adding fasm metadata output to muxgen at the moment?
<hackerfoo>
litghost: Yosys+Vivado? Do we have anything to automate that?
<litghost>
hackerfoo: I don't believe so
<litghost>
hackerfoo: I know people have done it in the past
<hackerfoo>
Can I just feed top_synth.v into Vivado?
<litghost>
hackerfoo: No, as we've already applied VPR specific transformations
<litghost>
hackerfoo: You have two options
<litghost>
hackerfoo: You can either just use the Vivado path (e.g. don't pass "-vpr" to synth_xilinx and don't apply the xc7 VPR techmap)
<litghost>
hackerfoo: Or you can write a techmap to lower from the VPR specific blackboxes to something Vivado understands
<litghost>
hackerfoo: In theory both paths are equivilant, the first is easier to do
<hackerfoo>
Yeah, the first sounds easier. I'll do that. Thanks.
<hackerfoo>
litghost: `grep RAMB18E1 top.eblif` shows nothing for bram_shifter, but does for bram. I don't think I need Vivado to confirm Yosys isn't working, right?
<litghost>
hackerfoo: Yes.
<litghost>
hackerfoo: I guessed that you take the original verilog (not the post-synth verilog) and confirm Vivado synthesized a BRAM
<litghost>
suggested*
<hackerfoo>
It did.
<litghost>
hackerfoo: I believe you confirmed that bram_shifter under vivado did synth a BRAM, but Yosys
<litghost>
hackerfoo: Right, so that points to something in Yosys doing something different
<litghost>
hackerfoo: It is possible that Yosys made a legal transformation of the underlying design such that a BRAM was no longer required
<hackerfoo>
So I should probably compare logs between bram and bram_shifter?
<litghost>
hackerfoo: For example, if Yosys understood that only the first 64 elements would be accessed, then it might emit LUT-RAM's instead
<litghost>
hackerfoo: Yosys (in theory) will only make legal synthesis transformations, and if you aren't actually using enough of the RAM, it might be superior to synthesis the RAM as a LUT-RAM
<litghost>
hackerfoo: Even if we wanted a BRAM
<hackerfoo>
The design does work on hardware. Maybe I should add more to the initialization. It's just weird, because I copy-pasted from bram.
<hackerfoo>
I would think (* ram_style = "block" *) would force Yosys to use block RAM.
<litghost>
hackerfoo: I believe ram_style is a Verilog extension, and I would not be suprised if Yosys does not respect it
<litghost>
hackerfoo: Ya, a quick grep in Yosys shows that ram_style is not supported
<litghost>
hackerfoo: It's an open question if Yosys should support something akin to ram_style or not, but I believe it effecitively always uses "ram_style = best"
<hackerfoo>
I added more entries to the initialization, and still nothing. Either that doesn't do anything, or Yosys figured out that I'm just overwriting it.
<hackerfoo>
It's just stuffing it all in 8xRAM128X1D. I guess that works.
<hackerfoo>
For 64x16bits
<hackerfoo>
I guess I'll have to use the RAMB18E1 primitive, then.
<litghost>
hackerfoo: Ya
<litghost>
hackerfoo: Did you just inadvertently test RAM128X1D?
<hackerfoo>
I think I know why it's not using block RAM. I'm only using one bit out of each entry.
<hackerfoo>
litghost: I already have a shifter test for RAM128X1D.
<litghost>
hackerfoo: Ah, sure
<hackerfoo>
It's cool that it figured that out, though. 1024x1bit fits in 8xRAM128X1D.
<mithro>
hackerfoo: Yosys can produce edif which Vivado reads
<litghost>
hackerfoo: In that case, each output of the mux asserts something, so the absence of a mux selection is valid, in which case no FASM feature is written, and the output of the mux is likely supressed
<litghost>
hackerfoo: In terms of internal muxes, they are selecting from one of many inputs, assuming we used "valid" bit patterns, there will not be multiple drivers
<litghost>
hackerfoo: routing muxes are more "exciting"