--- Log opened Thu May 28 00:00:09 2015 | ||
olofk | blueCmd: 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 list | 07:46 |
---|---|---|
olofk | If you're using Icarus, there is an option to list the timescales for all modules | 07:47 |
olofk | That can help track down some issues | 07:47 |
olofk | I 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 file | 07:48 |
blueCmd | olofk: yes, I ended up doing https://github.com/bluecmd/wb-axi/blob/master/bench/modelsim/Makefile | 10:22 |
blueCmd | 'vlog -timescale X' | 10:22 |
blueCmd | this 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 for | 10:23 |
blueCmd | I haven't written HDL in almost a year - when ModelSim fired up I got all excited, like seeing an old friend :P | 10:24 |
olofk | haha. I know the feeling :) | 11:07 |
olofk | I've been doing VHDL for the first time in almost a year, and I kind of like it in some way | 11:08 |
blueCmd | wb_stb_i - is it safe to consider that every new read/write starts with a posedge on that? | 19:32 |
blueCmd | for stuff like bursts and so on as well | 19:32 |
stekern | not really | 19:39 |
stekern | it's not mandatory to de-assert wb_stb_i between accesses | 19:39 |
blueCmd | ok, cool. I thought that might be the case. makes it slightly more complicated, but I'll manage | 19:57 |
blueCmd | thanks | 19:57 |
blueCmd | olofk: testbench.wb_bfm_transactor_i : 900/1000, done: 1 | 21:08 |
blueCmd | woo | 21:08 |
olofk | blueCmd: Exellent! | 21:08 |
blueCmd | I didn't do anything for bursts, is that tested in bfm_transactor? | 21:09 |
blueCmd | or is this only single reads/writes? | 21:09 |
olofk | Yes. You're using wb_bfm 1.0, right? | 21:09 |
blueCmd | https://github.com/openrisc/orpsoc-cores/tree/master/cores/wb_bfm/wb_bfm-0 | 21:10 |
olofk | It should print out some statitics on which cycles that were executed | 21:10 |
olofk | Ah ok. That one is old | 21:11 |
blueCmd | I see that you have some newer one in your repo | 21:11 |
blueCmd | I'll use that instead | 21:11 |
blueCmd | is it drop-in? | 21:11 |
olofk | Yes. Use that one instead. It will give you a lot better coverage | 21:11 |
olofk | Yeah, I think it should be compatible | 21:11 |
blueCmd | You should nuke the old code | 21:13 |
olofk | blueCmd: Yes, but I can't do that until I have migrated all the cores that depend on the old version | 21:14 |
olofk | I have started with that though | 21:14 |
olofk | But some of them don't pass regression tests so I need to investigate that | 21: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 |
blueCmd | FYI | 21:18 |
olofk | hmm | 21:18 |
olofk | ah yes. | 21:19 |
olofk | Stupid modelsim parses the files in line order, so it complains if a variable is defined further down in the code | 21:19 |
blueCmd | aha | 21:20 |
olofk | So lines 340 and 341 needs to be moved up | 21:20 |
olofk | night | 21:23 |
olofk | Sounds like you have made great progress. Very interested in trying it out when you're getting done | 21:23 |
blueCmd | sure thing! | 21:24 |
blueCmd | weird, I only get 2 errors ("Invalid cycle types: 2") but it did a lof bursts, and I didn't do *anything* to support those | 21:25 |
blueCmd | so that seems wrong | 21:25 |
stekern | blueCmd: bursts are backward compatible with non-burst slaves | 21:38 |
blueCmd | stekern: oh? fantastic | 21:45 |
blueCmd | I haven't read that part of the spec, that was for tomorrow - but that's awesome | 21:45 |
--- Log closed Fri May 29 00:00:10 2015 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!