lekernel | azonenberg, to answer my earlier PLL clock switching question from a while ago: it seems you can use PLL_ADV on spartan6 - even if it's undocumented - and this primitives makes a clock multiplexer built into the PLL appear | 15:09 |
---|
azonenberg | davidc__: it's a little more complex than that | 02:11 |
---|---|---|
azonenberg | I'm doing CPLDs to start out since the structure is more regular | 02:11 |
azonenberg | And mostly black-boxing "this HDL makes this output" etc | 02:11 |
azonenberg | the silicon analysis is mostly to confirm hypotheses i can't easily test otherwise | 02:11 |
davidc__ | azonenberg: you're part of that homeCMOS thing eh? Is that still alive? | 21:21 |
---|---|---|
azonenberg | davidc__: It's going slowly since i have a lot of stuff on my plate | 23:49 |
azonenberg | i am still interested in doing it | 23:49 |
davidc__ | azonenberg: cool. Yeah, I might be looking at some stuff related to that (looking at generating plasmas for etching / etc) | 23:50 |
azonenberg | Ooh | 23:52 |
azonenberg | You want to do RIE or sputtering? | 23:52 |
davidc__ | azonenberg: RIE to complement my SEM | 23:52 |
azonenberg | ooh | 23:52 |
azonenberg | very nice | 23:52 |
azonenberg | I'm REing the XC2C32A, not sure if anyone mentioned | 23:53 |
azonenberg | i have SEM cross sections and a low-res optical top metal image | 23:53 |
azonenberg | as well as about 90% of the bitstream figured out | 23:53 |
azonenberg | working toward a full transistor-level analysis of it | 23:53 |
azonenberg | lekernel: re your PLL problems | 18:31 |
---|---|---|
azonenberg | what are you trying to mux? | 18:31 |
azonenberg | xilinx has an appnote on dynamic pll reconfiguration if it comes to that | 18:31 |
azonenberg | but that's for changing multipliers and stuff | 18:31 |
azonenberg | So why will a BUFGMUX not work? | 18:32 |
azonenberg | not enough BUFGs? | 18:32 |
azonenberg | i'm thinking {IBUFG_1, IBUFG_2} -> BUFGMUX -> PLL | 18:32 |
azonenberg | But that has nothign to do with muxing | 18:32 |
azonenberg | In any case, three BUFGs is a serious cost | 18:32 |
azonenberg | considering you only have 16 | 18:32 |
azonenberg | Since this is source-synchronous data you need to preserve phase | 18:33 |
azonenberg | An IBUF doesnt use dedicated routing, afaik | 18:33 |
azonenberg | (compared to an IBUFG) | 18:33 |
azonenberg | lekernel: Yes, i know | 18:34 |
azonenberg | Hmm | 18:34 |
azonenberg | oh | 18:34 |
azonenberg | Where are your clock inputs located? | 18:34 |
azonenberg | what pins on which chip? | 18:34 |
azonenberg | So, if you want to use one BUFGMUX | 18:35 |
azonenberg | You are going to be routing the clocks from two different pins to one BUFGMUX | 18:36 |
azonenberg | the dedicated routing may not exist | 18:36 |
azonenberg | if you do two BUFGs it will definitely work | 18:36 |
azonenberg | What are the clock net names? | 18:37 |
azonenberg | How many clock domains are you using in total? | 18:37 |
azonenberg | and how many muxes do you need? | 18:37 |
azonenberg | So you need a two 4:1 clock muxes... | 18:38 |
azonenberg | so inputs 1/2 are muxed to output 1 etc? | 18:39 |
azonenberg | and 3/4 are muxed to 2? | 18:39 |
azonenberg | So if you have a BUFG for each of the 4 inputs | 18:39 |
azonenberg | then two BUFGMUXs | 18:39 |
azonenberg | that's six total | 18:40 |
azonenberg | do you have enough to spare that many? | 18:40 |
azonenberg | Including the two muxed clocks? | 18:40 |
azonenberg | or not | 18:40 |
azonenberg | Either way, if it fits | 18:40 |
azonenberg | Then problem solved | 18:40 |
azonenberg | I'm actually in the middle of debugging myself... been hunting this one on and off for ten days | 18:41 |
azonenberg | my ethernet subsystem randomly stops processing frames after a while | 18:41 |
azonenberg | as best i can tell it's blocking waiting for a DMA-done acknowledgement from RAM, but the RAM thinks it sent the ack | 18:41 |
azonenberg | so it's getting dropped somewhere and i haven't yet found where | 18:41 |
azonenberg | the same pll? | 18:42 |
azonenberg | hmm... another bufg? :p | 18:42 |
azonenberg | no, too fast for that | 18:42 |
azonenberg | DCM jitter is obvs way too high for this | 18:42 |
azonenberg | I assume it's too late to go to 7 series? | 18:43 |
azonenberg | artix7 has way more plls | 18:43 |
azonenberg | (and 32 global clocks) | 18:43 |
azonenberg | afaik, "one PLL to one BUFPLL" is the only possible config | 18:44 |
azonenberg | i think the BUFPLL is physically wired directly to the PLL and you either use it or don't | 18:45 |
azonenberg | I didn't think that was possible | 18:45 |
azonenberg | i thought you were supposed to use the pll right next to that bnak | 18:46 |
azonenberg | bank* | 18:46 |
azonenberg | hmm, sec | 18:46 |
azonenberg | UG382... there are two BUFPLLs per bank | 18:46 |
azonenberg | Read UG382 page 53 | 18:47 |
azonenberg | doesnt answer all the questions but provides some insight | 18:47 |
azonenberg | looking at the routing in fpga_editor might be of help too | 18:48 |
azonenberg | Btw, if you read the table on page 54 | 18:56 |
azonenberg | it looks like CLKOUT0 and CLKOUT1 of the PLL are the only ones that can drive BUFPLLs | 18:56 |
azonenberg | Hey, is there any info posted on the current resource usage of various cores? | 14:43 |
---|---|---|
azonenberg | from like a map -detail | 14:43 |
davidc__ | BTW - anyone looked at TORC? (http://torc-isi.sourceforge.net/subversion.php) azonenberg; might be of interest to you. | 00:11 |
---|---|---|
azonenberg | lekernel: 1080p video using what interface? | 14:38 |
azonenberg | that hacked-up QDR setup on spartan6? | 14:39 |
lekernel | azonenberg, VGA | 14:39 |
azonenberg | lekernel: oh, lol | 14:39 |
azonenberg | So parallel 24-bit data to a DAC? | 14:39 |
azonenberg | Hawk777: is it non-copyleft open source? | 01:02 |
---|---|---|
azonenberg | My entire SoC is BSD and i'm hoping to keep it that way | 01:02 |
azonenberg | My build system can optionally link with a GPL'd library and be dual-licensed | 01:03 |
azonenberg | But otherwise is pure BSD, all of the RTL is BSD too | 01:03 |
Hawk777 | azonenberg: not sure what GRLIBs license is; you should check it yourself. I dont need to know as Im only using it in stuff that will probably never be released anyway. | 07:44 |
azonenberg | I see | 07:45 |
azonenberg | I'll look into it | 07:45 |
azonenberg | I need to learn more hard number-theory math anyway | 07:45 |
azonenberg | and opencores has a complete lack of elliptic curve stuff last i looked | 07:45 |
azonenberg | even the RSA modules they had were horrible | 07:45 |
azonenberg | Lol, true | 08:24 |
azonenberg | the last CPU i tried to use from there didn't even synthesize on the platform they said it was designed for :p | 08:24 |
azonenberg | lekernel: the IOSERDES are not IP | 17:34 |
azonenberg | they're hard peripherals | 17:34 |
azonenberg | lolwut? | 17:37 |
azonenberg | It's not faster | 17:37 |
azonenberg | its a hackjob | 17:37 |
azonenberg | if you read, the PLL jitter prevents it from being fully standard compliant | 17:38 |
azonenberg | Lol | 17:39 |
azonenberg | Or use 7 series | 17:39 |
azonenberg | Have you used 7 yet? | 17:39 |
azonenberg | lol | 17:41 |
azonenberg | http://pastebin.com/EzCiqbi7 | 12:51 |
---|---|---|
azonenberg | :D :D :D :D :D | 12:51 |
azonenberg | I created an xc2c32a bitstream that consists of a single NOT gate going from one FTDI GPIO pin to another | 12:52 |
azonenberg | as well as breaking out both the original and inverted values to two LEDs | 12:52 |
azonenberg | and successfully verified in hardware | 12:52 |
azonenberg | The fitting has a lot of room for improvement and has //TODO's everywhere, and right now it only works with in-memory technology-mapped netlists | 12:53 |
azonenberg | http://redmine.drawersteak.com/projects/achd-soc/repository/revisions/1089/entry/trunk/tests/FCManualBitstreamGeneration/main.cpp#L203 | 12:53 |
azonenberg | as you can see i'm manually making netlist nodes in C++ | 12:53 |
azonenberg | In technology-mapped form | 12:53 |
azonenberg | I still have to reverse the bitstream config for the flipflops and global clocking | 12:54 |
azonenberg | as well as improve my fitter in the event of routing conflicts (right now it just gives up) | 12:54 |
azonenberg | In parallel with that, i'm going to work on a technology mapper that goes from generic EDIF to this architecture | 12:54 |
azonenberg | No optimization for now, just make it work | 12:54 |
azonenberg | Then see if i can hook iverilog up to that and run the same netlist all the way from verilog source to a bitstream | 12:55 |
azonenberg | Then repeat for clocked logic | 12:55 |
azonenberg | Then add a static timing analysis engine based on xilinx's published timing numbers (unlike for FPGAs, they actually publish the full speedfile data for the CPLDs in the datasheet... the FPGA timing characteristics in the datasheet do not include full details of routing delays) | 12:56 |
azonenberg | At that point i'll have a fully functional, but unoptimizing, toolchain | 12:56 |
azonenberg | Yeah | 13:00 |
azonenberg | And room for improvement | 13:00 |
azonenberg | Right now libcrowbar (the RE and synthesis stuff, CR-II only for now) is 4.4kloc of C++ | 13:00 |
azonenberg | libjtaghal, which includes the JTAG abstraction code, the logic for programming CR-II devices given a bitstream, and a lot of stuff for other device families, is 12.5kloc | 13:01 |
azonenberg | All BSD licensed and available from that redmine, but not officially released yet | 13:01 |
azonenberg | i'm holding off on that until i hav esomething more stable | 13:01 |
lekernel | azonenberg, what about migen-to-edif? | 13:46 |
azonenberg | lekernel: I want verilog support at some point | 13:46 |
azonenberg | But any open source tool that can generate EDIF would be a start | 13:47 |
azonenberg | I like it :p | 13:47 |
azonenberg | Anyway, i'm working bottom up | 13:47 |
azonenberg | The next step is to create some kind of EDIF file, probably by hand | 13:47 |
azonenberg | and make a mapper that turns it into product term expressions and macrocells etc | 13:48 |
azonenberg | I could do that too | 13:48 |
azonenberg | I also have to figure out how to do constraint entry | 13:48 |
azonenberg | can you put constraints in EDIF? | 13:48 |
azonenberg | i think not | 13:48 |
azonenberg | so i'd need a UCF or similar file | 13:48 |
azonenberg | And if i was using iverilog, to support in-source constraints | 13:49 |
azonenberg | i'd need to modify it to export those constraints to a file along with the EDIF | 13:49 |
azonenberg | I'd need to learn python first, lol | 13:49 |
azonenberg | anyway, i first have to finish a lot of stuff in the fitting and bitstream generation stuff | 13:49 |
azonenberg | i havent even RE'd the flipflop config fully | 13:49 |
azonenberg | and there's a lot of corner cases like i mentioned in the fitter | 13:50 |
azonenberg | and there's no mapper at all | 13:50 |
azonenberg | But the mapper will take in EDIF | 13:50 |
azonenberg | That's where i stop | 13:50 |
azonenberg | any industry standard synthesis tool can make EDIF | 13:50 |
azonenberg | And any open source one can be coaxed into generating it if you patch enough | 13:50 |
azonenberg | So i see no need to reinvent the wheel at that point | 13:51 |
azonenberg | The lower-level stuff is actually important | 13:51 |
azonenberg | Though I would eventually like a BSD-licensed synthesis tool, iverilog is GPL | 13:51 |
azonenberg | and you know how i feel about GPL :p | 13:51 |
azonenberg | i'm all for open source but i want it to be a gift, not taken at gunpoint | 13:51 |
azonenberg | What doesn't work? | 13:53 |
azonenberg | GPL? | 13:53 |
azonenberg | Lol, nice | 13:57 |
azonenberg | But i do want the ability to use existing verilog code eventually | 13:58 |
azonenberg | Some of my stuff, i'd like to think :p | 13:59 |
azonenberg | And i'm continuing to write new verilog for my research | 13:59 |
azonenberg | Obviously we can't fit any of that on a CPLD | 13:59 |
azonenberg | But this will be a good foot in the door for F/OSS EDA | 14:00 |
azonenberg | then maybe wolfspraul (or someone else) can pick up fpgatools at some point and get that going | 14:00 |
azonenberg | From what I see, btw, EDIF is a technology dependent format | 14:01 |
azonenberg | as in, it describes cells rather than boolean logic expressions | 14:01 |
azonenberg | So i'd need to make a cell library for whatever synthesis tool was being targeted | 14:01 |
azonenberg | I wonder if i could convince the synthesis tool to output mapped netlists for me :P | 14:02 |
azonenberg | I doubt it | 14:02 |
azonenberg | But basically the synthesis tool would output something made of and/nand/nor/or/xor gates and flipflops | 14:03 |
azonenberg | my mapper would then squish all the combinatorial logic at each level into an and/or array with an optional xor at the end | 14:03 |
azonenberg | oh also, on the topic of open source HDL | 14:04 |
azonenberg | Does anyone know of any open source elliptic curve signature schemes implemented for FPGA? | 14:04 |
azonenberg | I'm specifically looking at signature verification using any elliptic curve scheme, signing will be done elsewhere | 14:04 |
azonenberg | i just need a way to put a public key into my device and authenticate commands | 14:05 |
azonenberg | i'm starting to do some fairly complex remote control stuff in my lab and i'd like at least some defense against random people sending packets to it :p | 14:05 |
azonenberg | and although a HMAC is probably good enough for now, i will definitely need public key crypto eventually | 14:06 |
azonenberg | (I also need it for my research) | 14:06 |
Hawk777 | azonenberg: I think Aeroflex Gaislers open-source GRLIB has some elliptic curve crypto stuff in it. | 20:00 |
azonenberg | lekernel: So i just finished fully REing the XC2C32A interconnect | 10:17 |
---|---|---|
azonenberg | The flipflop configuration, as well as tri-state I/O buffers, aren't fully figured out yet | 10:17 |
azonenberg | But I can now fully understand and model arbitrary combinatorial logic that has unidirectional ports only | 10:17 |
azonenberg | I'm working on writing a fitter/mapper now | 10:18 |
azonenberg | i think i'm only a few hours of work away from being able to replace any arbitrary combinatorial logic with an XC2C32A using F/OSS tools only (though i'll have to create the netlist in C++ since I don't have HDL support yet) | 10:19 |
azonenberg | Once i get that working i'll try to figure out how to take iverilog EDIF output and map it to the technology-dependent form i can use on my fitter | 10:19 |
azonenberg | in parallel, finish figuring out the flipflop config so i can do clocked logic | 10:20 |
wpwrak | azonenberg: i'd agree with ysionnea1 - sounds like a great victory ! | 14:17 |
azonenberg | wpwrak: lol | 14:58 |
azonenberg | Just finished I/O bank and macrocell fitting | 14:59 |
azonenberg | global routing in progress... | 15:00 |
Action: larsc cheers for azonenberg along the finish line ;) | 15:19 | |
Action: kristianpaul cheers azonenberg too :) | 15:28 | |
azonenberg | kristianpaul: xc2c64a is basically two 32as glued together | 22:33 |
azonenberg | the only difference is global routing and the dedicated input pin | 22:33 |
azonenberg | The 128 and larger will need a little more work as the macrocell config is slightly different, not not by a lot | 22:33 |
azonenberg | woot http://pastebin.com/raw.php?i=ZaYb9mvY | 06:05 |
---|---|---|
azonenberg | my xc2c32a bitstream decompiler is coming along nicely | 06:06 |
azonenberg | flipflop and clock config is the only thing i have left at the core conceptual level | 06:06 |
azonenberg | then i need to script decoding of the other 3/4 of the global routing matrix, i only have one quadrant done so far | 06:06 |
azonenberg | lekernel: http://pastebin.com/raw.php?i=ZaYb9mvY | 08:18 |
larsc | azonenberg: pretty neat | 08:58 |
azonenberg | larsc: it's getting there, at this point i'd say only a few more days (of actual work, depends on my schedule when i can get to it) to have the whole chip pretty much decoded | 08:59 |
azonenberg | At which point i can stop the reverse engineering and start the forward engineering | 08:59 |
azonenberg | as well as some refactoring to make it easier to scale the code to larger CR-II devices | 08:59 |
azonenberg | right now i only support the 32a | 08:59 |
azonenberg | the 64a will be a fairly easy upgrade as the architectures are almost identical | 08:59 |
azonenberg | the 128 and larger are a different architecture which would require some code changes | 09:00 |
azonenberg | the low end devices each have one input-only pin, i have not yet decoded the bits for using it | 09:02 |
azonenberg | the higher-end do not | 09:02 |
azonenberg | low end are two I/O banks, larger is more (but thats an easy change too) | 09:02 |
azonenberg | the PLA is identical | 09:02 |
azonenberg | the global routing is different for each device but i have not yet seen any reason to believe the big are any more different from each other than the small | 09:03 |
azonenberg | the big difference is the low-end devices have one macrocell format | 09:03 |
azonenberg | the high-end have two, and it's not the same as that of the low end | 09:03 |
azonenberg | they introduce a new class "buried macrocells" which are internal logic only, not broken out to pads | 09:03 |
azonenberg | these are basically a subset of the low-end macrocell | 09:04 |
azonenberg | minus the I/O config | 09:04 |
azonenberg | but the non-buried mcells in the high-end devices have a lot of new options | 09:04 |
azonenberg | for example "datagate" | 09:04 |
azonenberg | and SSTL capability on the inputs | 09:04 |
azonenberg | that will take more work | 09:04 |
azonenberg | first priority is a full F/OSS toolchain for the 2c32a | 09:04 |
azonenberg | I think in another week i'll be able to go from bitstream to RTL source | 09:05 |
azonenberg | then use the xilinx tools to re-synthesize | 09:05 |
azonenberg | and get a bit-for-bit identical output | 09:05 |
azonenberg | (for the 32a) | 09:05 |
azonenberg | or at least, logically equivalent | 09:06 |
azonenberg | there's a few spots where its hard to control what the optimizer does | 09:06 |
azonenberg | which makes generating certain structures to study tricky :p | 09:06 |
azonenberg | I'd say it's closer to x86 and x86-64 lol | 09:07 |
azonenberg | Low end macrocell config (xilinx-generated comment in the bitstream) | 09:07 |
azonenberg | N Aclk ClkOp Clk:2 ClkFreq R:2 P:2 RegMod:2 INz:2 FB:2 InReg St XorIn:2 RegCom Oe:4 Tm Slw Pu* | 09:07 |
azonenberg | sorry the N shouldnt be there | 09:07 |
azonenberg | thats the comment marker | 09:08 |
azonenberg | Buried macrocells in high-end | 09:08 |
azonenberg | Aclk Clk:2 ClkFreq ClkOp FB:2 P:2 Pu RegMod:2 R:2 XorIn:2 | 09:08 |
azonenberg | I/O macrocells in high end | 09:08 |
azonenberg | Aclk Clk:2 ClkFreq ClkOp DG FB:2 InMod:2 InReg INz:2 Oe:4 P:2 Pu RegCom RegMod:2 R:2 Slw Tm XorIn:2 | 09:08 |
azonenberg | the DG bit enables/disables datagate but i dont know which is which yet | 09:08 |
azonenberg | the schmitt trigger (ST) bit was replaced with a two-bit "InMod" field | 09:09 |
azonenberg | this is to handle the fact that an IOB now has three encodings | 09:09 |
azonenberg | normal, schmitt trigger, SSTL comparator | 09:09 |
azonenberg | vs just two | 09:09 |
azonenberg | i dont know if the fourth value is used for anything | 09:09 |
azonenberg | then the PLA is the same | 09:09 |
azonenberg | the global routing differs from device to device | 09:09 |
azonenberg | global clock stuff i have not decoded for the 32a yet so i dont know how that differs | 09:10 |
azonenberg | Most code is going to be the same for all devices | 09:11 |
azonenberg | There are several spots i have device-specific stuff though | 09:11 |
azonenberg | My tools are on track to be *massively* faster than the xilinx ones lol | 09:11 |
azonenberg | as a minimum, i'll take muuuuch less time to go from an in-memory model of the device to a bitstream | 09:13 |
azonenberg | their tool takes like a second and a half | 09:13 |
azonenberg | lol | 09:13 |
azonenberg | mine took 260ms to load a bitstream, parse it, decompile it, then reserialize :p | 09:13 |
azonenberg | ... and most of that time was spent in printf calls in the decompiler | 09:13 |
azonenberg | this is also debug -O0 builds | 09:14 |
azonenberg | vs the xilinx shipping release build lol | 09:15 |
azonenberg | When, in the future, I write any FPGA stuff | 09:15 |
azonenberg | i will take great pains to design for scalability from the ground up | 09:15 |
azonenberg | including parallel algorithms from day one | 09:15 |
azonenberg | But for CPLDs i think optimized serial code is fast enough | 09:16 |
azonenberg | Lol | 09:16 |
azonenberg | that, and i have a rack of stuff in the living room | 09:16 |
azonenberg | i dont want it gathering dust while i build with one core :p | 09:16 |
azonenberg | That is the goal | 09:17 |
azonenberg | I plan to design my FPGA tools to be extremely scalable | 09:17 |
azonenberg | exactly what algorithms i use are TBD | 09:17 |
azonenberg | But i was reading some papers that got like 100x speedups on simulated annealing | 09:19 |
azonenberg | before i do that i'd want to look at more future-looking algorithms that are deterministic thoguh | 09:19 |
azonenberg | so i dont end up like xilinx's tools :p | 09:19 |
azonenberg | even if i do twice as much work as the random algorithm | 09:19 |
azonenberg | on 16 cores i can afford that :p | 09:20 |
azonenberg | Anyway that's a LONG way out | 09:20 |
azonenberg | CPLDs first | 09:20 |
azonenberg | So they claim, yes | 09:23 |
azonenberg | i want to explore such algorithms | 09:24 |
azonenberg | they seem to give better results | 09:24 |
azonenberg | Which is why i dont want to implement SA | 09:24 |
azonenberg | Right now i'm actually tuning some cluster settings to make my research codebase build / test faster | 09:27 |
azonenberg | i have lots of different dev boards and many test cases could run on any of several | 09:28 |
azonenberg | so i'm trying to load-balance so that each board is used about the same amount | 09:28 |
azonenberg | rather than having long queues on a few | 09:28 |
wpwrak_ | azonenberg: (My tools are on track to be *massively* faster than the xilinx ones) what's next on your list ? competitive swimming against a pile of rocks ? ;-) | 18:36 |
azonenberg | wpwrak_: lol | 19:44 |
azonenberg | I was actually thinking a 100m sprint vs a tree sloth | 19:44 |
lekernel | azonenberg, do I need to apply oil on KF25 gaskets? | 14:32 |
---|---|---|
azonenberg | lekernel: you mean vacuum grease? | 16:59 |
azonenberg | No, afaik they're intended to be used dry | 16:59 |
davidc__ | offtopic for here; but azonenberg - you seem to know a bit about vacuum handling gear. How hard is it to take apart and reseal high-vacuum gear? [I bought myself a SEM and am trying to figure out how in hell to move it] | 18:14 |
azonenberg | davidc__: No more offtopic than lekernel's question :p | 18:15 |
azonenberg | I've used some vacuum stuff (and seen people abuse it lol) | 18:15 |
azonenberg | What kind of SEM? | 18:15 |
azonenberg | Tungsten? Field emission? | 18:15 |
davidc__ | azonenberg: Tungsten | 18:15 |
davidc__ | azonenberg: old-school '96 Phillips XL-30 | 18:15 |
azonenberg | davidc__: If it's low vacuum using viton gaskets, you should be good | 18:18 |
azonenberg | Copper seals are used in UHV and some field emission guns might use them | 18:18 |
azonenberg | But i would not expect to see them on a tungsten SEM | 18:18 |
azonenberg | interesting | 05:56 |
---|---|---|
azonenberg | is there a cycle-accurate model of the cortex-a9 in zynq? | 05:56 |
azonenberg | could you get the full a9 RTL that way? :P | 05:56 |
davidc__ | azonenberg: its a hard core | 06:07 |
azonenberg | davidc__: i know | 06:07 |
davidc__ | azonenberg: any cycle-accurate model would probably be a softmodel. No need for RTL for cycle-accuracy | 06:07 |
azonenberg | but they have secureip models of the powerpc on the old virtexes | 06:07 |
azonenberg | Meaning they plan to deploy one but it's not out yet | 06:08 |
lekernel | azonenberg, why care about a9, there's nothing special about it | 21:48 |
azonenberg | lekernel: a) curiosity | 21:55 |
azonenberg | b) it'd be fun to do a security audit :p | 21:56 |
azonenberg | i've always wanted to get an 0day in a popular cpu that gives you user-to-kernel priv escalation | 21:56 |
azonenberg | ? | 21:57 |
azonenberg | what do you mean | 21:57 |
azonenberg | anyone doing remotely interesting work is probably on the wrong end of chinese industrial espionage these days | 21:58 |
azonenberg | i've been using libftd2xx | 07:59 |
---|---|---|
azonenberg | my library could be easily ported to use libftdi, in fact i was doing that in the past | 07:59 |
azonenberg | but bugs forced me t oleave | 07:59 |
lekernel | seems they didn't - http://siliconpr0n.org/archive/doku.php?id=azonenberg:ftdi:ft232rl | 18:02 |
---|
azonenberg | wpwrak: the problem is that if you route half a net (as part of bga escape etc) | 05:53 |
---|---|---|
azonenberg | then more of it | 05:53 |
azonenberg | kicad doesnt know they're the same track | 05:54 |
azonenberg | so the length reading comes out wrong | 05:54 |
azonenberg | i'm using 2012-10-01 | 06:44 |
azonenberg | which is a little out of date | 06:44 |
azonenberg | larsc, lekernel: i usually use planahead for looking at placement | 18:10 |
azonenberg | but it doesn't show routing | 18:10 |
larsc | azonenberg: how does that work? | 18:17 |
azonenberg | what do you mean, how does it work? | 18:18 |
azonenberg | you run it and look at the instances | 18:18 |
azonenberg | oh | 18:19 |
azonenberg | make one | 18:19 |
azonenberg | select "import ise P&R reuslts" | 18:19 |
azonenberg | wpwrak: I usually use a swab and isopropyl alcohol for removing no-clean flux | 11:15 |
---|---|---|
lekernel | azonenberg, hi | 11:24 |
azonenberg | hi | 11:24 |
lekernel | azonenberg, how much do you know about Wolfgang's fpgatools? | 11:24 |
azonenberg | Not much, i was focusing on CR-II | 11:25 |
azonenberg | the microarchitecture is totally different so we didnt really share any code | 11:25 |
azonenberg | My goal was to make something simple, but tractable to do by one person in a few months | 11:25 |
azonenberg | i've been taking time off due to school but i plan to get back to it over the summer | 11:25 |
azonenberg | i have maybe two weeks more work to do | 11:26 |
azonenberg | and i'll be able to turn placed-and-routed netlists into bitstreams | 11:26 |
azonenberg | Lol | 11:26 |
azonenberg | I'm very interested in picking it up eventually | 11:26 |
azonenberg | Just not any time soon since i have bigger fish to fry :( | 11:26 |
sb0 | azonenberg, when do we see your upcoming excellent on-chip LA? ;) | 09:38 |
---|
lekernel | larsc azonenberg | 14:25 |
---|---|---|
azonenberg | lekernel: I personally don't have a use case for migen since i already have a tool that does what i need | 18:07 |
azonenberg | that said, i am in favor of BSDing everything in general | 18:07 |
lekernel | azonenberg, yes, I know you love NIH :) | 21:51 |
azonenberg | lekernel: on hold, i'm swamped with homework this week | 21:51 |
azonenberg | fpga_editor is terrible | 02:14 |
---|---|---|
azonenberg | planahead actually makes decent UIs | 02:14 |
azonenberg | has* | 02:14 |
azonenberg | I just wish it had an option to show routing rather than just placement | 02:15 |
azonenberg | larsc: ooh | 02:15 |
azonenberg | very nice | 02:15 |
azonenberg | lol, wow | 23:11 |
---|---|---|
azonenberg | Also, i think i know that guy | 23:11 |
azonenberg | (the OP) | 23:12 |
azonenberg | he went to my school and was talking to me a year or so ago about doing HDMI on an Atlys | 23:12 |
azonenberg | lekernel: http://colossus.cs.rpi.edu/~azonenberg/unlisted/xc2c32a_bf_neo5x_annotated.jpg | 21:42 |
---|---|---|
mwalle | azonenberg: what is FB and ZIA? | 21:44 |
lekernel | azonenberg, very cool! | 21:44 |
azonenberg | mwalle: FB = function block | 21:44 |
azonenberg | ZIA = zero-power input array | 21:44 |
azonenberg | that's semi-internal terminology used by the toolchain | 21:44 |
azonenberg | lekernel: it's beautiful how well the silicon matches up with the bitstream | 21:44 |
azonenberg | i knew what to expect before i even opened the package | 21:45 |
azonenberg | It's a switching matrix that routes every function block's output, and every input pin, back to the inputs of the AND array | 21:45 |
azonenberg | I'm still trying to understand the exact structure of it | 21:45 |
azonenberg | i have most of it figured out by bruteforce but i don't yet understand the actual structure, i was hoping the silicon could help clarify that | 21:46 |
azonenberg | It appears not | 21:46 |
azonenberg | The 2c32a has config SRAM | 21:46 |
azonenberg | you can even download a bitstream into the SRAM without touching the flash | 21:46 |
azonenberg | Yes | 21:46 |
azonenberg | That was a surprise to me as well | 21:47 |
azonenberg | The actual configuration cells are probably regular 6T SRAM or D FFs | 21:47 |
azonenberg | They are, in theory | 21:47 |
azonenberg | It's semi-documented | 21:47 |
azonenberg | jtag instruction ICS_SRAM_WRITE | 21:47 |
azonenberg | ISC* | 21:48 |
azonenberg | Same here | 21:49 |
azonenberg | You can write to the SRAM or the flash independently of the other | 21:49 |
azonenberg | i dont know if xc9500* has that feature but cr-ii does | 21:49 |
azonenberg | cr-ii is a much nicer architecture | 21:49 |
lekernel | azonenberg, you | 21:53 |
azonenberg | lekernel: ? | 21:53 |
lekernel | azonenberg, have you checked some microsemi/actel devices? | 21:53 |
azonenberg | Funny you ask | 21:53 |
azonenberg | http://colossus.cs.rpi.edu/pictures/2013/March/3-11-2013%20-%20decapping/a3p030/a3p030_01_bf_neo5x.jpg | 21:53 |
azonenberg | I have had zero time to analyze it | 21:53 |
azonenberg | just a few pictures in that directory | 21:53 |
azonenberg | Look at the date ;) | 21:54 |
azonenberg | Unknown | 21:54 |
azonenberg | I opened it up and took a few photos | 21:55 |
azonenberg | that was all i had time for | 21:55 |
azonenberg | I did an XC2C64A as well http://colossus.cs.rpi.edu/pictures/2013/March/3-11-2013%20-%20decapping/xc2c64a/xc2c64a_bf_neo5x.jpg | 21:55 |
azonenberg | No analysis on that | 21:55 |
Fallenou | azonenberg: how much time does it take to decap a chip and then take a picture ? | 21:56 |
azonenberg | Hmm, maybe an hour? But you can run a lot of chips at once on the hot plate | 21:57 |
lekernel | azonenberg, another thing to consider taking apart is a spartan 3an device | 21:57 |
azonenberg | i did a dozen chips of nine part numbers in that run | 21:57 |
azonenberg | Yes | 21:57 |
azonenberg | It's stacked die SPI | 21:57 |
azonenberg | I havent taken one apart but docs say it's "similar to" Atmel DataFlash | 21:57 |
Fallenou | azonenberg: what do you use for taking the pictures? pice range of it? | 21:57 |
azonenberg | There's an SPI_ACCESS primitive in spartan6 too | 21:57 |
azonenberg | but as far as i know there was never a Spartan-6N series | 21:58 |
azonenberg | Fallenou: The optical microscope is an olympus BHM | 21:58 |
azonenberg | $250 on ebay for the body with objectives and a binocular head, another $250 for a head with the camera port | 21:59 |
azonenberg | sold new for probably ten times that | 21:59 |
azonenberg | I got lucky | 21:59 |
azonenberg | they were asking $500 OBO | 21:59 |
azonenberg | i offered 250 with the intention of negotiating | 22:00 |
azonenberg | but they sold it to me right then and there | 22:00 |
azonenberg | Fallenou: Depends on what you're looking at | 22:00 |
azonenberg | For something modern like spartan6, optical won't be of use for more than the top layer or two | 22:00 |
azonenberg | you need a SEM | 22:00 |
azonenberg | On the other hand for old MCUs made on like a 500nm process, 400x is fine | 22:00 |
azonenberg | with 1000x you can do 350nm stuff | 22:01 |
azonenberg | maybe 250 if you're really careful and have high-end optics | 22:01 |
azonenberg | 180 and below pretty much needs SEM if you want to see all the details | 22:01 |
azonenberg | Being a student at a tech school is nice, i get access to all the labs :) | 22:02 |
azonenberg | and the rates are quite reasonable | 22:02 |
azonenberg | the one i took the spartan6 pic on is $65 an hour | 22:02 |
azonenberg | they have a lower end one available for i think 45 or 4o | 22:02 |
azonenberg | 40* | 22:02 |
azonenberg | Yes | 22:02 |
azonenberg | 500x, lol | 22:02 |
azonenberg | i can magnify anything 500 times | 22:03 |
azonenberg | doesnt mean it'll be anything but a blur :p | 22:03 |
azonenberg | There are good optics and cheap optics, but no good cheap optics | 22:03 |
azonenberg | Compare: http://colossus.cs.rpi.edu/pictures/2013/January/01-18-2013%20-%20ENC424J600/enc424j600_01_bf_am40x_annotated.jpg | 22:03 |
azonenberg | AmScope objective | 22:03 |
azonenberg | http://colossus.cs.rpi.edu/pictures/2013/January/01-18-2013%20-%20ENC424J600/enc424j600_02_bf_neo40x_annotated.jpg | 22:03 |
azonenberg | Olympus Neo40 objective | 22:03 |
azonenberg | Same camera, same specimen | 22:03 |
azonenberg | different lenses | 22:03 |
Fallenou | azonenberg: wow indeed | 22:04 |
azonenberg | Fallenou: For scale the smallest wires visible in the Olympus image are about 500nm across | 22:04 |
azonenberg | the device is a 250 or 180nm process but this is an upper metal layer | 22:04 |
azonenberg | Lol, yep | 22:10 |
azonenberg | Note that the AmScope that took that blurry picture | 22:10 |
azonenberg | sells new for around $1000 | 22:10 |
azonenberg | and looks that bad compared to the olympus | 22:10 |
azonenberg | now imagine what $50 optics will look like ;p | 22:10 |
azonenberg | Lol, yes | 22:12 |
azonenberg | The objective is the most critical part | 22:12 |
azonenberg | you can skimp on eyepieces to some extent | 22:12 |
azonenberg | You *do* want to see whatever is under that objective, right? | 22:13 |
azonenberg | you need something to look through ;) | 22:13 |
azonenberg | wpwrak: lol | 21:38 |
---|---|---|
azonenberg | yep | 21:38 |
azonenberg | http://i.imgur.com/eLcZsvy.png :D | 16:45 |
---|---|---|
azonenberg | My cluster is coming online :) | 16:45 |
azonenberg | need another dozen jtag cables before the rest of the nodes will be usable though :p | 16:45 |
lekernel | azonenberg, what is that supposed to do in the end? | 16:45 |
azonenberg | Fallenou: very heterogeneous | 16:46 |
azonenberg | everything from an XC3S50A on a homemade board to the Atlys | 16:46 |
azonenberg | Two of them in fact | 16:46 |
azonenberg | I'm using it for unit tests of my thesis research and libjtaghal | 16:46 |
azonenberg | Fallenou: The bigger boards are being used as testbeds for that, yes | 16:47 |
azonenberg | the smaller ones are for one-off prototyping and libjtaghal regression testing | 16:47 |
azonenberg | and just for good measure as long as i was bringing up a batch scheduler i set up distributed builds | 16:47 |
azonenberg | i can't make one P&R run go any faster, but a lot of cores will trivially speed up building ten bitstreams at once | 16:47 |
lekernel | azonenberg, well you can, thanks to wolfspraul's fpgatools and some coding ;) | 16:48 |
azonenberg | lekernel: I dont think it's mature enough for that | 16:48 |
azonenberg | the CPLD boards, however, are being used for active development of my CPLD toolchain | 16:48 |
azonenberg | For his or mine? | 16:48 |
azonenberg | I intend to do full timing analysis on mine | 16:49 |
azonenberg | not yet implemented | 16:49 |
azonenberg | I'm still working at the bitstream level | 16:49 |
azonenberg | balrog: how many others are there? | 16:49 |
azonenberg | besides my CPLD stuff and fpgatools | 16:49 |
azonenberg | debit was mostly RE focused though right?> | 16:50 |
azonenberg | not aiming at synthesis | 16:50 |
azonenberg | I want both | 16:50 |
azonenberg | fpgatools is your best hope, ye | 16:50 |
azonenberg | yes* | 16:50 |
azonenberg | my CPLD stuff is mostly a side project that i think is small enough compared to fpgatools that it can become production-ready relatively quickly | 16:50 |
azonenberg | whereas fpgatools needs a LOT of work still | 16:50 |
azonenberg | That was the point | 16:51 |
azonenberg | it's tractable for one person to do in a few months | 16:51 |
azonenberg | Another week or so of effort should be enough to get the full bitstream format worked out | 16:51 |
lekernel | azonenberg, what are the next major obstacles, except the timing model? | 16:51 |
azonenberg | then the place-and-route for a CPLD is pretty easy since the netlists are so small | 16:51 |
azonenberg | coolrunner-II | 16:51 |
azonenberg | oh | 16:51 |
azonenberg | I havent been following him too closely | 16:51 |
azonenberg | been playing my own game here | 16:51 |
azonenberg | there is no shared code since the architectures are so different | 16:52 |
azonenberg | balrog: i'm focusing on cr-ii because of one crucial detail | 16:52 |
azonenberg | the .jed files generated by the xilinx compilers include comments | 16:52 |
azonenberg | describing most of the bitstream format | 16:52 |
azonenberg | i suspect someone left _DEBUG defined | 16:52 |
azonenberg | by accident | 16:52 |
azonenberg | But i'm not gonna look a gift horse in the mouth | 16:52 |
azonenberg | Correct | 16:52 |
azonenberg | from what i understand cr-ii was based on another company xilinx acquired | 16:53 |
azonenberg | this may be their code | 16:53 |
azonenberg | If it's done at the preprocessor level, no | 16:53 |
azonenberg | lekernel: mainly 74xx replacement | 16:53 |
azonenberg | they're nonovolatile, small, and cheap | 16:53 |
azonenberg | i'd rather throw an xc2c32a on a board than two or three 74HC's | 16:53 |
azonenberg | one 74HC i might do but even then i might prefer the cpld for flexibility | 16:54 |
azonenberg | lekernel: Maybe a SERDES for a microcontroller? | 16:54 |
azonenberg | They're not meant to be full systems | 16:54 |
azonenberg | they're meant for glue logic | 16:54 |
azonenberg | Fallenou: $1.15 for the xc2c32a | 17:01 |
azonenberg | in the slow speed grade | 17:01 |
azonenberg | 32 flipflops and 32 macrocells worth of combinational logic | 17:01 |
lekernel | azonenberg, your cmakefile still generates a makefile when gtkmm is not found | 22:23 |
---|---|---|
azonenberg | lekernel: Hmm, i'll fix that | 22:23 |
azonenberg | The stuff in the google code repo is actually somewhat out of date | 22:24 |
azonenberg | version 0.2 is in the repo with my thesis | 22:24 |
azonenberg | it uses a lot of the same build infrastructure | 22:24 |
azonenberg | and i havent had the time to split it off and push back | 22:24 |
azonenberg | It's not public at the moment because my VPS provider is oversubscribing me and i dont even have enough capacity for myself | 22:25 |
azonenberg | i'm in the process of changing hosts | 22:25 |
azonenberg | i'm still SVN based | 22:26 |
azonenberg | I need detailed control over the primitives in order to do the partial reconfig properly | 22:33 |
azonenberg | i have to make sure it's exactly one level of logic | 22:33 |
azonenberg | anyway the JTAG stuff (not in that code version) is inherently xilinx specific | 22:34 |
azonenberg | I've had bad experiences with inference in such cases | 22:35 |
azonenberg | In order to get maximum speed i'm pretty sure that device-specific optimizations are necessary | 22:35 |
azonenberg | i plan to make an altera port at some point too | 22:35 |
azonenberg | with the same capabilities | 22:35 |
azonenberg | and probably re-using a lot of the logic | 22:36 |
azonenberg | i've been able to infer fixed-address shift registers | 22:36 |
azonenberg | but not variable-address ones | 22:36 |
azonenberg | i'll look, i just know that i've had difficulty convincing the tools to do it | 22:37 |
azonenberg | bear in mind that code that infers properly for xilinx may not infer properly on altera | 22:37 |
azonenberg | and thus still need vendor-specific tuning | 22:37 |
azonenberg | Also, i may not keep that exact SRL structure | 22:38 |
azonenberg | i'm in the process of experimenting with different options to allow reconfigurability while packing as many trigger controls as possible into one slice | 22:38 |
azonenberg | i'm looking at options including SRLs, dual-port RAM, etc | 22:38 |
azonenberg | Oh, and i still have to do the run-length encoding | 22:41 |
azonenberg | the trigger logic is going to by necessity be quite specialized to the underlying FPGA slice primitives | 22:41 |
azonenberg | If i want to be able to run the LAs as fast as whatever input i throw at it | 22:42 |
azonenberg | the LA has to be extremely efficient | 22:42 |
azonenberg | The trick is to switch the trigger block to edge detection (for RLE) | 22:43 |
azonenberg | My current thinking it so squeeze that into the last unused SRL32 primitive | 22:43 |
azonenberg | the last input* | 22:43 |
azonenberg | are you kidding me? more | 22:44 |
azonenberg | even in -3 series s6 it's 210ps through one LUT | 22:45 |
azonenberg | then routing delays | 22:45 |
azonenberg | it'll probably be at least 500ps | 22:45 |
azonenberg | which at 200 MHz is a 10% speedup for each LUT I can cut out of the critical path | 22:45 |
azonenberg | My current platform is s6 based | 22:46 |
azonenberg | I have an artix7 bord in the works | 22:46 |
azonenberg | board* | 22:46 |
azonenberg | No, just the LA | 22:47 |
azonenberg | the goal is for the LA to be fast enough to keep up with anything i can conceivably throw at it | 22:47 |
azonenberg | artix7 in -1 spee is 130ps per LUT, lol | 22:49 |
azonenberg | Double the LUT performance right there | 22:49 |
azonenberg | kintex7 is 60ps, wow | 22:49 |
lekernel | azonenberg, so after the trigger condition is met, you get 512 samples at the clock frequency? | 23:03 |
azonenberg | lekernel: Right now, yes | 23:03 |
azonenberg | The RLE version will give you 512 edges | 23:03 |
azonenberg | as in, sample all signals whenever any one changes | 23:03 |
azonenberg | Which will let you capture with long delays between bus cycles etc | 23:04 |
azonenberg | or slow signals like a UART as long as there isnt fast stuff in the same capture | 23:04 |
azonenberg | In the future i'll be making it parameterizable depth | 23:04 |
azonenberg | and possibly with | 23:04 |
azonenberg | width* | 23:04 |
azonenberg | these are all in progress for v0.2 | 23:04 |
azonenberg | The code in that repo hasnt been touched in months | 23:05 |
azonenberg | It's not that simple because the new version is using my NoC protocol for reading data out over JTAG | 23:05 |
azonenberg | and packets have a 512-word limit | 23:05 |
azonenberg | so i'll need to add code to send multiple packets | 23:05 |
azonenberg | Adding more depth to the actual capture core will be trivial | 23:07 |
azonenberg | the wrappers, less so | 23:07 |
azonenberg | The UART code in that version is buggy too | 23:08 |
azonenberg | i need to rewrite it from scratch | 23:09 |
azonenberg | larsc: High on my list of things to explore | 23:09 |
azonenberg | first thing to do is improve my JTAG code so i can get more than 80 Kbps | 23:09 |
azonenberg | lekernel: the UART itself is fine | 23:10 |
azonenberg | it's the code that talks to it | 23:10 |
azonenberg | And if its wishbone based then no, not an option | 23:10 |
azonenberg | as i'm not using wishbone | 23:10 |
azonenberg | But my uart is being used in a lot of code and works fine | 23:11 |
azonenberg | by several people | 23:11 |
azonenberg | the binary protocol on the wire is horrible thoguh | 23:11 |
azonenberg | pythin :p | 23:11 |
azonenberg | python* | 23:11 |
azonenberg | And that's the thing, it's not a bus | 23:12 |
azonenberg | it's a network | 23:12 |
azonenberg | the topology isn't flat | 23:12 |
azonenberg | wpwrak: this is able to capture signals with data rates of over 200 MHz | 23:13 |
azonenberg | lekernel: The old version did not | 23:13 |
azonenberg | the new version is a NoC slave | 23:13 |
azonenberg | you can have a softcore download trigger conditions and pull data off | 23:13 |
azonenberg | or, as i'm doing now, use the NoC-to-JTAG debug bridge to control it from a PC | 23:13 |
azonenberg | Once i work out a bug in the debug bridge i'll be all set | 23:15 |
wpwrak | azonenberg: oh, i thought it would be faster. the ben goes up to 56 MHz, maybe even 84 MHz on a good day | 23:16 |
azonenberg | wpwrak: This is the hgihest i've tested it at | 23:16 |
azonenberg | i'm mostly limitd by spartan6 block RAM | 23:16 |
azonenberg | when i move to 7 series i'll be able to go a lot higher | 23:16 |
azonenberg | s6 block ram maxes out at like 300ish MHz | 23:17 |
azonenberg | i forget the exact number, 320ish? | 23:17 |
azonenberg | I could potentially go faster by DDRing the RAM bank | 23:17 |
azonenberg | have two ram blocks with 180 degree phase-shifted clocks | 23:17 |
azonenberg | And also double the size of the core | 23:18 |
azonenberg | Which is a real concern if you want it to be small | 23:19 |
azonenberg | But now the minimum size of the core in the smallest provisioned size is bigger | 23:21 |
azonenberg | 512 is a little shallow though so i plan to fix that | 23:22 |
azonenberg | first step is to get rid of this jtag race condition | 23:22 |
azonenberg | lol well i prioritize bug fixing over new features | 23:23 |
azonenberg | lol | 23:24 |
azonenberg | but i'm not trying to sell | 23:24 |
azonenberg | i want to solve my own problem :p | 23:25 |
azonenberg | and that means looking sexy isn't the first priority | 23:25 |
azonenberg | working is :p | 23:25 |
azonenberg | http://i.imgur.com/5CPFuxF.png :D | 18:21 |
---|---|---|
azonenberg | screw you chipscope | 18:21 |
azonenberg | Which text, the channel names? | 18:32 |
azonenberg | or the text in the signals | 18:32 |
azonenberg | the text in the signals should be, i used pango calls to get the line height and then put it at (signal height/2 - line height/2) | 18:32 |
azonenberg | i know that the channel-name list on the left is way off | 18:33 |
azonenberg | hmm, it might just not divide evenly | 18:40 |
azonenberg | if the font is an odd number of pixels high and the signal is an even | 18:40 |
lekernel | azonenberg, looks nice, though the obvious question is: why not gtkwave? | 19:08 |
azonenberg | lekernel: I considered gtkwave | 19:09 |
azonenberg | in fact my first version used it | 19:09 |
azonenberg | But its internal architecture was not amenable to arbitrary protocol decode | 19:09 |
azonenberg | the UI is almost irrelevant | 19:10 |
azonenberg | most of the work is the back end on the capture core | 19:10 |
azonenberg | The other problem is that gtkwave is gpl'd | 19:12 |
azonenberg | My entire stack as far down as i can get is going to be BSD | 19:12 |
azonenberg | Several times i've found very nice looking apps and been ready to start integrating them, then realized they were GPL | 19:14 |
azonenberg | Which would mean i'd have to GPL a sizable fraction of my code | 19:14 |
azonenberg | and that's not an option | 19:14 |
azonenberg | not if i link it with a gpl'd application | 19:15 |
azonenberg | everything i add would have to be gpl'd | 19:15 |
azonenberg | larsc: That's what i'm doing here | 19:16 |
azonenberg | all of the protocol decode and back-end stuff is a standalone library | 19:16 |
azonenberg | Yes | 19:16 |
azonenberg | But the combination of the two becomes GPL'd | 19:16 |
azonenberg | My bigger issue is gpl'd libraries | 19:17 |
azonenberg | forcing me to gpl the entire application | 19:17 |
azonenberg | that is not acceptable | 19:17 |
azonenberg | my goal is to deliver a useful product that can be used by the widest possible audience | 19:18 |
azonenberg | not to push the ideology of free software | 19:18 |
azonenberg | and that means rejecting anything that's too overly politicized like the gpl | 19:18 |
azonenberg | Stallman himself tried to convince me otherwise but when he said "I have no sympathy for anyone who uses such a ridiculously permissive license" that was the last straw | 19:19 |
azonenberg | i couldn't care less if some company forks my code and turns it into a commercial product | 19:19 |
azonenberg | as long as my copy is still usable by me then i lose nothing | 19:19 |
azonenberg | and the world gains something | 19:20 |
azonenberg | And as a result, if left with no choice | 19:22 |
azonenberg | and I need a library to do something in a BSD'd application | 19:22 |
azonenberg | I will replace a GPL'd library with a BSD'd equivalent | 19:22 |
azonenberg | even if that means writing it from scratch | 19:22 |
azonenberg | Like i said, i had been using gtkwave as a standalone executable for my first version of the LA app | 19:23 |
azonenberg | but it lacked a lot of capabilities i needed to do proper live updates and protocol decoding | 19:23 |
azonenberg | and i didn't want to put all of that time into patching a GPL'd project | 19:23 |
azonenberg | Since i want my viewer to be a librarized component that i can drop into a larger appliction | 19:25 |
azonenberg | without having to gpl it | 19:25 |
azonenberg | lekernel, xiangfu: http://pastebin.com/raw.php?i=QKqKhViS | 07:23 |
---|---|---|
azonenberg | The interconnect muxes are now decoded for function block 1 | 07:23 |
azonenberg | only four unknown fields left in the macrocell config | 07:23 |
azonenberg | and three or four global muxes to work out | 07:23 |
azonenberg | wpwrak: This is a debug visualization | 07:45 |
azonenberg | i plan to do something more substantial down the road for reverse engineering | 07:45 |
azonenberg | But users of the toolchain will not have any real use for this | 07:45 |
azonenberg | Basically i'm writing RTL that is explicitly constrained to the maximum extent possible (so that very little is left up to the compiler) | 07:46 |
azonenberg | synthesize it, then verify that my output matches | 07:46 |
azonenberg | As you can see there are still a half-dozen fields or so that aren't decoded | 07:46 |
azonenberg | The sample design only uses function block 1 | 07:47 |
azonenberg | FB2 is legitimately blank | 07:47 |
azonenberg | That said, my code has not yet figured out all of the muxes for FB2 | 07:47 |
azonenberg | the unknowns are, first, which settings to use for FFs and IBUFs in FB2 to rout to FB1 | 07:47 |
azonenberg | and second, whether FB2 uses the same mux settings or different ones | 07:48 |
azonenberg | All of the mux work will have to be redone for each device in the family since the mux is different widths, but i've mostly automated it | 07:48 |
azonenberg | so it shouldn't be too bad | 07:48 |
azonenberg | A macrocell is hard-wired to one pin | 07:48 |
azonenberg | But, not exactly | 07:48 |
azonenberg | Each output buffer can be driven either by its attached macrocell's combinational logic, or that macrocell's flipflop | 07:49 |
azonenberg | The input buffers drive global routing as well as a high-speed path to the D input of the associated macrocell's flipflop | 07:49 |
azonenberg | the alternative input for the FF is the combinational path of the same macrocell | 07:49 |
azonenberg | When the IBUF drives the flipflop, the combinational logic is available for internal use or driving non-registered outputs | 07:49 |
azonenberg | i still have a decent amount of work to do to write a synthesis, mapping, and PAR toolchain for the architecture | 07:50 |
azonenberg | Step 1 is figuring out what config bits to set to put each mux in the datasheet block diagram in a desired state | 07:50 |
azonenberg | Step 2 is taking a mapped netlist (as in, structured in the form of sum-of-product expressions with no more than X inputs at each level, D/T flipflops and latches, and I/O buffers) and packing it into the device | 07:51 |
azonenberg | including finding places where i can use a function-block level control term rather than a separate product term for (say) each flipflop's clock enable | 07:51 |
azonenberg | Step 3 is taking a generic gate-level RTL netlist and mapping it into the CPLD-friendly form | 07:52 |
azonenberg | Step 4 is figuring out how to use iverilog, ghdl, or a homebrewed synthesis tool to turn HDL into generic gate-level RTL | 07:52 |
azonenberg | and obviously all the way down the stack i need to be able to attach constraints to the netlist like "put this flipflop in this macrocell" or "this signal goes on that pin" | 07:53 |
azonenberg | So right now i'm still on step 1 | 07:53 |
azonenberg | At some point I also have to decide on how to release this | 07:53 |
azonenberg | Yeah | 07:54 |
azonenberg | Or if you want to try out-optimizing my optimizer | 07:54 |
azonenberg | Which probably won't be hard | 07:54 |
azonenberg | Anyway right now i have one master repo for everything i've been doing lately which includes my thesis research, libjtaghal, and libcrowbar (the CPLD stuff) | 07:54 |
azonenberg | I'm not ready to release the thesis stuff yet | 07:54 |
azonenberg | both libjtaghal and libcrowbar need lots of cleanup and documentation | 07:55 |
azonenberg | So i have to decide whether to split the repo into multiple ones, release a tarball but not have public version control\ access, etc | 07:55 |
azonenberg | Or whether to keep on working in my current semi-public mode until i finish my thesis | 07:55 |
azonenberg | and just dump the whole thing on sourceforge/github/whatever | 07:55 |
azonenberg | There's zero doubt whatsoever that (at the latest) when i finish my thesis the entire repo will be relased somewhere under 3-clause BSD | 07:56 |
azonenberg | What's still uncertain is whether there will be intermediate releases of the support libraries in the short term | 07:56 |
azonenberg | You mean my thesis stuff or what? | 07:57 |
azonenberg | I don't want to dump code out somewhere until i have a paper that talks about the science behind it | 07:58 |
azonenberg | I have a survey paper that sets the stage for what i'm doing | 07:58 |
azonenberg | once that is submitted i'll re-evaluate what to publish immediately and what to hold back on | 07:58 |
azonenberg | I'm almost ready to submit the first one | 07:59 |
azonenberg | only been working on this for a year and a half and the first year was mostly coursework | 07:59 |
azonenberg | Lol he's decently happy with what i've been doing so far | 07:59 |
azonenberg | Lol, well i have 15 pages i sent to him and the other guys in the research group for a review | 08:00 |
azonenberg | waiting for suggestions | 08:00 |
azonenberg | It's a survey paper so it'd go in a journal | 08:01 |
azonenberg | And will also turn into the related-work section of my thesis | 08:02 |
azonenberg | so if i have to strip it down a bit for publication that's fine | 08:02 |
azonenberg | I suspect that 44 references is a little bit long for a conference paper | 08:02 |
azonenberg | Yeah, like i said i'm not even considering submitting it to a conference | 08:04 |
azonenberg | perhaps original research in six months or so | 08:04 |
azonenberg | but journals are a more proper venue for survey papers anyway | 08:04 |
azonenberg | The survey paper outlines the problem i'll be doing my thesis on so once i get that out i'll probably move my repo to full-on public | 08:04 |
azonenberg | right now i have a viewer on a Redmine install that doesn't require a password but isn't linked anywhere | 08:04 |
azonenberg | as in, i'm not exactly trying to hide but i don't think i have enough to show yet to go out of my way to publicize it | 08:04 |
azonenberg | Most of the code i have now is libjtaghal, libcrowbar, an old MIPS softcore that is going to get replaced by a new design soon, and the NoC i'll be building all of the fun stuff on | 08:05 |
azonenberg | I intend to do a few tech reports etc | 08:05 |
azonenberg | or maybe just jam something up on my website | 08:05 |
azonenberg | Lol | 08:06 |
azonenberg | I'm not out to get a million citations or sell my work to some company and get rich or whatever | 08:06 |
azonenberg | i just want to get a phd, hopefully make a useful contribution to the field, and then go find a lab that likes what i've been spending the last few years on enough to hire me :p | 08:06 |
azonenberg | Yeah | 08:07 |
azonenberg | Well I have my hands in so many places with this work its not even funny | 08:07 |
azonenberg | i'm doing SoC architecture, NoC, CPU microarchitecture, security, networks, OS architecture | 08:07 |
azonenberg | i'm citing stuff ranging from IEEE papers to ACM journals to Vanity Fair to declassified NSA memos | 08:07 |
azonenberg | Not really | 08:08 |
azonenberg | There is a central theme to it all | 08:08 |
azonenberg | but it's interdisciplinary | 08:08 |
azonenberg | and thus related work is everywhere depending on which end i'm grabbing from | 08:08 |
azonenberg | I mean, when you look at stuff like fault attacks on crypto (similar but not what i'm doing) | 08:10 |
azonenberg | you need to know the math and the hardware since either by itself isn't exploitable | 08:10 |
azonenberg | but the combination is vulnerable | 08:10 |
azonenberg | Well, my focus is on securing applications | 08:12 |
azonenberg | by using an OS architecture including some hardware components inside a SOC | 08:12 |
azonenberg | Connected by a NoC | 08:13 |
azonenberg | and using a CPU with a few ISA tweaks to optimize performance for the platform | 08:13 |
azonenberg | So... | 08:13 |
azonenberg | Nope | 08:14 |
azonenberg | Thats the beauty of it | 08:14 |
azonenberg | it's microarchitecture tweaks, plus repurposing the "syscall" instruction while keeping the same machine syntax | 08:15 |
azonenberg | that's not an instruction the compiler generates anyway | 08:15 |
azonenberg | Most of the interesting stuff in the CPU is related to register file and pipeline tweaks for efficient multithreading | 08:16 |
azonenberg | but that's all RTL modifications | 08:16 |
azonenberg | i'm taking great pains to make sure it'll work with gcc | 08:16 |
azonenberg | Unmodified gcc | 08:16 |
azonenberg | Which means emulating things like branch delay slots even if the microarchitecture doesn't strictly require them | 08:16 |
azonenberg | I'll probably cut a few of my planned ideas and simplify stuff | 08:19 |
azonenberg | But i might keep working on it in my spare time after i graduate | 08:19 |
azonenberg | because this is what i plan on using to run my homebrew laptop | 08:19 |
azonenberg | Anyway, enough talking about code i haven't yet written :p | 08:23 |
azonenberg | things are likely to change a lot before i actually get to that point | 08:23 |
azonenberg | Lol | 08:30 |
azonenberg | lekernel: So IDK if i mentioned but i'm writing a F/OSS toolchain for coolrunner-ii CPLDs | 05:34 |
---|---|---|
azonenberg | i figure i'll let wolfspraul and company work on spartan6, thats a nice goal but is a huge undertaking | 05:34 |
azonenberg | CR-II is small enough to actually be tractable for a one-man operation | 05:34 |
azonenberg | I have the bitstream structure largely reversed and am able to load them into memory and serialize back to disk, then load the resulting image onto the chip | 05:35 |
azonenberg | there's a handful of fields i haven't figured out (like a dozen 2-input muxes and one part of the crossbar) but another few hours of work is all that will take | 05:35 |
azonenberg | then i can work on a place-and-route setup | 05:35 |
azonenberg | xiangfu: did you miss what i just said about the CPLD stuff? | 05:46 |
azonenberg | (00:35:13) azonenberg: I have the bitstream structure largely reversed and am able to load them into memory and serialize back to disk, then load the resulting image onto the chip | 05:46 |
azonenberg | (00:35:38) azonenberg: there's a handful of fields i haven't figured out (like a dozen 2-input muxes and one part of the crossbar) but another few hours of work is all that will take | 05:46 |
azonenberg | (00:35:49) azonenberg: then i can work on a place-and-route setup | 05:46 |
azonenberg | i did a test an hour ago of taking an object-oriented in-memory representation of a design (loaded from an ISE-generated bitstream), serializing to a bitstream, then loading onto the chip | 05:47 |
azonenberg | at this point it's just figuring out which 2-bit value for a mux corresponds to which of the input choices, etc | 05:47 |
azonenberg | he does have the stuff on github but i havent looked at it much | 07:39 |
azonenberg | been busy with the CPLDs | 07:39 |
azonenberg | thats a separate codebase since the architecture has basically nothing in common | 07:39 |
lekernel | azonenberg, sounds cool! | 07:39 |
azonenberg | lekernel: it appears XC2C has only one bit per IO bank for input and one for output standard | 07:39 |
azonenberg | low range (LVCMOS18/LVCMOS15) and high (LVCMOS33/LVCMOS25/LVTTL) | 07:40 |
azonenberg | the detailed standard values affect timing analysis but not the bitstream | 07:40 |
roh | azonenberg: cool stuff. looking forward to play with it. | 09:37 |
azonenberg | roh: lol | 09:39 |
azonenberg | Give me 5 mins and i'll pastebin some output | 09:40 |
azonenberg | Yeah | 09:40 |
azonenberg | I'm only supporting XC2C32A for now but the code will scale to other stuff too | 09:41 |
azonenberg | Yeaj | 09:41 |
azonenberg | xc2c32a is $1.20 in the US for the cheapest package/speed | 09:42 |
azonenberg | only ~750 gate equivalents and 32 flipflops | 09:42 |
azonenberg | but still, *any* programmable logic with a F/OSS toolchain is a lot better than none | 09:42 |
azonenberg | I'm just confused as to what is going on with the xilinx toolchain | 09:44 |
azonenberg | going from an in-memory bitstream image for the CPLD to a ROM image takes them 1.6 seconds | 09:44 |
azonenberg | my code at the moment runs in 40ms | 09:44 |
azonenberg | either i'm missing something or they did something really dumb | 09:44 |
azonenberg | i'm not far enough along yet to know which | 09:45 |
azonenberg | Lol | 09:45 |
azonenberg | a strace shows that they load 85KB of XML with static timing analysis info | 09:46 |
azonenberg | that process has no output | 09:46 |
azonenberg | and runs on a netlist that's already placed and routd | 09:46 |
azonenberg | Lol, yes | 09:46 |
azonenberg | Lol | 09:47 |
azonenberg | The second | 09:47 |
azonenberg | that screams "java" to me | 09:47 |
azonenberg | Lol | 09:48 |
azonenberg | roh: http://pastebin.com/raw.php?i=PkJnMYK3 | 09:48 |
azonenberg | This is my code to date running on an XC2C32A bitstream consisting of the single verilog line "assign dout = ~din" | 09:49 |
azonenberg | din is LVCMOS33 on pin 28 and dout is LVCMOS33 on pin 38 | 09:49 |
azonenberg | Lol | 09:53 |
azonenberg | The *s in the arrays mean there's a connection, a space means no connection | 09:53 |
azonenberg | Drawing a NOT gate in UTF-8 is a pain in the neck :P | 09:53 |
azonenberg | Notice a lot of the fiedls are still numeric values | 09:54 |
azonenberg | fields* | 09:54 |
azonenberg | rather than descriptive names | 09:54 |
azonenberg | Those are the ones i have not yet figured out | 09:54 |
azonenberg | Yes | 09:54 |
azonenberg | I am quite confident i will have the structure mostly figured out by the end of the weekend | 09:54 |
azonenberg | The next step will be to take the library and start building a place-and-route tool in front of it (given an optimized, unplaced netlist and constraints) | 09:55 |
azonenberg | Then I can decide whther to try to adapt iverilog to be a front end or try to roll my own | 09:55 |
azonenberg | One design decision is final already | 09:55 |
azonenberg | I am not going GPL | 09:55 |
azonenberg | BSD license | 09:55 |
azonenberg | The only reason for GPL is to prevent third parties from stealing your work and turning it into a proprietary product | 09:56 |
azonenberg | nobody but xilinx would have any reason to do that | 09:56 |
azonenberg | and xilinx has a full-time team of programmers working on this | 09:56 |
azonenberg | they don't need my spare-time project :p | 09:56 |
roh | azonenberg: you think... well... all the current xilinx stuff was some other companies before | 09:56 |
azonenberg | This entire codebase, btw, was the work of two or three days | 09:56 |
azonenberg | roh: also, the bigger thing | 09:56 |
azonenberg | why would anyone pay for their fork when mine is open source and costs nothing :p[ | 09:57 |
azonenberg | If they end up merging my code into their product i wouldn't complain | 09:57 |
azonenberg | i'd be honored | 09:57 |
lekernel | azonenberg, how far are you from verilog/vhdl-style synthesis? | 09:57 |
azonenberg | lekernel: I'm not even touching that | 09:57 |
azonenberg | Right now what i'm doing is compiling simple dummy designs and manipulating them | 09:57 |
roh | azonenberg: fork means 'it stays open' .. thats not what happens when companies use bsd code. | 09:58 |
azonenberg | roh: they'd make a private fork and commercialize it, sure | 09:58 |
azonenberg | But it won't stop this version from being useful | 09:58 |
azonenberg | So i really don't care | 09:58 |
azonenberg | lekernel: XST -> cpldfit -> hprep6 -> JED file is the normal workflow | 09:58 |
azonenberg | My library can do JED -> in-memory image | 09:59 |
azonenberg | in-memory image -> JED | 09:59 |
azonenberg | and in-memory image -> programmed CPLD | 09:59 |
roh | azonenberg: well.. thats where we differ ;) i like to keep free stuff free. i see it as a step back. but i respect such decisions. | 09:59 |
azonenberg | what i'm working on now is making the in-memory image be intellegible | 09:59 |
azonenberg | rather than say a variable called "fb" with the value 3, which is pretty meaningless | 10:00 |
azonenberg | so basically creating enums for all of the muxes | 10:00 |
azonenberg | figuring out how the interconnect matrix works | 10:00 |
azonenberg | etc | 10:00 |
azonenberg | The next step will be to use the C++ API i have now as the underlying framework for a place-and-route tool | 10:00 |
azonenberg | Objects fit very nicely for what i'm doing | 10:01 |
azonenberg | I could make a C front end to the PAR tool i guess | 10:01 |
azonenberg | anyway, you'd synthesize to some kind of equation format and then feed that to the PAR tool | 10:01 |
azonenberg | I've written enough C++ i've grown to like it | 10:02 |
azonenberg | But you have to use it carefully | 10:02 |
azonenberg | i dont go all-out with crazy stuff | 10:02 |
azonenberg | i usually treat it as C with the ability to put functions in structs :p | 10:02 |
azonenberg | Because the syntactic sugar increases my productivity | 10:03 |
azonenberg | don't like it, fork my code :P | 10:03 |
azonenberg | or write a wrapper | 10:03 |
azonenberg | Example JED file from the Xilinx toolchain (what my app generated that visualization from) http://pastebin.com/8pQgE7j3 | 10:04 |
azonenberg | Output from my tool (syntactically equivalent but pretty-printed) http://pastebin.com/3bdezXyu | 10:04 |
azonenberg | Oh, and at some point in the pipeline I need to do static timing analysis | 10:06 |
azonenberg | The big thing about C++ that i use in this code is inheritance, in some cases multiple | 10:09 |
azonenberg | that's mostly in the JTAG HAL library though, not the bitstream stuff | 10:10 |
azonenberg | libcrowbar links to libjtaghal but libjtaghal can be used standalone as well | 10:10 |
azonenberg | lekernel: at some point i would eventually (i dont have the time now) make a behavioral model of the xc2c32a | 10:14 |
azonenberg | it will be theoretically synthesizeable but use a huge number of FFs and likely not meet timing | 10:14 |
azonenberg | http://pastebin.com/raw.php?i=zvtj7U8U :) | 11:54 |
azonenberg | Figured out FF edge triggering | 11:54 |
azonenberg | Ten more fields to figure out, a couple of which are already mostly reversed but not quite fully | 11:54 |
azonenberg | then global interconnect and i'm done | 11:54 |
azonenberg | xiangfu: ping | 09:08 |
---|
azonenberg | i just spent a whole day hunting down this bug... writing to a FIFO with data synchronous to clock A | 18:06 |
---|---|---|
azonenberg | when you told the buffer to sample on clock B, which has no phase relationship | 18:06 |
azonenberg | tends to not end well | 18:06 |
azonenberg | silly typos :P | 18:06 |
azonenberg | larsc: yeah, that would be nice | 18:10 |
azonenberg | This is a textbook mandelbug lol | 18:11 |
azonenberg | "A bug whose underlying causes are so complex and obscure as to make its behavior appear chaotic or even non-deterministic. This term implies that the speaker thinks it is a Bohr bug, rather than a heisenbug" | 18:11 |
larsc | azonenberg: yea, it's a nice method for introducing random failures | 18:14 |
azonenberg | wpwrak: "A design or implementation bug in a program that doesn't manifest until someone reading source or using the program in an unusual way notices that it never should have worked, at which point the program promptly stops working for everybody until fixed" - lol | 18:17 |
azonenberg | i know those | 18:17 |
azonenberg | lol | 18:29 |
wpwrak | azonenberg: btw, with your chip disassembly procedures, could you strip a chip (e.g., an FPGA) to the point where it would still work but where you'd have little enough material between the silicon and the outside that you could obtain meaningful chip temperature measurements | 17:40 |
---|---|---|
azonenberg | wpwrak: You can remove the epoxy entirely using HNO3 and leave bond wires intact | 17:43 |
azonenberg | then do IR temp measurements | 17:44 |
azonenberg | Using nitric acid, yes | 17:44 |
azonenberg | these days i've been mostly doing sulfuric which is less precise but cheaper and easier to get | 17:44 |
azonenberg | sulfuric reacts slowly so you have to heat it a lot and just soak it in the tank for like half an hour or so | 17:48 |
azonenberg | nitric is much faster and more aggressive but if done right you can control it pretty precisely | 17:48 |
azonenberg | if all you wnat is a bare die then sulfuric is fine | 17:48 |
azonenberg | http://siliconpr0n.org/wiki/lib/exe/detail.php?id=tutorial%3Atutorial_on_epoxy_decapsulation&media=image:walkthrough08s.jpg | 17:48 |
azonenberg | http://siliconpr0n.org/wiki/lib/exe/detail.php?id=tutorial%3Atutorial_on_epoxy_decapsulation&media=image:walkthrough07.jpg | 17:49 |
azonenberg | that's what a chip done using nitric looks like if prepared skillfully | 17:49 |
azonenberg | We drilled it first to a little above the die and then put the acid in the well | 18:08 |
azonenberg | makes for a much cleaner decap and less risk of damaging the leadframe | 18:08 |
azonenberg | oh, and a lot faster too | 18:10 |
azonenberg | less stuff to etch | 18:10 |
azonenberg | You have to heat it or it wont etch at any appreciable rate | 18:11 |
azonenberg | normally you run the decap at 150C ish | 18:11 |
azonenberg | red fuming nitric can decap at room temp if you let it sit overnight | 18:11 |
azonenberg | lower concentrations absolutely must be heated, as with sulfuric | 18:11 |
azonenberg | lo,l | 18:20 |
azonenberg | I use 1 part HCl to 6 parts 3% H2O2 | 18:21 |
azonenberg | at ~80C for aggressive etch or slghtly above room temp for controllable | 18:21 |
azonenberg | lol | 20:45 |
azonenberg | 35%? Ok, lol | 20:45 |
azonenberg | RCA-2 is 1 part conc HCl, one part 30% H2O2 | 20:45 |
azonenberg | ... and 6 parts water to slow down the reaction to sane rates :P | 20:45 |
azonenberg | Lol | 21:00 |
azonenberg | I note also that RCA-2 is meant for *stripping* metal (when used at 85C that is) | 21:00 |
azonenberg | Not for controlled etching | 21:00 |
azonenberg | It works reasonably well for PCBs at a less elevated temperature | 21:01 |
azonenberg | for wet etching IC-level features I normally use ten parts water to one part of RCA-2 | 21:02 |
azonenberg | etch rate of that is a few hundred nm per minute i believe | 21:02 |
azonenberg | Yeah, and more importantly somewhat controllable | 21:03 |
azonenberg | lol | 21:03 |
azonenberg | where'd wolfspraul go lately? havent seen him around | 08:44 |
---|---|---|
azonenberg | lol | 08:51 |
azonenberg | i was going to tell him that i got a new decap setup so i can get some die pics now | 08:51 |
azonenberg | next time someone sees him send him this http://siliconexposed.blogspot.com/2013/01/new-decap-setup.html | 08:51 |
kyak | azonenberg: you might as well use memoserv (/quote memoserv help) | 09:28 |
azonenberg | didnt know there was one here | 09:28 |
azonenberg | and thanks | 09:28 |
kyak | azonenberg: correct me if i'm wrong. Decapping of MCU allows not only to break protection, such as read-only switch, but also reproduce the MCU? | 09:42 |
azonenberg | Depackaging just lets you look at it | 09:43 |
azonenberg | What you do after that is up to you | 09:43 |
azonenberg | kyak: Given enough time, effort, and electron microscope time you could fully clone the chip (ignoring legal issues) | 09:44 |
azonenberg | But my interest is not in cloning devices, I want to see how they work | 09:44 |
azonenberg | As well as security analysis | 09:44 |
azonenberg | My group is mostly interested in building a body of public knowledge on how IC reversing works | 09:46 |
azonenberg | While the fab of small devices is a lot harder than large ones, once you have photos it's no harder to figure out how they work (ignoring scalability issues in the analysis tools for huge netlists, etc) | 09:46 |
azonenberg | So we mostly stick to >=350nm devices which are possible to study by optical microscopy | 09:47 |
azonenberg | since SEM is somewhat pricey to get time on and optical scopes are free (I have four in my lab i can use whenever i want) | 09:47 |
azonenberg | That said, I do want to see a spartan6 naked at some point and the lower levels will need a SEM | 09:47 |
wpwrak | azonenberg: you need to integrate this: eching and scanning in one easy device. put in the chip, press a button, out come transistor-level pictures :) | 11:28 |
larsc | azonenberg: over at #homecmos wolfgang is actually creating quite some noise | 14:20 |
azonenberg | wpwrak: i have a board here http://uploads.oshpark.com/uploads/project/top_image/xcxzJIC7/i.png that is along those lines but a little more complex | 04:49 |
---|---|---|
azonenberg | 4 layers since i wanted to make it tiny :P | 04:49 |
azonenberg | FT232H for JTAG plus an oscillator and an XC2C32A/64A CPLD | 04:50 |
azonenberg | should be a self-contained dev board | 04:50 |
azonenberg | I wanted enough LEDs and buttons to be able to develop my toolchain on it | 04:52 |
azonenberg | i wanted access to a lot of pins | 04:52 |
azonenberg | otherwise you could be simpler | 04:52 |
azonenberg | makes sense | 04:52 |
azonenberg | I haven't stressed my lx9's much | 04:54 |
azonenberg | But, low | 04:54 |
azonenberg | That's probably high | 04:55 |
azonenberg | i pulled ~100 from an LX25 at 160 MHz with a NoC prototype and a softcore CPU | 04:55 |
azonenberg | but my lx9 boards are not instrumented | 04:55 |
azonenberg | so i can't give you numbers | 04:55 |
azonenberg | I've been using 1117-series on my little boards and it's fine | 04:56 |
azonenberg | http://colossus.cs.rpi.edu/pictures/2012/August/8-18-2012%20-%20dev%20setup/S7302890.JPG | 04:56 |
azonenberg | Those numbers are for 3v3, 2v5, 1v2 rails on the entire board in the upper left | 04:56 |
azonenberg | most of the 3v3 is consumed by the 10/100 ethernet | 04:57 |
azonenberg | when the DDR RAM is active it pulls like 500mA from the 2.5V rail between the core, I/O, and FPGA | 04:57 |
azonenberg | I don't think i've ever gotten an lx25 above 150 mA on the 1v2 rail | 04:57 |
azonenberg | so 100 as a ceiling for an lx9 sounds entirely realistic | 04:58 |
azonenberg | you can see all of the little boards are lx9 based | 04:58 |
azonenberg | Have you looked at my lx9 mini board btw? | 04:58 |
azonenberg | i have the kicad files for the little lx9 boards in that picture public | 04:59 |
azonenberg | Depends on how ismple you want | 05:00 |
azonenberg | i wanted enough peripherals that it was still useful | 05:00 |
azonenberg | but its far from disposable in that state | 05:00 |
azonenberg | well it works | 05:01 |
azonenberg | oh and the cpld board is self-contained | 05:08 |
azonenberg | has onboard jtag | 05:08 |
azonenberg | annoying but i havent yet made anything of my own that is better | 05:08 |
azonenberg | have you guys had bad experiences wit hthem? | 05:08 |
azonenberg | i spent a lot of time hunting down bugs from their driver, libftdi was just as buggy | 05:08 |
azonenberg | 232h allows mpsse mode | 05:10 |
azonenberg | 232r does not | 05:10 |
azonenberg | yeah, the r is uart only + basic bitbang | 05:11 |
azonenberg | the h has mpsse | 05:11 |
azonenberg | the original 2232 did not do mpsse either | 05:11 |
azonenberg | it didnt? o_O | 05:11 |
azonenberg | i had issues with data being lost on reads too | 05:12 |
azonenberg | on the 2232h | 05:12 |
azonenberg | took me like a week to figure out a hack of repeated reads and polls that seems to work | 05:12 |
azonenberg | i do not like it, but it's the best i've found so far | 05:13 |
azonenberg | i will be making a custom jtag dongle soon thouhg | 05:13 |
azonenberg | well the goal here was on-board programming | 05:15 |
azonenberg | i wanted something i could integrate int oa board and make it not need external hardwar | 05:15 |
azonenberg | well i already have libjtaghal working for most of this stuff | 05:20 |
azonenberg | i just need to build myself a smart in-circuit debug module | 05:20 |
azonenberg | so i dont have four usb packet latencies being added to every operation | 05:20 |
azonenberg | my new module will have an fpga and gig-e | 05:21 |
azonenberg | and do as much smarts as possible in the adapter | 05:21 |
azonenberg | most of my boards need more current anyway | 05:23 |
azonenberg | and some have unusual clock requirements | 05:23 |
azonenberg | there are some things i'm sure its good for but this isnt one :p | 05:23 |
azonenberg | lol | 05:25 |
azonenberg | lol | 05:27 |
azonenberg | Can the MM1 do 1080p btw? | 05:29 |
azonenberg | or only 720 | 05:29 |
azonenberg | well spartan6 cannot drive 1080p with the SERDES onboard but it could drive an external HDMI PHY | 05:33 |
azonenberg | which would allow it | 05:33 |
azonenberg | why? | 05:49 |
azonenberg | lekernel: so i see you saw my FB status | 12:26 |
---|---|---|
azonenberg | What are you guys doing for in-circuit debug, if anything? | 12:26 |
azonenberg | both hardware and software | 12:26 |
azonenberg | lekernel: also if i want to cite migen in a paper i'm working on, do you have a specific paper/article etc that i should reference? | 12:32 |
azonenberg | A BibTeX citation would be desirable if possible ;) | 12:32 |
lekernel | azonenberg, hmm, http://milkymist.org/3/migen.html or http://milkymist.org/3/migen.pdf | 13:34 |
azonenberg | lekernel: ok | 13:34 |
azonenberg | I'm doing some work on NoC for my thesis and am thinking of exploring methods of automatically generating optimal topologies from activity traces | 13:34 |
azonenberg | so i'm looking for prior examples of programmatically generating bus/NoC topology | 13:35 |
azonenberg | And I see, i'm trying to get something a little more involved | 13:35 |
azonenberg | Do you guys do hardware cosimulation at all? | 13:35 |
azonenberg | You guys would love the stuff i'm developing then | 13:36 |
azonenberg | i need another month or so to get it to the point that it's usable | 13:36 |
azonenberg | And i'm not sure how hard it would be to port it to wishbone since a few of the modules have hard-coded my NoC frame structure | 13:36 |
azonenberg | But basically I make a VPN into the NoC from my PC | 13:37 |
azonenberg | and then am able to send NoC frames to any core on the chip over TCP sockets | 13:37 |
azonenberg | From any application on my laptop including but not limited to a bridge that talks to ISim | 13:37 |
azonenberg | i have a verilog core that pretends to be a NoC router and sends frames to the nocswitch binary which then forwards over jtag to the board | 13:38 |
azonenberg | all of the routing just works because of the hierarchal address space, the simulated stuff just shows up as another block of address space | 13:38 |
azonenberg | And since the NoC is multimaster i can then send traffic to any core on the bus from it | 13:38 |
azonenberg | So I could code up a quick testbench, run it in the simulator, have it send messages to real hardware, and print everything that goes between them | 13:39 |
lekernel | azonenberg, btw, any luck with coaxing ACM into putting your paper into the public domain? | 13:39 |
azonenberg | I haven't submitted anything yet | 13:39 |
azonenberg | I'm putting most of my effort now into a survey paper | 13:40 |
azonenberg | Both because it's my research qualifying exam, and because it will give me a better idea of prior work related to what i'm doing | 13:40 |
azonenberg | oh joy | 13:41 |
azonenberg | Submit to another journal instead? :P | 13:41 |
azonenberg | also, yay - my issue tracker has <50 tickets on it for the first time in a week :D | 13:42 |
azonenberg | open, that is | 13:42 |
azonenberg | sneaky | 13:47 |
azonenberg | So you let them claim the rights to the paper and then you publish the TR | 13:48 |
azonenberg | make the TR slightly more in-depth | 13:48 |
azonenberg | and the journal can hardly complain about you releasing your future work | 13:49 |
azonenberg | what i mean is, by making the TR look like it came after the paper | 13:49 |
azonenberg | the journal can't complain about you publishing work you did "after" the paper that happens to include some of the old material | 13:49 |
wpwrak | azonenberg: naw, no need to go extremes trying to hide things. there's not much of a conflict anyway. the IEEE/Springer/Elsevier/etc. publications have their role for scoring anyway. it's only now that this is changing | 13:50 |
azonenberg | yeah, that's the tricky part | 13:51 |
azonenberg | not being the same thing | 13:51 |
azonenberg | Yeah, adding new content is to me the biggest thing that makes the TR different | 13:53 |
azonenberg | yep | 13:53 |
azonenberg | Yeah | 13:55 |
azonenberg | The big thing is, it would be seen as unreasonable for them to prohibit you from publishing a TR based on work you did after the journal paper was submitted | 13:56 |
azonenberg | and it's expected that you'd include your earlier work for background | 13:56 |
azonenberg | legally it's still a copyright gray area, especially if you re-use figures etc | 13:56 |
azonenberg | I have free access through my school but the numbers i see are absurd | 13:57 |
azonenberg | $20+ for one paper | 13:57 |
azonenberg | Yeah | 13:57 |
azonenberg | lekernel: oh, i believe it | 13:57 |
azonenberg | So far my only cited paper has never been published in such a journal | 13:57 |
azonenberg | i just posted it on my own website and people found it | 13:57 |
azonenberg | lol | 14:04 |
azonenberg | i am a very applied person too | 14:05 |
azonenberg | But I like to do pure applications and not waste time with such frivolities as how to make money with it | 14:05 |
azonenberg | which most companies sadly seem to put as their first priority | 14:06 |
azonenberg | the world needs more nonprofit R&D labs | 14:06 |
azonenberg | My first priority is "solve $PROBLEM as well as i possibly can" | 14:07 |
azonenberg | not "solve $PROBLEM well enough to meet the needs of 70-80% of our potential customer base, at the minimum cost, while doing just enough work that they don't demand refunds" | 14:08 |
azonenberg | Or built a nuclear device :P | 14:08 |
azonenberg | If all of the bored engineers in the world got together we could probably build a small nuke in a few years' time | 14:09 |
azonenberg | lol | 14:10 |
azonenberg | i'm actually idly curious about that | 14:11 |
azonenberg | there are all kinds of nonproliferation treaties restricting what you can export | 14:11 |
azonenberg | But i suspect if a group within say the USA decided to build a nuke from domestic parts it would be a lot easier :P | 14:11 |
azonenberg | Back to on-topic stuff | 14:12 |
azonenberg | i've been noticing an annoying problem with kicad, it always puts a pad around a via on every layer | 14:12 |
azonenberg | even if you are not connecting to it | 14:12 |
azonenberg | Which means if I have a via from top to bottom, an inner layer trace has to stay (annular ring + clearance) away from it | 14:13 |
azonenberg | lekernel: maybe i can make it to the next one in person | 14:13 |
azonenberg | how did john's talk go? | 14:13 |
azonenberg | lekernel: :( | 14:15 |
azonenberg | BTW idk if i mentioned before in here but i was looking at the coolrunner-ii CPLDs | 14:15 |
azonenberg | as a side project in parallel with fpgatools | 14:15 |
azonenberg | they're about the cheapest programmable logic around (at least for the small like 32 macrocell units) | 14:15 |
azonenberg | the bitstreams are tiny | 14:16 |
azonenberg | And the JED files xilinx tools generate have comments in them :D | 14:16 |
azonenberg | they partition the fuses into the AND array, the OR array, the interconnect, global clock, etc | 14:16 |
azonenberg | I feel like once i have time to sit down and play with it i could probably bang out a basic compiler in a few weeks | 14:16 |
azonenberg | at most | 14:16 |
azonenberg | wolfgang's work is all well and good for high-capacity stuff but CR-II is something i think we could feasibly have a full FOSS toolchain for pretty quickly | 14:17 |
azonenberg | libjtaghal can already program spartan-6 and as soon as a board i designed (currently at the fab) with an FT232H and XC2C32A is done i will write a CR-II bitstream loader module for it | 14:19 |
azonenberg | So we could have a full end-to-end FOSS toolchain for *a* currently shipping programmable logic device | 14:19 |
azonenberg | Even if it is just a 32-macrocell CPLD (with eventual scaling to larger devices) | 14:20 |
azonenberg | i'm debating whether to try writing my own super-simple synthesis tool or try to hack iverilog | 14:20 |
azonenberg | since it no longer seems to support synthesis | 14:20 |
azonenberg | For the first attempt of course i'll be entering manual sum-of-products expressions by hand in some kind of text file | 14:20 |
azonenberg | wpwrak: well it's actively in progress | 14:21 |
azonenberg | i'm going bottom up | 14:21 |
azonenberg | first, load flash images onto the chip (that's waiting on the board) | 14:21 |
azonenberg | then, take hand-generated product terms and config settings and make a bitstream | 14:21 |
azonenberg | then synthesize verilog to that intermediate represnetation | 14:21 |
azonenberg | first target is XC2C32A, then scaling to larger CR-II devices later on | 14:22 |
azonenberg | the 64a is pin compatible in tqfp 44 so i can put it on the same PCB and test it too | 14:22 |
azonenberg | there isnt much with the coolrunners | 14:22 |
azonenberg | the arch seems pretty simple and well documented | 14:22 |
azonenberg | The bitstream almost doesn't need reversing | 14:23 |
azonenberg | http://pastebin.com/G07Wb6Tw | 14:23 |
azonenberg | This is what the xilinx tools generate | 14:23 |
azonenberg | look at that | 14:23 |
azonenberg | "Block 0 PLA AND array" is a comment in the source | 14:23 |
azonenberg | this is the equivalent of a .bit | 14:24 |
azonenberg | this is not output from my tools, the compiler generates it | 14:24 |
azonenberg | And each one of those 1s and 0s is directly written to a flash cell | 14:24 |
azonenberg | Sure, but not much | 14:24 |
azonenberg | The chip starts at $1.20 for the lowest speed grade in single units | 14:24 |
azonenberg | So it would be a great stepping stone | 14:24 |
azonenberg | It can't share much code with fpgatools since the microarchitecture is so different, unfortunately | 14:25 |
azonenberg | FPGA bitstreams you need to start from scratch more since the bit file isnt commented | 14:25 |
azonenberg | and there are soooo many different types of tile | 14:25 |
azonenberg | the CPLD is basically a PLA and a bit of global routing | 14:26 |
azonenberg | and nothign else | 14:26 |
azonenberg | no ram, no multipliers | 14:26 |
azonenberg | n oserializers | 14:26 |
azonenberg | Which makes it a very attractive first study target | 14:26 |
azonenberg | 32 macrocells is the smallest CR-II device | 14:27 |
azonenberg | each macrocell is able to implement a sum-of-products expression with up to i think around 56 inputs | 14:27 |
azonenberg | or is it 40? | 14:27 |
azonenberg | i have this written down somewhere | 14:27 |
azonenberg | and then output both directly and throguh a flipflop | 14:27 |
azonenberg | in my experience, once you start doing state machines the limiting factor is running out of FFs | 14:28 |
azonenberg | Yes | 14:28 |
azonenberg | But the CR-II line gets bigger | 14:28 |
azonenberg | they go up to 512 macrocells | 14:28 |
azonenberg | larsc: no, they aren't LUT based | 14:28 |
azonenberg | CPLD microarchitecture is very different | 14:28 |
azonenberg | it's a big and-or array | 14:28 |
azonenberg | wpwrak: Those are $$$ though | 14:28 |
azonenberg | 256 is like $20 | 14:28 |
azonenberg | 384 and 512 are absurd | 14:28 |
azonenberg | But 32/64/128 are relatively cheap | 14:29 |
azonenberg | those are my main targets, for glue-logic type applications | 14:29 |
azonenberg | if you need more than 128 macrocells for your system, go talk to wolfgang :P | 14:29 |
azonenberg | iirc 256 macrocells is enough to fit a picoblaze CPU | 14:30 |
azonenberg | or is it 128 | 14:30 |
azonenberg | but it needs external flash for the program rom i think | 14:30 |
azonenberg | Yes | 14:31 |
azonenberg | Its not cost effective to buy big cplds | 14:31 |
azonenberg | Hence why the small ones are my target | 14:31 |
azonenberg | xc6slx4/9 start at like $8-10 | 14:31 |
azonenberg | but you can get 32 / 64 / 128 macrocells of CR-II cheaper | 14:31 |
azonenberg | and in a nice friendly 0.8mm TQFP for the 32/64 | 14:31 |
azonenberg | noob friendly | 14:31 |
kristianpaul | azonenberg: Hi, is your NoC related work going or already been public? | 15:09 |
Fallenou | 15:13 < azonenberg> how did john's talk go? < it was really good ! | 15:40 |
azonenberg | kristianpaul: will be made public, yes | 16:42 |
azonenberg | is, no | 16:42 |
azonenberg | Step 1, debug infrastructure | 16:47 |
azonenberg | I will be publishing that as well as a survey paper in the spring some time | 16:47 |
azonenberg | step 2, build something on top of that | 16:47 |
azonenberg | Will be published when i finish my thesis | 16:47 |
azonenberg | there may be other intermediate steps too | 16:47 |
johndmcmaster | lekernel: I'm lurking around berlin a few days before EHSM (there now). azonenberg says you like to do urban exploring. if you are doing something interesting (that or something else) give me a ping if you don't mind some company :) | 08:01 |
---|
azonenberg | kristianpaul: well you have to "cmake .." from the build directory | 00:09 |
---|---|---|
azonenberg | the first time | 00:09 |
azonenberg | but once you have it configured, yes | 00:09 |
azonenberg | just a make | 00:09 |
azonenberg | oh, i never had that problem | 00:19 |
azonenberg | now, getting it to auto-detect the xilinx toolchain was a bit of a pain and i'm still working on version ID | 00:19 |
lekernel | azonenberg: milkymist and milkymist-ng use makefiles. rhino uses a python based system (which I mostly didn't develop). | 11:26 |
azonenberg | Are you guys using ISE as the build system? | 23:32 |
---|---|---|
azonenberg | as in the gui? | 23:32 |
azonenberg | if not, what? | 23:32 |
azonenberg | i see | 23:51 |
azonenberg | http://pastebin.com/gnrCXcbY | 23:51 |
azonenberg | i got some stuff set up to call the xilinx toolchain from cmake | 23:51 |
azonenberg | http://i.imgur.com/mC2js.png | 23:51 |
azonenberg | early WIP: http://pastebin.com/PDK2eNwS | 07:25 |
---|---|---|
azonenberg | working on getting the xilinx toolchain to play nice with CMake/CTest/CDash | 07:26 |
azonenberg | http://cdash.drawersteak.com/index.php?project=Dummy+Project | 07:27 |
azonenberg | http://cdash.drawersteak.com/testDetails.php?test=1&build=1 | 07:27 |
azonenberg | Are you guys doing unit testing now? if so, how? | 07:28 |
azonenberg | kristianpaul: yes | 17:33 |
---|---|---|
azonenberg | the only patent that covered mips1 as of like 4 years ago was the one related to unaligned load/store | 17:33 |
azonenberg | which my core doesnt implement anyway and, i think, expired a year or two ago | 17:33 |
wpwrak | azonenberg: you may find this useful: http://www2.vmi.edu/Faculty/squirejc/Research/IC_Datasheets/digital_cmos/Write%20Only%20Memory.pdf | 00:36 |
---|---|---|
wolfspraul | azonenberg: if you were to tape-out your own chip, what packaging would you choose initially? | 09:16 |
azonenberg | wolfspraul: if i was making an ASIC? Depends on what it did | 12:07 |
azonenberg | For low pin counts i'd likely package one or two in DIP-40 and the rest in TQFP-44 | 12:08 |
azonenberg | if it was higher speed or more I/O intensive i'd use 256FTBGA 1mm | 12:08 |
xiangfu | azonenberg, Hi. I would add a smallest/easiest SPI flash to my mini board. do you have any advice? thanks | 12:31 |
xiangfu | azonenberg, I have another question on your s60-devboard. you soldering all those components in toaster oven? | 12:44 |
azonenberg | wolfspraul: yes, i would | 12:53 |
azonenberg | From what i hear DIP40 is most common for low-speed MOSIS chips used for educational stuff | 12:53 |
azonenberg | but I am more interested in high speed stuff, if i were to get an ASIC fabbed it'd be something with a DDR3 controller and a GHz-range CPU | 12:54 |
azonenberg | xiangfu: Is this for an xc6slx9 boot flash? | 12:54 |
azonenberg | W25Q80BV in 8SOIC | 12:54 |
azonenberg | quad SPI | 12:54 |
xiangfu | azonenberg, yes. for xc6slx9 boot flash. | 12:55 |
azonenberg | and yes, i solder everything in the toaster oven | 12:55 |
azonenberg | You've seen my minimal-s6-tq144 board, right? | 12:55 |
azonenberg | thats what i used on there | 12:55 |
azonenberg | the same chip has enouhg capacity for up to the xc6slx25 iirc | 12:55 |
azonenberg | you can go smaller for a lower end chip if you want but i like to keep only a few values in stock since it makes inventory management simpler | 12:55 |
xiangfu | azonenberg, (toaster oven) it's double side. so solder top side first then the bottom side. so you use the top 2 heat pipe? | 12:56 |
azonenberg | FTG256 is the Xilinx code for 256ftbga with SAC305 solder balls | 12:56 |
azonenberg | 256ftbga is a generic name for 1mm 16x16 full array BGA | 12:56 |
azonenberg | FT256 is the xilinx code for the same package with 63/37 solder | 12:57 |
azonenberg | xiangfu: I actually do bottom first | 12:57 |
azonenberg | G = "green" = lead free | 12:57 |
azonenberg | A tiny fraction for military etc are not | 12:57 |
azonenberg | due to reliability concerns | 12:58 |
xiangfu | azonenberg, (you can go smaller for a lower end chip) what is the lower/smaller chip? I would look into that one too. :-) | 12:58 |
azonenberg | xiangfu: since that tends to be lightweight components | 12:58 |
azonenberg | which wont fall off | 12:58 |
azonenberg | I want to avoid gluing and have surface tension hold stuff on | 12:58 |
azonenberg | So i do bottom first (facing up) since solder paste isnt sticky until it melts | 12:58 |
azonenberg | then let cool, flip over, do top side with all the big stuff | 12:58 |
azonenberg | and rely on surface tension to hold the bottom stuff on | 12:58 |
azonenberg | and read the configuration guide, it gives bitstream sizes for each fpga | 12:59 |
azonenberg | w25q40 or 20 will likely be fine for the lx9 | 12:59 |
azonenberg | SPI flash is pretty industry standard | 12:59 |
azonenberg | the only real variables are package, array size, operating voltage | 12:59 |
azonenberg | and whether it's true SPI only or supports dual/quad mode | 13:00 |
azonenberg | the winbond chips normally support quad mode, check the datasheet | 13:00 |
azonenberg | most micron parts in the M25PE80 family do not | 13:00 |
azonenberg | i used to use the m25pe80 with spartan3a but 6 supports quad mode that boots 4x faster at the same clock rate | 13:00 |
azonenberg | xiangfu: and yes, you just have to design the board with that asseembly process in mind | 13:00 |
azonenberg | Meaning you want lots of surface area for solder and not much mass | 13:01 |
azonenberg | so avoid, say, big electrolytic caps on the underside | 13:01 |
azonenberg | and a QFN with thermal pad would be preferred over a TQFP | 13:01 |
xiangfu | azonenberg, thanks for advice. | 13:04 |
azonenberg | xiangfu: also that means that if a large heavy connector must be on the underside | 13:04 |
azonenberg | it needs to be hand soldered after reflow or it'd fall off | 13:04 |
azonenberg | in a real production process you'd put a dab of high-temperature glue under each part on the underside and have much fewer restrictions | 13:04 |
wpwrak | azonenberg: i kinda wonder why people still even consider DIP. well, except for cases of extreme mechanical stress perhaps. | 13:04 |
xiangfu | azonenberg, I am making a very simple board. with only jtag pins out now. :) | 13:05 |
azonenberg | wolfspraul: I use winbond | 13:05 |
xiangfu | azonenberg, checkout: http://downloads.openmobilefree.net/tmp/IMG_1732.JPG and http://downloads.openmobilefree.net/tmp/IMG_1734.JPG | 13:05 |
azonenberg | wpwrak: the only thing it'd be good for is prototyping on a very expensive but low speed ASIC before you made a board for it | 13:05 |
azonenberg | and if you had sockets even then tqfp would be better | 13:05 |
azonenberg | wpwrak: agreed | 13:06 |
azonenberg | wolfspraul: thats more than i can afford right now :P | 13:06 |
azonenberg | xiangfu: also, is that a 1-layer board for ftg256? Impressive | 13:07 |
azonenberg | even if you dont use all the pins, breaking everything out would be tricky | 13:07 |
xiangfu | azonenberg, yes. 1-layer. I don't have drilling machine now. | 13:07 |
azonenberg | so you have all the IO banks and vccaux at one voltage | 13:07 |
azonenberg | then vccint at 1.2 | 13:07 |
azonenberg | why didnt you go tqfp? | 13:08 |
azonenberg | or did you want to use the lx16 and 25 too? | 13:08 |
xiangfu | azonenberg, I want experience bga. :-) | 13:10 |
azonenberg | Oh, i see | 13:10 |
azonenberg | Makes sense | 13:10 |
azonenberg | Though i think you will find it vastly easier with ENIG and soldermask | 13:10 |
azonenberg | wpwrak: the problem is that it sticks up | 13:10 |
azonenberg | so you cant put it under QFPs | 13:10 |
wpwrak | azonenberg: yup. there are limitations :) | 13:11 |
azonenberg | wpwrak: and since i use low-profile smt so much i dndt even bother develponig that process | 13:11 |
azonenberg | since the limitations were such that i'd gain next to nothing | 13:11 |
azonenberg | yes, 0.5mm is at the edge of what i can homebrew too | 13:12 |
azonenberg | xiangfu: Read the datasheet for recommended sizes | 13:13 |
xiangfu | azonenberg, the 1200DPI printer will give good result on photo paper. | 13:13 |
azonenberg | I normally use 0.45mm pads for 0.5mm balls on 1mm centers | 13:14 |
azonenberg | wpwrak: i usually use carbide bits from drillbitcity.com with straight shanks | 13:19 |
azonenberg | those are much easier to handle than tiny ones | 13:19 |
azonenberg | 1/8" shanks i meant | 13:19 |
wpwrak | azonenberg: yeah, they also center better in a dremel. at least on digi-key, the price difference is large, though. | 13:21 |
azonenberg | wpwrak: i buy boxes of 50 for $45 | 13:21 |
azonenberg | they're re-sharpened, not new | 13:21 |
xiangfu | azonenberg, I am download the datasheet of w25Q40bw. so you would advice winbond-w25Q40bw for my mini slx9 board. I want the easiest chip. :-) | 13:23 |
azonenberg | bv vs bw is i think just a die revision change so they should be interchangeable | 13:23 |
azonenberg | and the 40 should be fine for the lx9, check the config guide | 13:23 |
azonenberg | W25Q is the family i've used | 13:24 |
azonenberg | W25X may not be protocol compatible | 13:24 |
xiangfu | azonenberg, ok. got it. | 13:25 |
azonenberg | XC5SLX9 needs 2,742,528 config bits | 13:25 |
azonenberg | XC6SLX9* | 13:25 |
azonenberg | So the 2mbit is not enough, the 4 or 8 are fine | 13:25 |
azonenberg | the LX16 bitstream is 3,731,264 bits so even that should fit in a 4 | 13:25 |
azonenberg | if you want to use the 25 you need 8mbits, 45 needs 16, 75 and 100 need 32, 150 needs 64 | 13:26 |
azonenberg | that's from table 5-5 in UG380 | 13:26 |
azonenberg | And of course if you want to store data as well as bitstream | 13:27 |
azonenberg | you will need more capacity | 13:27 |
azonenberg | for the lx if you use 4Mbits you'll have the last ~1mbit free | 13:27 |
azonenberg | the lx9* | 13:27 |
azonenberg | Yeah, thats not something i would try lol | 13:38 |
azonenberg | given the prices i pay for batch PCB fab, if i'm dropping $30 on an FPGA i can afford to spend $25 on three dual-layer professionally fabbed PCBs | 13:38 |
azonenberg | $30 being the going rate for the xc6slx25 around here | 13:38 |
xiangfu | azonenberg, before do oven-soldering have you do any 'moisture protection' on PCB and CHIP. | 13:59 |
azonenberg | I do nothing for pcbs | 14:03 |
azonenberg | i keep bgas in moisture bags | 14:03 |
azonenberg | if theyve been out ofr a whlie i bake | 14:03 |
xiangfu | azonenberg, 'bv vs bw' have different voltage. bv: 3V, bw: 1.8v | 14:10 |
azonenberg | oh, i see | 14:17 |
azonenberg | so B is the die rev | 14:17 |
azonenberg | and V/W are voltage range | 14:17 |
kristianpaul | azonenberg: mips 1 is free of patent? | 15:07 |
azonenberg | Anybody here work with the BSCAN primitive? | 09:09 |
---|---|---|
azonenberg | i'm trying to make an API that allows point-to-point contact through multiplexers from one (or more) PC-based applications to cores on the FPGA | 09:11 |
azonenberg | so that i can have say a gdb bridge and a bus sniffer both running simultaneously using the single jtag interface | 09:11 |
azonenberg | via a packet-switched protocol using USER1 as an address, USER2 as the per-core IR, and USER3 as the per-core DR | 09:12 |
azonenberg | so you basically have virtualized TAPs on each core | 09:12 |
lekernel | azonenberg: http://www.milkymist.org/misc/ml401_flasher-1.0.tar.bz2 | 09:21 |
azonenberg | lekernel: i'll take a look | 09:23 |
azonenberg | does the system i mentioned sound useful? | 09:23 |
azonenberg | i want a TCP server that allows you to configure FPGAs with bitstreams, do boundary scan operations, and communicate with virtualized TAPs on fpgas through the USER* instructions | 09:24 |
azonenberg | it's going to be nice and generic, i'm going to support the Digilent API, openocd, and possibly raw ftdi adapters as back ends | 09:24 |
azonenberg | Yes | 09:35 |
azonenberg | The goal is to expose an API that allows you to open a TCP socket to the server and then select "/scanchain0/device0/core2" | 09:36 |
azonenberg | you will then use a simple frame-based format consisting of {opcode, length, data} or similar | 09:36 |
azonenberg | for example "set IR to 16 bits 0xDEAD" | 09:36 |
azonenberg | "set IR to 32 bits BAADC0DE and return result" | 09:36 |
azonenberg | the idea is to use jtag as a link-layer protocol and define a socket-style transport layer on top | 09:37 |
azonenberg | and then you can run any application-layer traffic you want on top of those connections | 09:37 |
azonenberg | Yep | 09:37 |
azonenberg | I intend to add a RED TIN module for it | 09:37 |
azonenberg | It will also allow you to speak directly to the chip rather than to cores on it | 09:38 |
azonenberg | to query serial numbers, do boundary scan, and Xilinx-specific commands for loading bitstreams etc | 09:38 |
azonenberg | though you could of course add another class that derives from FPGA and JtagDevice other than XilinxSpartan6Device | 09:38 |
azonenberg | It will support plug-and-play to the extent possible | 09:39 |
azonenberg | automatically identifying FPGAs via IDCODE and then querying USER* instructions to see if one of my cores is present on it | 09:39 |
azonenberg | and if so, finding out how many cores are present and getting ID codes off each | 09:39 |
azonenberg | so you'll be able to autodiscover "JTAG plug-and-play controller at address 0", "LM32 GDB interface at address 1", "RED TIN logic analyzer at address 2" | 09:40 |
azonenberg | So then you'd be able to start up RED tin and connect to the server and it'd give you a drop-down list of LA servers discovered | 09:40 |
azonenberg | you could thus have multiple LAs present | 09:40 |
azonenberg | i dont think chipscope can do that :D | 09:40 |
azonenberg | the big problem with chipscope though is that it doesnt play well with softcore ICD since i think it monopolizes the USER* instructions | 09:41 |
azonenberg | this system would be built around multiplexing and sharing from the start | 09:41 |
azonenberg | And by virtue of being socket based, remote config/debug comes almost for free | 09:41 |
azonenberg | Lol | 09:41 |
azonenberg | RED TIn is still a bit buggy but is getting there, and is like 2000 lines of C++ and verilog :D | 09:42 |
azonenberg | 1k of each roughly | 09:42 |
azonenberg | lightweight, does exactly what it needs to and not a single thing more | 09:42 |
azonenberg | Lol | 09:42 |
azonenberg | while meanwhile RED TIN is open source and, while not fully debugged, the first beta tester i gave it to caught a memory controller bug within like an hour or two of downloading it | 09:43 |
azonenberg | i'm a big fan of minimalism in hardware/software design | 09:43 |
azonenberg | well feel free to use this system | 09:45 |
azonenberg | I've only been working on it for a day or so (~1kloc) but will be pushing it to google code under a BSD license in a week or so once i have something actually usable | 09:45 |
azonenberg | it's already able to connect to my Atlys via the embedded Digilent programmer, probe the chain, and identify the chip as an XC6SLX45 rev 3 | 09:45 |
azonenberg | Nice | 09:47 |
azonenberg | I want to play with that at some point too | 09:47 |
azonenberg | Make a bridge over jtag that connects my NoC to the PC | 09:47 |
azonenberg | so i can have emulated and softcore nodes speaking freely | 09:47 |
azonenberg | system-level hardware cosimulation :D | 09:49 |
azonenberg | Hmm, good idea | 09:50 |
azonenberg | i need to play with verilog simulation more and see how to get it to bridge with native APIs | 09:50 |
azonenberg | like, have a verilog module i instantiate in my simulation that bridges to C++ code or (indirectly) a hardware device | 09:50 |
azonenberg | this could massively speed up verification | 09:51 |
azonenberg | i should have done this a long time ago | 09:51 |
azonenberg | writing C++ code to send stimuli to a module being exercised in hardware | 09:52 |
azonenberg | whle having an internal LA capture bus traffic that module generates | 09:52 |
azonenberg | No, you misunderstand | 09:52 |
azonenberg | The integration would be done at the protocol level | 09:53 |
azonenberg | my NoC is based on a packet-switched fabric | 09:53 |
azonenberg | so packets would be generated by the simulator or PC code, when fully transmitted they'd be sent over jtag to the DUT, then sent at full speed onto the wire | 09:53 |
azonenberg | i'm debating whether to make the jtag mux use the NoC too | 09:53 |
azonenberg | because that would be cleaner but restrict usage somewhat | 09:54 |
azonenberg | i might make two endpoints | 09:54 |
azonenberg | have 16-bit addresses and you could have either a native front-end or a NoC front end | 09:54 |
azonenberg | So this is an early draft | 10:04 |
azonenberg | but does anyone have comments? http://colossus.cs.rpi.edu/~azonenberg/downloads/datasheet.pdf :p | 10:04 |
azonenberg | lol | 10:19 |
azonenberg | lekernel: so i have my jtag software speaking to the fpga now via USER1 | 17:12 |
azonenberg | the first design decision i have to make is the semantics of the interface | 17:13 |
azonenberg | should i keep it JTAG-style with an IR and a DR for each peripheral? | 17:13 |
azonenberg | i'm thinking maybe it'd be better to build it around packet switching | 17:13 |
azonenberg | wpwrak: probably not, but i wasnt in the mood to convert | 17:24 |
azonenberg | did you get a laugh out of it otherwise? :P | 17:24 |
azonenberg | and no, they ship with blank disks | 17:25 |
azonenberg | you need years of firmware updates and configuration before they're usable | 17:25 |
azonenberg | someone needs to port dd to nerdOS... | 17:25 |
azonenberg | then you can just drop in a new firmware image | 17:25 |
azonenberg | lol | 17:27 |
azonenberg | and yes, i am going to add a lot more stuff | 17:34 |
Action: azonenberg plugs jtag cable into wpwrak's brain | 17:34 | |
azonenberg | wpwrak: you cant feel it | 17:39 |
azonenberg | first off, boundary scan doesnt affect normal device functioning | 17:39 |
azonenberg | so until i start loading new memories into your brain or moving your fingers you wont notice anything out of the ordinary | 17:40 |
azonenberg | second, the brain does not have any sensory nerve endings in it :p | 17:40 |
wpwrak | azonenberg: it's more the obstacles on the way to the brain that i suspect would give me a bit of a headache | 17:44 |
azonenberg | details, details :P | 17:44 |
azonenberg | wpwrak: with any luck the TAP will still be functional | 17:47 |
azonenberg | wolfspraul: well they didnt manually lay out everything | 00:02 |
---|---|---|
azonenberg | and i wouldnt expect GREAT performance from an autorouter | 00:02 |
azonenberg | But i'd expect mediocre rather than poor | 00:02 |
wolfspraul | azonenberg: yes but you understand my point, the layout of apple's latest arm cores is very unusually 'clean' | 00:02 |
azonenberg | Yes, and was probably done by hand | 00:02 |
azonenberg | My point is, only the arm cores | 00:03 |
azonenberg | not the whole doc | 00:03 |
azonenberg | i'm going to say "not worth it" | 00:03 |
azonenberg | Yeah, I just expect its best guess to be better than garbage | 00:03 |
azonenberg | i mean that doesnt even look like a local minima | 00:04 |
wpwrak | azonenberg: maybe try to hand-optimize it. see if you can find a better local minimum. | 00:05 |
azonenberg | wpwrak: i'm doing hand placement now | 00:05 |
azonenberg | i was hoping i wouldnt need to do that because i wont be on the xc6slx45 for very long | 00:05 |
wolfspraul | azonenberg on apple's heels | 00:05 |
azonenberg | i just ran out of space on the lx25 and am moving to the xc7a100t as soon as i have time to finish designing this board | 00:05 |
azonenberg | i just jumped onto an atlys in the interim for a couple of months so my coding doesnt hit a standstill | 00:06 |
azonenberg | Oh, i hand route all of my pcbs | 00:06 |
azonenberg | But thats because they are somewhat less complex | 00:06 |
azonenberg | i can afford to hand tune | 00:06 |
azonenberg | on fpgas i cannot hand route everything | 00:06 |
azonenberg | But hand tuning of autorouting is commonplace | 00:06 |
azonenberg | http://colossus.cs.rpi.edu/pictures/2012/October/10-5-2012%20-%20switch/S7302929.JPG | 00:07 |
azonenberg | all hand routed | 00:07 |
azonenberg | wow, it's been a month? | 00:07 |
azonenberg | and i havent had time to assemble it yet | 00:07 |
azonenberg | lol my cheap camera cant handle low light well | 00:11 |
azonenberg | i dont think skill could save it | 00:11 |
azonenberg | long exposure... do you see how much thermal noise is on that sensor? | 00:15 |
azonenberg | that isnt motion lbur | 00:15 |
azonenberg | blur* | 00:15 |
azonenberg | that's the sensor sucking | 00:16 |
azonenberg | I tried flash but i think it didnt turn out well | 00:16 |
azonenberg | i mean its a long exposure but still | 00:16 |
azonenberg | this is a $50 camera from three or four years ago | 00:17 |
azonenberg | what do you expect | 00:17 |
azonenberg | It's irrelevant in short exposures | 00:17 |
azonenberg | the SNR gets a lot better | 00:17 |
azonenberg | Yeah, this was a 3-megapixel sensor that was pretty small | 00:18 |
azonenberg | WTF xilinx http://i.imgur.com/qahTq.png | 23:31 |
---|---|---|
azonenberg | what kind of autorouter invented this layout | 23:31 |
azonenberg | for some reason it's putting a bunch of flipflops (not connect to IOBs, mind you) waaay over on the right side of the chip | 23:32 |
azonenberg | nowhere near the logic they connect to | 23:32 |
azonenberg | Lol | 23:37 |
azonenberg | no | 23:37 |
azonenberg | Any idea how to fix that? Lol | 23:45 |
azonenberg | I'm starting to floorplan but i dont want to have to floorplan the whole stupid design by hand | 23:45 |
wolfspra1l | azonenberg: thanks for the floorplans | 01:17 |
---|---|---|
azonenberg | wolfspra1l: lol you agree with my assesment that spartan6 is kind of awkward them? | 01:18 |
azonenberg | oh, and if you thought the lx25 was bad | 01:19 |
azonenberg | take a look at the xc6slx75 :P http://i.imgur.com/6AlFb.png | 01:19 |
azonenberg | I wasnt talking in terms of toolchain development though | 01:21 |
azonenberg | And yeah | 01:21 |
azonenberg | Thats what i meant | 01:21 |
azonenberg | I do not, i have a pretty low opinion of their capabilities | 01:22 |
azonenberg | All of my PCBs so far have been 100% hand routd | 01:22 |
azonenberg | and my FPGA designs are normally autorouted by necessity, but usually with manual hints to guide placement | 01:22 |
azonenberg | Synthesis is source code to unplaced netlist | 01:23 |
azonenberg | just so we have terminology strate | 01:23 |
azonenberg | straight* | 01:23 |
azonenberg | Anyway, http://i.imgur.com/5uVch.png for example | 01:23 |
azonenberg | this is a design i had to manually floorplan | 01:23 |
azonenberg | CPU in yellow, rather overcomplicated but functional interconnect in purple, peripherals in blue | 01:23 |
azonenberg | i had to manually exclude the upper left from routing | 01:24 |
azonenberg | 7 series also eliminates SLICEXs | 01:24 |
azonenberg | if you look closely at most of my designs you will see every other column of CLBs is more heavily loaded | 01:24 |
azonenberg | because my kinds of project tend to use the muxes and adder chains a lot | 01:24 |
azonenberg | so 7 series will give me much better packing | 01:24 |
azonenberg | as in? | 01:25 |
azonenberg | i've only looked at high level stuff so far | 01:26 |
azonenberg | oh | 01:26 |
azonenberg | So basically every other column of CLBs is mirrored left to right | 01:26 |
azonenberg | so you can have easier access to the next column of routing over? | 01:27 |
azonenberg | I see | 01:27 |
azonenberg | I'm only looking so far at the docs and the planahead floorplans | 01:27 |
azonenberg | I see | 01:28 |
azonenberg | Well the floorplans look cleaner than xc6 does | 01:28 |
azonenberg | and the new CLBs with muxes and adder trees in every column will help | 01:28 |
azonenberg | https://docs.google.com/document/d/1gxH3zQZzspff2adjZanX-NnFIqQSDHgj4J1PO7z87Cg/edit?pli=1# | 01:34 |
azonenberg | my xc7 dev board if you're interested | 01:34 |
azonenberg | preliminary design is finished, starting schematic capture in a couple of days | 01:34 |
azonenberg | Lol yes | 01:35 |
azonenberg | You might want to get it nice and stable on xc6 first | 01:35 |
azonenberg | also looking at the xc6slx4 again | 01:36 |
azonenberg | wow, that is not a lot of CLBs | 01:36 |
azonenberg | only five across the whole device | 01:36 |
azonenberg | and 60 high | 01:36 |
azonenberg | One lot of board fab plus components for a prototype will cost me about $1500 | 01:38 |
azonenberg | hopefully i can get some of that back by selling blank boards to other people | 01:38 |
azonenberg | But i want to be 100% certain i do not need a respin | 01:38 |
azonenberg | So i'm trying to leave nothing to chance | 01:39 |
azonenberg | i'm sure there will be mistakes but i hope they won't be fatal | 01:40 |
azonenberg | Yeah, it wasnt really written for a general audience | 01:48 |
azonenberg | it was more for me and the few other people involved with it to discuss requirements | 01:49 |
azonenberg | Yeah, i guess | 01:55 |
azonenberg | I mean the intention is to be a fairly generic SoC prototyping platform, as well as being something that i can expand my research into since i'm running out of space in the XC6SLX25 | 01:56 |
azonenberg | So I want more of what I already have, basically | 01:57 |
azonenberg | plus a few extras like USB and HDMI that i couldn't fit in my last board | 01:58 |
azonenberg | Yeah, I want fast boots and it's a large bitstream | 01:58 |
azonenberg | so i'm going for BPI rather than SPI | 01:58 |
azonenberg | Can you explain why? | 01:58 |
azonenberg | You prefer quad SPI? | 01:59 |
azonenberg | or regular SPI? | 01:59 |
azonenberg | or what | 01:59 |
azonenberg | I've specced out a specific component that is on the officially supported list | 01:59 |
azonenberg | Is your concern that the solution is unstable in general, or that the vendor might stop making that part? | 01:59 |
azonenberg | Hmm | 02:00 |
azonenberg | You mean parallel NOR | 02:00 |
azonenberg | because SPI flash is NOR too | 02:00 |
azonenberg | I called for 16-bit wide parallel flash from spansion in a 64-BGA | 02:01 |
azonenberg | Well, I am hoping for fast boots and quad SPI vs 16-bit parallel is 4x slower | 02:02 |
azonenberg | Doing the math, XC7A200T is 78 Mbits of configuration data | 02:03 |
azonenberg | let's say max clock rate of 26 MHz | 02:03 |
azonenberg | 4-bit SPI | 02:03 |
azonenberg | 104 Mbps | 02:03 |
azonenberg | Yes | 02:03 |
azonenberg | So that would translate to just under a second of boot time | 02:04 |
azonenberg | That's for the 200T, initially i'll use the 100 so half that | 02:04 |
azonenberg | I'm filling half of the XC6SLX25 with one of my design's several major subsystems | 02:04 |
azonenberg | I'll probably be using a good chunk of the 100T | 02:04 |
azonenberg | 2/3 or so | 02:04 |
azonenberg | No, but one of the intended applications is in network infrastructure so tens of seconds of downtime on power outage would be an issue | 02:05 |
azonenberg | one second i can handle | 02:05 |
azonenberg | well, configuration in 500ms is probably doable | 02:05 |
azonenberg | if i use the 100T | 02:06 |
azonenberg | Well that will certainly free up a lot of I/O pins | 02:08 |
azonenberg | i might do that | 02:08 |
azonenberg | wolfspra1l: i have used quad SPI for spartan6 | 02:23 |
azonenberg | at up to ~20 MHz so 80 Mbps | 02:23 |
azonenberg | you can go a lot faster in 7 series (66 Mhz for artix7) | 02:24 |
azonenberg | and up to like 100 in kintex/virtex | 02:24 |
azonenberg | So that means an uncompressed artix7 could boot in 155ms lol | 02:25 |
azonenberg | for the 100T | 02:26 |
azonenberg | and that's at 50 MHz, not even the max | 02:26 |
azonenberg | i'm switching :P | 02:26 |
azonenberg | yes | 02:27 |
azonenberg | 50 MHz (max is 66) * 4 bits is 200 Mbps | 02:28 |
azonenberg | to load ~31 Mbits | 02:28 |
azonenberg | Yes | 02:28 |
azonenberg | so under 150ms if you use the max clock rate | 02:28 |
azonenberg | with no compression | 02:28 |
azonenberg | and yes, for very big devices you dont have much of a choice if you don't want to wait all week | 02:28 |
azonenberg | Actuallly | 02:29 |
azonenberg | It isn't as bad as you might think | 02:29 |
azonenberg | the largest virtex-7 is still only 448 Mbits of data | 02:29 |
azonenberg | So that's just over two seconds on 4-bit parallel | 02:30 |
azonenberg | or 500ms with 16-bit | 02:30 |
azonenberg | And lol, if you are doing something like that | 02:30 |
azonenberg | you configure the fpga before launch | 02:30 |
azonenberg | or do high-speed partial reconfig | 02:30 |
azonenberg | Yes, it is | 02:30 |
azonenberg | But i was hoping for 500ms from power on to operational | 02:30 |
azonenberg | and it looks like thats doable wit hquad SPI | 02:31 |
azonenberg | Thanks for the suggestion :) | 02:31 |
azonenberg | looks like i can fit another GPIO port | 02:31 |
azonenberg | and still have some pins free | 02:31 |
azonenberg | Good to know | 02:35 |
azonenberg | and i didnt realize the 7 series could use so much higher of a clock rate | 02:35 |
azonenberg | to config i mean | 02:35 |
lekernel | azonenberg: what software did you use to make those chip floorplans? | 10:28 |
lekernel | azonenberg: tried running linux on your mips softcore yet? | 13:42 |
azonenberg | lekernel: no MMU | 17:03 |
azonenberg | so not an option | 17:03 |
azonenberg | it runs code compiled with GCC though | 17:03 |
azonenberg | no idea, i havent looked | 17:07 |
azonenberg | The main thing is that it isnt on my roadmap and i haven't had the time | 17:07 |
azonenberg | i'm in the middle of trying to figure out how to add all the peripherals i need for my prototype in the XC6SLX25 so i can give a demo in a month or so | 17:08 |
azonenberg | without running out of space | 17:08 |
azonenberg | Because there is no way my artix7 board will be ready before the Jan-Feb time frame | 17:08 |
azonenberg | Hopefully? A demonstration of how the isolation capabilities of my proposed architecture will prevent compromise of the kernel or other apps if one app gets pwned | 17:10 |
azonenberg | Not sure if i can pull that off in a month though | 17:10 |
azonenberg | not yet, let's see | 17:12 |
azonenberg | Yeah, they're trying to solve the same problem a different way | 17:13 |
azonenberg | Also if i implement a MMU it will likely be one designed for my platform rather than stock | 17:57 |
azonenberg | I'm not trying to maintain compatibility with "normal" MIPS platforms at any level other than the binary ISA | 17:58 |
azonenberg | because that saves me the trouble of porting gcc to a new ISA | 17:58 |
azonenberg | Fallenou: not yet | 18:37 |
azonenberg | i have an unpublished draft i've bounced off a couple of people but i dont want to share it too widely until i have a demo-able prototype | 18:37 |
azonenberg | I think xilinx may have a winner with the 7 series if they can get yields up | 07:30 |
---|---|---|
azonenberg | http://i.imgur.com/Pu4no.png | 07:30 |
azonenberg | Floorplan of the XC6SLX25, what's the first thing that strikes you? | 07:31 |
azonenberg | The GTP qaud is eating a huge hole in the upper left of the array | 07:34 |
azonenberg | And there are just a few lonely CLBs stuck in the upper left | 07:34 |
azonenberg | I've seen that the xilinx P&R toolchain has a very annoying habit of putting timing-critical logic up in that corner | 07:35 |
azonenberg | Where it cannot really route to... anything... efficiently | 07:35 |
azonenberg | i hate floorplanning designs manually but i've had to do it several times to force it to not split things from that corner out to other spots | 07:36 |
azonenberg | By comparison the XC7A100T http://i.imgur.com/cvvZT.png | 07:36 |
azonenberg | nice rectangular cutous, one in the top and one in the bottom, for the GTPs | 07:36 |
azonenberg | then a smaller cutout behind the top one for the PCIe endpoint block | 07:37 |
azonenberg | no small fingers of CLBs with difficulty routing to other stuff | 07:37 |
azonenberg | though i am worried that the block on the center left side by the IOBs behind the XADC etc could become a similar chokepoint | 07:38 |
azonenberg | on a larger scale | 07:38 |
azonenberg | mwalle: lol if lm32's forwarding is as complex as the MIPS-based softcore i'm working with for my thesis it needs a page at least | 07:10 |
---|---|---|
mwalle | azonenberg: imho there should be one sheet, which gives a rough overview, whats happening | 07:13 |
azonenberg | Actually, now that i look at things, my forwarding isn't as bad as i remember | 07:13 |
azonenberg | 116 lines including the BSD license header and comments and whitespace | 07:13 |
azonenberg | the actual logic doesn't even start until line 86, the rest is signal declarations and header comments | 07:14 |
azonenberg | fits in one screen | 07:14 |
azonenberg | lol no :P | 07:15 |
azonenberg | http://code.google.com/p/utica-softcore/source/browse/trunk/hdl/achd-soc/UticaCPUPipelineForwarding.v#77 | 07:15 |
azonenberg | that's the public version of the codebase which is a few months out of date, i'm now developing on a private branch and will merge back when i publish my thesis | 07:16 |
azonenberg | dont want to give away all of my secrets before the paper is ready :P | 07:16 |
azonenberg | but that file i dont think has changed much, if at all, since | 07:17 |
azonenberg | Lol | 07:17 |
azonenberg | The CPU is nothing particularly new | 07:17 |
azonenberg | i just couldnt find any open-source MIPS-1 implementations that were well documented so i had to make one | 07:18 |
azonenberg | but all of the NoC stuff etc is where my real research is at | 07:18 |
azonenberg | The CPU was a half-semester project just to kick things off | 07:18 |
azonenberg | Lol hey, it gets the job done | 07:18 |
azonenberg | it runs at 80 MHz in spartan6 without me even attempting to tune for performance, 5-stage pipeline, runs code compiled by unmodified mipsel-elf gcc, and is BSD licensed | 07:19 |
azonenberg | no MMU but it will be getting one shortly | 07:20 |
azonenberg | The fun part obviously is here http://code.google.com/p/utica-softcore/source/browse/trunk/hdl/achd-soc/UticaCPUExecuteStage.v | 07:20 |
azonenberg | The only file in the project more than 1k lines | 07:20 |
azonenberg | i tried to keep it nice and modular | 07:20 |
azonenberg | but yeah, all of the fun work lately has been NoC and CPU-NoC integration | 07:22 |
mwalle | azonenberg: the bypassing/forwarding in lm32 is rather simple | 07:35 |
azonenberg | wpwrak: it's actually named after a nearby city | 07:36 |
azonenberg | as are all of the simple 8/16 bit cores i made to learn verilog | 07:37 |
lekernel | azonenberg: SFP+ modules are also pricy | 12:35 |
---|---|---|
azonenberg | lekernel: yes, they are | 16:07 |
azonenberg | lekernel: so i did some reading and it seems that if you are willing to pay the $100+ per 10gig SFP+ transceiver | 05:10 |
---|---|---|
azonenberg | you could have a kintex-7 talk directly to a SFP+ | 05:10 |
azonenberg | and do 10gbe with no need for an external PHY | 05:10 |
azonenberg | This of course assumes you are running over fiber optics | 05:10 |
azonenberg | The other option would be infiniband using bare GTPs with no other external components except maybe TVS diodes or a buffer | 05:11 |
azonenberg | You cannot do a switch with the 70T though, unfortunately | 05:13 |
azonenberg | the GTPs are organized in quads and the 70T only has two quads | 05:13 |
azonenberg | as best i can tell the quads share a common clock within themselves (for two tx and two rx pairs) | 05:14 |
azonenberg | sorry, four tx and four rx so the 70T only has one quad | 05:14 |
azonenberg | wolfspra1l: So I heard back from my FAE | 06:00 |
---|---|---|
azonenberg | the Artix-7s on digikey now are first-round engineering samples and are CSG324 and FGG676 only, in -1 and -2 speed grades only | 06:00 |
azonenberg | Second round samples will include FGG484 (I think probably the whole range of packages) and be -1 and -2 only | 06:00 |
azonenberg | those are expected to be out some time next month | 06:01 |
azonenberg | then early Q1 2013 volume production starts | 06:01 |
wolfspra1l | azonenberg: nice | 06:37 |
azonenberg | wolfspra1l: i didnt ask but it was implied that the second round samples will include all package combos | 06:40 |
azonenberg | :) | 06:43 |
azonenberg | :) | 06:44 |
azonenberg | one thing is for sure, all of the work i am doing for my research is resulting in me getting really good at mental logic synthesis | 06:44 |
azonenberg | as in, i can give pretty much exact netlist and resource estimates for a module given just a pencil and paper | 06:45 |
azonenberg | and even synthesize to primitives given enough time | 06:45 |
azonenberg | lol | 06:46 |
larsc | azonenberg: next time I need a bitstream I'll just come to you ;) | 07:20 |
azonenberg | larsc: If you want bitstreams talk to wolfspra1l :P | 07:20 |
azonenberg | my brain only goes to netlist level | 07:21 |
azonenberg | well ok, i can map and PAR to some extent too | 07:21 |
azonenberg | His tools want a fully placed and routed netlist atm | 07:21 |
azonenberg | so i'd have to map and par manually too | 07:22 |
azonenberg | Not that i cant do it, but its a little bit of a pain to do | 07:22 |
azonenberg | on the other hand, mental synthesis i find is a very good way to santiy check how big some module is going to be | 07:22 |
azonenberg | and how long the critical path is | 07:22 |
azonenberg | Dont worry about details like exactly what the logic function implemented by some LUT is | 07:22 |
azonenberg | I just think about what decisions need to be made with what data | 07:22 |
azonenberg | dataflow level, pretty much, as well as storage requirements | 07:23 |
azonenberg | and i usually end up with a slice-by-slice model for what the thing is going to look like before i write a single line of RTL | 07:23 |
azonenberg | then i just write the code and the synthesis tool usually generates pretty much exactly what i expect | 07:23 |
azonenberg | A lot of times i just write RTL without thinking much about what goes on under the hood but if i have any doubts as to how things are going to work i find this is a good way to sanity check | 07:26 |
kristianpaul | you can get made the one from azonenberg , i guess is cheap street work | 15:02 |
---|
kristianpaul | azonenberg: indeed what happened witht the cmos.. you were're building some tools last time i heard | 00:38 |
---|---|---|
azonenberg | kristianpaul: Yes, things are going slow because of school | 00:41 |
azonenberg | i'm still working on the spin coater and CNC microscope stage | 00:41 |
wolfspra1l | and because azonenberg is doing 20 things in parallel :-) | 00:41 |
azonenberg | wolfspra1l: I'm a bit of a barrel processor | 00:42 |
azonenberg | I need lots of threads to get maximal utilization | 00:42 |
azonenberg | wolfspra1l: :) | 00:48 |
azonenberg | Nice | 00:49 |
azonenberg | I'm going to work on higher level tooling stuff for now | 00:49 |
azonenberg | and operate under the assumption that at some point your code will get mature enough that i can generate your native file format instead of XDL output from my tools | 00:49 |
lekernel | seems wolfspra1l and azonenberg are doing better tools anyway :) | 11:44 |
cde | azonenberg: and its too fast for my LA <- the LA1034 is supposedly fast enough for a 125 MHz SDRAM, and it's not too expensive | 22:07 |
---|---|---|
azonenberg | cde: i was using DDR at 160 MHz | 22:07 |
azonenberg | and i've been using my internal LA lately since it can go over 200 MHz and captures synchronous to an on-chip clock | 22:08 |
azonenberg | cde: an older version of it is | 22:09 |
azonenberg | i'm doing current work on a private fork until i publish my thesis | 22:09 |
azonenberg | at which point i'll merge back to the mainline | 22:10 |
azonenberg | Yeah, mine is nicer | 22:10 |
azonenberg | plasma was slow, i think only three pipeline stages | 22:10 |
azonenberg | mine is five | 22:10 |
azonenberg | Not implemented because gcc doesnt generate those opcodes by default | 22:11 |
azonenberg | but the patent is expired so i could add it if needed | 22:11 |
azonenberg | well afaik as long as you dont use the MIPS trademark when describing your design | 22:12 |
azonenberg | mips1 is unencumbered now | 22:12 |
azonenberg | I think its still patented | 22:13 |
azonenberg | and it is | 22:13 |
azonenberg | My arch is pure 32 bit | 22:13 |
azonenberg | well i'm going to need at least a basic mmu here but it wont be mips standard | 22:14 |
azonenberg | it's going to have to be full custom to interface with my NoC | 22:14 |
azonenberg | openrisc? | 22:20 |
azonenberg | no experience with it but i've heard its decent | 22:20 |
azonenberg | i see | 22:21 |
cde | azonenberg: http://code.google.com/p/utica-softcore/ <= this is your softcore MIPS CPU I assume? | 22:26 |
cde | azonenberg: looking forward to your first IC :) | 22:33 |
azonenberg | Lol its a ways out | 23:11 |
azonenberg | cde: and yes | 23:11 |
kristianpaul | azonenberg: Hi | 15:20 |
---|---|---|
kristianpaul | azonenberg: Why you wrote your own uart core for the red tin logic analizer and no re-used one from somewhere else? | 15:21 |
Hodapp | azonenberg hangs out here? | 15:33 |
azonenberg | kristianpaul: i wanted something simple that had a raw interface | 16:01 |
azonenberg | rather than forcing use of wishbone or some other bus | 16:01 |
azonenberg | like the opencores one did | 16:01 |
azonenberg | i had written the uart a while ago for a different project anyway | 16:01 |
azonenberg | so just dropped it in | 16:01 |
wolfspraul | azonenberg made me switch to public domain a while back and I think it was a great idea, more freedom | 02:05 |
---|
azonenberg | lekernel: you found a KTN source? | 15:33 |
---|---|---|
azonenberg | remind me again what were you doing with it? | 15:33 |
azonenberg | lekernel: unrelated question, are you familiar with NoC architectures at all? | 12:06 |
---|---|---|
lekernel | azonenberg: a little bit | 12:10 |
azonenberg | lekernel: Would you be interested in commenting on a very early draft of a paper i'm writing? | 12:11 |
azonenberg | Right now i'm basically proposing what i want to make, most of the code isn't actually implemented | 12:11 |
azonenberg | lekernel: see PM | 12:14 |
lekernel | azonenberg: you there? | 20:58 |
---|---|---|
azonenberg | lekernel: yep | 20:58 |
azonenberg | This is probably a better forum for this discussion than FB :P | 20:58 |
azonenberg | anyway so have you considered using spartan6 lxt serdes? | 20:59 |
azonenberg | You're transmitting, right? | 20:59 |
azonenberg | or do you need to receive too | 20:59 |
azonenberg | whats the difference? I know the GTPs can do clock recovery and the s6 serdes cannot | 21:00 |
azonenberg | is that it? | 21:00 |
azonenberg | but "can do" and "must do" arent the same thing | 21:00 |
azonenberg | hmm, interesting | 21:02 |
azonenberg | so the gtp is a serdes + clock recovery + other stuff | 21:02 |
azonenberg | i've never used them | 21:02 |
azonenberg | i looked briefly at IOSERDES | 21:03 |
azonenberg | But again, refresh my memory | 21:05 |
azonenberg | what is the application here, do you need to accept video in? | 21:05 |
azonenberg | i thought this was only for generating video | 21:05 |
azonenberg | because for *sending* vidoe, the IOSERDES should work fine | 21:06 |
azonenberg | video* | 21:06 |
azonenberg | and at higher speed, the GTPs should be usable | 21:06 |
azonenberg | Thats what i'm wondering | 21:07 |
azonenberg | does it mandate IBM 8b10b? | 21:07 |
azonenberg | like i said i've never actually used the GTPs | 21:07 |
azonenberg | Well in that case if the gtp requires clock recovery that wont work | 21:07 |
azonenberg | phase-shifted sampling may or may not, but i'm inclined to say no | 21:08 |
azonenberg | the limit is not just Fclk, it's setup/hold times too | 21:08 |
azonenberg | which the incoming phase-shifted data will likely not respect | 21:08 |
azonenberg | Can they be used as dumb SERDES? | 21:09 |
azonenberg | if they run at 3.2 Gbps they're almost certainly CML + 8b10b as used in infiniband, SATA, etc | 21:09 |
azonenberg | that seems to be turning into an industry standard for gigabit serial | 21:10 |
azonenberg | HDMI is the lone holdout | 21:10 |
Action: azonenberg wonders when we'll see a GTP-compatible video standard coming out | 21:10 | |
azonenberg | interesting | 21:11 |
Action: azonenberg pulls UG386 | 21:11 | |
azonenberg | interesting | 21:12 |
azonenberg | "The actual width of the port depends on the GTPA1_DUAL tiles INTDATAWIDTH setting (controls the width of the internal datapath), and whether or not the 8B/10B encoder is enabled." | 21:12 |
azonenberg | So the s6 GTP should be capable of transmitting TMDS with the GTPs | 21:13 |
azonenberg | not sure about receiving | 21:13 |
azonenberg | and that appnote is supposed to be about using the lowest end chips | 21:14 |
azonenberg | the LXT are higher end | 21:14 |
azonenberg | he GTP transceiver includes an 8B/10B decoder to decode RX data without consuming | 21:14 |
azonenberg | FPGA resources. The decoder includes status signals to indicate errors and incoming | 21:14 |
azonenberg | control sequences. If decoding is not needed, the block can be disabled to minimize latency. | 21:14 |
azonenberg | Hmm | 21:15 |
azonenberg | Is it possible to do clock recovery on TMDS data? | 21:15 |
azonenberg | LOL | 21:16 |
azonenberg | anyway reading pages 150-160 of UG386 suggests it may be possible to use external clocking on the rx | 21:18 |
azonenberg | not certain yet | 21:18 |
wolfspraul | azonenberg seems to be quite successful with home-made 'reflow ovens' in the form of simple toaster ovens | 12:34 |
---|---|---|
azonenberg | wolfspraul: I use SAC305 lead-free and have no real problems with it | 17:22 |
xiangfu | azonenberg, Hi | 06:40 |
---|---|---|
azonenberg | hi | 06:40 |
azonenberg | whats up? | 06:40 |
xiangfu | azonenberg, I try to make a tiny slx9 board for learn. the first thing I need to is: power-on the chip and make jtag detect the chip. | 06:41 |
azonenberg | xiangfu: Sorry, cant talk tech now - it's 3AM and i'm getting ready to go to sleep | 06:41 |
xiangfu | azonenberg, sure. | 06:41 |
azonenberg | i'll be hanging out with $GF tomorrow but if you ping me in the early evening my time (EDT) i'll see what i can do | 06:42 |
xiangfu | azonenberg, good night. thanks. | 06:42 |
xiangfu | azonenberg, I learn base on your slx9-azonenberg-devboards , BTW. :-) | 06:43 |
azonenberg | Glad to hear it's getting used | 06:44 |
azonenberg | I assembled one of the boards and it works fine | 06:44 |
azonenberg | will do the other two soon | 06:44 |
azonenberg | The one mistake in the original design was that R8 (I think? the 10k pulldown on one of the mode pins) should have been 10 ohms, or any small value | 06:44 |
azonenberg | i forgot the chip has an on-die pullup and you have to pull down strongly enough to override that | 06:44 |
azonenberg | Not a layout change, just a BOM tweak | 06:45 |
xiangfu | azonenberg, one simple question. there are like 5 VCCINT/AUX/_O pins. for power-on the chip. I only needs connect one GND, one VCCINT, one VCCAUX and one VCC_O_2 is enough, right? no needs connect all them | 06:54 |
azonenberg | xiangfu: you have to connect all of the vccint and vccaux for the chip to work reliably | 08:19 |
azonenberg | vcco_2 is needed for jtag | 08:19 |
azonenberg | check the datasheet, it may be possible to leave off vcco for banks you arent using | 08:19 |
azonenberg | BUT | 08:19 |
azonenberg | you should probably ground it rather than leaving it floating | 08:19 |
azonenberg | which wont be any harder to route, probably, than hooking it up properly | 08:19 |
xiangfu | azonenberg, thanks. | 08:20 |
azonenberg | I've always hooked them all up | 08:21 |
azonenberg | its doable on 2 layers | 08:21 |
azonenberg | for a tq144 | 08:21 |
azonenberg | yes | 08:21 |
azonenberg | look at my board | 08:21 |
azonenberg | i had two concentric rings on one layer and a plane on the other | 08:21 |
azonenberg | i even got in nice decoupling | 08:21 |
azonenberg | while routing about half of the IOs to headers and useful stuff | 08:22 |
azonenberg | i could have routed the other IOs too but not without making the board larger | 08:22 |
wolfspra1l | azonenberg: about the slx9 board, I assume the board on the pic you showed the other day was soldered by yourself? | 01:25 |
---|---|---|
azonenberg | wolfspra1l: an hour or so maybe? Not that long | 01:26 |
azonenberg | i spent more time debugging it | 01:26 |
azonenberg | i put the power LED on backwards during assembly (the label o nthe board is correct) | 01:26 |
azonenberg | and R8, originally a 10K resistor, should be a very small value | 01:27 |
azonenberg | i used 10 ohms but its just a pulldown | 01:27 |
azonenberg | i didnt realize the input pin had an internal pullup of around 1K i had to override | 01:27 |
azonenberg | Other than that the board is assembled and working great | 01:27 |
azonenberg | i havent had time to do much with it | 01:27 |
azonenberg | i'm going to assemble the other two today or tomorrow | 01:27 |
azonenberg | I've pretty much finished testing and there are no known bugs in the board at this time | 01:29 |
azonenberg | wolfspraul: maybe 2 | 04:40 |
azonenberg | kristianpaul: no, it was all reflow | 04:40 |
azonenberg | but i did use an iron for touchup, i bridged a few of the QFP pins with excess paste | 04:41 |
azonenberg | had to use the iron to clean it out | 04:41 |
azonenberg | Lol of course fpgas are fun | 23:49 |
---|
azonenberg | wolfspraul: fyi, components + LX9 boards are here | 17:29 |
---|---|---|
azonenberg | will be assembling in a couple of minutes | 17:29 |
kristianpaul | azonenberg: assembled now? := | 18:25 |
azonenberg | kristianpaul: just came out of the oven | 18:49 |
azonenberg | first reflow cycle (back side) was perfect | 18:50 |
azonenberg | second cycle (front side) went decently well but i used too much paste on one component so i got a few bridges | 18:50 |
azonenberg | and one passive tombstoned | 18:50 |
azonenberg | quick fixes, thoguh | 18:50 |
azonenberg | kristianpaul, wolfspraul: http://imgur.com/a/k73TN#0 | 20:07 |
azonenberg | doing initial tests now but all seems well | 20:07 |
azonenberg | The ribbon connector for JTAG works beautifully | 20:08 |
wpwrak | azonenberg: looks nice. the screws seem massive ;-) | 21:16 |
azonenberg | wpwrak: lol those are 4-40 | 21:16 |
kristianpaul | azonenberg: P1 is for LCM? | 21:16 |
azonenberg | P1 is GPIO | 21:17 |
azonenberg | Four LVDS pairs, two each way, plus two single-ended lines in the middle (intended for a reference clock) | 21:17 |
azonenberg | grounds between every signal | 21:17 |
azonenberg | and 3V3 power for and inputs for bidirectional presence detection | 21:18 |
azonenberg | So I see some interesting blocks in the corner of spartan6 | 21:54 |
---|---|---|
azonenberg | anybody know what these do? | 21:54 |
azonenberg | SLAVE_SPI, SPI_ACCESS | 21:54 |
azonenberg | SPI_ACCESS was mentioned briefly in these channel logs a while ago but i never heard if anyone figured out what it did | 21:55 |
azonenberg | you think there was originally plans for a stacked-die spartan6-N series like spartan3an? | 21:55 |
Fallenou | azonenberg: maybe ug333.pdf page 9/90 | 21:56 |
azonenberg | what about SLAVE_SPI? | 21:56 |
azonenberg | yeah | 21:57 |
azonenberg | So that would mean there's bond pads on the s6 die | 21:57 |
azonenberg | intended to connect to stacked-die SPI flash | 21:57 |
azonenberg | that isnt actually used? | 21:57 |
azonenberg | also, interesting | 21:58 |
azonenberg | spartan3an have atmel dataflash onboard | 21:58 |
azonenberg | Not sure | 21:59 |
azonenberg | it doesnt seem to be documented | 21:59 |
azonenberg | Yeah, i've made my own spi controllers too | 21:59 |
azonenberg | but slave implies fpga = slave | 21:59 |
azonenberg | so i wonder how that works | 21:59 |
azonenberg | i know, but outside configuration what does that do | 22:00 |
azonenberg | Yes, i know about that | 22:02 |
azonenberg | but what use is it outside of booting the fpga? | 22:03 |
azonenberg | having a dedicated fabric-routable block implies it's usable after configuration | 22:03 |
azonenberg | but it just looks to have connections to MISO, MOSI, CSB, CLK, etc | 22:03 |
azonenberg | like i would expect from external SPI | 22:03 |
azonenberg | how is that different from the ICAP | 22:03 |
azonenberg | but it doesnt include a SERDES or parallel otput as far as i can see | 22:04 |
azonenberg | i'm just looking at the pins hooked up in planahead | 22:04 |
azonenberg | w/e | 22:04 |
mwalle | azonenberg: maybe there are plans for the -N version of it, but no real customer yet? | 22:08 |
azonenberg | Perhaps | 22:08 |
azonenberg | also possible they just wanted to futureproof it | 22:08 |
azonenberg | i cant imagine those few extra bond pads cost much die area | 22:08 |
mwalle | azonenberg: btw what are youre cpld reverse engineering efforts do? iirc you bought some xilinx cplds to make photos from the die? | 22:10 |
azonenberg | mwalle: we took photos of an xc9536xl but have not gone any further than that | 22:10 |
azonenberg | at the moment my main RE efforts are focusing on a ST 24C02 | 22:10 |
azonenberg | i want to fully understand the whole thing at transistor level | 22:10 |
azonenberg | yes | 22:11 |
azonenberg | EEPR0N ;) http://siliconpr0n.org/archive/doku.php?id=mcmaster%3Ast%3A24c026 | 22:11 |
azonenberg | nude photos of floating gates | 22:11 |
azonenberg | and no, just curious | 22:12 |
azonenberg | its simple and large process tech | 22:12 |
azonenberg | therfore shouldnt be impossibly hard to completely analyze | 22:12 |
azonenberg | Just thoughtds for you guys | 01:07 |
---|---|---|
azonenberg | look at how MIPS does segmentation in nommu builds | 01:08 |
azonenberg | as well as in mmu builds | 01:08 |
azonenberg | the kernel has two segments with a constant offset to go from cached to uncached | 01:08 |
azonenberg | wolfspraul: FYI | 20:12 |
---|---|---|
azonenberg | my 2-layer LX9 breakouts shipped from the fab | 20:12 |
azonenberg | should be at my place early next week | 20:12 |
mwalle | azonenberg: do you solder bgas yourself? | 20:12 |
azonenberg | mwalle: this board is a TQFP144 XC6SLX9 on 2 layers | 20:13 |
azonenberg | i have done FTG256 bga on 4 layers by hand, though | 20:13 |
mwalle | azonenberg: with an ir heater? | 20:13 |
azonenberg | toaster oven | 20:14 |
mwalle | azonenberg: nice | 20:17 |
mwalle | azonenberg: did it work in the first place? | 20:18 |
azonenberg | lekernel: hardware multithreading :D | 20:18 |
azonenberg | Lol | 00:43 |
---|---|---|
azonenberg | That was the slowest reboot i've had in a while | 00:43 |
azonenberg | thanks to accidentally leaving udev in "debug" logging mode | 00:43 |
azonenberg | had to boot off a livecd and turn it off to avoid waiting all month :P | 00:44 |
azonenberg | wpwrak: but it works now :) | 00:45 |
azonenberg | still no idea what went wrong | 00:45 |
azonenberg | gaah | 23:49 |
---|---|---|
azonenberg | ISim wont simulate | 23:49 |
azonenberg | i tried cleaning the project and restarting ise | 23:49 |
azonenberg | Lol | 23:52 |
azonenberg | ERROR: The simulation failed to launch for the following reason: | 23:52 |
azonenberg | Failed to communicate with child process. | 23:52 |
azonenberg | Please shut down ISim and retry the simulation. If the problem persists, please contact Xilinx support. | 23:52 |
azonenberg | Think a reboot would help anything? | 23:53 |
azonenberg | if some socket is in use etc | 23:53 |
azonenberg | wolfspra1l: what can you do with a verilog tool that doesnt synthesize? | 01:50 |
---|---|---|
azonenberg | simulate only? | 01:50 |
azonenberg | yeah, i'm not sure | 01:55 |
azonenberg | i havent looked that far up the stack yet | 01:55 |
azonenberg | my first-run lx9 boards are at the fab now btw | 01:55 |
azonenberg | EDIF = electronic device interchange format | 01:56 |
azonenberg | its a device-independent RTL netlist | 01:56 |
azonenberg | that then has to be mapped into technology-dependent stuff and PAR'd | 01:56 |
azonenberg | Why do you say that | 01:56 |
azonenberg | what do you use now? | 01:56 |
azonenberg | i thought edif was the only way to exchange RTL other than source code | 01:56 |
azonenberg | link? | 01:56 |
azonenberg | i see | 01:57 |
azonenberg | i've only been doing FPGA stuff for a year myself lol | 01:57 |
azonenberg | Yeah | 01:59 |
azonenberg | to me, dead means no longer in active use, or being phased out | 01:59 |
azonenberg | vs stable and mature | 02:00 |
Action: azonenberg hates that | 02:00 | |
azonenberg | the goal of a company shouldnt be to grow | 02:00 |
azonenberg | it should be to produce a product | 02:00 |
azonenberg | looking on wiki under EDA file formats | 02:01 |
azonenberg | they have CIF, GDS, LXF for masks | 02:01 |
azonenberg | gerber for PCBs and (occasionally) IC masks | 02:01 |
azonenberg | DXF | 02:02 |
azonenberg | OASIS also for masks | 02:02 |
azonenberg | but EDIF seems the only netlist format | 02:02 |
azonenberg | lekernel, kristianpaul: http://siliconexposed.blogspot.com/2012/07/bga-process-notes.html | 00:21 |
---|---|---|
azonenberg | This is the same process I use with FT256 package | 00:22 |
azonenberg | havent tried on FG484 but i expect it to work | 00:22 |
azonenberg | kristianpaul: yeah, its all human-in-the-loop feedback | 00:33 |
azonenberg | not scalable to mass production but requires very little fancy equipment | 00:33 |
azonenberg | i do have the capabilities to make a real profile controller | 00:34 |
azonenberg | building one is on the short-term TODO list | 00:34 |
azonenberg | its going to be ethernet enabled | 00:34 |
azonenberg | so i can put a board in there | 00:34 |
azonenberg | then go back to my desk and dial in a profile | 00:34 |
azonenberg | and it'll beep when its done | 00:34 |
azonenberg | Lol well the real one is going to be based on a thermocouple and a relay | 00:35 |
azonenberg | and some kind of closed-loop feedback loop | 00:35 |
lekernel | azonenberg: nice | 07:35 |
azonenberg | kristianpaul: open source ARM core? | 20:08 |
azonenberg | i'm sticking to mips since its a nice old architecture | 20:08 |
azonenberg | all patents on mips1 have long since expired | 20:08 |
kristianpaul | azonenberg: kinda yes, old arch same as your mips core | 20:09 |
azonenberg | Well yeah, all the current ones are patented up the wazoo | 20:10 |
azonenberg | wpwrak: 40 MHz on an ARM core on s6? | 20:44 |
azonenberg | even my MIPS hits 80, do they have significantly better performance per clock? | 20:44 |
azonenberg | half the clock rate would need a much more efficient architecture to be competitive | 20:44 |
lekernel | azonenberg: can you deposit titanium films (on a KTN crystal)? | 20:58 |
azonenberg | In house, or do i hav access to it? | 21:00 |
azonenberg | In house the only film coating i can do is spin coating, i plan to build a sputtering setup but don't have the parts yet | 21:00 |
azonenberg | i can however do evaporation on campus | 21:00 |
wpwrak | azonenberg: they only compare it with itself. so no idea how it compares with other cores in real life. 1.0 MIPS/MHz suggests they're not ~2x faster than the rest of the pack (which they'd need to make up for the low clock speed) | 21:00 |
azonenberg | Let me look up the temps | 21:01 |
azonenberg | I've done copper (melts 1084C boils 2562C) | 21:01 |
azonenberg | titanium is a little higher (1668 and 3287) | 21:01 |
azonenberg | i've also done Cr (1907, 2671) | 21:02 |
azonenberg | and while i have not personally other people use the tool for gold (1064, 2856) | 21:02 |
azonenberg | So it should be possible to get hot enough | 21:02 |
azonenberg | The tool cannot get hot enough to do Pt (1768, 3285) | 21:03 |
azonenberg | 3825* | 21:03 |
azonenberg | vapor pressure is too low | 21:03 |
azonenberg | and hmm... | 21:03 |
azonenberg | lol nice | 21:04 |
azonenberg | wpwrak: 1.0 MIPS/MHz is comparable to my architecture | 21:05 |
azonenberg | maybe eve na little worse if they're talking DMIPS | 21:05 |
azonenberg | and i clock twice as fast | 21:05 |
azonenberg | no experience with LM32 but i'v eheard its comparable to a hair faster than mine | 21:05 |
azonenberg | I see | 21:06 |
azonenberg | well, sputtering it shouldnt be too difficult | 21:06 |
azonenberg | i havent built a sputtering system yet, its the third on my TODO list | 21:06 |
azonenberg | the first two being a better spin coater and a 2-inch contact mask aligner | 21:06 |
azonenberg | mumptai: #homecmos | 21:07 |
azonenberg | its coming along slow since i'm doing it part time while in school | 21:07 |
azonenberg | but it is moving | 21:07 |
lekernel | azonenberg: so, titanium sputtering sounds like something you would be capable of doing? | 21:08 |
azonenberg | Am currently capable of, no. Will be at some point, yes | 21:08 |
azonenberg | how long it'll take depends on a lot of factors | 21:08 |
azonenberg | If i can evaporate it, i can do it easily | 21:09 |
azonenberg | evaporation is done with a tungsten filament | 21:09 |
azonenberg | the hard part is getting the necessary vacuum | 21:10 |
azonenberg | 1E-6 torr range | 21:10 |
azonenberg | Yes | 21:10 |
azonenberg | Sputtering can be done much hgiher | 21:10 |
azonenberg | 1E-3 to 1E-2 | 21:10 |
azonenberg | You get oxidation etc | 21:11 |
azonenberg | sputtering is done with an inert gas plasma at low temperature | 21:11 |
wpwrak | azonenberg: (MIPS) yes, DMIPS. so it sounds like a nice achievement in terms of proof of concept. but it doesn't quite feel as if they had just obsoleted what we have. | 21:41 |
azonenberg | which has had exploits out in the past | 00:00 |
---|---|---|
azonenberg | kristianpaul: yeah, my goal is to be the antithesis of that | 00:00 |
azonenberg | wpwrak: i clip silk off pads | 00:00 |
azonenberg | wpwrak: i made my own 0402 footprint since the lib didnt have any | 00:01 |
azonenberg | i used the stock 0603 | 00:01 |
azonenberg | Lol | 00:01 |
azonenberg | Ok, fixed | 00:02 |
azonenberg | wave soldering for SMT?? | 00:04 |
azonenberg | not for BGA i hope | 00:04 |
azonenberg | lol | 00:04 |
azonenberg | i've been doing reflow from day 1 | 00:04 |
azonenberg | my first SMT board was an 0.65mm TSSOP and the next was a 64-TQFP | 00:05 |
azonenberg | lol | 00:07 |
azonenberg | So, any further suggestions? | 00:07 |
azonenberg | bottom left is a little mepty but there isnt really any space to route any pins out there | 00:07 |
azonenberg | empty* | 00:07 |
azonenberg | C33 is fine | 00:08 |
azonenberg | C10 should move | 00:08 |
azonenberg | those pads are the outside of the pad, mind you | 00:09 |
azonenberg | the lead doesnt stick out that far | 00:09 |
azonenberg | i dod have one since there's a power plane there | 00:10 |
azonenberg | did* | 00:10 |
azonenberg | i have 1V2, 3V3, and 2V5 planes under the fpga | 00:10 |
azonenberg | and ground outside | 00:10 |
azonenberg | Thats a custom footprint | 00:11 |
azonenberg | no qfn32 in the library | 00:11 |
azonenberg | Yeah, i'll try adding a keepout | 00:13 |
azonenberg | also, this board is assuming soldermask | 00:15 |
azonenberg | i would never do a big QFP without one | 00:15 |
azonenberg | and all vias are tented in the gerbers | 00:15 |
azonenberg | the intention was to use a cheap batch fab service | 00:16 |
azonenberg | So 8 mils clearance from plane to pin is completely fine especially if you use fine pitch soldermask like i normally do | 00:16 |
azonenberg | http://i.imgur.com/Hd3Pl.jpg | 00:19 |
azonenberg | typical mask clearance i work with | 00:19 |
azonenberg | those are 0201s | 00:20 |
azonenberg | Note how good the registration is | 00:21 |
azonenberg | its off by like 25 microns | 00:21 |
azonenberg | am i getting spoiled by working with good fabs? | 00:22 |
azonenberg | My reflow oven, btw, is very similar to this model :P http://www.amazon.com/Black-Decker-TRO490W-Toast-R-Oven-Countertop/dp/B00130399K/ref=sr_1_34?s=kitchen&ie=UTF8&qid=1341102257&sr=1-34&keywords=toaster+oven | 00:25 |
azonenberg | like i said this board is designed for 6/6 rules with soldermask | 00:25 |
azonenberg | there are so many cheap batch fabs out there | 00:26 |
azonenberg | i'm going to pay about $8 each for three blank boards | 00:26 |
azonenberg | With 6/6 rules, silk, and high-res LPI soldermask | 00:26 |
azonenberg | back when i used to make boards at home more often than i do now | 00:27 |
azonenberg | i used to use 0805 and 0603 passives to jump over traces all the time | 00:27 |
azonenberg | It cooks a lot hotter than the thermostat says | 00:28 |
azonenberg | when set for 200-210C my SAC305 melts | 00:28 |
azonenberg | the melting point is 220ish so the oven is prob 230-240 at that point | 00:28 |
azonenberg | I have 8 mil clearance on this fill | 00:28 |
azonenberg | to allow it to sneak in under the QFP etc | 00:28 |
azonenberg | as long as you have soldermask you're fine | 00:29 |
azonenberg | and if you're remaking it without mask, nothing stops you from using bigger clearance or eliminating the fill | 00:29 |
azonenberg | it is open hardware after all :P | 00:29 |
azonenberg | but i'm designing the version in the repo for cheap professional fab | 00:29 |
azonenberg | all wrong? how | 00:31 |
azonenberg | i didnt put a paste print on the footprint | 00:31 |
azonenberg | since its meant for manual application | 00:32 |
azonenberg | but i have used that footprint before with hand soldering and it worked correctly with the ft232 | 00:32 |
azonenberg | I clipped silk during gerber export | 00:33 |
azonenberg | the fab clips too | 00:33 |
azonenberg | thats also the default tqfp144 footprint btw | 00:34 |
azonenberg | Lol | 00:35 |
azonenberg | Just ordered 3 boards from my usual fab | 00:35 |
azonenberg | we'll see how it turns out | 00:35 |
azonenberg | yes, it didnt fit easily | 00:35 |
azonenberg | there wasnt when i first routed it :P | 00:36 |
azonenberg | So now i'm going to order some LX9s and then we'll see how it turns out in a few weeks | 00:37 |
azonenberg | Yeah, i'm not used to designing for newbies anymore | 00:38 |
azonenberg | been spending too much time working with 01005s :P | 00:38 |
azonenberg | and BGAs | 00:38 |
azonenberg | All of them are the same size | 00:39 |
azonenberg | its plenty big enough | 00:39 |
azonenberg | well i've never had trouble probing one lol | 00:39 |
azonenberg | Oh | 00:40 |
azonenberg | Those were intended for temporary | 00:40 |
azonenberg | look at my ground pad | 00:40 |
azonenberg | thats a permanent clip-on test point | 00:40 |
azonenberg | the small ones are meant to just jab a scope probe into | 00:40 |
azonenberg | see if there's noise or not | 00:41 |
azonenberg | Pogo pins | 00:41 |
azonenberg | thats what the pads are really intended for | 00:41 |
wpwrak | azonenberg: btw, here are two makefiles you can use to generate the sort of overview i made: http://downloads.qi-hardware.com/people/werner/tmp/ad-mst-mk.tar.bz2 | 00:53 |
wpwrak | wolfspra1l: and you'll need this patch if you want to open azonenberg's design with kicad: http://downloads.qi-hardware.com/people/werner/tmp/ad-mst-path.patch | 01:07 |
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) | 00:00 |
---|---|---|
azonenberg | wolfspraul: going to dumpster dive on campus for an hour or so | 00:03 |
azonenberg | if nobody has further suggestions i'll send gerbers out to the fab tonight | 00:03 |
azonenberg | should get 'em in ~3 weeks | 00:04 |
wolfspraul | you mean azonenberg's board has some vias there? haven't checked yet | 00:54 |
azonenberg | wpwrak, wolfspraul: i designed the board for the oshpark.com 2-layer process | 02:22 |
azonenberg | $5/in^2 gets you three units | 02:22 |
azonenberg | it'd be around $8 per blank board at that rate | 02:22 |
azonenberg | with a ~3 week lead time | 02:22 |
azonenberg | at least, that's the design rules i used and thts where i'll be making the prototype | 02:22 |
wpwrak | azonenberg: PCBs for the patient ;-) | 02:24 |
azonenberg | wpwrak: well most of my stuff is 4 layers | 02:24 |
azonenberg | and i cant make that in house | 02:24 |
azonenberg | its also 6/6 mil design rules, decently small vias, ENIG finish, silk, soldermask | 02:24 |
azonenberg | totally worth the wait | 02:25 |
wpwrak | azonenberg: "I have a quad-monitor setup on my desk" nice ;-) | 22:42 |
azonenberg | wpwrak: i'm actually about to get several more screens going but they're going out in the lab, not on my desk | 22:43 |
azonenberg | yay tech-school dumpsters :D | 22:43 |
azonenberg | somebody threw out a half-dozen perfectly functional screens | 22:43 |
azonenberg | a little scuffed up, and low res (1024x768 or so) but still perfectly serviceable | 22:44 |
azonenberg | actually | 22:45 |
azonenberg | that was a while ago | 22:45 |
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 | 22:45 |
azonenberg | its former occupant, an SGI Origin 2000, had been retired | 22:45 |
azonenberg | and the rack was sitting next to it in the dumpster | 22:45 |
azonenberg | well ok, next to the dumpster | 22:45 |
azonenberg | so me and my roommate wheeled it half a mile across town and down a hill to the apartment lol | 22:46 |
azonenberg | http://i.imgur.com/uQsBK.jpg here it is halfway through being set up | 22:46 |
azonenberg | the green post-its mark where stuff is going to go | 22:46 |
azonenberg | i'm trying to move the unused compute nodes and the switch that runs all of the currently unoccupied bedrooms first | 22:47 |
azonenberg | then the stuff that's in service last | 22:47 |
azonenberg | Re my quad-mon, i have 3x 1920x1080 plus one 1280x800 | 22:48 |
azonenberg | yes i do lol | 22:48 |
azonenberg | The Sun cases at bottom are empty atm but i'm going to be building some stuff in them | 22:48 |
azonenberg | one is going to turn into an FPGA-based VPN appliance | 22:48 |
azonenberg | So any last-minute suggestions on that s6 board? | 22:49 |
azonenberg | (the TQFP one) | 22:49 |
azonenberg | i'm doing a final CAM review on the gerbers now | 22:49 |
azonenberg | moving silkscreen text so it doesnt overlap pads etc | 22:50 |
azonenberg | of the fpga? looks fine to me | 22:52 |
azonenberg | I expect this to be reflowed | 22:52 |
azonenberg | toaster ovens are cheap | 22:53 |
azonenberg | ? | 22:53 |
azonenberg | i've never had any yield issues on mine | 22:54 |
azonenberg | at least not that i could trace to the temperature | 22:54 |
azonenberg | As is | 22:54 |
azonenberg | manual feedback | 22:54 |
azonenberg | as in, turn the knob based on the color of the paste | 22:54 |
azonenberg | http://colossus.cs.rpi.edu/pictures/2012/June/6-7-2012%20-%20Spartan-6%20board/S7302765.JPG - done in a cheap toaster | 22:55 |
azonenberg | connectors were done by hand after | 22:55 |
azonenberg | this was reflowed on both sides | 22:55 |
azonenberg | note the dust, i used no-clean rosin flux and apparently didn't wash enough afterwards | 22:55 |
azonenberg | so the thing is a dust magnet lol | 22:55 |
azonenberg | i touched up one or two shorts (caused by too much paste) with an iron but it was otherwise all reflow | 22:56 |
azonenberg | Lol well it means it wont short your board if you leave it on | 22:56 |
azonenberg | i think it looks nicer gone | 22:56 |
azonenberg | No | 22:57 |
azonenberg | just the syringe and steel needle the paste was shipped in | 22:57 |
azonenberg | chipquik flux did have a single 20ga steel needle (blunt tip, not pointed) | 23:00 |
azonenberg | and paste | 23:00 |
azonenberg | i buy my needles from celeritous.com | 23:00 |
azonenberg | i prefer 22ga blunt-tip because its slightly more precise | 23:00 |
azonenberg | 25ga was too fine and it didnt flow | 23:00 |
azonenberg | color-accurate preview of bottom http://i.imgur.com/hCNLT.png | 23:01 |
azonenberg | top* | 23:01 |
azonenberg | ok, give me a min to play with those | 23:04 |
azonenberg | i'm personally used to tight work | 23:04 |
azonenberg | re c15/27 they're decouplers, i want them close | 23:08 |
azonenberg | i guess | 23:09 |
azonenberg | c15 cant move though | 23:09 |
azonenberg | too much routing nearby | 23:09 |
azonenberg | the jtag connector has plenty of clearance | 23:10 |
azonenberg | it fits completely inside that silk footprint | 23:10 |
azonenberg | but hmm | 23:10 |
azonenberg | yeah | 23:12 |
azonenberg | rerouting a bit | 23:12 |
azonenberg | yeah, i'm moving the led bank | 23:14 |
azonenberg | give me a few mins | 23:14 |
azonenberg | i'm designing for 6/6 rules | 23:26 |
azonenberg | and reflow | 23:26 |
azonenberg | i guess | 23:26 |
azonenberg | that was automatic | 23:27 |
azonenberg | i'll fix that | 23:27 |
azonenberg | 4-40 screws with small heads | 23:28 |
azonenberg | why? | 23:28 |
azonenberg | The holes arent grounded | 23:29 |
azonenberg | The ring is very small | 23:29 |
azonenberg | its not intended to be grounded | 23:29 |
azonenberg | but this process mandates all holes be plated | 23:29 |
azonenberg | i think i have 254um clearance to the ground fill now | 23:30 |
azonenberg | I moved it laready | 23:30 |
azonenberg | screenshot is old | 23:30 |
azonenberg | i havent committed my most recent changes | 23:33 |
azonenberg | give me a few mins | 23:33 |
azonenberg | i'm used to working on 6/6 rules with tight registration | 23:35 |
azonenberg | thats what the fab i use does | 23:41 |
azonenberg | and i'm used to working at those levels | 23:41 |
azonenberg | 0402 is the smallest i routinely use | 23:41 |
azonenberg | i go down smaller only if forced to by spatial constraints (rare) | 23:41 |
azonenberg | no, its vision | 23:44 |
azonenberg | i do them by hand under a microscope | 23:44 |
azonenberg | then reflow | 23:44 |
azonenberg | Hmm, true | 23:45 |
azonenberg | i guess i just assumed you guys are operating at this level | 23:45 |
azonenberg | i take it the M1 prototypes arent hand assembled then?> | 23:46 |
azonenberg | well i do mine in the living room | 23:46 |
azonenberg | that doesnt say much considering my living room | 23:46 |
azonenberg | i do photolith in my living room and have gotten to 6/6 traces, though 8/8 gives better yields | 23:47 |
azonenberg | well, depends on what you define by "reasonably expect to work with" | 23:49 |
azonenberg | i'm DIYing 256FTBGA in the living room (though on a professionally made PCB) | 23:49 |
azonenberg | http://colossus.cs.rpi.edu/pictures/2012/June/6-7-2012%20-%20Spartan-6%20board/S7302765.JPG | 23:51 |
azonenberg | my most recent board | 23:51 |
azonenberg | http://colossus.cs.rpi.edu/pictures/2012/April/4-30-2012%20-%20Spartan6%20board/S7302710.JPG is the bare board | 23:51 |
azonenberg | and the back side, chock full of 0402s http://colossus.cs.rpi.edu/pictures/2012/April/4-30-2012%20-%20Spartan6%20board/S7302711.JPG | 23:52 |
azonenberg | personally i consider that perfectly doable as a DIY project | 23:52 |
azonenberg | of the big one or the small one? | 23:53 |
azonenberg | didnt fall off | 23:54 |
azonenberg | it was never placed | 23:54 |
azonenberg | the fab screwed up and masked off the pad | 23:54 |
azonenberg | luckily it was a noncritical decoupler | 23:54 |
azonenberg | the gerber is fine | 23:54 |
azonenberg | C22 had the same defect | 23:54 |
azonenberg | and C39/46 passed DRC and had good spacing | 23:55 |
azonenberg | i just bridged them | 23:55 |
azonenberg | but they were paralleled anyway | 23:55 |
azonenberg | so i didnt care | 23:56 |
azonenberg | lol | 23:56 |
azonenberg | i also should have used 0201 for C39/46 | 23:56 |
azonenberg | since they did have to be that close | 23:56 |
azonenberg | a smaller component would allow more clearance | 23:56 |
azonenberg | lol nice | 23:57 |
azonenberg | http://imgur.com/a/F4tg2#0 | 23:58 |
azonenberg | final gerber render | 23:58 |
azonenberg | kristianpaul: from scratch | 23:58 |
azonenberg | i do not want an OS whatsoever | 23:58 |
azonenberg | just a big state machine | 23:58 |
azonenberg | probably not a CPU either | 23:58 |
azonenberg | the goal is to be so simple as to be virtually unexploitable | 23:58 |
azonenberg | but guess what | 23:59 |
azonenberg | UDP is small | 23:59 |
azonenberg | and for a layer 2 VPN | 23:59 |
azonenberg | you just have to encapsulate ethernet frames in UDP packets | 23:59 |
azonenberg | and encrypt them | 23:59 |
azonenberg | I use openvpn over UDP now | 23:59 |
azonenberg | but its on linux | 23:59 |
azonenberg | the goal is to make something protocol-compatible but so simple as to be almost infallible | 23:59 |
azonenberg | compared to something like a cisco router | 23:59 |
azonenberg | wolfspraul: just committed a final BOm | 00:05 |
---|---|---|
azonenberg | $55.81 including PCB and all optional components | 00:05 |
azonenberg | before bulk discount | 00:05 |
azonenberg | iow, assuming you pay 17 cents for every single decoupling cap | 00:05 |
azonenberg | $40.40 of that is the required stuff, the rest is optional accessories | 00:06 |
azonenberg | Whoops, forgot to tab-to-space | 00:06 |
azonenberg | fixed | 00:07 |
azonenberg | wolfspraul: let me know when you've had a chance to look over the design in some detail | 00:12 |
azonenberg | i'm probably going to add an oscilloscope ground clip and a couple of probe pads with silkscreened labels on interesting signals | 00:13 |
azonenberg | but other than that it's finished | 00:13 |
azonenberg | Ok, let me phrase this a little differently | 00:14 |
azonenberg | I'm going to send the design out for first-run prototype fab tonight or tomorrow so any comments received after that point will have to wait for rev 0.2 | 00:15 |
wpwrak | azonenberg: why is SPI_SCK on a voltage divider ? (R4/R5) | 09:12 |
azonenberg | wpwrak: did i not commit after annotating it? | 09:12 |
azonenberg | and these are indicator LEDs, you dont need a lot of current | 09:12 |
azonenberg | i run 470 on most of mine and it works well | 09:13 |
azonenberg | re the divider, that's the recommended termination from the datasheet | 09:13 |
azonenberg | UG380 page 52 | 09:13 |
azonenberg | 2*Z0 from SCK to Vdd and Vss | 09:14 |
azonenberg | Board Layout for Configuration Clock (CCLK) | 09:16 |
azonenberg | which doc version do you have? i'm reading v2.3 | 09:16 |
azonenberg | wpwrak: yeah, i didnt do that on any of my past boards | 09:20 |
azonenberg | the fpga booted fine | 09:20 |
azonenberg | but i noticed significant overshoot on the scope | 09:20 |
azonenberg | i also noticed that the flash chip, rated for ~80 MHz operation, could only be used by user designs up to around 40 | 09:21 |
azonenberg | i was using on-chip termination for all of the data from me to the flash | 09:21 |
azonenberg | i think that MISO needs termination too | 09:21 |
azonenberg | i think i'm going to put a pad on there and i can always put a 0-ohm if it turns out to be unnecessary | 09:22 |
azonenberg | lekernel: also, my LA has just proven its worth http://i.imgur.com/0AAhe.png | 09:23 |
azonenberg | that's the bug in my memory controller | 09:23 |
azonenberg | read is issued after a write but occurs before | 09:23 |
azonenberg | so you end up reading what was there before the write happened | 09:23 |
azonenberg | lekernel: the controller handles that fine | 09:25 |
azonenberg | i've tested | 09:25 |
azonenberg | this is a bug in the glue that goes from my SoC's internal bus to the MCB | 09:26 |
azonenberg | i intend to explore replacing this module and the mcb with something else later | 09:26 |
azonenberg | the wrapper is intended to make that easy should i choose to do so | 09:26 |
azonenberg | in any case the sun is coming up so i'm off to get some sleep | 09:27 |
wpwrak | basically sed s|/nfs/home/azonenberg/Documents/local/Electronics/kicad-|../../| | 09:29 |
azonenberg | wpwrak: interesting, they're P3-6 in my design | 09:35 |
azonenberg | guess i never committed that version | 09:35 |
azonenberg | will do that after i do a final review of the design for things like power trace widths etc | 09:35 |
azonenberg | and i had it set to absolute paths? Good catch | 09:36 |
wpwrak | azonenberg: hmm, you could shrink the OHW logo and bring some I/Os out on a 100 mil header. easier for debugging (scope probes and such) than the small stuff | 09:48 |
wpwrak | azonenberg: is the bead really enough to make bead+220 uF silo behave like the 44 R+10 uF usb 2.0 allows ? (page 177, section 7.2.4.1) | 10:38 |
azonenberg | wpwrak: i will definitely be adding some more headers | 17:51 |
azonenberg | re the cap, good point | 17:51 |
azonenberg | i'm used to running off wallwarts | 17:51 |
azonenberg | and putting a ton of capacitance on | 17:51 |
azonenberg | i probably dont need nearly that much before the reg if its running off a nice stable usb supply | 17:51 |
azonenberg | Yeah | 17:52 |
azonenberg | Debating whether to go with a 10uf ceramic or a 47uf tant | 17:52 |
azonenberg | since its after the bead | 17:52 |
azonenberg | lol wow | 17:55 |
azonenberg | yeah, i have a massive amount of capacitance on my SBC board | 17:55 |
azonenberg | But it's also a LX16/25 plus DDR memory so it needs it | 17:55 |
azonenberg | and its running on a wallwart | 17:55 |
azonenberg | Good suggestions, guys... i should get this done more often | 17:57 |
azonenberg | Going to fix up a bunch of stuff and add some debug points (scope ground clip etc) | 17:59 |
azonenberg | then commit an updated version in a few hours... if nobody sees any problems in that version i'll send it out for first-round fab | 17:59 |
lekernel | azonenberg: if you like a challenge, I'll have the M3 board to get done ;) | 18:03 |
azonenberg | i don't think i'm quite that good at layout yet lol | 18:03 |
azonenberg | i wouldnt mind looking over it and offering suggestions | 18:03 |
azonenberg | which fpga are you using on it? | 18:04 |
lekernel | azonenberg: btw I'm looking for potassium tantalate niobate (aka KTaNbO3 or KTN) crystals - any clues? | 18:06 |
azonenberg | lekernel: ooh, artix | 18:06 |
azonenberg | do you have a source for them yet or is this planning for the future? | 18:06 |
azonenberg | Also have you considered Zynq and, if you decided against it, what was your reasoning? | 18:07 |
azonenberg | seems like the a9 would outperform LM32 by a huge margin | 18:08 |
azonenberg | mumptai: yes | 18:08 |
azonenberg | So it's no less free than a proprietary FPGA with open RTL | 18:08 |
azonenberg | a proprietary CPU with open code | 18:08 |
azonenberg | Correct | 18:09 |
azonenberg | but so is the rtl for the boot loader on an FPGA that reads from SPI etc | 18:09 |
azonenberg | I do agree with that | 18:09 |
azonenberg | I wasn't recommending it, just curious as to your reasoning | 18:09 |
azonenberg | I see | 18:14 |
azonenberg | re the crystals, no clue | 18:14 |
azonenberg | i have a source for TaxClx | 18:14 |
azonenberg | in ethanol solution | 18:14 |
azonenberg | which upon spin coating and heating forms Ta2O5 for optical coatings, high-K, hardmasking, etc | 18:14 |
azonenberg | thats the only tantalum compound i know where to get | 18:15 |
azonenberg | wpwrak: ok, so now the bottom right area by the jtag header has a 2x4 header of GPIO | 21:05 |
azonenberg | cap is 47uF | 21:05 |
azonenberg | i'll be adding a scope ground clip and some probe pads shortly | 21:05 |
azonenberg | Ok | 21:06 |
azonenberg | wpwrak: http://i.imgur.com/ZgxF4.png | 21:27 |
azonenberg | added a 2x4 header for GPIO (eight signals, no power/ground) plus a ground clip for a scope and a bunch of labeled probe pads on the power rails and clock | 21:28 |
azonenberg | still room for more probe pads in the upper right and between the fpga and jtag area | 21:28 |
azonenberg | i just want to avoid breaking the ground plane under the GPIO traces at right center since those are LVDS capable and i want the option of decently high speed | 21:28 |
azonenberg | Six signals / 3V3 / gnd? | 21:35 |
azonenberg | i cant fit more than 8 pins there | 21:35 |
azonenberg | I'm puttnig stuff there too | 21:36 |
azonenberg | i just dont want pins to go to waste | 21:36 |
azonenberg | which one? | 21:36 |
azonenberg | the one above the led bank? thats actually a cap | 21:37 |
azonenberg | i run the same LDOs on my LX16 board | 21:37 |
azonenberg | i wouldnt go any bigger but they're fine for a LX9 | 21:37 |
azonenberg | Header at bottom right is now 6 GPIO + 3V3 + gnd | 21:38 |
azonenberg | mumptai: oh, and the LX16 board has DDR memory on it | 21:39 |
azonenberg | without the RAM active it only pulls about 200 mA (800ish with the RAM going) | 21:39 |
azonenberg | at max power they get up to 75C or so, a bit warm but well below the 125 upper limit | 21:39 |
azonenberg | I'll move it to the underside | 21:40 |
azonenberg | there are vias right there anywy | 21:40 |
azonenberg | yes, i know | 21:41 |
azonenberg | http://imgur.com/a/RjpwX#0 | 21:43 |
azonenberg | front and back | 21:43 |
azonenberg | One thing i have yet to add is a little white silkscreen region on the back | 21:45 |
azonenberg | for Sharpie-ing a serial number onto | 21:45 |
azonenberg | i like to s/n all of my boards that i make mutiple units of so i can keep track of slight changes | 21:46 |
azonenberg | for example on one of my boards i put a lower density fpga on number 1 and 2/3 got the regular one | 21:46 |
azonenberg | Depends on if you're connecting to a grounded enclosure or not | 21:47 |
azonenberg | (for EMI reasons) | 21:47 |
azonenberg | if you are not, you can always use a plastic washer | 21:47 |
azonenberg | but i figure it'd be nice to have the option of grounding it | 21:47 |
azonenberg | if you disagree and can provide a good reason i'll certainly think about it | 21:48 |
azonenberg | hmm, well my other board i made is not grounded on the holes | 21:48 |
azonenberg | i guess i can isolate them | 21:48 |
azonenberg | hmm ok | 21:50 |
azonenberg | i just know i've seen RF stuff with copper-painted cases | 21:50 |
azonenberg | where the board has a via fence all around the edge that's screwed down | 21:50 |
azonenberg | Ok, fixed | 21:51 |
azonenberg | also added a silkscreen area on the back for writing in the s/n | 21:53 |
azonenberg | wolfspraul: how's it looking now? | 21:56 |
azonenberg | lekernel: lol is that expensive or cheap? | 23:30 |
azonenberg | also, http://siliconexposed.blogspot.com/2012/06/isim-bugs-and-introducing-red-tin.html | 23:30 |
azonenberg | alpha testers wanted | 23:31 |
azonenberg | lekernel: lol the furnace i was going to get was a 4 inch cube, only $1200 | 23:33 |
azonenberg | wpwrak: yeah lol | 23:34 |
azonenberg | But its not like altera or lattice or actel is any better | 23:35 |
azonenberg | and boycotting programmable logic entirely isnt a viable option | 23:35 |
azonenberg | I believe so | 23:40 |
azonenberg | I dont know specifically about simulation model line counts | 23:40 |
azonenberg | i know the free ones have device capacity limitations | 23:40 |
azonenberg | and people wonder why folks like wolfspraul are making their own tools? :P | 23:43 |
azonenberg | wolfspraul: http://imgur.com/a/RjpwX#0 | 23:44 |
azonenberg | updated version of the board | 23:44 |
azonenberg | i added a bunch of silkscreen text to label stuff, and added a 2x4 header at bottom right | 23:45 |
azonenberg | plus a scope ground clip and probe pads on all power rails plus the clock | 23:45 |
azonenberg | there's not much i can fit in the top right | 23:46 |
azonenberg | because the right side bank is mostly used | 23:46 |
azonenberg | the top bank is completely empty but i cant use it for anything since the power supply is in the way | 23:46 |
azonenberg | lol | 23:46 |
azonenberg | well i felt like i had to put *something* there | 23:46 |
azonenberg | lol | 23:47 |
azonenberg | Anyway, last call for suggestions | 23:47 |
azonenberg | i'm sending gerbers out to batch fab in an hour or two | 23:47 |
wpwrak | azonenberg: btw, this is for your vi: :%s#/nfs/home/azonenberg/Documents/local/Electronics/kicad-#../../# | 23:48 |
Action: azonenberg doesnt vi | 23:48 | |
Fallenou | very nice blog post azonenberg :) | 23:49 |
azonenberg | wolfspraul: that minimalistic LX9 board we talked about is in progress at http://code.google.com/p/azonenberg-devboards/source/list | 00:12 |
---|---|---|
azonenberg | so far i've just published my existing libraries (needed to do that anyway and this was a good excuse) as well as creating a skeleton schematic with a usb UART and some linear reg | 00:20 |
azonenberg | i should have the sch done in an hour or so | 00:20 |
azonenberg | ok | 00:30 |
azonenberg | I'm releasing my board under BSD license btw | 00:31 |
azonenberg | with a comment added in the LICENSE file to make it clear that "binary form" includes physical PCBs, gerbers, masks, or anything other than native CAD formats | 00:31 |
azonenberg | Lol | 00:34 |
azonenberg | IANAL but i think this is pretty unambiguous http://pastebin.com/Zt59CErn | 00:34 |
azonenberg | "The two categories combined are intended to encompass all possible uses of these designs." leaves little room for misunderstanding, i think | 00:36 |
azonenberg | wpwrak: there is, they have to acknowledge your work | 02:22 |
azonenberg | and then there's the "use at your own risk" clause which never hurts | 02:23 |
azonenberg | But other than the acknowledgement requirement, not really | 02:23 |
azonenberg | wpwrak: yeah | 02:28 |
azonenberg | But it's widely used and imposes virtually no restrictions that would result in someone choosing not to use it | 02:29 |
azonenberg | Hence why i like it | 02:29 |
azonenberg | wolfspraul: schematic done, starting layout | 02:30 |
azonenberg | i included a few optional components (FT232, GPIO header, flash) that can be left off if you want a simpler/cheaper design | 02:33 |
azonenberg | the area cost is near zero | 02:33 |
azonenberg | device is bus powered (mini USB) | 02:33 |
azonenberg | i'm going to add a ground clip for a scope plus a bunch of probe pads once i do rough-draft layout | 02:34 |
wpwrak | azonenberg: i think the idea is to have a two board design: one board with just the FPGA (which wolfgang expects to destroy with his experiments) and another board with the more permanent components (power and such) | 02:35 |
azonenberg | wpwrak: well i want to be able to use the board too | 02:36 |
azonenberg | so i figure i'll just put on all the stuff | 02:36 |
azonenberg | then document which parts can be left off | 02:36 |
azonenberg | and i cnat imagine any failure mode that would destroy the rest of the board | 02:36 |
azonenberg | reworking the chip is a matter of hot air and 5 minutes | 02:36 |
azonenberg | wpwrak: the component count is minimal though | 02:37 |
azonenberg | its just decoupling caps | 02:37 |
azonenberg | which have to be on the fpga board itself | 02:37 |
azonenberg | the support stuff is literally three vregs and a jtag port | 02:37 |
azonenberg | plus peripherals you can leave off (clock crystal, some LEDs, reset button, SPI flash) | 02:38 |
azonenberg | and you'd have to solder the new fpga to a new board anyway | 02:42 |
azonenberg | Taking an old one off with hot air is the work of 15 seconds | 02:42 |
azonenberg | wolfspraul: it looks like it'll be around 4 in^2 btw | 02:57 |
azonenberg | Trying to shrink but not sure how much i can do | 02:57 |
azonenberg | the fpga itself is like a square inch by itself and i need room around it for routing lol | 02:57 |
azonenberg | wolfspraul: http://i.imgur.com/8pUkp.png | 22:35 |
azonenberg | wolfspraul: it's on google code | 22:39 |
azonenberg | i've committed that version | 22:39 |
azonenberg | the tinyurl goes straight to the SVN url for checking out the board files | 22:39 |
azonenberg | and i am going to make one more verification pass | 22:39 |
azonenberg | then send a run of 3 out to batch fab | 22:39 |
azonenberg | lead time for fab+assembly+test will be around a month | 22:40 |
azonenberg | I'd appreciate a peer review before sending it out to fab | 22:40 |
azonenberg | on the version in the repo | 22:40 |
azonenberg | Just as a quick overview of what's on there - 3.3, 2.5, 1.2V regulators | 22:40 |
azonenberg | mini USB port for power plus optional FT232RQ usb-uart | 22:41 |
azonenberg | Ok | 22:41 |
azonenberg | It also has eight LEDs, a reset switch (which needs a "RESET" label still), a 5x7mm CMOS oscillator, a W25Q80BV flash chip or similar, a 20-pin FFC connector for GPIO (same pinout as all of my other boards), the usual 2x7mm JTAG header | 22:42 |
azonenberg | as well as 10-pin FFC, which is my experimental nonstandard low-profile JTAG solution (much smaller than the normal Molex connector) | 22:43 |
azonenberg | i left the standard one on there too both as a backup and for easy interoperability | 22:43 |
azonenberg | Grounded 4-40 mounting holes in each corner, inset 2mm from the edges of the PCB | 22:44 |
azonenberg | i'm going to draw up a formal BOM including digikey part numbers for all components | 22:45 |
kristianpaul | nice looking board azonenberg !! | 22:53 |
azonenberg | kristianpaul: ty | 22:54 |
azonenberg | it's intended as a fairly minimalistic spartan6 platform | 22:54 |
azonenberg | drawing up a BOM workup now to find the per-unit cost | 22:54 |
azonenberg | most of the components on there can be left off to cut costs if you dont need them | 22:55 |
azonenberg | Just finished the layout like 15 mins ago | 22:55 |
azonenberg | And i have all the parts except the FPGA in my inventory already | 22:55 |
azonenberg | while i do have spartan6 in inventory now they're all FT256 package | 22:55 |
azonenberg | so i'm gonna have to order some tqfp ones | 22:55 |
azonenberg | wolfspraul: unless you want to use ring oscillators (unstable and uncontrolled frequency) you'll need the osc | 23:10 |
azonenberg | you need 1.2 for the core and 2.5 or 3.3 for vccaux (configuration, PLLs, and a few other things) | 23:11 |
azonenberg | plus vccio | 23:11 |
azonenberg | the osc i specified is a 3.3v part | 23:11 |
azonenberg | so you'd need all 3 | 23:11 |
azonenberg | i suppose you could remove the 2.5V reg and solder a wire from the 2.5V rail to the 3.3 | 23:12 |
azonenberg | the chip can run at 3.3 on vccaux | 23:12 |
azonenberg | but for saving 50 cents idk if it's worth it | 23:12 |
azonenberg | you might be able to route it off CCLK i suppose | 23:13 |
azonenberg | In any case i'm documenting the optional parts | 23:14 |
azonenberg | in the BOM | 23:14 |
azonenberg | sorry, cclk isnt it | 23:15 |
azonenberg | tck | 23:15 |
azonenberg | typo | 23:15 |
azonenberg | cclk is the clock the fpga supplies to an external SPI flash chip during boot | 23:15 |
azonenberg | there's an oscillator on the fpga but to my knowledge it's not exposed onto the routing fabric | 23:15 |
azonenberg | i dont think its possible to | 23:17 |
azonenberg | i think the configuration state machine shuts it off | 23:17 |
azonenberg | Let me rephrase that | 23:18 |
azonenberg | i am not aware of a documented and vendor-supported means of doing that | 23:18 |
azonenberg | The decoupling network is probably overkill unless you're doing high speed stuff but it's basically right off their reference designs | 23:21 |
azonenberg | for the LX9 | 23:21 |
azonenberg | so i'm going to let sleeping dogs lie | 23:21 |
azonenberg | Hawk777: ooh | 23:43 |
azonenberg | very interesting | 23:43 |
azonenberg | So highly variable, probably on-chip RC, but it is exposed | 23:43 |
azonenberg | Not sure if it stops when the TAP isn't being probed | 23:44 |
azonenberg | if you just plug the cable into a circuit does it start clocking it? | 23:44 |
azonenberg | or is it only during a scan operation | 23:44 |
azonenberg | from what i know of the jtag state machine, it has to not clock during some parts of the process | 23:45 |
azonenberg | In any case, quick draft bom at http://code.google.com/p/azonenberg-devboards/source/browse/trunk/boards/minimal-spartan6-tq144/bom.txt | 23:45 |
azonenberg | i'm still looking up digikey part numbers for some of the stuff and have yet to pretty it up (tabs to spaces, etc) | 23:45 |
lekernel | azonenberg: have you read this? http://download.micron.com/pdf/technotes/DDR/tn4614.pdf | 09:04 |
---|---|---|
azonenberg | lekernel: i've read a bunch of appnotes, let me see that one | 15:12 |
azonenberg | Well they very strongly recommend 6-layer (3S3P or 4S2P) stackups in most cases lol | 15:13 |
azonenberg | so i'm already violating most of their guidelines by using 2 layers :p | 15:13 |
azonenberg | sorry, 2 signal layers | 15:13 |
azonenberg | 2S2P on 4 layers | 15:13 |
azonenberg | oh, and lack of controlled impedance | 15:16 |
azonenberg | But i dont think that at 240 MT/s (120 MHz) that wil.l matter quite as much as 400 MT/s 200 MHz | 15:16 |
azonenberg | wpwrak: not for DDR memory lol | 15:17 |
azonenberg | I was getting ~160mV peak to peak ripple on my SSTL Vref | 15:17 |
azonenberg | put 10nF across the output of the regulator (right by the reg, the RAM is about 1/2" away and the FPGA 1-2" away) and ripple went down but i still am getting a lot of bit corruption | 15:18 |
azonenberg | once i'm fully awake i'm gonna put another 10nF across the other side of the Vref bus near the FPGA | 15:18 |
azonenberg | i dont want to put the board under the knife until i'm awake | 15:18 |
azonenberg | lol | 15:18 |
azonenberg | i also dont know for sure if Vref is the only problem | 15:18 |
azonenberg | i know i was getting crosstalk on Vref from DQ1 | 15:19 |
azonenberg | they're routed worryingly close | 15:19 |
azonenberg | Fallenou: http://i.imgur.com/tEL3p.png | 15:19 |
azonenberg | this is top and bottom copper only with ground fills hidden | 15:19 |
azonenberg | LP2995 reg outputs two independent 1.25V lines for Vtt and Vref (the SOIC8 at top left near the big tant caps) | 15:19 |
azonenberg | Vref runs on bottom layer (green) down the left side of the board | 15:19 |
azonenberg | under the DDR chip, then in to the FPGA at the bottom left | 15:20 |
azonenberg | this area here http://i.imgur.com/9yJYe.png is where i think noise is getting in | 15:20 |
azonenberg | all manual | 15:20 |
azonenberg | http://i.imgur.com/vhcBU.png shows that there's ground between the Vref trace and all other signal routing | 15:20 |
azonenberg | this is the full bottom layer including ground fills | 15:21 |
azonenberg | Vref is the long snaky trace on the left | 15:21 |
azonenberg | http://i.imgur.com/q7Jls.jpg is the assembled board (not that that will tell you much) | 15:21 |
azonenberg | its an 8 bit data bus and i'm testing with 0x00FF00FF since thats worst case crosstalk from DQ* to other signals and worst-case SSO | 15:21 |
azonenberg | No | 15:22 |
azonenberg | Stackup is signal and ground fill on top | 15:22 |
azonenberg | then a power plane broken in a few spots (mostly under the DDR chip and between it and the FPGA) for extra signal routing | 15:22 |
azonenberg | then solid ground broken only by via antipads | 15:22 |
azonenberg | then the green layer, signal with ground fill | 15:22 |
azonenberg | all main components are on top copper except for the INA226 current shunt monitors (under the power supply area at top left) | 15:23 |
azonenberg | most small bypass caps are on the bottom but all of the big tantalum/ceramic tank caps are on top | 15:23 |
azonenberg | when i write 0x00FF00FF to the bus with no capacitance on Vref, it read back as 00FB00FF (I don't know whether the write or read was corrupted, that's still being investigated) | 15:26 |
azonenberg | My oscilloscope is 1Gsa/s with 100 MHz bandwidth so DDR at 120 MHz/240 MT/s is a little fast | 15:27 |
azonenberg | http://imgur.com/a/HC7Cf#4 shows Vtt Vref DQ0 left to right | 15:27 |
azonenberg | and bus idle and active top to bottom | 15:27 |
azonenberg | when i put the capacitance on, Vref ripple dropped by a lot but the test data read as 00F800FF (even worse!) | 15:28 |
azonenberg | the wrong values are consistent across all tests i've run so far | 15:28 |
azonenberg | i need to get time on a faster scope... | 15:28 |
azonenberg | lekernel: 8 bits | 21:59 |
---|---|---|
azonenberg | i scoped the board a bit | 21:59 |
azonenberg | high ripple current on Vref | 21:59 |
azonenberg | looks like insufficient decoupling and/or crosstalk | 21:59 |
azonenberg | going to put a decoupling cap on it and see if it goes away | 21:59 |
azonenberg | if not, will investigate further | 21:59 |
lekernel | azonenberg: how many DQ bits do you have between the dram chip and the fpga? | 07:26 |
---|
azonenberg | Woo, i now have an alpha of my internal LA ready to go | 02:00 |
---|---|---|
azonenberg | http://code.google.com/p/red-tin-logic-analyzer/ | 02:00 |
azonenberg | whoops i meant http://code.google.com/p/red-tin-logic-analyzer/downloads/list | 02:02 |
azonenberg | lekernel: so you seem to have more fpga debugging experience than me | 15:36 |
azonenberg | i have a design that outputs status information to a bank of eight LEDs | 15:36 |
azonenberg | Changing the (status bit -> LED) mapping seems to change the behavior of the circuit | 15:36 |
azonenberg | preliminary looking at the PCB footprint suggests an electrical short should be impossible, the balls in question are very far away from each other (and are surrounded by other signals known to not be shorting) | 15:37 |
azonenberg | and the traces never run near each other | 15:37 |
azonenberg | lekernel: http://i.imgur.com/xrwDm.png | 17:23 |
azonenberg | actual data pulled off my MCB debugging | 17:23 |
azonenberg | it looks to be working | 17:23 |
Fallenou | congratz azonenberg :) | 18:22 |
azonenberg | Fallenou: of course it also means i've found a bug in the xilinx datasheet | 18:23 |
azonenberg | because my code breaks when i follow the timing in the datasheet | 18:23 |
azonenberg | and works when i assume something happens combinatorially instead of being buffered | 18:23 |
azonenberg | Yep | 18:23 |
azonenberg | that capture is using 105 of 128 channels | 18:24 |
azonenberg | and yes | 18:24 |
azonenberg | actually there's 16 samples before the trigger | 18:24 |
azonenberg | only two clocks are shown, i scrolled a little | 18:24 |
azonenberg | Yeah, thats why i wrote it | 18:25 |
azonenberg | did you see the googlecode link? | 18:25 |
azonenberg | i have an alpha release out and am looking for people to test it | 18:25 |
azonenberg | http://code.google.com/p/red-tin-logic-analyzer/downloads/list | 18:25 |
azonenberg | the baud rate in the UART wrapper is hard coded for 500 Kbps at 20 MHz, to clock at a different speed you'll have to patch it | 18:26 |
azonenberg | i forgot to add a parameter to do that :p | 18:26 |
azonenberg | No worries | 18:27 |
azonenberg | just keep it in mind and if you do test it, let me know if you found it useful / found bugs / both | 18:27 |
azonenberg | ok :) | 18:27 |
azonenberg | Lol | 18:28 |
azonenberg | I wrote the manual in one evening while doing some other stuff | 18:28 |
azonenberg | So it might not be too complete :p | 18:28 |
azonenberg | <3 LaTeX | 18:29 |
azonenberg | http://pastebin.com/Ff6H6jnx | 21:38 |
azonenberg | Does this look like bad RAM to you guys btw? | 21:38 |
azonenberg | or SI issues? | 21:38 |
azonenberg | or something else | 21:38 |
kristianpaul | after all the key is having visual aid? azonenberg ? | 19:02 |
---|---|---|
azonenberg | kristianpaul: both stable hands and magnification are important | 19:51 |
azonenberg | lol | 17:01 |
---|---|---|
azonenberg | So I'm making good progress on my internal LA, it now computes all of the trigger masks properly | 17:02 |
azonenberg | i should have a testable alpha later today or tomorrow at the latest | 17:02 |
azonenberg | this is what the UI looks like now http://i.imgur.com/TaWUA.png :D | 17:02 |
azonenberg | wolfspraul: see above | 17:06 |
lekernel | azonenberg: looks good. but have you had a look at sigrok, finally? | 17:23 |
azonenberg | lekernel: they're intended for different purposes | 17:47 |
azonenberg | Most of what i'm doing would have to be redone anyway if i was making a sigrok plugin, it looks | 17:47 |
azonenberg | My entire project is focused on data acquisition | 17:48 |
azonenberg | the analysis can be done by anything that can read a vcd file | 17:48 |
azonenberg | for now i'm using gtkwave | 17:48 |
azonenberg | you'd need to write a libsigrok plugin to interface with the hardware anyway | 17:49 |
azonenberg | and that's about all i'm doing | 17:49 |
azonenberg | that equivalent module | 17:49 |
azonenberg | wpwrak: yes, that is annoying | 01:31 |
---|---|---|
azonenberg | i understand the need for load balancing | 01:31 |
azonenberg | but that can be done server side | 01:31 |
azonenberg | wolfspraul: also, initial UI mockup for the control panel http://i.imgur.com/xGozm.png | 01:31 |
azonenberg | kristianpaul: * | 01:31 |
azonenberg | you'd use this to dial in what signals you're watching (a future, more advanced version may be able to parse HDL but thats a much longer term project) | 01:32 |
azonenberg | then specify trigger conditions | 01:32 |
azonenberg | then hit the "start" button | 01:32 |
azonenberg | once the trigger condition occurs, it'll launch gtkwave with the data of interest | 01:32 |
azonenberg | wpwrak: thats up to gtkwave | 01:33 |
azonenberg | make a plugin for it | 01:33 |
azonenberg | my job is just to get data from the board into a .vcd file | 01:33 |
azonenberg | and launch $VCD_VIEWER (currently gtkwave) to render it | 01:33 |
azonenberg | I dont know if it can | 01:34 |
azonenberg | what i do know is, that's beyond the scope of the LA | 01:34 |
azonenberg | i'm doing capture and transport | 01:34 |
azonenberg | not the presentation layer | 01:34 |
azonenberg | Good point | 01:34 |
azonenberg | Thats a much longer term project though | 01:34 |
azonenberg | The trigger systm i have now is adequate for catching the single bug i'm developing the tool for | 01:35 |
azonenberg | once i have it finished to the point that i can use it, i'll then use it to catch my bug | 01:35 |
azonenberg | Right now, i use four block RAMs | 01:35 |
azonenberg | each 32 bits wide x 512 bits deep | 01:35 |
azonenberg | to get 128 channels x 512 samples | 01:35 |
azonenberg | You could make it deeprr | 01:35 |
azonenberg | remember this is better than a normal LA for fpga stuff since you are capturing on a clock | 01:36 |
azonenberg | so you dont need to oversample unless you're looking for glitches | 01:36 |
azonenberg | so 512 samples = 512 clocks | 01:36 |
azonenberg | This isnt meant to replace a conventional LA | 01:36 |
azonenberg | this is meant to replace chipscope | 01:36 |
azonenberg | and i cant stream to dram | 01:36 |
azonenberg | for one very simple reason | 01:37 |
azonenberg | i'm trying to fix a bug in my dram controller | 01:37 |
azonenberg | using this tool :p | 01:37 |
azonenberg | So block ram is a necessity lol | 01:37 |
azonenberg | a dram based back end is a possibility for a future version | 01:37 |
azonenberg | as a plugin | 01:37 |
azonenberg | i want to make it highly modular | 01:37 |
azonenberg | i'm already setting it up so the PC interface is modular | 01:37 |
azonenberg | the interface implemented right now is a uart at 500kbps but that can be swapped out with usb, ethernet, jtag, etc potentially | 01:38 |
azonenberg | though uart is the only one i'm implementing in the short term | 01:38 |
azonenberg | 64 kbits * 500kbps = fraction of a second | 01:38 |
azonenberg | so its not a bottleneck | 01:38 |
azonenberg | you could always use more block ram too | 01:38 |
azonenberg | but this is meant to be a minimally invasive debugging solutoin | 01:39 |
azonenberg | that you can throw in almost anywhere | 01:39 |
azonenberg | the current system including a 32-bit counter (my DUT) and the UART | 01:39 |
azonenberg | uses less than 100 spartan6 slices and four block rams | 01:39 |
azonenberg | wpwrak: yeah | 01:43 |
azonenberg | And i want to do something like that TOO | 01:43 |
azonenberg | But my goal right now is to make something useful for fpga debugging | 01:43 |
azonenberg | where you can't simulate for some reason | 01:44 |
azonenberg | and you dont want to break out to GPIOs and hook up to a regular LA | 01:44 |
azonenberg | either for lack of GPIOs or lack of a LA or whatever | 01:44 |
azonenberg | or in my case lack of a sufficiently fast LA | 01:44 |
azonenberg | So i dont wnat to have for example super sophisticated triggering systems | 01:45 |
azonenberg | as that would either make it slower or bigger | 01:45 |
azonenberg | both are counterproductive in this case | 01:45 |
azonenberg | i also dont want it so complex i have to spend a long time debugging it | 01:46 |
azonenberg | which is that? | 01:50 |
azonenberg | This is a tool, not one of my main projects | 01:51 |
azonenberg | a necessary step on the road toward world domination is to be able to debug your robot army :p | 01:52 |
kristianpaul | azonenberg: nice | 02:02 |
azonenberg | kristianpaul: how so | 02:02 |
azonenberg | Oh | 02:02 |
azonenberg | This is meant for raw data dumps though | 02:02 |
azonenberg | and it captures in real time at high speed and then dumps slowly | 02:03 |
azonenberg | and integrates nicely with gtkwave for plotting signals :) | 02:03 |
azonenberg | sure, there are other ways to solve the same problem | 02:03 |
azonenberg | but i think this one will work well for a lot of applications | 02:03 |
azonenberg | Lol well i'm trying to debug a memory bus | 02:07 |
azonenberg | so i have ~25 bits of address, 32 of data, and a few other things | 02:07 |
azonenberg | http://www.eejournal.com/archives/articles/20080212_lattice/ | 02:08 |
azonenberg | might find that interesting | 02:08 |
wolfspraul | azonenberg: nice project indeed, good luck with polishing/blog etc! You may want to tell the sigrok folks about it (sigrok.org). do you know sigrok? they have different hw&sw right now, mostly, but they might be interested in your LA. | 02:47 |
azonenberg | wolfspraul: no, i dont know them | 03:30 |
azonenberg | Just curious, how do you guys typically debug? | 16:55 |
---|---|---|
azonenberg | Simulation? Observe actual behavior in hardware? Break signals out to GPIOs and use a LA? Chipscope? All of the above? | 16:55 |
azonenberg | i'm trying to debug some of my code that uses DRAM and thus would be difficult to downclock, and it's too big to simulate in the free ISim at a reasonable speed | 16:58 |
azonenberg | and its too fast for my LA | 16:58 |
azonenberg | So i decided to build my own internal LA similar to chipscope, it currently has 128 channels and programmable triggers (rising, falling, low, and high on each of 128 channels, AND the results together and OR with external trigger) | 16:59 |
azonenberg | logs 512 samples to block RAM on a provided clock | 16:59 |
azonenberg | then dumps over a UART and renders in gtkwave | 16:59 |
azonenberg | first successful capture http://i.imgur.com/V911H.png | 16:59 |
kristianpaul | sharing is caring azonenberg :-) (ABout internal LA) | 17:00 |
azonenberg | if anybody is interested once i polish the toolchain a bit i'll be looking for beta testers, it's BSD licensed | 17:00 |
azonenberg | or will be once i post it somewhere public, right now its just a directory on my laptop :P | 17:00 |
azonenberg | Think you guys would find it useful? | 17:00 |
azonenberg | on spartan6 -3 it can get up to almost 200 MSa/sec (180 i think) and if you cut the number of channels to 64 or 32 it would be even faster | 17:01 |
azonenberg | uses four block ram and a few dozen slices | 17:01 |
azonenberg | The current implementation has 512 samples deep memory but that would be easy to tweak | 17:01 |
azonenberg | its not fully parameterizable yet, thats one of the things i plan to tweak before release | 17:02 |
azonenberg | It uses the open source uart core i wrote a while ago | 17:02 |
azonenberg | i didnt like the opencores ones since they were wishbone and i needed native interface | 17:02 |
azonenberg | Well | 17:02 |
azonenberg | there's four components to it | 17:02 |
azonenberg | first is the core LA | 17:02 |
azonenberg | which is trigger and a dual ported block ram | 17:02 |
azonenberg | second is the wrapper that, when the LA asserts DONE, dumps to the PC over some interface | 17:02 |
azonenberg | right now that's a uart at 500 Kbps but you could replace it with usb, ethernet, etc easily | 17:03 |
azonenberg | third is a short C++ program that takes data from the uart and reformats it into a standard .vcd file, taking the 128-bit raw samples and splitting them up according to the signals you defined (buttons and count in this screenshot) | 17:04 |
azonenberg | then fourth is the waveform viewer, i'm using an existing tool (gtkwave) for that | 17:04 |
azonenberg | its all modular so by replacing blocks 2 and 3 you could easily adapt it to any interface other than uart | 17:04 |
azonenberg | uart is what i had on this board | 17:04 |
azonenberg | plus 100mbit ethernet but i dont have HDL to interface to it yet | 17:04 |
azonenberg | the big thing left to do before a v0.1 alpha release is to make component 3 a little more polished | 17:05 |
azonenberg | for example don't hardcode /dev/ttyUSB0 | 17:05 |
azonenberg | and dont hardcode the channel-to-signal mappings | 17:05 |
azonenberg | and allow trigger to be updated at run time rather than hardcoded on the FPGA | 17:05 |
azonenberg | It samples continually | 17:05 |
azonenberg | in a ring buffer | 17:05 |
azonenberg | thereare three pointers | 17:05 |
azonenberg | start, write, and stop | 17:06 |
azonenberg | in the "waiting for trigger" state, write is start+16 | 17:06 |
azonenberg | and stop is start+512 | 17:06 |
azonenberg | once triggered, start and stop freeze | 17:06 |
azonenberg | and it stops capture when write = stop\ | 17:06 |
azonenberg | so you get 16 samples before trigger and (512-16) after | 17:06 |
azonenberg | then once the wrapper has sent the data tothe PC it resets the LA | 17:07 |
azonenberg | so you can capture again | 17:07 |
azonenberg | in my screenshot i had the trigger set as rising edge of buttons[0] | 17:07 |
azonenberg | the red cursor is at the trigger point | 17:07 |
lekernel | azonenberg: why not use the milkymist dram controller? | 17:07 |
azonenberg | lekernel: thats irrelevant, the code is in my bridge between the CPU and the dram | 17:07 |
azonenberg | not the MCB | 17:08 |
azonenberg | the bug* | 17:08 |
azonenberg | i intend to try using it in the future | 17:08 |
azonenberg | it should be drop-in for the MCB if i rewrite the bridge | 17:08 |
azonenberg | the problem i have now is that the bridge is occasionally losing data or something like that (hangs) | 17:08 |
azonenberg | and i cant clock it any slower | 17:08 |
azonenberg | and the MCB primitive wont simulate in isim lite | 17:08 |
azonenberg | and i dont have a chipscope license | 17:08 |
azonenberg | solution? make my own | 17:08 |
azonenberg | This is completely standalone | 17:09 |
azonenberg | you have two modules | 17:09 |
azonenberg | RedTinLogicAnalyzer is the core | 17:09 |
azonenberg | then (unnamed wrapper thats currently part of my testbench) reads the data from that into a PC interface such as a uart | 17:09 |
azonenberg | you could even log to SD if you didnt have a pc handy | 17:09 |
azonenberg | and then analyze the capture later | 17:10 |
azonenberg | lekernel: interesting but isim still has a 50k line limit | 17:10 |
azonenberg | which i will hit sooner or later | 17:10 |
azonenberg | probably sooner | 17:10 |
azonenberg | I intend to explore that | 17:10 |
azonenberg | In any case that's all irrelevant, the point is i'm workign on this tool and i'll have an alpha out for you guys to play with soon | 17:10 |
azonenberg | and its free software | 17:10 |
azonenberg | I'll be polishing it for another day or two and then release an alpha on google code probably this weekend some time | 17:11 |
azonenberg | when that happens i'll do a short blog post on it | 17:11 |
azonenberg | lekernel: chipscope or the MCB? | 17:11 |
azonenberg | mcb, because i had been using it before i knew your controller existed | 17:11 |
azonenberg | cpu, because i like mips and there's no good open source mips core out there | 17:11 |
azonenberg | plasma is so-so (3 stage pipeline and slow), mine is meant to go faster | 17:12 |
azonenberg | i have an existing codebase for it with lots of asm | 17:12 |
azonenberg | thats really the main reason | 17:12 |
azonenberg | i was working on pic32 and outgrew its RAM capacity | 17:12 |
azonenberg | its a kernel | 17:12 |
azonenberg | not really an alternative for asm in context switching etc | 17:13 |
azonenberg | and i'm doing my thesis work on OS architecture and such so i need a cpu/os that is bare bones and simple to modify | 17:13 |
azonenberg | linux is a little too big to be easy to make sweeping changes to | 17:13 |
azonenberg | i also wanted practice in cpu design | 17:14 |
azonenberg | before i went on to the NEXT stage of my research which will involve major cpu architecture changes | 17:14 |
azonenberg | and chipscope, well... | 17:14 |
azonenberg | there is no open source alternative that i could find | 17:14 |
azonenberg | so it was a pretty simple decision | 17:14 |
azonenberg | well if you dont like my cpu you dont have to use it :p | 17:15 |
azonenberg | Most of my other projects were done to get experience with the technology and learn | 17:15 |
azonenberg | like the cpu | 17:15 |
azonenberg | i wanted to learn more about how to build an efficient pipelined microarchitecture given the instruction set but no details of how to implement it | 17:16 |
azonenberg | kristianpaul: yes | 17:16 |
azonenberg | its a fork of gcc with some pic-specific patches | 17:16 |
azonenberg | that arent in mainline yet | 17:16 |
azonenberg | but it is gcc and you can get source | 17:16 |
azonenberg | proprietary libc i think on pic32 | 17:16 |
azonenberg | i didnt use it | 17:16 |
azonenberg | my core is designed to work with mainline gcc plus a custom linker script for my memory map | 17:16 |
azonenberg | mipsel-elf target | 17:16 |
azonenberg | the original goal was to take my existing tens of thousands of lines of pic32 code | 17:18 |
azonenberg | and move it onto a similar platform with more ram | 17:18 |
azonenberg | saw it already | 17:18 |
kristianpaul | azonenberg: why you dont use wishbone? | 17:19 |
azonenberg | kristianpaul: for my low-end designs i wanted something simple and SRAM-esque | 17:20 |
azonenberg | the mips is getting fast enough that i probably will want a "real" bus on it at some point | 17:20 |
azonenberg | wishbone is on the list | 17:20 |
azonenberg | this is my first design that's needed to deal with DRAM | 17:20 |
azonenberg | Just created a google code project for it btw, http://code.google.com/p/red-tin-logic-analyzer/ | 17:22 |
azonenberg | will be pushing my code to it later today | 17:22 |
azonenberg | lekernel: the mcb is actually not giving me any trouble | 17:23 |
azonenberg | its the bridge between it and my code | 17:23 |
azonenberg | i'm overrunning their fifos | 17:23 |
azonenberg | and i cant figure out why | 17:23 |
kristianpaul | ok, now are you happy that azonenberg is coding a LA that could help us debug MM SoC? :-) | 17:29 |
azonenberg | You can use git, svn, or hg | 17:49 |
azonenberg | i prefer svn | 17:49 |
azonenberg | Lol well it isnt done yet | 17:55 |
azonenberg | and there's absolutely zero documentation atm :p | 17:55 |
azonenberg | I'd prefer to say "it's going to be nice" :p | 18:02 |
azonenberg | right now its a work in progress lol | 18:02 |
azonenberg | i just synced my repo over to the google code and will be doing future development there | 18:02 |
azonenberg | next step is going to be removing some of the hard-coded config and making it more tweakable | 18:03 |
lekernel__ | azonenberg, http://www.youtube.com/watch?v=LG1kVIIy2Ok Particle Accelerator on a Chip | 16:33 |
---|
azonenberg | Anybody know how many layers the MM1 board is? | 05:03 |
---|---|---|
wolfspra1l | azonenberg: 6 | 06:04 |
azonenberg | wolfspra1l: ok, thought so | 06:04 |
azonenberg | 'm trying to build a spartan6 board (FTG256) on 4 layers and its hard | 06:04 |
azonenberg | lekernel: yeah, SDRAM is nasty stuff | 09:05 |
---|---|---|
azonenberg | whether DDR or not | 09:05 |
azonenberg | lol | 09:05 |
azonenberg | Btw, roughly how big is the ethernet MAC you guys are using? In terms of slices | 09:06 |
Action: azonenberg wonders why we cant just talk to ram over LVDS | 09:07 | |
azonenberg | have like 16 source-synchronous DDR LVDS pairs clocked at a GHz or so | 09:07 |
azonenberg | is it compatible with existing, say, FPGAs? | 09:07 |
azonenberg | not that the hard MCBs etc will work | 09:08 |
azonenberg | And not that it matters to me since i dont yet have board fab capabilities to do BGAs that fine | 09:08 |
azonenberg | the newest RAM i can handle on my process is DDR in TSSOP since the BGA versions of DDR2/3 are too small | 09:08 |
azonenberg | pitch wise | 09:08 |
azonenberg | And i have to use FTG256 or FGG484 FPGAs | 09:09 |
azonenberg | CSG324 is too fine pitch for the fab's design rules | 09:09 |
azonenberg | http://i.imgur.com/X2I03.jpg is my first FTG256 board | 09:10 |
azonenberg | lekernel: i am very interested in REing the spartan6 bitstream formwat | 09:10 |
azonenberg | but i want to start small | 09:10 |
azonenberg | with say XC9500 CPLDs | 09:10 |
azonenberg | btw, speaking of which, XC9536XL-5VQG44 http://siliconpr0n.org/map/xilinx/xc9536xl_vqg44awn1105__neo50xulwd__semipol_lev_noz_dirty/ | 09:11 |
azonenberg | top metal, roughly gigapixel resolution | 09:11 |
azonenberg | no, i want to learn abourt xilinx's bitstreams in general | 09:12 |
azonenberg | the next will be spartan3a | 09:12 |
azonenberg | i have some i dont mind killing so i may decap and image them to study the die layout and see how accurately it matches the planahead / fpga editor views | 09:12 |
azonenberg | Yeah | 09:13 |
azonenberg | I may look at an original 4000 series first | 09:13 |
azonenberg | those are 350nm and big enough to do transistor-level RE of with the equipment me and my collaborators have | 09:13 |
azonenberg | Yeah | 09:14 |
azonenberg | Xilinx devices are high on our hit list | 09:14 |
azonenberg | but we're working our way up | 09:14 |
azonenberg | the CPLD came first since i had one around i didnt mind killing and it was only $1.60 | 09:14 |
azonenberg | plus it was a 350nm process whcih is big enouhg to fully image optically | 09:14 |
azonenberg | i dont need that many lol | 09:15 |
azonenberg | Let me ask my friend if he has any yet | 09:15 |
azonenberg | he may have some xc4000 series already | 09:15 |
azonenberg | just not decapped yet | 09:15 |
azonenberg | we have so many specimens its not even funny, the bottleneck is lab time | 09:15 |
azonenberg | he only has so many hours a day to work on it | 09:15 |
azonenberg | Nice | 09:15 |
azonenberg | Do you know if there are any patent concerns re writing FOSS toolchains btw? | 09:16 |
azonenberg | iow, if we do not implement an FPGA using their architecture | 09:16 |
azonenberg | but only target theirs with our software | 09:16 |
azonenberg | a) do they have any legal basis to complain | 09:16 |
azonenberg | b) do you think they would care, or welcome it | 09:16 |
azonenberg | Too sleepy to do technical reading but will check when i'm awake | 09:17 |
azonenberg | i meant for s3a/s6 | 09:18 |
azonenberg | 4000 is EOL'd so much they dont even support it in currnet ISE | 09:18 |
azonenberg | they wont care about that | 09:18 |
azonenberg | I just wonder if it'd prove impossible to get a toolchain for current generation architecture | 09:18 |
azonenberg | why must FPGAs be so secretive? Intel documents their instruction set | 09:19 |
azonenberg | and welcomes third party compilers | 09:19 |
azonenberg | so why cant fpga vendors do the same | 09:19 |
azonenberg | Hmm, I think i'm going about FPGA development more like ASIC development | 06:31 |
---|---|---|
azonenberg | I have printouts of spartan6 slices at various magnifications (ranging from 1x2 slices to the whole XC6SLX45) | 06:32 |
azonenberg | that i mark up with a pencil | 06:32 |
azonenberg | doing physical layout :p | 06:32 |
azonenberg | whoever sent me the link to Lava, i cant thank you enough | 06:32 |
wolfspraul | azonenberg: cool! :-) | 06:41 |
azonenberg | wolfspraul: this isnt physical, its from planahead | 06:45 |
azonenberg | although i am studying physical | 06:45 |
azonenberg | as well | 06:45 |
azonenberg | i have some XC9536 CPLDs that are decapped already and being imaged shortly | 06:45 |
azonenberg | i hav esome pics already but they're not full die | 06:45 |
azonenberg | spartan3a will be next | 06:45 |
azonenberg | s6 is further out as they're pricier :p | 06:46 |
azonenberg | i might do like an LX4 at some point though | 06:46 |
azonenberg | Yeah | 06:46 |
azonenberg | actually, let me upload a pic of this design now | 06:46 |
azonenberg | pencil on paper printout from planahead lol | 06:46 |
azonenberg | i'm not one of those "write the HDL and let the synthesis tool do the rest" types lol | 06:48 |
azonenberg | in fact, as soon as i fully understand one level of abstraction i find myself wanting to see what's underneath | 06:48 |
azonenberg | did you see my BGA board btw? http://colossus.cs.rpi.edu/pictures/2012/January/1-31-2012%20-%20BGA/S7302457.JPG | 06:48 |
azonenberg | this is spartan3a but i have some XC6SLX16 in the same package that are going on the next board | 06:48 |
azonenberg | home soldered | 06:48 |
azonenberg | that's FTG256 | 06:49 |
azonenberg | http://i.imgur.com/KYotZ.jpg | 06:49 |
azonenberg | sorry for bad lighting, its 2 AM here and my room isnt the brightest place | 06:49 |
azonenberg | you're working with xilinx FPGAs and you've never used it??? | 06:51 |
azonenberg | you have no idea what you're missing | 06:51 |
azonenberg | it's part of ISE | 06:51 |
azonenberg | it lets you do graphical IO pin planning, view a placed design on a physical (though somewhat stylized) layout of the chip | 06:52 |
wolfspraul | azonenberg: I'm in the learning department, forgive me ;-) | 06:52 |
azonenberg | color-code by hierarchal blocks | 06:52 |
azonenberg | view critical paths on the physical layout so you can get a feel for what's trying to talk to what | 06:52 |
azonenberg | that combined with color-coding by hierarchy is a very powerful tool for understanding when you're constrained by routing and placement rather than too many gate delays | 06:53 |
azonenberg | http://i.imgur.com/6JKOB.png | 06:53 |
azonenberg | random example of how i'd use it for timing analysis | 06:54 |
azonenberg | this is a rather extreme design (note the timing constraint in the lower panel) | 06:54 |
azonenberg | so i was hand-placing every FF and LUT | 06:54 |
azonenberg | It's been slow due to school etc | 06:55 |
azonenberg | current bottleneck is still deep Si etching | 06:55 |
azonenberg | i determined that i need to be able to etch with an evaporated Ni hardmask | 06:55 |
azonenberg | my last experiment failed because i couldnt evaporate it using the default configuration of the tool on campus | 06:56 |
azonenberg | because nickel sublimes rather than melting and then evaporating | 06:56 |
azonenberg | So the current TODO is designing an adapter to hold my wafer *above* the evaporatoin source instead of below it like the tool is normally used | 06:56 |
azonenberg | there's room in the bell jar if i do it right | 06:56 |
azonenberg | and i have some aluminum bar stock that should work fine at those vacuum levels | 06:57 |
azonenberg | i just have to actually find time to go down to the machine shop | 06:57 |
azonenberg | and yes, there's a lot of process development going on so i havent had much to show | 06:57 |
azonenberg | right now its tooling | 06:57 |
azonenberg | for example, i built myself a fume hood over break | 06:57 |
azonenberg | now i can work with more aggressive etchants safely | 06:57 |
azonenberg | or just larger volumes of the existing ones | 06:58 |
azonenberg | the next step is to make a nicer spin coater | 06:58 |
azonenberg | i'll be blogging on those shortly | 06:58 |
azonenberg | i also did some work on high aspect ratio etching of copper | 06:58 |
azonenberg | will be posting on that as soon as i get SEM cross section images of the sample | 06:58 |
azonenberg | when *that* happens is TBD | 06:58 |
azonenberg | of course | 06:59 |
azonenberg | anyway so did you see the pencil image i linked a minute or two ago? | 06:59 |
azonenberg | that's part of a device i am hoping to have done by weds | 06:59 |
azonenberg | it's a clock glitch generator for an in-class demo | 07:00 |
azonenberg | i want to be able to generate a ~5 MHz clock signal | 07:00 |
azonenberg | with one pulse (at a precise position in the train) a lot shorter | 07:00 |
azonenberg | but always the same length, and at the same offset | 07:00 |
azonenberg | so the thinking is to make a tapped ring oscillator much like the delay-locked loop in a DCM | 07:00 |
azonenberg | except the tap position is user controlled rather than being based on detecting phase shifts | 07:01 |
azonenberg | so i can hold it at tap 15 for a while, then suddenly jump to tap 3 | 07:01 |
azonenberg | and the period of the signal suddenly gets longer | 07:01 |
azonenberg | the hard part will be glitch-free shifting of frequencies | 07:02 |
azonenberg | so i can jump straight from Fa to Fb with no unwanted pulses of different lengths | 07:02 |
azonenberg | lol | 07:05 |
azonenberg | i'm the TA for a class on cryptography at my school | 07:05 |
azonenberg | we're talking about hardware vulnerabilities and fault attacks | 07:06 |
azonenberg | how flaws in the physical implementation can make a strong algorithm like AES or RSA fail | 07:06 |
azonenberg | so i'm gonna try and put together a nice demo | 07:06 |
azonenberg | run a stripped down RSA on a little 8-bit microcontroller or something | 07:06 |
azonenberg | clocked by my gadget | 07:06 |
azonenberg | and demonstrate how we can cause single-bit errors by giving it a glitchy clock | 07:06 |
wolfspraul | azonenberg: colossus.cs.rpi.edu/pictures are all your pictures? | 07:30 |
azonenberg | Thats a raw dump of every photo i've taken since 2004 | 07:30 |
azonenberg | except for a tiny fraction that i didnt want public for one reason or other | 07:31 |
azonenberg | I've never officially set licenses on them since the server is mostly there for me to show people specific pics without the hassle of uploading it on demand | 07:32 |
azonenberg | i'd probably be willing to share almost all under cc-by-nc or similar | 07:32 |
azonenberg | I'd have to decide on an exact license depending on the pic | 07:32 |
azonenberg | if its stuff of my lab work, then cc-by or cc-by-sa would be fine | 07:33 |
azonenberg | but if you're talking, say, my nature photos i might want -nc on those | 07:33 |
azonenberg | Ok, how about this | 07:34 |
azonenberg | any pics of gadgets i've built or lab stuff are cc-by | 07:34 |
azonenberg | anything else, ask | 07:34 |
azonenberg | i'm not opposed to sharing, understand | 07:34 |
azonenberg | but the archive is something like 30,000 pics and its hard to make a blanket statmeent :p | 07:35 |
azonenberg | Agreed | 07:35 |
azonenberg | It really boils down to two things | 07:35 |
azonenberg | I want to be credited when my work is used | 07:35 |
azonenberg | And i would like, but do not mandate, for people to drop me a line and say what it's being used for | 07:36 |
azonenberg | i understand thats far too complex to put in a license, nearly impossible to enforce, and sometimes too restrictive | 07:36 |
azonenberg | which is why i dont mandate it | 07:36 |
azonenberg | The only time i would do -nd is if i had a very specific reason not to have the image modified | 07:37 |
azonenberg | like, say, an identifiable person or event | 07:37 |
azonenberg | Yep | 07:37 |
azonenberg | Yeah, again thats just when i'd consider it | 07:38 |
azonenberg | realistically, i dont expect to profit off any of my photography | 07:38 |
azonenberg | and i dont want to limit what other people can do with it, within reason | 07:38 |
azonenberg | lol | 07:38 |
azonenberg | just out of curiosity, which pics in particular were you thinking of using and for what? | 07:39 |
azonenberg | I like to have some idea of what my work is being used for :) | 07:39 |
azonenberg | if nothing else it gives me a hint as to what would be most useful to others if i did more of it | 07:39 |
azonenberg | Yeah | 07:40 |
azonenberg | well i probably have a lot of that | 07:40 |
azonenberg | all of Silicon Exposed is intended to be breaking down barriers as to what's assumed possible for hobbyists | 07:40 |
azonenberg | including but certainly not limited to ic fab | 07:40 |
lekernel | azonenberg: you should combine lava with the bitstream reverse engineering work at recobus.de / debit | 19:42 |
kristianpaul | gpl violations in asic will be fun, we'll need azonenberg skills :) | 19:15 |
---|
azonenberg | want to build an osre lbuejust codingc0dking dev/breakout boardsBut when i write code i d | 06:22 |
---|
azonenberg | Hi guys | 05:38 |
---|---|---|
azonenberg | Trying to apply a constraint to a verilog module created in a generate block | 05:38 |
azonenberg | cant figure out the syntax | 05:38 |
azonenberg | http://pastebin.com/rut5t8Zn | 05:38 |
azonenberg | each Mux16to1_raw fits in a single slice | 05:38 |
azonenberg | Lol, am I crazy or what? http://i.imgur.com/lbfjz.jpg | 08:47 |
---|---|---|
azonenberg | Wet DRIE | 08:47 |
azonenberg | my adaptation of the bosch process for high aspect ratio structures in copper | 08:47 |
wpwrak | azonenberg: interesting .. you mix peroxide with hcl 6:1. the ratio i usually see recommended is 2:1 (that's also what i use) | 22:06 |
azonenberg | wpwrak: I haven't experimented too much yet, characterixzing etch rates was one of my TODOs for logner term | 22:07 |
azonenberg | that's the mix used in the RCA clean | 22:07 |
azonenberg | approximately | 22:07 |
azonenberg | they use i think 1:1:7 conc HCl : 30% peroxide : water | 22:07 |
azonenberg | but the proportions are as close as i could get with 3% peroxide | 22:07 |
azonenberg | and for cleaning silicon wafers | 22:07 |
azonenberg | Characterization of optimal concentrations was one of my TODOs for this winter | 22:08 |
azonenberg | Well it's used for cleaning, not pattterning | 22:08 |
azonenberg | it's entirely possible a different concentration is better for a patterning etch | 22:08 |
azonenberg | i use 1:5 or thereabouts (excess of HCl) for chromium | 22:08 |
azonenberg | The second round had to coat the sidewalls | 22:09 |
azonenberg | oh, wait a second | 22:09 |
azonenberg | you're talking the BGA or the high aspect ratio treches? | 22:09 |
azonenberg | trenches* | 22:09 |
azonenberg | for the BGA, i could have | 22:09 |
azonenberg | except i exposed it to light during the etch | 22:09 |
azonenberg | it was simpler to re-coat | 22:09 |
azonenberg | if i didn't have more resist on hand i would have made it work | 22:09 |
azonenberg | also possible | 22:11 |
azonenberg | But this way, i can recoat if i have a bad alignment or something | 22:11 |
azonenberg | I also wanted to test a multi-etch process that i later used in http://i.imgur.com/KwST0.jpg | 22:11 |
azonenberg | which was my adaptation of the Bosch DRIE process to a wet etch | 22:11 |
azonenberg | That's ~50um half-pitch trenches | 22:13 |
azonenberg | etched into copper seen from a glancing angle | 22:13 |
azonenberg | using my experimental method for getting more vertical sidewalls than were possible with a conventional wet etch | 22:13 |
kristianpaul | azonenberg: how do you planed to solder the eeprom? | 23:04 |
azonenberg | Reflow | 23:04 |
azonenberg | align by hand, then shove in an oven | 23:04 |
azonenberg | So i'm looking at a bit of code for XC6SLX45 that's failing timing | 01:37 |
---|---|---|
azonenberg | in planahead it looks to be ff -> lut -> ff | 01:37 |
azonenberg | in the path report i see 2.25ns of delay in a FD | 01:37 |
azonenberg | how does that make sense? | 01:37 |
sb0 | azonenberg, use fpga editor to get a lower level view | 10:32 |
azonenberg | sb0: Good one, i'll have to try that | 15:34 |
azonenberg | In planahead everything looked fine | 15:34 |
azonenberg | the strange thign is, it shows up in the analysis as logic delay and not routing | 15:35 |
azonenberg | in planahead | 15:36 |
azonenberg | But in the ISE timing nalysis tool there are a couple of additional LUTs that i dont see in planahead... wtf | 15:36 |
azonenberg | and in that case it shows up mostly as routing delay... which still leaves me needing to add another FF level to this pipeline in order to make timing | 15:37 |
azonenberg | r events | 01:28 |
---|
Action: azonenberg actually thinks V*HDL suck too | 14:44 | |
azonenberg | They dont allow enough programmer-guided optimization | 14:44 |
---|---|---|
azonenberg | for example "place this next to that" | 14:44 |
azonenberg | Lava looks interesting but too hard to use | 14:44 |
wpwrak | azonenberg: couldn't placement hints be added to the existing framework ? | 15:14 |
azonenberg | No idea, i havent looked into it | 15:14 |
azonenberg | but i want to explore EDA tools in more depth | 15:14 |
azonenberg | I dont like lava as-is | 15:16 |
azonenberg | but the premise is extremely interesting | 15:16 |
azonenberg | Probably | 15:24 |
wpwrak | azonenberg: yeah. the dark side of china :) | 15:11 |
---|---|---|
azonenberg | Lol | 15:11 |
azonenberg | They have many dark sides, thats just one of 'em | 15:11 |
azonenberg | I wouldnt think anyone would counterfeit a buffer though lol | 15:11 |
azonenberg | usually i'd expect something cheap like a buffer to be sold as something more expensive like a MCU | 15:11 |
azonenberg | but what do you pass off as a buffer that's worth even less than a buffer? | 15:12 |
azonenberg | lars_: I suppose thats possible, but where do you get one? | 15:15 |
azonenberg | More likely possibility is factory scrap | 15:15 |
azonenberg | with a bad die inside | 15:15 |
azonenberg | If you have any of them left | 15:16 |
azonenberg | my microscope is hungry | 15:16 |
wpwrak | azonenberg: someone actually made an effort of faking them, believe it or not ;-) | 15:16 |
azonenberg | i'd love to see one of them naked | 15:16 |
azonenberg | whats his name on here? or is he AFK atm | 15:16 |
azonenberg | Looks like worse quality engraving and the lines arent straight | 15:20 |
azonenberg | Probably IRL its a vreg or something | 15:21 |
azonenberg | Because at 11 cents per 500 it'd be hard to fake economically unless the source material was REALLY cheap | 15:21 |
azonenberg | Where did you get the bad parts? | 15:22 |
azonenberg | lol | 15:23 |
azonenberg | Lol, probably a cheap stencil | 15:36 |
azonenberg | was it painted on or laser engraved? | 15:36 |
azonenberg | Not that lasers are very expensive | 15:36 |
azonenberg | lol | 15:38 |
azonenberg | lekernel: Just out of curiosity (not that i'd do it, or have heard of anyone doing it) | 14:39 |
---|---|---|
azonenberg | But is it possible to GPL a patent? | 14:39 |
azonenberg | iow, you invent some technology | 14:39 |
azonenberg | You patent it | 14:39 |
azonenberg | And then you issue an open license to all GPL'd projects | 14:40 |
azonenberg | but a non-GPL'd project can't legally use it without licensing | 14:40 |
azonenberg | basically a copyleft patent | 14:40 |
azonenberg | The intetn would be to prevent proprietary software from implementing your idea | 14:41 |
azonenberg | so only free software is compatible | 14:41 |
azonenberg | I am not recommending it, just curious from a legal perspective if you guys think its even possible | 14:42 |
azonenberg | Basically ,the same way GPL means only GPL'd projects can use your *code* | 14:43 |
azonenberg | can you do the same thing with an idea | 14:43 |
azonenberg | nobody can implement your algorithm unless they GPL the code | 14:43 |
azonenberg | Again, i'm not recommending the practice | 14:43 |
azonenberg | Just wondering if it could even theoretically happen | 14:43 |
azonenberg | lars_: thats what i was thinking | 14:44 |
azonenberg | so basically you patent it, then grant an open license to any open source project | 14:44 |
azonenberg | wpwrak: How would that work? | 14:44 |
lars_ | azonenberg: you sell it | 14:45 |
azonenberg | again, i dont think it's likely to happen | 14:45 |
azonenberg | wpwrak: easy, create a shell company or foundation that exists solely to oversee the patent | 14:45 |
azonenberg | and has no assets or liabilities | 14:45 |
azonenberg | Personally i dont like copyleft | 14:46 |
azonenberg | i like permissive licenses | 14:46 |
kristianpaul | azonenberg: cc0 :) | 14:46 |
azonenberg | so rather than patenting something i'd just publish it :p | 14:46 |
kristianpaul | azonenberg: publis it certainly is a better way to avoid soemboy patent it, but of course you still need to make lot of noise | 14:47 |
wpwrak | azonenberg: a company without assets wuold be even easier to destroy ;-) | 14:47 |
azonenberg | wpwrak: how? | 14:47 |
wpwrak | azonenberg: create any upset you want ;) poof, it runs out of money. remember, you can sue anyone at any time over even the most ludicrous things | 14:48 |
azonenberg | wpwrak: maybe | 14:49 |
azonenberg | In any case i wasnt recommending the practice, or considering it feasible | 14:50 |
azonenberg | more curious if it had been tried | 14:50 |
kristianpaul | azonenberg: still a patent so same dislike a copyrighted license like gps or other has, a patent well.. follow the principles.. | 14:50 |
azonenberg | wpwrak: The only conceivable reason to do something like that | 14:51 |
azonenberg | woudl be if you want to, say, implement a file format with some novel feature in your open source project | 14:51 |
azonenberg | and prevent m$ products from ever being compatible | 14:51 |
azonenberg | while allowing open code to interoperate | 14:51 |
azonenberg | It sounds like something stallman would try if he had half the chance | 14:52 |
azonenberg | It's an offensive technique, not defensive like PDing | 14:52 |
azonenberg | kristianpaul: Personally i'd just BSD the code and to heck with anyone else | 14:53 |
azonenberg | if they implement it, i dont care | 14:53 |
azonenberg | but knowing stallman and his offensive strategies, it seems like he'd try that | 14:53 |
azonenberg | even the GPL is an offensive license | 14:53 |
azonenberg | not a defensive one | 14:53 |
azonenberg | wpwrak: The intention would be to become the dominant application in that field | 14:54 |
azonenberg | and force m$ out of the market | 14:54 |
azonenberg | because they cannot interoperate | 14:54 |
azonenberg | The hypothetical application would be an office format | 14:54 |
azonenberg | that somehow became dominant | 14:54 |
azonenberg | but couldn't be implemented by proprietary applications | 14:54 |
azonenberg | Again it seems unrealistic | 14:55 |
azonenberg | but knowing the FSF nutjobs i suspect if the opportunity ever arose they'd try something like that | 14:55 |
kristianpaul | azonenberg: for you initial question gpl is not like it is, interionally i think, i mean you need to be offensive if want to defend your position | 14:56 |
kristianpaul | azonenberg: actually if that patent you think about exist, will be somethin or even more complicated that reading the glpv3 or such :) | 14:56 |
azonenberg | kristianpaul: its offensive because it was designed by the FSF | 14:56 |
azonenberg | and stallman doesnt want to compete with proprietary software | 14:57 |
azonenberg | he wants to destroy it | 14:57 |
azonenberg | i know stallman well enough | 14:57 |
azonenberg | i've had a few f2f discussions with him about his offensive tactics | 14:57 |
azonenberg | causing splits in the community (vs *bsd etc) | 14:57 |
azonenberg | We called a halt at his stop lol | 14:58 |
azonenberg | (we were driving somewhere) | 14:58 |
azonenberg | no clear victor | 14:58 |
azonenberg | neither was able to convince the other of anything | 14:58 |
azonenberg | Not that i was surprised at atll | 14:58 |
azonenberg | I know, just saying i got the impression pretty quickly he wants to destroy proprietary software by any means possible | 14:59 |
azonenberg | while i'd rather compete with it in a free market and win because i have a superior product | 15:00 |
azonenberg | or lose, because mine is inferior, in which case they deserve to win | 15:00 |
azonenberg | in other news i think i am finally figuring out how i am going to handle the interconnect in that multicore SoC i've been designing | 15:00 |
azonenberg | i wanted something with support for DMA and out-of-order request handling which wishbone didnt seem to do | 15:01 |
azonenberg | my new design has a lot in common with infiniband | 15:01 |
azonenberg | switched fabric supporting multiple simultaneous connections | 15:01 |
azonenberg | and out of order request handling | 15:01 |
azonenberg | TCP-esque retransmission if a packet is dropped due to congestion | 15:02 |
azonenberg | my system will tentatively have 16 ports on the switch between the three CPU cores, RAM, and various high-speed peripherals like the cameras | 15:03 |
azonenberg | Sound like a reasonable design? | 15:03 |
azonenberg | roh: Good, because while my current design is 3 cores i want to do 5 in the future :p | 15:04 |
azonenberg | on an xc6slx75 | 15:04 |
azonenberg | each packet is 32 bits address and 64 of data plus a read/write flag (in read mode, data is ignored) | 15:04 |
azonenberg | times 200 MHz is 12.5 Gbps per port | 15:04 |
azonenberg | Which conveniently is exactly the bandwidth of 16 bit DDR2 800 | 15:04 |
azonenberg | hmm, i wonder if thats a coincidence :p | 15:05 |
azonenberg | Since the RAM has a whole switch port dedicated to itself | 15:05 |
azonenberg | But yeah, i basically want a switched fabric network rather than a bus | 15:05 |
azonenberg | and something that supports out of order delivery of data | 15:05 |
azonenberg | so for example if core 0 is busy talking to the camera and core 1 wants data from RAM, an outstnading core0 request from RAM should not block the core1 request | 15:06 |
azonenberg | roh: Similar, but pcie is meant for off-chip use | 15:06 |
azonenberg | multiple high-speed serial lanes | 15:06 |
azonenberg | this is an on-chip bus | 15:06 |
azonenberg | although i suppose i could potentially add future support for a serialized version that does off-chip communication | 15:06 |
azonenberg | I dont know if pcie is switched or still a bus though | 15:07 |
azonenberg | i know infiniband is | 15:07 |
azonenberg | and this bus has comparable bandwidth in this implemenataion | 15:07 |
azonenberg | DDR 4x infiniband is 16 Gbps and my bus is 12.5 (one way) | 15:08 |
azonenberg | the difference is that i'm parallel on-chip and infiniband is serial off-chip | 15:08 |
azonenberg | kristianpaul: I havent implemented the cores fully yet, most of the design is done | 15:08 |
azonenberg | I wanted to design the architecture fully first | 15:08 |
azonenberg | it's heterogeneous | 15:08 |
azonenberg | somehwat like the Cell | 15:09 |
azonenberg | one mips-like core for non-parallel code | 15:09 |
azonenberg | fast and pipelined but no FPU | 15:09 |
azonenberg | and then two highly parallel DSPs | 15:09 |
azonenberg | 2-way superscalar, 16-way barrel | 15:09 |
azonenberg | i.e. 16 hardware threads and i issue two instructions from one thread every clock | 15:10 |
azonenberg | per core | 15:10 |
azonenberg | The DSPs are a completely custom archiecture, i havent even begun the ISA yet | 15:11 |
azonenberg | been working on microarchitecture | 15:11 |
azonenberg | but it will be 64 bit VLIW with two 32-bit instruction fields | 15:11 |
azonenberg | only one of every execution unit but you can issue instructions to any two every clock | 15:12 |
azonenberg | i have the register file implemented already, it's 4 reads and two writes every clock | 15:12 |
azonenberg | all reads, and all writes, must be within the same two 16 bit windows | 15:12 |
azonenberg | 32 register* | 15:12 |
azonenberg | read and write windows need not be the same | 15:12 |
azonenberg | in fact they will usually be shifted by a bit due to pipelining | 15:12 |
azonenberg | Right now the current focus is the interconnect fabric | 15:13 |
azonenberg | once i get that designed i'm going to work on the CPUs more | 15:14 |
azonenberg | i was thinknig a shared bus and even maybe using wishbone for a while but it didnt seem like it'd play nicely with multiple cores and DMA | 15:14 |
azonenberg | and specifically request reordering | 15:14 |
azonenberg | Which is going to be a must if i want the system to scale | 15:15 |
azonenberg | wpwrak: Flight control for a UAV my school's electronics club is building | 15:23 |
azonenberg | including onboard machine vision and path planning | 15:23 |
azonenberg | i'm shooting for peak performance of 800 mflops in the dual DSP version and 1600 in the quad | 15:23 |
azonenberg | I also am considering building a laptop around a slightly modified version of the same SoC | 15:24 |
azonenberg | Since i've wanted to make a full custom laptop for a while and i think this thing will have the juice to do so | 15:25 |
azonenberg | i'd probably use the quad core model in the laptop | 15:26 |
azonenberg | lekernel: yes | 15:26 |
azonenberg | i want a full custom CPU + GPU | 15:26 |
azonenberg | and MOSIS is a little pricey | 15:26 |
azonenberg | The goal of the project would be to build a laptop starting with the RTL and going all the way up to the mobo, case, and operating system + apps | 15:27 |
wpwrak | azonenberg: oh, drones for iran. nice ;-) | 15:27 |
azonenberg | wpwrak: Lol, this one isnt going to be able to stray that far off course | 15:27 |
azonenberg | it communicates with the base station by 802.11n | 15:27 |
azonenberg | and will force-land immediately if signal is lost | 15:27 |
azonenberg | this is an indoor micro-uav | 15:27 |
azonenberg | And strictly research oriented | 15:28 |
lekernel | azonenberg: what does it need compute power for? | 15:28 |
azonenberg | lekernel: It's autonomous | 15:28 |
azonenberg | actually it uses a kinect for 3d position sensing | 15:28 |
azonenberg | my roommate already has some pretty nice algorithms done up for point cloud processing | 15:29 |
azonenberg | then yes, a kalman filter | 15:29 |
lekernel | azonenberg: do you know how the kinect works btw? | 15:29 |
azonenberg | identifying interesting targets in video feeds | 15:29 |
azonenberg | lekernel: yeah, stereo on a grid of projected IR points | 15:29 |
azonenberg | That's good enough, all it has to do is find walls and such | 15:29 |
azonenberg | we originally considered LIDAR but it was way too expensive | 15:30 |
azonenberg | kinect gave slightly less good data for much less cost | 15:30 |
azonenberg | lol, homebrewing would be nice | 15:30 |
azonenberg | but is beyond our time budget | 15:30 |
azonenberg | the main difficult part of hte project is the flight planning algorithms | 15:30 |
azonenberg | lekernel: 2D? | 15:30 |
azonenberg | i'm pretty sure its only 1 | 15:31 |
azonenberg | remember this is a UAV, we're working in 3-space here | 15:31 |
azonenberg | I'm not on that team anyway | 15:31 |
azonenberg | i'm doing the SoC | 15:31 |
azonenberg | including the DSP and various support stuff like the camera controller | 15:31 |
azonenberg | and hardware JPEG compression unit | 15:31 |
azonenberg | oh, and a hardware driver for the kinect including associated usb stuff | 15:32 |
azonenberg | Better position sensing would be nice, but the data we got off the kinect looked adequate | 15:33 |
azonenberg | again, all it's needed for is seeing whether we're headed for a door or a wall | 15:33 |
azonenberg | and registering that data with our existing data to build a map | 15:33 |
azonenberg | i do agree that lidars are way more expensive than they need to be | 15:35 |
azonenberg | same thing with, say, semiconductor fab equipment | 15:35 |
azonenberg | but i dont have time to reinvent EVERYTHING ;) | 15:35 |
azonenberg | Put on hold for exams, just finishing up | 15:36 |
azonenberg | The choice to use a kinect wasnt mine | 15:36 |
azonenberg | it was the flight control team | 15:36 |
azonenberg | we have like 15 people on the project now | 15:36 |
azonenberg | Re fab, i have some very interesting ideas | 15:37 |
azonenberg | The first is fooling around with packaging, i want to try making a FCBGA | 15:37 |
azonenberg | just with some simple wiring patterns, no active compnents | 15:37 |
azonenberg | to test if i can actually package chips i make | 15:37 |
azonenberg | second is lithography related | 15:37 |
azonenberg | i want to build a fairly complex mask with a lot of differnet designs on it | 15:38 |
azonenberg | send it out to laserlab to be fabbed | 15:38 |
azonenberg | they'll give me a 10x16 inch piece of film at 8000DPI which equals 12.5um design rules and 3.175um lambda | 15:38 |
azonenberg | which comes out to quite a few 2" contact masks and 2cm projection masks | 15:38 |
azonenberg | i should be able to easily hit single-micron design rules with optical reduction of a 12.5 or 25um mask | 15:39 |
azonenberg | The optics say that i can even hit 350nm | 15:39 |
azonenberg | not sure if my dust / photoresist / developer / etch combination will let me go quite that far | 15:39 |
azonenberg | 500 to 750 might be reachable | 15:40 |
azonenberg | At that point i could start thinking pretty seriously about transistor fab | 15:41 |
azonenberg | kristianpaul: the SoC? No lol | 15:41 |
azonenberg | that was a 50k gate chip | 15:41 |
azonenberg | i'm using the XC6SLX45 | 15:41 |
azonenberg | Current estimates say i can fit the tri-core version there | 15:42 |
azonenberg | and the quad in the -75 | 15:42 |
azonenberg | the 5-core* | 15:42 |
azonenberg | Right now i'm using the Atlys dev board | 15:42 |
azonenberg | i expect to do my own in the future | 15:42 |
azonenberg | one of the things i've been working on on the side is developing a BGA soldering process | 15:42 |
azonenberg | i cant handle csg324 due to the 0.8mm pitch but fgg484 or ftg256 should be doable on affordable design rules (6 mil trace/space, 4 layers, no filled vias, no blind/buried vias) | 15:43 |
azonenberg | maybe 6 layers depending on how thigns go | 15:43 |
azonenberg | kristianpaul: the UAV or the laptop? | 15:45 |
azonenberg | The laptop is just me and a lower priority project | 15:45 |
azonenberg | i'm quite handy with a milling machine tyvm | 15:45 |
azonenberg | The laptop is just me | 15:49 |
azonenberg | my plan for the case is TiG welded 1/4" aluminum plate | 15:49 |
azonenberg | The UAV may use the atlys or a custom board | 15:49 |
azonenberg | we're not sure yet | 15:49 |
azonenberg | I havent though that far haead | 15:49 |
azonenberg | most likely going to be built around a pair of 5 Ah 11.2v li-po packs | 15:50 |
lekernel | azonenberg: what's so special about the atlys btw? everyone's using that | 15:57 |
azonenberg | lekernel: Cheap :p | 15:57 |
azonenberg | 199 | 15:58 |
azonenberg | for educational | 15:58 |
azonenberg | it was the only spartan6 board i saw that had a decently large fpga (lx45), a decent amount of memory (128MB), and a decent selection of peripherals | 15:58 |
azonenberg | they have an 8051 based adapter built in but i use the xilinx platform cable | 16:03 |
azonenberg | which runs fine on my debian and ubuntu system after i installed an open source driver | 16:03 |
azonenberg | lekernel: yes | 16:17 |
azonenberg | i want to build my own programmer at some point | 16:17 |
azonenberg | much cheaper, probably based on PIC32 and a small CPLD or FPGA | 16:17 |
azonenberg | target price point $50 or less | 16:17 |
azonenberg | will include a 12V Vpp generator | 16:17 |
azonenberg | and should be able to do xilinx JTAG, atmel in-circuit programming, and microchip ICSP | 16:18 |
azonenberg | if not more | 16:18 |
azonenberg | cross platform libusb based command line interface | 16:18 |
azonenberg | and lol | 16:18 |
azonenberg | i just wrote libjpeg instead of libus... | 16:18 |
azonenberg | lekernel: bus pirates lack Vpp generators | 16:29 |
azonenberg | and most PICs still need high voltage on MCLR# | 16:29 |
azonenberg | even if the real Vpp is charge-pumped onboard | 16:29 |
azonenberg | they use it as a "time to program" indicator | 16:29 |
kristianpaul | azonenberg: there is a expansion boar for vpp tought i havent bouht it yet.. | 16:31 |
azonenberg | wpwrak: low voltage programmable, yes, but i think you have to set LVP in the config bits | 16:51 |
azonenberg | they need HV the first time out of the box | 16:51 |
azonenberg | unless i'm mistaken | 16:51 |
azonenberg | the project is still a long-term todo, i havent really read the programming specs etc yet | 16:52 |
azonenberg | Hmm, interesting | 16:52 |
azonenberg | i'll have to check that | 16:52 |
azonenberg | i've always used default settings which i think is high Vpp | 16:53 |
azonenberg | on the low-pin-count parts, yes | 16:54 |
azonenberg | but not the ones with 64 or 100 pins | 16:55 |
azonenberg | proprortionally, i mean | 16:55 |
azonenberg | i think LVP uses one extra pin on the programmer, which i've never hooked up in any of my circuits | 16:55 |
azonenberg | wpwrak: i've never used a lot of the cheap 8-bit ones | 16:57 |
azonenberg | most of what i've used lately is pic32s | 16:57 |
azonenberg | which are completely different | 16:57 |
azonenberg | the ICSP is just JTAG muxed onto less pins | 16:57 |
azonenberg | And the core *is* something decent | 16:57 |
azonenberg | mips m4k | 16:57 |
azonenberg | NUMA AVRs? Lol | 18:40 |
azonenberg | Reminds me of the time i was thinking of building a PIC32 cluster | 18:40 |
azonenberg | nice little blade maybe 1:10 scale of a 2U rack case | 18:41 |
azonenberg | make a little model rack | 18:41 |
barbu-uucp | azonenberg: you might like this http://raintown.org/lava/ | 11:02 |
---|---|---|
azonenberg | "These pages assume a good understanding of Xilinx's Virtex FPGA architecture and of the Haskell lazy functional programming language. The number of people that know about both can easily fit inside a medium sized elevator" | 11:03 |
azonenberg | Looks interesting but i question whether it's too complex to be of any use lol | 11:06 |
azonenberg | I understand what they're doing | 11:08 |
azonenberg | i just think that often you dont care about placement | 11:08 |
azonenberg | But OTOH, mixing that with verilog or vhdl | 11:08 |
azonenberg | for the most speed critical parts of the circuit | 11:08 |
azonenberg | Might well be worth doing | 11:08 |
azonenberg | HmmI definitely want to play with it, thats for sure | 11:09 |
azonenberg | Is there a back end for spartan chips? | 11:09 |
azonenberg | yeah | 11:10 |
azonenberg | Well, i am definitely going to fool around with it though | 11:10 |
azonenberg | As well as manually doing low level (LUT and CLB based) FPGA dev at some point | 11:11 |
azonenberg | I intend to learn the architecture inside out | 11:11 |
barbu-uucp | azonenberg: you can also try to combine Lava with a DIY router (not too hard to do using the XDL descriptions) and the Recobus bitstream generator | 11:11 |
azonenberg | lol | 11:12 |
azonenberg | I do want a free toolhain | 11:12 |
azonenberg | And one optimized for extreme performance wouldn't hurt | 11:12 |
azonenberg | Something to look into when i have free time, perhaps | 11:12 |
azonenberg | But I have a doctoral thesis in *computer science* to finish first | 11:13 |
azonenberg | Maybe then i can think about doing one in EE :p | 11:13 |
azonenberg | No idea, i havent used lm32 | 11:15 |
azonenberg | I'm actually writing my own softcore optimized for my specific workloads | 11:15 |
azonenberg | 2-way superscalar barrel processor | 11:16 |
azonenberg | 16 threads, it issues two instructions from each one in a round-robin fashion | 11:16 |
azonenberg | then goes back and issues two from the first thread again etc | 11:16 |
azonenberg | that allows a 16-stage pipeline with no stalls | 11:16 |
azonenberg | in reality some of the FPU is 32 stages so i need to have one delay slot in which you can't use the output of the fdiv/fsqrt or it'll stall | 11:17 |
azonenberg | lol | 11:17 |
azonenberg | I havent even started to think about the OS i'd run on this guy | 11:17 |
azonenberg | But it'd have to be hardware multithreading aware | 11:17 |
azonenberg | My roommate says that lava looks like the C of HDLs | 11:23 |
azonenberg | as in, getting close to the architecture for maximum performance | 11:24 |
azonenberg | while still maintaining some level of abstraction for ease of development | 11:24 |
azonenberg | wpwrak: what i was saying earlier today | 09:24 |
---|---|---|
azonenberg | was that it passes timing | 09:24 |
azonenberg | faster than the numbers the datasheet says it should | 09:24 |
azonenberg | i havent yet tested to see if it actually works | 09:24 |
azonenberg | lekernel: So apparently my really fast adder is pointless | 09:25 |
azonenberg | BUFGs, according to the datasheet, top out at 400 MHz | 09:25 |
azonenberg | and i'm pretty sure the normal xilinx 32-bit adder still works at that speed | 09:25 |
azonenberg | But somehow my design passes timing at 500 | 09:26 |
azonenberg | so either trce doesnt check component switching limits on PLLs and BUFGs | 09:26 |
azonenberg | or i'm misreading something | 09:26 |
lekernel | azonenberg: you can route clocks without BUFGs, only you'll get a lot of skew *g* | 09:30 |
azonenberg | lekernel: lol | 09:30 |
azonenberg | Not an option :p | 09:30 |
azonenberg | I mean even 400 would be nice | 09:31 |
azonenberg | Lol | 09:32 |
azonenberg | lekernel: I also have to be able to fill the entire device with a working design | 09:32 |
wpwrak | azonenberg: if you can try to make it run at way out of whack speeds, perhaps you can find out if that speed limit is being checked ? it wouldn't be uncommon for a data sheet to give you a pessimistic estimate, and the real device still performing well under worse conditions | 09:35 |
azonenberg | wpwrak: What i mean is, there are two differnet specs | 09:38 |
azonenberg | timing analysis and the datasheet disagree | 09:38 |
azonenberg | so 500 is either barely within spec or 20% out of spec | 09:38 |
azonenberg | and i have no idea how far i'm pushing it | 09:38 |
azonenberg | this is for a relatively accuracy-critical application so i dont want somethign that will misbehave if it gets warm etc | 09:39 |
azonenberg | also... | 09:39 |
azonenberg | how much do you guys know about spartan6 IO clocks? | 09:39 |
azonenberg | Can you drive LUT logic with them? | 09:39 |
wpwrak | azonenberg: i guess you;ll have to ask xilinx on how to interpret those limits. could be that they don't really expect people to read the data sheets and the tools are designed to enforce the real limits. but then, maybe not. | 09:43 |
azonenberg | Well, in any case once exams are over i will be testing on the real chip | 09:43 |
azonenberg | Of course, i have a problem there too | 09:44 |
azonenberg | there is a heatsink on my board | 09:44 |
azonenberg | i cant see if the chip is a -2 or a -3 :p | 09:44 |
azonenberg | the datasheet is unclear | 09:44 |
azonenberg | Hmm | 23:14 |
---|---|---|
azonenberg | The datasheet and timing analysis disagree | 23:14 |
azonenberg | as to the high end of the BUFG clock range | 23:14 |
azonenberg | I'm creating a PoC design (just a single LUT and a flipflop configured as a divide-by-two) that I want to clock as fast as I can | 23:14 |
azonenberg | using a 100 Mhz input clock multiplied up by a PLL_ADV | 23:14 |
azonenberg | The datasheet seems to suggest the global clock network runs up to 400 Mhz | 23:15 |
azonenberg | But my design passes timing at a 5x multiplier | 23:15 |
azonenberg | Any guesses as to which one to believe and how ot test this for sure? | 23:15 |
azonenberg | lekernel_: Any experience working with multiprocessor softcores? | 09:37 |
---|---|---|
azonenberg | I'm particularly interested in the interconnect | 09:38 |
azonenberg | in terms of cache coherency and how multiple processors share the bus | 09:39 |
azonenberg | i'm working on a triple-core SoC from scratch | 09:39 |
azonenberg | and am designing the interconnect fabric now | 09:39 |
azonenberg | i'm using a shared bus (only one core can talk at a time, but it's full duplex) | 09:39 |
azonenberg | A fixed-mapping MMU | 09:40 |
azonenberg | That splits the address bus between memory mapped IO and DDR2 | 09:40 |
azonenberg | the DDR2 has an L2 cache in front of it | 09:40 |
azonenberg | each core has its own dedicated L1 | 09:40 |
azonenberg | Basically, yes | 09:41 |
azonenberg | hardwired mapping | 09:41 |
azonenberg | The L1 is gonig to be structured in such a way as to be a passthrough for the IO address range and cache DRAM and flash addresses | 09:41 |
azonenberg | then DRAM and flash will have their own SoC-wide L2 caches | 09:41 |
azonenberg | I know i'm reinventing the wheel a bit, its mostly an educational exercise | 09:42 |
Action: azonenberg is writing a dissertation on computer architecture soon and wants to sharpen his skills first | 09:42 | |
azonenberg | But its actually going to be quite fast | 09:42 |
azonenberg | on spartan6 -2 speed i am shooting for 200 MHz | 09:42 |
azonenberg | * 2-way superscalar | 09:43 |
azonenberg | = 800 mflops for 2 cores | 09:43 |
azonenberg | I had to pipeline the heck out of it, but its looking feasible | 09:44 |
azonenberg | Actually, the bus arbiter is looking just fine | 09:46 |
azonenberg | i just did a standalone test of it at 200 mhz and it works just fine | 09:46 |
azonenberg | on hardware | 09:46 |
azonenberg | My solution to this thing is, pipeline it like crazy | 09:47 |
azonenberg | its a barrel processor | 09:47 |
azonenberg | so a 16 stage pipeline means zero latency | 09:47 |
azonenberg | and 32 stages means one stall | 09:47 |
azonenberg | i run 16 threads and context switch every clock | 09:47 |
azonenberg | Right now its looking like when running out of L1 cache with a 16 stage pipeline i will have no stalls | 09:47 |
azonenberg | despite not having any forwarding whatsoever | 09:47 |
azonenberg | an L1 cache miss that hits in L2 will most likely stall one instruction | 09:47 |
azonenberg | if i can fit the L1=>L2 and back in 16 clocks | 09:48 |
azonenberg | or 2 instructions if it takes me 32 | 09:48 |
azonenberg | as long as i can keep the entire bus structure pipelined | 09:48 |
azonenberg | this is a very GPU-esque architecture | 09:48 |
azonenberg | hiding latency by multithreading | 09:48 |
azonenberg | I envision it being something like CUDA, each thread executing mostly the same instructions | 09:48 |
azonenberg | But they can branch as they see fit' | 09:48 |
azonenberg | The entire architecture is mostly an experiment | 09:49 |
azonenberg | you mean, ASIC level? | 09:49 |
azonenberg | Sure, go get me $30K and i'll get it fabbed in MOSIS :p | 09:49 |
azonenberg | and no, this is mostly an educational exercise | 09:49 |
azonenberg | The goal is to see how many flops i can pull out of a softcore CPU | 09:49 |
azonenberg | running real code | 09:50 |
azonenberg | also i have a project in mind that will involve me working with non-hardware people | 09:50 |
azonenberg | I have dedicated accelerators for stuff like JPEG encoding that i'm working on | 09:50 |
azonenberg | But the flight control code has to be in C | 09:50 |
azonenberg | or C++ | 09:50 |
azonenberg | or assembly | 09:50 |
azonenberg | since i am working with CS people who dont knowh hardware | 09:51 |
azonenberg | So i want to design a nice powerful architecture for them to run it on | 09:51 |
azonenberg | the other motivation as i said is just cutting my teeth on computer architecture | 09:51 |
azonenberg | this is not something i envision being a softcore forever, but custom ASICs are not cheap | 09:51 |
azonenberg | if things go well and it works as planned i might try sending it out to mosis eventually | 09:52 |
azonenberg | i would love to have a laptop running a CPU i designed | 09:52 |
azonenberg | in 180nm TSMC or something | 09:52 |
azonenberg | But i'm not that advanced yet :p | 09:52 |
azonenberg | I read your post about the latticemico32 synthesis lol | 09:53 |
azonenberg | and i think my processor will be faster | 09:53 |
azonenberg | But i'd have to reimplement some of the xilinx hard IP cores like the memory controller | 09:54 |
azonenberg | and their soft FPU | 09:54 |
azonenberg | I'm pretty sure i can write a better FPU but i havent gotten around to it yet, and as long as it's interface-compatible with theirs it'd be a drop-in replacement | 09:54 |
azonenberg | Yes, for now | 09:56 |
azonenberg | i wanted to focus on the datapath and interconnect first | 09:56 |
azonenberg | then go and write myself an FPU when i had all of the surrounding stuff done | 09:56 |
azonenberg | in the meantime i have theirs because it tells me an FPU of that size and speed is possible | 09:56 |
azonenberg | iow, setting a lower bound | 09:56 |
azonenberg | then i can try and outperform it with an open one | 09:56 |
azonenberg | Coregen lets you generate floating point add/sub, multiply, divide, and sqrt units separately | 09:57 |
azonenberg | So i'll replace them with my own one by one | 09:57 |
azonenberg | But again the focus for now is on the datapath and microarchitecture more than implementation | 09:58 |
azonenberg | The goal here is to practice efficient pipelined architecture | 10:00 |
azonenberg | So i want to use as little premade code as possible | 10:00 |
azonenberg | like i said i'm doing a thesis on computer architecture soon and i want practice | 10:00 |
azonenberg | Temporarily, so i could build the other stuff around them | 10:01 |
azonenberg | its not expected to stay | 10:01 |
azonenberg | if i had used a free one i'd have less incentive to replace it :p | 10:01 |
azonenberg | production project? Sure | 10:04 |
azonenberg | But for educational value sometimes its better to reimplement | 10:04 |
azonenberg | Once i build mine, i'll compare it to yours and any other open ones i find | 10:05 |
azonenberg | and use the best one in real projects | 10:05 |
kristianpaul | and now image this laser tech to micro umeter scale like azonenberg work :) | 03:41 |
---|---|---|
azonenberg | kristianpaul: if someone gets a device for under $2K that can do 365-405nm direct write at <50um resolution, i'm interested | 03:42 |
azonenberg | i dont need a lot of power, this is for photolithography and not ablation | 03:42 |
roh | azonenberg: i dont really know your setup.. is it documented somewhere? | 03:43 |
azonenberg | homecmos.googlecode.com has some info | 03:43 |
azonenberg | mainly i'm interested in mask fab | 03:43 |
azonenberg | evaporate or sputter metal over a piece of glass | 03:43 |
azonenberg | spin coat in photoresist | 03:43 |
azonenberg | then draw my pattern at 1:1 scale into the photoresist with a laser | 03:43 |
azonenberg | develop and etch the metal, then strip resist | 03:44 |
wpwrak | azonenberg: we still haven't explored that direct bluray writer idea :) | 03:44 |
azonenberg | wpwrak: i know | 03:45 |
azonenberg | bluray has the power and then some | 03:45 |
azonenberg | it's just focusing and aiming | 03:45 |
azonenberg | its a lot | 03:48 |
azonenberg | i'd be firing it in short pulses | 03:48 |
azonenberg | like 10-100ns | 03:48 |
azonenberg | then moving the beam and firing another shot | 03:48 |
wolfspraul | azonenberg: do you know marcan and OpenLase? | 03:48 |
azonenberg | Negative | 03:49 |
azonenberg | Lol | 03:49 |
azonenberg | Well, what I *really* want to do is skip the laser entirely and do e-beam :p | 03:49 |
azonenberg | But thats a little... smaller | 03:49 |
azonenberg | or EUV :P | 03:50 |
azonenberg | i say EUV because even the real semiconductor industry cant get it working :p | 03:50 |
azonenberg | lol | 03:51 |
azonenberg | I need a SEM first | 03:51 |
azonenberg | scanning electron microscope | 03:54 |
azonenberg | lol | 03:54 |
azonenberg | wpwrak: no bribes, everything is above board | 03:56 |
roh | azonenberg: wish for a FIB workstation eh? | 03:56 |
azonenberg | roh: A SEM is actually on the feasible list | 03:57 |
azonenberg | while i'd love one of these, i dont expect to be able to get it any time soon http://www.semtechsolutions.com/node/138/zeiss-neon-40-esb-crossbeam | 03:57 |
azonenberg | My school has one in the cleanroom that cost $1.3M new | 03:58 |
azonenberg | consensus among a few friends is that used in good condition it'd probably sell for $500K ish | 03:58 |
azonenberg | On the other hand the JSM-840 they sell on the same site is probably in the low five figures | 03:59 |
azonenberg | about the price of a decent car | 03:59 |
azonenberg | Which is entirely affordable for someone with a PhD making >$100K a year, as i hope to be by 2016ish | 03:59 |
azonenberg | But i'm not going to spend five years' pay on one piece of equipment :p | 04:00 |
azonenberg | roh: yeah | 05:16 |
azonenberg | I am hoping to bring IC fab to that level | 05:16 |
azonenberg | though its still a ways out | 05:17 |
lekernel | mwalle: http://lekernel.net/re.jpg (from azonenberg :) | 20:53 |
---|---|---|
azonenberg | lekernel: lol, glad to see you like it | 20:53 |
azonenberg | lol | 21:00 |
azonenberg | Have you guys used the xilinx MIG / MCB? | 02:57 |
---|---|---|
azonenberg | I'm trying to get an XC6SLX45 talking to DDR2 | 02:58 |
azonenberg | So you are using raw GPIO pins and doing all of the DDR logic in CLBs? | 02:58 |
azonenberg | Because right now i am fighting with the MIG and its not playing well | 02:59 |
azonenberg | lol | 02:59 |
azonenberg | The issue i'm seeing - i wont call it a bug as its more likely me not understanding what i'm doing | 02:59 |
azonenberg | is that i am feeding a 200 MHz clock into the module, which is doubled to 400 | 03:00 |
azonenberg | and their own MIG internal code | 03:00 |
azonenberg | is failing timing | 03:00 |
azonenberg | if i cut the clock to below 200 the PLL complains "input clock too slow" | 03:00 |
azonenberg | lol | 03:00 |
azonenberg | I assume you guys' ddr controller is GPLed? | 03:01 |
azonenberg | :( | 03:01 |
azonenberg | My project is BSD licensed | 03:01 |
azonenberg | i cant use it | 03:01 |
azonenberg | I have no objections with a dual license etc but i want to keep my project under a permissive license | 03:02 |
azonenberg | i'm still researching options now but i cant even get a simple demo design using the MCB to compile | 03:02 |
azonenberg | This project is actually unrelated to homecmos, it's an open source softcore CPU designed for heavy number crunching | 03:03 |
azonenberg | target is 200 MHz on a s6 -2, not sure if i can hit that | 03:03 |
azonenberg | 4-way SIMD floating point | 03:03 |
azonenberg | using xilinx FPU cores initially and then gradually replacing with opencores etc | 03:04 |
azonenberg | MIPS 1 instruction set (all patents expired) but a completley new microarchitecture | 03:04 |
azonenberg | All of the mips 1 patents are | 03:04 |
azonenberg | mips 1 came out >17 yrs ago | 03:04 |
azonenberg | i havent looked at more recent arch versions | 03:04 |
azonenberg | Loongson omitted unaligned load/stores | 03:05 |
azonenberg | due to a patent that expired around three years ago | 03:05 |
azonenberg | All i can say is, i did some pretty exhaustive reading and it looks like mips1 is as unencumbered as 8051 | 03:05 |
azonenberg | newer versions, definitely not so | 03:06 |
azonenberg | I have no plans to make money :p | 03:06 |
azonenberg | its for me to get practice in FPGA stuff, and will be used in one noncommercial research project (single unit run size) | 03:06 |
azonenberg | But again, i dont see how patents could still be covering any part of the *instruction set* | 03:07 |
azonenberg | of mips 1 | 03:07 |
azonenberg | considering that i am completely reimplementing the microarchitecture | 03:07 |
azonenberg | as in, i'm not even using their pipeline design | 03:07 |
azonenberg | Also, i dont know if loongson is paying | 03:08 |
azonenberg | They bought a mips license specifically so they can promote it as mips compatible | 03:09 |
azonenberg | then two years later they licensed the whole architecture and started implementing mips32 | 03:09 |
azonenberg | i have no plans to implement anything past mips1 | 03:09 |
azonenberg | wolfspraul: But an open project cannot pay patent license fees | 03:11 |
azonenberg | Look at http://jonahprobell.com/lexra.html though | 03:12 |
kristianpaul | azonenberg: i guess just skip first talking about MIPS if you already re-write the whole thing? | 03:12 |
azonenberg | Lexra implemented mips 1 without unaligned loads and stores | 03:12 |
azonenberg | Got sued for trademark infringement | 03:12 |
azonenberg | Yes | 03:13 |
azonenberg | and settled by agreeing not to use mips trademarks without attribution and a few other little things | 03:13 |
azonenberg | Which basically means, if i happen to use their ISA | 03:13 |
azonenberg | Without using any patented instructions | 03:13 |
azonenberg | And dont use their trademarks anywhere | 03:13 |
azonenberg | then it's clean | 03:13 |
azonenberg | "After its experience with Lexra MIPS Technologies changed all of its 32-bit cores to use its new MIPS32 instruction set which extends the MIPS-I instruction set to include other features patented by MIPS Technologies. This is similar to Intel's addition of the instruction set extensions to Pentium III in order to prevent AMD from building compatible processors. " | 03:14 |
azonenberg | So basically, dont use any >mips1 instructions | 03:14 |
azonenberg | Then i'd go after someone who actually had money to take | 03:15 |
azonenberg | Probably not | 03:16 |
azonenberg | The way i see it is, courts have already ruled on this matter | 03:16 |
azonenberg | mips1 patents were those four instructions, that one patent | 03:16 |
wpwrak | azonenberg: they may also consider that a project that gets away may erode their ability to milk others | 03:16 |
azonenberg | Which expired four or five years ago | 03:16 |
azonenberg | Use their trademarks, you're in trouble | 03:17 |
azonenberg | Otherwise it looks like they have no basis | 03:17 |
azonenberg | Loongson was for quite a while | 03:17 |
azonenberg | the only reason loongson got a license was to use mips32 | 03:17 |
azonenberg | and to get the trademarks | 03:17 |
azonenberg | Which was a sound business strategy, most mips binaries these days are mips32 | 03:17 |
azonenberg | And using the trademarks makes your product more marketable | 03:18 |
azonenberg | for example plasma is a mips1 processor (using the actual mips microarch, 5 stage pipeline etc) | 03:19 |
azonenberg | on opencores | 03:19 |
azonenberg | not licensing it at all | 03:19 |
azonenberg | and they've been used in a decent number of projects | 03:19 |
azonenberg | Plasma did? | 03:19 |
azonenberg | Yeah | 03:19 |
azonenberg | So the easy solution is, stay squeaky clean and never use the trademark | 03:19 |
azonenberg | And the one patent that has caused problems with mips1 is expired | 03:20 |
azonenberg | >=2 is dangerous territory | 03:20 |
azonenberg | i think some of those instructions are still covered | 03:20 |
wpwrak | azonenberg: since MIPS and you are both in the US, maybe make friends in the local gun nuts community, and brag publicly about your new acquaintances and just how much they hate lawyers. after all MAD worked to keep the cold war cold, ... :) | 03:20 |
azonenberg | Explain how so many people started implementing 8051 | 03:21 |
azonenberg | as soon as the intel patents expired | 03:21 |
azonenberg | and afaik many (most?) are not licensing | 03:21 |
azonenberg | intel was, until they expired | 03:21 |
azonenberg | So like i said, the solution is to locate all of them and verify you are clean by any reading of the wording | 03:22 |
azonenberg | for example, never use the text "mips" anywhere in documenataion or source code | 03:23 |
azonenberg | And if i dont implement any instructions that were added to the architecture since today's date 17 years ago | 03:23 |
azonenberg | what claim do they have? | 03:23 |
azonenberg | Show me a case where someone has succeeded in court by suing on the basis of an expired patent? | 03:24 |
azonenberg | The R2000 was released in 1985 | 03:24 |
azonenberg | that's 26 years ago | 03:24 |
azonenberg | All of the manufacturers use mips32 | 03:24 |
azonenberg | most of the open ones are mips1 | 03:25 |
wpwrak | azonenberg: how do you tell people how to build a cross-compiler ? | 03:25 |
azonenberg | tell me there isnt a reason | 03:25 |
azonenberg | Why do you say loongson failed? | 03:25 |
azonenberg | They didnt | 03:25 |
azonenberg | They decided they would be more marketable if they implemented the full architecture | 03:26 |
azonenberg | for quite some years they were implementing mips1 and paying nothing | 03:26 |
azonenberg | So the poitn is, mips didnt go after them except for the trademark | 03:26 |
azonenberg | i only see one legal opinion from a quick search involving a mips case that went to court | 03:28 |
azonenberg | and it was related to a suit against the company | 03:28 |
azonenberg | not by them | 03:28 |
wpwrak | well, if azonenberg can make a credible statement that he will and can actually fight back long enough that there may be a ruling against MIPS, even if they can later get it reversed, then MIPS may decide not to push weak claims and risk having their weakness exposed in all the press | 03:32 |
azonenberg | wolfspraul: And it worked | 03:32 |
azonenberg | They paid nothing until they decided they weren't selling enough | 03:33 |
azonenberg | at which point they licensed mips32 | 03:33 |
azonenberg | and started paying | 03:33 |
azonenberg | But until then, they were selling chips and paying nothing | 03:33 |
azonenberg | and not sued for over two years | 03:33 |
azonenberg | and afaik nobody has *ever* sued them over that version of the chip | 03:33 |
azonenberg | i dont think loongson even got sued at all | 03:33 |
azonenberg | from my reading of the articles they approached mips and say "we wants mips32, let us have it" | 03:34 |
azonenberg | Because it means the project is admitting they are no longer unencumbered | 03:36 |
azonenberg | Yes, but in every case i see a clear violation of a trademark | 03:37 |
azonenberg | or something similar | 03:37 |
azonenberg | I can find no recorded cases of them complaining about anyone implementing the original archiecture without using their tradmeark | 03:38 |
azonenberg | Why? | 03:38 |
azonenberg | They wont file a case that has no basis | 03:38 |
azonenberg | so its as simple as, dont give them one | 03:39 |
azonenberg | wolfspraul: nobody will do what | 03:40 |
wolfspraul | if azonenberg is the CEO of a small chip maker in 10 years, he will make the right decision then, as everybody else | 03:40 |
azonenberg | But the question i ask is, what if i dont | 03:41 |
azonenberg | what if i keep making mips1 | 03:41 |
azonenberg | not using their trademark | 03:41 |
azonenberg | and not using any recently added instructions | 03:41 |
azonenberg | I'm not asking that | 03:41 |
azonenberg | I'm asking, will they have any basis to complain | 03:42 |
azonenberg | In a business sense, i'd probably license it because it would be cheaper than reimplementing | 03:42 |
azonenberg | But if i am running an open project | 03:42 |
azonenberg | as you guys should understand | 03:42 |
azonenberg | Say, for example | 03:42 |
azonenberg | milkymist deployed my core instead of latticemico | 03:42 |
azonenberg | Let's say milkymist sells 50,000 units next year | 03:42 |
azonenberg | mips wants money | 03:43 |
azonenberg | My argument was, *that specific* patent has expired | 03:43 |
azonenberg | Which was the last one they have ever sued anyone over mips1 about | 03:43 |
azonenberg | and the last one anyone has been able to come up with that covers mips1 | 03:43 |
azonenberg | Although Lexra had announced its wares as MIPS compatible it had removed four Cobol compiler-dependent instructions not deemed necessary, and seen performance shoot up 30%. MIPS accused it of making false compatibility claims and of using the MIPS trademark in a misleading manner. The newly signed memorandum sees Lexra agreeing not to represent its products as MIPS compatible, and agreeing to accurately indicate that its LX-4080 | 03:44 |
azonenberg | No, and that isnt what i'm intending to do | 03:44 |
azonenberg | I'm asking, if a project like milkymist starts getting on radars | 03:44 |
azonenberg | using a core like this | 03:44 |
azonenberg | Does mips have any legal basis to go after them | 03:44 |
azonenberg | And if so, what can be done to the core to make this less likely | 03:45 |
azonenberg | The fundamental question is | 03:47 |
azonenberg | at a more basic level | 03:47 |
azonenberg | If one wants to make a softcore from scratch | 03:47 |
azonenberg | Using an existing RISC ISA and a completely new microarchitecture | 03:48 |
azonenberg | That there are already C compilers etc for | 03:48 |
azonenberg | are there *any* that are not patent encumbered? | 03:48 |
azonenberg | i chose mips1 as one that i was familiar with and that had no current patents i could find | 03:48 |
azonenberg | wolfspraul: But they are widely supported | 03:49 |
azonenberg | Exactly | 03:49 |
azonenberg | A troll can claim your sandwich or laser pointer cat exerciser violates his patent | 03:49 |
azonenberg | wpwrak: if i was going to extent 8051 | 03:50 |
azonenberg | (which would mean new c compilers etc anyway) | 03:50 |
azonenberg | i'd go all out | 03:50 |
azonenberg | and do a full custom arch | 03:50 |
azonenberg | i designed an 8-bit, i can do a 32 | 03:51 |
azonenberg | The thing is, i'd have to do a gcc port of my architecture | 03:51 |
azonenberg | wolfspraul: also, the last patent suit against a mips1 implementation was five years ago | 03:52 |
azonenberg | and again, i agree that openly using the trademark is silly | 03:53 |
azonenberg | Because it is something they clearly have a claim to | 03:53 |
azonenberg | But the instruction set? | 03:53 |
azonenberg | December 23, 2006 | 03:54 |
azonenberg | was when it expired | 03:54 |
azonenberg | I have seen no suits filed since that date | 03:54 |
wpwrak | azonenberg: one risk may be an implementation technique you use that's "similar" to something they've patented | 03:55 |
azonenberg | mips announces evry time they sue someone | 03:55 |
azonenberg | wpwrak: I will be using a ~20 stage pipeline | 03:55 |
azonenberg | mips1 used around five | 03:55 |
azonenberg | so do most of the newer ones | 03:55 |
azonenberg | wolfspraul: Thats what i'm saying - if you dont use the trademark or market the cpu as compatible | 03:56 |
azonenberg | I dont think they have any option | 03:56 |
azonenberg | no matter how many you are selling | 03:56 |
lekernel | azonenberg, if you get a M1 for your project, we can discuss switching the license of my memory controller to BSD (plus you will already get an out of the box working implementation) | 09:36 |
kristianpaul | wow, that conductive silver ink video from lekernel_ blog very nice, now azonenberg have some video guidelines to follow later too ;-) | 13:16 |
---|
lekernel | azonenberg, you will like this :) | 09:34 |
---|
azonenberg | Except for the massive bloat? Lol | 13:06 |
---|---|---|
azonenberg | And i dont usually do command line editing | 13:06 |
azonenberg | i normally use an X11 based editor like geany (with IDE features disabled) or gedit | 13:06 |
azonenberg | and then manually compile in command line gcc | 13:06 |
wpwrak | azonenberg: so, an X11-based editor ? i wonder if that's enough to make the heresy charge stick ... | 13:38 |
azonenberg | lol | 13:38 |
azonenberg | I do use nano on a routine basis | 13:38 |
azonenberg | but i like my mouse tyvm | 13:38 |
azonenberg | for editing | 13:38 |
azonenberg | wpwrak: The big thing i like about X based editors is the ability to respond to a mouse scroll wheel | 14:03 |
azonenberg | as well as higher resolution than any of my framebuffer modes support | 14:03 |
wpwrak | azonenberg: oh, i like the ability to have multiple xterms in view at the same time. i have a triple-head setup. usually have ~6-12 xterms visible at any given moment. each head (screen) has a 4x4 array of virtual screens. e.g., xchat shares its space with a few xterms with mutt reading my inbox, plus a few xterms for very short-liven activities (kinda post-its). the next virtual screen has 6 large xterms with mutts reading various threa | 14:07 |
wolfspraul | http://code.google.com/p/homecmos/source/browse/trunk/lithography-tests/labnotes/azonenberg_labnotes.txt | 03:09 |
---|---|---|
wolfspraul | also tons of pictures at http://colossus.cs.rpi.edu/~azonenberg/images/homecmos/ | 03:10 |
Thihi | http://colossus.cs.rpi.edu/~azonenberg/images/homecmos/2011-08-06/S7301594.JPG <3 :) | 03:11 |
azonenberg | Lol | 03:13 |
azonenberg | Thihi: I see you've discovered my nyanotechnology? | 03:14 |
wolfspraul | azonenberg: I sell your wares! | 03:14 |
Thihi | azonenberg, :) | 03:14 |
Thihi | azonenberg, way cool | 03:14 |
azonenberg | That was halfway through processing | 03:14 |
azonenberg | patterned photoresist over 200nm evaporated copper | 03:14 |
azonenberg | http://colossus.cs.rpi.edu/~azonenberg/images/homecmos/2011-08-06/S7301603.JPG was the final result after etch and strip of resist | 03:14 |
azonenberg | Going to be doing some more boring (i.e. not nyan cat etc) test patterns tonight or tomorrow in preparation for a run on the campus SEM late this or early next week | 03:15 |
azonenberg | I want to measure slope of edges (which will determine feasible aspect ratios) and thickness of some of my deposited layers | 03:16 |
azonenberg | I did some SEM work before, you can see a few shots at http://colossus.cs.rpi.edu/~azonenberg/images/homecmos/2011-07-05/die_f6/die_f6_002.jpg and http://colossus.cs.rpi.edu/~azonenberg/images/homecmos/2011-07-05/die_f6/die_f6_006.jpg among others | 03:16 |
azonenberg | That was while diagnosing a strange particle contamination | 03:17 |
azonenberg | Which ended up being silicon sawdust from fracturing wafers into individual dies | 03:17 |
azonenberg | and was trivially removed by a more thorough clean before the first processing | 03:17 |
azonenberg | And lol | 03:17 |
azonenberg | I was doing the companion cube before that | 03:17 |
azonenberg | but it got old | 03:17 |
azonenberg | I already promised a friend my next tests (of curves) will use Keroppi | 03:18 |
azonenberg | probably mudkip after that | 03:18 |
azonenberg | MEMS are still a few months out | 03:18 |
azonenberg | but i can make MEMES now ;) | 03:18 |
azonenberg | Lol no | 03:18 |
azonenberg | I might try "THE GAME" though | 03:19 |
azonenberg | 1500? Have fun lol | 03:20 |
azonenberg | My entire archive last time i counted was like 20,000 | 03:20 |
azonenberg | but that goes back to 2004 | 03:20 |
azonenberg | If i had a DSLR i'd do a lot more too | 03:21 |
azonenberg | this silly point and shoot takes a couple seconds to save each image | 03:21 |
azonenberg | And lol, my policy is shoot first and ask questions later | 03:21 |
azonenberg | Disk space is cheap | 03:21 |
azonenberg | A guy i know from back in NJ is a police firearms instructor and he almost always double-taps with his SLR | 03:22 |
azonenberg | although at important events when he doesnt want to crop anything important the policy is two in the chest, one in the head :P | 03:22 |
Action: azonenberg thinks asm is better used in kernel mode | 03:24 | |
azonenberg | Not to say i haven't written hundreds to thousands of lines of ring0 MIPS asm for my kernel... | 03:24 |
azonenberg | But using it for graphics seems a bit silly | 03:24 |
azonenberg | The nyan cat isnt 10um actually | 03:26 |
azonenberg | that process is a little flaky | 03:26 |
azonenberg | i made him at 20um per pixel | 03:26 |
azonenberg | the 15 is obsolete (not much smaller than the 10 but used different optics with serious problems) | 03:26 |
azonenberg | and the 5 is still being debugged | 03:27 |
azonenberg | it needs long exposures and my focuser drifts during them | 03:27 |
azonenberg | so i get all kinds of blurs etc | 03:27 |
azonenberg | Remember MEMS are generally a lot larger than MOS devices though | 03:32 |
azonenberg | I've seen youtube demos of mems devices from real labs that had parts 30um across | 03:32 |
azonenberg | i'm already on par with that | 03:32 |
azonenberg | Yeah | 03:35 |
azonenberg | Point is, CMOS is a lot less likely to be feasible (in terms of building a device of useful complexity) | 03:35 |
azonenberg | than mems | 03:35 |
azonenberg | And if it CAN be made to work, it will take longer to develop | 03:35 |
azonenberg | Both due to the size and the sensitivity to trace metal ions | 03:38 |
wolfspraul | I showed them azonenberg's homecmos pictures too | 09:42 |
---|
lekernel | http://colossus.cs.rpi.edu/~azonenberg/images/homecmos/2011-06-22/ | 07:56 |
---|---|---|
lekernel | http://colossus.cs.rpi.edu/~azonenberg/images/homecmos/2011-06-22/S7300909.JPG | 07:57 |
azonenberg | lekernel: So my hardmask cracked and broke off during the etch step | 18:57 |
---|---|---|
azonenberg | But i feel like i'm getting very close | 18:58 |
lekernel | azonenberg, yeah I read that. but very good results still :-) | 18:59 |
azonenberg | I got the hardmask on there, and in the past i've used the hardmask successfully | 19:00 |
azonenberg | i think it was either thermal shock (I did a cold rinse then a hot etch right after baking), trying to etch too deep too fast | 19:00 |
azonenberg | or the hardmask being too thick | 19:00 |
azonenberg | One drop wasnt thick enough but two was too much, i think i might need to do several depositions using a dilute solution | 19:01 |
azonenberg | if it's too thick in a single layer it'll crack more readily | 19:01 |
wolfspraul | 4'' wafer 35 USD (according to azonenberg) | 05:20 |
---|---|---|
azonenberg_lab | You guys talking fab? | 05:25 |
wolfspraul | azonenberg_lab: hey, is that OK I used your ring oscillator assuming it was cc-by licensed or public domain? | 05:26 |
wpwrak | azonenberg: is your alarm clock synced with IRC ? :) | 05:26 |
azonenberg_lab | wpwrak: No, i saw the log on my other machine when i went to grab something | 05:26 |
azonenberg_lab | This is my machine in the lab | 05:26 |
azonenberg_lab | wolfspraul: I didnt explicitly pick license terms for it but cc-by is fine i guess | 05:27 |
azonenberg_lab | No worries | 05:27 |
azonenberg_lab | Be warned that it's never been tested or even analyzed | 05:27 |
azonenberg_lab | So it might not quite be correct ;) | 05:27 |
wolfspraul | azonenberg_lab: when someone makes an entire wafer full of ICs, how are they normally tested? | 05:28 |
azonenberg_lab | Basic testing for functionality, or failure analysis? Basic testing is a lot easier | 05:28 |
azonenberg_lab | You design a probe card specific to that chip | 05:28 |
azonenberg_lab | Its a ring-shaped PCB with a bunch of needles pointing into the hole at center | 05:28 |
azonenberg_lab | The testing unit sticks that onto the bare wafer (before dicing) and checks each die | 05:29 |
azonenberg_lab | The ones that fail are marked bad immediately | 05:29 |
azonenberg_lab | Then they test again after dicing and packaging | 05:29 |
azonenberg_lab | But you are then more limited since you cant get to any of the test points unless they were brought out to pins | 05:29 |
azonenberg_lab | However, you can now test for packaging flaws | 05:30 |
azonenberg_lab | So its still necessary | 05:30 |
azonenberg_lab | Yep | 05:30 |
azonenberg_lab | Right now, for example, I am about to do visual inspection of an in-process die to see if my hardmask has pinholes in it | 05:30 |
azonenberg_lab | At least, once my hot plate gets warm enough that i can etch on it | 05:30 |
azonenberg_lab | It depends a lot on the contents of the mask set | 05:30 |
azonenberg_lab | If you licensed the fab's cell library you're locked into them | 05:31 |
azonenberg_lab | If you used an in-house or open source cell lib (none of the fab's IP) then it's more feasible to move | 05:31 |
azonenberg_lab | But you still might have to make some tweaks depending on process variaitons | 05:31 |
azonenberg_lab | In my case, a consulting customer of mine has a MEMS device that was desigend completely in house | 05:32 |
azonenberg_lab | and is now shopping fabs for price quotes | 05:32 |
azonenberg_lab | to build a prototype | 05:32 |
azonenberg_lab | However right now we just have the GDS (no physical masks), some little tweaks may be needed to adapt it to their specific process before making physical masks | 05:32 |
azonenberg_lab | Even something as simple as switching from wet etching to lift-off means inverting the light/dark areas of the mask | 05:33 |
azonenberg_lab | rjeffries: Not sure, i'm not involved in that | 05:33 |
azonenberg_lab | I do simulation and wafer test | 05:33 |
azonenberg_lab | plus a little bit of failure analysis here and there | 05:33 |
azonenberg_lab | wolfspraul: They are definitely expensive to make | 05:33 |
azonenberg_lab | How expensive, depends on the feature size and material | 05:33 |
azonenberg_lab | for example really large masks can use film like PCBs | 05:33 |
azonenberg_lab | Anything below like 15um feature size (on the mask) needs chrome on glass | 05:34 |
azonenberg_lab | and really small feature sizes need even more exotic substrates | 05:34 |
azonenberg_lab | Lifetime is pretty long | 05:34 |
azonenberg_lab | they dont get physically damaged in any way unless something scratches them, they get dirty, etc | 05:34 |
azonenberg_lab | woo my KOH is at 85C | 05:35 |
azonenberg_lab | Time to take this die for a swim :) | 05:35 |
wolfspraul | azonenberg_lab: how big are the manufacturing differences between digital, analog and mixed-signal ics? | 05:35 |
azonenberg_lab | wolfspraul: I've only ever really done MEMS | 05:38 |
azonenberg_lab | i'm learning digital stuff now | 05:38 |
azonenberg_lab | and know zilch about analog - analog stuff scares me :P | 05:39 |
azonenberg_lab | I joke that if a circuit i built has anything other than 0, 3.3, or 5 volts on a signal during normal operation, it's broken | 05:39 |
azonenberg_lab | And I'll still be around - this is my living room fab lol | 05:40 |
azonenberg_lab | So i IRC or write lab notes on the netbook while waiting for wafers to cook :p | 05:40 |
Action: azonenberg_lab AFKs for a min to toss die in KOH | 05:40 | |
azonenberg_lab | back | 05:41 |
azonenberg_lab | wolfspraul: Have you been following my home fab work at all? | 05:42 |
wolfspraul | azonenberg_lab: yes definitely. but where is the best place to follow? | 05:45 |
azonenberg_lab | #homecmos | 05:45 |
wpwrak | azonenberg: how's the FOV coming along ? shopping for 12" wafers already ? :) | 05:45 |
azonenberg_lab | i've been committing lab notes every day after i finish my experiments to the google code repo in the topic | 05:45 |
azonenberg_lab | wolfspraul: trunk/lithography-tests/labnotes | 05:47 |
azonenberg_lab | wolfspraul: yes | 05:48 |
azonenberg_lab | wpwrak: No, i'm using 2mm square dies lol | 05:48 |
azonenberg_lab | diced from a 2 incher | 05:48 |
wolfspraul | azonenberg_lab: perfect, now I know how to follow | 05:49 |
azonenberg_lab | wolfspraul: I also have photos http://colossus.cs.rpi.edu/~azonenberg/images/homecmos/ | 05:50 |
azonenberg_lab | sorted by date | 05:50 |
azonenberg_lab | i have one of each die after just about every process step | 05:50 |
azonenberg_lab | wolfspraul: I was tired of people doing cool stuff but not telling other people how theydid it | 05:53 |
azonenberg_lab | I'm a scientist for crying out loud lol | 05:53 |
azonenberg_lab | Ok | 05:58 |
azonenberg_lab | I'd appreciate a link if you do share, but its by no means mandatory | 05:58 |
azonenberg_lab | And actually, to be techical i'd say its covered under the new BSD license | 05:58 |
azonenberg_lab | Sincve thats what the googlecode repo is under | 05:59 |
azonenberg_lab | http://colossus.cs.rpi.edu/~azonenberg/ | 05:59 |
azonenberg_lab | And when i said link, i meant let me know where you posted it :P | 05:59 |
azonenberg_lab | As in, i'd like to hear what people think | 06:00 |
azonenberg_lab | Yeah | 06:00 |
azonenberg_lab | If you want to make your own renders, btw, i have Glade CAD files in the repo of it (and all of the standard cells i made to use in it) | 06:00 |
azonenberg_lab | You can export them to GDS, DXF, or whatever | 06:00 |
azonenberg_lab | Lol | 06:01 |
azonenberg_lab | Well the CAD is way ahead of my fab capabilities atm | 06:01 |
azonenberg_lab | i'm still doing simple wet etching and am trying to get yields up | 06:01 |
azonenberg_lab | Open source standard cell libraries | 06:02 |
azonenberg_lab | And yes | 06:02 |
azonenberg_lab | I do hope to be able t omake 4000 series chips or similar in the future (a year or so) | 06:02 |
azonenberg_lab | Well yeah, of course | 06:03 |
azonenberg_lab | But the educational value of making your own 7400 or 4000 series part | 06:03 |
azonenberg_lab | From a blank wafer and a CAD program | 06:03 |
azonenberg_lab | would be immense | 06:03 |
azonenberg_lab | lol, yes | 06:04 |
azonenberg_lab | actually, this die literally has a heart :P | 06:08 |
azonenberg_lab | It's a companion cube from Portal lol | 06:08 |
azonenberg_lab | at 60 microns per pixel (large, i'm just testing the etch rates) | 06:08 |
lekernel | azonenberg_lab, well, I guess you can print on A0 masks and a reprography machine with good optics to feed into the microscope :) | 07:56 |
azonenberg | lekernel: ping | 01:07 |
---|---|---|
lekernel | azonenberg, pong | 07:53 |
wolfspraul | azonenberg: I meant to ask this for a while. I mentioned your work in my last community news http://en.qi-hardware.com/wiki/Copyleft_Hardware_News_2011-06-01 | 07:58 |
wolfspraul | this one http://en.qi-hardware.com/wiki/File:Azonenberg_ring_oscillator.png | 08:00 |
fpgaminer | azonenberg: I am terribly excited for your work on homebrew ASICs! :D | 00:21 |
---|---|---|
azonenberg | lekernel: http://i.imgur.com/qT8tG.png | 06:36 |
azonenberg | Finally | 06:37 |
azonenberg | I added a few more tests to measure my exact FOV andcheck for edge effects | 06:37 |
azonenberg | Lol yep | 06:42 |
azonenberg | And its 02:42 here | 06:43 |
azonenberg | So not many people awake :p | 06:43 |
azonenberg | I wish it was for me too | 06:56 |
azonenberg | Have to wait for some checks to clear first | 06:56 |
azonenberg | Yeah - a month late in this case | 06:56 |
azonenberg | *want* http://www.mtixtl.com/siwafer1004diax05mm1spntypepdopedresistivities15ohm-cm.aspx | 07:07 |
fpgaminer | azonenberg: is that a companion cube? :P | 07:26 |
azonenberg | fpgaminer: Yes | 07:26 |
azonenberg | this test mask is designed to test a couple of different things | 07:26 |
azonenberg | Resolution, alignment of multiple mask levels | 07:26 |
azonenberg | Edge effect, exact FOV | 07:27 |
azonenberg | Characterize etch rates | 07:27 |
azonenberg | And, in the case of the cube, the potential of etched Si as an artistic medium :P | 07:27 |
azonenberg | i got the idea from http://xkcd.com/260/ | 07:27 |
azonenberg | Except this is Si instead of SiO2 | 07:28 |
azonenberg | Lol the mounting will be far from ESD safe | 07:29 |
azonenberg | Bare ~1cm die mounted with cyanoacrylate glue to a 1 inch stainless steel disk | 07:29 |
azonenberg | Debating whether to try growing thermal oxide over the Si to make it a little more scratch resistant | 07:30 |
azonenberg | Or encapsulating it in some kind of polymer | 07:30 |
azonenberg | In any case when it's done, sputter in a few nm of Au or Pt | 07:30 |
azonenberg | Correct | 07:31 |
azonenberg | The first functional test will be a comb drive, actually | 07:31 |
azonenberg | Still no transistors | 07:31 |
azonenberg | After that, i'll have to get some TMAH (current developer is NaOH which doesnt play well with CMOS) | 07:32 |
azonenberg | Try making some simple logic cells (single inverter etc) | 07:32 |
azonenberg | Followed by a ring oscillator | 07:32 |
azonenberg | I'm going to need to get myself some microprobes for testing as there's no way i can use a multimeter on these things :P | 07:32 |
azonenberg | I had some around the apartment but they belonged to a former roommate who has since graduated | 07:33 |
azonenberg | Lol | 07:36 |
azonenberg | Good luck getting them to 5 micron tips | 07:37 |
azonenberg | Lol | 07:39 |
azonenberg | I've done microsurgery on 200um PCB traces | 07:39 |
azonenberg | I've soldered 25um bond wires to probe tips | 07:39 |
azonenberg | (with difficulty) | 07:40 |
azonenberg | but 5um is probably beyond me | 07:40 |
azonenberg | This was a pain because i couldnt actually pick up the wire easily with my tweezers | 07:43 |
azonenberg | My new tweezers would prob make it a lot easier | 07:44 |
azonenberg | Lol, ASIC is a ways out | 07:46 |
azonenberg | But would certainly be nice | 07:46 |
azonenberg | lol yep | 07:48 |
azonenberg | Lol | 07:53 |
azonenberg | 4004 will probably come first | 07:53 |
azonenberg | A serious goal is to make a working 1:1 replica off published mask art | 07:53 |
azonenberg | Yes | 07:55 |
azonenberg | In any case, copyright is expired and you could just reverse it | 07:55 |
azonenberg | But that saves us the trouble | 07:55 |
azonenberg | One question is whether my process would be compatible enough to actually use their masks | 07:55 |
azonenberg | i'd be using metal gates instead of poly for example | 07:55 |
lekernel | azonenberg: regarding sharpening tips, have you had a look at those DIY tunneling microscopes? | 08:17 |
azonenberg | No, the only EM i was considering making was a SEM | 08:17 |
azonenberg | And i can buy tungsten probe tips for cheap from signatone | 08:17 |
azonenberg | $55 per 5-pack | 08:17 |
azonenberg | *reads* | 08:18 |
azonenberg | lekernel: This look about right? http://i.imgur.com/Mzycj.png | 09:45 |
azonenberg | blue = metal 1, green = N+ diffusion, yellow = P+ diffusion, red = metal gate, white = via 0 | 09:45 |
xiangfu | azonenberg: just want know, what are you doing? | 10:03 |
azonenberg | lekernel: Somebody just pointed out I forgot the N-well around the pmos device :P | 10:04 |
azonenberg | fixed now | 10:04 |
azonenberg | xiangfu: Homebrew MEMS and eventually CMOS fab | 10:04 |
xiangfu | azonenberg: cool | 10:19 |
azonenberg | http://i.imgur.com/y7LzG.png | 11:04 |
azonenberg | lekernel: thoughts? This is an improved version of the last link, you can ignore that one | 11:05 |
azonenberg | kristianpaul: you know what it is? | 11:08 |
azonenberg | kristianpaul: ring oscillator | 11:10 |
azonenberg | lekernel: well this is nice - i'm pretty close to convincing the guy who runs one of the SEM labs at my school | 09:04 |
---|---|---|
azonenberg | to let me image a couple of dies for free | 09:04 |
azonenberg | lekernel: Do you have any experience with ultrasonic cleaning? | 09:03 |
---|---|---|
azonenberg | I'm debating buying one | 09:03 |
azonenberg | holy... how many fpgas are in those things? | 09:26 |
azonenberg | And what type? | 09:26 |
azonenberg | ok, old 36k gate ones | 09:26 |
azonenberg | Wow - could be a nice competitor to nsa@home | 09:28 |
azonenberg | Very nice | 09:29 |
azonenberg | What do you guys plan on doing with it? | 09:29 |
azonenberg | i see | 09:30 |
azonenberg | just wow lol | 09:31 |
azonenberg | those fpgas are packed so tightly they look like a tiled wall | 09:31 |
azonenberg | lekernel: hi | 09:17 |
---|---|---|
azonenberg | I see you saw my latest test pattern, any thoughts? | 09:17 |
azonenberg | http://i.imgur.com/nsrQk.png is a lossless PNG version | 09:17 |
azonenberg | top right and top center of http://i.imgur.com/RQ1lO.png is the actual mask layout | 09:18 |
azonenberg | at ~600 DPI | 09:18 |
azonenberg | ready to be printed and reduced 40x onto the wafer | 09:18 |
azonenberg | Lol me too | 09:26 |
azonenberg | Payday was thursday so i'm in the process of ordering blank wafers etc | 09:27 |
azonenberg | within a month i should be starting fab runs | 09:27 |
azonenberg | But in the meantime i'm killing time by doing mask design | 09:28 |
azonenberg | The plan for this mask is, stick the bottom (red) mask in | 09:28 |
azonenberg | Line up so that the horizontal axis is parallel to a <111> plane and roughly center it on the die | 09:28 |
azonenberg | Expose and etch | 09:28 |
azonenberg | Then do the second level on to pof that | 09:29 |
azonenberg | Align the central cross | 09:29 |
azonenberg | Expose, develop, etch | 09:29 |
azonenberg | And then use the vernier scales etc to see how close I got | 09:29 |
azonenberg | to perfect alignment | 09:29 |
azonenberg | In addition, the squares made out of parallel lines below the cross are there to test how well double etches turn out | 09:30 |
azonenberg | io, hole on top of hole and peak on top of peak | 09:31 |
azonenberg | Each etch will probably be a micron or so deep | 09:31 |
azonenberg | Which is about a minute in 30% KOH at 80C | 09:31 |
azonenberg | well actually that'd be 1.25um but close enough for testing, i just need it deep enough to see edges clearly | 09:36 |
wpwrak | azonenberg: you guys lost me at KOH vs. HF. i live in HCl+H2O2 stone age. what do these critters do ? i suppose at least one of them is an etchant, but does this make the other ? | 00:22 |
---|---|---|
azonenberg | wpwrak: HF is hydrofluoric acid, which eats | 00:25 |
azonenberg | SiO2 (glass) and related materials | 00:25 |
azonenberg | But not silicon or polymer materials | 00:25 |
azonenberg | HF is quite nasty, thats why i work with 2% solution and am still paranoid with double gloves, a face shield, etc :P | 00:26 |
azonenberg | Overkill considering the stuff in this concentration is household rust remover | 00:26 |
azonenberg | But i've seen what the strong stuff can do | 00:26 |
azonenberg | My photoresist is a polymer that dissolves in a weak solution NaOH (household lye) when it's been exposed to light | 00:26 |
azonenberg | UV in particular | 00:27 |
azonenberg | So you shine UV through your mask onto the resist, then develop | 00:27 |
azonenberg | Then you can use HF to eat away the glassy layer under it | 00:27 |
azonenberg | but only where light hit the mask | 00:27 |
azonenberg | It's rare, most rust remover is phosphoric acid | 00:27 |
azonenberg | But Whink brand is HF based | 00:27 |
azonenberg | KOH is potassium hydroxide (caustic potash) which will eat silicon | 00:27 |
azonenberg | It also attacks photoresist so i need the Ta2O5 glass layer as a mask | 00:28 |
azonenberg | i.e. pattern hardmask with photoresist, then pattern silicon with hardmask | 00:28 |
azonenberg | using two etch steps | 00:28 |
azonenberg | The nice thing about KOH is that it's sensitive to the bond structure in the silicon crystal | 00:29 |
azonenberg | It eats nearly 100x faster along one axis than the other one | 00:29 |
azonenberg | So by choosing the angle that you cut the wafer vs the bond planes you can get almost no etching (surface on the <111> vector), 57 degree sloped sidewalls (surface on the <100> vector), or vertical sidewalls (surface on the <110> vector) | 00:30 |
azonenberg | Jeri used HF | 00:31 |
azonenberg | Same concentration as I am - 2% from Whink rust remover | 00:31 |
azonenberg | The main difference is she was doing patterning by hand with electrical-tape masks etc | 00:31 |
azonenberg | I'm doing real lithography at several-micron scales | 00:31 |
azonenberg | And i'm not to the point i can do transistors at this scale by far | 00:31 |
azonenberg | The first step is MEMS | 00:32 |
azonenberg | Build a comb drive | 00:32 |
azonenberg | And before that, basic 2D engraving in Si | 00:33 |
azonenberg | Shallow etching, 10 microns or so | 00:33 |
azonenberg | just characterizing the process | 00:33 |
azonenberg | Connectivity, well | 00:33 |
azonenberg | Etching metal is a solved problem, so is alignment | 00:33 |
azonenberg | The unsolved problem is how to get the metal there in the first place | 00:33 |
azonenberg | there are several deposition processes (sputtering and evaporation are the two big ones) but both need high vacuum | 00:34 |
azonenberg | Lol, or something i build here in new york | 00:34 |
azonenberg | The first step will be etching these patterns http://i.imgur.com/VDW36.png just a few microns deep | 00:34 |
azonenberg | Lol | 00:35 |
azonenberg | Black is informational only (not on the actual mask) | 00:35 |
azonenberg | The outer disk around each pattern is the field of view of my exposure system (about 500 microns) | 00:35 |
azonenberg | Blue areas are masked off, white is to be etched | 00:36 |
azonenberg | Everything outside the disk is not etched | 00:36 |
azonenberg | I'm still thinking of direct write but not for exposure on the wafer | 00:36 |
azonenberg | it'll be used for making metal-on-glass masks | 00:37 |
azonenberg | that are then used in my projection system | 00:37 |
azonenberg | Because it can pattern but has little alignment capability | 00:37 |
azonenberg | unless you build it in a far more advanced way | 00:37 |
azonenberg | The idea was, stick mask blank into the system | 00:37 |
azonenberg | zero it *somewhere* on the blank | 00:37 |
azonenberg | expose, develop, etch | 00:37 |
azonenberg | now you have your mask, 100nm of (say) nickel plated on glass | 00:38 |
azonenberg | With 50 micron (for example) features | 00:38 |
azonenberg | Feed that into my current exposure system | 00:38 |
azonenberg | Reduce 10x | 00:39 |
azonenberg | You now have 5um features and a 2mm FOV, which is enough for a pretty good sized die | 00:39 |
azonenberg | It'd be enough to build a 4004 i think | 00:39 |
azonenberg | 500um is FOV with 40x objective | 00:39 |
azonenberg | 2mm is FOV with 10x | 00:39 |
azonenberg | But that also means my feature size grows 4x so the only way to prevent that is to make the mask 4x smaller | 00:40 |
azonenberg | i.e. 50um half-pitch vs 200um (the limit of my printer) | 00:40 |
azonenberg | I could even hit 5mm if i used the 4x obj but that'd be pushing it | 00:40 |
azonenberg | Because i'd need 20um features on the mask | 00:40 |
azonenberg | And those would be so small i wouldn't be able to see them at 40x magnification easily and get good alignment | 00:41 |
azonenberg | 100x is about the minimum to get micron-level alignment | 00:41 |
azonenberg | And like i said, i'd love direct write onto the wafer | 00:41 |
azonenberg | I just think it's beyond trhe scope of a rev 1 process | 00:42 |
azonenberg | Exactly | 00:43 |
azonenberg | That was the single biggest unsolved problem for me, my group at RPI was puzzling over lithography and mask alignment for months | 00:43 |
azonenberg | thinknig about building an optical column from scratch | 00:44 |
azonenberg | Then i realized we already had one, problem solved | 00:44 |
azonenberg | Yeah, I fully agree with you there | 00:44 |
azonenberg | It's just something that should be saved until the rest of the process is somewhat more mature | 00:44 |
azonenberg | If you want, i can set you up with access to the project http://code.google.com/p/homecmos/ so you can hack on the wiki and start throwing thoughts in there | 00:45 |
azonenberg | Exactly, once you have all the numbers and plans anybody can go build it | 00:45 |
azonenberg | It's the engineering that's hard | 00:45 |
azonenberg | And, once you've built it, the calibration | 00:45 |
azonenberg | getting everything precisely in focus | 00:45 |
azonenberg | Lol | 00:47 |
azonenberg | And this is a solved problem with the microscope - which is a pretty nice piece of glass for the price | 00:47 |
azonenberg | The only big problem is chromatic aberration at higher powers | 00:47 |
azonenberg | But when using monochromatic light from an LED? Non-issue | 00:47 |
azonenberg | Correcty | 00:49 |
azonenberg | Hence why it's a rev 1 process | 00:49 |
azonenberg | The big problem, like i said, with BR is alignment | 00:49 |
azonenberg | It's going to have to be done like they do with steppers | 00:49 |
azonenberg | you have purpose-built alignment marks around the edge of the die | 00:49 |
azonenberg | that it calibrates off | 00:50 |
azonenberg | Maybe for rev 3? But it'd be tricky | 00:50 |
azonenberg | This would be quite the hack if we pulled it off though | 00:50 |
azonenberg | Direct write laser lithography system with 5um or better features | 00:50 |
azonenberg | Good point, only alignment matters | 00:51 |
azonenberg | But what about if you have a nearly blank mask? | 00:51 |
azonenberg | Also, when you say "align to them" | 00:51 |
azonenberg | The detector is easy | 00:52 |
azonenberg | But how do you see it? | 00:52 |
azonenberg | Illuminate with the laser? Bear in mind every laser pulse punches a hole in the photoresist | 00:52 |
azonenberg | Hole meaning drilled? | 00:52 |
azonenberg | Waaay too imprecise | 00:52 |
azonenberg | Do you have any idea how small five microns is? | 00:52 |
azonenberg | Hint, typical human hair is 20um across | 00:53 |
azonenberg | Let's say you drill a hole 1mm across | 00:53 |
azonenberg | You need to be able to localize to within 1/50 of the hole diameter | 00:53 |
azonenberg | And you'd need >1 hole to get rotation locked down as well as position | 00:53 |
azonenberg | It'd just be too imprecise | 00:54 |
azonenberg | lol | 00:54 |
azonenberg | the other thing is, in MEMS, puncturing the die can be problematic | 00:54 |
azonenberg | You might need a big piece for a heatsink or whatever | 00:54 |
azonenberg | It just strikes me as a really bad idea | 00:54 |
azonenberg | Whereas if the first exposure etched alignment marks into th esurface | 00:55 |
azonenberg | At 5um pitch | 00:55 |
azonenberg | We could then see those markings and align future stages to them | 00:55 |
azonenberg | The other thing is, silicon fractures along cleavage planes | 00:56 |
azonenberg | A hole is a potential fracture point | 00:56 |
azonenberg | And, on top of that, each edge of the hole is going to be (at the microscale) broken along one of the cleaveage planes | 00:56 |
azonenberg | Well, the substrate will have at least one edge (or a flat for a wafer) parallel to a cleavage plane | 00:59 |
azonenberg | you'd align theta to that | 00:59 |
azonenberg | So you're aligned to the crystal structure | 01:00 |
azonenberg | (for the first level) and then etch your main pattern plus alignment markings | 01:00 |
azonenberg | crosses, vernier scale, etc | 01:00 |
azonenberg | Around the edges | 01:00 |
azonenberg | Then the next level just aligns to them | 01:00 |
azonenberg | No, you need one edge for the first step since you know which plane it's on a priori | 01:02 |
azonenberg | From there on, you have a cross at each side of the die | 01:02 |
azonenberg | Align x/y to the center of them | 01:02 |
azonenberg | and theta so that the lines are parallel to your axes | 01:02 |
azonenberg | google "byu contact aligner" for Bringham Young Universtity's doc on their manual mask aligner | 01:03 |
azonenberg | We just need to design an automated system that can read those marks | 01:03 |
azonenberg | no, you misunderstand | 01:03 |
azonenberg | You stick the die into it, it scans the edge | 01:04 |
azonenberg | Determines the crystal orientation (if the first run) | 01:04 |
azonenberg | i.e. you tell it "this is a <100> wafer, align X axis to a <111> plane | 01:04 |
azonenberg | Then it'll center your pattern on the fragment approximately | 01:04 |
azonenberg | Future exposures will scan the edge, determine the approximate center (to within 100um or so, really coarse) and then locate the alignment crosses | 01:04 |
azonenberg | which it will use for the real fine alignment | 01:05 |
azonenberg | The problem is that we need to figure out how to see those marks | 01:05 |
azonenberg | and get data that a machine vision system can use to determine the actual position of the die and adjust the stage accordingly | 01:05 |
azonenberg | Correct | 01:06 |
azonenberg | Its the only way to get precise alignment | 01:06 |
azonenberg | below a hundred microns or so | 01:06 |
azonenberg | Not good enough | 01:06 |
azonenberg | Some of my substrates are precise rectangles 1cm square | 01:06 |
azonenberg | you cant tell orientation from that | 01:06 |
azonenberg | http://www.cnf.cornell.edu/cnf_process_photo_step_align.html | 01:07 |
azonenberg | Scroll down to the bottom | 01:07 |
azonenberg | Take it from someone who's done a good amount of machine vision | 01:08 |
azonenberg | Simple euclidean shapes are waaaay easier to work with | 01:09 |
azonenberg | And you can get better precision with them | 01:09 |
azonenberg | What do you mean? | 01:09 |
azonenberg | The first mask level is positioned approximately | 01:09 |
azonenberg | Adds marks for all subsequent alignment steps | 01:10 |
azonenberg | All of the others lock onto those marks | 01:10 |
azonenberg | Unless you're built into a microscope | 01:11 |
azonenberg | You need a camera of some sort, which means an optical column | 01:11 |
azonenberg | I still think the best option is direct write with little to no alignment onto a mask blank | 01:11 |
azonenberg | followed by manual alignment using the microscope | 01:12 |
azonenberg | But there's another problem | 01:12 |
azonenberg | Drift | 01:13 |
azonenberg | As you pan from one side of the die to the other | 01:13 |
azonenberg | Alignment will gradually be lost | 01:13 |
azonenberg | due to imprecisions in the motors etc | 01:13 |
azonenberg | I suspect you'll need to realign periodically during a long run | 01:13 |
azonenberg | Especially if stepping multiple patterns on multiple dies on one wafer | 01:13 |
azonenberg | IOW, if i move 1000um right and 1000um left | 01:14 |
azonenberg | I won't be exactly where i started | 01:14 |
azonenberg | Well, i think we can all agree that the first draft of the bluray system will have little to no visio ncapability | 01:15 |
azonenberg | and just be direct patterning on mask blanks | 01:15 |
azonenberg | Vision is a v3 problem | 01:15 |
azonenberg | v2 is where we introduce laser direct write | 01:15 |
azonenberg | v1 is transparencies on microscope | 01:15 |
azonenberg | Exaggerate? What do you mean | 01:23 |
azonenberg | When you're trying to get alignment down to a few nm it's kinda important | 01:23 |
azonenberg | +/- 150nm for example | 01:24 |
wpwrak | azonenberg: (exaggerated) http://www.cnf.cornell.edu/image/stepper alignment global with microscope overlay.jpg | 01:24 |
azonenberg | what about it? | 01:25 |
azonenberg | You need to be able to start from any angle and determine the correct position | 01:25 |
azonenberg | The rounded corners are an artifact of the etch probably, and the long bars are for theta alignment | 01:27 |
azonenberg | you need a baseline that's good enough to find the other alignnment mark across the wafer | 01:27 |
azonenberg | then the small stepped bars are probably a vernier scale | 01:27 |
azonenberg | for alignment to below the smallest feature scale you can etch | 01:28 |
azonenberg | i know that the stepper the guys at work are using (not the same model as the one on this page) has a vernier | 01:28 |
azonenberg | It's advanced vision | 01:33 |
azonenberg | Those things cost $40M + | 01:33 |
azonenberg | Lol | 01:33 |
azonenberg | For my process i envision using a much simpler alignment strategy | 01:33 |
azonenberg | Probably just a couple of crosses at 0/90/180/270 degrees | 01:33 |
azonenberg | The thing is that not all of the dies have ragged edges | 01:35 |
azonenberg | http://www.mtixtl.com/sisinglecrystalsubstrate110orn10x10x05mm1spundoped.aspx | 01:35 |
azonenberg | 1cm square | 01:36 |
azonenberg | Thats the thing, the edges are accurate to maybe 10um or 25um | 01:37 |
azonenberg | i need alignment to 5um | 01:37 |
azonenberg | and you still need optical to determine which way is up | 01:37 |
azonenberg | Also, http://www.laserlab.com/plotprices.php | 01:37 |
azonenberg | This is the price to beat, you can get commercial photoplots for $34 for a 12x18 inch film sheet | 01:38 |
azonenberg | at 4000 DPI | 01:38 |
azonenberg | Feature sizes on the masks are maybe 25 or 50 um | 01:38 |
azonenberg | if not better | 01:38 |
azonenberg | And 12x18 inch film is enough for a complete mask set | 01:38 |
azonenberg | several times over | 01:39 |
azonenberg | considering that my exposure system can handle up to a 2cm square mask | 01:39 |
azonenberg | Correct | 01:39 |
azonenberg | I'm just saying, unless you are making a lot it may be the case that masks are not viable to homebrew | 01:40 |
azonenberg | On the other hand, the cost of wafer fab is insanely high and homebrew is the only affordable way to experiment | 01:40 |
azonenberg | True | 01:42 |
azonenberg | I think I am going to place a single order from these guys over the summer | 01:42 |
azonenberg | Include a bunch of test patterns etc | 01:42 |
azonenberg | And see how small i can actually reach | 01:43 |
azonenberg | IOW my current lambda is limited by printer resolution | 01:43 |
azonenberg | So if i have a super high res mask i can push the rest of the process to its limit | 01:43 |
azonenberg | I'll do the CAD myself since i want to know all of the details of the mask layout | 01:44 |
azonenberg | $35 plus shipping for 12x18 inches is like 100 test patterns | 01:44 |
azonenberg | heck, for scale | 01:44 |
azonenberg | $35 is the cost of a 4-inch wafer | 01:44 |
azonenberg | They do canada and mexico | 01:46 |
azonenberg | not sure about overseas | 01:46 |
azonenberg | No idea, they just mentioned canada and mexico as being extra fees for shipping etc | 01:47 |
azonenberg | The very-high-res is $52 | 01:49 |
azonenberg | Line widths of 12.7um for axially aligned and 25um for diagonal | 01:49 |
azonenberg | The normal is limited ot 38um for axially aligned and 75 for diagonal | 01:49 |
azonenberg | Yeah, looks like it | 01:59 |
azonenberg | so 6pix is the smallest line they can reliably resolve | 01:59 |
azonenberg | And my printer is 1200 DPI = 21um per pixel | 02:00 |
azonenberg | times 6 pix = 127 microns | 02:00 |
azonenberg | 150 is the smallest i've actually tried doing, but 200 is the smallest that gives goodr results last time i tried | 02:01 |
azonenberg | Actually no, that explains it | 02:01 |
azonenberg | The printer is 600dpi, not 1200 | 02:01 |
azonenberg | lekernel: you around? | 22:47 |
---|---|---|
azonenberg | Did you have a chance to look at the test patterns i posted? Any suggestions? | 22:47 |
azonenberg | The goal is to characterize KOH etch rates and determine the minimum feature size i can reliably fabricate | 22:48 |
azonenberg | I don't know where in the process the limiting factor will be, so far I know that in tests I've hit 5um per pixel in photoresist on copper | 22:48 |
azonenberg | But I haven't done the rest of the process yet (HF wet etching through developed photoresist into tantalum pentoxide hardmask, then stripping PR and wet etching with KOH through hardmask into silicon) | 22:49 |
azonenberg | Well, one thing i need test patterns for even if it works fine is characterizing etch rates | 22:49 |
azonenberg | The hardmask i'm using is Ta2O5 which is marketed as an antireflection coating for solar cells and optoelectronics | 22:50 |
azonenberg | It's never been used for this purpose AFAIK | 22:50 |
azonenberg | But i needed something that could be deposited by spin coating, was more resistant to KOH than SiO2 (which will work as a hardmask but is eaten slowly by KOH and won't survive deep through-wafer etches), and could still be patterned with HF | 22:51 |
azonenberg | That's the biggest risk AFAIK - i dont know if it'll work for this purpose | 22:52 |
azonenberg | I already know i can coat and pattern the photoresist, I already know PR will survive HF (I've etched glass microscope slides with it, though adhesion was poor because i over-etched) | 22:52 |
azonenberg | And KOH etching of Si is a well documented process | 22:53 |
azonenberg | So the hardmask is the biggest risk as of now | 22:53 |
azonenberg | Once I have patterns formed in Si, though, things get a lot less clear | 22:53 |
azonenberg | Metalization etc is much less well developed on the amateur side of things | 22:54 |
azonenberg | I'm in talks with a friend of mine (grad student doing her research on sputtering) and a physics professor at another university who's trying to build a homebrew sputter deposition rig | 22:54 |
azonenberg | Between the three of us, and anybody else who joins my sputter research group between now and when I get Si etching working reliably (which is the last milestone before tackling metalization), I'm hoping in ~6 months of work we'll be able to get a working DC sputtering rig | 22:56 |
azonenberg | o_O | 22:56 |
azonenberg | Working turbopumps?? | 22:56 |
azonenberg | If you guys want to part with any, or design a sputtering rig with my help and let me mail you guys dies to process, that'd be great lol | 22:57 |
azonenberg | I could just imagine this becoming an international hacker fab with the lithography here, metalization in Paris, and wafers being mailed back and forth for processing | 22:58 |
azonenberg | Same here lol | 22:58 |
azonenberg | I'm a PhD student, on a grad student's budget | 22:59 |
azonenberg | Which is why this project is moving as slowly as it is on my end lol | 22:59 |
azonenberg | I finally have a few extra $$ so i'll be placing some orders shortly | 23:00 |
azonenberg | lekernel: Yes, i know it'll be slow - but better than nothing | 23:01 |
azonenberg | And hmm... | 23:02 |
azonenberg | I know what you mean, i've seen shredded pumps | 23:02 |
azonenberg | Are you concerned about a mechanical failure or user error (flipping on the vent valve while it's still spinning)? | 23:02 |
azonenberg | The second could be partially addressed by using electronic valves and building a control system that warns the user, or outright says "no", if you try venting before the pump spins down | 23:03 |
azonenberg | But mechanical failure that brings you from high vacuum to near atmosphere instantly? | 23:03 |
azonenberg | That's gonna be catastrophic no matter what IMO | 23:04 |
azonenberg | However, on the plus side | 23:04 |
azonenberg | That's very rare | 23:04 |
azonenberg | Much more likely is a slow leak | 23:04 |
azonenberg | Which will be something you can detect and plug in advance | 23:04 |
azonenberg | And which, if it starts while the chamber is pumped down, is unlikely to hit a dangerously high pressure before you can shut down the turbo | 23:04 |
azonenberg | Also, consider there are other options besides turbopumps | 23:05 |
azonenberg | Diffusion pumps are almost indestructible for example | 23:05 |
azonenberg | o_O | 23:05 |
azonenberg | I'm told oil diffusion isn't that hard to build | 23:05 |
azonenberg | Good luck in today's world lol | 23:06 |
azonenberg | I know a guy in california with a vial containing a few CCs but thats it | 23:06 |
azonenberg | Outgasses? I don't think so | 23:06 |
azonenberg | The bigger risk IMO would be the surface trapping water | 23:06 |
azonenberg | Which would outgas | 23:06 |
azonenberg | But the vapor pressure of FeO2 is high | 23:07 |
azonenberg | *low | 23:07 |
azonenberg | Oh, good point | 23:07 |
azonenberg | its not just iron oxide, its the hydrate | 23:07 |
azonenberg | So yeah that would be problematic | 23:07 |
azonenberg | My advice would be to build an oil diffusion pump from scratch and not touch the turbo until and unless you get a chamber you're confident with (having gotten down to high vac with the diffusion pump and left it in operation for several hours at a stretch) | 23:08 |
azonenberg | Excellent | 23:08 |
azonenberg | I'm told diffusion pumps have been DIYed in the past | 23:09 |
azonenberg | If you get it working i'd love to see docs | 23:09 |
azonenberg | In other news - stuff on deck for ordering within the next week: bottle of 50nm colloidal silica slurry for CMP, diamond scribe for wafer cleavage, more rubber gloves (it's not a cleanroom but i don't want TOO many fingerprints), empty 4-inch cassettes, a 4-inch single side polished N doped <100> wafer, ten <110> 1cm square single side polished undoped substrates, some die trays | 23:11 |
azonenberg | two pounds of technical grade KOH | 23:11 |
azonenberg | 4 ounce bottle each of Ta2O5 and SiO2 spin-on coating solutions | 23:12 |
azonenberg | UV safety glasses | 23:12 |
azonenberg | And a 1-watt 385nm UV LED flashlight | 23:12 |
azonenberg | I'd go for oil, it's safer | 23:12 |
azonenberg | I know a guy who messed with Cl2 at home | 23:13 |
azonenberg | After a lab accident (ground glass joint popped from overpressure) he had a cough and wheeze for six months | 23:13 |
azonenberg | Why he's still alive is beyond me but past experience has shown that the guy is pretty hard to kill | 23:13 |
azonenberg | being around 20kV laser capacitors doesn't seem to bother him much either lol | 23:14 |
azonenberg | Suffice it to say, oil diffusion is probably a much better bet lol | 23:15 |
azonenberg | France isn't as paranoid about that stuff as the rest of the EU is with RoHS etc? | 23:16 |
azonenberg | Not to say you can't buy all kinds of nasties in the USA too | 23:16 |
azonenberg | But considering stories i hear about people unable to buy isopropanol above 50% in australia etc | 23:16 |
azonenberg | For the record i have a 16oz bottle of 99% IPA / 1% DI water around that i clean stuff with lol | 23:17 |
azonenberg | And lol, i see | 23:17 |
azonenberg | I own a now-defunct LLC that i route orders through if they are suspicious | 23:17 |
azonenberg | My apartment is in a commercial district, the sign on the front of the building says "TROY NEON SIGN COMPANY" | 23:18 |
azonenberg | So no problems here lol | 23:18 |
azonenberg | And i see | 23:18 |
azonenberg | I actually get a lot of good stuff from a biodiesel supplier - DudaDiesel.com | 23:19 |
azonenberg | That's where i'm ordering my KOH from | 23:19 |
azonenberg | It's all pretty pure but still technical grade, if you need trace-metal go elsewhere lol | 23:19 |
azonenberg | Btw, what do you think of getting something published in a journal of electronics education or something like that after this is done? | 23:22 |
azonenberg | The focus not being on hobbyists but on schools, getting kids a taste of microfab without super-expensive equipment or access to a cleanroom | 23:23 |
azonenberg | Demonstrating that your average high school lab is able to do 5um fab with little additional material | 23:23 |
lekernel | azonenberg: do you think the mercury diffusion pump could work with oil instead? | 23:28 |
azonenberg | lekernel: You'd need to clean it out well, the mixture of the two would definitely be problematic | 23:29 |
azonenberg | And the heater would need to be updated for a different set temperature | 23:29 |
azonenberg | So not a problem, you need one anyway | 23:29 |
azonenberg | Maybe some different sized apertures for the nozzle | 23:29 |
azonenberg | But that's about it, i suspect it will work fine | 23:29 |
azonenberg | And it would be significantly more robust than a turbopump | 23:31 |
azonenberg | Yep | 23:31 |
azonenberg | Probably | 23:32 |
azonenberg | Ion pumps? Not familiar with the design | 23:35 |
azonenberg | cryo, diffusion, and turbo are the only three high-vac i know | 23:35 |
azonenberg | Oh, lol | 23:36 |
azonenberg | Something you use on top of a turbo etc? | 23:36 |
azonenberg | That would explain it lol | 23:36 |
azonenberg | I dont expect we'd need one any time soon | 23:36 |
lekernel | azonenberg: because of lack of time to try other modes | 06:57 |
---|---|---|
azonenberg | Btw, have any of you guys tried hand soldering 256-BGA at 1mm pitch? (like the xilinx fpga package) | 07:03 |
azonenberg | Hand meaning at home, not with an iron | 07:03 |
azonenberg | hot plate, toaster oven, etc | 07:03 |
azonenberg | and if so, did you get it to work? | 07:03 |
azonenberg | For a one-off unit? | 07:08 |
azonenberg | and is that for the entire board or a single large bga? | 07:08 |
azonenberg | I'm doing a couple of FPGA designs right now that haven't left simulation but i'm going to have to move them to real hardware at some point | 07:09 |
azonenberg | I see | 07:09 |
azonenberg | I think i'll probably try my hand at homebrewing first, see if i can make it work | 07:09 |
azonenberg | if it fails, $30 down the drain | 07:09 |
azonenberg | and i go have it done right | 07:09 |
azonenberg | ($30 being the cost of the FPGA i'm gonna be using) | 07:09 |
azonenberg | Also, I have an interesting problem I'm working on, maybe you'll have some suggestions | 07:11 |
azonenberg | I'm trying to do counting in arbitrary base | 07:11 |
azonenberg | IOW i have a series of regs representing digits, and a value indicating the base of the arithmetic | 07:11 |
azonenberg | each cycle i add 1 to the rightmost one and if it exceeeds the base, wrap and bump the next one etc | 07:12 |
azonenberg | Do you think carry lookahead is feasible in, say, base 94? | 07:12 |
azonenberg | Or some other relatively large non-power-of-two base? | 07:12 |
azonenberg | Each digit i just use a normal synthesized CLA to increment, but i need to handle carry between digits myself | 07:13 |
azonenberg | wolfspraul, lekernel: any ideas re the high-base counting? | 07:14 |
azonenberg | You mean ripple carry? | 07:16 |
azonenberg | I think it'll be too slow | 07:16 |
azonenberg | This will be running at 200-300 MHz on a spartan-6 | 07:16 |
azonenberg | and needs to generate a result every clock | 07:16 |
azonenberg | back of the envelope guess for 16 base-94 digits says 30+ gate delay | 07:16 |
azonenberg | well 8 is more likely, 16 is an extreme | 07:17 |
azonenberg | 8-10 is a realistic limit | 07:17 |
azonenberg | Cryptanalysis | 07:17 |
azonenberg | I'm generating candidate plaintexts | 07:17 |
azonenberg | starting at AAAAAA and going to ZZZZZ | 07:17 |
azonenberg | the base depends on the character set chosen (lowercase letters, uppercase letters, alphanumeric, alnum with symbols, etc) | 07:18 |
azonenberg | The pipeline after this will expect a plaintext every cycle is the thing | 07:18 |
azonenberg | That slows it down | 07:18 |
azonenberg | No, i mean it skips a cycle | 07:18 |
azonenberg | which is a potentially significant slowdown | 07:19 |
azonenberg | i am trying to avoid needing that stall | 07:19 |
azonenberg | i'm trying to figure out if there's an efficient way to generate a plaintext every cycle, pipelining as deeply as necesssary in the input generation logic | 07:19 |
azonenberg | Yes, but what about base 26? | 07:19 |
azonenberg | or 10, for numeric only? | 07:19 |
azonenberg | I'll certainly consider your suggestion if that turns out to be the best way, but i want to look at all options | 07:20 |
azonenberg | In my CPU implementation i used ripple carry but if there's a more efficient way of doing things in hardware i'm hoping to do that | 07:21 |
azonenberg | I already figured out a block-RAM based method of converting from digits to ASCII text in a single cycle | 07:21 |
azonenberg | vs the relatively long delay i had with multiple data-dependent memory transactions in the CPU code | 07:21 |
azonenberg | i'll be using a dual ported block ROM to generate two characters, then cascade 8 of them side by side | 07:23 |
azonenberg | as long as i can keep the routing delays low, since nothing else will happen that clock cycle, i should be good | 07:23 |
lekernel | azonenberg: btw for the BGA you might ask Andrey from Elphel | 07:45 |
azonenberg | i see | 07:45 |
azonenberg | The one I'm looking at using is an XC6SLX16-FTG256 | 07:46 |
azonenberg | which is 16x16 full array, 1mm pitch | 07:46 |
azonenberg | not super fine | 07:46 |
azonenberg | i have another part that's available in either 64-TQFP, 100-TQFP, or 11x11 0.8mm BGA | 07:47 |
azonenberg | i'm not sure if i can pull off the 0.8mm without paying for a much more expensive process with tighter design rules | 07:47 |
azonenberg | So I just decided to upgrade to a spartan-6 from the spartan-3a i was designing my platform before... huge improvement | 01:33 |
---|---|---|
azonenberg | But now i want a Virtex so i can do 1080P | 01:33 |
lekernel | azonenberg: what platform? | 16:09 |
azonenberg | lekernel: the softcore MIPS i'm practicing verilog on | 18:39 |
azonenberg | lekernel: Nice | 23:12 |
azonenberg | Why is mm1 limited to 1024x768 then? | 23:12 |
azonenberg | and why VGA rather than, say, DVI? | 23:13 |
azonenberg | spartan6 has TMDS, right? | 23:13 |
azonenberg | Any of you guys familiar with Glade? | 00:30 |
---|---|---|
azonenberg | I don't mean the GDK UI editor | 00:30 |
azonenberg | I mean the GDS layout editor | 00:30 |
azonenberg | http://www.peardrop.co.uk/glade/ | 00:31 |
azonenberg | kristianpaul: I set up the google code project "homecmos" and google group "homecmos" | 00:03 |
---|---|---|
azonenberg | Lab blog is on the to-do list | 00:03 |
azonenberg | Right now i have just been posting status updates to my facebook :P | 00:04 |
azonenberg | But that needs to change | 00:04 |
azonenberg | probably gonna set up another blogspot for it | 00:07 |
azonenberg | I already have one, "siliconexposed" | 00:08 |
azonenberg | for my IC reversing work | 00:08 |
azonenberg | You mean semiconducting materials? Or materials used in fab / research | 00:08 |
azonenberg | Silicon is the main actual semiconductor used, germanium and gallium arsenide are used in microwave stuff and LEDs | 00:09 |
azonenberg | Phosphorus, boron, and arsenic are used for P and N type doping | 00:09 |
azonenberg | Aluminum for interconnect wiring, replaced by copper in newer high-speed chips | 00:09 |
azonenberg | Copper ions tend to diffuse and contaminate PN junctions so the copper is usually isolated by some kind of barrier material | 00:10 |
azonenberg | titanium nitride and ruthenium are two i recall specifically | 00:10 |
azonenberg | For dielectric normally you use SiO2 | 00:10 |
azonenberg | newer processes use high-K dielectrics like tantalum pentoxide | 00:10 |
azonenberg | Which i was actually considering using in my process but for a totally different reason (hardmask for wet etching, the stuff is pretty impervious to KOH but is etched quickly in dilute HF) | 00:11 |
azonenberg | Low-K dielectric between wiring layers of newer chips, dont know of any specific materials though | 00:11 |
azonenberg | For processing, various photoresists and developers | 00:11 |
azonenberg | KOH, tetramethyl ammonium hydroxide (TMAH), EDP, and other water-amine complexes for anisotropic wet etching of silicon | 00:12 |
azonenberg | HF for wet etching of SiO2 and some metals, other acids for other metals | 00:12 |
azonenberg | Lots of fluorine based gases for RIE | 00:12 |
azonenberg | And chlorine, halogens in general | 00:12 |
azonenberg | SF6, CCl4, ClF3 | 00:12 |
azonenberg | Argon, as an inert gas for sputtering and purging of stuff | 00:13 |
azonenberg | Nitrogen, for forced-air drying of wafers, purging, and in some cases reactive sputtering to form nitrides and oxynitrides | 00:13 |
azonenberg | there are more but those are the ones that come to mind in particular | 00:13 |
azonenberg | Lol, many of them are hard | 00:14 |
azonenberg | But my processes will be using a much smaller subset of those materials | 00:14 |
azonenberg | I'm actually going to start documenting a lot more stuff in the near future, probably going to start the blog tonight | 00:14 |
azonenberg | 4004 was on a 10um PMOS process iirc | 00:15 |
azonenberg | Can you imagine making a 1:1 scale working replica? :D | 00:16 |
azonenberg | There will def be some process changes though, 4004 was not made to use high-K dielectric | 00:16 |
azonenberg | It probably used polysilicon gates, my process will be using metal | 00:16 |
azonenberg | Well, the first step is MEMS as i can get away with much looser tolerances etc there | 00:17 |
azonenberg | Then, single transistors | 00:17 |
azonenberg | simple CMOS logic cells | 00:18 |
azonenberg | And if i can pull that off - a couple of standard cells plus interconnect wiring | 00:18 |
azonenberg | Then its time to start thinking bigger | 00:18 |
azonenberg | And smaller, as well | 00:18 |
azonenberg | Lol not just yet, i have a ways to go still | 00:19 |
azonenberg | lol | 00:22 |
azonenberg | I'm only concerned about US vendors right now as thats where i'm located | 00:23 |
azonenberg | but there are a lot of international fabs | 00:23 |
azonenberg | in fact, *most* fab is done in the far East - china, taiwan, etc | 00:23 |
azonenberg | japan | 00:23 |
azonenberg | Oh... you are not likely to find semiconductor grade silicon there very easily lol | 00:24 |
azonenberg | your best bet will be ebaying etc probably | 00:24 |
kristianpaul | azonenberg: Is it only you, or it will be an interdiciplinary research? | 00:25 |
azonenberg | You mean, am i the only person on the project? | 00:25 |
azonenberg | As of now i'm the only really active person but i'm bouncing ideas off of a bunch of friends and colleagues | 00:26 |
azonenberg | Lol | 00:26 |
azonenberg | Good luck getting five nines (or probably six or eight, actually) purity silicon out of sand at home | 00:27 |
azonenberg | I'm doing the fab, not the materials production | 00:27 |
azonenberg | Well, its a little more complex than that | 00:31 |
azonenberg | The bluray module won't have alignment capability | 00:31 |
azonenberg | You'll use it to make the masks | 00:31 |
azonenberg | But then a contact aligner will be necessary to actually fab the chip layer by layer | 00:32 |
wpwrak | azonenberg: for alignment, if you can get a substrate that's smaller than the movement range of the x/y laser, you could just align with chip edges (photo sensor on the other side, chip blocks laser light or not) | 00:37 |
azonenberg | Too imprecise | 00:37 |
azonenberg | i'd need theta, magnfiication, etc | 00:37 |
azonenberg | Substrate dimensions will not be precisely controlled | 00:37 |
azonenberg | I'll be fracturing along cleavage planes | 00:37 |
azonenberg | I'll need optical alignment using purpose-built alignment markers on the chip surface | 00:38 |
azonenberg | The thing is, doing that with laser direct write will be tricky | 00:38 |
azonenberg | Doing it by hand under a microscope is a lot easier | 00:38 |
azonenberg | The standard alignment mark is a cross on the bottom layer | 00:39 |
azonenberg | then a hollow cross on the next one | 00:39 |
azonenberg | that you fit over it | 00:39 |
azonenberg | You have one at each side of the die to detect slight theta shifts | 00:40 |
azonenberg | Most production systems don't use lasers | 00:40 |
azonenberg | They use electron beam direct-write (similar to the laser process i'll be using) to create a photomask in chrome on copper | 00:40 |
azonenberg | And then you run that through a contact or projection exposure system | 00:41 |
azonenberg | the key is that the mask-fab process is distinctly separate from the alignment and exposure process | 00:41 |
azonenberg | outline of the die? | 00:42 |
azonenberg | bear in mind that i'll be taking little fractured pieces of silicon and then patterning a square in the middle of them | 00:42 |
azonenberg | Also, scanning will require optical pickups, a camera, vision software | 00:42 |
azonenberg | I'm not saying it's impossible | 00:42 |
azonenberg | But it will definitely not be easy and is certainly not a rev1 or even rev2 capability | 00:42 |
azonenberg | Real production steppers do something similar | 00:43 |
azonenberg | They scan the alignment markings on the first mask level and line the new mask up to that | 00:43 |
azonenberg | all done automatically with no human intervention | 00:43 |
azonenberg | The key is getting good resolution | 00:43 |
azonenberg | we're talking submicron here, potentially | 00:43 |
azonenberg | you cant just use a photodiode, you'd need a full camera | 00:44 |
azonenberg | You could, but that means much more intensive DSP capabilities | 00:44 |
azonenberg | Not for a realtime process | 00:44 |
azonenberg | If you can't automate it faster than a human can align it? | 00:44 |
azonenberg | Not worth the trouble | 00:44 |
azonenberg | Exactly, such as automated alignment | 00:45 |
azonenberg | Which is why i am using a manual alignment process instead | 00:45 |
azonenberg | Which is cheap to set up and requires minimal hardware | 00:46 |
azonenberg | Did you read my paper? | 00:46 |
azonenberg | It was pasted to the channel a few times | 00:46 |
azonenberg | It's just a converted microscope (that still functions as a regular microscope, in fact) | 00:46 |
azonenberg | print the mask pattern on a laser printer at 200 microns per pixel (the limit of my cheap printer, 150 is doable sometimes but closely spaced lines will blur together) | 00:47 |
kristianpaul | wpwrak: http://colossus.cs.rpi.edu/~azonenberg/papers/litho1.pdf | 00:47 |
azonenberg | And use the microscope optics run backwards to project the pattern onto the die | 00:47 |
azonenberg | The first process i described there got me to 15um per pixel on the actual die | 00:47 |
azonenberg | The second one is still being refined, i've hit 5um per pixel but it didnt expose evenly across the field | 00:47 |
azonenberg | i need a more intense UV source and a diffuser | 00:47 |
azonenberg | which is going to be ordered next payday :P | 00:48 |
wpwrak | azonenberg: okay. but that's the process that gives you a very limited field. i'm talking about the x/y BR laser. that shouldn't need a microscope, right ? | 00:48 |
azonenberg | My plan, actually, is to combine the two | 00:48 |
azonenberg | Use the laser direct write process instead of the printer to make masks | 00:48 |
azonenberg | use a low-power objective (say 4x) to project this mask slightly reduced onto the die | 00:48 |
azonenberg | and align through the microscope | 00:48 |
azonenberg | I considered it | 00:49 |
azonenberg | But this lets me get away with lesser tolerances on the laser | 00:49 |
azonenberg | also, direct write is slow | 00:49 |
azonenberg | This way, if i fix a bug on metal 3 | 00:49 |
azonenberg | i can reuse the M1/M2 etc masks | 00:49 |
azonenberg | and only redo the M3 mask | 00:49 |
azonenberg | navre is what? softcore CPU? | 00:50 |
azonenberg | Ah | 00:51 |
azonenberg | wpwrak: Maskless is nice in theory but is awkward | 00:51 |
azonenberg | My thinking is, sputter a microscope slide in metal and direct write on that | 00:51 |
azonenberg | then use the mask in my current process | 00:51 |
azonenberg | Also, has anybody tried synthesizing navre in an ASIC tool? | 00:53 |
azonenberg | rather than fpga | 00:53 |
azonenberg | as in, getting actual gate counts etc | 00:53 |
wpwrak | azonenberg: hmm, seems that a BR reader would already have a strong enough diode. makes things nicely inexpensive :) | 01:49 |
azonenberg | wpwrak: Agreed | 04:04 |
azonenberg | My first project will be a simple MEMS comb drive, once i get that working i'll make a transistor | 04:04 |
azonenberg | then gates | 04:04 |
azonenberg | First actual CMOS project will be a ring oscillator | 04:05 |
azonenberg | That alone, in a 5um homebrew process, will be worth quite a bit for bragging rights lol | 04:05 |
azonenberg | Even if it is just a "hello world" circuit lol | 04:27 |
azonenberg | But there will be a lot of work needed before i'm even close to there... | 04:28 |
azonenberg | Lol, i dont plan on doing that any time soon :p | 04:29 |
azonenberg | lol | 04:30 |
azonenberg | only one drive | 04:34 |
azonenberg | just get a precision linear stage | 04:34 |
azonenberg | put the single axis perpendicular | 04:34 |
azonenberg | The sled would be sitting on top of a linear actuator of some sort | 04:37 |
azonenberg | like used for an automated microscope focuser or similar | 04:37 |
azonenberg | Perhaps | 04:40 |
azonenberg | Correct | 04:47 |
azonenberg | I was planning on having a relatively loose tolerance on the direct-write system | 04:47 |
azonenberg | getting maybe 50 microns per pixel or so | 04:47 |
azonenberg | and then further reducing in the projection system | 04:47 |
azonenberg | I just want something that can go better than the 200um/pix of my cheap laser printer | 04:47 |
azonenberg | and will make darker masks (chrome on glass) | 04:48 |
azonenberg | and the masks will be up to maybe 1cm^2 | 04:48 |
azonenberg | which is, in fact, about the travel range of the servo end to end | 04:48 |
azonenberg | Sure, that's an option | 04:49 |
azonenberg | And thats definitely at least 50um resolution | 04:49 |
azonenberg | But is it chrome on glass, or on plastic? | 04:49 |
azonenberg | If plastic it's less stiff and flat | 04:50 |
azonenberg | and you can get focusing etc issues | 04:50 |
azonenberg | Which is a problem with my current system, actually | 04:50 |
azonenberg | But is it ink on glass? | 04:50 |
azonenberg | Or metal | 04:50 |
azonenberg | I dont think its metal | 04:51 |
azonenberg | The whole idea of the direct write system was to get metal-on-glass masks | 04:51 |
azonenberg | Laser printer or commercial print shop, same deal | 04:51 |
azonenberg | it's still think plastic | 04:51 |
wpwrak | azonenberg: the sled should be able to travel a bit more than 3 cm (for a 12 cm disc). so you'd get at least 9 cm2. plenty of room for that hexacore ;-) | 04:52 |
azonenberg | Lol, no way am i making 3cm^2 dies | 04:52 |
azonenberg | 3cm x 3cm* | 04:52 |
azonenberg | Trying to keep something that big planar and in focus? Not happening any time soon | 04:53 |
azonenberg | i'm shooting for 1cm x 1cm as a more realistic size | 04:53 |
azonenberg | However, that's per die | 04:53 |
azonenberg | Being able to make a stepper, and put multiple dies on a wafer in one session | 04:53 |
azonenberg | Would be very cool for the long run | 04:53 |
azonenberg | lol | 04:58 |
azonenberg | I'm going to need a street between dies anyway for dicing | 05:00 |
azonenberg | What about direct write through the microscope | 05:00 |
azonenberg | Microscope camera | 05:00 |
azonenberg | Realtime feedback of spot size etc | 05:00 |
azonenberg | And would permit alignment as well | 05:00 |
azonenberg | then just get a motorized stage | 05:00 |
azonenberg | I have one already is the point | 05:01 |
azonenberg | and its a $800 model | 05:01 |
azonenberg | not a $10K mitutoyo or zeiss | 05:01 |
azonenberg | But then you need all of the control electronics, optics, assemblies to hold it all together | 05:01 |
azonenberg | And you'd need a scope for inspection anyway | 05:01 |
azonenberg | and failure analysis | 05:02 |
azonenberg | Nobody is going to be doing 5um fab if they can't even see 5um features | 05:02 |
azonenberg | A microscope is implied | 05:02 |
azonenberg | Not really, this scope is about the bare minimum you'd want for work like this | 05:04 |
azonenberg | you cant use a biological scope for opaque samples easily | 05:04 |
azonenberg | you need through-lens illumination | 05:04 |
azonenberg | and low-power 30-50x stereo ones arent enough power to see 5um features clearly | 05:04 |
azonenberg | trust me, i've tried :P | 05:04 |
azonenberg | camera? | 05:05 |
azonenberg | Pixel size is normally a few microns but you can't actually resolve that clearly | 05:05 |
azonenberg | they have bayer filters | 05:05 |
azonenberg | so 10+um is your actual resolution | 05:05 |
azonenberg | thats assuming you have a condensing lens to properly focus everything, ideal best case | 05:06 |
azonenberg | realistically i think 50 is more reasonable | 05:06 |
azonenberg | Yes, its 13.6mm wide | 05:18 |
azonenberg | so you say that's 15-30um per pixel | 05:18 |
azonenberg | But can you actually resolve two lins at that spacing? | 05:18 |
azonenberg | s/lins/lines | 05:18 |
azonenberg | Or is it just empty resolution | 05:18 |
azonenberg | pixels with no meaningful data | 05:18 |
azonenberg | Correct | 05:19 |
azonenberg | I'm willing to be 3-5 pixels is your minimum actual resolution | 05:19 |
azonenberg | Realistically, 10pix is what i see in most cheaper sensors | 05:21 |
azonenberg | So 20-80 | 05:21 |
azonenberg | About what i expected | 05:21 |
azonenberg | Correct | 05:24 |
azonenberg | On the other hand, my nice scope... | 05:24 |
azonenberg | http://www.drawersteak.com/downloads/diffraction-grating-annotated.jpg | 05:25 |
azonenberg | those lins are pretty small lol | 05:25 |
azonenberg | lines* | 05:25 |
azonenberg | iirc around 400nm pitch | 05:25 |
azonenberg | this is with contrast turned all the way up using oil immersion | 05:25 |
azonenberg | those marks are scratches on the sample | 05:26 |
azonenberg | thin plastic diffraction grating | 05:26 |
azonenberg | Having some DNS issues | 05:27 |
azonenberg | 128.213.48.35 | 05:27 |
azonenberg | is the correct IP | 05:27 |
azonenberg | Not nearly as nice as this http://www.drawersteak.com/downloads/chippics/pic16f59/pic16f59_005.jpg | 05:29 |
azonenberg | That's on the zeiss supra 55 SEM at my school's cleanroom lol | 05:29 |
azonenberg | metal 3 of a 350nm 3-metal chip at 50,000x | 05:29 |
azonenberg | i was doing a failure analysis job for a consulting customer and decided to play for a few minuts afterwards on some samples i had lying around | 05:30 |
azonenberg | No, actually | 05:30 |
azonenberg | those arent bacteria | 05:30 |
azonenberg | Look at the one at top left | 05:30 |
azonenberg | it's cracked open | 05:30 |
azonenberg | Those are glass beads from the packaging material | 05:30 |
azonenberg | Lol, they dont show brittle fracture | 05:31 |
azonenberg | (bacteria) | 05:31 |
azonenberg | After the 150C boiling nitric acid to decap | 05:31 |
azonenberg | followed by rinses in acetone and isopropanol | 05:31 |
azonenberg | It's about as sterile as you can get lol | 05:31 |
azonenberg | Stored inside a closed container before being brought into the cleanroom | 05:31 |
azonenberg | I'd expect them to be completely lysed by the HNO3 | 05:31 |
azonenberg | the other giveaway is the perfect spheres and large size range | 05:32 |
azonenberg | I mean, you could be right | 05:32 |
azonenberg | I didn't actually try IDing them | 05:32 |
azonenberg | i was just trying to get practice in focusing the thing just right | 05:32 |
azonenberg | idk if you've ever used an electron microscope but they're a little tricky to get good images out of | 05:32 |
azonenberg | getting the last little bit of focus is hard | 05:32 |
azonenberg | you have two axes of astigmatism, two of aperture alignment, and focus to adjust | 05:33 |
azonenberg | Lol | 05:33 |
azonenberg | Cleanroom time is not cheap | 05:33 |
azonenberg | i cant afford to use it a lot | 05:33 |
azonenberg | $188.50 an hour | 05:33 |
azonenberg | What i do instead is, when i have to use it for work | 05:33 |
azonenberg | Sneak in at the end and shave 15 minutes off the bill when i send it to the customer | 05:33 |
azonenberg | That way i don't have to pay for gowning, pumping down vacuum, etc | 05:34 |
azonenberg | Only for the time i actually used on my own stuff | 05:34 |
azonenberg | combined shipping, you could say ;) | 05:34 |
azonenberg | Yep | 05:34 |
lekernel | azonenberg: http://warrantyvoidifremoved.com/ is coming instead of you, presenting DIY metalwork and jewelry :-) | 16:04 |
azonenberg | lekernel: I won't be om Europe any time soon, sorry | 21:02 |
---|---|---|
azonenberg | s/om/in | 21:02 |
azonenberg | But i'll be sure to keep you guys updated on my progress | 21:03 |
azonenberg | I ran a test this weekend of my photoresist (thinned with acetone to make it less viscous) spin-coated on silicon | 21:03 |
azonenberg | Worked beautifully at 60um feature sizes, the 15um run i thinned it a little too much but most of it still resolved | 21:04 |
azonenberg | I didnt try the 5um process though | 21:04 |
azonenberg | i dont have any polished wafers | 21:04 |
azonenberg | and unpolished lapped finish is so rough that 5um features won't resolve | 21:04 |
azonenberg | So the next step is to wait until payday and buy a batch of wafers :) | 21:05 |
azonenberg | i'm looking at getting two <100> SSP 100mm wafers for surface micromachining work, and ten 1cm x 1cm square <110> dies | 21:06 |
azonenberg | For reasons unknown, <110> is quite a bit more expensive | 21:07 |
roh | azonenberg: what kind of equipment do you have and use? | 21:28 |
azonenberg | roh: A hack job lol | 21:29 |
azonenberg | Spin coater is made from an electric drill, sanding wheel, and a 2x4 | 21:30 |
roh | azonenberg: so you are basically working on semicond. manuf. equipment, redneck-style, homebrew | 21:31 |
azonenberg | roh: mask aligner is a microscope plus some electrical tape | 21:32 |
azonenberg | my exposure lamp is a AA maglite | 21:32 |
azonenberg | though i'm getting a UV led next payday | 21:32 |
lekernel | roh: http://colossus.cs.rpi.edu/~azonenberg/papers/litho1.pdf | 21:32 |
azonenberg | And also, my goal is MEMS right now | 21:32 |
azonenberg | CMOS comes down the road | 21:33 |
wpwrak | azonenberg: are you a son of McGuyver ? :) | 21:33 |
azonenberg | wpwrak: Lol, no | 21:33 |
azonenberg | Nor am i jeri ellsworth's brother | 21:33 |
azonenberg | Just another random geek | 21:33 |
azonenberg | lekernel: Content licenses? | 21:38 |
azonenberg | When did i ever mention that | 21:38 |
azonenberg | Or she, for that matter | 21:38 |
roh | azonenberg: nice | 21:39 |
azonenberg | lekernel: Ah, yes i did | 21:39 |
azonenberg | Probably CC-BY for the documentation and BSD for code | 21:39 |
azonenberg | mask art is TBD as i dont know of any existing FOSS licenses for mask work | 21:40 |
azonenberg | i'd need to think of what will fit best | 21:40 |
azonenberg | cc, treating it as art? BSD, treating the cad fils as code? | 21:40 |
azonenberg | s/fils/files | 21:40 |
azonenberg | roh: I want to build myself a full fab eventually using nice equipment but for now i'm going "redneck style" as you put it | 21:40 |
azonenberg | i cant afford a SEM or commercial mask aligner etc lol | 21:40 |
azonenberg | But i sure can afford a bit of duct tape :P | 21:41 |
azonenberg | That's my thought as well | 21:43 |
azonenberg | Current goal is a MEMS comb drive end of the calendar year | 21:43 |
azonenberg | End of summer i want bulk micromachining worked out | 21:43 |
azonenberg | i.e. build the silicon mechanical structure | 21:43 |
azonenberg | then i'm giving myself till the end of the calendar year to build a DC sputtering system or thermal evaporation rig | 21:43 |
azonenberg | for metal deposition | 21:43 |
azonenberg | lekernel: I'm considering RF for hardware rev 2 | 21:53 |
azonenberg | rev 1 the goal is "make it work" | 21:53 |
azonenberg | rev 2 is "make it work well" | 21:53 |
azonenberg | wpwrak: Lol | 22:08 |
azonenberg | Quite a bit | 22:08 |
azonenberg | Bigger question, will i be below 5um by then? :P | 22:08 |
azonenberg | My roadmap already goes down to 1-2um | 22:09 |
azonenberg | The problem is scaling up to bigger die sizes | 22:09 |
azonenberg | i.e. >100 \lambda across | 22:09 |
wpwrak | azonenberg: 1-2 um .. so if you keep the pace, it'll be 200 nm by 2012, 40 nm by 2013, and 8 m, by 2014 :) | 22:11 |
azonenberg | wpwrak: Lol | 22:11 |
azonenberg | 500nm is the smallest i expect will be even possible with my current process | 22:11 |
azonenberg | Since that's the smallest thing i've even been able to *see* with these optics | 22:11 |
azonenberg | But realistically, since my current focus is MEMS and not CMOS | 22:12 |
azonenberg | How much smaller do you need? | 22:12 |
azonenberg | Exactly | 22:12 |
azonenberg | So for hobbyists, the current scale (or a little further) is probably adequate | 22:13 |
azonenberg | The big thing is expanding die sizes | 22:13 |
azonenberg | No, field of view | 22:14 |
azonenberg | I cannot make the FOV bigger than it is now with the current process, so i'll need to design a scanning system | 22:14 |
azonenberg | using two motorized stages (one for mask and one for die) | 22:14 |
azonenberg | keeping those in sync +/- 1um for a 2-5um process | 22:15 |
azonenberg | over what could be a pretty long exposure | 22:15 |
azonenberg | The other fab technique i'm considering is more involved but may give better results in the long term | 22:15 |
azonenberg | Laser direct write onto metalized microscope slides to make metal-on-glass masks | 22:15 |
azonenberg | Then contact lithography 1:1 using those | 22:15 |
azonenberg | Yes, i considered that too | 22:16 |
azonenberg | So step multiple exposures across | 22:16 |
azonenberg | using big fat bond pads to connect | 22:16 |
azonenberg | Blu-ray sled on a perpendicular axis | 22:18 |
azonenberg | direct write onto the mask | 22:18 |
azonenberg | You can either do 1:1 | 22:18 |
azonenberg | Or, say, use the laser to make a 25um scale mask | 22:18 |
azonenberg | then shrink 10x using the projection system to get 2.5um | 22:18 |
azonenberg | Nope, i dont think so | 22:28 |
azonenberg | The sled already has one axis | 22:28 |
azonenberg | i just need a single-axis linear stage | 22:28 |
azonenberg | Focus range is pretty short | 22:28 |
azonenberg | good focus will need very good planarity i think | 22:29 |
azonenberg | no idea | 22:31 |
azonenberg | I havent looked into it in much depth yet | 22:32 |
azonenberg | projection was the rev1 option because it was so much easier to build | 22:32 |
azonenberg | Well, here's the issue | 22:36 |
azonenberg | DVD is infrared | 22:37 |
azonenberg | bluray is 405nm | 22:37 |
azonenberg | Which is right in the peak sensitivity range of most photoresists | 22:37 |
azonenberg | I'm not patterning by ablation | 22:37 |
azonenberg | that needs way too much power | 22:37 |
azonenberg | this is photochemical | 22:37 |
azonenberg | The photoresist needs ~200 mJ / cm^2 | 22:37 |
azonenberg | So even a 1 mW laser is plenty | 22:37 |
azonenberg | 200 sec for a cm^2 die | 22:38 |
azonenberg | in fact, something more powerful like a bluray will probably have to be fired in few-ns pulses to keep it from dumping too much power and causing heat damage to the mask lol | 22:38 |
azonenberg | Still, localized heating | 22:43 |
azonenberg | The concern is thermal gradients | 22:43 |
azonenberg | Uneven expansion | 22:43 |
azonenberg | and the mask not being the same shape after it cools off | 22:43 |
azonenberg | i'm not using super-expensive ultra-low-thermal-expansion glass for the mask blanks :P | 22:43 |
kristianpaul | azonenberg: you have a blog/wiki/mail-list or something to follow your work? | 23:44 |
azonenberg | kristianpaul: What about MIPS on xilinx? | 04:49 |
---|---|---|
Action: azonenberg is building a mips softcore | 04:50 | |
kristianpaul | azonenberg: mips altera sorry | 11:06 |
azonenberg | ... wow division is slow lol | 22:20 |
---|---|---|
azonenberg | I just wrote a suite of unit tests for my ALU | 22:21 |
azonenberg | in the time it takes to do one division it can test every other instruction on the CPU twice | 22:21 |
wpwrak | azonenberg: in the good old days of CISC, this wouldn't have happened. e.g., the VAX POLYH instruction. calculates an arbitrary-length polynomial with 128-bit floating-point math. | 22:25 |
azonenberg | lol | 17:09 |
---|---|---|
azonenberg | lekernel: I'm intimately familiar with the failings of libcurl | 23:27 |
azonenberg | one of my projects is in seirous trouble due to a segfault deep in the library that nobody can diagnose | 23:28 |
azonenberg | But i havent had issues with its build system (yet) | 23:28 |
azonenberg | Of course, that doesnt stop me from using cmake whenever possible :P | 23:28 |
azonenberg | Have you guys considered DVI output at all? | 06:34 |
---|---|---|
azonenberg | They added TMDS support in spartan-3a | 06:34 |
azonenberg | i havent worked with the 6 but i assume it's there | 06:34 |
wolfspraul | azonenberg: yes definitely lekernel thought about this, and it's doable afaik. One of the nearly infinite things that _could_ be done. | 07:56 |
azonenberg | hdmi is more complex than dvi | 16:13 |
azonenberg | in software | 16:13 |
azonenberg | its a packet based protocol | 16:13 |
azonenberg | havent actually implemented either but was reading up on them a while ago | 16:13 |
azonenberg | lekernel: First, iirc DVI supports HDCP as well | 16:18 |
azonenberg | Though i've never considered implementing it for obvs reasons :P | 16:18 |
azonenberg | But yeah, both are TMDS at the physical layer | 16:18 |
azonenberg | Layer 2 is either raw video data (DVI) or interleaved frames of video and other data (HDMI) | 16:19 |
azonenberg | lekernel: Lol, you and me are the only fans of sputter deposition on fb | 16:21 |
azonenberg | Something tells me it's not the most popular subject | 16:21 |
azonenberg | lekernel: Thats possible | 16:26 |
azonenberg | It's also possible that the HDMI headers are in the blanking interval | 16:26 |
azonenberg | So that you can transparently feed them to DVI | 16:26 |
azonenberg | But going the other way around almost certainly involves adding packet headers | 16:26 |
azonenberg | I'm not sure, like i said i havent actually implemented either yet | 16:27 |
azonenberg | I do know they are compatible at the physical layer, both are R/G/B encoded as TMDS plus a clock at the pixel frequency (i.e. 1/10 the bit rate) | 16:28 |
azonenberg | ? | 17:52 |
azonenberg | is he suspecting ground bounce inside the fpga? | 17:52 |
azonenberg | Sounds like bad power filtering to me | 17:53 |
azonenberg | not enough vccint bypass caps etc | 17:53 |
azonenberg | or enough but too big/too small/too fast/too slow | 17:53 |
azonenberg | Yeah | 17:54 |
azonenberg | i'm sure you know more about fpga stuff than i do (just getting started) but that much seems clear | 17:54 |
azonenberg | lekernel: http://code.google.com/p/homecmos/ | 00:03 |
---|---|---|
azonenberg | setting it up now | 00:03 |
azonenberg | lol | 07:50 |
azonenberg | And that's why the softcore i'm writing is mips | 07:50 |
wolfspraul | azonenberg: from a freedom perspective, mips is a really bad choice. MIPS Inc. has made it clear many times, publicly, privately - they consider anything MIPS their territory and will defend it vigorously. | 07:56 |
lekernel | wolfspraul: btw you should check out azonenberg's work, it's awesome | 08:03 |
lekernel | http://colossus.cs.rpi.edu/~azonenberg/papers/litho1.pdf | 08:03 |
wolfspraul | yes, read azonenberg paper - EXCELLENT WORK! really fantastic stuff | 08:33 |
wolfspraul | roh: did you see the azonenberg paper posted earlier? | 12:11 |
wolfspraul | http://colossus.cs.rpi.edu/~azonenberg/papers/litho1.pdf | 12:12 |
kristianpaul | nice paper azonenberg! | 12:49 |
azonenberg | kraehe: how do you expect to implement an ADC on an fpga? | 15:46 |
azonenberg | oh, you mean an adc driver? | 15:47 |
lekernel | http://colossus.cs.rpi.edu/~azonenberg/papers/litho1.pdf | 21:36 |
---|---|---|
lekernel | hi azonenberg | 22:28 |
azonenberg | hi | 22:28 |
azonenberg | ah, k | 22:28 |
azonenberg | Lets move our discussion to here rather than fb chat so other people can see | 22:28 |
azonenberg | The paper i sent you only describes my work at the 15um node | 22:29 |
azonenberg | Though i did outline the process that I later reached 5um at | 22:29 |
azonenberg | I plan to open the project as much as possible btw, all tools etc will be released under an open license (probably BSD or similar) | 22:30 |
azonenberg | Read the FB note (which i need to post publicly somewhere) | 22:30 |
azonenberg | Long story short, apply hardmask (probably Ta2O5) to the silicon by spin coating and heat treatment | 22:30 |
azonenberg | Spin coat photoresist over that | 22:31 |
azonenberg | expose and develop | 22:31 |
azonenberg | Etch hardmask with 2% HF (Whink rust remover, same stuff jeri uses for gate oxide) | 22:31 |
azonenberg | Then etch the silicon using 30% KOH / 15% IPA / 55% water at ~80C | 22:31 |
azonenberg | You cant use KOH directly because it will attack the resist | 22:31 |
azonenberg | Lol, no questions are dumb | 22:32 |
azonenberg | For the record i have no formal training in EE myself :P | 22:32 |
azonenberg | my BS (and PhD in a few years) will be in comp sci | 22:32 |
azonenberg | Anyway so the nice thing about KOH is that its very anisotropic | 22:32 |
azonenberg | FeCl3 and similar etchants for copper, if you've ever done home PCB fab, are isotropic - they eat equally in all directions | 22:33 |
azonenberg | So you get rounded sidewalls and such | 22:33 |
azonenberg | But KOH eats along the <100> crystal plane nearly 100x faster than <111> | 22:33 |
azonenberg | And <110> is a hair slower than <100> but not by too much | 22:33 |
azonenberg | If you get <110> you can go straight down (assuming your features are parallel to the <111> plane> | 22:34 |
azonenberg | h/o let me send you a paper | 22:34 |
azonenberg | "Fabrication of very smooth walls and bottoms of silicon microchannels for heat dissipation of semiconductor devices" | 22:34 |
azonenberg | http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6V44-40D0MGJ-3&_user=659639&_coverDate=06%2F30%2F2000&_rdoc=1&_fmt=high&_orig=gateway&_origin=gateway&_sort=d&_docanchor&view=c&_searchStrId=1730655729&_rerunOrigin=google&_acct=C000035878&_version=1&_urlVersion=0&_userid=659639&md5=c27c2d506cd9137d148a914c8bde1407&searchtype=a | 22:34 |
azonenberg | Look at the figure they have in there (fig 9 i think?) - 400 micron deep etch with almost vertical sidewalls | 22:34 |
azonenberg | if i didnt know better i'd say it was made with RIE | 22:34 |
azonenberg | that's what i used as the starting point for the comb drive process i have on fbook | 22:35 |
azonenberg | Lol | 22:36 |
azonenberg | I have an openvpn server running at a friend's house | 22:36 |
azonenberg | the machine in my office on campus, and my laptop here, tunnel into it | 22:36 |
azonenberg | then the office machine advertises routes to most journal websites ;) | 22:36 |
azonenberg | I run OSPF http://pastebin.com/Tn4T2e8k | 22:39 |
azonenberg | .11 is the vpn addy of my box on campus lol | 22:39 |
Action: azonenberg mirrors | 22:40 | |
azonenberg | I havent done any etching yet since i cant afford the materials until my next payday lol | 22:42 |
azonenberg | Look at the date on the paper | 22:42 |
azonenberg | i only got litho working reliably last week | 22:42 |
azonenberg | this was an unsolved problem for months | 22:42 |
azonenberg | cant belive how simple the solution turned out to be lol | 22:42 |
azonenberg | lekernel: http://colossus.cs.rpi.edu/~azonenberg/mirror/smoothwalls.pdf | 22:45 |
azonenberg | lekernel: Why not? | 22:46 |
azonenberg | I can buy KOH for $4 a pound | 22:46 |
azonenberg | First off, i will be buying wafers aligned to <110> | 22:47 |
azonenberg | Probably these http://www.mtixtl.com/sisinglecrystalsubstrate110orn10x10x05mm1spundoped.aspx | 22:47 |
azonenberg | they arent technically wafers as they arent round, but <110> is hard to find in full wafers for decent prices | 22:47 |
azonenberg | And i will not be growing oxide, also | 22:48 |
azonenberg | iirc they used Si3N4 deposited by LPCVD as a hardmask, but i dont have CVD capabilities | 22:48 |
azonenberg | So i'll be spin coating this stuff http://emulsitone.com/taf.html | 22:48 |
azonenberg | After heat treating it forms Ta2O5, which is pretty easy to etch with HF | 22:48 |
azonenberg | But it's resistant to alkaline etches | 22:49 |
azonenberg | Dielectric is, it need not be SiO2 | 22:49 |
azonenberg | tantalum pentoxide was actually considered as a high-K dielectric for DRAM a while back - it would work | 22:49 |
azonenberg | But emulsitone also sells a SiO2 coating solution | 22:49 |
azonenberg | And, more importantly, i plan to buy a furnace i can do thermal oxidation in | 22:50 |
azonenberg | I just dont have $1200 to spare yet | 22:50 |
azonenberg | i can do bulk micromachining for much less ($500 or so) | 22:50 |
azonenberg | Including all of the consumables | 22:50 |
azonenberg | CMOS is definitely on the to-do list but its down the road | 22:50 |
azonenberg | among other things because transistors are so sensitive to trace metal contamination whereas MEMS are less so | 22:51 |
azonenberg | Yep | 22:51 |
azonenberg | I do reversing too | 22:51 |
azonenberg | Lol, um | 22:51 |
azonenberg | you *do* know that one of my dreams has been to make a 1:1 scale model of the 4004? | 22:51 |
azonenberg | fully functional | 22:52 |
azonenberg | But like i said mems is easier so that comes first | 22:52 |
azonenberg | no need for doping or tons of masks, the process i'm looking at only needs three masks and only one even somewhat precise alignment step | 22:52 |
azonenberg | the first mask is contact litho at \lambda = 200um lol | 22:52 |
azonenberg | just thinning the wafer in the middle and leaving a thick rim around the edge for handling | 22:53 |
azonenberg | then the through-wafer etch for the fingers followed by metal 1 | 22:53 |
azonenberg | though, as you saw in the paper, getting sub-5um alignment will be pretty easy | 22:55 |
azonenberg | ? | 22:55 |
azonenberg | oh... Those will be trickier - tighter tolerances | 22:55 |
azonenberg | Once i get the basic process working i'll see where it goes lol | 22:55 |
azonenberg | Good point | 22:56 |
azonenberg | Actually, funny thing - i was thinking of making a hybrid of PCB and IC technology at some point to do massively multilayer boards | 22:56 |
azonenberg | Start with dual layer FR4 with copper on both sides | 22:57 |
azonenberg | Pattern your metal 1 and 2 (for power distribution) | 22:57 |
azonenberg | lay down oxide on top of M2 | 22:57 |
azonenberg | sputter or evaporate a micron or so of Al or Cu, etch M3 | 22:57 |
azonenberg | rinse and repeat lol | 22:57 |
azonenberg | What about concentrated HF? | 22:58 |
azonenberg | or SiH4? | 22:58 |
azonenberg | I draw the line at 2% HF myself lol | 22:58 |
azonenberg | Phosgene? | 22:58 |
azonenberg | They use that for ion implantation | 22:58 |
azonenberg | Arsine too | 22:59 |
azonenberg | Neither of those are healthy to be around | 22:59 |
azonenberg | My process will be diffusion based using spin on dopants though | 22:59 |
azonenberg | Less precise but safer and requires less fancy equipment | 22:59 |
azonenberg | just HF wet etch the doped oxide film, coat undoped oxide around it, and heat for a while | 22:59 |
azonenberg | According to wiki, GeH4 is used for CVD epitaxy in a similar manner to SiH4 | 23:01 |
azonenberg | So that means they're using germanium based substrates | 23:01 |
azonenberg | Nope | 23:02 |
azonenberg | I'm ranking processes in order of preferenace | 23:03 |
azonenberg | Spin coating is pretty much impossible to avoid and easy to do (though precise coating thickness control will be a bit tricky until i get a speed controller) | 23:03 |
azonenberg | Metalization will be done by filament evaporation or DC sputtering | 23:03 |
azonenberg | I'm exploring both in parallel and whichever one starts working first is the one i'll use | 23:03 |
azonenberg | though eventually i want both | 23:04 |
azonenberg | Thermal diffusion id going to be necessary for CMOS but not MEMS | 23:04 |
azonenberg | is* | 23:04 |
azonenberg | or at least, not the comb drive | 23:04 |
azonenberg | No, actually, I havent | 23:05 |
azonenberg | But i do have a friend doing research in sputtering | 23:05 |
azonenberg | Metalization was my second area to focus on after litho | 23:05 |
azonenberg | To be done in parallel with etching | 23:06 |
azonenberg | I really havent studied it in nearly as much depth lol | 23:07 |
azonenberg | Nice | 23:10 |
azonenberg | I was planning to do thermal evaporaition initially, actually, since i thouhgt it would be easier | 23:11 |
azonenberg | but if you get sputtering working I might send you guys a few dies to metalize lol | 23:11 |
azonenberg | the tricky thing with sputtering is gonna be doing it *cheaply* | 23:12 |
azonenberg | For $3.5K - $5K you can buy a small sputtering rig from MTI or similar | 23:12 |
azonenberg | Homebrewing cheaper is not going to be easy | 23:12 |
azonenberg | But evaporation looks like it will be a lot easier to do cheaply | 23:12 |
azonenberg | You need a high current, precisely controlled power supply (may be possible to adapt one designed for welding, i may build one for the low-power ~100W prototype) | 23:13 |
azonenberg | A 2-stage rotary vane vacuum pump will get me down to ~40 mtorr, i dont know if thats deep enough | 23:13 |
azonenberg | Ted Pella will sell tungsten boats, filaments, etc for a decent price | 23:13 |
azonenberg | As with wire / pellet charges for evaporation | 23:13 |
azonenberg | I projected (given the pump and vacuum gauge i am thinking of borrowing from a friend) that building a working evaporator would cost ~$1.5K | 23:14 |
azonenberg | maybe only $1K | 23:14 |
azonenberg | Nice, but i dont know french :( | 23:15 |
azonenberg | And i dont plan to build a pump since i can get access to one | 23:16 |
azonenberg | Or, at least a roughing pump | 23:16 |
azonenberg | if high-vac turns out to be necessary i may try my hand at makign a diffusion pump | 23:16 |
azonenberg | unitednuclear sells a 2-stage rotary vane roughing pump for $295 | 23:17 |
azonenberg | i cant imagine DIYing one for less | 23:17 |
azonenberg | Yeah | 23:17 |
azonenberg | But i am not really focusing on vacuum too much yet | 23:17 |
azonenberg | I'm designing processes in the order that i'd use 'em | 23:17 |
azonenberg | and next after spin coating and exposure is etching | 23:17 |
azonenberg | Yeah, i saw that one | 23:18 |
azonenberg | Not bad at all | 23:18 |
azonenberg | Turbopumps are not cheap, that's for sure | 23:21 |
azonenberg | But do you really think you can build one? | 23:21 |
azonenberg | And yes, that will kill them | 23:21 |
azonenberg | Impressive | 23:22 |
azonenberg | But the question i'm asking right now is, how high vacuum is needed for basic evaporation? | 23:22 |
azonenberg | If I purge the chamber with argon or something to remove any traces of oxygen | 23:22 |
azonenberg | then pump down to 40 microns vacuum | 23:22 |
azonenberg | will that be adequate? | 23:22 |
azonenberg | I mean, i've seen DC sputtering done at ~100 mtorr | 23:22 |
azonenberg | Its probably less efficient, slower deposition, etc | 23:23 |
azonenberg | But for DIY the first rule is "make it work" | 23:23 |
azonenberg | not "make it cost effective for mass production" | 23:23 |
azonenberg | Yeah | 23:24 |
azonenberg | I'm not sure why | 23:24 |
azonenberg | But RF sputtering is normally done at much lower (1-2 mtorr) pressures | 23:24 |
azonenberg | i'll be doing DC | 23:24 |
azonenberg | Yep, one more item on the todo list | 23:25 |
azonenberg | I want to set up some kind of proper website for coordinating this, now that i have people interested from all over the place | 23:25 |
azonenberg | right now i'm the main guy pushing the research, i'm bouncing ideas off of two friends who live near me | 23:26 |
azonenberg | and there are a bunch of folks i know online who i talk to about it here and there | 23:26 |
azonenberg | But there's no central location for posting status reports etc | 23:26 |
azonenberg | Any recommendations on some kind of web-based tool that will work well for it? | 23:27 |
azonenberg | I set up the group "homecmos" on google groups but there's been zero traffic so far lol | 23:28 |
azonenberg | i havent tried using it much | 23:28 |
azonenberg | Want to host the list somewhere? Be my guest | 23:29 |
azonenberg | that might work... right now i'm still trying to figure out what kind of web presence to have | 23:31 |
azonenberg | right now its just static html hosted from my office box lol | 23:31 |
azonenberg | any wiki hosts to recommend? | 23:31 |
azonenberg | As a minimum I want a wiki (posting restricted to registered users probably) and a mailing list | 23:32 |
azonenberg | Yeah, i run default mediawiki for one project but its internal and on a LAN-only server | 23:33 |
azonenberg | behind a firewall | 23:33 |
azonenberg | grrrr git | 23:33 |
azonenberg | no | 23:33 |
Action: azonenberg prefers svn | 23:33 | |
azonenberg | Never liked distributed vcs in general | 23:34 |
azonenberg | i'm a big fan of continuous integration so i want everyone committing to trunk so the code gets as many eyes on it as possible early on | 23:34 |
azonenberg | git seems to encourage branching to an extent i dislike | 23:34 |
azonenberg | but i dont want to start any religious wars lol | 23:34 |
azonenberg | lol i've never seen any of those, but w/e | 23:37 |
azonenberg | Right now i have an svn repo but its pretty empty, migrating wouldnt be hard | 23:37 |
azonenberg | I want the wiki and mailing list first, vcs can be hosted wherever | 23:37 |
azonenberg | thoughts on google code? They support VCS backed wikis | 23:38 |
azonenberg | So I think i'm going to go google on this | 23:41 |
azonenberg | i already have the group so i'll google-code the wiki | 23:41 |
azonenberg | lekernel: I dont, unfortunately | 23:43 |
azonenberg | nice thing about google code is that the wiki is VCS backed | 23:43 |
azonenberg | So you can even send out commit emails on wiki changes etc | 23:43 |
azonenberg | Yeah lol | 23:44 |
azonenberg | lekernel: Never heard of it, i think i'll run with google for a while and see how it works | 23:48 |
wpwrak | azonenberg: btw, i agree that vcs-based makes a lot of sense. particularly if you also have an offline renderer/formatter such that you can edit your pages locally and just commit | 23:49 |
4843 matches in 4662 log files with 136329 lines (3.1 seconds).
Generated by irclogsearch.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!