xiangfu has joined #milkymist
sh4rm4 has quit [*.net *.split]
ximian has quit [*.net *.split]
roh has quit [*.net *.split]
sh4rm4 has joined #milkymist
roh has joined #milkymist
ximian has joined #milkymist
elldekaa has quit [Remote host closed the connection]
xiangfu has quit [Ping timeout: 245 seconds]
jimmythehorn has quit [Quit: jimmythehorn]
xiangfu has joined #milkymist
xiangfu has quit [Client Quit]
Martoni has joined #milkymist
xiangfu has joined #milkymist
bkero has quit [Read error: Connection reset by peer]
bkero has joined #milkymist
bkero has quit [Changing host]
bkero has joined #milkymist
elldekaa has joined #milkymist
robmyers has joined #milkymist
robmyers has quit [Quit: Lost terminal]
lekernel has joined #milkymist
<
lekernel>
azonenberg: SFP+ modules are also pricy
xiangfu has quit [Ping timeout: 246 seconds]
cladamw has joined #milkymist
aeris has quit [Ping timeout: 245 seconds]
aeris has joined #milkymist
Gurty has quit [Ping timeout: 246 seconds]
hypermodern has joined #milkymist
jimmythehorn has joined #milkymist
Gurty has joined #milkymist
<
azonenberg>
lekernel: yes, they are
cladamw has quit [Quit: Ex-Chat]
jimmythehorn has quit [Quit: jimmythehorn]
jimmythehorn has joined #milkymist
elldekaa has quit [Remote host closed the connection]
<
GitHub192>
[milkymist-mmu/mmu] Add support for page permission bits in BIOS - Yann Sionneau
elldekaa has joined #milkymist
hypermodern has quit [Quit: hypermodern]
<
mwalle>
Fallenou: i think you should delay the itlb miss until the x stage
<
mwalle>
and stall the pipeline(?)
lekernel_ has joined #milkymist
lekernel has quit [Ping timeout: 246 seconds]
lekernel_ is now known as lekernel
elldekaa has quit [Ping timeout: 260 seconds]
elldekaa has joined #milkymist
mumptai has joined #milkymist
<
Fallenou>
hi mwalle
<
Fallenou>
why delaying the itlb exception ?
<
Fallenou>
I'm not sure I can stall the pipeline and let the instruction go to X stage
<
Fallenou>
because I think that if I stall the pipeline, nothing will move anymore
<
Fallenou>
so the instruction causing the itlb miss will stay in fetch stage, and never go to decode and execute stage
<
Fallenou>
it seems that lm32 stalls the pipeline only when a stage needs more than 1 clock cycle to finish its job
<
Fallenou>
for instance a cache miss stalls the pipeline during the refill through wishbone bus
<
Fallenou>
but I can let the pipeline continue going forward but with a "kill flag" on adress/fetch/decode stage instructions
<
Fallenou>
it's a way of saying "ok the instruction is passing by but it should not do anything"
<
Fallenou>
it's used for instance when branch prediction failed
<
Fallenou>
so that the fetched instruction is not executed
<
mwalle>
its delayed until the x stage
<
mwalle>
i guess all exceptions are handled in the x statge
<
mwalle>
and if you delay it, you wont have any problems with itlb miss in x stage and dtlb miss in m (?) stage at the same time
<
Fallenou>
exception "occure" in x stage yes, that's what they say in the datasheet
<
Fallenou>
and that's what is saved in EA
<
Fallenou>
I should have a look on scall indeed
<
wpwrak>
careful with additional state that's being passed along the pipeline. the more state you have, the more interesting the bugs ... :)
<
mwalle>
f stage is where the itlb miss exception currently occurs, right?
<
Fallenou>
and dtlb in m stage
<
mwalle>
so only the a stage is stalled
<
Fallenou>
oh yes true
<
Fallenou>
but then there is a "bubble" in the pipeline ?
<
Fallenou>
I wonder what happens then
<
Fallenou>
I am not sure if at the moment lm32 handles this
<
Fallenou>
if it can happen with original lm32 design
<
mwalle>
the current instruction moves to decode stage
<
mwalle>
then to x stage
<
mwalle>
the exception also moves to d then x
<
mwalle>
and is handled
<
mwalle>
and i guess the instruction in x is killed
<
mwalle>
or anything before x
<
Fallenou>
anything before x
<
mwalle>
havent looked at the exception handling, once there is one ;)
<
mwalle>
btw what happens atm with the instruction right before that one which causes an itlb miss=
<
Fallenou>
it gets executed (and m/w)
<
mwalle>
is there additional logic?
<
Fallenou>
yes a little bit
<
Fallenou>
I have some kind of delay in fact
<
Fallenou>
when I raise the exception it is not taken into account right away anyway
<
Fallenou>
so the instruction in decode reaches the X stage anyway
<
mwalle>
if you delay the exception i guess it will be consistent with the current exception handling and you wont need that delay
<
Fallenou>
but I need to study that a little bit more
<
Fallenou>
I'm going to sleep, I will study a bit simulations to have consistant datas
<
Fallenou>
I'm talking by memory here
<
mwalle>
i'll watch some lectures ;)
<
Fallenou>
hard to have all precise informations about pipeline states in the head :)
<
Fallenou>
see you ! gn8!
<
Fallenou>
thanks for your feedback!
<
mwalle>
i think its relly good explained in the lessons ;)
<
Fallenou>
don't hesitate to answer the email as well :p
<
mwalle>
tomorrow, too tired atm ;)
mumptai has quit [Ping timeout: 252 seconds]
Gurty has quit [Ping timeout: 244 seconds]