lekernel changed the topic of #m-labs to: Mixxeo, Migen, MiSoC & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
sb0_ has quit [Quit: Leaving]
balrog has quit [Ping timeout: 272 seconds]
balrog has joined #m-labs
JewFro297 has joined #m-labs
<JewFro297> Sup?
<JewFro297> I'm working on designing an 80186 compatible computer on the DE0
JewFro297 has quit [Ping timeout: 240 seconds]
sh4rm4 has quit [Ping timeout: 264 seconds]
sh4rm4 has joined #m-labs
sb0 has joined #m-labs
jix has joined #m-labs
JewFro297 has joined #m-labs
<ysionneau> JewFro297: Hi!
<JewFro297> Sup?
<ysionneau> What will be the purpose of your project?
<JewFro297> It's just for fun, a learning experience type thing
<ysionneau> I mean, you need this old 80186 for something?
<ysionneau> ah ok, good :)
<JewFro297> Nah I have a 486 machine in my basement that still runs
<ysionneau> I throw mine out a few years ago
<ysionneau> I just kept the CPU
<JewFro297> Shoulda sold it, they're worth a good amount to collectors
<ysionneau> really?
<ysionneau> it was taking a lot of space for nothing
<JewFro297> Well, back when I was looking up how much it would cost for a new motherboard I was seeing $1000
<ysionneau> I had 3 old computers taking hell of a place
<ysionneau> I dumped everything except CPUs
<JewFro297> I don't think they sell for that much though
<ysionneau> because it's rare I think
<JewFro297> Looks like they aren't, oh well
<ysionneau> good luck then with your project
<ysionneau> Are you gonna do it in Verilog? VHDL? Migen (python)
<ysionneau> ?
<JewFro297> Verilog
<JewFro297> I've never heard about Migen
<JewFro297> (Off to google...)
<ysionneau> it's a python framework for designing digital logic
<ysionneau> it's been used to design a System-on-Chip for instance
<ysionneau> it has nice helpers for generating bus signals, arbiters, connecting cores together
<JewFro297> Looks interesting, it seems sort of like a high level hardware language
<ysionneau> if you have questions about it sb0 here (sometimes his nickname is "lekernel") developped Migen
<ysionneau> yes, high level, tries to do the boring stuff for you
<JewFro297> Cool, I'll probably check it out sometime
<ysionneau> documentation is out there: http://milkymist.org/3/migen.html
<ysionneau> it supports dataflow paradigm
<ysionneau> I let you check the doc out :)
<JewFro297> Pretty cool, do you know if it
<JewFro297> 's used in the industry at all?
<ysionneau> it's used by some research lab AFAIK
<JewFro297> Is the speaker sb0?
<ysionneau> yes
sh4rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #m-labs
<ysionneau> mwalle: after investigation, the psw gets reset from 0xC3 to 0x03 during the call to splash_display()
<ysionneau> so most certainly a dtlb miss :o
<ysionneau> what's weird is that dtlb miss occure before that, because the 0x43 turns into 0xC3
<ysionneau> (edtlbe is set)
<ysionneau> more precisely it's due to the loop which copies the splash_screen from the flash memory to the main memory (framebuffer)
<ysionneau> or maybe it means somehow I get a double dtlb miss ... which would overwrite edtlbe with dtlbe (which is 0 inside the exception handler)
<ysionneau> but it should be impossible to get this double dtlb miss
<ysionneau> maybe there is an issue if I have 2 load-stores in a row
<ysionneau> and the first causes a dtlb exception
<ysionneau> maybe the second one causes an exception too ...
<ysionneau> turns out it's not the issue: in simulation, 2 loads in a row only triggers the exception handler once and edtlbe is not overwritten
sb0_ has joined #m-labs
sb0 has quit [Ping timeout: 252 seconds]
<ysionneau> this is driving me insane.
<ysionneau> who the hell is resetting PSW.
<sb0_> JewFro297, have you seen zet86?
<ysionneau> pretty cool project :)
<ysionneau> seems to work well, according to the game screenshots
<JewFro297> Yup, I actually just made an opencores account so I can look at source for reference if I need to
<sb0_> JewFro297, and yes, use migen, just don't replicate something that already exists
<ysionneau> would be cool to show a softcore written in migen
<JewFro297> Of course, copying isn't my thing.
<ysionneau> sb0_: funny, the zet project seems to reuse some Milkymist cores (fml and csr)
<sb0_> yeah, there aren't that many options when you want an open source SDRAM controller that actually works
mrueg has quit [Remote host closed the connection]
<sb0_> well, there's grlib too, but it's very complex
mrueg has joined #m-labs
mrueg has quit [Changing host]
mrueg has joined #m-labs
<ysionneau> vga_backbuffer[5393] = splash_src[5393]; <= this disables PSW.DTLBE and PSW.EDTLBE
<ysionneau> I tried booting several times, it's always at index 5393 in the loop
<sb0_> are you sure it's not an interrupt, like uart?
<ysionneau> there are a few uart lines before that, which do not disable PSW.dtlb
<ysionneau> and it happens during a loop with not uart output
<sb0_> ok, but did the UART ISR run before that?
<ysionneau> in the middle of the loop
<ysionneau> yes, it ran a few times before that
<ysionneau> TX is using isr, right?
<ysionneau> I sent a lot of keystrokes very early during the BIOS bootup and it's still erasing PSW at index 5393 of the splashscreen loading loop
<ysionneau> here is my instrumentation : http://pastebin.com/baeGd6q6
<ysionneau> well, sometimes it's i=5392 ...
<ysionneau> so it's not always the exact same index :o
<ysionneau> I don't think the timer is used in the BIOS
mumptai has joined #m-labs
<ysionneau> sb0_: there is a TMU ISR right before the bug!
<ysionneau> ah. got it
<ysionneau> the tmu_isr does some load/stores
<ysionneau> hummm but tlb should be of
<ysionneau> off*
* ysionneau does not get it
<ysionneau> sb0_: it's definetely due to TMU, I just commented the "CSR_TMU_CTL = td->flags|TMU_CTL_START;" line and PSW always keeps the good expected value :)
<ysionneau> I still don't get why the TMU isr would fuck up the PSW
<ysionneau> even if, by chance, the TMU isr fires when LM32 is servicing a dtlb miss, interrupts should be off and the TMU isr should only be serviced after return from exception
<ysionneau> maybe there is a race condition between Interrupts and TLB exceptions
<ysionneau> hard to simulate/debug :(
<ysionneau> if such a race condition exists, then it's understandable that it happens during this big load-store loop
<ysionneau> since we have an ISR firing regularly (TMU isr) and a big copy loop
<ysionneau> after some loop iteration there is a high chance that the ISR will end up firing at the right moment for the race condition to happen
balrog has quit [Read error: Operation timed out]
balrog has joined #m-labs
Alarm has joined #m-labs
Alarm has quit [Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131205075310]]
sb0_ has quit [Quit: Leaving]
JewFro297 has quit [Ping timeout: 272 seconds]