IRC logs for #openrisc Thursday, 2015-05-28

--- Log opened Thu May 28 00:00:09 2015
olofkblueCmd: It's a bitch to handle the timescales correctly in verilog. My empiric study of this is that it's best to put modules that has a hard requirement on a timescale first in the dependency list07:46
olofkIf you're using Icarus, there is an option to list the timescales for all modules07:47
olofkThat can help track down some issues07:47
olofkI also think that you can specify timescale at compile-time, but I'm not sure if FuseSoC is set up to handle that. I've been thinking about handling timescales with a special config parameter in the core file07:48
blueCmdolofk: yes, I ended up doing
blueCmd'vlog -timescale X'10:22
blueCmdthis particular bench is ModelSim, since I want to simulate against Xilinx's IP cores to make sure it works for what I want it to work for10:23
blueCmdI haven't written HDL in almost a year - when ModelSim fired up I got all excited, like seeing an old friend :P10:24
olofkhaha. I know the feeling :)11:07
olofkI've been doing VHDL for the first time in almost a year, and I kind of like it in some way11:08
blueCmdwb_stb_i - is it safe to consider that every new read/write starts with a posedge on that?19:32
blueCmdfor stuff like bursts and so on as well19:32
stekernnot really19:39
stekernit's not mandatory to de-assert wb_stb_i between accesses19:39
blueCmdok, cool. I thought that might be the case. makes it slightly more complicated, but I'll manage19:57
blueCmdolofk: testbench.wb_bfm_transactor_i : 900/1000, done: 121:08
olofkblueCmd: Exellent!21:08
blueCmdI didn't do anything for bursts, is that tested in bfm_transactor?21:09
blueCmdor is this only single reads/writes?21:09
olofkYes. You're using wb_bfm 1.0, right?21:09
olofkIt should print out some statitics on which cycles that were executed21:10
olofkAh ok. That one is old21:11
blueCmdI see that you have some newer one in your repo21:11
blueCmdI'll use that instead21:11
blueCmdis it drop-in?21:11
olofkYes. Use that one instead. It will give you a lot better coverage21:11
olofkYeah, I think it should be compatible21:11
blueCmdYou should nuke the old code21:13
olofkblueCmd: Yes, but I can't do that until I have migrated all the cores that depend on the old version21:14
olofkI have started with that though21:14
olofkBut some of them don't pass regression tests so I need to investigate that21:14
blueCmd** Warning: [8] ../../cores/wb_bfm/wb_bfm_transactor.v(270): (vlog-2623) Undefined variable: transaction.21:18
blueCmd** Warning: [8] ../../cores/wb_bfm/wb_bfm_transactor.v(270): (vlog-2623) Undefined variable: subtransaction.21:18
olofkah yes.21:19
olofkStupid modelsim parses the files in line order, so it complains if a variable is defined further down in the code21:19
olofkSo lines 340 and 341 needs to be moved up21:20
olofkSounds like you have made great progress. Very interested in trying it out when you're getting done21:23
blueCmdsure thing!21:24
blueCmdweird, I only get 2 errors ("Invalid cycle types: 2") but it did a lof bursts, and I didn't do *anything* to support those21:25
blueCmdso that seems wrong21:25
stekernblueCmd: bursts are backward compatible with non-burst slaves21:38
blueCmdstekern: oh? fantastic21:45
blueCmdI haven't read that part of the spec, that was for tomorrow - but that's awesome21:45
--- Log closed Fri May 29 00:00:10 2015

Generated by 2.15.2 by Marius Gedminas - find it at!