<mithro> litghost: It looks like there are changes to the fasm tool which hasn't been sent upstream to vtr?
<litghost> mithro: 3 I believe now. The router changes, hackerfoo's parameter change and your pointer fix
<mithro> litghost: I don't see any upstream pull requests for them?
<litghost> mithro: I was waiting till the decision was made for genfasm sub-stuff
<mithro> litghost: genfasm sub-stuff?
<mithro> litghost: Oh you mean OWNERs
<litghost> mithro: I forgot what it was called
<mithro> I would just send it
<mithro> litghost: Did you see that one of the fasm unittests is failing?
<tpb> Title: Travis CI - Test and Deploy with Confidence (at travis-ci.com)
<tpb> Title: Run unit tests in Travis CI · Issue #610 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)
<mithro> litghost: Should I look at it?
<litghost> mithro: Feel free
<tpb> Title: Snippet | IRCCloud (at www.irccloud.com)
<mithro> litghost: Should they have that newline?
<litghost> Yes, ish
<litghost> The answer is yes
<litghost> it
<litghost> should have the newline
<litghost> The better answer is, the newline doesn't matter, so the test simply behaving like a change detector
ZipCPU has joined #symbiflow
space_zealot has joined #symbiflow
proteusguy has quit [Ping timeout: 248 seconds]
citypw has joined #symbiflow
citypw has quit [Remote host closed the connection]
citypw has joined #symbiflow
<mithro> hackerfoo: When you get a moment, can you look at https://github.com/SymbiFlow/symbiflow-arch-defs/pull/779 ?
<tpb> Title: xc7: Use the common_slice definition when LUTRAM used as a LUT. by mithro · Pull Request #779 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
synaption[m] has quit [Remote host closed the connection]
mrhat2010[m] has quit [Read error: Connection reset by peer]
nrossi has quit [Remote host closed the connection]
xobs has quit [Read error: Connection reset by peer]
alexhw[m] has quit [Read error: Connection reset by peer]
vitamin-q[m] has quit [Remote host closed the connection]
zeigren has quit [Read error: Connection reset by peer]
xobs has joined #symbiflow
proteusguy has joined #symbiflow
alexhw[m] has joined #symbiflow
nrossi has joined #symbiflow
synaption[m] has joined #symbiflow
vitamin-q[m] has joined #symbiflow
zeigren has joined #symbiflow
mrhat2010[m] has joined #symbiflow
proteusguy has quit [Remote host closed the connection]
proteusguy has joined #symbiflow
OmniMancer has joined #symbiflow
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined #symbiflow
Bertl_zZ is now known as Bertl
proteusguy has quit [Ping timeout: 258 seconds]
space_zealot has quit [Ping timeout: 250 seconds]
futarisIRCcloud has joined #symbiflow
space_zealot has joined #symbiflow
<sf-slack2> <acomodi> litghost: I am dealing with the non-consecutive ptc. I have applied the changes here https://github.com/SymbiFlow/vtr-verilog-to-routing/pull/64
<tpb> Title: WIP: rr_graph_reader: allow non-consecutive ptc by acomodi · Pull Request #64 · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com)
<sf-slack2> <acomodi> litghost: I still need to find all the locations where I need to have a check whether the inode is valid or not
<sf-slack2> <acomodi> litghost: I have removed the dummy_tracks from the `routing_import.py` script and tested if now the routing reading happens correctly and it does.
<sf-slack2> <acomodi> litghost: the issue is that now router loops infinitely and the Overused RR nodes increase at each iteration
<sf-slack2> <mkurc> @litghost: I filed an issue to the VPR regarding modelling of async S/R flip-flops: https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/617
<tpb> Title: Problem defining a FF with async reset with timings · Issue #617 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)
<sf-slack2> <mkurc> @litghost And I got an answer which from my understanding means that such logic is currently not supported.
<sf-slack2> <mkurc> @litghost The functionality of such a FF does not correspond to any timing model shown in the examples: https://docs.verilogtorouting.org/en/latest/tutorials/arch/timing_modeling/#arch-model-timing-tutorial
<sf-slack2> <mkurc> @litghost I think that what we need is a cell model which has FFs on D and CE inputs but the output Q depends on those FFs plus on the CLR (combinationaly)
<sf-slack2> <mkurc> @litghost We need something like that: https://pasteboard.co/IgXtm7W.png
<tpb> Title: Pasteboard - Uploaded Image (at pasteboard.co)
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
OmniMancer has quit [Quit: Leaving.]
<litghost> One way to model that might be to emit two black boxes
<litghost> Have the combitorial path from SR to Q in the second black box, and SR to CLK in the first second black box
<litghost> Just an idea off the top of my head, unclear if that would actually work
Bertl is now known as Bertl_oO
bjorkintosh has quit [Remote host closed the connection]
bjorkintosh has joined #symbiflow
bjorkintosh has quit [Ping timeout: 264 seconds]
<sf-slack2> <kgugala> @mithro we really need the latest database to get green CI on this one https://github.com/SymbiFlow/symbiflow-arch-defs/pull/738
<tpb> Title: Arch XML timings by kgugala · Pull Request #738 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<mithro> kgugala: Okay, will look at that this afternoon
<sf-slack2> <kgugala> awesome, thanks
Bertl_oO is now known as Bertl_zZ
<hackerfoo> I found this to descramble parallel make output: https://www.gnu.org/software/make/manual/html_node/Parallel-Output.html
<tpb> Title: GNU make: Parallel Output (at www.gnu.org)
<sf-slack2> <kgugala> this is really cool
<mithro> hackerfoo: Already tried that previously it doesn't really work in our system
<tpb> Title: symbiflow-arch-defs/ice40.sh at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<hackerfoo> mithro: --output-sync=recurse also doesn't work? On local builds it seems to be better, at least.
<mithro> hackerfoo: I think the issue is that it ends up with no output until the command finishes
space_zealot has quit [Ping timeout: 258 seconds]
<hackerfoo> Interleaving 36k bits seems to be a lot of work for Yosys.
<litghost> hackerfoo: Like its slow?
<litghost> hackerfoo: Or just hard to do?
<hackerfoo> litghost: It's been running for a while now.
<litghost> hackerfoo: Any chance you made an infinite loop?
<litghost> hackerfoo: I'd bet on an infinite loop over Yosys being super slow, but who knows
<hackerfoo> litghost: ^ I don't think so?
<litghost> hackerfoo: Depends on the width of i, but I assume it's a 32-bit int
<litghost> hackerfoo: Might be worth making a little example and profile it
<litghost> hackerfoo: something like interleave 1k, 2k, 4k, etc
<mithro> hackerfoo: I think you want i to be an integer rather than a 1 bit width register?
<litghost> hackerfoo: Oh, also you problably want to be using generate for and genvar?
<hackerfoo> Can't generate in a function.
<litghost> hackerfoo: Does it work without the function as a generate statement?
<litghost> hackerfoo: Working is better than pretty
<litghost> hackerfoo: Anyways, I think @mithro has the right idea, reg by itself isn't wide enough
<litghost> hackerfoo: So you did make an infinite loop
<hackerfoo> Sure. I'll keeping trying stuff until I find something that works.
<mithro> hackerfoo: I 1bit register will never get bigger than 1, not matter how much you want it too :-P
<hackerfoo> I was trying to use a 7-level macro, but couldn't figure that out.
<mithro> I would think a generate statement would just work in this case?
<litghost> 7-level?
<hackerfoo> good catch litghost , but now it just seems to crash.
<hackerfoo> 2^7
<litghost> Well crashing is a yosys bug you can file :)
<hackerfoo> mithro: Depends on how much voltage you apply.
<litghost> Or do you mean generating an error
<hackerfoo> I can't find the error, at least.
<litghost> hackerfoo: I recommend a nice small reproducible case, and create an issue upstream once you've narrowed it
tpb has quit [Remote host closed the connection]
tpb has joined #symbiflow