clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
tpb has quit [Remote host closed the connection]
tpb has joined #yosys
emeb has quit [Quit: Leaving.]
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #yosys
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined #yosys
emeb_mac has quit [Ping timeout: 256 seconds]
emeb_mac has joined #yosys
citypw has joined #yosys
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #yosys
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #yosys
xtro has quit [Ping timeout: 256 seconds]
emeb_mac has quit [Quit: Leaving.]
<pepijndevos> glad to say I at least broke it myself... by changing the timing numbers it appears
<pepijndevos> daveshah, any reason why increasing the delay of pips would fail routing?
<daveshah> Assuming they aren't totally nonsensical, and in the same couple of orders of magnitude as the delay estimates, no
<pepijndevos> if I do ctx.addPip with ctx.getDelayFromNS(0.05) it works great, but if I do it with 1.225 it fails to route
<pepijndevos> I believe the 0.05 came from the upstream simple example
<pepijndevos> 1.225 is a number I pulled from the critical path of the vendor tools
<daveshah> You probably need to change the delay estimate scaling too
<pepijndevos> the what?
<daveshah> It needs to be in the same order of magnitude as the pip delays or the router won't know what to do
<tpb> Title: nextpnr/generic.md at master · YosysHQ/nextpnr · GitHub (at github.com)
<pepijndevos> uh, so how do I come up with reasonable numbers for that?
<daveshah> They only need to be in the right order of magnitude
<pepijndevos> So I just set both numbers equal to the pip delay?
<daveshah> Saying, idk, 0.5ns for offset and 0.5ns for scale would probably be a place to start
<pepijndevos> Alright.
<pepijndevos> What I really need to do is document the fanout timing stuff
<pepijndevos> jaaay works now
<pepijndevos> as a temporary fix at least
<daveshah> Incidentally, 1.225 seems like quite a high pip delay
<daveshah> that's about the slowest pip in the up5k which is already a very slow FPGA
<pepijndevos> yea... well... this was probably a conservative number used by their synthesis tools
<pepijndevos> The slowest Gowin devices are... really slow
<pepijndevos> I think it should be not too hard to get the actual answer from the vendor db
Asu has joined #yosys
<pepijndevos> saaaaad... yosys qos is actually going backwords for picosoc on apicula
<pepijndevos> I used to be able to just barely fit it, but now it takes 104% slices
<Lofty> pepijndevos: how much does ABC9 help? :p
<pepijndevos> Lofty, Apicula does not use the actual synth_gowin because of the generic nextpnr target
<pepijndevos> Without the correct data, it's actually worse
<pepijndevos> 115%
<pepijndevos> Maybe it's time for a serv core :)))
<pepijndevos> Or maybe it's time for a proper nextpnr target...
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined #yosys
_whitelogger has joined #yosys
maartenBE has quit [Ping timeout: 256 seconds]
FFY00 has quit [Remote host closed the connection]
maartenBE has joined #yosys
craigo has quit [Ping timeout: 264 seconds]
citypw has quit [Ping timeout: 240 seconds]
jakobwenzel has quit [Ping timeout: 256 seconds]
jakobwenzel has joined #yosys
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined #yosys
emeb has joined #yosys
xtro has joined #yosys
citypw has joined #yosys
citypw has quit [Ping timeout: 240 seconds]
Forty-Bot has quit []
m4ssi has joined #yosys
jeanthom has joined #yosys
<jeanthom> good evening everyone! I'm running into an issue with my ECP5 DDR3 controller, and I can't figure what's wrong.
<jeanthom> Using the same bitsteam, I get different burstdet values from the DQSBUFM
<jeanthom> Burstdet looks like this when everything is fine: 01110011
<jeanthom> And randomly I get 00000111 and memtest fails
<jeanthom> (the "00000111" thing is burstdet with different values of readclksel)
<daveshah> Are you being careful to start things up correctly?
<tpb> Title: litedram/ecp5ddrphy.py at master · enjoy-digital/litedram · GitHub (at github.com)
<jeanthom> daveshah, yep my code is fairly similar to LiteDRAM
<tpb> Title: gram/ecp5ddrphy.py at master · jeanthom/gram · GitHub (at github.com)
<daveshah> Yeah, that should be fine then
<jeanthom> Also in simulation my read transactions are totally fine, but I don't get activity on burstdet (Lattice verilog models + Icarus Verilog)
maartenBE has quit [Ping timeout: 240 seconds]
<daveshah> Huh, not sure what is happening then
<daveshah> I've definitely seen burstdet work in an iverilog simulation but it was a long time ago
m4ssi has quit [Remote host closed the connection]
Asuu has joined #yosys
Asu has quit [Ping timeout: 240 seconds]
maartenBE has joined #yosys
Forty-Bot has joined #yosys
<cr1901_modern> daveshah: Have you ever seen this warning? http://ix.io/2twl
<daveshah> Yes it is because those functions are a bit long
<cr1901_modern> Not sure when it started, but compiling baseconfigs.cc seems to have started taking a horrific amount of memory (5GB)
<daveshah> They haven't changed for well over a year
<cr1901_modern> Wonder if it's always been that way and I just noticed
<daveshah> If it is causing a problem then ideally they should move into the chipdb instead
<daveshah> It's not ideal but then that applies to a lot of nextpnr at the momen5
<cr1901_modern> Last time I built nextpnr-ecp5 was late June. I don't _recall_ anything like this happening. But no way to test now.
<cr1901_modern> Anyways, I'll leave it be for now and let you know if I find anything. I could've very well just not noticed
Asuu has quit [Quit: Konversation terminated!]
jeanthom has quit [Ping timeout: 244 seconds]
emeb_mac has joined #yosys
<cr1901_modern> daveshah: Yea, I basically concluded that this always happened and I just didn't notice until today. Oops :P
<daveshah> Maybe it is possible to set things up so that file is built with O0
<daveshah> That would probably help the compiler a bit
<cr1901_modern> That's one option. If it becomes a bigger problem, I'll look into it
<sorear> all fun and games until you hit an -O0 only compiler crash
<whitequark> isn't that just some data?
<whitequark> (also by definition -O0 compiler crashes are the easiest to debug, no?)
emeb has quit [Ping timeout: 246 seconds]
mumptai has joined #yosys
emeb_mac has quit [Ping timeout: 240 seconds]
emeb_mac has joined #yosys
jeanthom has joined #yosys
emeb has joined #yosys
az0re has quit [Remote host closed the connection]
<tpb> Title: GitHub - RasmusB/rbServo: Hobby servo controller with CANBUS support (at github.com)
<mumptai> sry, wrong window
cr1901_modern has quit [Ping timeout: 256 seconds]
lf has quit [Ping timeout: 260 seconds]
lf has joined #yosys
mumptai has quit [Quit: Verlassend]
Cerpin has quit [Ping timeout: 246 seconds]
cr1901_modern has joined #yosys
Cerpin has joined #yosys
jeanthom has quit [Ping timeout: 256 seconds]