#milkymist IRC log for Wednesday, 2012-05-09

cladamwwpwrak, my U3's STANDBY and GND text size of pin # and name here is 1.27mm(0.05"), yours maybe not be updated ?01:02
wpwrakchecking ...01:03
wpwrak0.04" all the way01:05
wpwrakin oscillator-cmos-out-4.lib and in the schematics01:06
wpwrakthat is, STANDBY, GND, VDD, and OUT01:07
wpwrakpins are 50 mil, as you say. and "CLOCK OSCILLATOR" is 60 mil01:07
wpwrakin kicad-libs/components, if you run01:10
wpwrakmd5sum oscillator-cmos-out-4.lib01:10
wpwrakdoes it say01:10
wpwrakf897753a70d86eead9960687b04e2b62  oscillator-cmos-out-4.lib01:10
wpwrak?01:10
wpwrakif not, then you need to commit or push01:10
wpwrakif yes, then you may have a cache somewhere along the way01:10
cladamwDoes 0.05" to be 1.27mm( i.e. 50 mil ), no ?01:11
wpwrakyes, correct01:12
cladamwso you are meant the commit on git server is 0.04" now ?01:13
wpwrakthat's what i get, yes01:13
wpwrakaha, you're bringing reinforcements :)01:14
wpwraksee for example  http://projects.qi-hardware.com/index.php/p/kicad-libs/source/tree/master/components/oscillator-cmos-out-4.lib#L1401:15
wpwrakthe "40" means 0.04"01:15
cladamwoah ...yes, i'm very surprising now ...01:16
wpwrakhehe ;-)01:17
cladamwmust be my git commit skill was wrong somewhere. ?01:17
wpwrakperhaps. what does the md5sum say ?01:18
cladamw_md5sum oscillator-cmos-out-4.lib01:20
cladamw_f897753a70d86eead9960687b04e2b62  oscillator-cmos-out-4.lib01:20
wpwrakinteresting01:21
cladamw_what's happened ?01:21
wpwrakso your git skills are fine01:21
cladamw_yeah ... i used gedit to check my local file, it's exactly correct same as 0.04"01:22
cladamw_BUT why in Eeschema , it shows still 0.05" (1.27mm) ?01:22
wpwrakare you double-clicking on, for example, the "STANDBY" text ?01:23
cladamw_and i just imported new xtal part, in eeschema , it's still 0.05". :(01:23
cladamw_yes, in Library Editor I doubled-clicking on STANDBY , the size is 1.27mm01:25
wpwrakcrazy :)01:25
cladamw_but i used gedit to view kicad-lib/components/ , it shows 0.04" (40)01:26
wpwrakdid you call the library editor from board-m1/r4/ or from kicad-libs/components/ ?01:26
cladamw_i see on the top frame shows text folder in Library Editor: ../../../kicad-lib/components/osci****.lib01:28
wpwrakhmm. try this: exit eeschema01:30
cladamw_did you see also 1.27mm when double-clicking in Library Editor ?01:30
wpwrakthen, in board-m1/r4/  do   ls *cache*01:30
wpwraki don't see 1.27 mm. i always get the 40 mil, i.e., the one that is really in the file :)01:32
cladamw_adam@adam-laptop:~/milkymist/board-m1/r4$ ls *cache*01:32
cladamw_m1-cache.lib01:32
cladamw_kill it ?01:32
wpwrakyeah, death to all caches01:33
cladamw_now, i entered Library Editor, it still shows 1.27mm . :(01:34
wpwrakthat one's persistent01:35
wpwraki wonder if we're talking about the same thing, though01:35
cladamw_hmm. ... maybe01:37
cladamw_so did you mean STANDBY text size or STANDBY pin number size ?01:37
wpwraktext size01:40
cladamw_wpwrak, i think i was stupid though, you meant for text size!01:40
cladamw_poor english from adam01:40
wpwrakhttp://downloads.qi-hardware.com/people/werner/tmp/mystery-40mil.png01:40
wpwraki double-clicked on the STANDBY text (arrow)01:41
cladamw_yeah  ... i'm very SORRY that i mis-understood your meanings.01:42
wpwrakno problem :)01:44
wpwrakso i think the conclusion is "no change" then ?01:44
wpwrakah, "with change" :)01:45
wpwraklet's see how that went ...01:45
cladamw_:-\01:47
wpwrakah, looks good. that went better than i thought :)01:47
cladamw_wpwrak, does this http://people.openmoko.org/werner/gta02-core/gta02-core-modules.pdf  ALL made by fped ?01:48
wpwrakyup. 100% fped :)01:49
cladamw_so why did NOT use by default KiCad tool ?01:50
cladamw_what's the histories behind ?01:50
wpwrakhave you tried kicad's module (footprint) editor ?01:51
wpwrakif yes, i challenge you do to this ;-)  http://downloads.qi-hardware.com/people/werner/tmp/header.pdf01:52
wpwrakall these are generated from this: http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/labsw/modules/header.fpd01:53
cladamw_wpwrak, yes, i tried it to make few modules before but not too much.01:53
wpwrak(and don't fear, i made it through the GUI, not by editing the .fpd directly)01:54
wpwrakfped is good at doing loops and such. so it's very easy to make a set of similar footprints. like these headers.01:56
cladamw_wow ~ so seems we can use a lot of modules gta02-core ?01:56
wpwrakbe careful about these. many there have bugs.01:56
cladamw_or even current specific projects in qi-hw ?01:56
wpwrakthe ones in the qi-hw universe are better01:56
wpwrakyes, these are safer01:56
cladamw_hmm, okay01:57
wpwrakbut before we move on to the modules/footprints, are we done with the schematics ?01:57
cladamw_no, i'm changing few things now.01:59
wpwrakokay. when you're done with the schematics, i'll do an item by item comparison with the original, to see if this is really an exact replication02:02
cladamw_okay, thanks a lot.02:05
wpwrakbut that's for tomorrow. now, dinner :)02:16
GitHub158[board-m1] adamwang pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/a73bd04c14517f3575cc0a62077162eb4cb4165c02:43
GitHub158[board-m1/master] MiscControl.sch: make zerners vertically - Adam Wang02:43
GitHub99[board-m1] adamwang pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/7fad55b7a9e7b203303fb85d697c381a9fe79e6c02:55
GitHub99[board-m1/master] Audio.sch: moved texts to better places. - Adam Wang02:55
GitHub179[board-m1] adamwang pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/183c33bee2d3e0ed870020d722fee4702de3f35206:23
GitHub179[board-m1/master] MiscControl.sch: changed D[6..13] to chip name ZENER-13 - Adam Wang06:23
Fallenousb0: Do we want to flush TLB at context switch ? (meaning marking all TLB entry invalid, resetting the valid bit you are talking about in yout MMU code review)18:35
Fallenouyour*18:35
sb0it should not be needed18:36
sb0otoh you do need the valid bit, eg after a peripheral has done DMA, the cache copy is no longer valid and needs to be flushed18:36
Fallenouyou are talking about the cache tag valid bit, right ?18:37
Fallenounot the TLB tag valid bit18:37
sb0don't they become the same?18:37
Fallenouwell for me it's two different things18:37
sb0what's the TLB tag valid bit then?18:38
sb0it indicates whether there's a page mapped at that address or not?18:38
Fallenoua bit that tells if the tlb entry is valid or not18:38
Fallenouif the bit is 0, then generate an exception to be handled by the kernel to set up a correct mapping18:38
sb0yes, sure, we need that18:39
Fallenouwhether there is a page mapped or not, this piece of information is kept inside the kernel structures18:39
Fallenoutlb is just a cache of this structure18:39
Fallenoua subset18:39
sb0at a context switch you obviously need to rewrite (or flush) the entire TLB no?18:40
FallenouI would say so yes18:40
Fallenouit's not very good for performances, because you then will get a bunch of exceptions18:41
sb0you can keep the cache data though18:41
Fallenouyes18:41
FallenouI don't see how we could keep the TLB valid at context switch18:41
Fallenoubut the cache yes18:41
sb0to avoid those exceptions, what you can do is keep the last TLB state for each task18:41
Fallenouyes18:41
sb0and you reload it when switching to that task18:42
Fallenouit means that the context switch will take a little bit more time18:42
Fallenoubecause we refill TLB with known entries18:42
sb0yeah, sure, all those things have some overhead...18:42
sb0that's also why we have rtems...18:42
Fallenouok18:42
FallenouI just wanted to know if there was some magical (or ingenious) solution in order not to flush TLB at context switch18:43
Fallenouit seems there is none18:43
sb0if you don't modify the TLB, the new process will get memory mappings from the old, which is obviously wrong18:43
Fallenouthere could be one, we talked about adding some kind of task id to the TLB tag18:43
Fallenouyes18:43
sb0nah but don't bother now18:44
sb0maybe this is fast enough18:44
Fallenouok, I hope so ^^18:44
sb0a possible acceleration will be to DMA the TLB *g*18:46
sb0assuming this is really the bottleneck18:46
Fallenouthat would mean making the TLB accessible via wishbone, right ?18:46
Fallenouthat would slow it down I guess18:46
sb0no, add two instructions "load whole TLB starting from memory address x" and "store whole TLB starting from memory address x"18:47
sb0cisc-style instructions :)18:47
Fallenouoh ok :)18:47
Fallenouit's like the CR3 register from x8618:47
Fallenouwell, some kind of18:47
FallenouOK, it's more clear to me now !18:50
Fallenousb0: about the "tag" being one single bit. I think I need extra bits, because say TLB has 2^10 entries, it means there could be a lot of collisions18:53
Fallenoubecause page frame numbers are 20 bits wide18:54
sb0huh?18:54
sb0what you call "tag" really is just the valid bit in the code atm18:54
Fallenoutag should contain the 10 top physical address bits18:55
Fallenouarg nop18:55
Fallenouit should contain the 10 top virtual address bits18:55
sb0but now it doesn't18:56
Action: Fallenou checks18:56
sb0and why would you need to store the virtual address? it's given by the memory access..18:57
sb0and it indexes the TLB18:57
Fallenousay I set up the following memory mapping : 0b0000000000 1000000000 -> 0b0000000000 110000000018:58
FallenouI am only writting the top 20 bits here18:58
Fallenou(virtual -> physical)18:59
FallenouIf I try to access the following virtual address : 0b0000000001 1000000000 , then it will translates it to 0b0000000000 110000000019:00
Fallenoubecause TLB index is only 10 bits wide19:00
sb0ah, sorry. yes, you need to store those extra VA bits that are not part of the TLB index19:00
Fallenouso you can have a lot of collisions (actually 2^10 collisions per entry)19:00
Fallenouyes19:00
sb0but I think you can have one single memory, and each word is {valid bit, extra VA bits, physical address}19:02
Fallenouyes I guess19:02
Fallenouthe "data" would be 10+20+1 = 31 bits wide19:03
sb0where is 20 coming from?19:03
sb0you should make that parametrizable by the way19:03
Fallenou20 is the physical address19:03
sb0physical addresses are 32 bits19:03
Fallenouonly the top 20 bits are interesting here19:04
Fallenounot the offset which is given in the request19:04
sb0ah, yes, 30-bit (with word alignment)19:04
sb0I see19:04
sb0split into 10-bit TLB and cache index + 20 bit extra19:05
Fallenou30 ? and the valid bit ?19:05
sb0yes19:05
Fallenouword alignment ?19:06
Fallenouwe are talking about the upper part of the address, right ?19:06
sb0yes, the 32 bit address is with byte granularity19:06
Fallenouoh yes you are talking about the index19:07
Fallenoubrb *diner*19:07
Fallenou*back*19:43
Fallenousb0: do you think it's possible to infer 1024 32bits words in blockRAM in a Spartan 6 ?19:49
Fallenouin http://www.xilinx.com/support/documentation/user_guides/ug383.pdf they say "512 x 32" :o19:50
Fallenoumaybe it will automagically instantiate 2 512x32 blockram blocks and some muxes19:51
sb0yes, the tools are smart enough to do that19:53
sb0you generally do not have to worry about what kind of block rams are used and how many19:54
Fallenouok great19:55
FallenouI was already inferring 1kx20 bits anyway19:55
Fallenougn8 !21:00
wpwrakdoes the TLB truly need a valid bit ? or could it just have an unusable tag ? (of course, valid bit is cleaner. just in case we're squeezed for bits and/or operations)23:04
sb0it could have a unusable tag, but the cost of the valid bit isn't so high that it would justify such a hack23:07
wpwrakgood. i prefer it cleaner, too :)23:11
--- Thu May 10 201200:00

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