| wpwrak | it's pretty nice that you can outsource the production testing, even for prototypes. should make things a lot easier | 13:39 |
|---|---|---|
| davidc__ | lekernel: hey, around? Just wanted to continue the discussion on platforms/ in mibuild | 15:50 |
| davidc__ | lekernel: my thoughts are that migen right now is effectively defining a language and a stdlib | 15:50 |
| davidc__ | lekernel: while migen right now is still in flux, (and probably will be for some time), at some point it'll stabilize | 15: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 kernel | 15:51 |
| 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 | 15:53 |
| lekernel | there won't be platform-specific code in the migen/ path, never | 15: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 |
| lekernel | how do you define "cyclic dependency"? | 15:55 |
| davidc__ | cyclic dependancies in combinatorial logic | 15:55 |
| davidc__ | I mean self.comb += [a.eq(b), b.eq(a)] | 15:56 |
| lekernel | well, that particular one can be safely disallowed | 15: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 point | 15:57 |
| davidc__ | IE, self.comb += If(a, ...).Elif(b, x.eq(c + d)), x would depend on a,b,c and d | 15:58 |
| davidc__ | (This is a property that'd be checked at compile-to-verilog time) | 15:59 |
| 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 | 16:00 |
| lekernel | (maybe) | 16:02 |
| davidc__ | yeah; some for of constant prop or predicate analysis could break the cycle there; but those are much more heavyweight analyses | 16:03 |
| lekernel | are 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 migen | 16:04 |
| ysionneau | I'd like to propose adding ASID support for lm32 MMU | 18:27 |
| ysionneau | any serious kernel developer I talk to about running NetBSD on lm32-mmu tells me I really should add ASID support | 18:27 |
| 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?" | 18:28 |
| 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 | 18:28 |
| ysionneau | and having to rewrite all the low level tlb code | 18:29 |
| ysionneau | (low level kernel code, not verilog) | 18:29 |
| 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 | 18:29 |
| ysionneau | maybe it's not that big a change... | 18:29 |
| ysionneau | first question: where to store "current ASID"? we have bits [31:12] of PSW (Processor Status Word) which are currently unused | 18:30 |
| ysionneau | so plenty of space for ASID, no? | 18:30 |
| ysionneau | let say, 5 bits ASID? giving 31 concurrent user space memory mapping + kernel memory mapping (which is always active) | 18:31 |
| ysionneau | one complex TLB operation I can see would be "flush TLB entries for ASID N" | 18:33 |
| 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 | 18:33 |
| 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. | 18:34 |
| ysionneau | moreover, we have also 9 unused bits in TLBPADDR and TLBVADDR to put the ASID for the "update tlb entry" operation | 18:35 |
| ysionneau | to again, plenty of room | 18:35 |
| ysionneau | -to+so | 18:35 |
| ysionneau | I may shoot an email about that soon ^^ | 18:37 |
| 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. | 18:43 |
| ysionneau | well, I honestly think they are right (I don't have any number) about that | 18:50 |
| ysionneau | flushing the entire TLB upon context switch kills a lot of perf | 18:50 |
| ysionneau | and it will be even more visible on slow cpu | 18:50 |
| ysionneau | and if you start to run several processus, and they wanna talk to each other with pipes/UNIX sockets/shared memories | 18:50 |
| ysionneau | then it's a disaster | 18:50 |
| ysionneau | tornados of tlb miss | 18:50 |
| ysionneau | you spend your life in tlb miss handler to update your tlb | 18:51 |
| ysionneau | or maybe I'm pesimistic about that? | 18:52 |
| ysionneau | I think the perf difference can be measured with a simple cat file | cut | sed | grep combination | 18:53 |
| ysionneau | but since nothing works right now ... | 18:53 |
| ysionneau | hard to compare :) | 18:53 |
| lekernel | hmm, I can believe there is a significant gain when you have a few processes intensively exchanging relatively small buffers, yes | 18:54 |
| 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 | 18:54 |
| lekernel | wpwrak, what video card did you test the HDMI EDID with? | 18:55 |
| 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. | 18:56 |
| larsc | you should go to a plugfest ;) | 19:06 |
| wpwrak | hmm, it may have been an ATI. lspci says: VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV610 [Radeon HD 2400 PRO] | 19:08 |
| 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) | 19:09 |
| lekernel | anyone near Amsterdam? https://twitter.com/HFDNL/status/405815687748534272 | 21:51 |
| ysionneau | sorry no | 22:29 |
| lekernel | larsc, any upcoming ones you know in Europe? | 22:37 |
| ysionneau | gn8 | 22:42 |
| --- Thu Nov 28 2013 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!