| *** tpb has joined #symbiflow | 00:00 | |
| hackerfoo | I'm trying to figure out why there are no RAM features set in fasm after this change: https://github.com/SymbiFlow/symbiflow-arch-defs/pull/663 | 00:35 |
|---|---|---|
| tpb | Title: [WIP] reducing RAM primitives to DPRAM32/64 by HackerFoo · Pull Request #663 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 00:35 |
| hackerfoo | Any tips? | 00:35 |
| hackerfoo | It'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 |
| hackerfoo | Maybe the problem is in Yosys, because the eblif looks different. | 00:39 |
| litghost | hackerfoo: Does the eblif has the right blackbox's? | 00:50 |
| *** Bertl_oO is now known as Bertl_zZ | 01:04 | |
| hackerfoo | I can't even find the .cname for the ram. | 01:05 |
| litghost | huh, ya that sounds like a yosys bug | 01:07 |
| litghost | did you update the cells_sim.v file? | 01:07 |
| hackerfoo | There's no RAM .subckt | 01:07 |
| litghost | So not a yosys bug, but a techmap issue | 01:07 |
| litghost | Sorry* | 01:07 |
| hackerfoo | I just did. I thought that was only for simulation? | 01:07 |
| litghost | Yosys uses it for defining blackbox's | 01:08 |
| litghost | Yosys tends to just eat poorly defined techmaps, something to watch for | 01:09 |
| litghost | it will vomit in the Yosys log | 01:09 |
| hackerfoo | Thanks. Now I see it in the eblif and fasm. | 01:20 |
| *** citypw has quit IRC | 01:23 | |
| *** citypw has joined #symbiflow | 01:24 | |
| hackerfoo | I have RAM32X1S working on hardware! | 01:25 |
| hackerfoo | Now I have to fix up the dual port RAMs. | 01:26 |
| hackerfoo | RAM64X1D works, but RAM32X1D is broken the same way it was before. At least I fixed X1S. | 01:36 |
| *** futarisIRCcloud has joined #symbiflow | 01:52 | |
| elms | hackerfoo: woot! Progress | 03:58 |
| hackerfoo | RAM32X1S now passes through VPR->fasm2v->Vivado->bitstream without errors. I'm going to load it and see what happens. | 04:00 |
| hackerfoo | Doesn't work. | 04:07 |
| elms | :/ | 04:10 |
| elms | hackerfoo: you can take it back to fasm and compare right? | 04:11 |
| hackerfoo | Yeah, 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 |
| hackerfoo | ERROR: [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 there | 04:13 |
| *** lopsided98_ is now known as lopsided98 | 04:16 | |
| hackerfoo | The `_CD` seems weird. I can't find anything on it, except RAM128X1S_CD in clb_models.py | 04:19 |
| elms | hackerfoo: Is that ganging the C and D LUTs? | 04:29 |
| hackerfoo | That would be my guess, but I'm only using one. | 04:30 |
| * hackerfoo sent a long message: < http://sandbox.hackerfoo.com:8008/_matrix/media/v1/download/sandbox.hackerfoo.com/qMvtIrElnWQcXaXSmfzjAPdd > | 04:31 | |
| hackerfoo | It's using C and D, and not able to route that for some reason. | 04:31 |
| hackerfoo | Oh yeah, I am using them both since it's dual port. | 04:31 |
| elms | looks like it can be AB, or BC, or CD from https://github.com/HackerFoo/symbiflow-arch-defs/blob/28c64dc905426c56210ce70bc53e0b8cc2a5a9dc/xc7/fasm2bels/clb_models.py#L492 | 04:32 |
| tpb | Title: symbiflow-arch-defs/clb_models.py at 28c64dc905426c56210ce70bc53e0b8cc2a5a9dc · HackerFoo/symbiflow-arch-defs · GitHub (at github.com) | 04:32 |
| hackerfoo | Ah, thanks. It's highly ungreppable. | 04:34 |
| elms | agree | 04:34 |
| elms | I was wrong about BC as an option as it is only for LUT B and D as the later https://github.com/HackerFoo/symbiflow-arch-defs/blob/28c64dc905426c56210ce70bc53e0b8cc2a5a9dc/xc7/fasm2bels/clb_models.py#L455 | 04:35 |
| tpb | Title: symbiflow-arch-defs/clb_models.py at 28c64dc905426c56210ce70bc53e0b8cc2a5a9dc · HackerFoo/symbiflow-arch-defs · GitHub (at github.com) | 04:35 |
| elms | still doesn't help with that error. What is CLBLL_R_X13Y110_SLICE_X18Y110_AMUX in the design? | 04:36 |
| litghost | The output wire from the slice | 04:36 |
| litghost | From a slice | 04:37 |
| elms | ok 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 |
| elms | May be it doesn't matter, but it points to the RAM32x1D not correctly excluding that in VPR. | 04:41 |
| hackerfoo | Funny, 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 routable | 04:41 |
| hackerfoo | Nondeterministic errors are never boring. | 04:41 |
| elms | Are you just rerunning just vivado? or through VPR as well. | 04:42 |
| hackerfoo | I re-ran VPR when it changed. It seems to be the same from just re-running Vivado. | 04:46 |
| elms | good. 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 |
| hackerfoo | Nevermind. The second one was my fault. I switched SPO/DPO to see if that had anything to do with it. | 04:48 |
| hackerfoo | It's just me that's nondeterministic. | 04:49 |
| hackerfoo | AMUX seems to be addr[0] -> https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/tests/dram_shifter/dram_shifter_32x1d.v#L16 | 05:08 |
| tpb | Title: symbiflow-arch-defs/dram_shifter_32x1d.v at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 05:08 |
| hackerfoo | It looks like what we're calling DPRAM32 is called RAMD32 by Vivado. | 05:11 |
| * hackerfoo sent a long message: < http://sandbox.hackerfoo.com:8008/_matrix/media/v1/download/sandbox.hackerfoo.com/KWEFqqwHiqxTdzBNneRusluC > | 05:12 | |
| *** hzeller has quit IRC | 07:00 | |
| hackerfoo | It'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 |
| hackerfoo | Somehow one of the SMALL bits are missing in the FASM. | 07:33 |
| *** kraiskil has joined #symbiflow | 08:00 | |
| *** OmniMancer has joined #symbiflow | 08:07 | |
| *** kraiskil has quit IRC | 08:13 | |
| *** GuzTech has joined #symbiflow | 08:16 | |
| *** kraiskil has joined #symbiflow | 08:34 | |
| hackerfoo | Holy shift registers, all of RAM{32,64]X1{S,D} work on hardware! Thanks for the help everyone. | 08:39 |
| hackerfoo | https://github.com/SymbiFlow/symbiflow-arch-defs/pull/663 | 08:39 |
| tpb | Title: [WIP] reducing RAM primitives to DPRAM32/64 by HackerFoo · Pull Request #663 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 08:39 |
| *** kraiskil has quit IRC | 08:39 | |
| *** citypw has quit IRC | 08:56 | |
| hackerfoo | I found a list of the names used by Xilinx: https://github.com/Xilinx/RapidWright/blob/master/com/xilinx/rapidwright/design/Unisim.java | 09:10 |
| tpb | Title: RapidWright/Unisim.java at master · Xilinx/RapidWright · GitHub (at github.com) | 09:10 |
| *** citypw has joined #symbiflow | 09:16 | |
| *** kraiskil has joined #symbiflow | 09:47 | |
| *** _whitelogger has quit IRC | 10:20 | |
| *** _whitelogger has joined #symbiflow | 10:22 | |
| *** futarisIRCcloud has quit IRC | 11:11 | |
| *** kraiskil has quit IRC | 11:33 | |
| *** Bertl_zZ is now known as Bertl | 11:55 | |
| *** kraiskil has joined #symbiflow | 13:10 | |
| *** alexhw[m] has joined #symbiflow | 13:42 | |
| *** space_zealot has quit IRC | 14:00 | |
| *** kraiskil has quit IRC | 14:28 | |
| *** hzeller has joined #symbiflow | 14:28 | |
| *** kraiskil has joined #symbiflow | 14:29 | |
| *** OmniMancer has quit IRC | 14:46 | |
| *** kraiskil has quit IRC | 14:51 | |
| *** hzeller has quit IRC | 14:53 | |
| *** GuzTech has quit IRC | 14:59 | |
| *** kraiskil has joined #symbiflow | 15:03 | |
| mithro | kgugala: did those examples for v2x help? | 15:05 |
| *** space_zealot has joined #symbiflow | 15: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 hours | 15:10 |
| mithro | kgugala: I need to do some more which are composite modules | 15:11 |
| mithro | kgugala: and more tests for the association for clocked inputs / outputs | 15:12 |
| *** kraiskil has quit IRC | 15:14 | |
| sf-slack2 | <kgugala> + some that instantiate the above so we can test if the clock signals are correctly inferred in the top level | 15:36 |
| *** kraiskil has joined #symbiflow | 18:36 | |
| mithro | kgugala: So the is_registered function seems wrong | 18:52 |
| sf-slack2 | <kgugala> @mithro yes | 18:52 |
| sf-slack2 | <kgugala> I think to solve this properly we should follow the connection path from considered input to the first $dff | 18:53 |
| sf-slack2 | <kgugala> I mean the `is_registered` function should do that | 18:54 |
| mithro | kgugala: You should be using yosys for this | 18:57 |
| mithro | kgugala: See https://github.com/SymbiFlow/symbiflow-arch-defs/blob/dc45861228a81ade14f22d828856a575f9b471d9/utils/vlog/yosys/run.py#L206-L213 for example | 18:58 |
| tpb | Title: symbiflow-arch-defs/run.py at dc45861228a81ade14f22d828856a575f9b471d9 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 18:58 |
| mithro | # Find things which affect the given output | 18:59 |
| mithro | # show w:*D_IN_0 %a %ci* | 18:59 |
| sf-slack2 | <kgugala> thanks, I was about to ask for an example | 18:59 |
| sf-slack2 | <kgugala> this is really helpful | 18:59 |
| mithro | kgugala: http://www.clifford.at/yosys/cmd_select.html | 19:00 |
| tpb | Title: Yosys Open SYnthesis Suite :: Command Reference :: select (at www.clifford.at) | 19:00 |
| *** adjtm has quit IRC | 19:04 | |
| mithro | kgugala: Things seem to work better when you do that reg change... | 19:16 |
| mithro | kgugala: Looking at how we can make that warning an error | 19:17 |
| sf-slack2 | <kgugala> Yosys stops complaining about assigning a wire i always block | 19:18 |
| *** adjtm has joined #symbiflow | 19: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 IRC | 20:05 | |
| *** tux3 has joined #symbiflow | 20:07 | |
| mithro | kgugala: Unsure | 20:30 |
| sf-slack2 | <kgugala> I implemented such approach and it doesn't seem to break other tests | 20:33 |
| sf-slack2 | <kgugala> I'll push that in a minute | 20:33 |
| *** kraiskil has quit IRC | 20:34 | |
| mithro | kgugala: I pushed an update to how yosys runs | 20:44 |
| *** Bertl is now known as Bertl_oO | 20:47 | |
| sf-slack2 | <kgugala> yeah I see that | 20:47 |
| sf-slack2 | <kgugala> @mthro I see you push-forced the v2x-clock-tests | 20:48 |
| sf-slack2 | <kgugala> it conflicts with mine changes, I resolved the conflicts, but it'd be nicer if I rebase the whole thing | 20:49 |
| sf-slack2 | <kgugala> this will require push -f | 20:49 |
| mithro | kgugala: I think the issue is on https://github.com/SymbiFlow/symbiflow-arch-defs/blob/dc45861228a81ade14f22d828856a575f9b471d9/utils/vlog/vlog_to_model.py#L195-L209 | 20:49 |
| tpb | Title: symbiflow-arch-defs/vlog_to_model.py at dc45861228a81ade14f22d828856a575f9b471d9 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 20:49 |
| mithro | kgugala: Were where your changes? | 20:51 |
| sf-slack2 | <kgugala> in dff_two_clocks (both verilog and golden_model) | 20:51 |
| mithro | kgugala: I mean which repo were you pushing too? | 20:52 |
| sf-slack2 | <kgugala> I just pushed the changes without rebasing | 20:52 |
| sf-slack2 | <kgugala> @mithro see this commit https://github.com/mithro/symbiflow-arch-defs/commit/ffbb1d41e0c0834ced7e03b1d73e742eb4594269 | 20:53 |
| tpb | Title: vlog_to_model: correctly handle clock association and multiple clks · mithro/symbiflow-arch-defs@ffbb1d4 · GitHub (at github.com) | 20:53 |
| sf-slack2 | <kgugala> it fixes the #667 | 20:53 |
| sf-slack2 | <kgugala> ale also handles multiple clock association | 20:53 |
| mithro | kgugala: You should push your version of my branch to another repo too | 20:54 |
| mithro | Otherwise I can't access the commits | 20: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 there | 20:55 |
| sf-slack2 | <kgugala> @mithro the relevant change is in the commit I linked above | 20:57 |
| sf-slack2 | <kgugala> + golden model change so it fits what is generated by the script | 20:58 |
| mithro | kgugala: Sure, but if you push to your own repo, then I won't accidentally push over the top of your changes :-) | 21:00 |
| mithro | kgugala: I rebased your changes | 21:07 |
| sf-slack2 | <kgugala> I see | 21:09 |
| sf-slack2 | <kgugala> I pushed the dff_two_clocks golden model update | 21:09 |
| sf-slack2 | <kgugala> it's cosmetic | 21:10 |
| mithro | kgugala: Why is your change needed? | 21:11 |
| sf-slack2 | <kgugala> @mithro what do you think about the https://github.com/SymbiFlow/symbiflow-arch-defs/pull/664/commits/0349a652be87a5b5b08c3ce2d38b545c7c94b9d2 | 21:11 |
| tpb | Title: WIP: v2x clock tests by mithro · Pull Request #664 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 21:11 |
| sf-slack2 | <kgugala> it switches c1 and c2 for port b (it's cosmetic, but that was causing diff to fail) | 21:12 |
| mithro | kgugala: Is cmake not running the golden model through xmlsort.xml ? | 21:12 |
| sf-slack2 | <kgugala> I generated new golden model with 'update_golden_model' target | 21: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 switched | 21:14 |
| mithro | Ahh... | 21:14 |
| sf-slack2 | <kgugala> as I said it is cosmetic | 21:14 |
| mithro | https://github.com/SymbiFlow/symbiflow-arch-defs/issues/668 | 21:16 |
| tpb | Title: 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 github.com) | 21:16 |
| *** space_zealot has quit IRC | 21:17 | |
| *** space_zealot has joined #symbiflow | 21:17 | |
| mithro | kgugala: I'll work on #668 if you are working on the v2x stuff | 21:31 |
| sf-slack2 | <kgugala> Ok | 21:34 |
| *** space_zealot has quit IRC | 21:39 | |
| *** space_zealot has joined #symbiflow | 21:40 | |
| hackerfoo | How can I set a FASM feature based on the input to a mux in VPR? Do I need to use modes instead? | 22:40 |
| hackerfoo | I can see the equivalent to what I want for <direct> | 22:41 |
| litghost | You mean fasm_mux? | 22:42 |
| litghost | https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/primitives/common_slice/common_slice.pb_type.xml#L267 | 22:43 |
| tpb | Title: symbiflow-arch-defs/common_slice.pb_type.xml at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 22:43 |
| hackerfoo | Thanks, I think so. Is the synax a list of "<input> = <fasm feature name>"? | 22:45 |
| hackerfoo | And I guess "NULL" is a keyword for not adding anything. | 22:46 |
| litghost | Yes | 22:56 |
| elms | hackerfoo: I think that is accepted, but use `input : feature` as shown here https://github.com/SymbiFlow/vtr-verilog-to-routing/blob/master%2Bwip/utils/fasm/test/test_fasm_arch.xml#L146-L149 | 22:56 |
| tpb | Title: vtr-verilog-to-routing/test_fasm_arch.xml at master+wip · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com) | 22:56 |
| litghost | https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/primitives/common_slice/common_slice.pb_type.xml#L306 | 22:56 |
| tpb | Title: symbiflow-arch-defs/common_slice.pb_type.xml at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 22:56 |
| litghost | NONE is actually the keyword, not NULL | 22:57 |
| litghost | Sorry, NULL is correct, opps | 22:58 |
| litghost | Might be some errors at L306 | 22:58 |
| hackerfoo | elms: Why use `input : feature`? `input = feature` is used everywhere else. | 22:59 |
| hackerfoo | If we're changing the syntax, I suggest `->` or `=>`. | 23:01 |
| elms | Both are supported and I think we should go back and change existing uses. | 23:01 |
| hackerfoo | Inconsistency is worst: http://i.imgur.com/vOWAAUK.png | 23:04 |
| elms | https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/master/doc/src/utils/fasm.rst#within-tile-interconnect-features | 23:05 |
| tpb | Title: vtr-verilog-to-routing/fasm.rst at master · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 23:05 |
| hackerfoo | If we're going to change it, it's probably best to do in a single PR. | 23:05 |
| hackerfoo | As much as possible, at least. | 23:06 |
| elms | that's valid. | 23:06 |
| *** space_zealot has quit IRC | 23:07 | |
| litghost | For now, stay consistent with the XML's around it. I believe ice40 is using the ":" and xc7 is using "=". | 23:07 |
| litghost | hackerfoo: We cannot use ">" because XML | 23:07 |
| litghost | hackerfoo: Much sadness | 23:08 |
| elms | maybe this is a better link for the FASM in VPR https://symbiflow.readthedocs.io/projects/vtr/en/latest/utils/fasm.html#within-tile-interconnect-features | 23:08 |
| tpb | Title: FPGA Assembly (FASM) Output Support Verilog-to-Routing 8.0.0-dev documentation (at symbiflow.readthedocs.io) | 23:08 |
| litghost | elms: Yes | 23:08 |
| hackerfoo | Can 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 #symbiflow | 23:09 | |
| litghost | hackerfoo: Nope | 23:09 |
| litghost | hackerfoo: That's the reason for the "PARENT_DI" stuff | 23:09 |
| litghost | hackerfoo: It is simply converting the input port to an output port | 23:09 |
| litghost | hackerfoo: Or vise-versa | 23:10 |
| litghost | hackerfoo: Been a while since I messed with this stuff | 23:10 |
| hackerfoo | I guess I need an internal wire. | 23:12 |
| elms | litghost: has there been any discussion around how to support different speed grades? | 23:22 |
| litghost | elms: Funny that you mention it | 23:22 |
| litghost | elms: https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/551 | 23:23 |
| tpb | Title: PVT corner timing models · Issue #551 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 23:23 |
| litghost | elms: Speed grades are just another take on the corner analysis, kind of | 23:23 |
| litghost | elms: If VPR supported multiple corners, and we could select which corners we used in analysis, that would cover speed grades | 23:24 |
| elms | litghost: 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 |
| litghost | elms: Hard to say, I lack an intuition on that topic | 23:26 |
| elms | If it just adds constants I would imagine little impact on the routing for example. It would impact fmax. | 23:27 |
| elms | ok | 23:27 |
| litghost | elms: Given that we are controlling the import, we can just emit pbtypes and rrgraphs at a particular speed grade, yes? | 23:27 |
| elms | litghost: 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 |
| litghost | elms: I don't think we are going to be able to avoid that without a symbolic solution to https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/551 | 23:55 |
| tpb | Title: PVT corner timing models · Issue #551 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 23:55 |
| elms | litghost: 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 structure | 23:57 |
| litghost | elms: Sure, which is what I mean by a symbolic solution, e.g. a side lookup | 23:57 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
