| --- Sat Sep 8 2012 | 00:00 | |
| sb0 | got some kintex 7 prices... XC7K160T-1FBG676C is 210E | 07:05 |
|---|---|---|
| sb0 | that's still expensive, but not as bad as the $1200+ from online shops | 07:05 |
| sb0 | wpwrak, so, how do you feel about kicad for m3 design? | 07:15 |
| lekernel | hmm... where can I find a 10GbE PHY with datasheet not requiring a NDA? | 12:54 |
| wpwrak | sb0: people have made multilayer designs of comparable complexity with kicad, so i think it should be able to handle the task. maybe it would benefit from a few additions, though, e.g., a trace length calculator | 16:35 |
| lekernel | wpwrak: there will be DDR3 (at 1.8Gbps/pin, which will require matched track lengths) and differential traces carrying 5.4Gbps of data | 17:19 |
| lekernel | according to http://dangerousprototypes.com/forum/viewtopic.php?f=2&t=2822&start=30 there's no serious length matching ... | 17:25 |
| lekernel | https://bugs.launchpad.net/kicad/+bug/593988 | 17:29 |
| wpwrak | something easier would already do the trick: have a means to measure your tracks. since you route manually anyway, you can then make corrections as needed. so you wouldn't even need to specify this to the DRC. | 17:30 |
| wpwrak | (of course, having DRC watch such issues would be an additional benefit in the future) | 17:31 |
| lekernel | http://www.ohwr.org/attachments/1200/kicad_wp.pdf | 17:34 |
| lekernel | do you have links to complex kicad boards? | 17:35 |
| wpwrak | we have one even in the qi-hw universe: http://projects.qi-hardware.com/index.php/p/xue/ | 17:37 |
| wpwrak | (only routed, never built, though) | 17:37 |
| wpwrak | (wp.pdf) i see a few good items :) e.g., selection is indeed a crying shame at the time | 17:39 |
| lekernel | (xue) hmm, it's not fully routed | 17:42 |
| wpwrak | yes, they stopped somewhat in the middle of the project. but what they did looks pretty decent. | 17:43 |
| lekernel | there isn't any track length matching too | 17:43 |
| wpwrak | track matching may be messy. three choices: 1) figure out a workflow that lets you do it without adding/changing code. 2) add a trace length calculator to kicad (you should have connectivity information inside pcbnew). 3) write some processor for the .brd file or maybe even gerber. | 17:46 |
| wpwrak | 3) may be easier but a bit less convenient | 17:46 |
| wpwrak | not sure if 1) is possible without going insane ;-) | 17:46 |
| wpwrak | since i hate C++ and even more the way it's used in kicad, i tend to choose 3) over 2) when i need some features. a bit of perl can work miracles ;-) | 17:47 |
| wpwrak | an "offline" trace length checker could also be easily extended to do DRC on trace length | 17:49 |
| wpwrak | my usual kicad setup is to have things on all my three screens. so a routing process with external tools could have eeschema on the left (for reference and for swapping pins and such), pcbnew in the middle, and a few xterms with tools on the right | 17:50 |
| lekernel | and same things for differential pairs...? | 17:56 |
| wpwrak | they're just a special case of length-matched traces, no ? | 17:57 |
| lekernel | you have to respect the spacing between the two signals too | 17:57 |
| wpwrak | does this have to be precise ? or is just "about the same path" combined with the common sense "avoid parallel traces" enough ? | 17:58 |
| lekernel | I'm thinking of something 40 differential pairs (80 individual signals) + around 200 signals that need to be length matched (in 8 groups) | 17:59 |
| lekernel | at 5.4Gbps I guess it has to be quite precise, yes | 18:00 |
| lekernel | eg http://www.nxp.com/documents/application_note/AN10798.pdf | 18:00 |
| wpwrak | ah, lots of interesting rules :) | 18:03 |
| wpwrak | sounds like 3) would be preferable over 2) for getting started. first find a nice workflow, and only then worry about integration | 18:03 |
| lekernel | I'm a bit worried about disaster scenarios like a couple of expensive respins followed by the conclusion that kicad is not suitable and then switching everything to altium/pads and trying again... | 18:06 |
| lekernel | especially since few layout people would work with kicad | 18:06 |
| wpwrak | do you think altium/pads have secret knowledge ? like the alchemists did ? :) | 18:07 |
| lekernel | no, but there can be practical issues, like kicad DRC not spotting some errors that we painfully find after the board is fabricated and tested | 18:13 |
| wpwrak | ah well, that's always a possibility | 18:14 |
| GitHub161 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/51f9a2a963c52cff1174954ca9f48fc9e3a20ab6 | 23:18 |
| GitHub161 | [migen/master] fhdl/namer: simplify + more relevant names - Sebastien Bourdeauducq | 23:18 |
| --- Sun Sep 9 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!