#milkymist IRC log for Wednesday, 2013-11-27

wpwrakit's pretty nice that you can outsource the production testing, even for prototypes. should make things a lot easier13:39
davidc__lekernel: hey, around? Just wanted to continue the discussion on platforms/ in mibuild15:50
davidc__lekernel: my thoughts are that migen right now is effectively defining a language and a stdlib15:50
davidc__lekernel: while migen right now is still in flux, (and probably will be for some time), at some point it'll stabilize15:51
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 kernel15:51
lekernelwe 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 boards15:53
lekernelthere won't be platform-specific code in the migen/ path, never15:53
davidc__lekernel: Ok; fair enough. Just wanted to provide my 2c.15:54
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)?15:55
lekernelhow do you define "cyclic dependency"?15:55
davidc__cyclic dependancies in combinatorial logic15:55
davidc__I mean self.comb += [a.eq(b), b.eq(a)]15:56
lekernelwell, that particular one can be safely disallowed15:56
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 point15:57
davidc__IE, self.comb += If(a, ...).Elif(b, x.eq(c + d)), x would depend on a,b,c and d15:58
davidc__(This is a property that'd be checked at compile-to-verilog time)15:59
lekernelok; but then I think "self.comb += If(a, x.eq(0)).Elif(b, x.eq(c + d)), If(a, c.eq(x))" should be allowed16:00
davidc__yeah; some for of constant prop or predicate analysis could break the cycle there; but those are much more heavyweight analyses16:03
lekernelare there useful cyclic dependencies e.g. in the misoc code base?16:03
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 migen16:04
ysionneauI'd like to propose adding ASID support for lm32 MMU18:27
ysionneauany serious kernel developer I talk to about running NetBSD on lm32-mmu tells me I really should add ASID support18:27
ysionneauat 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?"18:28
ysionneaubut then, maybe it's a better idea to add ASID right now, rather than having everything work and then wanting to add it later on18:28
ysionneauand having to rewrite all the low level tlb code18:29
ysionneau(low level kernel code, not verilog)18:29
ysionneauso 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 not18:29
ysionneaumaybe it's not that big a change...18:29
ysionneaufirst question: where to store "current ASID"? we have bits [31:12] of PSW (Processor Status Word) which are currently unused18:30
ysionneauso plenty of space for ASID, no?18:30
ysionneaulet say, 5 bits ASID? giving 31 concurrent user space memory mapping + kernel memory mapping (which is always active)18:31
ysionneauone complex TLB operation I can see would be "flush TLB entries for ASID N"18:33
ysionneaubecause then the flushing code would need to iterate on each TLB line and 1°) read the entry 2°) flush it if ASID == N18:33
ysionneauwhich is more complex than current "flush all" code which does no reading at all and iterates over the whole TLB and only writes.18:34
ysionneaumoreover, we have also 9 unused bits in TLBPADDR and TLBVADDR to put the ASID for the "update tlb entry" operation18:35
ysionneauto again, plenty of room18:35
ysionneauI may shoot an email about that soon ^^18:37
lekernelsoftware 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.18:43
ysionneauwell, I honestly think they are right (I don't have any number) about that18:50
ysionneauflushing the entire TLB upon context switch kills a lot of perf18:50
ysionneauand it will be even more visible on slow cpu18:50
ysionneauand if you start to run several processus, and they wanna talk to each other with pipes/UNIX sockets/shared memories18:50
ysionneauthen it's a disaster18:50
ysionneautornados of tlb miss18:50
ysionneauyou spend your life in tlb miss handler to update your tlb18:51
ysionneauor maybe I'm pesimistic about that?18:52
ysionneauI think the perf difference can be measured with a simple cat file | cut | sed | grep combination18:53
ysionneaubut since nothing works right now ...18:53
ysionneauhard to compare :)18:53
lekernelhmm, I can believe there is a significant gain when you have a few processes intensively exchanging relatively small buffers, yes18:54
ysionneauI 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 that18:54
lekernelwpwrak, what video card did you test the HDMI EDID with?18:55
lekernelthe 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.18:56
larscyou should go to a plugfest ;)19:06
wpwrakhmm, it may have been an ATI. lspci says: VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV610 [Radeon HD 2400 PRO]19:08
wpwraki 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)19:09
lekernelanyone near Amsterdam? https://twitter.com/HFDNL/status/40581568774853427221:51
ysionneausorry no22:29
lekernellarsc, any upcoming ones you know in Europe?22:37
--- Thu Nov 28 201300:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!