elldekaa has quit [Read error: Connection reset by peer]
cladamw has joined #milkymist
elldekaa has joined #milkymist
Jia has joined #milkymist
rejon has quit [Ping timeout: 260 seconds]
jimmythehorn has joined #milkymist
aeris has quit [Ping timeout: 252 seconds]
aeris has joined #milkymist
rejon has joined #milkymist
rejon has quit [Ping timeout: 260 seconds]
voidcoder has quit [Remote host closed the connection]
voidcoder has joined #milkymist
rejon has joined #milkymist
voidcoder has quit [Read error: Connection reset by peer]
rejon has quit [Ping timeout: 265 seconds]
rejon has joined #milkymist
rejon has quit [Ping timeout: 260 seconds]
cladamw has quit [Quit: Ex-Chat]
wolfspra1l has quit [Quit: leaving]
wolfspraul has joined #milkymist
rejon has joined #milkymist
rejon has quit [Ping timeout: 248 seconds]
rejon has joined #milkymist
cladamw has joined #milkymist
rejon has quit [Ping timeout: 245 seconds]
elldekaa has quit [Ping timeout: 246 seconds]
rejon has joined #milkymist
elldekaa has joined #milkymist
Martoni has joined #milkymist
mumptai has joined #milkymist
elldekaa has quit [Remote host closed the connection]
togi has quit [*.net *.split]
bkero has quit [*.net *.split]
togi has joined #milkymist
mumptai has quit [Ping timeout: 250 seconds]
bkero has joined #milkymist
voidcoder has joined #milkymist
rejon has quit [Ping timeout: 265 seconds]
cladamw has quit [Quit: Leaving]
rejon has joined #milkymist
Martoni has quit [Read error: Connection reset by peer]
elldekaa has joined #milkymist
Martoni has joined #milkymist
rejon has quit [Ping timeout: 248 seconds]
Martoni has quit [Read error: Connection reset by peer]
lekernel_ has joined #milkymist
lekernel has quit [Ping timeout: 260 seconds]
bkero has quit [*.net *.split]
bkero has joined #milkymist
cladamw has joined #milkymist
lekernel_ is now known as lekernel
azonenberg has quit [Ping timeout: 245 seconds]
rejon has joined #milkymist
rejon has quit [Ping timeout: 240 seconds]
rejon has joined #milkymist
Jia has quit [Quit: Konversation terminated!]
Martoni has joined #milkymist
cladamw has quit [Quit: Leaving]
rejon has quit [Ping timeout: 252 seconds]
lekernel has quit [Read error: Connection reset by peer]
cladamw has joined #milkymist
Gurty` has quit [Ping timeout: 265 seconds]
Zorro has joined #milkymist
Zorro is now known as Gurty
cladamw has quit [Quit: Ex-Chat]
elldekaa has quit [Ping timeout: 256 seconds]
elldekaa has joined #milkymist
lekernel has joined #milkymist
rejon has joined #milkymist
jimmythehorn has quit [Quit: jimmythehorn]
voidcoder has quit [Read error: Connection reset by peer]
voidcoder has joined #milkymist
azonenberg has joined #milkymist
Martoni has quit [Quit: ChatZilla 0.9.88.2 [Firefox 13.0.1/20120615040410]]
rejon has quit [Ping timeout: 272 seconds]
elldekaa has quit [Remote host closed the connection]
elldekaa has joined #milkymist
<Fallenou>
hi there
<Fallenou>
it has been some time I haven't seen any usb commit :) any upcoming surprise ? :)
<Fallenou>
is there some work in progress about usb soft stack ?
<Fallenou>
or is it stalled ?
elldekaa has quit [Ping timeout: 248 seconds]
elldekaa has joined #milkymist
mumptai has joined #milkymist
elldekaa has quit [Ping timeout: 240 seconds]
elldekaa has joined #milkymist
kristianpaul has quit [Ping timeout: 248 seconds]
<wpwrak>
Fallenou: there seems to be little point in adding features to softusb. once your mmu works, we can make linux run nicely and give it a proper USB host (which will have to be different from the current softusb)
<Fallenou>
yes indeed
<Fallenou>
I didn't want to stop softusb improvements though :'
* Fallenou
starts to feel the heavy responsabilities on his shoulders
<wpwrak>
why not ? everybody is very happy to have a good excuse for not sinking more time into it ;-))
<sh4rm4>
it would be nice tho if softusb worked well
<Fallenou>
let's hope I will achieve a stable state and a stable Linux then :)
<Fallenou>
anyway linux or not we need the navre/softusb low lever usb signaling to work well , right ?
<Fallenou>
is the low level stuff perfectly ok now ?
<Fallenou>
level*
<wpwrak>
Fallenou: i'd do it that way, yes. another approach may be to make a "hard" host controller, which would probably be faster. but also more work.
<wpwrak>
Fallenou: low-level seems to be much better now
<wpwrak>
the main source of trouble are now fancy report formats and hubs. both are the sort of problem we should let linux worry about :)
<wpwrak>
softusb will probably need a DMA interface for decent performance
<sh4rm4>
hmm lekernel's new OS plan doesnt seem to involve linux
<wpwrak>
i guess he'll come around the second linux is stable (and fast) ;-)
<Fallenou>
ahah I hope someone will ever use lm32-mmu and linux =)
<Fallenou>
wpwrak: I have a code configuration where the itlbtest (running the f function with itlb enable) works , even with relocation
<Fallenou>
I need to map (in itlb) the whole (used) nand
<Fallenou>
this works well if mmu_map (which registers in an array in the bios the mappings in order to put them back in *TLB upon any *TLB miss) pushes the mapping in the TLB right away
<Fallenou>
if I do "lazy" mapping
<Fallenou>
then it crashes (soc hang)
<Fallenou>
I suspect a NULL page being asked on wishbone bus by either inst_fetch or data_fetch
<Fallenou>
but I could not reproduce it (for now) in ISim to understand why a NULL page gets asked
<Fallenou>
I even implemented the same kind of "if NULL is asked I do a $display() and hang the SoC" in my simulation SoC
<Fallenou>
in order to detect such problems
<Fallenou>
running approx. the same itlbtest() in ISim does not trigger any NULL page
<Fallenou>
but maybe the devil is in the details :)
<Fallenou>
anyway it's quite nice how well it works in ISim, even with lazy mapping (which means tons of TLB misses and exception to handle the mappings), I guess with a few "FPGA only" bugs corrected it should work as well on the FPGA :)
<mwalle>
Fallenou: btw whats the reason not to use verilator/iverilog?
<Fallenou>
lekernel: is it on purpose that you don't activate cache associativity "2" ? synthesis fails ?
<Fallenou>
mwalle: iverilog faild to simulate lm32, I started with iverilog before trying ISim
<Fallenou>
mwalle: verilator ... I don't remember if I tried, is it free ? easy to grab ?
<Fallenou>
works on Linux ?
<mwalle>
Fallenou: acutally i meant cver
<mwalle>
gplcver
mumptai has quit [Read error: Operation timed out]
<Fallenou>
description seems nice :
<Fallenou>
:)
<Fallenou>
I didn't try, maybe I should
<Fallenou>
thanks for the link
<mwalle>
Fallenou: iirc lekernel simulated the lm32 with it
<Fallenou>
great :)
<mwalle>
mh maybe not
<mwalle>
i'm confused, sorry ;)
<Fallenou>
I must say, proprietary or not, ISim has done quite a nice job for me for now
<wpwrak>
Fallenou: does your definition of NULL match the SoC's ? iirc, the condition is anything < 128*1024.
<Fallenou>
wpwrak: to answer fully your question, in lm32 an interrupt is triggering an exception, interrupt stuff is using a given exception ID
<Fallenou>
or exception vector
<Fallenou>
so yes in fine ITLB/DTLB are triggering an exception, just like an interrupt would
<wpwrak>
i wonder if the pipeline is properly synchronized. how many stages does lm32 have ? something like fetch, reg read, execute, reg write ?
<Fallenou>
6 stages
<Fallenou>
address, fetch, decode, execute, memory, write back
<Fallenou>
the execute stage triggers exception (via exception_x)
<Fallenou>
but the cpu really branches only if exception_x gets propagated to exception_m (the next stage)
<Fallenou>
and it only does if the correct combinaison of stage stalling is OK (and branch conditions etc etc etc)
<Fallenou>
it only does so*
<wpwrak>
so that would be for breakpoint, divide by zero, etc.
<wpwrak>
in the case of the ITLB, the exception would be raised in the address or fetch stage
<wpwrak>
so the "we're in an exception" information would have to be passed along (delayed) by some more stages
<Fallenou>
hum well why delaying it ?
<Fallenou>
we are fetching from an unmapped address
<Fallenou>
we need to do something immediately, no ?
<Fallenou>
but yes that could be wrong in case of a branch (and wrong branch prediction)
<Fallenou>
that would just mean we would trigger a "tlb miss" for nothing but it should not kill anything
<Fallenou>
both "results" of a test-and-branch should be mapped I guess
<wpwrak>
what about the preceding instructions that are still in the pipeline ?
<Fallenou>
after exception handled I jumb back to where PC_x was
<Fallenou>
so I get the same pipeline "configuration"
<Fallenou>
and then execution resumes
<wpwrak>
hmm. assume we have instructions FOO, BAR, BLAH, and TROUBLE. in this order. if you raise the exception in fetch, then TROUBLE would be in fetch, BLAH would be in decode, BAR in execute, FOO in memory. each of which would still have work to do. are you sure they leave the pipeline cleanly ?
<Fallenou>
FOO is just "fetch" which does not change internal cpu state
<Fallenou>
BAR is decode, it's the same (reg read)
<Fallenou>
BLAH is executed anyway
<Fallenou>
when I return from exception it goes like this BLAH is fetched, then BAR BLAH, then FOO BAR BLAH and here we are again
<Fallenou>
same configuration
<Fallenou>
maybe I'm not seing something
<Fallenou>
in theory an interrupt could happen anytime, it would raise an exception too
<Fallenou>
and it would not mess the pipeline :o
<Fallenou>
is this proving something ?
<wpwrak>
the order is reversed. you have FOO, BAR, BLAH, then TROUBLE. by the time TROUBLE hits fetch, FOO is already almost done, BAR a little less, etc.
<Fallenou>
oh OK you were stating the other way
<Fallenou>
sorry I missread you :)
<wpwrak>
i wonder about interrupts :) in theory, you could treat them like an exception of the instruction that's executing (which is where i suppose breakpoint, divide by zero, and such happen)
<Fallenou>
yes that's it
<Fallenou>
exception of the instruction in X stage
<Fallenou>
so when it returns it jumps back to PC_X + 1 or something like that
<Fallenou>
or PC_X
<Fallenou>
it jumps back to PC_X sorry
<Fallenou>
it does EA = PC_X and then PC_F = exception_vector (and kills other instructions from the pipeline)
<Fallenou>
and then when returning from exception, it does PC_F = EA (and kills other instructions from the pipeline)
<wpwrak>
so ... what happens with the half-finished instructions ?
<wpwrak>
you just repeat them ? if yes, could they have had a side-effect in their first life ?
<Fallenou>
instructions in stage "MEM" and "WB" do whatever they want in their stage (like the one in X stage)
<Fallenou>
but the pipeline does not go forward anymore
<wpwrak>
e.g., change status register bits, initiate a memory write
<Fallenou>
see page 29 of the datasheet
<Fallenou>
Exceptions occur in the execute pipeline stage. If there is an instruction in the memory pipeline stage, that instruction is first allowed to finish. All instructions from the Execute stage back are then killed and do not cause any user- transparent state changes. For example, no flags are set.
<wpwrak>
okay. and what if the exception is in fetch ?
<Fallenou>
well the exception is due to something happening in "fetch", but the exception occures as if it was caused by "execute"
<Fallenou>
it should do the same thing
<wpwrak>
maybe adding some NOPs could change how successful your code is :)
<wpwrak>
(exception in fetch) so you carry the "this instruction is exceptional" information along ?
<Fallenou>
no no
<Fallenou>
sorry I am explaining this badly
<Fallenou>
let say from left to right : address | fetch | decode | exec | mem | write back
<Fallenou>
let say instructions are A B C D E F
<Fallenou>
if A triggers an ITLB exception (in fetch stage)
<Fallenou>
I instantly raise "exception_x"
<Fallenou>
so it's as if instruction D has caused an exception in stage execute
<Fallenou>
and it's as if an interrupt happened from some GPIO
<wpwrak>
you mean if your code is F; E; D; C; B; A; ? :)
<Fallenou>
yes
<wpwrak>
if A is in fetch (raising an exception), then B is in decode, C in exec, right ?
<Fallenou>
do you think there might be a problem with this way of raising "instantly" exception_x, even if the real cause of the exception is in fetch ?
<Fallenou>
ah yes sorry
<Fallenou>
I was counting "address"
<Fallenou>
yes it's not D but C
<Fallenou>
which is in exec
<wpwrak>
i wonder what happens to the instructions in decode and execute
* Fallenou
is tired a bit
<wpwrak>
i.e., B and C
<Fallenou>
well C finishes it's execution, but does not change any flag
<Fallenou>
and B never reaches the execution stage
<wpwrak>
ah, but you reset the PC to where C has been
<Fallenou>
yes
<wpwrak>
so this PC can be quite different from the ITLB fault address
<Fallenou>
upon returning I do "bi address_of_C"
<Fallenou>
which is "bi EA" (or eret)
<Fallenou>
yes
<wpwrak>
okay. that sounds correct then.
<Fallenou>
it can be different, it depends on if there is a branch somewhere
<Fallenou>
knowing that AFAIK lm32 is doing "I take branch anyway as a prediction"
<Fallenou>
branches are "taken"
<wpwrak>
the should always be at least a little different. since it's the address of A, not of C
<Fallenou>
yes sure
<larsc>
i think backward branches are predicted as taken, forward branches as not taken
<Fallenou>
ah yes maybe
<Fallenou>
I forgot exactly what was the algorithm :)
<Fallenou>
wpwrak: itlb stuff seems pretty OK in ISim, so unless I am kind of lucky with my pipelines (which could be right) the present implementation sounds ok
<wpwrak>
could this happen ? A gets an ITLB fault. you handle it. then the exception handling "rewinds" to C. then you get an ITLB fault for C.
<Fallenou>
it could if A and C are aliases for the TLB
<Fallenou>
and the A handling expulses the C mapping from TLB
<Fallenou>
oh god
<wpwrak>
yup :) (or if B had an issue too and evicted C)
<Fallenou>
I guess you discovered a "itlb storm" issue ?
<wpwrak>
(not sure if you can have this sort of triple ITLB misses, though. depends on how branches are done.)
<wpwrak>
;-)))
<Fallenou>
I will think about that situation :)
<Fallenou>
it's becoming late here
<Fallenou>
and tomorrow I have to be at the office early because I meet with the boss :p
<wpwrak>
let's hope it's for a promotion :)
<Fallenou>
hehe nop
<wpwrak>
at least a pay rise ?
<Fallenou>
for an official talk and presentation of the numerous department
<Fallenou>
since I'm "new"
<Fallenou>
(6-8 months in the company)
<wpwrak>
some kind of "new" ;-)
<Fallenou>
it takes the whole day
<Fallenou>
productivity drop
<wpwrak>
wow. a big company then.
<Fallenou>
yes pretty big :)
<Fallenou>
for a french tech company
<Fallenou>
~500 engineers
<wpwrak>
not too bad. they must have many toys then :)
<Fallenou>
sure :)
elldekaa has quit [Read error: Connection reset by peer]
elldekaa has joined #milkymist
<Fallenou>
gn8!
elldekaa has quit [Read error: Connection reset by peer]