lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs :: EHSM Berlin Dec 28-30 http://ehsm.eu :: latest video http://www.youtube.com/playlist?list=PL181AAD8063FCC9DC
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] fallen pushed 1 new commit to mmu: http://git.io/rfToPg
<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> see scall
<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> yes
<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
<mwalle> right
<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
<mwalle> ok
<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> ok gn8
<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
<Fallenou> *zZzZ*
<mwalle> tomorrow, too tired atm ;)
mumptai has quit [Ping timeout: 252 seconds]
Gurty has quit [Ping timeout: 244 seconds]