kraiskil has quit [Ping timeout: 245 seconds]
kraiskil has joined #symbiflow
somlo has quit [Ping timeout: 246 seconds]
somlo has joined #symbiflow
kraiskil has quit [Ping timeout: 244 seconds]
Bertl_oO is now known as Bertl_zZ
OmniMancer has joined #symbiflow
citypw has joined #symbiflow
sorear has quit [Ping timeout: 240 seconds]
litghost has quit [Ping timeout: 268 seconds]
ovf has quit [Ping timeout: 268 seconds]
litghost has joined #symbiflow
sorear has joined #symbiflow
ovf has joined #symbiflow
_whitelogger has joined #symbiflow
tmichalak has quit [Ping timeout: 240 seconds]
tmichalak has joined #symbiflow
Sarthak has joined #symbiflow
Sarthak has quit [Client Quit]
Sarthak has joined #symbiflow
kraiskil has joined #symbiflow
Sarthak has quit [Ping timeout: 256 seconds]
<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.
<sf-slack1> <tmichalak> The sad thing is that https://github.com/SymbiFlow/prjxray/issues/567 reappeared
<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
<litghost> be true for the GFAN bits.
Bertl is now known as Bertl_oO
<sf-slack1> <mkurc> Good time of day. I've created a test design that can be scaled in size for testing of VPR operation. https://github.com/SymbiFlow/symbiflow-arch-defs/pull/490
<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)
ants` is now known as nats`
<sf-slack1> <acomodi> Here I have started a doc used to think about the major VPR patches that have to be isolated and upstreamed: https://docs.google.com/document/d/17Rp4SEG0uSLG4gWUSPTTjb7We7-MRHtI0L4Mwb9YDPQ/edit?usp=sharing
<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> yes indeed
<litghost> acomodi: Because you've tested the ROI, can you make a PR on https://github.com/SymbiFlow/prjxray-db with the harness?
<tpb> Title: GitHub - SymbiFlow/prjxray-db: Project X-Ray Database: XC7 Series (at github.com)
<sf-slack1> <acomodi> litghost: all right
<sf-slack1> <acomodi> litghost, mithro: done, PR opened to add working arty harness (UART and one LED are correctly working)
<litghost> acomodi: Where are we with the testing with https://github.com/SymbiFlow/vtr-verilog-to-routing/pull/30 ? I believe you said the router was getting stuck? Still true?
<tpb> Title: VTR: upstream merge by acomodi · Pull Request #30 · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com)
<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?
<dhiraj24> write some verilog ? can i get an example ? is verilog code not present in https://github.com/SymbiFlow/symbiflow-arch-defs
<tpb> Title: GitHub - SymbiFlow/symbiflow-arch-defs: FOSS architecture definitions of FPGA hardware useful for doing PnR device generation. (at github.com)
kraiskil has quit [Read error: Connection reset by peer]
<dhiraj24> Asking again sorry for it. [22:30] <dhiraj24> write some verilog ? can i get an example ? is verilog code not present in https://github.com/SymbiFlow/symbiflow-arch-defs
<tpb> Title: GitHub - SymbiFlow/symbiflow-arch-defs: FOSS architecture definitions of FPGA hardware useful for doing PnR device generation. (at github.com)
<litghost> Please wait for @mithro to answer your question
<dhiraj24> alright, i will wait meanwhile should i add comments on the issue tracker for this project on github
<litghost> Feel free
<dhiraj24> okay thanks, i will wait.
kraiskil has joined #symbiflow
<dhiraj24> i guess he is not online
<litghost> mkurc: I've filed https://github.com/SymbiFlow/symbiflow-arch-defs/issues/491 to track what is going with the designs failing on hardware
<tpb> Title: [XC7] Some designs fail on hardware · Issue #491 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
kraiskil has quit [Read error: Connection reset by peer]
OmniMancer has quit [Quit: Leaving.]
<dhiraj24> @litghost can i tell me do i need to solve some issues in order to get selected for GSOC or should i directly work on proposal
<mithro> dhiraj24: Hi! I think for GSoC adding Verilog support to Sphinx would be a better project
<dhiraj24> hello sir, alright but need some clarification
<dhiraj24> i had commented 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)
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)
<litghost> acomodi/mkurc: https://github.com/SymbiFlow/symbiflow-arch-defs/issues/491#issuecomment-475754051 Looks like round robin packing might be causing other issues
<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)
acomodi has joined #symbiflow
kraiskil has joined #symbiflow
<litghost> acomodi: I believe there were regressions with it. See his comment on https://github.com/SymbiFlow/symbiflow-arch-defs/pull/490
<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
kraiskil has quit [Ping timeout: 245 seconds]
<mithro> litghost: Running a db rebuild now
<litghost> mithro: Thanks
<mithro> litghost: What is going on here ->
<mithro> https://tinyurl.com/yy6qk49f CLK_HROW_BOT_R ?
<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
<tpb> Title: Comparing SymbiFlow:master...mithro:master · SymbiFlow/prjxray-db · GitHub (at github.com)
<mithro> litghost: How does that look?
<litghost> mithro: Looks great
<mithro> litghost: Pushed
<litghost> mithro: Please merge https://github.com/SymbiFlow/prjxray-db/pull/6
<tpb> Title: arty-a7: add UART harness by acomodi · Pull Request #6 · SymbiFlow/prjxray-db · GitHub (at github.com)
<litghost> mithro: acomodi has tested it, and there is now first class arty support in arch-defs
<mithro> litghost: I don't quite understand this harness?
<litghost> how so?
<litghost> I believe it is one button, one LED and a UARt
<litghost> mithro: How so?
<mithro> litghost: Hold on a sec
<tpb> Title: gist:c41d7443dab3e6b33df17c9704c0cc57 · GitHub (at gist.github.com)
<litghost> mithro: And?
<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?
<tpb> Title: roi_harness: Add ARTY-A7-UART configuration by acomodi · Pull Request #724 · SymbiFlow/prjxray · GitHub (at github.com)
<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