<cladamw>
wpwrak, one quick question, why did you correspondingly find that TI "Input Capacitor" for explaining 150uF T520 polymer-tantalum capacitors cap ? Although 150uF those are for usb switcher's output use.
<cladamw>
Although TI strongly recommended polymer-tantalum in their both input and output of related product. :-)
<wpwrak>
cladamw: oh, i just remembered having seen that comment on non-polymer caps. not sure why they recommend such a large margin, though
<cladamw>
aha...okay
<wpwrak>
cladamw: my "bible" (the circuit degsiner's companion) doesn't have anything nasty to say about tantalum. so i don't know what TI found :)
<wpwrak>
but i thought i'd pass the warning on
<wpwrak>
the implied message is of course that, should you some day consider a non-polymer tantalum cap for some reason, we may need to find out what those issues are
<cladamw>
since we've not measured surge current & (ac)ripple vs, temperature curve relationship, some good news might be behind them.
<cladamw>
but it'okay that we go for use of polymer-tantalum cap. :)
<wpwrak>
yeah :)
<cladamw>
(trace lengths) about this. I do really have no further ideas now although you seems are against.
<wpwrak>
hmm ?
<wpwrak>
you're talking about the RAM ?
<cladamw>
your last comments that mentioned "That doesn't sound excessively demanding, even without zig-zagging."
<cladamw>
yes
<cladamw>
are you serious ? ;-)
<wpwrak>
what i meant: the layout people shouldn't find it too difficult to follow these design rules
<wpwrak>
maybe the clock is more difficult, with only 0.5 mm of difference recommended
<cladamw>
oah...sure, yes if I tell them. :-)
<cladamw>
yes, but my concerns is that I don't have no idea on that to change current routes between fpga and RAM. ;-)
<wpwrak>
do you think they'll be able to keep the existing routes ? we have quite a lot of changes ...
<cladamw>
not about yes we knew the rules from chip Micron. so if you'd prefer to change it, i may not agree it.
<wpwrak>
so you say you wouldn't want to change the routing, even if it violates micron's design recommendations ?
<cladamw>
yes, I think house will change the "area" under fpga but not the routes existed area there between outside of fpga and RAM.
<cladamw>
wpwrak, yes, i am trying to say like that (i.e) I'd prefer to keep current rc3 routes.
<wpwrak>
(what they'll change) we'll see :) depends a bit on how crowded the layout is so far. e.g., i would expect that running DVI across the FPGA will upset a lot of things
<wpwrak>
let's do it like this: 1) if they have to reroute everything - including RAM - anyway, then they may as well do it properly (following the micron recommendations)
<cladamw>
oah..yes, it's already crowed there, house will inform me like that since the (changes/area) under fpga must be changed.
<cladamw>
2) ?
<wpwrak>
2) if they can keep the FPGA-RAM routes (or only need minor changes), then they or you should measure the lengths and check how far off we are
<wpwrak>
3) if there are excessive differences, we try to fix them
<wpwrak>
how does that sound ?
<cladamw>
three points sound okay. the fact i knew already in M1r4, the area under fpga must be changed since crowed reasons. so what I'd like to keep is the routes from RAM to fpga. I think our goal is focusing on those improvements which rc3 doesn't have. If the changes of RAM routes causes unexpected results, things go complex.
<wolfspraul>
8-layer pcb is also an option I think
<wolfspraul>
I have no problem with that as long as the costs are understood
<cladamw>
i know now is you're keeping at work on every piece of improvements in one time if as possible
<wpwrak>
cladamw: sure. if the RAM traces aren't overly horrible, there's no need to change them
<wolfspraul>
more layers may also help us later if we have smaller boards, higher density balls, bigger chips, etc.
<wolfspraul>
and I think they help with better gnd, emi/signal integrity and similar as well - in general
<cladamw>
also like wolfspraul always said to me, risks sometimes is good thing to discover likely.
<wolfspraul>
ah wait :-)
<wolfspraul>
in business, risk = profit
<wolfspraul>
but maybe that's just theory, I'm scratching my head... :-)
<wolfspraul>
given the risks we take, if it were that easy, we would all be multi-millionaires already :-)
<wpwrak>
i'm just cautious to trust "it works" if the design is way off the specs. because then you don't control your design but the design controls you. and that's when the fear begins. the fear of making any significant change, because you don't know why your system works. we've met this kind of situation in a previous life, haven't we ? ;-)
<wolfspraul>
oh definitely
<cladamw>
so I'd really prefer change/or follow Micron's rules when a next generation or 8 layers then. :-)
<wolfspraul>
once we understand something, once we look in a datasheet and see something is off, we have to investigate!
<wolfspraul>
maybe that next-gen is r4
<wolfspraul>
memory performance is very important, as we have learnt
<wolfspraul>
and we have plans to support ddr3 etc in the future
<cladamw>
wpwrak, sure, one trusts "it works" but liked your points on "because there could also be nasties like one-in-a-billion bit errors"
<wolfspraul>
cladamw: I think 8-layer is an option, why not. depends on you.
<wpwrak>
DDR3 ought to be fun :) note that the design spec i found is from 2006. so we're not exactly talking about bleeding edge :)
<wolfspraul>
I can still reproduce m1 freezing by just leaving it rendering in simple mode. but in order to really make it reproducible, I need about a week now :-)
<cladamw>
wolfspraul, are you trying to say that M1r4 we can route it as 8-layer this time ?
<wolfspraul>
sure why not
<cladamw>
wow...big deal though. :-)
<wolfspraul>
if that makes the layout easier, 8 layer may be the better design/solution
<wpwrak>
wolfspraul: sounds like even more fun than the NOR troubles ;-)
<wolfspraul>
talk with the layout people
<wolfspraul>
I think more layers may make things easier, not harder
<cladamw>
wpwrak, wolfspraul now things go really fun. i like it to direct 8 layers. but i don't know if Sebastien likes or not. :-)
<wpwrak>
hehe :)
<wolfspraul>
you prefer 8 layers?
<wolfspraul>
I don't think what the problem would be - especially if the layout people are comfortable with it and even prefer that!
<wolfspraul>
boards with more layers tend to be *easier* than those with less - or am I wrong?
<wpwrak>
the "problem" would be that it would probably not make sense to try to carry over the old layout
<wolfspraul>
the additional layers help with emi, integrity, better gnd. the only thing I would like to watch and understand well is cost.
<wolfspraul>
ah
<wpwrak>
but i suspect that the potential for this is very limited anyway
<wolfspraul>
the one thing I learn from professional layout people is how fast they are
<wolfspraul>
without any inside knowledge, I can guess they can redo the entire layout in 2-3 days
<wpwrak>
yes, one thing is labour saved. that may not be significant.
<cladamw>
since from all reviews for couples months, we knew DVI routes and RAM routes (caused by crowed addings) which are two biggest things to worry. so a 8-layers can try to do great ground shielding layers. :-)
<wolfspraul>
yes, exactly
<wpwrak>
the other thing is new mistakes avoided. that can of course be hairy.
<wpwrak>
yeah, better have some ground between DVI and RAM ;-)
<cladamw>
wpwrak, sure it indeed to have that, then no much worries.
<wolfspraul>
so why would anyone be opposed to 8-layer?
<cladamw>
so now the problem is can sebastien agree ? ;-)
<cladamw>
:-)
<wpwrak>
wolfspraul: maybe mechanical stability. maybe cost. maybe some obscure parameters that get harder to manage. (thermal, dielectric, whatever)
<wolfspraul>
I want to understand the costs. the rc3 pcb cost 21 USD I think.
<wolfspraul>
we made about 100
<wolfspraul>
1900 USD for 95 pcbs, something like that
<wolfspraul>
I think more layers makes things easier, for everybody.
<wolfspraul>
we may make back any extra pcb costs in saved layout time alone.
<wolfspraul>
the reason people (in the industry) prefer less layers is cost-reduction (!)
<cladamw>
okay, tomorrow I'll send new design files to house for evaluation on 6 and 8-layers cost firstly then feedback here.
<wpwrak>
let alone the debugging an overcrowded layout may need ;-)
<wolfspraul>
the reason the hobbyists prefer less layers is because they are overwhelmed already, and try to remove any difficulty, whatever that may be
<wolfspraul>
so the motivation for 'less layers' is totally different
<wolfspraul>
in the industry, I think most people will agree with you more layers make things *easier*
<wpwrak>
well, the limit for all-DIY is still 2 layers ;-)
<wolfspraul>
less layers = cost, risk
<wolfspraul>
but you can save a little (pennies mostly), which you make back over large volumes
<wpwrak>
yeah. once the "M" stands for "Million", then we should worry about that :)
<cladamw>
wpwrak, ha DIYs are kinda also 'fun' industries.
<wolfspraul>
cladamw: would you agree with my description?
<wolfspraul>
I am super relaxed about 8-layer, I think it will make everybody's life easier.
<wolfspraul>
it may make the pcb a few USD more expensive, but at our volume that doesn't really matter compared to the advantages in design stability we get
<wolfspraul>
now - if all is fine with 6-layer, then of course there may be no need to switch. that's why I say let's consult with the layout house over this.
<wpwrak>
sounds good
<cladamw>
wolfspraul, some points agreed some are not. it depends on what things( adventures of 'sales' or 'tech' developments) we are concerning. ;-)
<cladamw>
since i am not sure what we discussing now is good for M1, but maybe you can say me is F.U.D. though. hehe...;-)
<cladamw>
surroundings among rising developments for execution/ease is yes good. ;-)
<wolfspraul>
what?
<wolfspraul>
don't understand
<wolfspraul>
I think we agree on the next practical steps: go to layout house, see what they say about 6 vs 8 layer.
<cladamw>
sure. :-)
<wolfspraul>
most likely they will say "both seem possible" (of course)
<wolfspraul>
also I think you agree the reason the oem/odm industry prefers less layers is cost reduction
<wolfspraul>
every layer first of all adds some cost, inevitably
<wolfspraul>
so naturally an oem/odm that tries to squeeze out every fraction of a penny will try to remove layers as well :-)
<cladamw>
haha....we are their customer, they would say like that. let's see the costs thy give us later. :-)
<wolfspraul>
but our reason is not cost reduction! our volume is too low
<wolfspraul>
we must make decisions now that help us now
<wolfspraul>
and without cost reduction, I think 8-layer would normally be considered easier/more stable than a 6-layer design for our board
<wolfspraul>
but let's see
<wolfspraul>
I think we are all roughly on the same page about this.
<wolfspraul>
cladamw: how many layers does a typical notebook mainboard have nowadays?
<wolfspraul>
I think it's still 12-14 or so?
<wolfspraul>
if it's that many - why? to keep different signals away safely?
<wolfspraul>
a lot of phones I see have 8 layers
<wolfspraul>
I should check some wifi usb dongles, curious now
<cladamw>
Acer notebooks for 8-layers, I just called house to know.
<wolfspraul>
nice - thanks!
<kristianpaul>
wpwrak: oh indeed, looks odd and something missing
<kristianpaul>
youtube video, now wee ne back to the past 10years and made the M1 revolution begin ;)
<wpwrak>
kristianpaul: oh. that was a long context switch ;-)
<wpwrak>
yup. M2 shall have built-in time travel :)
<kristianpaul>
long, sorry just arriving from work..
<kristianpaul>
traffic wasnt very good today :|
<kristianpaul>
perhaps just un-used white spacces
<kristianpaul>
and lack of video mix and VJ interaction with it
<kristianpaul>
they tought pre-recorded vide clip both music and video loops were all the thing
<wpwrak>
heh :) the joy of "live" performances :)
<kristianpaul>
indeed
* kristianpaul
loves Jean Michel Jarre live performances
<wolfspraul>
what are the plans for m1 boomification now?
<wolfspraul>
should we get started on the kicad transfer?
<wolfspraul>
I wouldn't mind firing up kicad and learning about schematics editing, I hope I can contribute a little...
<wpwrak>
are we done with the review ?
<wolfspraul>
seems like
<wolfspraul>
that thread is messing up my email view :-)
<wolfspraul>
too long!
<wpwrak>
yeah, the thread is a little complex ;-) maybe i should have started a new thread for each subsystem
<wolfspraul>
I'm really eager to get this boom thing going, efficient sourcing is so often overlooked in open hardware, it's not funny anymore
<wpwrak>
boom comes after the schematics. first we need to give it something to eat :)
<wolfspraul>
sure
<wpwrak>
and the new boom also isn't ready yet. maybe 1/3 done so far. the characteristics database should be usable soon. that one of the nastier bits.
<wpwrak>
s/that/that's/
<wpwrak>
ah, and digi-key produced a snag as well. lemme find it ..
<wpwrak>
but if you wget it, you get something weird. function decode_string(in_str) { return decodeURIComponent(in_str); } ... and then a lot of hex data. not entirely sure if this is some particularly clever bit of web design or if they're trying to obfuscate their query results
<wolfspraul>
hmm, I see
<wolfspraul>
I should ping them about boom, adding to todo
<cladamw>
wpwrak, all pages/sheets are done ! so now I'm going to combine them for all into final M1r4.
<wpwrak>
the great finale ! :)
<cladamw>
I just read back log. Agreed on an email would be needed to include those seperate mail threads linked.
<wpwrak>
ok. i'll do better the next time :)
<cladamw>
no, you did well already. The threads are bit a messy since I edited subsystem(each sch sheet) only to corresponding your sub-reviews. :-)
<cladamw>
But actually in my original design files are always kept as newest just generate sub-sheet pdf. :)
<cladamw>
next for me to clean up AD design files about each part's footprint libraries, some of them will let house to do not me though.
<wpwrak>
footprints are fun ;-)
<cladamw>
sorry that about reviews to footprints, i did this way between house and me before.
<cladamw>
but this time, i'll try to open it as possible, i'll find a way for this.
<wpwrak>
would be cool. do they have a nice human-readable export format for footprints ?
<cladamw>
like Y1/C259/new connectors etc...those footprints I still can't edit it for now. :(
<cladamw>
yeah...I'll try to know if there's export way to our list reviews.
<wpwrak>
kewl
<cladamw>
hehe...house doesn't have good review system, they just quick edit then sent to me for review their dimensions before.
<cladamw>
house here jobs as I co-worked with them, they are NOT responsible for accurately 'correct' to corresponding to datasheet's drawing. Always sent back to EE RD to 'confirm'
<wpwrak>
smart ;-)
<cladamw>
this way is eastern businese doings, but not the way as now we're doing though. i know this is not good.
<wpwrak>
well, doing it our way, they wouldn't be responsible for the footprints either :)
<cladamw>
but I'll think another way to 'display', export and else to show out for reviews.
<cladamw>
so since from rc1 to rc3, all new changes for footprints are confirmed by me when house sent back. If i don't like then ask to modify back and forth, that's sometimes spending too long time. :(
<wpwrak>
couldn't you just have edited the ones you didn't like yourself and sent them the corrected versions ?
<cladamw>
yeah, so far i can't, not i couldn't. :(
<cladamw>
if i can then i'll surely & directly myself for it. So i can only edit sch and sch libraries. :-)
<cladamw>
like om has layout member, ee can't do edit footprint jobs but review only. :-O Here's east. :(
xiangfu has joined #milkymist
xiangfu has joined #milkymist
cladamw has joined #milkymist
<wpwrak>
cladamw: but what's preventing you from editing footprints ? would the layout people not accept footprints from you ?
<cladamw>
no else can prevent me to edit footprints. also not from layout people. It's about me that to 'learn' AD for me is not the efficient way.
<cladamw>
1. can i learn it well as expected ?
<wpwrak>
aah, i see. okay :)
<cladamw>
2. is it worthy ?
<wpwrak>
1. sure. 2. perhaps not, since we're moving away from that anyway.
<wpwrak>
have you used fped yes ?
<wpwrak>
s/yes/yet/
<cladamw>
3. i am old now. well.....those are not the blocks if want to learn. But prefer to learn else open s/w step by step, but still slow though for projects.
<cladamw>
(fped) ? seems it's your smart tool again. i remembered there's some for footprints too ?
<wpwrak>
yes, fped is my footprint editor
<wpwrak>
i hope you'll like it. it's not very complicated once you get used to the concept
<cladamw_>
ha...okay I'll learn your gui, so there's no icon in Applications ?
<wpwrak>
icon ?
<cladamw_>
I mean Ubuntu's "Applications" -> "Electronic" -> "KiCad" ? if no, forget it. ;-)
<wpwrak>
ah no. the command line is your friend ;-)
<wpwrak>
and there's no "open" anyway :)
<cladamw_>
yeah...forget it. terminal is my friend recently. :)
<wpwrak>
ah, one warning: fped doesn't warn you if you made changes and try to quit without saving. so always save before quitting (unless you want to discard your changes)
<cladamw_>
aha...good and important warn. ;-)
<wpwrak>
you'll find footprints in the qi-hw projects kicad-libs, ben-wpan, wernermisc, etc. the files are called *.fpd
<cladamw_>
so we will use fped for M1 soon. :-)
<cladamw_>
yeah...to use those you've done already.
<wpwrak>
but first the schematics :)
<wpwrak>
anyway, i'll take a nap now. and then i'll figure out how to get cups to print the M1 schematics ... i hate upgrades :-(
<cladamw_>
alright, sleep first. :-)
<cladamw_>
wait, do you want me to collect sub-system/sheets into one mail ? and also inlcude latest final M1r4 ?
<cladamw_>
i mean i go for collect those sub-reviews url links into one.
<cladamw_>
well...you sleep first though. thanks. :)
<lekernel>
wpwrak: if you want to try the high speed DDR (since you seem to have little trust in the current design, let's build more data) you can use milkymist-ng and the ddrrd/ddrwr commands
<lekernel>
wpwrak: they use some "bit banging" from software to read/write the memory
<GitHub41>
[milkymist/master] Bump version numbers - Sebastien Bourdeauducq
<lekernel>
mwalle: thanks for the patches!
lekernel_ has joined #milkymist
voidcoder has joined #milkymist
cladamw has joined #milkymist
elldekaa has joined #milkymist
<wpwrak>
cladamw: (one mail) no no ... that was about threading. it would have been better if i had started a new thread for each subsystem. that's all. no need to recompile what's there - we now have the updated schematics for this :)
<cladamw>
wpwrak, good morning ! no need a notification about final M1r4 mail to list ?
<cladamw>
since I'm preparing all design files and layout note for house. :-)
<wpwrak>
lekernel: let's wait with this until we have the first M1r4 prototypes. if there was anything obviously wrong already in M1rc3, you'd hit it yourself. and a proper test will take some time (and preparation), so that's better done just once.
<wpwrak>
cladamw: (notification) well, if you think it's useful and not a lot of extra work, sure :)
<lekernel>
then let's not mess with the routing in R4
<wpwrak>
cladamw: and yes, it's good to send an announcement of the latest version of the whole schematics
<lekernel>
we need to support the current boards anyway
<wpwrak>
lekernel: i think the routing will be messed with anyway. i don't see much of a chance for a 1:1 copy
<lekernel>
in the sdram region? why?
<wpwrak>
small things. move that component a little, make room for some other traces here, go to a different layer there, etc. before you know you have to reroute the whole thing
<wpwrak>
so they may as well match the trace lengths while they're at it
<cladamw>
wpwrak, okay, I'lll send a final latest R4 of whole schematics for announcement.
<wpwrak>
it also depends on how crowded the layout already it. if there's a lot of room, maybe you can get away with copying. but i doubt it. there are just too many changes.
<lekernel>
then remove some of those changes
<wpwrak>
that doesn't have to mean that they'd do something radically different, just lay the routes again
<lekernel>
the last thing I want is go through another round of SDRAM timing tinkering, especially if then we have pre-R4/R4 differences that need to be supported e.g. with different bitstreams
<wpwrak>
it doesn't work like that ;-) of course they CAN preserve everything you specify 1:1. make a gerber copy even and connect into it. it just makes the rest of the work harder.
<wpwrak>
did you make optimizations specifically to deal with skew ?
<lekernel>
no
<lekernel>
and I don't want to
<lekernel>
:)
<wpwrak>
exactly my opinion ;-)
<lekernel>
except using the fast I/O clocks and registers ofc
<wpwrak>
and you're making a fine example for why it's important to stick to those design recommendations :) because if you don't, you lose control. and you're already afraid of what may happen.
<wpwrak>
register OFC ?
<lekernel>
I'm not afraid, but life's simply too short to do this.
<lekernel>
yes, I'm using the dedicated I/O registers (in the SERDES) which have good timing
<wpwrak>
in the sense of the FPGA not adding skew of its own ?
<lekernel>
yes, and with timing that doesn't depend on the P&R heuristics
<wpwrak>
all that sounds as if a more precise layout could only help but not make things worse
<lekernel>
theoretically yes
<lekernel>
but fixing a working system is almost always a bad idea
<wpwrak>
did you read the three points i suggested to adam ? 1) let they layout people try to keep things (if that makes sense to them) 2) get a report of trace lengths. 3) see if anything sticks out as particularly bad. i wouldn't worry about a 501 mil difference anywhere. but, say, 1000 mil would be suspicious