lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs :: EHSM Berlin Dec 28-30 http://ehsm.eu :: latest video http://www.youtube.com/playlist?list=PL181AAD8063FCC9DC
elldekaa has quit [Ping timeout: 264 seconds]
rejon has joined #milkymist
rejon has quit [Ping timeout: 246 seconds]
xiangfu has joined #milkymist
rejon has joined #milkymist
rejon has quit [Ping timeout: 248 seconds]
rejon has joined #milkymist
sb0 has joined #milkymist
<sb0> got some kintex 7 prices... XC7K160T-1FBG676C is 210E
<sb0> that's still expensive, but not as bad as the $1200+ from online shops
<sb0> wpwrak, so, how do you feel about kicad for m3 design?
xiangfu has quit [Remote host closed the connection]
lekernel has joined #milkymist
elldekaa has joined #milkymist
elldekaa has quit [Read error: Connection reset by peer]
elldekaa has joined #milkymist
mumptai has joined #milkymist
elldekaa has quit [Remote host closed the connection]
rejon has quit [Remote host closed the connection]
wpwrak has quit [Ping timeout: 246 seconds]
<lekernel> hmm... where can I find a 10GbE PHY with datasheet not requiring a NDA?
xiangfu has joined #milkymist
methril has joined #milkymist
methril is now known as Guest70045
Guest70045 is now known as methril
methril_ has joined #milkymist
methril has quit [Ping timeout: 255 seconds]
rejon has joined #milkymist
xiangfu has quit [Ping timeout: 246 seconds]
mumptai has quit [Ping timeout: 246 seconds]
rejon has quit [Ping timeout: 246 seconds]
mumptai has joined #milkymist
wpwrak has joined #milkymist
qwebirc7898 has joined #milkymist
<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
methril_ has quit [Ping timeout: 276 seconds]
methril has joined #milkymist
methril is now known as Guest31209
<lekernel> wpwrak: there will be DDR3 (at 1.8Gbps/pin, which will require matched track lengths) and differential traces carrying 5.4Gbps of data
<lekernel> according to http://dangerousprototypes.com/forum/viewtopic.php?f=2&t=2822&start=30 there's no serious length matching ...
<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.
<wpwrak> (of course, having DRC watch such issues would be an additional benefit in the future)
<lekernel> do you have links to complex kicad boards?
<wpwrak> we have one even in the qi-hw universe: http://projects.qi-hardware.com/index.php/p/xue/
<wpwrak> (only routed, never built, though)
<wpwrak> (wp.pdf) i see a few good items :) e.g., selection is indeed a crying shame at the time
<lekernel> (xue) hmm, it's not fully routed
<wpwrak> yes, they stopped somewhat in the middle of the project. but what they did looks pretty decent.
<lekernel> there isn't any track length matching too
<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.
<wpwrak> 3) may be easier but a bit less convenient
<wpwrak> not sure if 1) is possible without going insane ;-)
<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 ;-)
<wpwrak> an "offline" trace length checker could also be easily extended to do DRC on trace length
<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
<lekernel> and same things for differential pairs...?
<wpwrak> they're just a special case of length-matched traces, no ?
<lekernel> you have to respect the spacing between the two signals too
<wpwrak> does this have to be precise ? or is just "about the same path" combined with the common sense "avoid parallel traces" enough ?
<lekernel> I'm thinking of something 40 differential pairs (80 individual signals) + around 200 signals that need to be length matched (in 8 groups)
<lekernel> at 5.4Gbps I guess it has to be quite precise, yes
<wpwrak> ah, lots of interesting rules :)
<wpwrak> sounds like 3) would be preferable over 2) for getting started. first find a nice workflow, and only then worry about integration
<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...
<lekernel> especially since few layout people would work with kicad
<wpwrak> do you think altium/pads have secret knowledge ? like the alchemists did ? :)
<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
<wpwrak> ah well, that's always a possibility
Guest31209 has quit [Remote host closed the connection]
qwebirc7898 has quit [Ping timeout: 245 seconds]
aeris has quit [Ping timeout: 245 seconds]
aeris has joined #milkymist
elldekaa has joined #milkymist
elldekaa has quit [Ping timeout: 240 seconds]
jimmythehorn has joined #milkymist
lekernel has quit [Ping timeout: 246 seconds]
sb0 has quit [Ping timeout: 276 seconds]
lekernel has joined #milkymist
sb0 has joined #milkymist
<GitHub161> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/51f9a2a963c52cff1174954ca9f48fc9e3a20ab6
<GitHub161> [migen/master] fhdl/namer: simplify + more relevant names - Sebastien Bourdeauducq
sb0 has quit [Quit: Leaving]
rejon has joined #milkymist