<sf-slack1>
<acomodi> upstream VTR merge update: murax is working on HW after merge (without round robin option)
citypw has quit [Ping timeout: 252 seconds]
<sf-slack1>
<mkurc> @acomodi I've stumbled on a similar issue as you did with routing the PicoSoC. The routing was taking a huge number of iterations and the number of overused connections were varying between 1 and 5. Don't remember which commit it was though...
<sf-slack1>
<acomodi> @mkurc: I think it could be after the first merge done by @litghost. I will investigate, even though, given that Round Robin is the issue, it will not be pushed upstream as it was a workaround before the tile split.
<sf-slack1>
<tmichalak> Hi everyone, a small update on the effort to remove the use of design.bit (https://github.com/SymbiFlow/symbiflow-arch-defs/issues/418). With the database that has the HCLK_CMT and CLK_HROW bits and the design.json generated with the small change that adds the bits outside of ROI to the required_features, I was able to generate a working counter bitstream from the frames with xc7frames2bit. So no harness bitstream
<sf-slack1>
is needed anymore.
<tpb>
Title: Remove use of design.bit (ROI bitstream harness) · Issue #418 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<sf-slack1>
<acomodi> That's great!
Bertl_zZ is now known as Bertl
kraiskil has quit [Ping timeout: 244 seconds]
kraiskil has joined #symbiflow
kraiskil has quit [Ping timeout: 272 seconds]
kc8apf_ has joined #symbiflow
ants` has joined #symbiflow
kc8apf has quit [*.net *.split]
galv[m] has quit [*.net *.split]
nats` has quit [*.net *.split]
kc8apf_ is now known as kc8apf
galv[m] has joined #symbiflow
<sf-slack1>
<tmichalak> In parallel to adding the BRAM36 support to VTR I am looking at the stabilization of the CI fuzzer runs. Since it was mostly Vivado that failed I modifed the run_fuzzer.py script to be more verbose when a fuzzer fails and print out last 50 lines of the vivado.log. The build seems to be more stable, but not stable enough.
<tpb>
Title: INT FAN_ALT[0-9].GFAN0 solutions are still unstable · Issue #567 · SymbiFlow/prjxray · GitHub (at github.com)
<sf-slack1>
<tmichalak> @acomodi: you worked on a fix for this right? Can we improve your fix somehow?
<sf-slack1>
<tmichalak> @mithro: btw, since I already mentioned the fuzzer stabilization, if I wanted to work on https://github.com/SymbiFlow/prjxray/issues/713 I would need some of my questions that I asked in the ticket answered
<tpb>
Title: Test output on CI cleanup needed · Issue #713 · SymbiFlow/prjxray · GitHub (at github.com)
<sf-slack1>
<acomodi> @tmichalak: well, there is one option that could increase the success probabilities and it would be to increase the number of specimens, but as always it does not assure a 100% success.
<sf-slack1>
<tmichalak> @acomodi: well, increase the number of specimen is not really the solution I would like to go with
<sf-slack1>
<acomodi> @tmichalak: another thing that could be done is to have a fuzzer to get GFAN only related bits, and than FAN_ALT, that will depend on the GFAN fuzzer will not add the bits related to GFAN
<sf-slack1>
<tmichalak> I will rerun the CI with the small stabilization changes I made a couple of times and see what is the success rate
<sf-slack1>
<acomodi> I think that right now GFAN related bits are computed in the `056-rem` fuzzer, if I'm not wrong
<sf-slack1>
<tmichalak> @acomodi: this sounds much better, I guess we might have to do this eventually
<sf-slack1>
<tmichalak> @acomodi: you are right about the `056-rem` fuzzer and GFAN bits
<sf-slack1>
<acomodi> Maybe it is worth extracting the GFAN in another fuzzer and add it to the dependencies of the FAN_ALT one
lethalbit has quit [Ping timeout: 250 seconds]
lethalbit has joined #symbiflow
<litghost>
tmichalak: I think a dedicated GFAN fuzzer is a good idea. Increases sample count has not stabilized it. One advantage of using a dedicated fuzzer is you can limit the solution size to 2 bits (e.g. "-c 2"), which I believe all the GFAN bits fall within. This is not generally true for all INT pips, but might
<tpb>
Title: Scalable test design by mkurc-ant · Pull Request #490 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<sf-slack1>
<mkurc> I wrote initial conclusions of testing in the PR's comment.
<sf-slack1>
<acomodi> Hi everyone. Here there is a PR that changes the cmake build system to allow the creation of different devices/boards/parts for the same architecture: https://github.com/SymbiFlow/symbiflow-arch-defs/pull/462
<tpb>
Title: WIP: Add arty support by acomodi · Pull Request #462 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<tpb>
Title: Google Docs - create and edit documents online, for free. (at docs.google.com)
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<litghost>
mkurc: Thanks, it's good to have something we can test with. It makes a good regression test too. I've found another case that breaks too. I suspect this may be caused by the MUX vs SHORT issue on the channel merges. I'll test if that helps in my case
<sf-slack1>
<mkurc> I used the design also to test on the split grid based on SLICEs and observed that it fails for less complex designs than for the CLB based grid.
kraiskil has joined #symbiflow
<litghost>
Huh
<sf-slack1>
<acomodi> litghost, mithro: I have merged https://github.com/SymbiFlow/symbiflow-arch-defs/pull/462. Arty doesn't currently compile as a new harness is needed and placed in this directory `third_party/prjxray-db/artix7/harness/arty-a7/uart/`
<tpb>
Title: Sign in to GitHub · GitHub (at github.com)
<litghost>
acomodi: I assume prjxray can generate the arty harness right now?
<sf-slack1>
<acomodi> litghost: yes, it stucks only with round robin option enabled
<sf-slack1>
<acomodi> I am still investigating why this happens, but I couldn't find the source of the issue yet
dhiraj24 has joined #symbiflow
<dhiraj24>
Hello
<litghost>
Hi
<dhiraj24>
I am interested in https://github.com/SymbiFlow/ideas/issues/11 project for gsoc. I am Third year undergraduate student doing Bachelor of engineering in Electronics and Telecommunication in India and have good grasp over python.I have been contributing to opensource a lot.Please see my github profile https://github.com/Dhiraj240 and also in summers 2018 i had participated in an opensource contest where i built this project https
<tpb>
Title: Add a Verilog / SystemVerilog support to Sphinx · Issue #11 · SymbiFlow/ideas · GitHub (at github.com)
<dhiraj24>
The link for sphinix document is not opening and please provide me a little advise over the above project.I had seen the approach given in the issue but basically i am confused as which of your repos will be used by doxygen-verilog .
<litghost>
symbiflow-arch-defs I believe is teh one we are targetting. mithro should pop in later and can answer more questions
<tpb>
Title: GitHub - SymbiFlow/symbiflow-arch-defs: FOSS architecture definitions of FPGA hardware useful for doing PnR device generation. (at github.com)
<dhiraj24>
Alright so doxygen-verilog will use symbiflow-arch-defs to generate Doxygen output from the Verilog and i have to use either breathe or exhale to read it and output it to sphinx.
<dhiraj24>
Am i right ?
<litghost>
That sounds correct. What we are intending for the architecture documentation process is to write some verilog, generate a schematic diagram in SVG from it, and then build sphnix documentation including both
<litghost>
mithro: Want to add to that explaination?
<tpb>
Title: Add a Verilog / SystemVerilog support to Sphinx · Issue #11 · SymbiFlow/ideas · GitHub (at github.com)
acomodi has quit [Quit: Connection closed for inactivity]
<mithro>
dhiraj24: I've yet to get through my email this morning, so probably haven't seen your question
<dhiraj24>
alright sir, in India there is 12:30 am and tomorrow is my college. can i know as when you will guide me for that ?
<mithro>
dhiraj24: I have replied to your comment
<dhiraj24>
Okay sir, i had commented again there please check.
<dhiraj24>
Also sir, should i directly start with my proposal and show the implementation of it ? or before that any contribution is necessary ? Meanwhile please check the updated comment on https://github.com/SymbiFlow/ideas/issues/11
<tpb>
Title: Add a Verilog / SystemVerilog support to Sphinx · Issue #11 · SymbiFlow/ideas · GitHub (at github.com)
<tpb>
Title: [XC7] Some designs fail on hardware · Issue #491 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<sf-slack1>
<acomodi> litghost: well, given that round robin is not going to be needed anymore with the clb tile being splitted we could disable it for good, right?
<litghost>
acomodi: Sure. Hopefully if mkurc tests with round robin disabled the tile split starts working as expect, then that is the path forward + equivilent tils
<litghost>
es
<sf-slack1>
<acomodi> litghost: my question though is: why would the SLICEM be set to DRAMs mode instead of LUTs?
<litghost>
acomodi: Because the round robin packer is doing what it is supposed to, alturnate modes on packing
dhiraj24 has quit [Ping timeout: 256 seconds]
<sf-slack1>
<acomodi> litghost: All right. What is still needed to merge and start using @mkurc work on splitting tiles? (Provided that we test that there is no regression wrt the current status)
<tpb>
Title: Scalable test design by mkurc-ant · Pull Request #490 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<litghost>
acomodi: To be fair, that PR fails on both pre- and post- split
<litghost>
but the post-split seems worse
<litghost>
If round robin packing explains the failure, then maybe we are ready to merge the split. I would like the tile split to have the unified tile names (e.g. just SLICEL/SLICEM), but unclear how much more work is left for that
<tpb>
Title: Diff to HTML by rtfpessoa (at tinyurl.com)
<mithro>
Looks like you renamed some stuff?
<litghost>
mithro: Which are you asking about?
<litghost>
mithro: Segbits for CLK_HROW?
<mithro>
litghost: Yeah
<litghost>
mithro: Couple things happened. Turns out the offset and word count was too small to include all the bits in the interconnect, so the offset was lowered, which resulted in all bits getting rebased
<litghost>
mithro: the other thing that happened is that we enabled fuzzing of the entire clk hrow interconnect switch box, which resulted in a bunch of new features
<mithro>
Shouldn't we just add the UART to the ARTY-A7-SWBUT harness? Both the Zybo and Basys SWBUT harness have the UART available... -- then with that change, I'm not sure what the point of the Arty-A7-UART harness is?
<mithro>
litghost: BTW Have you landed the short switch change?
<litghost>
mithro: Not yet, I've been focused on a large refactor in the fasm2verilog work. Hopefully with a little more effort that will be ready to merge.
<litghost>
mithro: I don't believe we have evidence that the MUX vs SHORT has been causing a problem. There does appear to be an issue with the round robin packing interacting with the DRAM bits.
<litghost>
mithro: To be clear I do want to land the PR
<mithro>
litghost: without the short change vpr might end up trying to use the same wire for two signals?
<litghost>
mithro: But we don't have evidence that has actually happened
<litghost>
mithro: In fact I specifically added logic to the fasm2verilog code to look for such a problem
<litghost>
mithro: And did not see it
<mithro>
litghost: Oh, I guess the Xilinx parts really only have point-to-point wires... would be more a problem with the long wires which I don't think you are importing at the moment?
<litghost>
mithro: No I do believe that the MUX vs SHORT is a bug, and should be fixed. I just don't have evidence it is a problem this very minute.
futarisIRCcloud has joined #symbiflow
<mithro>
litghost: I've committed a replacement for that pull request
tpb has quit [Remote host closed the connection]
<litghost>
mithro: ?
<litghost>
mithro: Replacement for which PR?
tpb has joined #symbiflow
<mithro>
litghost: I fixed the Info.md and updated the README -- Arty UART harness
<litghost>
mithro: Okay, great.
<litghost>
mithro: So that brings our supported board count to 3