lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs :: EHSM Berlin Dec 28-30 http://ehsm.eu :: latest video http://www.youtube.com/playlist?list=PL181AAD8063FCC9DC
<wolfspraul> short 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)
<wolfspraul> 'very simple' is something like an inverter, from one pad to another pad
<wolfspraul> then going up from there, a few more gates (slices), clocks, etc.
<wolfspraul> the longer term goal is to be able to synthesize the milkymist soc into something that runs on the chip
<Fallenou> what Xilinx tool would youreplace ?
<Fallenou> Xst ?
<wolfspraul> all
<wolfspraul> no, all
<Fallenou> oh :)
<wolfspraul> in fact I'm not at the Xst level and won't be for a while
<wolfspraul> hopefully there is something reusable in icarus verilog or elsewhere
<Fallenou> so you parse verilog, synth, map, place , route, and then generate bitstream from netlist ?
<azonenberg> wolfspraul: going to dumpster dive on campus for an hour or so
<azonenberg> if nobody has further suggestions i'll send gerbers out to the fab tonight
<azonenberg> should get 'em in ~3 weeks
<wpwrak> will they do something with the order during the weekend ?
<wpwrak> if not, perhaps wait until sunday, i case someone has further ideas
<wpwrak> s/i /in/
<wolfspraul> Fallenou: no, not at all
<wolfspraul> that is all far too much and too diverse
<wolfspraul> I work on the bitstream, and only that
<wolfspraul> I 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 chip
<wolfspraul> that's what I work on
<wolfspraul> the goal is to keep that first level as small and clearly focused as possible
<Fallenou> oh ok
<wolfspraul> it must be 100% stable, bug-free, etc.
<wolfspraul> (that's the goal)
<Fallenou> so you want to connect a few LUT together
<wolfspraul> not even that, at the beginning just an inverter between two pads
<Fallenou> you generate the bitstream that does that
<wolfspraul> but then a (one) slice, yes
<wolfspraul> then two slices
<wolfspraul> that already includes lots of routing
<wolfspraul> the inverter would only go to the ILOGIC/OLOGIC, through some switch boxes, and out the other pad
<wolfspraul> I start with that
<Fallenou> you will soon be an expert of FPGA internals :)
<wolfspraul> that's at least 50% of the value of the project for me
<wolfspraul> after 1 month I already start to feel better, but there are many more things to understand
<wolfspraul> let's see where it is in 2 months
<wolfspraul> I'm optimistic
<wolfspraul> 'inverter' though, ok?
<wolfspraul> milkymist soc is the longer term goal
<Fallenou> I started the MMU project in mid january, and it's not finish, all of these things take time
<Fallenou> speaking with "months" is the good granularity I think :)
<wpwrak> small 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 :)
<Fallenou> sure
<Fallenou> definitely
<Fallenou> is m1r4 still in the pipeline ? at least for a few samples ?
<Fallenou> I can see a few adam's emails from time to time :)
<Fallenou> which makes me think it's still in the pipe
<Fallenou> which is great :)
<wolfspraul> it won't take a decade
<wolfspraul> out now for a few hours, saturday family obligations
<wolfspraul> but, in good fallenou culture, my notebook goes with me and so go the s6 primitive schematics :-)
<wolfspraul> I try to isolate the chip-specific knowledge in the smallest possible tool/code
<wolfspraul> on 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/routing
<wolfspraul> but that problem can and should be addressed in a chip-agnostic way
<wolfspraul> I talk about it more when something actually works, i.e. not now :-)
<wolfspraul> if I have the inverter running on my desk in 2 months I'm happy
<wpwrak> hmm, the vias under the FPGA will be hard for a DIY FPGA
<wpwrak> s/DIY FPGA/DIY PCB/
<Fallenou> good saturday wolfspraul :)
<wolfspraul> is there a free tool for schematic entry of a chip?
<wolfspraul> I started to do drawings in svg but it's too raw and wasting time
<wolfspraul> maybe I use kicad
<wolfspraul> the purpose is to document primitive or parts-of-primitives schematics
<wolfspraul> vias under fpga?
<wolfspraul> don't understand
<wolfspraul> you mean azonenberg's board has some vias there? haven't checked yet
<wolfspraul> one by one :-)
<wpwrak> yes, he has vias under the fpga. this means that you have to make them VERY flat
<wpwrak> not taller than 0.1 mm
<wolfspraul> sure, or I modify the board, or I de-couple the diy-pcb and fpgatools a little and just fab it somewhere locally
<wolfspraul> I can probably get this made in 2 days, in horrible sloppy quality then I can learn about testing and fixing pcbs :-)
<wpwrak> yup. all viable options
<wpwrak> ;-))
<wolfspraul> in the end it all comes around to knowledge and quickly picking what one really needs
<wpwrak> sure. the only thing is that you don't learn how to make DIY-friendly layouts this way
<wpwrak> but yes, everything has its price ;)
<Fallenou> hum hum my first relocated calli seems to be OK
<Fallenou> second one ok too
* 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 instruction
<Fallenou> arg fucking moskito
<wpwrak> gas 'em :)
<Fallenou> it's dead
<Fallenou> the shoe shoot
<wpwrak> may its rotten soul burn in hell ;-)
<Fallenou> amen !
<Fallenou> nice !
<Fallenou> relocating on-the-fly non-PIC code works :)
<Fallenou> I have the void f(void) { puts("@"); } working
<Fallenou> the code of f() contains 9 CALLI =)
<Fallenou> puts got inlined
<Fallenou> all 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"
<Fallenou> output is kind of messy because I don't think the puts/printf stuff are re-entrant :p
<Fallenou> I mean the ITLB/DTLB exception handler is using printf and puts
<Fallenou> so I guess bad things happen if puts or printf cause the DTLB/ITLB exception :)
<Fallenou> a puts while putsing ...
<wpwrak> hmm. use write() ?
<Fallenou> yes I should use more low level stuff in exception handlers
<Fallenou> untill now it didn't make any problem
<Fallenou> so it was good enough :)
* Fallenou uses crappy code, unless it makes real problems
km2 has quit [Ping timeout: 276 seconds]
<Fallenou> ok awesome, it works really well (in ISim) if I comment puts/printf from DTLB/ITLB exception handlers
<Fallenou> I can still see the exceptions happening because of a $display() in verilog code anyway :)
km2 has joined #milkymist
<Fallenou> wpwrak wolfspraul lekernel http://pastebin.com/kqcaKT8w :)
<Fallenou> a nice ITLB test with relocation, the assembly code of the function (f) being relocated, the ISim simulator output
<Fallenou> all mmu mappings are "lazy" ones, nothing is really mapped untill there is a page fault
<Fallenou> in the simulation you can see a few page faults
<wpwrak> whee !
<wpwrak> now let's see what it does on the real iron :)
* Fallenou fears
<Fallenou> I bet it won't run, bah
<Fallenou> but let's try anyway
<Fallenou> damn it
<Fallenou> wpwrak: on the FPGA, puts() is in the NAND at address 0x0086777C
<Fallenou> and I relocate f() at virtual address 0x44004000
<Fallenou> I can't calli this far :(
<Fallenou> the jump offset is too high
<wpwrak> write your own uart-writing loop
<wpwrak> that way, you also avoid weird effects from libc
<Fallenou> I tried again with just writting to uart RX_TX reg instead of calling puts() in f()
<Fallenou> and therefore without any rewritting any calli instr
<Fallenou> and without puts/printf in dtlb/itlb handlers
<Fallenou> and it still crashes
<Fallenou> let's try running the original f() without copying it
sh4rm4 has quit [Ping timeout: 276 seconds]
<wpwrak> are there any other pc-relative items ? such as a long pointer ?
sh4rm4 has joined #milkymist
<wpwrak> and ... can't you just compile with -fPIC ?
<Fallenou> maybe, I just did not try :p (-fPIC)
<Fallenou> I don't know exactly how it works (-fPIC)
<Fallenou> ok even running the f() from 0x86777C (nand) it still crashes
<Fallenou> so no PIC problem involved here
<azonenberg> wpwrak, wolfspraul: i designed the board for the oshpark.com 2-layer process
<azonenberg> $5/in^2 gets you three units
<azonenberg> it'd be around $8 per blank board at that rate
<azonenberg> with a ~3 week lead time
<azonenberg> at least, that's the design rules i used and thts where i'll be making the prototype
<Fallenou> compiling with -fPIC seems to produce something interesting, all calli are basically gone, replaced by call rX with rX loaded from memory
<Fallenou> I guess lm32-gcc does PIC correctly
<wpwrak> Fallenou: see :)
<Fallenou> but I am not sure my problem was PIC :p
<wpwrak> azonenberg: PCBs for the patient ;-)
<azonenberg> wpwrak: well most of my stuff is 4 layers
<azonenberg> and i cant make that in house
<azonenberg> its also 6/6 mil design rules, decently small vias, ENIG finish, silk, soldermask
<azonenberg> totally worth the wait
<Fallenou> wpwrak: bios does not even boot, compiled with -fPIC :'
<Fallenou> it prints "SDRAM initialization completed, boot continuing" and then nothing
<Fallenou> maybe I need to hack the linker script a little bit, maybe I need to add a few sections
<Fallenou> like .got
<Fallenou> and .got.plt
<Fallenou> ok now it boots :)
<Fallenou> still crashing when running f()
<Fallenou> 4h30 am here, going to sleep, gn8 !
<Fallenou> we should drop the FPGA from the M1, put an Intel X86, run ISim with Milkymist SoC :)
<Fallenou> mmu works better in ISim :p
* Fallenou goes to bed singing "trololololo"
sh4rm4 has quit [Ping timeout: 276 seconds]
aeris has quit [Ping timeout: 244 seconds]
sh4rm4 has joined #milkymist
aeris has joined #milkymist
rejon has joined #milkymist
azonenberg has quit [Ping timeout: 245 seconds]
sh4rm4 has quit [Ping timeout: 276 seconds]
azonenberg has joined #milkymist
rejon has quit [Ping timeout: 250 seconds]
mumptai has joined #milkymist
mumptai has quit [Client Quit]
mumptai has joined #milkymist
mumptai has quit [Client Quit]
mumptai has joined #milkymist
rejon has joined #milkymist
Gurty has quit [Ping timeout: 265 seconds]
sh4rm4 has joined #milkymist
lekernel has quit [Ping timeout: 248 seconds]
lekernel has joined #milkymist
<lekernel> huh, yes, the relocate is a bit messy
<lekernel> why not just a function that writes to the UART without any libc call?
<lekernel> Fallenou:
<lekernel> CSR_UART_RXTX = '@';
<lekernel> while(!(CSR_UART_STAT & UART_STAT_THRE));
<lekernel> that's all
<lekernel> and no interrupts etc.
<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)
<lekernel> and you loop on that if you want to write a string
<lekernel> speaking of interrupts, does it correctly store the virtual address for return when an interrupt occurs with the MMU enabled? that might be your problem
<lekernel> but i'd start by getting it to work without any interrupt involved
rejon has quit [Ping timeout: 246 seconds]
<Fallenou> lekernel: yes for both simulation and real fpga stuff I disactivate interrupts in the main()
<Fallenou> and uart is used in polled mode
<Fallenou> but yes indeed I should not call libc stuff from exception handler and from my f() function running in virtual addressing
<Fallenou> it's just painfull to directly use CSR_UART_RXTX
<Fallenou> and even more if you want to have a printf() like functionnality :p
sh4rm4 has quit [Ping timeout: 276 seconds]
<Fallenou> lekernel: 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 ok
<Fallenou> it works for page faults
<Fallenou> it should work the same for irq
<Fallenou> but for now I disabled irq ^^
<Fallenou> something 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 mode
<Fallenou> I should just add a backup reg
<Fallenou> if an exception*
<roh> can exceptions happen in its handlers?
<Fallenou> heh I am wondering the same thing
<Fallenou> I think nested exceptions are allowed here
<roh> maybe a stupid question.. but i am trying to understand ;)
<Fallenou> so it will be a pain
<roh> irgh. well.. fun!!1!
* Fallenou opens lm32 datasheet
<Fallenou> it's kind of blury
<Fallenou> datasheet says "limitd nesting exception is possible"
<Fallenou> limited*
<Fallenou> it says that more advanced nesting needs software help
<Fallenou> not very usefull
<Fallenou> because if I'm in the *TLB handler (an exception handler), and I get an incomming IRQ (another exception) it could be bad
<Fallenou> oh there is a paragraph about nested exceptions (another one)
<Fallenou> one mess at a time :'
rejon has joined #milkymist
kilae has joined #milkymist
<lekernel> try with CSR_UART_RXTX firs
<lekernel> t
<lekernel> it's not painful, just 2 lines of code
<Fallenou> lekernel: I just tried with CSR_UART_RXTX = '@'; while(!(CSR_UART_STAT & UART_STAT_THRE));
<Fallenou> it still crash
<Fallenou> I don't believe my troubles come from uart stuff
<Fallenou> I guess it's some pipeline timing problem
<Fallenou> http://pastebin.com/V7zpUXUE < if I don't do lazy mapping for ITLB it works quite well :)
<Fallenou> this is on FPGA
<Fallenou> if I do lazy mapping it prints "Mapping DONE" and hangs
sh4rm4 has joined #milkymist
sh4rm4 has quit [Ping timeout: 276 seconds]
sh4rm4 has joined #milkymist
wolfspraul has quit [Quit: leaving]
wolfspraul has joined #milkymist
<wpwrak> you 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 mess
<lekernel> yeah
<wpwrak> (apply) a nice instant portability barrier ;-)
<Fallenou> hehe yes I agree
<Fallenou> but a nice technical solution
<lekernel> and 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)
<Fallenou> a nice geeky code
<Fallenou> (disable irq during itlb handler) yes agreed
<wpwrak> you 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 fine
<wpwrak> (mmu) we'll also need a way to enable the MMU while in kernel mode, for things like vmalloc
<lekernel> huh? that would be messy... kernel mode == MMU disabled
<lekernel> microblaze does it that way... so it's possible
<wpwrak> you'd lose the functions that avoid trouble with memory fragmentation. you should be able to fall back to the non-MMU functions, though
<wpwrak> ah, 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" ?
<lekernel> reading the page table from sw looks simpler
<Fallenou> I agree with lekernel
<Fallenou> kernel == user mode
<Fallenou> and accessing user land memory is done by accessing physical address (doing the lookup in software)
<Fallenou> wpwrak: why would the kernel need to allocate virtual memory if it's not for a processus context ?
* Fallenou is not an expert of the linux kernel
<Fallenou> could you elaborate about vmalloc ?
<Fallenou> how does it work in x86 ? the kernel activates the MMU even in kernel land when it needs to access "kernel virtual memory" ?
<wpwrak> yes. MMU and kernel mode are decoupled. so you can choose whether you want to have the MMU on or not.
<Fallenou> oh
<Fallenou> ok I didn't know that
<wpwrak> vmalloc 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 them
<wpwrak> linEar
<Fallenou> on my x86 desktop computer mmu is ON while kernel is running a syscall ?
<wpwrak> this 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 fragmentation
<wpwrak> but - as long as there is any memory left at all - you can always allocate a single page
<Fallenou> yes ok
<Fallenou> I understand it helps if you can use virtually contiguous memory
<Fallenou> I guess I would need to read a bit of this www.kernel.org/doc/gorman/pdf/understand.pdf
<wpwrak> so defensively written kernel code allocates things > 4 kB either with vmalloc or has its own strategy to break the allocation down into smaller pieces
<wpwrak> lemme check how the MMU is switched on x86 ...
* wpwrak blows dust from a big old book
<Fallenou> hehe :)
<Fallenou> I wonder how openrisc does to manage mmu_on/off
* Fallenou will have a look
<kristianpaul> cant just be always on?
<Fallenou> well I can do that, it's even easier for me :)
<Fallenou> boots with mmu off, and you can manually (with asm instr) activate/disactivate it, and it never changes by itself
<Fallenou> if this is OK I'm very happy =)
<Fallenou> that would mean mapping exception vectors in the mmu but .... why not !
<Fallenou> opencores website is down =(
<Fallenou> when you need it ... !
<larsc> as far as I can see microblaze on linux has support for virtual memory in kernel mode
<kristianpaul> what this mean in mmu terms? (sorru mmu noob here trying yo understand)
<kristianpaul> sorry*
<larsc> that the mmu needs to be on
<kristianpaul> always?
<Fallenou> kristianpaul: I mean if mmu is always on, you need to map CPU exception vectors (divide by zero, interrupt, page fault) to virtual memory
<Fallenou> since they will be accessed through virtual memory (because mmu is ALWAYS on)
<larsc> Fallenou: you could have a memory region which has always a direct mapping
<larsc> which is as far as I know what is usually done
<kristianpaul> Fallenou: that sounds like more "safe" to me
<Fallenou> yes that would mean redesigning the mmu :'
<kristianpaul> wich is good i think
<wpwrak> wormed 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.
<Fallenou> I will have a look at Cortex A8 datasheet
<wpwrak> the 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 TLB
<larsc> wpwrak: I don't think you want to take the i386 as an example for anything ;) unless it's as a bad example
<Fallenou> well 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 you
<wpwrak> i.e., you set up your page tables in memory and tell the MMU where they start. then the hardware takes care of the rest.
<Fallenou> yes sure
<Fallenou> but I won't do such a thing
<wpwrak> larsc: yeah, "protected mode" is phenomenally perverse ;-) i already tried to leave out the nasty bits in my summary
<larsc> if you want to do fast context switches you also want to avoid having to flush the caches on a context switch
<Fallenou> it's too much work and it will blow the cpu performance
<wpwrak> you 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.
<larsc> here is a paper how that was implemented on ARM: https://lwn.net/images/conf/rtlws11/papers/proc/p01.pdf
<Fallenou> yes I saw this paper, I read parts of it
<Fallenou> I don't remember why but I ruled this implementation out :o
<Fallenou> I didn't like the PID stuff I guess
<Fallenou> it forces you to have a special virtual memory mapping for user processes
<Fallenou> and it limits the number of processes
<Fallenou> but it's definitely worth re-reading
<Fallenou> thanks
<wpwrak> kernel/user mode protection would basically use the same exception path as writing to a read-only page
<Fallenou> hum hum http://lxr.linux.no/#linux+v3.4.4/arch/x86/mm/fault.c
<Fallenou> they have a special handler for vmalloc faults
<Fallenou> but they specifically say "a page fault in the kernel is not normal we should OOPS"
<Fallenou> it'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 fault
<Fallenou> http://lxr.linux.no/#linux+v3.4.4/arch/arm/mm/fault.c#L400
<Fallenou> hum interesting
<Fallenou> it seems ARM can page fault for vmalloc area
<Fallenou> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0198e/Babegida.html
<Fallenou> but there is a lockdown tlb
<Fallenou> which could be used for exception stuff I guess
<Fallenou> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344k/Biijbjie.html on Cortex A8 too
<Fallenou> out to the movie, see you
kristianpaul has quit [Quit: leaving]
kristianpaul has joined #milkymist
kristianpaul has joined #milkymist
sh4rm4 has quit [Ping timeout: 276 seconds]
Fallenou has quit [Remote host closed the connection]
Fallenou has joined #milkymist
kristianpaul has quit [Quit: Reconnecting]
kristianpaul has joined #milkymist
kristianpaul has joined #milkymist
<larsc> kristianpaul: undecided whether to leave or to stay today? ;)
<kristianpaul> lol
<kristianpaul> troubles with my ipv6 tunnel afaik...
mumptai has quit [Read error: Connection reset by peer]
sh4rm4 has joined #milkymist
mumptai has joined #milkymist
sh4rm4 has quit [Ping timeout: 276 seconds]
sh4rm4 has joined #milkymist
kristianpaul has quit [Remote host closed the connection]
kristianpaul has joined #milkymist
kristianpaul has quit [Ping timeout: 272 seconds]
kristianpaul has joined #milkymist
kristianpaul has joined #milkymist
sh4rm4 has quit [Ping timeout: 276 seconds]
sh4rm4 has joined #milkymist
sh4rm4 has quit [Ping timeout: 276 seconds]
sh4rm4 has joined #milkymist
Gurty has joined #milkymist
cozy has joined #milkymist
cozy is now known as cozyspell
methril has joined #milkymist
hypermodern has joined #milkymist
hypermodern has left #milkymist [#milkymist]
sh4rm4 has quit [Ping timeout: 276 seconds]
sh4rm4 has joined #milkymist
wolfspra1l has joined #milkymist
wolfspraul has quit [Ping timeout: 245 seconds]
kilae has quit [Quit: ChatZilla 0.9.88.2 [Firefox 13.0.1/20120614114901]]
<wpwrak> azonenberg: "I have a quad-monitor setup on my desk" nice ;-)
<azonenberg> wpwrak: i'm actually about to get several more screens going but they're going out in the lab, not on my desk
<azonenberg> yay tech-school dumpsters :D
<azonenberg> somebody threw out a half-dozen perfectly functional screens
<azonenberg> a little scuffed up, and low res (1024x768 or so) but still perfectly serviceable
<wpwrak> ah, that's what you meant when you said you were going dumpster diving :)
mumptai has quit [Ping timeout: 246 seconds]
<azonenberg> actually
<azonenberg> that was a while ago
<azonenberg> what i got this last time was a 37U (yes, strange number - but we double checked the count) 4-post server rack on wheels
<azonenberg> its former occupant, an SGI Origin 2000, had been retired
<wpwrak> i'm now at 3 x 1920x1080, plus a trust old 1024x768 off in the corner, connected to M1
<azonenberg> and the rack was sitting next to it in the dumpster
<azonenberg> well ok, next to the dumpster
<azonenberg> so me and my roommate wheeled it half a mile across town and down a hill to the apartment lol
<azonenberg> http://i.imgur.com/uQsBK.jpg here it is halfway through being set up
<wpwrak> ;-))
<azonenberg> the green post-its mark where stuff is going to go
<azonenberg> i'm trying to move the unused compute nodes and the switch that runs all of the currently unoccupied bedrooms first
<azonenberg> then the stuff that's in service last
<azonenberg> Re my quad-mon, i have 3x 1920x1080 plus one 1280x800
<wpwrak> i see that you have a lot of rackable gadgets
<azonenberg> yes i do lol
<azonenberg> The Sun cases at bottom are empty atm but i'm going to be building some stuff in them
<azonenberg> one is going to turn into an FPGA-based VPN appliance
<azonenberg> So any last-minute suggestions on that s6 board?
<azonenberg> (the TQFP one)
<azonenberg> i'm doing a final CAM review on the gerbers now
<azonenberg> moving silkscreen text so it doesnt overlap pads etc
<wpwrak> you seem to have a dead-end GND trace on pin 77
<azonenberg> of the fpga? looks fine to me
<wpwrak> D12+R20 are not friendly for manual soldering
<azonenberg> I expect this to be reflowed
<azonenberg> toaster ovens are cheap
<wpwrak> some other items are also very close (on their head ends) for manual soldering
<wpwrak> and unreliable
<azonenberg> ?
<azonenberg> i've never had any yield issues on mine
<azonenberg> at least not that i could trace to the temperature
<wpwrak> you used it "as is" or you added a temperature control circuit ?
<azonenberg> As is
<azonenberg> manual feedback
<azonenberg> as in, turn the knob based on the color of the paste
<wpwrak> mine just produces toasted pcbs
<wpwrak> they may actually work, but a) yield is horrible, and b) the pcb always has discoloration
<azonenberg> connectors were done by hand after
<azonenberg> this was reflowed on both sides
<azonenberg> note the dust, i used no-clean rosin flux and apparently didn't wash enough afterwards
<azonenberg> so the thing is a dust magnet lol
<azonenberg> i touched up one or two shorts (caused by too much paste) with an iron but it was otherwise all reflow
<wpwrak> in theory, "no clean" should be just that ;-)
<azonenberg> Lol well it means it wont short your board if you leave it on
<azonenberg> i think it looks nicer gone
<wpwrak> do you use a stencil ?
<azonenberg> No
<azonenberg> just the syringe and steel needle the paste was shipped in
<wpwrak> yeah, no clean still leaves too much of a mess. i just use water soluble and leave the details to my ultrasound cleaner
<wpwrak> hmm. 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.
<azonenberg> chipquik flux did have a single 20ga steel needle (blunt tip, not pointed)
<azonenberg> and paste
<azonenberg> i buy my needles from celeritous.com
<azonenberg> i prefer 22ga blunt-tip because its slightly more precise
<azonenberg> 25ga was too fine and it didnt flow
<azonenberg> color-accurate preview of bottom http://i.imgur.com/hCNLT.png
<azonenberg> top*
<wpwrak> move C9 and C10 a bit more out of each other's hair ?
<wpwrak> and 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 iron
<wpwrak> also C15 and C27 are very close to the FPGA pins. again not rework-friendly
<azonenberg> ok, give me a min to play with those
<azonenberg> i'm personally used to tight work
<wpwrak> C33 also seems a little close to the QFN
<wpwrak> yeah, i do it too. that's why i'm concerned about the pitfalls ;-)
<wpwrak> btw, 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 well
lekernel_ has joined #milkymist
lekernel has quit [Ping timeout: 252 seconds]
<azonenberg> re c15/27 they're decouplers, i want them close
<wpwrak> why not give them as much room as you're giving the other decouplers ?
<wpwrak> just a bit more
<azonenberg> i guess
<azonenberg> c15 cant move though
<azonenberg> too much routing nearby
<azonenberg> the jtag connector has plenty of clearance
<wpwrak> (C15) c'mon ;-)
<azonenberg> it fits completely inside that silk footprint
<azonenberg> but hmm
<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 things
<azonenberg> yeah
<azonenberg> rerouting a bit
<wpwrak> the QFN will suck if it needs any rework
<wpwrak> not only is C33 blocking a corner, but there's also a lot of ground there
<azonenberg> yeah, i'm moving the led bank
<azonenberg> give me a few mins
<wpwrak> perhaps add a zone exclusion around U1 to have the heat traps further away. and it seems that you didn't connect the center pad
<wpwrak> the zone settings seem a but right anyway, with zone fill reaching in between center pad and pins.
<wpwrak> that's asking for trouble :)
<wpwrak> for 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 be
<wpwrak> for a board that's already quite nasty to solder (atusb, with RF and all that fun), i have 10 mil (0.254 mm) for both
<wpwrak> you have 0.1524 mm. even tighter
<azonenberg> i'm designing for 6/6 rules
<azonenberg> and reflow
<wpwrak> i would just keep the ground zones further away
<azonenberg> i guess
<wpwrak> and i've never seen anyone put a zone fill between a qfn center pad and the pins. that's just begging for trouble.
<azonenberg> that was automatic
<azonenberg> i'll fix that
<wpwrak> yes, because your zones are too tight :)
<wpwrak> the mounting holes ... what's supposed to go into them ? nothing with screws, i suppose ?
<azonenberg> 4-40 screws with small heads
<azonenberg> why?
<wpwrak> are the heads really *that* small ?
<wpwrak> you have almost no room between hole and the edge of the copper ring
<azonenberg> The holes arent grounded
<wpwrak> so either the hole is very wide or the ring very small
<azonenberg> The ring is very small
<azonenberg> its not intended to be grounded
<azonenberg> but this process mandates all holes be plated
<azonenberg> i think i have 254um clearance to the ground fill now
<wpwrak> ground 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 afterlife
<azonenberg> I moved it laready
<azonenberg> screenshot is old
<wpwrak> lemme generate a better one ...
<azonenberg> i havent committed my most recent changes
<azonenberg> give me a few mins
<azonenberg> i'm used to working on 6/6 rules with tight registration
<wpwrak> seems a bit excessive for this sort of circuit
<azonenberg> thats what the fab i use does
<azonenberg> and i'm used to working at those levels
<wpwrak> just checked the footprints ... good, you restrained yourself to no smaller than 0402 ;-)
<azonenberg> 0402 is the smallest i routinely use
<azonenberg> i go down smaller only if forced to by spatial constraints (rare)
<wpwrak> 0402 is already more by instinct than vision :) but yes, manual soldering works remarkably well for being that small
<azonenberg> no, its vision
<azonenberg> i do them by hand under a microscope
<azonenberg> then reflow
<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.
<azonenberg> Hmm, true
<wpwrak> ah yes, you have your fancy microscopes ;-)
<wpwrak> i just have instinct :)
<azonenberg> i guess i just assumed you guys are operating at this level
<azonenberg> i take it the M1 prototypes arent hand assembled then?>
<wpwrak> i do my pcbs in my kitchen :)
<azonenberg> well i do mine in the living room
<wpwrak> ah no, M1 is a bit different ;-)
<azonenberg> that doesnt say much considering my living room
<wpwrak> (pcbs) i mean the etching :) layout transfer in my office, with good old toner transfer
<azonenberg> i do photolith in my living room and have gotten to 6/6 traces, though 8/8 gives better yields
<wpwrak> yeah. 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 mistakes
<azonenberg> well, depends on what you define by "reasonably expect to work with"
<azonenberg> i'm DIYing 256FTBGA in the living room (though on a professionally made PCB)
<wpwrak> so far, i've limited myself to QFN :)
<azonenberg> my most recent board
<wpwrak> (or MLF, which are a bit harder because they have no lateral metal. they're almost BGA, but just one ring of contacts.)
<azonenberg> personally i consider that perfectly doable as a DIY project
<wpwrak> the back is much cleaner :)
<azonenberg> of the big one or the small one?
<wpwrak> hmm, C39/C46 are the sort of think fabs frown upon ;-)
<wpwrak> and C36 (?) fell off ?
<azonenberg> didnt fall off
<azonenberg> it was never placed
<wpwrak> ah :)
<azonenberg> the fab screwed up and masked off the pad
<azonenberg> luckily it was a noncritical decoupler
<azonenberg> the gerber is fine
<azonenberg> C22 had the same defect
<wpwrak> (masked off the pad) yeah, there are a few things in there that would be considered design violations
<azonenberg> and C39/46 passed DRC and had good spacing
<azonenberg> i just bridged them
<azonenberg> but they were paralleled anyway
<wpwrak> DRC doens't find everything
<azonenberg> so i didnt care
<wpwrak> adam also lectured me on clearances on atben. which also passed DRC with flying flags :)
<azonenberg> lol
<azonenberg> i also should have used 0201 for C39/46
<azonenberg> since they did have to be that close
<azonenberg> a smaller component would allow more clearance
<wpwrak> well, the cleaned up design had 100% yield for some 120 or 130 units. so i guess the advice was sound :)
<azonenberg> lol nice
<wpwrak> with 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.
<azonenberg> final gerber render
<kristianpaul> vpn-fpga appliance, you planning using linux and mmio mapped fpga or implement tcp/ip stack from scratch in some custom rtos?
<azonenberg> kristianpaul: from scratch
<azonenberg> i do not want an OS whatsoever
<azonenberg> just a big state machine
<azonenberg> probably not a CPU either
<azonenberg> the goal is to be so simple as to be virtually unexploitable
<kristianpaul> tcp/ip is BIG :-)
<azonenberg> but guess what
<azonenberg> UDP is small
<azonenberg> and for a layer 2 VPN
<azonenberg> you just have to encapsulate ethernet frames in UDP packets
<azonenberg> and encrypt them
<kristianpaul> ah cheating :)
<wpwrak> C31/C32 are too close
<azonenberg> I use openvpn over UDP now
<azonenberg> but its on linux
<azonenberg> the goal is to make something protocol-compatible but so simple as to be almost infallible
<azonenberg> compared to something like a cisco router