#milkymist IRC log for Saturday, 2012-06-30

wolfspraulshort term goal is to be able to load very simple but running designs into a slx9 (for example, since that's on azonenberg's board)00:00
wolfspraul'very simple' is something like an inverter, from one pad to another pad00:00
wolfspraulthen going up from there, a few more gates (slices), clocks, etc.00:00
wolfspraulthe longer term goal is to be able to synthesize the milkymist soc into something that runs on the chip00:02
Fallenouwhat Xilinx tool would youreplace ?00:02
FallenouXst ?00:02
wolfspraulall00:02
wolfspraulno, all00:02
Fallenouoh :)00:02
wolfspraulin fact I'm not at the Xst level and won't be for a while00:02
wolfspraulhopefully there is something reusable in icarus verilog or elsewhere00:03
Fallenouso you parse verilog, synth, map, place , route, and then generate bitstream from netlist ?00:03
azonenbergwolfspraul: going to dumpster dive on campus for an hour or so00:03
azonenbergif nobody has further suggestions i'll send gerbers out to the fab tonight00:03
azonenbergshould get 'em in ~3 weeks00:04
wpwrakwill they do something with the order during the weekend ?00:06
wpwrakif not, perhaps wait until sunday, i case someone has further ideas00:07
wpwraks/i /in/00:07
wolfspraulFallenou: no, not at all00:11
wolfspraulthat is all far too much and too diverse00:11
wolfspraulI work on the bitstream, and only that00:11
wolfspraulI have a chip, say the slx9, ok? now I want to load a running design into it. something super simple, hand-mapped into the primitives on the chip00:12
wolfspraulthat's what I work on00:12
wolfspraulthe goal is to keep that first level as small and clearly focused as possible00:12
Fallenouoh ok00:12
wolfspraulit must be 100% stable, bug-free, etc.00:13
wolfspraul(that's the goal)00:13
Fallenouso you want to connect a few LUT together00:13
wolfspraulnot even that, at the beginning just an inverter between two pads00:13
Fallenouyou generate the bitstream that does that00:13
wolfspraulbut then a (one) slice, yes00:13
wolfspraulthen two slices00:13
wolfspraulthat already includes lots of routing00:13
wolfspraulthe inverter would only go to the ILOGIC/OLOGIC, through some switch boxes, and out the other pad00:13
wolfspraulI start with that00:13
Fallenouyou will soon be an expert of FPGA internals :)00:14
wolfspraulthat's at least 50% of the value of the project for me00:14
wolfspraulafter 1 month I already start to feel better, but there are many more things to understand00:14
wolfspraullet's see where it is in 2 months00:15
wolfspraulI'm optimistic00:15
wolfspraul'inverter' though, ok?00:15
wolfspraulmilkymist soc is the longer term goal00:15
FallenouI started the MMU project in mid january, and it's not finish, all of these things take time00:15
Fallenouspeaking with "months" is the good granularity I think :)00:16
wpwraksmall steps are good. it's much easier to stay motivated when each day ends with a little success than working on a project that will solve all the world's problems after a decade of work  but that does nothing else before that. (and by the end of that decade you'll be thorough lost in in-thinking anyway :)00:20
Fallenousure00:20
Fallenoudefinitely00:20
Fallenouis m1r4 still in the pipeline ? at least for a few samples ?00:20
FallenouI can see a few adam's emails from time to time :)00:21
Fallenouwhich makes me think it's still in the pipe00:21
Fallenouwhich is great :)00:21
wolfspraulit won't take a decade00:35
wolfspraulout now for a few hours, saturday family obligations00:35
wolfspraulbut, in good fallenou culture, my notebook goes with me and so go the s6 primitive schematics :-)00:35
wolfspraulI try to isolate the chip-specific knowledge in the smallest possible tool/code00:36
wolfspraulon top of that tool we are then dealing with very simple boolean logic and gates/structures etc. then I will think about how to translate higher-level logic abstractions into those structures, aka packing/routing00:37
wolfspraulbut that problem can and should be addressed in a chip-agnostic way00:37
wolfspraulI talk about it more when something actually works, i.e. not now :-)00:37
wolfspraulif I have the inverter running on my desk in 2 months I'm happy00:37
wpwrakhmm, the vias under the FPGA will be hard for a DIY FPGA00:41
wpwraks/DIY FPGA/DIY PCB/00:41
Fallenougood saturday wolfspraul :)00:42
wolfspraulis there a free tool for schematic entry of a chip?00:52
wolfspraulI started to do drawings in svg but it's too raw and wasting time00:52
wolfspraulmaybe I use kicad00:52
wolfspraulthe purpose is to document primitive or parts-of-primitives schematics00:52
wolfspraulvias under fpga?00:53
wolfsprauldon't understand00:53
wolfspraulyou mean azonenberg's board has some vias there? haven't checked yet00:54
wolfspraulone by one :-)00:54
wpwrakyes, he has vias under the fpga. this means that you have to make them VERY flat00:54
wpwraknot taller than 0.1 mm00:55
wolfspraulsure, or I modify the board, or I de-couple the diy-pcb and fpgatools a little and just fab it somewhere locally00:55
wolfspraulI can probably get this made in 2 days, in horrible sloppy quality then I can learn about testing and fixing pcbs :-)00:55
wpwrakyup. all viable options00:55
wpwrak;-))00:55
wolfspraulin the end it all comes around to knowledge and quickly picking what one really needs00:56
wpwraksure. the only thing is that you don't learn how to make DIY-friendly layouts this way00:58
wpwrakbut yes, everything has its price ;)00:58
Fallenouhum hum my first relocated calli seems to be OK01:06
Fallenousecond one ok too01:12
Action: Fallenou checking if the calli instructions get patched correctly to change the "immediate" part of the opcode according to the new virtual address of the instruction01:13
Fallenouarg fucking moskito01:13
wpwrakgas 'em :)01:20
Fallenouit's dead01:23
Fallenouthe shoe shoot01:23
wpwrakmay its rotten soul burn in hell ;-)01:23
Fallenouamen !01:24
Fallenounice !01:34
Fallenourelocating on-the-fly non-PIC code works :)01:35
FallenouI have the void f(void) { puts("@"); } working01:35
Fallenouthe code of f() contains 9 CALLI =)01:35
Fallenouputs got inlined01:35
Fallenouall 9 CALLI got rewritten on the fly when copied to their new physical locations, taking into account their virtual location to rewrite the "jump relative offset"01:36
Fallenououtput is kind of messy because I don't think the puts/printf stuff are re-entrant :p01:36
FallenouI mean the ITLB/DTLB exception handler is using printf and puts01:36
Fallenouso I guess bad things happen if puts or printf cause the DTLB/ITLB exception :)01:37
Fallenoua puts while putsing ...01:37
wpwrakhmm. use write() ?01:38
Fallenouyes I should use more low level stuff in exception handlers01:39
Fallenouuntill now it didn't make any problem01:39
Fallenouso it was good enough :)01:39
Action: Fallenou uses crappy code, unless it makes real problems01:40
Fallenouok awesome, it works really well (in ISim) if I comment puts/printf from DTLB/ITLB exception handlers01:41
FallenouI can still see the exceptions happening because of a $display() in verilog code anyway :)01:41
Fallenouwpwrak wolfspraul lekernel http://pastebin.com/kqcaKT8w :)01:47
Fallenoua nice ITLB test with relocation, the assembly code of the function (f) being relocated, the ISim simulator output01:48
Fallenouall mmu mappings are "lazy" ones, nothing is really mapped untill there is a page fault01:50
Fallenouin the simulation you can see a few page faults01:50
wpwrakwhee !01:50
wpwraknow let's see what it does on the real iron :)01:51
Action: Fallenou fears01:51
FallenouI bet it won't run, bah01:51
Fallenoubut let's try anyway01:51
Fallenoudamn it02:07
Fallenouwpwrak: on the FPGA, puts() is in the NAND at address 0x0086777C02:08
Fallenouand I relocate f() at virtual address 0x4400400002:08
FallenouI can't calli this far :(02:08
Fallenouthe jump offset is too high02:08
wpwrakwrite your own uart-writing loop02:08
wpwrakthat way, you also avoid weird effects from libc02:09
FallenouI tried again with just writting to uart RX_TX reg instead of calling puts() in f()02:14
Fallenouand therefore without any rewritting any calli instr02:15
Fallenouand without puts/printf in dtlb/itlb handlers02:15
Fallenouand it still crashes02:15
Fallenoulet's try running the original f() without copying it02:15
wpwrakare there any other pc-relative items ? such as a long pointer ?02:17
wpwrakand ... can't you just compile with -fPIC ?02:18
Fallenoumaybe, I just did not try :p (-fPIC)02:18
FallenouI don't know exactly how it works (-fPIC)02:19
Fallenouok even running the f() from 0x86777C (nand) it still crashes02:19
Fallenouso no PIC problem involved here02:19
azonenbergwpwrak, wolfspraul: i designed the board for the oshpark.com 2-layer process02:22
azonenberg$5/in^2 gets you three units02:22
azonenbergit'd be around $8 per blank board at that rate02:22
azonenbergwith a ~3 week lead time02:22
azonenbergat least, that's the design rules i used and thts where i'll be making the prototype02:22
Fallenoucompiling with -fPIC seems to produce something interesting, all calli are basically gone, replaced by call rX with rX loaded from memory02:23
FallenouI guess lm32-gcc does PIC correctly02:23
wpwrakFallenou: see :)02:23
Fallenoubut I am not sure my problem was PIC :p02:24
wpwrakazonenberg: PCBs for the patient ;-)02:24
azonenbergwpwrak: well most of my stuff is 4 layers02:24
azonenbergand i cant make that in house02:24
azonenbergits also 6/6 mil design rules, decently small vias, ENIG finish, silk, soldermask02:24
azonenbergtotally worth the wait02:25
Fallenouwpwrak: bios does not even boot, compiled with -fPIC :'02:25
Fallenouit prints "SDRAM initialization completed, boot continuing" and then nothing02:25
Fallenoumaybe I need to hack the linker script a little bit, maybe I need to add a few sections02:26
Fallenoulike .got02:26
Fallenouand .got.plt02:28
Fallenouok now it boots :)02:28
Fallenoustill crashing when running f()02:28
Fallenou4h30 am here, going to sleep, gn8 !02:29
Fallenouwe should drop the FPGA from the M1, put an Intel X86, run ISim with Milkymist SoC :)02:31
Fallenoummu works better in ISim :p02:31
Action: Fallenou goes to bed singing "trololololo"02:31
lekernelhuh, yes, the relocate is a bit messy09:43
lekernelwhy not just a function that writes to the UART without any libc call?09:44
lekernelFallenou:09:47
lekernelCSR_UART_RXTX = '@';09:47
lekernelwhile(!(CSR_UART_STAT & UART_STAT_THRE));09:47
lekernelthat's all09:47
lekerneland no interrupts etc.09:47
lekernel(of course, you'll want to make sure that the rest of the code that may uses the interrupt is disabled. so do uart_force_sync() before)09:48
lekerneland you loop on that if you want to write a string09:48
lekernelspeaking of interrupts, does it correctly store the virtual address for return when an interrupt occurs with the MMU enabled? that might be your problem09:49
lekernelbut i'd start by getting it to work without any interrupt involved09:50
Fallenoulekernel: yes for both simulation and real fpga stuff I disactivate interrupts in the main()10:51
Fallenouand uart is used in polled mode10:51
Fallenouhttps://github.com/fallen/milkymist-mmu/blob/mmu/software/libbase/uart.c#L10010:53
Fallenoubut yes indeed I should not call libc stuff from exception handler and from my f() function running in virtual addressing10:54
Fallenouit's just painfull to directly use CSR_UART_RXTX10:54
Fallenouand even more if you want to have a printf() like functionnality :p10:54
Fallenoulekernel: about interrupts, it should be handled OK, I have not tested yet though. if the code is running in "user mode" when the irq happens, the mmu goes in "kernel mode" and irq handler is run, and when irq handler does "eret" mmu goes back into user mode and jumps to EA which contains PC_x of when irq happened, which is always a virtual address so it should be ok10:58
Fallenouit works for page faults10:58
Fallenouit should work the same for irq10:58
Fallenoubut for now I disabled irq ^^10:58
Fallenousomething I should implement is : is an exception happens while mmu is in kernel mode, when returning from the exception mmu should not put itself in usermode, but "back" at the previous state => means stay in kernel mode11:01
FallenouI should just add a backup reg11:01
Fallenouif an exception*11:01
rohcan exceptions happen in its handlers?11:02
Fallenouheh I am wondering the same thing11:02
FallenouI think nested exceptions are allowed here11:03
rohmaybe a stupid question.. but i am trying to understand ;)11:03
Fallenouso it will be a pain11:03
rohirgh. well.. fun!!1!11:03
Action: Fallenou opens lm32 datasheet11:03
Fallenouit's kind of blury11:04
Fallenoudatasheet says "limitd nesting exception is possible"11:04
Fallenoulimited*11:04
Fallenouit says that more advanced nesting needs software help11:04
Fallenounot very usefull11:05
Fallenoubecause if I'm in the *TLB handler (an exception handler), and I get an incomming IRQ (another exception) it could be bad11:06
Fallenouoh there is a paragraph about nested exceptions (another one)11:08
Fallenouone mess at a time :'11:10
Fallenouhttp://vedantk.tumblr.com/post/26182854460/higher-order-programming-in-c < hehe nice magic trick !11:15
lekerneltry with CSR_UART_RXTX firs11:44
lekernelt11:44
lekernelit's not painful, just 2 lines of code11:44
Fallenoulekernel: I just tried with CSR_UART_RXTX = '@'; while(!(CSR_UART_STAT & UART_STAT_THRE));12:10
Fallenouit still crash12:10
FallenouI don't believe my troubles come from uart stuff12:10
FallenouI guess it's some pipeline timing problem12:13
Fallenouhttp://pastebin.com/V7zpUXUE < if I don't do lazy mapping for ITLB it works quite well :)12:13
Fallenouthis is on FPGA12:13
Fallenouif I do lazy mapping it prints "Mapping DONE" and hangs12:14
wpwrakyou should probably just disable interrupts in the ITLB handler. if handling the fault is more complex (e.g., reading a page from storage), then let software deal with the mess12:48
lekernelyeah12:50
wpwrak(apply) a nice instant portability barrier ;-)12:50
Fallenouhehe yes I agree12:50
Fallenoubut a nice technical solution12:50
lekerneland software can re-enable interrupts from the ITLB handler if it needs to (that's actually how you can have nested interrupts on LM32: reenable interrupts in sw from the isr)12:50
Fallenoua nice geeky code12:50
Fallenou(disable irq during itlb handler) yes agreed12:51
wpwrakyou should look at umlsim for doing nasty things ;-) the UML (User-Mode Linux) part no longer works because of changes in UML, but the rest of the system should still be fine12:51
wpwrak(mmu) we'll also need a way to enable the MMU while in kernel mode, for things like vmalloc12:53
lekernelhuh? that would be messy... kernel mode == MMU disabled12:55
lekernelmicroblaze does it that way... so it's possible12:55
wpwrakyou'd lose the functions that avoid trouble with memory fragmentation. you should be able to fall back to the non-MMU functions, though13:00
wpwrakah, and how about kernel accessing user mode data ? can you selectively enable the MMU for, say, the next access ? or do these functions have to walk the page tables "manually" ?13:01
lekernelreading the page table from sw looks simpler13:02
FallenouI agree with lekernel13:15
Fallenoukernel == user mode13:15
Fallenouand accessing user land memory is done by accessing physical address (doing the lookup in software)13:16
Fallenouwpwrak: why would the kernel need to allocate virtual memory if it's not for a processus context ?13:20
Action: Fallenou is not an expert of the linux kernel13:21
Fallenoucould you elaborate about vmalloc ?13:21
Fallenouhow does it work in x86 ? the kernel activates the MMU even in kernel land when it needs to access "kernel virtual memory" ?13:22
wpwrakyes. MMU and kernel mode are decoupled. so you can choose whether you want to have the MMU on or not.13:23
Fallenouoh13:24
Fallenouok I didn't know that13:24
wpwrakvmalloc allocates large sections of memory by allocating individual pages (which can be scattered all over the memory pool) and then making a single linar mapping of them13:24
wpwraklinEar13:24
Fallenouon my x86 desktop computer mmu is ON while kernel is running a syscall ?13:24
wpwrakthis avoids the problem of, say, having to find an unbroken chunk of 64 kB in the page pool. finding large chunks of contiguous memory gets harder as the uptime of your system increases, since you get fragmentation13:25
wpwrakbut - as long as there is any memory left at all - you can always allocate a single page13:26
Fallenouyes ok13:26
FallenouI understand it helps if you can use virtually contiguous memory13:26
FallenouI guess I would need to read a bit of this www.kernel.org/doc/gorman/pdf/understand.pdf13:27
wpwrakso defensively written kernel code allocates things > 4 kB either with vmalloc or has its own strategy to break the allocation down into smaller pieces13:27
wpwraklemme check how the MMU is switched on x86 ...13:27
Action: wpwrak blows dust from a big old book13:28
Fallenouhehe :)13:29
FallenouI wonder how openrisc does to manage mmu_on/off13:38
Action: Fallenou will have a look13:38
kristianpaulcant just be always on?13:39
Fallenouwell I can do that, it's even easier for me :)13:39
Fallenouboots with mmu off, and you can manually (with asm instr) activate/disactivate it, and it never changes by itself13:40
Fallenouif this is OK I'm very happy =)13:40
Fallenouthat would mean mapping exception vectors in the mmu but .... why not !13:40
Fallenouopencores website is down =(13:40
Fallenouwhen you need it ... !13:40
larscas far as I can see microblaze on linux has support for virtual memory in kernel mode13:41
kristianpaulwhat this mean in mmu terms? (sorru mmu noob here trying yo understand)13:41
kristianpaulsorry*13:42
larscthat the mmu needs to be on13:42
kristianpaulalways?13:43
Fallenoukristianpaul: I mean if mmu is always on, you need to map CPU exception vectors (divide by zero, interrupt, page fault) to virtual memory13:43
Fallenousince they will be accessed through virtual memory (because mmu is ALWAYS on)13:43
larscFallenou: you could have a memory region which has always a direct mapping13:44
larscwhich is as far as I know what is usually done13:44
kristianpaulFallenou: that sounds like more "safe" to me13:44
Fallenouyes that would mean redesigning the mmu :'13:44
kristianpaulwich is good i think13:44
wpwrakwormed my way through the old i386 stuff ... the magic is done with the x86 segments there. and it does seem that the MMU is always on. you achieve the protection by permission checks in the MMU/TLB, not by choosing whether you allow a page to be mapped.13:46
FallenouI will have a look at Cortex A8 datasheet13:46
wpwrakthe TLB is populated by hardware, so you only get an exception if a page is unmapped, but not just when it's missing in the TLB13:47
larscwpwrak: I don't think you want to take the i386 as an example for anything ;) unless it's as a bad example13:47
Fallenouwell yes there is the nice "hardware page walker" which allow to just give a pointer to CR3 reg and let the MMU do all the work for you13:48
wpwraki.e., you set up your page tables in memory and tell the MMU where they start. then the hardware takes care of the rest.13:48
Fallenouyes sure13:48
Fallenoubut I won't do such a thing13:48
wpwraklarsc: yeah, "protected mode" is phenomenally perverse ;-) i already tried to leave out the nasty bits in my summary13:48
larscif you want to do fast context switches you also want to avoid having to flush the caches on a context switch13:48
Fallenouit's too much work and it will blow the cpu performance13:48
wpwrakyou could simply have kernel/user mode bit in TLB entires. when trying to access a kernel page from user mode, you get an exception. everything else is allowed.13:50
larschere is a paper how that was implemented on ARM: https://lwn.net/images/conf/rtlws11/papers/proc/p01.pdf13:50
Fallenouyes I saw this paper, I read parts of it13:50
FallenouI don't remember why but I ruled this implementation out :o13:51
FallenouI didn't like the PID stuff I guess13:52
Fallenouit forces you to have a special virtual memory mapping for user processes13:53
Fallenouand it limits the number of processes13:53
Fallenoubut it's definitely worth re-reading13:54
Fallenouthanks13:54
wpwrakkernel/user mode protection would basically use the same exception path as writing to a read-only page14:00
Fallenouhum hum http://lxr.linux.no/#linux+v3.4.4/arch/x86/mm/fault.c14:01
Fallenouthey have a special handler for vmalloc faults14:02
Fallenoubut they specifically say "a page fault in the kernel is not normal we should OOPS"14:02
Fallenouit's ok with x86 because MMU have page tree walker, but here we only have a small TLB and access to a page which is not in the TLB will generate a page fault14:02
Fallenouhttp://lxr.linux.no/#linux+v3.4.4/arch/arm/mm/fault.c#L40014:06
Fallenouhum interesting14:06
Fallenouit seems ARM can page fault for vmalloc area14:06
Fallenouhttp://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0198e/Babegida.html14:09
Fallenoubut there is a lockdown tlb14:10
Fallenouwhich could be used for exception stuff I guess14:10
Fallenouhttp://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344k/Biijbjie.html on Cortex A8 too14:16
Fallenouout to the movie, see you14:16
larsckristianpaul: undecided whether to leave or to stay today? ;)14:45
kristianpaullol14:47
kristianpaultroubles with my ipv6 tunnel afaik...14:47
wpwrakazonenberg: "I have a quad-monitor setup on my desk" nice ;-)22:42
azonenbergwpwrak: i'm actually about to get several more screens going but they're going out in the lab, not on my desk22:43
azonenbergyay tech-school dumpsters :D22:43
azonenbergsomebody threw out a half-dozen perfectly functional screens22:43
azonenberga little scuffed up, and low res (1024x768 or so) but still perfectly serviceable22:44
wpwrakah, that's what you meant when you said you were going dumpster diving :)22:44
azonenbergactually22:45
azonenbergthat was a while ago22:45
azonenbergwhat i got this last time was a 37U (yes, strange number - but we double checked the count) 4-post server rack on wheels22:45
azonenbergits former occupant, an SGI Origin 2000, had been retired22:45
wpwraki'm now at 3 x 1920x1080, plus a trust old 1024x768 off in the corner, connected to M122:45
azonenbergand the rack was sitting next to it in the dumpster22:45
azonenbergwell ok, next to the dumpster22:45
azonenbergso me and my roommate wheeled it half a mile across town and down a hill to the apartment lol22:46
azonenberghttp://i.imgur.com/uQsBK.jpg here it is halfway through being set up22:46
wpwrak;-))22:46
azonenbergthe green post-its mark where stuff is going to go22:46
azonenbergi'm trying to move the unused compute nodes and the switch that runs all of the currently unoccupied bedrooms first22:47
azonenbergthen the stuff that's in service last22:47
azonenbergRe my quad-mon, i have 3x 1920x1080 plus one 1280x80022:48
wpwraki see that you have a lot of rackable gadgets22:48
azonenbergyes i do lol22:48
azonenbergThe Sun cases at bottom are empty atm but i'm going to be building some stuff in them22:48
azonenbergone is going to turn into an FPGA-based VPN appliance22:48
azonenbergSo any last-minute suggestions on that s6 board?22:49
azonenberg(the TQFP one)22:49
azonenbergi'm doing a final CAM review on the gerbers now22:49
azonenbergmoving silkscreen text so it doesnt overlap pads etc22:50
wpwrakyou seem to have a dead-end GND trace on pin 7722:50
azonenbergof the fpga? looks fine to me22:52
wpwrakD12+R20 are not friendly for manual soldering22:52
azonenbergI expect this to be reflowed22:52
azonenbergtoaster ovens are cheap22:53
wpwraksome other items are also very close (on their head ends) for manual soldering22:53
wpwrakand unreliable22:53
azonenberg?22:53
azonenbergi've never had any yield issues on mine22:54
azonenbergat least not that i could trace to the temperature22:54
wpwrakyou used it "as is" or you added a temperature control circuit ?22:54
azonenbergAs is22:54
azonenbergmanual feedback22:54
azonenbergas in, turn the knob based on the color of the paste22:54
wpwrakmine just produces toasted pcbs22:54
wpwrakthey may actually work, but a) yield is horrible, and b) the pcb always has discoloration22:55
azonenberghttp://colossus.cs.rpi.edu/pictures/2012/June/6-7-2012%20-%20Spartan-6%20board/S7302765.JPG - done in a cheap toaster22:55
azonenbergconnectors were done by hand after22:55
azonenbergthis was reflowed on both sides22:55
azonenbergnote the dust, i used no-clean rosin flux and apparently didn't wash enough afterwards22:55
azonenbergso the thing is a dust magnet lol22:55
azonenbergi touched up one or two shorts (caused by too much paste) with an iron but it was otherwise all reflow22:56
wpwrakin theory, "no clean" should be just that ;-)22:56
azonenbergLol well it means it wont short your board if you leave it on22:56
azonenbergi think it looks nicer gone22:56
wpwrakdo you use a stencil ?22:56
azonenbergNo22:57
azonenbergjust the syringe and steel needle the paste was shipped in22:57
wpwrakyeah, no clean still leaves too much of a mess. i just use water soluble and leave the details to my ultrasound cleaner22:57
wpwrakhmm. do digi-key ship needles ? couldn't find one there whe i bought my solder paste some years ago, so i mistreated one from the pharmacy. doesn't apply things in the most clean way. i get lots of pads with issues and solder residues where they shouldn't be.22:59
azonenbergchipquik flux did have a single 20ga steel needle (blunt tip, not pointed)23:00
azonenbergand paste23:00
azonenbergi buy my needles from celeritous.com23:00
azonenbergi prefer 22ga blunt-tip because its slightly more precise23:00
azonenberg25ga was too fine and it didnt flow23:00
azonenbergcolor-accurate preview of bottom http://i.imgur.com/hCNLT.png23:01
azonenbergtop*23:01
wpwrakmove C9 and C10 a bit more out of each other's hair ?23:02
wpwrakand i would really separate D12 and R20. if anything goes wrong in the reflow, you'll have a bitch of a time getting there with a soldering iron23:03
wpwrakalso C15 and C27 are very close to the FPGA pins. again not rework-friendly23:04
azonenbergok, give me a min to play with those23:04
azonenbergi'm personally used to tight work23:04
wpwrakC33 also seems a little close to the QFN23:05
wpwrakyeah, i do it too. that's why i'm concerned about the pitfalls ;-)23:05
wpwrakbtw, why not move the text in the lower left corner to the upper right and shift the LED array all the way to the left. that way, you could have a 2x5 header with 8 I/Os and a bit more clearance to the JTAG connector as well23:06
azonenbergre c15/27 they're decouplers, i want them close23:08
wpwrakwhy not give them as much room as you're giving the other decouplers ?23:08
wpwrakjust a bit more23:09
azonenbergi guess23:09
azonenbergc15 cant move though23:09
azonenbergtoo much routing nearby23:09
azonenbergthe jtag connector has plenty of clearance23:10
wpwrak(C15) c'mon ;-)23:10
azonenbergit fits completely inside that silk footprint23:10
azonenbergbut hmm23:10
wpwrak(JTAG) i mean considering that you may want to hook scope probes and such directly to the the GPIO connector. it's nice to have a bit of room around such things23:11
azonenbergyeah23:12
azonenbergrerouting a bit23:12
wpwrakthe QFN will suck if it needs any rework23:12
wpwraknot only is C33 blocking a corner, but there's also a lot of ground there23:12
azonenbergyeah, i'm moving the led bank23:14
azonenberggive me a few mins23:14
wpwrakperhaps add a zone exclusion around U1 to have the heat traps further away. and it seems that you didn't connect the center pad23:15
wpwrakthe zone settings seem a but right anyway, with zone fill reaching in between center pad and pins.23:17
wpwrakthat's asking for trouble :)23:17
wpwrakfor a not too nasty board, i use 0.4 mm zone clearance and 0.2 mm minimum width. that keeps the zones from crawling into areas where they shouldn't be23:19
wpwrakfor a board that's already quite nasty to solder (atusb, with RF and all that fun), i have 10 mil (0.254 mm) for both23:20
wpwrakyou have 0.1524 mm. even tighter23:21
azonenbergi'm designing for 6/6 rules23:26
azonenbergand reflow23:26
wpwraki would just keep the ground zones further away23:26
azonenbergi guess23:26
wpwrakand i've never seen anyone put a zone fill between a qfn center pad and the pins. that's just begging for trouble.23:26
azonenbergthat was automatic23:27
azonenbergi'll fix that23:27
wpwrakyes, because your zones are too tight :)23:27
wpwrakthe mounting holes ... what's supposed to go into them ? nothing with screws, i suppose ?23:28
azonenberg4-40 screws with small heads23:28
azonenbergwhy?23:28
wpwrakare the heads really *that* small ?23:28
wpwrakyou have almost no room between hole and the edge of the copper ring23:29
azonenbergThe holes arent grounded23:29
wpwrakso either the hole is very wide or the ring very small23:29
azonenbergThe ring is very small23:29
azonenbergits not intended to be grounded23:29
azonenbergbut this process mandates all holes be plated23:29
azonenbergi think i have 254um clearance to the ground fill now23:30
wpwrakground is one thing. the other is shear force as your screw scrapes over the pcb, for example transferring the trace south of P2 to the afterlife23:30
azonenbergI moved it laready23:30
azonenbergscreenshot is old23:30
wpwraklemme generate a better one ...23:32
azonenbergi havent committed my most recent changes23:33
azonenberggive me a few mins23:33
azonenbergi'm used to working on 6/6 rules with tight registration23:35
wpwrakseems a bit excessive for this sort of circuit23:41
azonenbergthats what the fab i use does23:41
azonenbergand i'm used to working at those levels23:41
wpwrakjust checked the footprints ... good, you restrained yourself to no smaller than 0402 ;-)23:41
azonenberg0402 is the smallest i routinely use23:41
azonenbergi go down smaller only if forced to by spatial constraints (rare)23:41
wpwrak0402 is already more by instinct than vision :) but yes, manual soldering works remarkably well for being that small23:42
azonenbergno, its vision23:44
azonenbergi do them by hand under a microscope23:44
azonenbergthen reflow23:44
wpwrak(ambitious specs) i was thinking of this board being intended also for use by wolfgang. you don't know how good his pcb fab is. and he doesn't have a lot of DIY experience yet. so this may yield a board that may be very unpleasant to work with for him.23:45
azonenbergHmm, true23:45
wpwrakah yes, you have your fancy microscopes ;-)23:45
wpwraki just have instinct :)23:45
azonenbergi guess i just assumed you guys are operating at this level23:45
azonenbergi take it the M1 prototypes arent hand assembled then?>23:46
wpwraki do my pcbs in my kitchen :)23:46
azonenbergwell i do mine in the living room23:46
wpwrakah no, M1 is a bit different ;-)23:46
azonenbergthat doesnt say much considering my living room23:46
wpwrak(pcbs) i mean the etching :) layout transfer in my office, with good old toner transfer23:47
azonenbergi do photolith in my living room and have gotten to 6/6 traces, though 8/8 gives better yields23:47
wpwrakyeah. i find 8/8 a good compromise for DIY. it's small enough for all the components you'd reasonably expect to work with and it's still large enough to forgive some mistakes23:49
azonenbergwell, depends on what you define by "reasonably expect to work with"23:49
azonenbergi'm DIYing 256FTBGA in the living room (though on a professionally made PCB)23:49
wpwrakso far, i've limited myself to QFN :)23:50
azonenberghttp://colossus.cs.rpi.edu/pictures/2012/June/6-7-2012%20-%20Spartan-6%20board/S7302765.JPG23:51
azonenbergmy most recent board23:51
wpwrak(or MLF, which are a bit harder because they have no lateral metal. they're almost BGA, but just one ring of contacts.)23:51
azonenberghttp://colossus.cs.rpi.edu/pictures/2012/April/4-30-2012%20-%20Spartan6%20board/S7302710.JPG is the bare board23:51
azonenbergand the back side, chock full of 0402s http://colossus.cs.rpi.edu/pictures/2012/April/4-30-2012%20-%20Spartan6%20board/S7302711.JPG23:52
azonenbergpersonally i consider that perfectly doable as a DIY project23:52
wpwrakthe back is much cleaner :)23:53
azonenbergof the big one or the small one?23:53
wpwrakhmm, C39/C46 are the sort of think fabs frown upon ;-)23:53
wpwrakand C36 (?) fell off ?23:54
azonenbergdidnt fall off23:54
azonenbergit was never placed23:54
wpwrakah :)23:54
azonenbergthe fab screwed up and masked off the pad23:54
azonenbergluckily it was a noncritical decoupler23:54
azonenbergthe gerber is fine23:54
azonenbergC22 had the same defect23:54
wpwrak(masked off the pad) yeah, there are a few things in there that would be considered design violations23:55
azonenbergand C39/46 passed DRC and had good spacing23:55
azonenbergi just bridged them23:55
azonenbergbut they were paralleled anyway23:55
wpwrakDRC doens't find everything23:55
azonenbergso i didnt care23:56
wpwrakadam also lectured me on clearances on atben. which also passed DRC with flying flags :)23:56
azonenberglol23:56
azonenbergi also should have used 0201 for C39/4623:56
azonenbergsince they did have to be that close23:56
azonenberga smaller component would allow more clearance23:56
wpwrakwell, the cleaned up design had 100% yield for some 120 or 130 units. so i guess the advice was sound :)23:57
azonenberglol nice23:57
wpwrakwith atusb we weren't so lucky. about 3/120 didn't work. i think 2 pick and place errors (component missing) and one bad solder joint. still not too evil.23:57
azonenberghttp://imgur.com/a/F4tg2#023:58
azonenbergfinal gerber render23:58
kristianpaulvpn-fpga appliance, you planning using linux and mmio mapped fpga or implement tcp/ip stack from scratch in some custom rtos?23:58
azonenbergkristianpaul: from scratch23:58
azonenbergi do not want an OS whatsoever23:58
azonenbergjust a big state machine23:58
azonenbergprobably not a CPU either23:58
azonenbergthe goal is to be so simple as to be virtually unexploitable23:58
kristianpaultcp/ip is BIG :-)23:59
azonenbergbut guess what23:59
azonenbergUDP is small23:59
azonenbergand for a layer 2 VPN23:59
azonenbergyou just have to encapsulate ethernet frames in UDP packets23:59
azonenbergand encrypt them23:59
kristianpaulah cheating :)23:59
wpwrakC31/C32 are too close23:59
azonenbergI use openvpn over UDP now23:59
azonenbergbut its on linux23:59
azonenbergthe goal is to make something protocol-compatible but so simple as to be almost infallible23:59
azonenbergcompared to something like a cisco router23:59
--- Sun Jul 1 201200:00

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