clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
seldridge has quit [Ping timeout: 252 seconds]
seldridge has joined #yosys
Forty-Bot has quit []
awordnot has quit [Ping timeout: 245 seconds]
awordnot has joined #yosys
eightdot has quit [Ping timeout: 244 seconds]
eightdot has joined #yosys
pie_ has quit [Remote host closed the connection]
pie__ has joined #yosys
emeb_mac has quit [Ping timeout: 246 seconds]
leviathan has joined #yosys
seldridge has quit [Ping timeout: 252 seconds]
m4ssi has joined #yosys
kg6hum has joined #yosys
kraiskil has joined #yosys
kraiskil has quit [Read error: Connection reset by peer]
kraiskil has joined #yosys
mjoldfie_ has joined #yosys
mjoldfield has quit [Ping timeout: 252 seconds]
jhol has quit [Read error: Connection reset by peer]
AlexDaniel has quit [Ping timeout: 252 seconds]
jhol has joined #yosys
jhol has quit [Read error: Connection reset by peer]
pie__ has quit [Ping timeout: 252 seconds]
GuzTech has joined #yosys
pie_ has joined #yosys
pie_ has quit [Ping timeout: 252 seconds]
leviathan has quit [Ping timeout: 246 seconds]
emeb_mac has joined #yosys
leviathan has joined #yosys
emeb_mac has quit [Quit: Leaving.]
jhol has joined #yosys
vup has quit [Quit: The Lounge - https://thelounge.github.io]
vup has joined #yosys
maikmerten has joined #yosys
develonepi3 has quit [Quit: Leaving]
<maikmerten> I've switched to nextpnr-ice40 recently, but found that some seeds, my design would not work as intended.
<tpb> Title: nextpnr-ice40 seed (extension board, no cache) - Google Sheets (at docs.google.com)
<maikmerten> I never *noticed* such things with arachne-pnr (which may, of course, be luck)
<maikmerten> how would one tackle such issues where simulation is fine, most synthesis runs are fine, but for *some* seeds things just don't work out?
<daveshah> the best approach is to do a post-pnr simulation using icebox_vlog to go back to a netlist
<daveshah> however, this won't simulate timing issues
<daveshah> do you have any inverted clocks in your design?
<maikmerten> I have only one clock, but the control logic acts on the falling edge, while stuff like the ALU, bus unit etc. act on the rising edge
<daveshah> I would say these can cause weird timing issues because at the moment (this will be fixed soon in nextpnr's own timing analysis) they aren't taken into account. But the fact your design's Fmax is double your operating clock more or less, then this wouldn't be the problem
<maikmerten> ah, okay
<daveshah> do you rely on initialised bram?
<maikmerten> yes (boot ROM), which is why I keep the system in reset for 2048 cycles
<daveshah> great
<maikmerten> there's a strange bram errata IIRC
<daveshah> yup
<daveshah> but 2048 cycles is more than enough to mitigate it
<maikmerten> yeah, but I also need to make sure the cache tags are invaldidated on reset ;-)
<maikmerten> and my horrible solution to that is to write zero to the cache tags one entry after another on each clock when reset is asserted ;-)
<maikmerten> so... just in case this happens due to my usage of inverted clocks and thus skewing timing results... arachne-pnr wouldn't care for that because all it does it to keep signal paths short, no matter what the clock?
<daveshah> the timing weighting in nextpnr isn't that big tbh
<daveshah> I don't think this is an inverted clock issue
<daveshah> assuming your duty cycle is near enough 50%, your design passes timing even considering the inverted clocks
cr1901_modern has quit [*.net *.split]
FL4SHK has quit [*.net *.split]
Max-P has quit [*.net *.split]
mwk has quit [*.net *.split]
flaviusb has quit [*.net *.split]
gnufan has quit [*.net *.split]
<daveshah> *clock duty cycle
<maikmerten> \o/ net split, woooo!
FL4SHK has joined #yosys
Max-P has joined #yosys
<maikmerten> okay, thanks :-)
<maikmerten> guess I'll do similar tests with arachne-pnr. Perhaps I just was lucky all the time and I'll find out that some seeds for arachne-pnr fail as well
mwk has joined #yosys
kraiskil has quit [Quit: Leaving]
cr1901_modern has joined #yosys
celadon has joined #yosys
<tpb> Title: nextpnr-ice40 seed (extension board, no cache) - Google Sheets (at docs.google.com)
<maikmerten> the good news is that I don't need to switch back to arachne-pnr
<maikmerten> the bad news is that not hitting any problems earlier with arachne-pnr was most likely just luck
<maikmerten> there must be some critical timing stuff going on in my design
seldridge has joined #yosys
<daveshah> it could be metastability?
<daveshah> if you have different clock domains or external IO
<maikmerten> only one clock driving everything
<maikmerten> heh, perhaps a silicon defect in my iCE40 ;-)
<maikmerten> these tests were conducted with external SRAM attached to the FPGA board, this would of course add considerable room for timing issues
<maikmerten> but I distinctly remember issues appearing with BRAM-only as well
<daveshah> I dare say it, but it might be worth seeing what happens in the vendor tools
<daveshah> They do perhaps have better timing, and rule out any possible icestorm bugs
<maikmerten> yeah, I might have to resort to that. I hear icecube2 is full of excellence.
<maikmerten> wow, Lattice presents me a registration page via HTTP. Manually changing to HTTPS works... at least.
<cr1901_modern> "icecube2" and "full of excellence" in the same sentence. I must've jumped between timelines recently...
<maikmerten> timelines all right https://www.youtube.com/watch?v=izrzkS5xxuc
leviathan has quit [Remote host closed the connection]
seldridge has quit [Ping timeout: 250 seconds]
<maikmerten> oh my, icecube2 is 32 bit. Great.
<maikmerten> awwwww, maaaaan. It wants a license file. They happily send me a license file tied to my NIC. And then it complains that license file does not match my NIC. Excellent!
m4ssi has quit [Remote host closed the connection]
GuzTech has quit [Remote host closed the connection]
<bluesceada> maikmerten, if you are in linux it might be due to icecube2 relies on using "eth0", newer distros don't use that naming scheme anymore
<bluesceada> easy solution is to load the dummy module
<bluesceada> then do ip link add dev eth0 type dummy
<bluesceada> and give it any mac address you want with ip link set dev eth0 address 00:11:22:33:44:55
<maikmerten> oh my. That's excellence right there.
<bluesceada> if you heard it with tuntap devices before, I prefer a dummy interface over that. At least on notebooks where you might use network-manager for all sorts of connections, a tuntap device sometimes can confuse it
<maikmerten> thanks for the hints
<bluesceada> it is anyway ridiculous "security", even on a 'real' eth0 device you can 1. rename it in software 2. often change the mac in software anyway ...
<maikmerten> I guess that's manager-type security
<maikmerten> bluesceada, cool, thanks, that worked wonderfully
AlexDaniel has joined #yosys
<maikmerten> okay, I guess I see now why iCECube2 is not universally referred to as being excellent.
seldridge has joined #yosys
<mithro> Has anyone played with RAM4K initialization options on the ice40 before?
dxld has quit [Ping timeout: 252 seconds]
dxld has joined #yosys
seldridge has quit [Ping timeout: 276 seconds]
seldridge has joined #yosys
kristianpaul has quit [Quit: Reconnecting]
kristianpaul has joined #yosys
SpaceCoaster has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
mjoldfield has joined #yosys
mjoldfie_ has quit [Ping timeout: 246 seconds]
m_w has joined #yosys
maikmerten has quit [Remote host closed the connection]
puddingpimp has quit [Remote host closed the connection]
m4ssi has joined #yosys
maartenBE has quit [Ping timeout: 264 seconds]
maartenBE has joined #yosys
maartenBE has quit [Ping timeout: 252 seconds]
puddingpimp has joined #yosys
maartenBE has joined #yosys
m4ssi has quit [Remote host closed the connection]
puddingpimp has quit [Quit: leaving]
tpb has quit [Remote host closed the connection]
tpb has joined #yosys