#milkymist IRC log for Saturday, 2012-07-21

--- Sat Jul 21 201200:00
Fallenouhum I wonder what happens when an exception happens (exception_x == TRUE) but stall_m or stall_x are TRUE, or q_x == FALSE14:45
FallenouDo we lose the exception ?14:45
Fallenousee lm32_cpu.v there : https://github.com/milkymist/milkymist/blob/master/cores/lm32/rtl/lm32_cpu.v#L257914:46
FallenouWe sould not lose the exception, in any case, 'cause exception origin could be an interrupt for example14:47
Fallenouand interrupt can happen any time, without any concern on pipeline state (stalls, kills, etc)14:47
FallenouI don't understand why exception_x does not et propagated all the time to exception_m14:47
Fallenoudoes not get*14:47
Fallenouor maybe the exception_x signal *MUST* be kept high untill it gets propagated to exception_m ?14:49
Fallenouthat's what I am doing for now14:49
FallenouI keep i/d tlb miss flag asserted untill I see exception_m asserted14:49
Fallenoubut I find this strange14:50
wpwraklosing an exception would be bad indeed. are interrupts edge-triggered ? because if they're level-triggered, then an interrupt that's not handled will simply come back in the next cycle14:50
Fallenouin lm32_top.v interrupt pins are passed to lm32_cpu (pipeline) as a wire14:51
Fallenouand then in lm32_interrupt.v there is a assign asserted = interrupt_pins & ie14:52
Fallenouand then the exception_x gets assigned to (asserted & im) something like that14:53
Fallenouit's all wire stuff, without any reg, so if the interrupt pin is de asserted before exception is triggered, there is no exception14:54
Fallenouwpwrak: interrupts are level triggered14:54
Fallenoubut the level has to be kept for a few clock cycles sometimes14:55
Fallenouyou have to wait exception_m becomes `TRUE, to be *sure* that the exception will happen later on14:55
Fallenouso you need to keep exception_x asserted, untill all condition for propagation from exception_x to exception_m are met14:56
Fallenoulike stall_m = false, stall_x=false, q_x = true14:56
wpwrakthe general rule for level-triggered interrupts is that they have to be asserted until there is a reaction15:17
wpwrakso that logic seems fine15:17
lekernelinterrupt inputs are edge triggered on the original LM3216:06
lekernela pulse sets the corresponding bit in IP at any time (regardless of the pipeline state)16:06
lekerneland that bit stays set until IP is written (w1c)16:06
lekernelthe pipeline sees only a "level" type of signal that is asserted whenever at least one bit is asserted in IP16:07
lekernel(in the LM32 used in -ng, I have removed this mechanism and made IP read-only, with its bit directly set by the now level-sensitive interrupt inputs. that should indeed be kept asserted by individual cores until there is a reaction from the CPU.)16:08
Fallenouin milkymist master branch it's level sensitif, right ?16:11
Fallenouyou modified the original lm3216:11
lekernelif you're using lm32 from milkymist-ng, it's level sensitive, yes16:13
lekernelinternally they're always level-sensitive anyway16:13
Fallenouoh ok now i can see, asserted gets stored into ip16:17
Fallenouok got it thx16:17
Fallenouitlb is really starting to work nicely on fpga22:31
Fallenouit's really less buggy than it was a week ago now22:32
Fallenoustill something weird in ITLB miss handler22:34
Fallenoulet me pastebin it :)22:35
wpwrakwhat was the big problem ?22:40
Fallenouwpwrak: I was mostly putting delays in value propagations from reg to reg in clock cycles22:43
Fallenouinstead of doing it in "pipeline cycles"22:43
Fallenouso in simulation it was "correct" because the two were correctly synchronized because I was able to see wire values etc22:43
Fallenoubut on fpga there is a lot of difference, because there is a real DDR SDRAM controler on the wishbone bus etc22:43
Fallenouso I was doing it totally wrong :)22:44
Fallenounow I look for stalls in the pipeline for instance22:44
Fallenouand strangely, it works really better now !22:44
FallenouI can : enable itlb and jump to a function with it's virtual address22:45
FallenouI can run (with itlb enabled) a function calling puts() and printf(), with ITLB totally flushed22:45
Fallenouwhich means it's going to generate a whole bunch of tlb miss (exceptions) , ITLB update and go back to code etc22:46
Fallenouand it works22:46
Fallenou"it works", but there is the bug I just posted in pastebin22:46
wpwrakhmm. what does "delay" mean in this case ? i suppose isn't not something like "wait 100 ns here", is it ?22:46
Fallenouno it's like cascading flip flops22:47
FallenouI want to use the value of regX, but two clock cycles later, I do always @(posedge clk) regX1 <= regX and always @(posedge clk) regX2 <= regX1; and I use regX222:48
wpwrakso you propagate between clock cycles ? i.e., from one "run" of an always block to its next "run" ?22:48
Fallenouyes, I was doing things like that22:49
Fallenouit kind of worked, but it was really stupid22:49
wpwrakah, perfect :) and i suppose these delays are constant, i.e., don't depend on, say, bus activity ?22:49
Fallenoumost of the time one clock cycle ~ 1 pipeline cycle but there are cases where you have stalls (upon branches, dcache refill, icache refill) and there you are screwed22:50
Fallenouyou cannot assume that pipeline will go forward at each clock cycle22:50
Fallenouand I was assuming that22:50
wpwrakah, i see. so now you basically have a parallel pipeline22:51
Fallenoubut now I am turning crazy, because if I remove a rcsr it goes in an infinite exception loop :)22:51
wpwrakand i can see how getting the delays wrong could cause very interesting bugs ;-))22:51
Fallenouwpwrak: well not sure if I understand what you means, but now we can say that I am doing it correctly :)22:51
Fallenouyes ^^22:51
Fallenouwpwrak: my problem now is that somehow EA (exception address, where you branch upon eret) gets the value of itlb_miss_handler22:52
FallenouI don't get how, but it happens22:52
Fallenouso when you eret, you branch to itlb_miss_handler, and then you eret etc etc22:53
Fallenouand I just added a rcsr to read the value of PSW22:53
Fallenouand it "fixed" the whole thing22:53
Fallenouand btw PSW is correct, it's value is 0x1022:53
wpwrakmaybe you're coying the PC a little too late ?22:53
Fallenouwhich means EITLBE = 1 and ITLBE = 022:53
FallenouEITLBE = Exception ITLB enable | ITLBE = ITLB enabled22:54
Fallenouupon exception ITLBE is copied to EITLBE and ITLBE is cleared22:54
Fallenouso it seems correct22:54
Fallenoutoo late or too early22:55
Fallenoutoo early maybe22:55
wpwraksounds as if you're copying PC -> EA too late. i.e., after the exception has already been started.22:56
Fallenoulook at the logs, EA is correct two times22:56
Fallenoufor the first two ITLB misses22:56
Fallenouand then it gets ***120 (which is itlb_miss_handler address)22:57
Fallenouwell you may be right, "too late"22:57
wpwrakmaybe it's concurrent ?22:58
Fallenouwpwrak: do you see why just commenting/uncommenting the rcsr somehow fixes or not the whole thing ? :o22:58
FallenouI just don't get this22:58
Fallenouthe instruction is in the middle of the tlb handler22:58
wpwrakmaybe that's just coincidence. or maybe it affects cache timing or such.23:00
FallenouI think I'm going to commit/push ITLB to github23:01
Fallenounow it's really less buggy23:01
wpwrakif you have conflicting operations in the simulator, e.g., you assign to the same variable from two different places that could execute in parallel. what will the simulator do ? warn you ? pick always a given order ? pick an arbitrary but unspecified order ? or pick a randomize order ?23:02
Fallenouyou cannot assign the value variable from two places running in //23:03
Fallenouit fails to "compile" in ISim and in Xst as well23:03
wpwrakah, i see23:03
wpwrakpity. that takes the fun out of a lot of very interesting mistakes :)23:04
Fallenouif you have a reg that you assign with "<=", you can assign it ONLY from one always block23:04
Fallenouyou can assign it in several if / else / switch case statements if you want23:04
wpwrakhow about "=" ?23:05
Fallenoubut you cannot have two different always blocks, assigning the same reg or wire23:05
Fallenouit's the same23:05
Fallenouto say it more efficiently : a signal can only be driven by one block23:05
Fallenou01:11 < wpwrak> pity. that takes the fun out of a lot of very interesting mistakes :) < there is already a lot of room for mistakes, trust me :p23:06
Fallenouand I am doing a lot of them :D23:07
Fallenoulet's track how the pipeline writes to EA upon exception :'23:10
--- Sun Jul 22 201200:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!