| *** tpb has joined #symbiflow | 00:00 | |
| *** Bertl is now known as Bertl_zZ | 00:26 | |
| *** ramin_r348 has joined #symbiflow | 00:27 | |
| *** Degi_ has joined #symbiflow | 00:57 | |
| *** Degi has quit IRC | 01:00 | |
| *** Degi_ is now known as Degi | 01:00 | |
| FFY00 | mithro, okay | 01:21 |
|---|---|---|
| FFY00 | what is blocking it other than the actual work? because I can help with that | 01:21 |
| FFY00 | also, please let me know if you think I am out of place | 01:22 |
| FFY00 | I guess I can come of a little strong | 01:22 |
| FFY00 | I really care about the fpga and overall hardware ecosystem on linux and I want to help make it the more stable and user friendly | 01:24 |
| FFY00 | which includes ensuring the build systems work without hassle for everyone and packaging the relevant tools | 01:25 |
| hackerfoo | FFY00: What do you think about Nix? I'd like to make Nix packages sometime. | 01:36 |
| hackerfoo | Here's a shell.nix for VtR: https://github.com/HackerFoo/vtr-verilog-to-routing/blob/macos_nix/shell.nix | 01:37 |
| tpb | Title: vtr-verilog-to-routing/shell.nix at macos_nix · HackerFoo/vtr-verilog-to-routing · GitHub (at github.com) | 01:37 |
| FFY00 | python packages are not usually problematic | 01:39 |
| FFY00 | I never used nix but the packaging seems pretty easy | 01:40 |
| FFY00 | but why do you need shell.nix in the upstream repo? | 01:41 |
| *** citypw has joined #symbiflow | 01:43 | |
| *** az0re has joined #symbiflow | 02:04 | |
| hackerfoo | So others can use it. | 02:24 |
| hackerfoo | I don't think it'd really be useful in nixpkgs yet. | 02:25 |
| *** adjtm has quit IRC | 03:41 | |
| *** adjtm has joined #symbiflow | 03:42 | |
| *** proteus-like has quit IRC | 03:45 | |
| FFY00 | okay | 03:55 |
| FFY00 | I guess there's nothing like the AUR in arch right? | 03:56 |
| FFY00 | if you want to start packaging, go for it :D | 03:57 |
| FFY00 | just keep in mind the headaches | 03:57 |
| *** adjtm has quit IRC | 04:07 | |
| *** adjtm has joined #symbiflow | 04:08 | |
| *** az0re has quit IRC | 04:54 | |
| *** citypw has quit IRC | 04:54 | |
| *** tcal has joined #symbiflow | 05:30 | |
| *** az0re has joined #symbiflow | 05:45 | |
| *** OmniMancer1 has joined #symbiflow | 05:47 | |
| *** OmniMancer has quit IRC | 05:51 | |
| hackerfoo | As far as I can tell, all users of VPR are also hacking on it. | 06:20 |
| hackerfoo | So there's no reason to package it up yet. The shell.nix gives you a stable cross-platform setup for development. | 06:22 |
| hackerfoo | So Nix is still useful before sending a PR to nixpkgs. | 06:26 |
| *** ramin_r348 has quit IRC | 06:36 | |
| *** OmniMancer1 has quit IRC | 06:55 | |
| *** OmniMancer has joined #symbiflow | 06:57 | |
| *** proteusguy has joined #symbiflow | 07:19 | |
| *** kraiskil has joined #symbiflow | 07:29 | |
| *** futarisIRCcloud has joined #symbiflow | 07:30 | |
| *** adjtm has quit IRC | 07:33 | |
| *** adjtm has joined #symbiflow | 07:34 | |
| daniellimws | Hi, I'm hoping to contribute to symbiflow-arch-defs by adding testbenches, starting with the muxes under vpr/ (https://github.com/symbiflow/symbiflow-arch-defs/tree/master/vpr/muxes/logic) as I see there's an example for mux2. May I know where can I find the steps to run the test (for example, vpr/muxes/logic/mux2)? Is it necessary for me to build every submodule in "third_party" for this? | 07:38 |
| tpb | Title: symbiflow-arch-defs/vpr/muxes/logic at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 07:38 |
| *** adjtm has quit IRC | 07:40 | |
| *** adjtm has joined #symbiflow | 07:40 | |
| *** adjtm has quit IRC | 07:58 | |
| *** adjtm has joined #symbiflow | 07:59 | |
| *** adjtm has joined #symbiflow | 08:01 | |
| *** wavedrom has quit IRC | 08:03 | |
| *** kraiskil has quit IRC | 08:34 | |
| *** Vonter has quit IRC | 09:04 | |
| *** Vonter has joined #symbiflow | 09:06 | |
| *** kraiskil has joined #symbiflow | 09:19 | |
| *** az0re has quit IRC | 10:06 | |
| *** CMP1 has joined #symbiflow | 10:08 | |
| *** Bertl_zZ is now known as Bertl | 10:43 | |
| *** OmniMancer1 has joined #symbiflow | 10:51 | |
| *** OmniMancer has quit IRC | 10:55 | |
| *** proteus-guy has joined #symbiflow | 11:08 | |
| CMP1 | Hello, I am looking at the `segbits_clbll_l` for every mux, only one connection can be established, right ? But what will happen if thats not the case ? Will the configuration be aborted ? | 12:15 |
| *** kraiskil has quit IRC | 13:05 | |
| *** pdp7 has quit IRC | 13:15 | |
| *** _whitelogger has quit IRC | 13:15 | |
| *** _florent_ has quit IRC | 13:15 | |
| *** heijligen has quit IRC | 13:15 | |
| *** filt3r has quit IRC | 13:15 | |
| *** pdp7_ has joined #symbiflow | 13:16 | |
| *** _florent_ has joined #symbiflow | 13:16 | |
| *** filt3r has joined #symbiflow | 13:16 | |
| *** heijligen has joined #symbiflow | 13:17 | |
| *** kraiskil has joined #symbiflow | 13:18 | |
| *** _whitelogger has joined #symbiflow | 13:18 | |
| litghost | CMP1: Are you asking from the perspective of the FASM assembler (e.g. fasm2frames) or the hardware itself? | 14:07 |
| daveshah | CMP1: no, there is no error checking for stuff like that, you could actually create a short circuit | 14:07 |
| daveshah | (I was assuming "configuration be aborted" was referring to the hardware config FSM) | 14:07 |
| mithro | CMP1: A lot of the configuration bits are set up to make it very hard to create shorts | 14:07 |
| mithro | CMP1: but I do believe there are cases where it is possible | 14:07 |
| CMP1 | Thank you and yes I am talking about the hardware config FSM | 14:08 |
| CMP1 | mithro isnt it very easy to do it in the muxes case for example? | 14:09 |
| CMP1 | So in the case of a short it would act like an or gate ? | 14:10 |
| *** luaraneda has left #symbiflow | 14:11 | |
| mithro | CMP1: possibly, I didn't look at your specific example | 14:11 |
| daveshah | No, a short would be a short, but I'm not sure if any of the muxes in `segbits_clbll_l` would be short-circuit-able | 14:13 |
| CMP1 | what I was thinking is something like that `CLBLL_L.SLICEL_X0.AFFMUX.AX !30_00 !30_02 !30_03 30_01CLBLL_L.SLICEL_X0.AFFMUX.CY !30_01 !30_03 30_00 30_02CLBLL_L.SLICEL_X0.AFFMUX.F7 !30_02 !30_03 30_00 30_01CLBLL_L.SLICEL_X0.AFFMUX.O5 !30_01 !30_02 30_00 30_03CLBLL_L.SLICEL_X0.AFFMUX.O6 !30_00 !30_01 !30_02 30_03CLBLL_L.SLICEL_X0.AFFMUX.XOR !30_00 | 14:13 |
| CMP1 | !30_01 !30_03 30_02` | 14:13 |
| CMP1 | and I was thinking what would happen if I enable both `CLBLL_L.SLICEL_X0.AFFMUX.O6` and `CLBLL_L.SLICEL_X0.AFFMUX.O5` for example | 14:15 |
| daveshah | Ultimately it depends how it is implemented in hardware | 14:18 |
| daveshah | the interconnect muxes are based on pass transistors, followed by buffers in some cases, so generally can create shorts | 14:18 |
| daveshah | I don't know what the SLICE muxes look like though | 14:18 |
| CMP1 | when you talk about interconnect muxes you mean something pip related that cant be seen in the vivado view ? | 14:19 |
| daveshah | In this case, O6 is a subset of the O5 bits | 14:20 |
| daveshah | so enabling both would be the same as the O5 pattern | 14:20 |
| daveshah | By interconnect muxes I mean pips in INT_ tiles | 14:20 |
| daveshah | as opposed to being inside slices | 14:20 |
| CMP1 | I see | 14:21 |
| CMP1 | so generally setting wierd combinations like that may lead to shorts | 14:21 |
| mithro | CMP1: adding DRC checking to some of the tooling to prevent things like that could be a good task | 14:23 |
| daveshah | But if you want to destroy the chip, filling it with ring oscillators will probably be just as destructive and easily possible without any bitstream hackery | 14:24 |
| daveshah | From what I've heard from people in the industry, the failure mode from shorts on a modern FPGA is likely to be thermal | 14:25 |
| mithro | CMP1 / daveshah: See the work from Derek and Imperial College if you want to really know how to do damage | 14:25 |
| CMP1 | mithro Nice! but one has to first find actual problems because as daveshah pointed my example was pretty much stupid | 14:25 |
| CMP1 | @daveshah I dont want to destroy the FPGA, on the contrary I want to see how many silly things I can do on the bitstream without risking to dammage it | 14:26 |
| mithro | CMP1: We aim to never generate a bitstream that Vivado wouldn't also generate | 14:27 |
| daveshah | Your FPGA is probably more likely to be destroyed by a lightning strike than by open source tooling | 14:28 |
| daveshah | Across 1000s of icestorm and trellis users there have been no reports of damage | 14:28 |
| CMP1 | I see, I havent really dug into your bitstream generating tools, I am currently focused on the XRay so I try to explore any manual modification as well | 14:28 |
| CMP1 | daveshah Its not the tool I am afraid of but the what ifs in my brain :P | 14:29 |
| daveshah | A single short like this isn't going to cause immediate damage | 14:29 |
| CMP1 | can it lead in unexpected behavior ? | 14:31 |
| hackerfoo | Xilinx's documentation on partial reconfiguration warns about mismatched bitstreams, saying that there could be damage over a period of time. | 14:31 |
| hackerfoo | So this means, even if you have random stuff next to each other, they still don't expect immediate damage. | 14:31 |
| CMP1 | also do you have a link of Derek's thesis ? | 14:32 |
| daveshah | Someone from Intel suggested that a probable failure mode for a bitstream full of short circuits would be the FPGA desoldering itself from the board | 14:32 |
| daveshah | CMP1: yes, because two inputs to the mux are now connected together this could cause odd things to happen | 14:32 |
| CMP1 | daveshah now that sounds fun haha | 14:32 |
| daveshah | I think azonenberg managed to kill a Xilinx CPLD that way through some kind of internal failure, but it took 30 minutes | 14:33 |
| CMP1 | those odd things would not be forseeable by the one that created that short though, right ? | 14:33 |
| daveshah | Chances are if you have created the short it is deliberate | 14:33 |
| CMP1 | yes but will the effect of it be deterministic ? | 14:34 |
| CMP1 | (I might have started saying stupid things now ) | 14:34 |
| daveshah | No, because it would depend on things like drive buffer strength and input sensitivity, which could vary chip-to-chip and across temperatures | 14:34 |
| daveshah | *buffer drive strength | 14:35 |
| CMP1 | daveshah thanks :)) | 14:35 |
| daveshah | https://scholarsarchive.byu.edu/cgi/viewcontent.cgi?article=5037&context=etd | 14:36 |
| daveshah | this is using short circuits for good/evil | 14:36 |
| CMP1 | I will take a look, thank you | 14:37 |
| CMP1 | I have a question regarding CRC, can you disable it from inside the bitstream ? | 14:37 |
| CMP1 | I have found this for older generations | 14:38 |
| CMP1 | https://www.xilinx.com/support/answers/35468.html | 14:38 |
| CMP1 | but I am interested in xc7 | 14:38 |
| daveshah | I think if you just exclude the CRC register writes then it will still accept the bitstream | 14:39 |
| CMP1 | you mean turn its value to zero ? | 14:40 |
| daveshah | No, remove the CRC write packets altogether | 14:40 |
| *** kraiskil has quit IRC | 14:40 | |
| daveshah | I haven't tried this but I suspect it would work, someone who has worked on xc7 bitstreams more could confirm | 14:40 |
| CMP1 | I see removing a packet is equal to deleting it or turning all its values to zero ? | 14:41 |
| daveshah | Deleting it | 14:41 |
| CMP1 | cool, thanks | 14:42 |
| daveshah | I think there is a NOOP packet that it could be replaced with too | 14:42 |
| daveshah | something like 0x20000000 | 14:42 |
| CMP1 | I see I will have to reado more about packets If I am to do it then | 14:43 |
| mithro | CMP1: What do you *actually* want to do? | 14:43 |
| CMP1 | with the crc thing ? beeing able to load changed bitstreams no matter if they have a crc set or not | 14:44 |
| CMP1 | the easy way is to just disable it in vivado | 14:45 |
| CMP1 | Also recalculation would be an option too, right ? | 14:46 |
| mithro | CMP1: In general | 14:47 |
| CMP1 | arent the data that it is calculated on known ? | 14:47 |
| *** CMP150 has joined #symbiflow | 14:53 | |
| *** kraiskil has joined #symbiflow | 14:54 | |
| *** CMP1 has quit IRC | 14:56 | |
| *** miek has quit IRC | 15:10 | |
| *** yeti has quit IRC | 15:10 | |
| *** bunnie[m] has quit IRC | 15:12 | |
| *** yeti has joined #symbiflow | 15:13 | |
| daniellimws | Is there a way to run individual tests within symbiflow-arch-defs? For example https://github.com/symbiflow/symbiflow-arch-defs/tree/master/vpr/muxes/logic | 15:14 |
| tpb | Title: symbiflow-arch-defs/vpr/muxes/logic at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 15:14 |
| mithro | CMP150: What did you want to do in general? | 15:14 |
| *** bunnie[m] has joined #symbiflow | 15:15 | |
| mithro | daniellimws: It has been a long time since anyone worked on that, so I don't know | 15:15 |
| daniellimws | Hmm ok, I'll look around and try to find out | 15:17 |
| *** OmniMancer1 has quit IRC | 15:17 | |
| *** OmniMancer has joined #symbiflow | 15:17 | |
| *** az0re has joined #symbiflow | 15:18 | |
| *** OmniMancer has quit IRC | 15:19 | |
| mithro | - SymbiFlow Checking / Testing Approach - https://docs.google.com/document/d/11wJUvr2aVBkUiuYYsFN07jkoYr_ccWlLLLFH8YQw8uQ/edit# | 15:22 |
| mithro | - Data Flow in SymbiFlow Arch Defs for Xilinx Series 7 Testing + Verification -https://docs.google.com/drawings/d/1-FmukrW4YtreRwkA4JKkYd-siscC3OvDTq8rKreOVHE/edit | 15:22 |
| mithro | - SymbiFlow Bitstream Verification Process - https://docs.google.com/drawings/d/1NJlN-cPLNx4nULHiL4938RD-H14izpayqtNSQ4XRjfA/edit | 15:22 |
| tpb | Title: SymbiFlow Checking / Testing Approach - Google Docs (at docs.google.com) | 15:22 |
| tpb | Title: Data Flow in SymbiFlow Arch Defs for Xilinx Series 7 Testing + Verification - Google Drawings (at docs.google.com) | 15:22 |
| tpb | Title: SymbiFlow Bitstream Verification Process - Google Drawings (at docs.google.com) | 15:22 |
| daniellimws | Oh so if it hasn't been worked on for quite some time, should I still work on adding testbench code for those modules? Would they be useful? | 15:32 |
| mithro | daniellimws: I would love to see that stuff working again | 15:33 |
| mithro | daniellimws: I hadn't actually realized we had merged it... | 15:33 |
| daniellimws | You mean from elmsfu's branch? | 15:34 |
| mithro | daniellimws: Yeah | 15:34 |
| *** miek has joined #symbiflow | 15:34 | |
| daniellimws | And some changes has been made to the build system too, i.e. the cocotb Makefile was removed and replaced with a CMakeLists.txt but I'm unsure how to use it | 15:35 |
| mithro | daniellimws: https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/Makefile#L20 | 15:36 |
| tpb | Title: symbiflow-arch-defs/Makefile at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 15:36 |
| *** tmichalak has quit IRC | 15:40 | |
| *** tmichalak has joined #symbiflow | 15:41 | |
| *** bubble_buster has quit IRC | 15:45 | |
| *** sorear has quit IRC | 15:45 | |
| *** xobs has quit IRC | 15:45 | |
| *** promach3 has quit IRC | 15:45 | |
| *** kmehall has quit IRC | 15:45 | |
| *** mats has quit IRC | 15:45 | |
| *** bubble_buster has joined #symbiflow | 15:45 | |
| *** sorear has joined #symbiflow | 15:45 | |
| *** promach3 has joined #symbiflow | 15:45 | |
| *** xobs has joined #symbiflow | 15:45 | |
| *** kmehall has joined #symbiflow | 15:45 | |
| *** mats has joined #symbiflow | 15:45 | |
| *** promach3 has quit IRC | 15:46 | |
| *** xobs has quit IRC | 15:48 | |
| *** bunnie[m] has quit IRC | 15:48 | |
| *** abeljj[m] has quit IRC | 15:49 | |
| *** lromor[m] has quit IRC | 15:49 | |
| *** hzeller[m] has quit IRC | 15:49 | |
| *** nrossi has quit IRC | 15:49 | |
| -_whitenotifier-3- [prjxray] mithro opened issue #1284: Move third_party designs to under /third_party/ - https://git.io/Jv7SG | 15:52 | |
| CMP150 | mithro my plan is to see what extra things you can do through bitstream not supported from vivado | 15:53 |
| mithro | CMP150: To what end goal? | 15:53 |
| FFY00 | mithro, did you see my previous messages? | 15:53 |
| mithro | CMP150: Do you have any idea what type of features you might be looking for? | 15:53 |
| mithro | FFY00: Which one? | 15:53 |
| FFY00 | when I replied to you yesterday, after asking about meson | 15:54 |
| mithro | FFY00: Probably not | 15:54 |
| FFY00 | okay | 15:54 |
| CMP150 | I am not sure about that, I think that the process alone can help me understand FPGAs and maybe through this process I can get some ideas | 15:54 |
| FFY00 | if you have time please take a look | 15:54 |
| CMP150 | mithro | 15:54 |
| FFY00 | I would like to help with meson, if that's something you are interested | 15:55 |
| mithro | FFY00: Last time we looked at meson it was missing features required to do things in symbiflow-arch-defs repository | 15:55 |
| FFY00 | which features? | 15:56 |
| *** wavedrom has joined #symbiflow | 15:57 | |
| mithro | FFY00: Can't remember - look for issues reported by me on the meson github repo? | 15:58 |
| FFY00 | mithro, in https://github.com/mesonbuild/meson/issues/3175 do you need to reuse the custom targets latter on? | 16:06 |
| tpb | Title: Using the return objects from custom_target to generate names of another custom_target · Issue #3175 · mesonbuild/meson · GitHub (at github.com) | 16:06 |
| FFY00 | nevermind | 16:07 |
| *** lromor[m] has joined #symbiflow | 16:46 | |
| *** sean has joined #symbiflow | 17:10 | |
| *** sean has joined #symbiflow | 17:11 | |
| *** CMP150 has quit IRC | 17:11 | |
| *** sean is now known as Guest46259 | 17:11 | |
| *** Guest46259 has quit IRC | 17:15 | |
| *** xobs has joined #symbiflow | 17:25 | |
| *** promach3 has joined #symbiflow | 17:25 | |
| *** abeljj[m] has joined #symbiflow | 17:25 | |
| *** bunnie[m] has joined #symbiflow | 17:25 | |
| *** nrossi has joined #symbiflow | 17:25 | |
| *** hzeller[m] has joined #symbiflow | 17:26 | |
| *** wavedrom has quit IRC | 17:39 | |
| brent | Been generating lots of BRAM tests for our BRAM bitstream patching project. Found, for the xc7a50 part, that some INIT bits are missing for certain BRAM locations on the chip (based on the .fasm file generated by bit2fasm). Have hundreds of successful test cases, seems to be working for all but 2 tiles (?). Have a miminal test case to exhibit issue. Would like to track down and fix, would appreciate an expert's input | 19:02 |
| brent | and insights at this point... | 19:02 |
| litghost | Any chance you are using BRAM36 with ECC enables? | 19:08 |
| brent | No, pretty basic | 19:26 |
| brent | Inferring memories using Verilog always blocks... | 19:27 |
| litghost | Best make an issue then | 19:27 |
| brent | That's what I thought... | 19:27 |
| daveshah | Hi brent, btw, good to see you around! | 19:33 |
| brent | Hi dave, long time no see. Been working behind the scenes for a while, this is the first I have interacted on the channel. Looking forward to much more... | 19:34 |
| brent | Hi daveshah, long time no see. Been working behind the scenes for a while, this is the first I have interacted on the channel. Looking forward to much more... | 19:34 |
| -_whitenotifier-3- [prjxray] nelsobe opened issue #1285: Missing INIT string data in FASM for selected BRAM sites - https://git.io/Jv7Nm | 19:42 | |
| *** OmniMancer has joined #symbiflow | 20:23 | |
| *** Bertl is now known as Bertl_oO | 20:24 | |
| *** OmniMancer1 has joined #symbiflow | 20:26 | |
| *** OmniMancer has quit IRC | 20:27 | |
| *** lromor[m] has quit IRC | 20:48 | |
| *** tcal has quit IRC | 21:14 | |
| *** tcal has joined #symbiflow | 21:26 | |
| *** tcal has quit IRC | 21:31 | |
| *** adjtm_ has joined #symbiflow | 21:40 | |
| *** adjtm has quit IRC | 21:43 | |
| *** tcal has joined #symbiflow | 21:45 | |
| *** hzeller[m] has left #symbiflow | 22:00 | |
| *** kraiskil has quit IRC | 22:16 | |
| *** kraiskil has joined #symbiflow | 22:29 | |
| *** tcal has quit IRC | 22:30 | |
| *** tcal has joined #symbiflow | 22:44 | |
| *** QDX45 has quit IRC | 22:51 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!