Wednesday, 2019-05-08

*** tpb has joined #symbiflow00:00
mithrolitghost: What is the status of
tpbTitle: file_targets.cmake: correctly handle included files by kgugala · Pull Request #688 · SymbiFlow/symbiflow-arch-defs · GitHub (at
*** hzeller has joined #symbiflow00:38
mithrolitghost: Does cmake correctly handle changing of version number for conda dependencies?01:04
mithrolitghost: I'm getting `Unexpected command-line argument '--disable_check_route'`01:04
litghostUnclear, I typically get a conda update in that case01:13
litghostBecause cmake detects a rule change01:13
*** hzeller_ has joined #symbiflow01:17
*** hzeller has quit IRC01:20
*** hzeller_ has quit IRC01:33
hackerfooFYI, CI doesn't seem to re-run automatically when something gets merged afterwards that affects it, so arch-defs #678 should break the build:
tpbTitle: symbiflow-arch-defs/CMakeLists.txt at 97966c24aba60e15686a13effda157a7b1fa9ea1 · SymbiFlow/symbiflow-arch-defs · GitHub (at
hackerfooI fixed it in #68201:35
hackerfooI'm tired of Conda 504 errors breaking tests.01:45
mithrohackerfoo: It's been a lot more unreliable lately...01:50
tpbTitle: Mirroring an Anaconda repository Anaconda 2.0 documentation (at
hackerfooOr we could fix this:
tpbTitle: cmake -DUSE_CONDA=FALSE is broken · Issue #564 · SymbiFlow/symbiflow-arch-defs · GitHub (at
mithrohackerfoo: Yes, we should also fix that....01:52
mithrohackerfoo: There is also and ?01:54
tpbTitle: repository - How do I create a local update server for Anaconda Python? - Super User (at
hackerfooCan we list local channels first, so that it will use local packages when present?01:56
mithrohackerfoo: What do you mean?01:57
hackerfooI'm guessing there's a list of channels in a configuration file from looking at this:
mithrohackerfoo: Yeah01:59
hackerfooI'm also guessing that they are tried in order, starting from the top.01:59
hackerfooAh, yes, it says that.02:00
hackerfooSo if you put a file URL at the top pointing to local packages, it should use those if present.02:01
*** hzeller_ has joined #symbiflow02:08
tpbTitle: GitHub - enjoy-digital/litescope: Small footprint and configurable embedded FPGA logic analyzer (at
*** alexhw has quit IRC05:49
*** alexhw has joined #symbiflow05:50
*** hzeller_ has quit IRC05:53
*** hzeller_ has joined #symbiflow06:02
*** OmniMancer has joined #symbiflow06:42
*** proteusguy has joined #symbiflow06:44
*** proteusguy has quit IRC07:13
*** hzeller_ has quit IRC07:19
*** proteusguy has joined #symbiflow07:29
*** adjtm has quit IRC07:44
*** adjtm has joined #symbiflow08:08
*** GuzTech has joined #symbiflow08:50
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 conflicts08:52
sf-slack2<mkurc> I added an issue related to adding "fasm_mux" support to the V2X:
tpbTitle: Add support for "fasm_mux" in "interconnect" to V2X · Issue #697 · SymbiFlow/symbiflow-arch-defs · GitHub (at
sf-slack2<acomodi> Upstream merge PR is here:
tpbTitle: Merge upstream by acomodi · Pull Request #49 · SymbiFlow/vtr-verilog-to-routing · GitHub (at
*** Akorsvang has quit IRC09:56
*** _whitelogger has quit IRC10:02
*** _whitelogger has joined #symbiflow10:04
*** kraiskil has joined #symbiflow10:35
*** futarisIRCcloud has quit IRC10:37
*** proteusguy has quit IRC11:17
*** proteus-guy has joined #symbiflow11:17
*** proteus-guy has quit IRC11:34
*** kraiskil has quit IRC12:07
*** proteusguy has joined #symbiflow12:12
*** OmniMancer1 has joined #symbiflow12:16
*** OmniMancer has quit IRC12:16
*** kraiskil has joined #symbiflow12:23
*** kraiskil_ has joined #symbiflow12:44
*** kraiskil has quit IRC12:47
*** hzeller_ has joined #symbiflow14:27
*** hzeller_ has quit IRC14:53
*** GuzTech has quit IRC15:19
sf-slack2<acomodi> opened the PR upstream here:
tpbTitle: WIP [DNM]: Equivalent Tiles placement by acomodi · Pull Request #559 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
*** OmniMancer1 has quit IRC15:45
*** kraiskil_ has quit IRC16:22
sf-slack2<acomodi> Good news is that picosoc seems to be working on HW with the equivalent tiles and tile split. Need to double check that though16:26
*** kraiskil_ has joined #symbiflow16:36
hackerfooacomodi: Nice!16:38
*** jevinskie has quit IRC17:16
hackerfooAny ideas why bram_shifter.v ( doesn't use block RAM, where `ram0` was copied from bram.v ( which does use block RAM?18:43
tpbTitle: symbiflow-arch-defs/bram_shifter.v at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghosthackerfoo: Too deep, that test requires a RAMB36E1, not a RAMB18E1 SDP18:45
litghosthackerfoo: Maybe?18:45
litghosthackerfoo: What does Vivado do?18:45
hackerfooI'll try it.18:45
litghosthackerfoo: I'm wrong, that should fit18:46
hackerfooI copied from bram, which uses RAMB1818:48
hackerfooCan Vivado load a .pcf file?18:52
litghosthackerfoo: No it uses tcl or xdc (which is tcl like)18:53
*** kraiskil_ has quit IRC19:29
*** celadon_ has joined #symbiflow20:23
*** proteusguy has quit IRC20:23
*** celadon has quit IRC20:23
hackerfoolitghost: Vivado uses a RAMB18E1 for bram_shifter.v20:23
litghosthackerfoo: Okay, so that points to some kind of yosys issue.  Check if it's our techmap by doing the standard Yosys flow only20:24
hackerfooAlso, I made this which automatically creates Vivado projects from a list of Verilog files:
tpbTitle: hackerfoo-go-functions/symbiflow at master · HackerFoo/hackerfoo-go-functions · GitHub (at
hackerfooIt's pretty basic, but it works.20:27
*** proteusguy has joined #symbiflow20:36
mithrokgugala / mkurc: Is anyone working on adding fasm metadata output to muxgen at the moment?22:07
hackerfoolitghost: Yosys+Vivado? Do we have anything to automate that?22:22
litghosthackerfoo: I don't believe so22:22
litghosthackerfoo: I know people have done it in the past22:22
hackerfooCan I just feed top_synth.v into Vivado?22:23
litghosthackerfoo: No, as we've already applied VPR specific transformations22:25
litghosthackerfoo: You have two options22:25
litghosthackerfoo: 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)22:25
litghosthackerfoo: Or you can write a techmap to lower from the VPR specific blackboxes to something Vivado understands22:26
litghosthackerfoo: In theory both paths are equivilant, the first is easier to do22:26
hackerfooYeah, the first sounds easier. I'll do that. Thanks.22:27
hackerfoolitghost: `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?22:49
litghosthackerfoo: Yes.22:49
litghosthackerfoo: I guessed that you take the original verilog (not the post-synth verilog) and confirm Vivado synthesized a BRAM22:50
hackerfooIt did.22:50
litghosthackerfoo: I believe you confirmed that bram_shifter under vivado did synth a BRAM, but Yosys22:50
litghosthackerfoo: Right, so that points to something in Yosys doing something different22:50
litghosthackerfoo: It is possible that Yosys made a legal transformation of the underlying design such that a BRAM was no longer required22:51
hackerfooSo I should probably compare logs between bram and bram_shifter?22:51
litghosthackerfoo: For example, if Yosys understood that only the first 64 elements would be accessed, then it might emit LUT-RAM's instead22:51
litghosthackerfoo: 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-RAM22:52
litghosthackerfoo: Even if we wanted a BRAM22:52
hackerfooThe design does work on hardware. Maybe I should add more to the initialization. It's just weird, because I copy-pasted from bram.22:52
hackerfooI would think (* ram_style = "block" *) would force Yosys to use block RAM.22:53
litghosthackerfoo: I believe ram_style is a Verilog extension, and I would not be suprised if Yosys does not respect it22:56
litghosthackerfoo: Ya, a quick grep in Yosys shows that ram_style is not supported23:01
litghosthackerfoo: 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"23:02
hackerfooI 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.23:02
hackerfooIt's just stuffing it all in 8xRAM128X1D. I guess that works.23:07
hackerfooFor 64x16bits23:07
hackerfooI guess I'll have to use the RAMB18E1 primitive, then.23:08
litghost hackerfoo: Ya23:14
litghosthackerfoo: Did you just inadvertently test RAM128X1D?23:17
hackerfooI think I know why it's not using block RAM. I'm only using one bit out of each entry.23:18
hackerfoolitghost: I already have a shifter test for RAM128X1D.23:18
litghosthackerfoo: Ah, sure23:18
hackerfooIt's cool that it figured that out, though. 1024x1bit fits in 8xRAM128X1D.23:19
mithrohackerfoo: Yosys can produce edif which Vivado reads23:20
mithrohackerfoo: This python script generates Yosys -> Vivado flow
tpbTitle: litex/ at master · enjoy-digital/litex · GitHub (at
tpbTitle: Snippet | IRCCloud (at
hackerfooI don't think the result would be any different from Yosys+VPR, although it seems Yosys is smarter than Vivado in this case.23:23
mithrohackerfoo: Memory inference is one area that Yosys seems to be better than other tools23:23
*** futarisIRCcloud has joined #symbiflow23:24
litghosthackerfoo/mithro : Vivado was specifically instructed to emit a BRAM, and that is what it did23:25
litghosthackerfoo/mithro: Yosys ignored (and doesn't understand) the instruction23:25
hackerfoolitghost: True. I'll see what happens without the annotation.23:26
mithroI'm not following the full chat - just throwing random comments in...23:26
hackerfooVivado still uses RAMB18E1. I don't know whether that's the right choice or not. The answer is probably "it depends."23:29
hackerfooAlthough distributed RAM's faster, right?23:30
litghosthackerfoo: Depends23:33
litghosthackerfoo: I believe BRAM is less power efficient?23:33
litghosthackerfoo: And speed is relative to placement23:34
hackerfooIs there an easier way than {x, x, ... (16 times)} in Verilog to fan out a wire?23:47
hackerfooNow I'm getting a RAMB18E1.23:47
litghosthackerfoo: Yes!23:51
tpbTitle: verilog - Whats the best way to create a mask knowing the number of bits? - Stack Overflow (at
litghosthackerfoo: Very usefully, but I never remember the syntax off the top of my head23:51
litghosthackerfoo: I always just google it23:51
hackerfoolitghost: Thanks23:52
mithrolitghost: Do I recall you "discovered" that a `<direct>`interconnect doesn't mean "always connected" but is a mux?23:54
litghostmithro: Yes23:54
litghostmithro: With the additional caveat that it was in a "unconnected" blackbox pin23:55
tpbTitle: Snippet | IRCCloud (at
litghostmithro: What's the question?23:55
mithroWhen COMMON_SLICE.AX is used you don't output any FASM features?23:55
litghostmithro: That is currently correct, we do not have the zero feature23:56
litghostmithro: I believe hackerfoo added an issue on this23:56
mithrolitghost: You mean it is missing from the prjxray FASM database?23:56
hackerfoo<direct> is more of a switch.23:56
tpbTitle: Add feature for each input of a mux · Issue #817 · SymbiFlow/prjxray · GitHub (at
litghosthackerfoo: <direct> and <mux> are actually identical under the hood23:56
litghost<mux> has slightly more legilable .net output23:57
hackerfooThat's how I understood it. Does <mux> support being disconnected, then?23:58
litghosthackerfoo: Yes23:58
litghost<mux> can select "nothing"23:58
hackerfooThat seems problematic if the hardware can't do that.23:59
litghosthackerfoo: The output of the mux from VPR's standpoint is "don't care' or "undefined"23:59
litghosthackerfoo: Not really, as long as something isolates the downstream signal23:59
litghosthackerfoo: Which usually happens as soon as the routing fabric is encountered23:59

Generated by 2.13.1 by Marius Gedminas - find it at!