| *** tpb <[email protected]> has joined #yosys | 00:00 | |
| *** bl0x_ <bl0x_!~bl0x@p200300d7a7126300f8ec693783760bc7.dip0.t-ipconnect.de> has joined #yosys | 02:59 | |
| *** bl0x <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 03:01 | |
| *** lexano <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 07:47 | |
| *** lexano <[email protected]> has joined #yosys | 08:00 | |
| *** bjorkint0sh <bjorkint0sh!~bjork@2600:1700:5400:c80:bfc:c58c:a354:7a7f> has quit IRC (Remote host closed the connection) | 09:14 | |
| *** bjorkint0sh <bjorkint0sh!~bjork@2600:1700:5400:c80:fa54:e67d:fc21:3d3d> has joined #yosys | 09:14 | |
| *** ikskuh <ikskuh!~xq@2a0d:5940:6:163::ad7e> has joined #yosys | 10:21 | |
| *** nak <nak!~nak@yosys/nak> has quit IRC (Ping timeout: 272 seconds) | 10:55 | |
| *** nak <nak!~nak@yosys/nak> has joined #yosys | 10:56 | |
| ikskuh | heya o/ | 11:12 |
|---|---|---|
| ikskuh | does anyone know if simulators like iverilog suffer from evaluation order? | 11:13 |
| corecode | certainly | 14:31 |
| corecode | your design shouldn't depend on evaluation order | 14:31 |
| 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 | 14:50 |
| ikskuh | but works perfectly in synthesis | 14:50 |
| corecode | yes, synthesis works differently | 15:03 |
| corecode | but either your design or your testbench suffer from race conditions; fixing them might uncover design errors | 15:04 |
| ikskuh | https://bpa.st/L6DJI | 15:14 |
| tpb | Title: View paste L6DJI (at bpa.st) | 15:14 |
| ikskuh | this is the design that might be flawed | 15:15 |
| ikskuh | it's a basic RAM implementation | 15:15 |
| ikskuh | memory bus is that of the picorv32 | 15:15 |
| ikskuh | writes on the memory don't seem to work in iverilog | 15:16 |
| ikskuh | they used to work, but now they stopped working, which is weird | 15:16 |
| ikskuh | and i didn't change my code | 15:16 |
| corecode | what's your testbench | 16:23 |
| ikskuh | the testbench is basically "let the system run for somethousand clocks and boot the firmware" | 16:38 |
| ikskuh | and the whole soc is simulated | 16:38 |
| ikskuh | the race condition can be fixed by copying instances up/down in the verilog source | 16:38 |
| ikskuh | which is really weird imho | 16:38 |
| corecode | no, that means that you are suffering from evaluation order | 16:42 |
| corecode | what are the failures? | 16:43 |
| corecode | do you have a testbench for only your ram module? | 16:43 |
| ikskuh | not really. i could remove every peripherial | 16:44 |
| ikskuh | i can try reducing the code | 16:44 |
| ikskuh | i should improve my tooling a bit anyways /o\ this is way too much manual work right now ^^ | 16:47 |
| corecode | you probably should have a test bench for every module you write | 16:48 |
| ikskuh | yeah true | 16:48 |
| ikskuh | but i guess the testbench would not capture this problem | 16:48 |
| corecode | then your test bench is not thorough enough | 16:48 |
| corecode | your module looks simple enough, so maybe the error is elsewhere | 16:49 |
| corecode | you say the writes don't work, how does that manifest? | 16:50 |
| corecode | they don't change the ram contents? reads later don't give you the correct contents? | 16:50 |
| ikskuh | hey, they don't change the ram contents | 16:53 |
| ikskuh | so i write something, and when i read it again, it iwll read just xxxxxxxx | 16:53 |
| corecode | do all reads return x? | 16:55 |
| ikskuh | i'm checking right now | 16:59 |
| ikskuh | yeah seems to | 17:01 |
| ikskuh | *so | 17:01 |
| corecode | you really need a test bench for just your component, so that you can observe what is going on | 17:03 |
| corecode | are you looking at captured signals? | 17:03 |
| corecode | my guess is that something has the protocol wrong | 17:04 |
| corecode | one clock cycle off or something like it | 17:04 |
| ikskuh | https://gist.github.com/MasterQ32/91aff45f8b7ef920bc388e63789360c9 | 17:08 |
| ikskuh | i'm looking at the vvp output with gtkwave | 17:08 |
| ikskuh | some comments to that gist: ashet-soc.v is mainly generated, and all the cs_... signals are automatically generated | 17:10 |
| ikskuh | main_cpu is the picorv32 cpu copied from the yosys github | 17:11 |
| ikskuh | main_rom and main_ram are both instances of the memory module that seems to fail | 17:11 |
| ikskuh | as i can successfully execute code without problems, so the reading-part seems to work | 17:12 |
| ikskuh | the writing part doesn't, tho | 17:12 |
| ikskuh | (fixed the lowres screenshots) | 17:14 |
| ikskuh | corecode: i found the bug \o/ | 17:22 |
| ikskuh | i'm accessing the storage[] array out of bounds | 17:23 |
| ikskuh | thanks for joining me in my rubber duck debugging session :D | 17:27 |
| *** acathla <[email protected]> has joined #yosys | 18:54 | |
| corecode | ikskuh: shouldn't that wrap around? | 19:24 |
| corecode | ikskuh: why did the bus arbiter route it to your memory even? | 19:28 |
| ikskuh | because i access 0x8000_0000 | 20:00 |
| ikskuh | which the ram portion is mapped to | 20:01 |
| *** nonchip <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 23:06 | |
| *** nonchip <[email protected]> has joined #yosys | 23:06 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!