cladamw | wpwrak, 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 |
---|---|---|
wpwrak | checking ... | 01:03 |
wpwrak | 0.04" all the way | 01:05 |
wpwrak | in oscillator-cmos-out-4.lib and in the schematics | 01:06 |
wpwrak | that is, STANDBY, GND, VDD, and OUT | 01:07 |
wpwrak | pins are 50 mil, as you say. and "CLOCK OSCILLATOR" is 60 mil | 01:07 |
wpwrak | in kicad-libs/components, if you run | 01:10 |
wpwrak | md5sum oscillator-cmos-out-4.lib | 01:10 |
wpwrak | does it say | 01:10 |
wpwrak | f897753a70d86eead9960687b04e2b62 oscillator-cmos-out-4.lib | 01:10 |
wpwrak | ? | 01:10 |
wpwrak | if not, then you need to commit or push | 01:10 |
wpwrak | if yes, then you may have a cache somewhere along the way | 01:10 |
cladamw | Does 0.05" to be 1.27mm( i.e. 50 mil ), no ? | 01:11 |
wpwrak | yes, correct | 01:12 |
cladamw | so you are meant the commit on git server is 0.04" now ? | 01:13 |
wpwrak | that's what i get, yes | 01:13 |
wpwrak | aha, you're bringing reinforcements :) | 01:14 |
wpwrak | see for example http://projects.qi-hardware.com/index.php/p/kicad-libs/source/tree/master/components/oscillator-cmos-out-4.lib#L14 | 01:15 |
wpwrak | the "40" means 0.04" | 01:15 |
cladamw | oah ...yes, i'm very surprising now ... | 01:16 |
wpwrak | hehe ;-) | 01:17 |
cladamw | must be my git commit skill was wrong somewhere. ? | 01:17 |
wpwrak | perhaps. what does the md5sum say ? | 01:18 |
cladamw_ | md5sum oscillator-cmos-out-4.lib | 01:20 |
cladamw_ | f897753a70d86eead9960687b04e2b62 oscillator-cmos-out-4.lib | 01:20 |
wpwrak | interesting | 01:21 |
cladamw_ | what's happened ? | 01:21 |
wpwrak | so your git skills are fine | 01: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 |
wpwrak | are 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.27mm | 01:25 |
wpwrak | crazy :) | 01:25 |
cladamw_ | but i used gedit to view kicad-lib/components/ , it shows 0.04" (40) | 01:26 |
wpwrak | did 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****.lib | 01:28 |
wpwrak | hmm. try this: exit eeschema | 01:30 |
cladamw_ | did you see also 1.27mm when double-clicking in Library Editor ? | 01:30 |
wpwrak | then, in board-m1/r4/ do ls *cache* | 01:30 |
wpwrak | i 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.lib | 01:32 |
cladamw_ | kill it ? | 01:32 |
wpwrak | yeah, death to all caches | 01:33 |
cladamw_ | now, i entered Library Editor, it still shows 1.27mm . :( | 01:34 |
wpwrak | that one's persistent | 01:35 |
wpwrak | i wonder if we're talking about the same thing, though | 01:35 |
cladamw_ | hmm. ... maybe | 01:37 |
cladamw_ | so did you mean STANDBY text size or STANDBY pin number size ? | 01:37 |
wpwrak | text size | 01:40 |
cladamw_ | wpwrak, i think i was stupid though, you meant for text size! | 01:40 |
cladamw_ | poor english from adam | 01:40 |
wpwrak | http://downloads.qi-hardware.com/people/werner/tmp/mystery-40mil.png | 01:40 |
wpwrak | i double-clicked on the STANDBY text (arrow) | 01:41 |
cladamw_ | yeah ... i'm very SORRY that i mis-understood your meanings. | 01:42 |
wpwrak | no problem :) | 01:44 |
wpwrak | so i think the conclusion is "no change" then ? | 01:44 |
wpwrak | ah, "with change" :) | 01:45 |
wpwrak | let's see how that went ... | 01:45 |
cladamw_ | :-\ | 01:47 |
wpwrak | ah, 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 |
wpwrak | yup. 100% fped :) | 01:49 |
cladamw_ | so why did NOT use by default KiCad tool ? | 01:50 |
cladamw_ | what's the histories behind ? | 01:50 |
wpwrak | have you tried kicad's module (footprint) editor ? | 01:51 |
wpwrak | if yes, i challenge you do to this ;-) http://downloads.qi-hardware.com/people/werner/tmp/header.pdf | 01:52 |
wpwrak | all these are generated from this: http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/labsw/modules/header.fpd | 01: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 |
wpwrak | fped 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 |
wpwrak | be careful about these. many there have bugs. | 01:56 |
cladamw_ | or even current specific projects in qi-hw ? | 01:56 |
wpwrak | the ones in the qi-hw universe are better | 01:56 |
wpwrak | yes, these are safer | 01:56 |
cladamw_ | hmm, okay | 01:57 |
wpwrak | but 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 |
wpwrak | okay. 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 replication | 02:02 |
cladamw_ | okay, thanks a lot. | 02:05 |
wpwrak | but 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/a73bd04c14517f3575cc0a62077162eb4cb4165c | 02:43 |
GitHub158 | [board-m1/master] MiscControl.sch: make zerners vertically - Adam Wang | 02:43 |
GitHub99 | [board-m1] adamwang pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/7fad55b7a9e7b203303fb85d697c381a9fe79e6c | 02:55 |
GitHub99 | [board-m1/master] Audio.sch: moved texts to better places. - Adam Wang | 02:55 |
GitHub179 | [board-m1] adamwang pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/183c33bee2d3e0ed870020d722fee4702de3f352 | 06:23 |
GitHub179 | [board-m1/master] MiscControl.sch: changed D[6..13] to chip name ZENER-13 - Adam Wang | 06:23 |
Fallenou | sb0: 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 |
Fallenou | your* | 18:35 |
sb0 | it should not be needed | 18:36 |
sb0 | otoh you do need the valid bit, eg after a peripheral has done DMA, the cache copy is no longer valid and needs to be flushed | 18:36 |
Fallenou | you are talking about the cache tag valid bit, right ? | 18:37 |
Fallenou | not the TLB tag valid bit | 18:37 |
sb0 | don't they become the same? | 18:37 |
Fallenou | well for me it's two different things | 18:37 |
sb0 | what's the TLB tag valid bit then? | 18:38 |
sb0 | it indicates whether there's a page mapped at that address or not? | 18:38 |
Fallenou | a bit that tells if the tlb entry is valid or not | 18:38 |
Fallenou | if the bit is 0, then generate an exception to be handled by the kernel to set up a correct mapping | 18:38 |
sb0 | yes, sure, we need that | 18:39 |
Fallenou | whether there is a page mapped or not, this piece of information is kept inside the kernel structures | 18:39 |
Fallenou | tlb is just a cache of this structure | 18:39 |
Fallenou | a subset | 18:39 |
sb0 | at a context switch you obviously need to rewrite (or flush) the entire TLB no? | 18:40 |
Fallenou | I would say so yes | 18:40 |
Fallenou | it's not very good for performances, because you then will get a bunch of exceptions | 18:41 |
sb0 | you can keep the cache data though | 18:41 |
Fallenou | yes | 18:41 |
Fallenou | I don't see how we could keep the TLB valid at context switch | 18:41 |
Fallenou | but the cache yes | 18:41 |
sb0 | to avoid those exceptions, what you can do is keep the last TLB state for each task | 18:41 |
Fallenou | yes | 18:41 |
sb0 | and you reload it when switching to that task | 18:42 |
Fallenou | it means that the context switch will take a little bit more time | 18:42 |
Fallenou | because we refill TLB with known entries | 18:42 |
sb0 | yeah, sure, all those things have some overhead... | 18:42 |
sb0 | that's also why we have rtems... | 18:42 |
Fallenou | ok | 18:42 |
Fallenou | I just wanted to know if there was some magical (or ingenious) solution in order not to flush TLB at context switch | 18:43 |
Fallenou | it seems there is none | 18:43 |
sb0 | if you don't modify the TLB, the new process will get memory mappings from the old, which is obviously wrong | 18:43 |
Fallenou | there could be one, we talked about adding some kind of task id to the TLB tag | 18:43 |
Fallenou | yes | 18:43 |
sb0 | nah but don't bother now | 18:44 |
sb0 | maybe this is fast enough | 18:44 |
Fallenou | ok, I hope so ^^ | 18:44 |
sb0 | a possible acceleration will be to DMA the TLB *g* | 18:46 |
sb0 | assuming this is really the bottleneck | 18:46 |
Fallenou | that would mean making the TLB accessible via wishbone, right ? | 18:46 |
Fallenou | that would slow it down I guess | 18:46 |
sb0 | no, add two instructions "load whole TLB starting from memory address x" and "store whole TLB starting from memory address x" | 18:47 |
sb0 | cisc-style instructions :) | 18:47 |
Fallenou | oh ok :) | 18:47 |
Fallenou | it's like the CR3 register from x86 | 18:47 |
Fallenou | well, some kind of | 18:47 |
Fallenou | OK, it's more clear to me now ! | 18:50 |
Fallenou | sb0: 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 collisions | 18:53 |
Fallenou | because page frame numbers are 20 bits wide | 18:54 |
sb0 | huh? | 18:54 |
sb0 | what you call "tag" really is just the valid bit in the code atm | 18:54 |
Fallenou | tag should contain the 10 top physical address bits | 18:55 |
Fallenou | arg nop | 18:55 |
Fallenou | it should contain the 10 top virtual address bits | 18:55 |
sb0 | but now it doesn't | 18:56 |
Action: Fallenou checks | 18:56 | |
sb0 | and why would you need to store the virtual address? it's given by the memory access.. | 18:57 |
sb0 | and it indexes the TLB | 18:57 |
Fallenou | say I set up the following memory mapping : 0b0000000000 1000000000 -> 0b0000000000 1100000000 | 18:58 |
Fallenou | I am only writting the top 20 bits here | 18:58 |
Fallenou | (virtual -> physical) | 18:59 |
Fallenou | If I try to access the following virtual address : 0b0000000001 1000000000 , then it will translates it to 0b0000000000 1100000000 | 19:00 |
Fallenou | because TLB index is only 10 bits wide | 19:00 |
sb0 | ah, sorry. yes, you need to store those extra VA bits that are not part of the TLB index | 19:00 |
Fallenou | so you can have a lot of collisions (actually 2^10 collisions per entry) | 19:00 |
Fallenou | yes | 19:00 |
sb0 | but I think you can have one single memory, and each word is {valid bit, extra VA bits, physical address} | 19:02 |
Fallenou | yes I guess | 19:02 |
Fallenou | the "data" would be 10+20+1 = 31 bits wide | 19:03 |
sb0 | where is 20 coming from? | 19:03 |
sb0 | you should make that parametrizable by the way | 19:03 |
Fallenou | 20 is the physical address | 19:03 |
sb0 | physical addresses are 32 bits | 19:03 |
Fallenou | only the top 20 bits are interesting here | 19:04 |
Fallenou | not the offset which is given in the request | 19:04 |
sb0 | ah, yes, 30-bit (with word alignment) | 19:04 |
sb0 | I see | 19:04 |
sb0 | split into 10-bit TLB and cache index + 20 bit extra | 19:05 |
Fallenou | 30 ? and the valid bit ? | 19:05 |
sb0 | yes | 19:05 |
Fallenou | word alignment ? | 19:06 |
Fallenou | we are talking about the upper part of the address, right ? | 19:06 |
sb0 | yes, the 32 bit address is with byte granularity | 19:06 |
Fallenou | oh yes you are talking about the index | 19:07 |
Fallenou | brb *diner* | 19:07 |
Fallenou | *back* | 19:43 |
Fallenou | sb0: do you think it's possible to infer 1024 32bits words in blockRAM in a Spartan 6 ? | 19:49 |
Fallenou | in http://www.xilinx.com/support/documentation/user_guides/ug383.pdf they say "512 x 32" :o | 19:50 |
Fallenou | maybe it will automagically instantiate 2 512x32 blockram blocks and some muxes | 19:51 |
sb0 | yes, the tools are smart enough to do that | 19:53 |
sb0 | you generally do not have to worry about what kind of block rams are used and how many | 19:54 |
Fallenou | ok great | 19:55 |
Fallenou | I was already inferring 1kx20 bits anyway | 19:55 |
Fallenou | gn8 ! | 21:00 |
wpwrak | does 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 |
sb0 | it could have a unusable tag, but the cost of the valid bit isn't so high that it would justify such a hack | 23:07 |
wpwrak | good. i prefer it cleaner, too :) | 23:11 |
--- Thu May 10 2012 | 00:00 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!