--- Log opened Sat Apr 13 00:00:13 2013 | ||
stekern | hmm, why doesnt the %h format works like I expect it to in verilator? | 06:33 |
---|---|---|
stekern | it just show 0x00000001 for all values | 06:33 |
-!- JanC_test_ is now known as JanC_test | 08:13 | |
@juliusb | stekern: interesting, I'm not sure I've ever relied on those things working in Verilator | 08:45 |
stekern | our old friend r. diez have noticed some bug related to %h when compiling with 03 and gcc 4.7.2 | 08:51 |
stekern | http://www.veripool.org/boards/2/topics/show/927?r=934 | 08:51 |
stekern | I don't think that's what happening in my case, but might be related to using gcc 4.7.2 | 08:51 |
stekern | anyways, I'm printing the PCs as %d now and convert them :/ | 08:52 |
stekern | maybe I should update my system c libraries and verilator | 08:52 |
@juliusb | what about using just -O2? | 08:53 |
@juliusb | are you debuging Linux boot? | 08:53 |
stekern | are we even using O3? | 08:53 |
stekern | yes, debugging Linux boot | 08:53 |
@juliusb | do a prepare-vlt with V=1 | 08:54 |
@juliusb | I think so | 08:54 |
@juliusb | # The default optimisation flag applied to all of the cycle accurate model files | 08:54 |
@juliusb | VLT_CFLAGS +=-O3 | 08:54 |
@juliusb | that's in scripts/make/Makefile-board-verilator.inc | 08:54 |
stekern | ah, ok, I'll try doing it with 02 then | 08:55 |
stekern | I'm trying to get rid of this: https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx_decode.v#L361 | 08:55 |
stekern | the condition that the comment claims doesn't exist anymore, but removing those bring out some bug still | 08:55 |
stekern | and it only happens in the end of the linux boot | 08:55 |
stekern | I've managed to reduce it to (op_lsu_store_o & op_jal) | 08:56 |
@juliusb | ah I see, you want to finish calculating the branch address even though LSU may still be busy | 08:56 |
stekern | and it looks like a store in a delay slot followed by a l.jal (so back to back branches) | 08:57 |
@juliusb | ohhh, delay slots | 08:58 |
stekern | nmja, the original problem came from that the cappuccino fetcher was a bit unstallable | 08:59 |
@juliusb | I liked your description of it as a wild horse | 08:59 |
@juliusb | :) | 09:00 |
@juliusb | pulling the CPU forward through the code, not wanting to be held back by and pesky multi-cycle instructions | 09:00 |
@juliusb | s/and/any/ | 09:00 |
stekern | just like that =P | 09:00 |
stekern | so when the branch came during the load/store the instruction currently in decode stage got replaced with the branch destination instruction | 09:03 |
@juliusb | and which instruction was in decode stage? | 09:07 |
stekern | before moving branch resolving to decode stage, it could be whatever, basically what would be in the delay slot | 09:11 |
stekern | actually, I think moving the branches to decode stage should have already fixed that condition, but there might be something that I'm overseeing, in any case having a wild horse fetcher is probably a bad idea =P | 09:13 |
stekern | O2 didn't help | 09:14 |
stekern | I'll just continue converting the %d manually, it's just two numbers, pc_decode and pc_execute | 09:14 |
@juliusb | :-/ | 09:15 |
@juliusb | strange | 09:15 |
@juliusb | ya maybe a verilator update will help | 09:15 |
stekern | I've already found the l.jal, but I wasn't printing the pc_decode, so I don't know where the store is | 09:15 |
stekern | once I know, it should be an excellent oppurtunity to write a test that mimics that condition | 09:15 |
stekern | I really love debugging this way, debug printing rom the verilog code | 09:16 |
stekern | s/from/rom | 09:16 |
stekern | s/rom/from | 09:16 |
stekern | bah | 09:16 |
stekern | simply mimicking the condition didn't bring out anything... | 11:42 |
@juliusb | it is quite cool being able to pritnf() from Verilog :) | 11:45 |
@juliusb | if only that was synthesisable :) | 11:46 |
@juliusb | stekern: what were the eint_pads for? | 11:47 |
@juliusb | (on the de0 nano port) | 11:47 |
stekern | umm, I think that was something that gong tao guy added | 12:07 |
@juliusb | oh right | 12:08 |
stekern | basically I believe it's for if you want to put something on the pin-headers that generates interrupts | 12:08 |
@juliusb | yep | 12:08 |
@juliusb | have a nice little software LED PWM on the de0 nano | 13:58 |
@juliusb | oh yeah, or1k teleconf.... | 16:14 |
@juliusb | stekern: what interrupt model do you normally use? | 17:33 |
@juliusb | interrupt behaviour type, I mean - edge, level, or the OR1200 latched-level? | 17:33 |
@juliusb | the default on mor1kx is edge | 17:33 |
@juliusb | and the mor1kx-dev-env driver's interrupt handler attempts to clear a set interrupt in the PICSR by writing the PICSR | 17:34 |
@juliusb | but for edge don't we write the particular bit back? | 17:34 |
@juliusb | else if (spr_we_i & spr_addr_i==`OR1K_SPR_PICSR_ADDR) | 17:34 |
@juliusb | spr_picsr[irqline] <= spr_dat_i[irqline] ? 0 : | 17:34 |
@juliusb | spr_picsr[irqline]; | 17:34 |
@juliusb | that's in the edge-triggered bit | 17:34 |
stekern | juliusb: depends, for linux you need the or1200-latched-level one | 17:57 |
stekern | but the tests needs the default | 17:57 |
@juliusb | hmmm | 18:00 |
@juliusb | not if they're using the built-in interrupt handling code, though | 18:00 |
@juliusb | anyway, it's something we should handle with the core features identification thing | 18:00 |
@juliusb | indicate what the scheme being used is and the software can set up interrupt handling properly | 18:00 |
@juliusb | on the TODO list :) | 18:00 |
stekern | I'm not sure I understand your other question, what do you mean by write the particular bit back? | 18:02 |
@juliusb | well, clearing the PICSR | 18:02 |
@juliusb | clearing the interrupt in the PICSR - for edge you write '0' to the bit, for latched-level you write '1' | 18:03 |
@juliusb | I got that around the wrong way | 18:03 |
stekern | don't you always write '1'? | 18:03 |
stekern | to clear | 18:03 |
stekern | except for or1200 compatible interrupts | 18:03 |
@juliusb | edge you write '1', level you don't write anything (just lower the external line), and latched-level (OR1200 interrupts) you must both lower the external interrupt and write '0' to the PICSR's bit | 18:04 |
@juliusb | latched-level is the odd-one out really | 18:04 |
jiayu | hello, everyone. I was just begining the orpsocv2. And I met some problem. is there anyone can help me? | 18:09 |
jiayu | I installed the ISE 13.2 for linux (32bit) webpack in the virtual box image provided by official website. | 18:09 |
@juliusb | what's the problem? | 18:10 |
stekern | yeah, agreed, but was there some problem with the edge clearing, or am I just not understanding? | 18:10 |
jiayu | I finished the synthesis in the terminal. | 18:10 |
stekern | I see no problem, but it sounded like you thought there was a problem =P | 18:10 |
jiayu | then I start mapping, place and route | 18:10 |
@juliusb | no, there's no problem with clearing the edge - it's just I debugged an interrupt problem and realised that the mor1kx default was enabled (endge triggered) and the mor1kx-dev-env (and ORPSoC, too I guess) default software clearing method is the level-latched | 18:10 |
stekern | juliusb: aha, you didn't asnwer me there ;) | 18:11 |
stekern | aha, ok | 18:11 |
@juliusb | so just making that observation | 18:11 |
jiayu | hethe problem is the terminal shows up that [orpsoc_mapped.ncd] Error 2 | 18:11 |
@juliusb | would be good if the a) CPU had a way of indicating which interrupt strategy it was using and b) the software could figure it out | 18:12 |
@juliusb | (and then use the right interrupt-clearing method for that strategy automatically) | 18:12 |
stekern | yeah | 18:12 |
@juliusb | jiayu: any idea as to what the error is | 18:12 |
jiayu | no, the terminal just shows that | 18:13 |
stekern | I think Linux can be configured to use edge triggered too, but I haven't tested that | 18:13 |
stekern | jiayu: run make with V=1 | 18:13 |
jiayu | Ok ,let me try that | 18:14 |
jiayu | the same result. | 18:14 |
jiayu | error again | 18:14 |
stekern | yes, but didn't you get some more information | 18:15 |
jiayu | it's seems like a license problem | 18:16 |
jiayu | that FLEXnet Licesing error: -5,357 | 18:17 |
stekern | there you go, problem solved | 18:18 |
jiayu | it seems like ise can't find my license file Xilinx.lic | 18:18 |
jiayu | but during the installation. i have already added a webpack license. | 18:20 |
stekern | how did you obtain that license? | 18:23 |
jiayu | is that important to set a LM_LICENSE_FILE environment variable? I guess the problem is here. | 18:23 |
jiayu | I registered on xilinx website | 18:23 |
stekern | from within the virtual box? | 18:23 |
jiayu | and input my hostid and MAC(I suppose) | 18:23 |
stekern | iirc it get bound to your mac address | 18:23 |
stekern | ok, and that was the mac from virtual box? | 18:24 |
jiayu | yes | 18:24 |
jiayu | then the license file is emailed and I copied it in the license manager | 18:25 |
jiayu | I succeed with the ise 13.2 for all platform installed in virtual box. but I failed in the process of generation orpsoc.bit. it seems the bitgen has not enough license. | 18:29 |
jiayu | this time is the ise 13.2 only for linux installed in virtual box. | 18:29 |
stekern | what does your license manager show now then? | 18:35 |
jiayu | a list of components | 18:36 |
jiayu | I found the problem. | 18:36 |
jiayu | maybe I use the previouse license of the last virtualbox. I deleted the last virtual box and set up a new one, then the MAC changes. | 18:37 |
jiayu | I suppose I should regenerate it. | 18:37 |
stekern | try that | 18:37 |
jiayu | it seems like no problem now. | 18:42 |
jiayu | thanks a lot!stekern! | 18:43 |
@juliusb | stekern: I think I nkow what that de0 nano port guy was doing | 19:23 |
@juliusb | he was talking to the accelerometer | 19:23 |
@juliusb | which is what I plan on donig | 19:23 |
--- Log closed Sun Apr 14 00:00:14 2013 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!