ChanServ changed the topic of #yosys to: Yosys Open SYnthesis Suite: https://github.com/YosysHQ/yosys/ | Channel logs: https://libera.irclog.whitequark.org/yosys/
tpb has quit [Remote host closed the connection]
tpb has joined #yosys
bl0x_ has joined #yosys
bl0x has quit [Ping timeout: 260 seconds]
lexano has quit [Ping timeout: 268 seconds]
lexano has joined #yosys
bjorkint0sh has quit [Remote host closed the connection]
bjorkint0sh has joined #yosys
ikskuh has joined #yosys
nak has quit [Ping timeout: 272 seconds]
nak has joined #yosys
<ikskuh> heya o/
<ikskuh> does anyone know if simulators like iverilog suffer from evaluation order?
<corecode> certainly
<corecode> your design shouldn't depend on evaluation order
<ikskuh> i mean thats true, but i don't really get some problems in my design. sometimes it works in sim, sometimes it doesn't
<ikskuh> but works perfectly in synthesis
<corecode> yes, synthesis works differently
<corecode> but either your design or your testbench suffer from race conditions; fixing them might uncover design errors
<tpb> Title: View paste L6DJI (at bpa.st)
<ikskuh> this is the design that might be flawed
<ikskuh> it's a basic RAM implementation
<ikskuh> memory bus is that of the picorv32
<ikskuh> writes on the memory don't seem to work in iverilog
<ikskuh> they used to work, but now they stopped working, which is weird
<ikskuh> and i didn't change my code
<corecode> what's your testbench
<ikskuh> the testbench is basically "let the system run for somethousand clocks and boot the firmware"
<ikskuh> and the whole soc is simulated
<ikskuh> the race condition can be fixed by copying instances up/down in the verilog source
<ikskuh> which is really weird imho
<corecode> no, that means that you are suffering from evaluation order
<corecode> what are the failures?
<corecode> do you have a testbench for only your ram module?
<ikskuh> not really. i could remove every peripherial
<ikskuh> i can try reducing the code
<ikskuh> i should improve my tooling a bit anyways /o\ this is way too much manual work right now ^^
<corecode> you probably should have a test bench for every module you write
<ikskuh> yeah true
<ikskuh> but i guess the testbench would not capture this problem
<corecode> then your test bench is not thorough enough
<corecode> your module looks simple enough, so maybe the error is elsewhere
<corecode> you say the writes don't work, how does that manifest?
<corecode> they don't change the ram contents? reads later don't give you the correct contents?
<ikskuh> hey, they don't change the ram contents
<ikskuh> so i write something, and when i read it again, it iwll read just xxxxxxxx
<corecode> do all reads return x?
<ikskuh> i'm checking right now
<ikskuh> yeah seems to
<ikskuh> *so
<corecode> you really need a test bench for just your component, so that you can observe what is going on
<corecode> are you looking at captured signals?
<corecode> my guess is that something has the protocol wrong
<corecode> one clock cycle off or something like it
<ikskuh> i'm looking at the vvp output with gtkwave
<ikskuh> some comments to that gist: ashet-soc.v is mainly generated, and all the cs_... signals are automatically generated
<ikskuh> main_cpu is the picorv32 cpu copied from the yosys github
<ikskuh> main_rom and main_ram are both instances of the memory module that seems to fail
<ikskuh> as i can successfully execute code without problems, so the reading-part seems to work
<ikskuh> the writing part doesn't, tho
<ikskuh> (fixed the lowres screenshots)
<ikskuh> corecode: i found the bug \o/
<ikskuh> i'm accessing the storage[] array out of bounds
<ikskuh> thanks for joining me in my rubber duck debugging session :D
acathla has joined #yosys
<corecode> ikskuh: shouldn't that wrap around?
<corecode> ikskuh: why did the bus arbiter route it to your memory even?
<ikskuh> because i access 0x8000_0000
<ikskuh> which the ram portion is mapped to
nonchip has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
nonchip has joined #yosys