| --- Log opened Fri Dec 19 00:00:17 2014 | ||
| _franck__ | any systemc user here ? | 08:25 |
|---|---|---|
| wallento | _franck_: yes | 08:54 |
| _franck__ | question from a newbie: I have a wishbone master with a wb_adr port which is a sc_lv<32> (or sc_uint). I my top simulation file, I want to connect wb_adr[0] to my DUT wb_adr wich is defined as a sc_in<bool> (generated by verilator) | 08:59 |
| _franck__ | how do we do that ? | 08:59 |
| _franck__ | I can't find any implicit casting from sc_uint ot sc_lv to bool | 09:00 |
| wallento | first of all you should avoid sc_lv | 09:01 |
| wallento | this has some performance issues | 09:01 |
| wallento | why is wb_adr bool? | 09:01 |
| wallento | it should all bei uint32_t | 09:01 |
| _franck__ | because it is one bit wide and verilator generates it as bool | 09:02 |
| _franck__ | wait I'll show you | 09:02 |
| wallento | you can force it to be unsigned int | 09:02 |
| _franck__ | http://pastie.org/9789632 | 09:02 |
| _franck__ | cool, so tell me how :) | 09:03 |
| wallento | yes, in a sec | 09:03 |
| wallento | need to find it in the verilator documentation :) | 09:03 |
| wallento | this is the one that helps you in your case: /*verilator sc_bv*/ | 09:05 |
| wallento | Used after a port declaration. It sets the port to be of sc_bv<width> type, instead of bool, vluint32_t or vluint64_t. This may be useful if the port width is parametrized and different of such modules interface a templated module (such as a transactor) or for other reasons. In general you should avoid using this attribute when not necessary as with increasing usage of sc_bv the performance increases significantly. | 09:05 |
| wallento | I still search for the setting that avoids bool and uses uint32_t instead | 09:05 |
| wallento | mmh, I think this needs to be done manually, which is kinda ugly | 09:07 |
| wallento | how does your testbench look like? | 09:08 |
| wallento | do you generate 32 bit addresses? | 09:08 |
| wallento | and connect the gpio module to a bus or so | 09:09 |
| _franck__ | yes, my wb_master has a 32 bit wb_adr signal | 09:09 |
| wallento | then I would recommend adjusting gpio's wb_adr_i to the bus address width | 09:09 |
| _franck__ | yes | 09:09 |
| wallento | and only use sc_signal<uint32_t> | 09:09 |
| wallento | the problem is you cannot simply attach an sc_in<bool> to an sc_signal<uint32_t> on bit zero | 09:10 |
| _franck__ | I wanted something generic. I don't want to touch anything in gpio.v. I'm setting up a test environment for bare metal drivers | 09:10 |
| wallento | of course you could overload it.. | 09:10 |
| wallento | then you need some process to convert this | 09:11 |
| wallento | the problem is: why is this a single bit? | 09:11 |
| _franck__ | I'll run the test on or1ksim, then drive a wb_master to control the verilated ip | 09:11 |
| wallento | is it like bit 31? | 09:11 |
| _franck__ | because gpio.v use only two registers | 09:11 |
| wallento | ah, line two then | 09:11 |
| wallento | wait a minute, I will think about it | 09:12 |
| wallento | or1ksim output is also uint32_t, correct? | 09:13 |
| _franck__ | it is | 09:13 |
| _franck__ | well, it's something else but, whatever it's not a problem here | 09:14 |
| wallento | but its arithmetic and not sc_bv, correct? | 09:15 |
| _franck__ | or1ksim (when used as a lib) use a function like this generic_read(void *class_ptr, unsigned long int addr, unsigned char mask[], unsigned char rdata[], int data_len) to read something | 09:15 |
| _franck__ | so it's pure c++ so after that, I'll interact with my systemc wb_master from this function | 09:16 |
| _franck__ | only c++ here | 09:16 |
| wallento | ah | 09:26 |
| wallento | this one: --pins-sc-uint | 09:26 |
| wallento | no, also not, mmh, I was quite sure there is a flag that can make 1 bits a uint32_t | 09:28 |
| wallento | if we really cannot force verilator to generate a uint32_t port for one bit wires, we need an extra process that does this | 09:29 |
| wallento | unfortunately | 09:29 |
| wallento | mmh, I just came to that we cannot avoid this at all | 09:30 |
| wallento | I assume gpio adr must be connected to bit 2 of the bus, correct? | 09:30 |
| wallento | I would put a verilog wrapper around the module | 09:31 |
| wallento | and have the wrapped adr mapped to input adr_i [2] | 09:31 |
| _franck__ | ok, good idea, thanks for your help | 09:33 |
| olofk | I've been thinking about this. I wonder if we should always make wb_adr 32 bits for all slaves | 09:57 |
| olofk | I usually make it smaller to avoid some warnings, but there are benefits with keeping it 32 bits | 09:58 |
| olofk | An IP-XACT model must have a fixed width, I think. And VHDL records (prior to 2008) must have a fixed width too | 09:58 |
| olofk | _franck__: What are you doing btw? Are you trying to use or1ksim together with verilog peripherals in verilator? | 09:59 |
| _franck__ | olofk: yes | 10:00 |
| olofk | AWESOME!!! I've been thinking about that for YEARS! | 10:00 |
| _franck__ | :) | 10:01 |
| _franck__ | so we can check the core _and_ the software lib (a.k.a baremetal driver) at the same time | 10:01 |
| olofk | Yes, I love it! | 10:01 |
| stekern | _franck__: is your house ready renovated now? ;) | 10:02 |
| _franck__ | not at all, just doing this during my day job ;) | 10:03 |
| stekern | ah, nice ;) | 10:04 |
| _franck__ | you tell that to my boss :) | 10:05 |
| olofk | I'm wondering if there's something fishy with the JTAG connection here | 19:05 |
| olofk | _franck__: Why is the expected tap ID set to 0x14951185 for the Mohor tap in the OpenOCD scripts, while it's set to 0x149511c3 in the code? | 19:08 |
| olofk | I noticed that the difference is that the manifacturer part is shifted one bit. Not sure if that's relevant | 19:08 |
| olofk | hmm.. or is it shifted...? | 19:10 |
| olofk | I can't understand how JTAG so often works. It seems like a complete mess to me | 19:10 |
| olofk | aha... it was set to 0x14951185 in the orpsocv2 fork | 19:17 |
| olofk | hmm... was there some shifting bug in one of the implementations? | 19:18 |
| _franck__ | olofk: yes there was something like this | 19:45 |
| olofk | _franck__: Should the one in the scripts be changed? (guess it's not a big deal, but still) | 19:46 |
| olofk | A bigger problem is that I can't hook up gdb to icarus via openocd and jtag_vpi anymore | 19:47 |
| olofk | openocd connects fine and halts the CPU, but nothing happens when I connect gdb | 19:47 |
| olofk | I remember it was slow, but I think it used to at least work | 19:47 |
| _franck__ | did you try with mor1kx generic ? | 19:49 |
| olofk | yep | 19:50 |
| olofk | Running it right now | 19:50 |
| _franck__ | cant help you that much iam afk right now | 19:51 |
| olofk | Yeah. Me too. It's not like I'm sitting home alone on a friday night and trying to set up a JTAG connection to a simulator | 19:52 |
| _franck__ | what does gdb say ? | 19:52 |
| olofk | It's a friend who's asking | 19:52 |
| _franck__ | :) | 19:52 |
| olofk | I had remotetimeout set to 100, and gdb doesn't say anything at all. When I set it back to 2, I get timeout and packet errors | 19:53 |
| olofk | ...said my friend | 19:53 |
| _franck__ | iam about to wath the hobit. it has been years since i didnt go to the cinema at night | 19:54 |
| _franck__ | did you look at the wabeform ? | 19:55 |
| _franck__ | is jtag alive ? | 19:56 |
| _franck__ | ah yes you told me openocd is ok | 19:56 |
| _franck__ | ypu know it is super long. did you wait enough ? | 19:57 |
| olofk | Yeah, it might be that I should wait longer. I'll look at the waveform first to see if I can spot anything obvious. | 20:03 |
| olofk | Saw the first Hobbit movie in the cinema, but I haven't been away since I got kids | 20:03 |
| olofk | hmm.. adding some debug printouts to OpenOCD. Everything looks fine. It reads back registers 0-34 (32 gprs + npc + ppc + version reg?) | 20:14 |
| olofk | But I do get a warning "Debug: 332 3890 log.c:422 keep_alive(): keep_alive() was not invoked in the 1000ms timelimit (2788). This may cause trouble with GDB connections." | 20:15 |
| olofk | and this is before I even have connected gdb | 20:17 |
| olofk | Could it be that jtag_vpi isn't reading from the buffer fast enough so openocd has to wait and spends more than 1000ms between running the keep_alive function | 20:18 |
| olofk | ? | 20:18 |
| olofk | s/buffer/socket | 20:18 |
| olofk | hmm... OpenOCD connects to the real target as well now, but GDB fails to connect to OpenOCD | 21:05 |
| olofk | And there aren't any messages at all in openocd to indicate that gdb tries to connect | 21:05 |
| olofk | Newlib 2.2.0 was released. The changelogs mention or1k, but is this all the patches? | 21:08 |
| olofk | Diffing wallento's tree against 2.2.0. Seems to differ on some OpenRISC stuff | 21:20 |
| olofk | _franck__: For some reason it works much better when I connect to port 3333 instead of 5555 | 21:43 |
| olofk | Time to consult the great IRC archive to remind me how to use this thing | 21:45 |
| olofk | A little embarrasing detail is that 90% of the results when searching for gdb in the IRC logs results is me trying to figure out how to connect/load files/read memory. | 21:51 |
| olofk | Isn't si supposed to execute just one instruction? | 22:30 |
| olofk | gdb just hangs after executing that | 22:30 |
| olofk | But after Ctrl-C it looks like I end up somewhere else | 22:31 |
| olofk | I vaguely remember people having problems with single-stepping. Could this be related? | 22:32 |
| olofk | Whaaaat!!!!?!?!?! It looks like my DDR2 controller works on the board first time I tried it | 22:33 |
| -!- _franck__ is now known as _franck_ | 22:55 | |
| olofk | Does anyone have some minimal assembler code for setting up the uart and printing something? | 22:56 |
| olofk | Oh well. This is enough social activitites for me. Good night | 22:59 |
| --- Log closed Sat Dec 20 00:00:19 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!