whitequark changed the topic of #yosys to: Yosys Open SYnthesis Suite: https://github.com/YosysHQ/yosys/ | Channel logs: https://libera.irclog.whitequark.org/yosys/ | Bridged to #yosys:matrix.org
tpb has quit [Remote host closed the connection]
tpb has joined #yosys
lexano has quit [Ping timeout: 264 seconds]
GenTooMan has quit [Read error: Connection reset by peer]
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #yosys
notgull has quit [Ping timeout: 260 seconds]
notgull has joined #yosys
cybernaut has joined #yosys
cybernaut has quit [Read error: Connection reset by peer]
GenTooMan has joined #yosys
notgull has quit [Ping timeout: 260 seconds]
emeb_mac has quit [Quit: Leaving.]
notgull has joined #yosys
notgull has quit [Ping timeout: 260 seconds]
notgull has joined #yosys
e_ter is now known as eater
<Zevv> On ICE40 I need to instantiate my bram explicitly using SB_RAM256X16 because I need the write mask bits, but now I don't know how to initialize the memory; how can this be done?
xiretza[cis] has joined #yosys
<xiretza[cis]> can't yosys infer write masks nowadays?
<Zevv> oh, maybe; I'm not sure where I can find info about that?
<tpb> Title: 10. Memory mapping (at yosyshq.readthedocs.io)
<tpb> Title: 10. Memory mapping (at yosyshq.readthedocs.io)
<Zevv> sweet, thank you!
<Zevv> what's the general way inference works - like, how is my code matched against a potential infered implementation?
<xiretza[cis]> a big bag of heuristics
<Zevv> yeah that's what I expected
<xiretza[cis]> usually it works quite well, sometimes you have to do things like shift around read/write blocks to get transparency semantics that are possible in hardware
<Zevv> yes, found and read that, and got it working. thank you
<Zevv> I just passed the riscv compliance test
<xiretza[cis]> congrats!
<Zevv> one small step for mankind, one giant leap for Zevv
jryans has quit [Quit: Connection closed for inactivity]
<lofty> Zevv: what extensions do you plan to implement?
<Zevv> none, it's ment merely for control stuff that I'm too lazy to write logic for
<Zevv> I want it lean and mean.
<Zevv> problem with M is that apart from the mul it also needs to impl a div. That's kind of crappy
<Zevv> for F i'm not interested.
<Zevv> and csrr is not relevant for me as well, I won't be running linux on it ;)
<lofty> Zevv: Zmmul :p
<Zevv> it's now 30% of a UP5k, running at 40Mhz, including BRAM, SPRAM, UART and LED PWM.
<Zevv> good enough for now.
<Zevv> hey zmmul, nice
<Zevv> that's just a toolchain thing I guess, so it will assume mul is there but never emit a div
<lofty> Mhm
<lofty> And even having multiply accelerates division in practice
<Zevv> sure. but still. the sheer amount of work to get that going and test it and all
<lofty> Though I guess it depends if you're using a UP5K DSP or not
<Zevv> I might put MUL in though; I used 2 of my MAC_16s for the alu add and sub, so there's enough left
<Zevv> I guess it won't infer a 32x32 mul for me :)
<lofty> Sure it can
<Zevv> it can?
<lofty> It can.
<Zevv> no way
<lofty> Yosys has a script - mul2dsp - to convert large multiplications into chunks of small multiplications
<lofty> So yes, it can.
<Zevv> wow. lemme try that
<lofty> Are you passing -dsp to synth_ice40?
<Zevv> I am now
<Zevv> whoa
<Zevv> I just got MUL running
<Zevv> I'll have to throw out my manual MAC_16 stuff as well now
<Zevv> well, at least I learned something from implementing those.
<lofty> ;)
<Zevv> well you got me there. I now do rv32im
<Zevv> let me upgrady my test suite
<Zevv> oh there's also E, didn't know that
<Zevv> sweet
<Zevv> well, actually, I don't care, it's just bram.
<Zevv> wait but -dsp does not infer my regular `+` and `-` to a MAC_16, how is that
emeb_mac has joined #yosys
SpaceCoaster has quit [Quit: Bye]
SpaceCoaster has joined #yosys
lexano has joined #yosys
notgull has quit [Ping timeout: 260 seconds]
notgull has joined #yosys
bjorkintosh has quit [Quit: Leaving]
bjorkintosh has joined #yosys
bjorkintosh has quit [Changing host]
bjorkintosh has joined #yosys
<tnt> Just rebuilt yosys/nextpnr for new laptop ... trying to build a project from a year ago and ...
<tnt> "Visited AIG node more than once; this could be a combinatorial loop that has not been broken"
<tnt> And `-noabc9` to the rescue.
<lofty> tnt: file a bug
<tnt> I'm checking with the last oss-cad-suite ATM to see if it's reproducible on a "known good build" of yosys
<tnt> and it does :/
<lofty> I mean, there's a non-zero chance that your design does actually have a combinational loop in it somehow
<tnt> That nextpnr somehow misses ?
<lofty> well, nextpnr doesn't get the netlist that ABC9 does. but anyway, I can take a look.
<tnt> Trying to package a test case rn.
<lofty> well, bugpoint is churning away on it.
<tnt> It's the async set in uart_tx.v on line 58.
<tnt> changing `always @(posedge clk or posedge rst)` to `always @(posedge clk)` makes it build.
<lofty> ...then yes, you absolutely have a combinational loop, but one that nextpnr does not recognise
<lofty> now, ABC9 *should* catch this somewhere in the loop-checking code
<tnt> Also uart_tx.v is instanced twice ... and only one of the instance have the issue ...
dkc has joined #yosys
notgull has quit [Ping timeout: 252 seconds]
notgull has joined #yosys
nonchip has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
nonchip has joined #yosys
corecode has quit [Quit: ZNC - http://znc.in]