Wednesday, 2019-05-01

*** tpb has joined #symbiflow00:00
hackerfooI'm trying to figure out why there are no RAM features set in fasm after this change:
tpbTitle: [WIP] reducing RAM primitives to DPRAM32/64 by HackerFoo · Pull Request #663 · SymbiFlow/symbiflow-arch-defs · GitHub (at
hackerfooAny tips?00:35
hackerfooIt's weird, because the RAMs seem to have just disappeared entirely from ram_shifter_*1xs, but no errors. I can't find the INIT bit pattern either.00:38
hackerfooMaybe the problem is in Yosys, because the eblif looks different.00:39
litghosthackerfoo: Does the eblif has the right blackbox's?00:50
*** Bertl_oO is now known as Bertl_zZ01:04
hackerfooI can't even find the .cname for the ram.01:05
litghosthuh, ya that sounds like a yosys bug01:07
litghostdid you update the cells_sim.v file?01:07
hackerfooThere's no RAM .subckt01:07
litghostSo not a yosys bug, but a techmap issue01:07
hackerfooI just did. I thought that was only for simulation?01:07
litghostYosys uses it for defining blackbox's01:08
litghostYosys tends to just eat poorly defined techmaps, something to watch for01:09
litghostit will vomit in the Yosys log01:09
hackerfooThanks. Now I see it in the eblif and fasm.01:20
*** citypw has quit IRC01:23
*** citypw has joined #symbiflow01:24
hackerfooI have RAM32X1S working on hardware!01:25
hackerfooNow I have to fix up the dual port RAMs.01:26
hackerfooRAM64X1D works, but RAM32X1D is broken the same way it was before. At least I fixed X1S.01:36
*** futarisIRCcloud has joined #symbiflow01:52
elmshackerfoo: woot! Progress03:58
hackerfooRAM32X1S now passes through VPR->fasm2v->Vivado->bitstream without errors. I'm going to load it and see what happens.04:00
hackerfooDoesn't work.04:07
elmshackerfoo: you can take it back to fasm and compare right?04:11
hackerfooYeah, I could do that later, but I really want to get RAM32X1D working, which is what I meant to run through Vivado. It gives and error, though.04:12
hackerfooERROR: [Vivado 12-2285] Cannot set LOC property of instance 'CLBLM_R_X11Y110_SLICE_X14Y110_RAM32X1D_CD',  for bel C6LUT Element SLICE_X14Y110.C5LUT can not be used as a route-through for net CLBLL_R_X13Y110_SLICE_X18Y110_AMUX taged to C5LUT_O5 because a RAM or shift register is placed there04:13
*** lopsided98_ is now known as lopsided9804:16
hackerfooThe `_CD` seems weird. I can't find anything on it, except RAM128X1S_CD in clb_models.py04:19
elmshackerfoo: Is that ganging the C and D LUTs?04:29
hackerfooThat would be my guess, but I'm only using one.04:30
* hackerfoo sent a long message: < >04:31
hackerfooIt's using C and D, and not able to route that for some reason.04:31
hackerfooOh yeah, I am using them both since it's dual port.04:31
elmslooks like it can be AB, or BC, or CD from
tpbTitle: symbiflow-arch-defs/ at 28c64dc905426c56210ce70bc53e0b8cc2a5a9dc · HackerFoo/symbiflow-arch-defs · GitHub (at
hackerfooAh, thanks. It's highly ungreppable.04:34
elmsI was wrong about BC as an option as it is only for LUT B and D as the later
tpbTitle: symbiflow-arch-defs/ at 28c64dc905426c56210ce70bc53e0b8cc2a5a9dc · HackerFoo/symbiflow-arch-defs · GitHub (at
elmsstill doesn't help with that error. What is CLBLL_R_X13Y110_SLICE_X18Y110_AMUX in the design?04:36
litghostThe output wire from the slice04:36
litghostFrom a slice04:37
elmsok and it's trying to route through the slice used for the RAM. I guess I'm wondering if there is something the understand from what that net is the the design.04:40
elmsMay be it doesn't matter, but it points to the RAM32x1D not correctly excluding that in VPR.04:41
hackerfooFunny, sometimes the error is different? ERROR: [Vivado 12-2285] Cannot set LOC property of instance 'CLBLM_R_X11Y110_SLICE_X14Y110_RAM32X1D_CD',  for bel C6LUT Element SLICE_X14Y110.CFFMUX is not routable04:41
hackerfooNondeterministic errors are never boring.04:41
elmsAre you just rerunning just vivado? or through VPR as well.04:42
hackerfooI re-ran VPR when it changed. It seems to be the same from just re-running Vivado.04:46
elmsgood. place and route (eg Synthetic annealing) is pseudo-random. You can record the seed if you need to reproduce. I have not looked at how to do this with VPR.04:48
hackerfooNevermind. The second one was my fault. I switched SPO/DPO to see if that had anything to do with it.04:48
hackerfooIt's just me that's nondeterministic.04:49
hackerfooAMUX seems to be addr[0] ->
tpbTitle: symbiflow-arch-defs/dram_shifter_32x1d.v at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
hackerfooIt looks like what we're calling DPRAM32 is called RAMD32 by Vivado.05:11
* hackerfoo sent a long message: < >05:12
*** hzeller has quit IRC07:00
hackerfooIt's something to do with the packing, because I removed the stub from RAM32X1D in the techmap and it works! Almost. The address is off by 5, but otherwise it works.07:21
hackerfooSomehow one of the SMALL bits are missing in the FASM.07:33
*** kraiskil has joined #symbiflow08:00
*** OmniMancer has joined #symbiflow08:07
*** kraiskil has quit IRC08:13
*** GuzTech has joined #symbiflow08:16
*** kraiskil has joined #symbiflow08:34
hackerfooHoly shift registers, all of RAM{32,64]X1{S,D} work on hardware! Thanks for the help everyone.08:39
tpbTitle: [WIP] reducing RAM primitives to DPRAM32/64 by HackerFoo · Pull Request #663 · SymbiFlow/symbiflow-arch-defs · GitHub (at
*** kraiskil has quit IRC08:39
*** citypw has quit IRC08:56
hackerfooI found a list of the names used by Xilinx:
tpbTitle: RapidWright/ at master · Xilinx/RapidWright · GitHub (at
*** citypw has joined #symbiflow09:16
*** kraiskil has joined #symbiflow09:47
*** _whitelogger has quit IRC10:20
*** _whitelogger has joined #symbiflow10:22
*** futarisIRCcloud has quit IRC11:11
*** kraiskil has quit IRC11:33
*** Bertl_zZ is now known as Bertl11:55
*** kraiskil has joined #symbiflow13:10
*** alexhw[m] has joined #symbiflow13:42
*** space_zealot has quit IRC14:00
*** kraiskil has quit IRC14:28
*** hzeller has joined #symbiflow14:28
*** kraiskil has joined #symbiflow14:29
*** OmniMancer has quit IRC14:46
*** kraiskil has quit IRC14:51
*** hzeller has quit IRC14:53
*** GuzTech has quit IRC14:59
*** kraiskil has joined #symbiflow15:03
mithrokgugala: did those examples for v2x help?15:05
*** space_zealot has joined #symbiflow15:07
sf-slack2<kgugala> @mithro Yes, they are. I'm still going through them. I'll have more time to work on that in a few hours15:10
mithrokgugala: I need to do some more which are composite modules15:11
mithrokgugala: and more tests for the association for clocked inputs / outputs15:12
*** kraiskil has quit IRC15:14
sf-slack2<kgugala> + some that instantiate the above so we can test if the clock signals are correctly inferred in the top level15:36
*** kraiskil has joined #symbiflow18:36
mithrokgugala: So the is_registered function seems wrong18:52
sf-slack2<kgugala> @mithro yes18:52
sf-slack2<kgugala> I think to solve this properly we should follow the connection path from considered input to the first $dff18:53
sf-slack2<kgugala> I mean the `is_registered` function should do that18:54
mithrokgugala: You should be using yosys for this18:57
mithrokgugala: See for example18:58
tpbTitle: symbiflow-arch-defs/ at dc45861228a81ade14f22d828856a575f9b471d9 · SymbiFlow/symbiflow-arch-defs · GitHub (at
mithro# Find things which affect the given output18:59
mithro# show w:*D_IN_0 %a %ci*18:59
sf-slack2<kgugala> thanks, I was about to ask for an example18:59
sf-slack2<kgugala> this is really helpful18:59
tpbTitle: Yosys Open SYnthesis Suite :: Command Reference :: select (at
*** adjtm has quit IRC19:04
mithrokgugala: Things seem to work better when you do that reg change...19:16
mithrokgugala: Looking at how we can make that warning an error19:17
sf-slack2<kgugala> Yosys stops complaining about assigning a wire i always block19:18
*** adjtm has joined #symbiflow19:25
sf-slack2<kgugala> @mithro can we assume the if an output is affected by an input, and the output has an associated clock, the input should also have this clock associated?19:28
*** tux3 has quit IRC20:05
*** tux3 has joined #symbiflow20:07
mithrokgugala: Unsure20:30
sf-slack2<kgugala> I implemented such approach and it doesn't seem to break other tests20:33
sf-slack2<kgugala> I'll push that in a minute20:33
*** kraiskil has quit IRC20:34
mithrokgugala: I pushed an update to how yosys runs20:44
*** Bertl is now known as Bertl_oO20:47
sf-slack2<kgugala> yeah I see that20:47
sf-slack2<kgugala> @mthro I see you push-forced the v2x-clock-tests20:48
sf-slack2<kgugala> it conflicts with mine changes, I resolved the conflicts, but it'd be nicer if I rebase the whole thing20:49
sf-slack2<kgugala> this will require push -f20:49
mithrokgugala: I think the issue is on
tpbTitle: symbiflow-arch-defs/ at dc45861228a81ade14f22d828856a575f9b471d9 · SymbiFlow/symbiflow-arch-defs · GitHub (at
mithrokgugala: Were where your changes?20:51
sf-slack2<kgugala> in dff_two_clocks (both verilog and golden_model)20:51
mithrokgugala: I mean which repo were you pushing too?20:52
sf-slack2<kgugala> I just pushed the changes without rebasing20:52
sf-slack2<kgugala> @mithro see this commit
tpbTitle: vlog_to_model: correctly handle clock association and multiple clks · mithro/[email protected] · GitHub (at
sf-slack2<kgugala> it fixes the #66720:53
sf-slack2<kgugala> ale also handles multiple clock association20:53
mithrokgugala: You should push your version of my branch to another repo too20:54
mithroOtherwise I can't access the commits20:55
sf-slack2<kgugala> the changes you made there were actually doing the same I did (I defined the verilog outputs as regs)20:55
sf-slack2<kgugala> I just resolved the conficts there20:55
sf-slack2<kgugala> @mithro the relevant change is in the commit I linked above20:57
sf-slack2<kgugala> + golden model change so it fits what is generated by the script20:58
mithrokgugala: Sure, but if you push to your own repo, then I won't accidentally push over the top of your changes :-)21:00
mithrokgugala: I rebased your changes21:07
sf-slack2<kgugala> I see21:09
sf-slack2<kgugala> I pushed the dff_two_clocks golden model update21:09
sf-slack2<kgugala> it's cosmetic21:10
mithrokgugala: Why is your change needed?21:11
sf-slack2<kgugala> @mithro what do you think about the
tpbTitle: WIP: v2x clock tests by mithro · Pull Request #664 · SymbiFlow/symbiflow-arch-defs · GitHub (at
sf-slack2<kgugala> it switches c1 and c2 for port b (it's cosmetic, but that was causing diff to fail)21:12
mithrokgugala: Is cmake not running the golden model through xmlsort.xml ?21:12
sf-slack2<kgugala> I generated new golden model with 'update_golden_model' target21:12
sf-slack2<kgugala> @mithro, yes it is but it does not fix this:21:13
sf-slack2<kgugala> -      <port clock="c1 c2" combinational_sink_ports="o2 o1" name="b"/>                                                 +      <port clock="c2 c1" combinational_sink_ports="o2 o1" name="b"/>21:14
sf-slack2<kgugala> c1 and c2 are switched21:14
sf-slack2<kgugala> as I said it is cosmetic21:14
tpbTitle: Include the v2x model + pb_type xml files into VPR architecture XML file and check VPR can load it · Issue #668 · SymbiFlow/symbiflow-arch-defs · GitHub (at
*** space_zealot has quit IRC21:17
*** space_zealot has joined #symbiflow21:17
mithrokgugala: I'll work on #668 if you are working on the v2x stuff21:31
sf-slack2<kgugala> Ok21:34
*** space_zealot has quit IRC21:39
*** space_zealot has joined #symbiflow21:40
hackerfooHow can I set a FASM feature based on the input to a mux in VPR? Do I need to use modes instead?22:40
hackerfooI can see the equivalent to what I want for <direct>22:41
litghostYou mean fasm_mux?22:42
tpbTitle: symbiflow-arch-defs/common_slice.pb_type.xml at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
hackerfooThanks, I think so. Is the synax a list of "<input> = <fasm feature name>"?22:45
hackerfooAnd I guess "NULL" is a keyword for not adding anything.22:46
elmshackerfoo: I think that is accepted, but use `input : feature` as shown here
tpbTitle: vtr-verilog-to-routing/test_fasm_arch.xml at master+wip · SymbiFlow/vtr-verilog-to-routing · GitHub (at
tpbTitle: symbiflow-arch-defs/common_slice.pb_type.xml at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostNONE is actually the keyword, not NULL22:57
litghostSorry, NULL is correct, opps22:58
litghostMight be some errors at L30622:58
hackerfooelms: Why use `input : feature`? `input = feature` is used everywhere else.22:59
hackerfooIf we're changing the syntax, I suggest `->` or `=>`.23:01
elmsBoth are supported and I think we should go back and change existing uses.23:01
hackerfooInconsistency is worst:
tpbTitle: vtr-verilog-to-routing/fasm.rst at master · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
hackerfooIf we're going to change it, it's probably best to do in a single PR.23:05
hackerfooAs much as possible, at least.23:06
elmsthat's valid.23:06
*** space_zealot has quit IRC23:07
litghostFor now, stay consistent with the XML's around it.  I believe ice40 is using the ":" and xc7 is using "=".23:07
litghosthackerfoo: We cannot use ">" because XML23:07
litghosthackerfoo: Much sadness23:08
elmsmaybe this is a better link for the FASM in VPR
tpbTitle: FPGA Assembly (FASM) Output Support Verilog-to-Routing 8.0.0-dev documentation (at
litghostelms: Yes23:08
hackerfooCan I use the output of a mux directly as the input to another? "Message: Syntax error processing port string 'B_DRAM.DI1 SLICEM_MODES.AI' (output from interconnect from parent is not an input or clock pin)"23:08
*** synaption[m] has joined #symbiflow23:09
litghosthackerfoo: Nope23:09
litghosthackerfoo: That's the reason for the "PARENT_DI" stuff23:09
litghosthackerfoo: It is simply converting the input port to an output port23:09
litghosthackerfoo: Or vise-versa23:10
litghosthackerfoo: Been a while since I messed with this stuff23:10
hackerfooI guess I need an internal wire.23:12
elmslitghost: has there been any discussion around how to support different speed grades?23:22
litghostelms: Funny that you mention it23:22
tpbTitle: PVT corner timing models · Issue #551 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
litghostelms: Speed grades are just another take on the corner analysis, kind of23:23
litghostelms: If VPR supported multiple corners, and we could select which corners we used in analysis, that would cover speed grades23:24
elmslitghost: makes sense. Last week I thought about it and realized forking pb_types would be terrible. Do you think the difference in speed grades are uniform enough to have little impact on PnR?23:26
litghostelms: Hard to say, I lack an intuition on that topic23:26
elmsIf it just adds constants I would imagine little impact on the routing for example. It would impact fmax.23:27
litghostelms: Given that we are controlling the import, we can just emit pbtypes and rrgraphs at a particular speed grade, yes?23:27
elmslitghost: yes, but we would have to generate one for each grade which would be mostly identical except for the timing. Or just emit for 1 speed grade and say that's good enough for now.23:54
litghostelms: I don't think we are going to be able to avoid that without a symbolic solution to
tpbTitle: PVT corner timing models · Issue #551 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
elmslitghost: I think this points to another aspect that could be optimized in the representation format. We will want an 1:N mapping for timing. Yes I agree about that issue. But I think as we look forward to other formats, it will be better to separate them to a separate data structure23:57
litghostelms: Sure, which is what I mean by a symbolic solution, e.g. a side lookup23:57

Generated by 2.13.1 by Marius Gedminas - find it at!