lekernel changed the topic of #milkymist to: Mixxeo, Migen, MiSoC & other Milkymist projects :: Logs: http://en.qi-hardware.com/mmlogs
mumptai has quit [Ping timeout: 272 seconds]
rjo_ is now known as rjo
kristianpaul has joined #milkymist
kristianpaul has joined #milkymist
xiangfu has joined #milkymist
lekernel has joined #milkymist
aeris has quit [Quit: en a pas]
aeris has joined #milkymist
mumptai has joined #milkymist
xiangfu has quit [Remote host closed the connection]
proppy has quit [Remote host closed the connection]
robmyers has quit [Remote host closed the connection]
proppy has joined #milkymist
wpwrak has joined #milkymist
<wpwrak>
it's pretty nice that you can outsource the production testing, even for prototypes. should make things a lot easier
robmyers has joined #milkymist
proppy has quit [Quit: Connection closed for inactivity]
<davidc__>
lekernel: hey, around? Just wanted to continue the discussion on platforms/ in mibuild
<davidc__>
lekernel: my thoughts are that migen right now is effectively defining a language and a stdlib
<davidc__>
lekernel: while migen right now is still in flux, (and probably will be for some time), at some point it'll stabilize
<davidc__>
lekernel: and then what's the plan for supporting the big platforms/ tree - I just worry it'll end up like mach-arm in the linux kernel
<lekernel>
we can break it off if it becomes too big... but right now I think it's more convenient to have only one repos to clone and get started with the supported boards
<lekernel>
there won't be platform-specific code in the migen/ path, never
<davidc__>
lekernel: Ok; fair enough. Just wanted to provide my 2c.
<davidc__>
BTW - I started working on the sim-hang issues again: Is it acceptable to disallow cyclic dependancies in migen (even if they would settle in HW/sim)?
<lekernel>
how do you define "cyclic dependency"?
<davidc__>
cyclic dependancies in combinatorial logic
<davidc__>
I mean self.comb += [a.eq(b), b.eq(a)]
<lekernel>
well, that particular one can be safely disallowed
<davidc__>
yeah, thats the simplified case. I guess the exact definition of 'dependancy' would be: everything on RHS of stmt + everything on control-flow path to this point
<davidc__>
IE, self.comb += If(a, ...).Elif(b, x.eq(c + d)), x would depend on a,b,c and d
<davidc__>
(This is a property that'd be checked at compile-to-verilog time)
mumptai has quit [Read error: Operation timed out]
<lekernel>
ok; but then I think "self.comb += If(a, x.eq(0)).Elif(b, x.eq(c + d)), If(a, c.eq(x))" should be allowed
<lekernel>
(maybe)
<davidc__>
yeah; some for of constant prop or predicate analysis could break the cycle there; but those are much more heavyweight analyses
<lekernel>
are there useful cyclic dependencies e.g. in the misoc code base?
<davidc__>
lekernel: I don't think so (from a preliminary test). But I've mostly been playing with ideas in a toy environment before making major changes to migen
sh4rm4 has quit [Ping timeout: 240 seconds]
antgreen has quit [Ping timeout: 272 seconds]
sh4rm4 has joined #milkymist
mumptai has joined #milkymist
sh4rm4 has quit [Ping timeout: 240 seconds]
<ysionneau>
I'd like to propose adding ASID support for lm32 MMU
sh4rm4 has joined #milkymist
<ysionneau>
any serious kernel developer I talk to about running NetBSD on lm32-mmu tells me I really should add ASID support
<ysionneau>
at first I was saying "I don't want to add code, bugs, take more LUTs, increase critical paths, for what? some perf? on already slow cpu?"
<ysionneau>
but then, maybe it's a better idea to add ASID right now, rather than having everything work and then wanting to add it later on
<ysionneau>
and having to rewrite all the low level tlb code
<ysionneau>
(low level kernel code, not verilog)
<ysionneau>
so I'm trying to see what would have to be changed in order for lm32 mmu to support ASID, to see if it's worth it or not
<ysionneau>
maybe it's not that big a change...
<ysionneau>
first question: where to store "current ASID"? we have bits [31:12] of PSW (Processor Status Word) which are currently unused
<ysionneau>
so plenty of space for ASID, no?
<ysionneau>
let say, 5 bits ASID? giving 31 concurrent user space memory mapping + kernel memory mapping (which is always active)
<ysionneau>
one complex TLB operation I can see would be "flush TLB entries for ASID N"
<ysionneau>
because then the flushing code would need to iterate on each TLB line and 1°) read the entry 2°) flush it if ASID == N
<ysionneau>
which is more complex than current "flush all" code which does no reading at all and iterates over the whole TLB and only writes.
Alarm has joined #milkymist
<ysionneau>
moreover, we have also 9 unused bits in TLBPADDR and TLBVADDR to put the ASID for the "update tlb entry" operation
<ysionneau>
to again, plenty of room
<ysionneau>
-to+so
<ysionneau>
I may shoot an email about that soon ^^
<lekernel>
software folks sometimes have weird ideas about what features hardware should have. I'd like to see some hard numbers on performance improvements brought by ASID mechanisms before deciding.
<ysionneau>
well, I honestly think they are right (I don't have any number) about that
<ysionneau>
flushing the entire TLB upon context switch kills a lot of perf
<ysionneau>
and it will be even more visible on slow cpu
<ysionneau>
and if you start to run several processus, and they wanna talk to each other with pipes/UNIX sockets/shared memories
<ysionneau>
then it's a disaster
<ysionneau>
tornados of tlb miss
<ysionneau>
you spend your life in tlb miss handler to update your tlb
<ysionneau>
or maybe I'm pesimistic about that?
<ysionneau>
I think the perf difference can be measured with a simple cat file | cut | sed | grep combination
<ysionneau>
but since nothing works right now ...
<ysionneau>
hard to compare :)
<lekernel>
hmm, I can believe there is a significant gain when you have a few processes intensively exchanging relatively small buffers, yes
<ysionneau>
I was only reluctant because I didn't want to spend any more time in the verilog part and I wanted to make it work for real on modern OS, since it had enough feature to work like that
<lekernel>
wpwrak, what video card did you test the HDMI EDID with?
<lekernel>
the three computers I've tested it with (2 linux + 1 mac os) all have NVIDIA GPUs. according to Murphy law's it'll fail like shit with GPUs from other manufacturers.
<larsc>
you should go to a plugfest ;)
<wpwrak>
hmm, it may have been an ATI. lspci says: VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV610 [Radeon HD 2400 PRO]
<wpwrak>
i also have an nVidia, but i think it was the ATI i used for testing. the NV would be: NVIDIA Corporation G72 [GeForce 7200 GS / 7300 SE] (rev a1)
mumptai has quit [Quit: Verlassend]
antgreen has joined #milkymist
Alarm has quit [Remote host closed the connection]