chaoticryptidz has quit [Ping timeout: 272 seconds]
philtor has quit [Ping timeout: 272 seconds]
TD-Linux has joined #yosys
philtor has joined #yosys
agg has joined #yosys
FabM has joined #yosys
FabM has joined #yosys
FabM has quit [Changing host]
kristianpaul has quit [Remote host closed the connection]
kristianpaul has joined #yosys
ec_ has quit [*.net *.split]
ec_ has joined #yosys
ec has joined #yosys
ec_ has quit [Ping timeout: 268 seconds]
FabM has quit [Ping timeout: 240 seconds]
FabM has joined #yosys
FabM has joined #yosys
FabM has quit [Ping timeout: 240 seconds]
FabM has joined #yosys
FabM has joined #yosys
FabM has quit [Changing host]
ec has quit [Remote host closed the connection]
ec has joined #yosys
ec has quit [Remote host closed the connection]
ec has joined #yosys
<ikskuh>
heya o/ is this the right channel to ask some questions about pico rv32?
<jix_>
ikskuh: yeah, I'm not aware of any channel specific to picorv32
jix_ is now known as jix
<ikskuh>
ah, thanks
<ikskuh>
i figured i'm probably yeeting my own cpu design from my project and replace it with the picorv
<ikskuh>
mostly because of compilers and general slowness of my isa
<ikskuh>
but my system is designed for a 16 bit data bus right now, and i wonder if it's worth the change to blow up the data bus to 32 bit...
peepsalot has quit [Read error: Connection reset by peer]
peepsalot has joined #yosys
<acathla>
Hi. I have a design that is using 98% of the ICESTORM_LC of an iCE40up5K, and building fine ith yosys 0.15. With yosys 0.16 and later it takes 108% LC and, of course, fails. Where should I look to find the right option that would allow me to not get stuck to 0.15?
<tnt>
-no-rw-check
tlwoerner has joined #yosys
<jix>
Note that using that option (or older yosys versions) can result in a mismatch between synthesized behavior and simulation in certain cases. Probably fine on an existing working design, but good to be aware of
<jix>
You can also use (* no_rw_check *) as attribute on memories, which makes it easier to only omit the extra logic in cases where you made sure that it doesn't make a difference
ec has quit [Remote host closed the connection]
ec has joined #yosys
<acathla>
tnt, jix, thank you, that seems to work fine now !
ec has quit [Ping timeout: 268 seconds]
ec has joined #yosys
<tnt>
I'm still a bit unclear as to what logic yosys in inserting TBH ...
<tnt>
I did a synht_ice40; write_verilog; to try and see but it's not making any sense to me.
<tnt>
But in any case just looking at it, I'm fairly certain it's not strictly correct either on ice40. Because a R/W conflict is defined there as a read and write to the same address for the underlying RAM4k module which is always 16 bit wide and not for the wrapper above it that allows 1/2/4/8/16 bits accesses.
<tnt>
(i.e. technically for a 8 bits wide ram, a read access at address 0 and a write to address 1 is a conflict.
<jix>
I haven't looked at the specifics at all, but even if a read access to address 0 and a write to address 1 conflict on the underlying primitive, in that case you get the same result independent of whether the primitve reads the new or the old value, because for the read byte they are the same, right?
<tnt>
Ah but the official sim model doesn't specify read-first or write-first behavior. It specifies xxxx as output in case of conflict.
Raito_Bezarius has quit [Ping timeout: 255 seconds]
ec has quit [Quit: ec]
<jix>
ah, in that case that does seem like an issue to me