<wpwrak>
andres-calderon: ah, don't worry about the standard passives. they're highly replacable anyway.
<wolfspraul>
wpwrak: I just saw Adam's mail on the list
<wolfspraul>
I did a little boom & dsv session with Adam last week, but I think we need to give a little more guidance and feedback otherwise it may go off in strange directions.
<wpwrak>
andres-calderon: only hif you have something particularly odd. ah, diodes are often interesting, too, e.g., for their reverse current
<wolfspraul>
but I think Adam is onto that task now, good! :-)
<wpwrak>
wolfspraul: (session) great !
<wpwrak>
checking the list ..
<wpwrak>
ah, i think i understand what he means
<wpwrak>
putting the component reference as an alias is a band-aid for sure. but since we don't have the proper connection through boom yet, i think it's a nice idea. only takes a moment to remove when the "real thing" is there.
<wpwrak>
it shouldn't interfere with the workflow either ... you'd look up the data sheet with dsv while reading the schematics. so you ought to know what part you need. the data sheet just explains how the part(s) work(s).
<wpwrak>
(guidance) yes, agreed
<wpwrak>
we also need a bit more real life experience with the whole thing :)
<wolfspraul>
wpwrak: Ornotermes was chatting to me about his Arduino-like Linux board
<wolfspraul>
I think Xue may be the closest :-)
<wolfspraul>
after testing Milkymist One boards for 2 weeks I am more than ever convinced that this is the right path
<wolfspraul>
the run was a big success by the way, speaking as the manufacturer for now (boards haven't reached customers yet)
<wolfspraul>
we learnt a lot, and produced 35 fully working boards (run of 40)
<wpwrak>
how big was the yield ?
<wolfspraul>
will send a detailed report asap, hopefully tomorrow
<wpwrak>
whee !
<wpwrak>
very good !
<wolfspraul>
well it was very messy of course
<wpwrak>
as one would expect for a fist run :)
<wolfspraul>
a slight euphemism, well you know me, when I say "we learnt a lot" :-)
<wolfspraul>
he he
<wpwrak>
(right path) what ? xue as arduino-like ?
<wolfspraul>
one option is to launch a browser instead of xpdf
<wolfspraul>
this page lists a lot of pdf docs
<wolfspraul>
so another option would be to include them directly in BOOKSHELF, maybe one by one as they are actually needed in the project
<wolfspraul>
what do you think?
<wolfspraul>
another idea - can you make 'xpdf' configurable, say if there is an environment variable DSV_PDFVIEWER or so it will take that, otherwise xpdf?
<wolfspraul>
there could even be some more logic, for example if someone has evince installed but not xpdf, dsv could detect that
<wpwrak>
launching a browser is problematic. first of all, which do you launch, and second, what will it do then ? e.g., firefox with its "one session only" dogma is a very bad fit
<wpwrak>
konqueror would work better. it spits out lots of junk on stderr (maybe stdout as well), though. plus, few people have/know it.
<wpwrak>
(pdfviewer) the variable sounds like a good idea
<wolfspraul>
how standardized is this /etc/alternatives/x-www-browser stuff?
<wolfspraul>
is that in LSB or somewhere?
<wpwrak>
i think (but not sure) it's a debianism
<wolfspraul>
what do you think about that particular .htm case?
<wolfspraul>
should we include some pdfs from inside it into the BOOKSHELF?
<wolfspraul>
I like the offline-ness
<wolfspraul>
that's whether dsv supports .htm or not
<wolfspraul>
another small detail - if you run 'dsv setup' without a filename, can't it assume 'BOOKSHELF' by default
<wolfspraul>
we want to write some more 'hardware style guide' anyway, and the BOOKSHELF file looks like a nice default
<wpwrak>
(pdfs inside) you can always manually put them. that's what i do.
<wolfspraul>
but then 'dsv setup' shouldn't just do nothing when it's called, it could print an error 'missing filename', or use BOOKSHELF as the default
<wolfspraul>
I would prefer the BOOKSHELF default
<wolfspraul>
have you looked at that url :-)
<wolfspraul>
there's like 20-50 pdfs there
<wpwrak>
and indeed, you lose the offline-ness if you just fire up a browser. taht is, unless you start mirroring. but let's not get there ;-)
<wpwrak>
you probably don't need all of them ;-)
<wolfspraul>
I will probably just add them one by one as needed. even if there is a duplication with the .html url, this is all about caching/offline and convenienc, so a bit of redundancy is not bad imho
<wpwrak>
(BOOKSHELF default) dunno. the fewer "magic names", the better :)
<wolfspraul>
ah, speaking about that
<wolfspraul>
how about adding a 'clean:' target in addition to the 'spotless:' magic name? :-)
<wolfspraul>
a BOOKSHELF file in the root folder looks like a good entry in the style guideline we plan to build over time
<wpwrak>
(clean target) err, where ?
<wolfspraul>
then at least 'dsv setup' could do more than nothing, for example it could say 'missing filename, try dsv setup BOOKSHELF'
<wolfspraul>
in boom
<wolfspraul>
just came to mind since you condemned magic names
<wolfspraul>
but with no 'clean' and only 'spotless' present, I'd say that qualifies too...
<wolfspraul>
if you want I can try some of those dsv improvements, can send you a patch or commit right away, whatever you prefer. just want to make sure it's in line with your thinking.
<wolfspraul>
the current dsv will just download .htm files, then call xpdf with it -> fail
<wpwrak>
(clean/spotless) yeah, i usually try to have both. not 100% consistent, though.
<qi-bot>
[commit] Werner Almesberger: dsv: added DSV_PDFVIEWER as a means to set a PDF viewer different from xpdf http://qi-hw.com/p/eda-tools/fb1c75c
<wpwrak>
supporting it may create the wrong incentive :)
<wolfspraul>
all fine by me, pdf seems to be the gold standard anyway
<wolfspraul>
the html pages I looked at so far (from the xue bookshelf), point to lists of pdf files
<wpwrak>
(pdf) yup. andres also found one .png  :)
<wpwrak>
extracting pdf URLs can sometimes be tricky. e.g., with silabs, it's all done in javascript, so if your browser doesn't let you access the download url, you have to dig into the page source :-(
<wolfspraul>
I'm wondering who uses those 'STEP-DOWN CONVERTER' names
<wpwrak>
(download urls) but i guess we can come up with some "best practice" for that
<wpwrak>
bogus, imho
<wolfspraul>
not to mention that it appears twice for two separate files.
<wolfspraul>
what happens if the same nick appears twice?
<wolfspraul>
probably it will just take the first, or last?
<wpwrak>
andres hasn't changed anything since i commented on the various problems with the names
<wolfspraul>
do you work with hardlinks?
<wpwrak>
hmm, the last :)
<wolfspraul>
well it's very easy
<wpwrak>
they're all regular files
<wolfspraul>
I will only manufacture after we have REAL innovation on the freedom, process and KiCad side
<wolfspraul>
and since I doubt there will be other daredevil manufacturers jumping into this, we will speed up the cleanup or delay the production :-)
<wpwrak>
you mean xue ?
<wpwrak>
(real innovation) with what we have already, most would probably consider us way beyond edge of the visible universe ;-)
<wolfspraul>
you mean the feedback you gave on the list?
<wpwrak>
yes
<wolfspraul>
I will pull up the mail and make it my todo list for tomorrow :-)
<wpwrak>
about the special characters, commas in aliases, etc.
<wpwrak>
(special = non-ascii)
<wpwrak>
some of them are nasty. they hang tools.
<wolfspraul>
sure
<wpwrak>
andres found a few interesting cases, though. e.g., "/" is indeed something you see from time to time
<wolfspraul>
do you understand Adam's feedback?
<wolfspraul>
I tried to explain to him that dsv is separate from boom, but he always keeps mentioning them together. he probably has a point somewhere, but I don't get it yet.
<wpwrak>
he found a real problem, namely that things in the schematics are under-specified. but then he confuses things by connecting them with dsv.
<wolfspraul>
ok we sort it out
<wolfspraul>
I do agree with adam that we will work on bookshelf and the bom in parallel
<wolfspraul>
in the end we should have a link to a pdf for almost everything on the board, why not
<wpwrak>
(gifts) yeah, you made it ! congratulations ! :)
<wpwrak>
kewl. and the ben is there, too
<lekernel>
yup
<wpwrak>
lekernel: btw, i think it would be good if you could post on the qi-hw list when you'll have your workshop. it currently seems a bit under-reported.
<lekernel>
what workshop? 27C3?
<lekernel>
yeah
<wpwrak>
yup
<lekernel>
it's totally under-reported
<lekernel>
it's not even on the congress website, nor fully confirmed yet... :/
<wpwrak>
it's a bit unfortunate that wolfgang didn't mention it in the last monthly news
<lekernel>
maybe i'll wait a bit for the boards to arrive to Beartech, then I can also announce price etc.
<wpwrak>
(not fully confirmed) you mean the event or the date ?
<lekernel>
I still haven't got a confirmation of the CCC organizers that i'll have the room
<wpwrak>
hmm, maybe ping them
<wpwrak>
would be bad if it got dropped on the floor somehow
<lekernel>
oh, they're aware of it
<wpwrak>
after all, "chaos" is part of the concept ;-)
<lekernel>
they wrote me last week
<wpwrak>
so if there's a problem with that room, what would be the plan B ?
<lekernel>
no workshop
<wpwrak>
urgh :-(
<wpwrak>
something else instead ? talk or such ?
<lekernel>
I don't know
<wpwrak>
(which may actually be an improvement, in terms of reaching the masses :)
<lekernel>
in all cases we'll sell boards and put posters all over the place
<wpwrak>
hehe :)
<wpwrak>
if you think a talk may be better than a workshop and it seems there may be a problem with getting the workshop, perhaps you could also suggest a change
<wpwrak>
if they have talk slots open (people dropping out and such), that may be a welcome relief for them
<wpwrak>
of course, it's rather ugly that they don't have such things confirmed by now. i guess you should have told them you'd travel there from australia :)
<lekernel>
they also have a soundsystem it seems, no?
<lekernel>
phonoelit or something like that
<lekernel>
in one of the rooms
<wpwrak>
no idea
<lekernel>
ah, yes, phonoelit
<lekernel>
though they moved the party to cassiopeia...
<lekernel>
from my experience cassiopeia is more a place for young and drunken people
<lekernel>
it's also rather far from the bcc
<wpwrak>
young and drunken should work well. geeks are the sort who grow up slowly if at all, and for many, surroundings with other geeks are the only opportunities to socialize - which invites excesses :-)
<kristianpaul>
damn i want a mm1 but i also want save more money for  a USRP v1
<kristianpaul>
:?
<lekernel>
kristianpaul: send software patches & bugfixes and you get discounts :)
<kristianpaul>
hmm
<wpwrak>
chicken and egg ;-)
<lekernel>
no, there's QEMU
<wpwrak>
good point
<kristianpaul>
well i have tow MM soc running on fpga, but i miss some ram :(
<kristianpaul>
well i have tim
<kristianpaul>
e
<kristianpaul>
ha wikireaders are shipped from taipei
<wpwrak>
kristianpaul: that's where om are at home
<kristianpaul>
oh
<kristianpaul>
worfgang neighbours :)
<kristianpaul>
s/r/l
<lekernel_>
what license would be better for a FPGA synthesis tool? BSD? GPL?
<viric>
Do you want to force the users to publish their modifications?
<viric>
When they publish some variant of it on binary form
<lekernel_>
yes, that's the question
<viric>
I'd go GPL unless someone asks for a BSD license
<wpwrak>
lekernel_: depends a bit on your objectives. if you want to see the code used as much as possible, bsd. if you want to see it prosper in an open environment, gpl.
<viric>
wpwrak: his code may be used, but he may not see it being used :)
<wpwrak>
viric: yes, that's the catch :)
<lekernel_>
I want to enable potential contributing companies as much as possible
<lekernel_>
otoh I'd still like them to release their modifications
<wpwrak>
lekernel_: in any case, don't count on them being "reasonable". if they see a way not to contribute back, they will almost certainly choose that path.
<viric>
for a company, it is usually a much heavier work to fulfill the GPL than the BSD *minimums*, so...
<lekernel_>
maybe something like LGPL or GPL with linking exception could be nice
<wpwrak>
lekernel_: you can also consider the option of dual licensing up to the point where you're no longer the only copyright holder. depending on how you see the process go, this may or may not be feasible.
<viric>
lekernel_: LGPL only requires that *your part* be always replaceable.
<viric>
lekernel_: and still requires modifications to be published as in GPL
<wpwrak>
in this scenario, you'd pick the most restrictive license, and wait for a "good enough reason" to come along. if none happens, nothing changes :)
<lekernel_>
wpwrak: yeah, that's a plan
<viric>
Yes, I'd do that way. If someone asks another kind of license, you may later decide what to do.
<viric>
but you have to care on where your contributions come from
<viric>
If more than one person holds the copyright... you all have to agree on licensing changes
<lekernel_>
yeah, sure
<wpwrak>
the good thing about the gpl is that it balances things quite well. it doesn't try to make everyone happy, but nobody has to be too unhappy either
<lekernel_>
aren't there companies which contribute to BSD-licensed projects?
<lekernel_>
it's hard to guess who would contribute to such a project...
<lekernel_>
hobbyists, probably not
<lekernel_>
mentor graphics, synopsys, etc. definitely not
<wpwrak>
there ought to be. but you also get those who just take the code and run.
<lekernel_>
fpga startups? maybe...
<viric>
it's hard to compete with the free synthesizers from the big companies
<wpwrak>
why not hobbyists ? they may not add "core functionality", but things like ports and such
<wpwrak>
viric: everything is hard before you've done it the first time :)
<lekernel_>
viric: what free synthesizers?
<viric>
free to use
<lekernel_>
Xst? Quartus? no :)
<viric>
yes
<lekernel_>
or, well, a synthesizer is hard to write
<lekernel_>
but Xst and Quartus are the easiest to compete with, relatively
<viric>
are they?
<lekernel_>
yeah, they're buggy bloated crap
<viric>
that, sure.
<viric>
but they are free, and they work for many cases.
<lekernel_>
wpwrak: why not hobbyists? look at what hobbyists contribute to opencores.org :)
<viric>
lekernel_: who do you work for?
<lekernel_>
people who can't design a CPU probably can't contribute much to a synthesizer...
<wpwrak>
well, there's a lot of stuff at opencores. seems to work for some people. their requirements may be different from yours, so things that you'd consider horribly inefficient are acceptable for them.
<wpwrak>
and haven't you used some of the material/concepts from there ? wishbone and such ?
<lekernel>
no
<wpwrak>
also, the big entry of programmable hardware into the DIY market is still to happen :)
<lekernel>
every time I used something from there, this resulted in a failed debug session, a complete rewrite and lots of time wasted
<wpwrak>
(wishbone) ah, i thought you once mentioned it
<viric>
lekernel: are you suffering the "I should do all myself" syndrome? :)
<wpwrak>
;-))
<lekernel>
yeah, I still have a few things which use wishbone, but it's not much, really
<wpwrak>
viric: in fact, it was recently renamed to "lekernel's syndrome" ;-)
<lekernel>
viric: no, I use good tools when they exist
<lekernel>
I didn't rewrite git for example, which is the only thing that never broke during milkymist development
<lekernel>
by contrast, svn was routelinely crashing and sometimes even corrupting my repository... I wonder how I have supported it for so long :)
<lekernel>
the problem is simply that most software is crappy
<lekernel>
and Verilog cores, even worse
<viric>
lekernel: it's for cvs users to feel comfortable
<wpwrak>
funny. never had such trouble with svn. svn is pretty much "nice and simple". alas, also grossly inefficient at some things.
<viric>
I've had troubles with both svn and git :)
<lekernel>
wpwrak: download the linux source, svn add *, svn ci
<lekernel>
this will crash it for sure
<lekernel>
git handles that perfectly
<viric>
svn is quite outdated software based on outdated ideas
<viric>
no fair comparision
<lekernel>
wpwrak: can you give a single example of something I should have re-used instead of replaced?
<wpwrak>
lekernel: of course not :)
<kristianpaul>
wolfspraul: are you planning to sell M1 as sharism or just this shop in germany?
<kristianpaul>
wolfspraul: btw what's that about the fedora server?.. (is related to milkymist and FEL?)
<wolfspraul>
I sell m1 to anybody who pays me.
<wolfspraul>
fedora, no this was just a private comment. After many years I am trying my first non-Debian system now, setting up a small Fedora server.
<wolfspraul>
this may become bigger if Fedora continues to support Milkymist as much as they seem to do.
<wolfspraul>
I was a RedHat user back in the 6.x days
<wolfspraul>
then a long journey through pretty much all other major distros, Debian the last few years
<wolfspraul>
maybe it's time to consider Fedora a bit more again :-)
<kristianpaul>
fedora and mm1 yes, if just dont have it working  my mm development env on debian now, i'll swich to fedore for sure
<wolfspraul>
hmm
<wolfspraul>
interesting
<wolfspraul>
well OK, if things go that way then maybe we see more Fedora use, don't know
<wolfspraul>
Sebastien has given up trying to get his stuff into Debian, and I don't blame him for his focus.
<wolfspraul>
(he has great focus)
<wolfspraul>
meanwhile the Fedora people come forward and jump into this enthousiastically, create a project page, track progress, pull pull pull
<wolfspraul>
admirable
<wpwrak>
the best approach with distros: write good stuff, then wait for them to find it and pick it up :)
<wpwrak>
the whole idea of "developing into a distro" is bogus. you can do that maybe for one, but even there, you're probably not at the edge for long (that is, unless you're an active maintainer of several packages)
<wpwrak>
but FEL is indeed quite impressive. lots of cool stuff there.
<kristianpaul>
yup
<wolfspraul>
what do you mean with 'developing into a distro'?
<kristianpaul>
From workshop in ccc you could better feedback on FEL, i think setup time will be clue on for that day
<wolfspraul>
someone has to be maintainer, it's not so much about pushing anything down anybody's throat, but offering help and sharing the workload
<wolfspraul>
say what we did with fped in Debian :-)
<wolfspraul>
you could have waited for 10 years and it would not have been 'picked up'
<kristianpaul>
other sofware "in the wild"? :)
<kristianpaul>
It was in fedora already may i wrong?
<wolfspraul>
fped you mean?
<wpwrak>
(developing into a distro) basically distro-centric development. instead of just maintaining a "standard" build environment and letting someone whose day to day business is putting things into the distro take care of the integration
<wolfspraul>
yeah it was 'picked up' very very early
<kristianpaul>
fped: yes
<wolfspraul>
the fedora guys are amazingly proactive
<kristianpaul>
yup
<kristianpaul>
thats the word, proactive
<wolfspraul>
ah yes I agree, of course distro-specific dependencies are bad
<wpwrak>
(debian/fped) oh, that was nice and it definitely accelerated things (and probably made the integration cleaner). but in the long run, xiangfu will probably run out of time for maintaining that link, because debian is probably only a very peripheral interest for him. then the package will age and eventually break. then someone else who is closer to debian will pick it up.
<wpwrak>
it all works magically. i never put much effort into aligning stuff with distros. when it gets used, they'll keep it in stock :)
<kristianpaul>
maintaing software is hard task for long run, sadly most of distro dont follow upstream work as openwrt i think it does
<kristianpaul>
that i think saves times
<kristianpaul>
not sure how really help or eventually may drop out some headaches (upstream fault?..)
<wpwrak>
depends a bit. some popular packages are in good shape. the more exotic ones with deep dependencies are the ones that tend to fall behind.
<wpwrak>
so i guess it's something like uptodateness = O(popularity/build_complexity)
<wpwrak>
e.g., kicad used to have troubles with this. basically all the distros only had ancient versions. but then, the build requisites are also quite hellish.
<kristianpaul>
wait may be git/svn/mercurial/bazaar will envolute/mutate some day in also a package management system
<kristianpaul>
that will really be helpfull for cases like kicad
<kristianpaul>
i think
<kristianpaul>
what a mess sofware is anyway :)
<wpwrak>
oh dear :-) not sure. there are a lot of dependencies those revision control systems don't know about. not that there wouldn't also be other used for having them understand such things a little, but oh the complexity ...
<kristianpaul>
yes i forgot that
<wpwrak>
(e.g. our schematics diffs would benefit from having proper inter-project dependencies. some day, it'll be necessary to add some hits to this system, so that it can at least loosely synchronize related projects.)
<wolfspraul>
I will start to collect bits and pieces there, slowly cleanup over time.
<wpwrak>
great, thanks
<wpwrak>
let's hope the mail wasn't too confusing :)
<wolfspraul>
no it's good
<wolfspraul>
we can only improve the system case by case
<wolfspraul>
then those cases set the precedent for the future, we see whether it still fits, or needs further specialization
<wpwrak>
yeah. component naming is nasty business. it's full of inconsistencies, implicit rules, and surprises.
<wolfspraul>
from all my experience in anything electrical and manufacturing, I'd say this is the way to go :-)
<wpwrak>
yeah. i don't know nearly enough for anything but the incremental approach :)
<adamwang>
wpwrak, agreed on full of inconsistencies, implicit rules, and surprises.
<wpwrak>
hehe :)
<adamwang>
i made wrong parts missed even swapped on Mlikymist One RC1/RC2 BoM.
<wpwrak>
i'm a little afraid that the high degree of automation in boom can cause trouble with bad specifications (e.g., incomplete names, overly specific names, and so on)
<wpwrak>
perhaps it'll be necessary to also keep boom output in repositories. that way, one can track what changes.
<wolfspraul>
let's work from top to bottom, starting in the schematics
<adamwang>
from latest status of boom. we know that this whole system can cover and overcome stupid mistakes made.
<wpwrak>
or maybe have some form of acceptance list. copy parts from the output to the list. then automatically compare new output with the list. if something changed too much, complain.
<wpwrak>
yes, it can work around lots of things. but it can also easily get mislaid. that's per se not so bad, because you ought to catch such things during review.
<adamwang>
um..i hope hackers work during developing sche, to do more precisely as possible even boom has not been became maturely.
<wpwrak>
(well, as long as you don't believe boom will just magically solve all your problems ;-)
<adamwang>
haha..:)
<wpwrak>
the missing bit is then simply to make sure any changes also get reviewed. since boom can change "spontaneously" (e.g., when prices or distributor stock change), we need some mechanism to record what has already been "seen".
<adamwang>
'review' is also unnecessary in the end! it takes time & cost.
<wpwrak>
not super-urgent for now, but something to keep in mind
<wpwrak>
yeah, right ;-)))
<adamwang>
yeah....so far now still need reviews.
<wolfspraul>
U4 is named as K8001
<wpwrak>
(no reviews) let's not waste a day reviewing if we can spend a month doing another run after having turned the previous one into a major bloodbath ;-)
<wolfspraul>
is that the same as KSZ8001L on Milkymist One?
<adamwang>
you probably know that it always can be changeable during pcb layout (e.g. : change footprint etc.), but forgot to update schematic in parallel.
<wpwrak>
one can tell andres wasn't too happy about making that BOOKSHELF file :)
<wolfspraul>
just sloppy as usual, honestly
<wolfspraul>
we'll sort it out
<adamwang>
wolfspraul, i haven't jump into checking all parts in Xue. It may probably messy there.
<wpwrak>
(k8001) another nice one: part number is KS8001 for leaded and KSZ8001 for lead-free
<wolfspraul>
yes but we want to specify lead-free
<wpwrak>
where do you guys find all those crazy ones ? ;-)
<adamwang>
I'd like any related part related similar to Milkymist One brd, we recommend Andres to use the same part.
<wolfspraul>
adamwang: oh it will be the biggest mess you have seen in a long time
<wolfspraul>
maybe we can clean it up, maybe not
<wolfspraul>
if I feel uncomfortable wasting my money in a failed run, then the run will not happen
<wolfspraul>
(with my money, but from my experience I'd say there are few people that can match me in craziness, so I doubt someone else will show up)
<wolfspraul>
having said that, let's start the cleanup :-)
<wolfspraul>
wpwrak: we find them because we have to find them to make a controlled run with actually successful boards
<wolfspraul>
big surprise :-)
<wolfspraul>
only in my testing the last 2 weeks I realized what a difficult board m1 is
<wolfspraul>
fantastic work by Sebastien and Adam
<adamwang>
that's what I see hackers on naming part in schematic..too short naming...more dangerous, too long on naming...waiting time on thinking from hackers
<adamwang>
how this big challenge on growing up boom system...is a long way to go and promote to list.
<wpwrak>
wolfspraul: (crazy parts) naw, it's pretty uncommon to have lead-free and such so early in the name. they usually put such things at the end. but we've now seen two in just a day.
<wpwrak>
(fantastic work) i agree. it's pretty impressive to get such a complex board right with so few runs
<wolfspraul>
yes but if we have to make a choice, let's specify lead-free and move on
<wolfspraul>
lots of work, spending the limited resources in the right places is very important
<wolfspraul>
wpwrak: yes but we have more complex boards to come, no? and ic tape-outs, which are entirely driven by testability, not features. that will be fun.
<wpwrak>
adamwang: (boom) the hard part are the interruptions it causes. you want to add something "simple" and then you realize that you should really add the whole class of parts. now, will you do it properly or not ? :) so the more short-tempered developers will need some cleaning after
<wpwrak>
wolfspraul: (lead-free) sure. the leaded one is probably a collector's item by now anyway :)
<adamwang>
ha:) of course agreed
<wpwrak>
wolfspraul: (driven by testability) what are you referring to ?
<wolfspraul>
the little I learnt about tape-outs so far is that the key driver in that process is whether you can test the results
<wolfspraul>
not the features
<wolfspraul>
that's because failure becomes exponentially more expensive as the process technology goes up
<wpwrak>
ah, i see. so that's the asics in ten years :)
<wolfspraul>
so the higher the process technology is, the more expensive failure gets, and in consequence (let's say for business that don't want to go bankrupt), the amount of time that goes into review, testing, preparing for testing, goes up exponentially as well
<wolfspraul>
it's quite simple actually, but some people seem to prefer bumping their head into the wall over and over and over again :-)
<wpwrak>
probably O(n^3) even
<wolfspraul>
adamwang: I want to show you something, not sure you have seen it before
<wpwrak>
one for the yield, one for increased cost of the process (assuming that per se is linear), and one for the higher probability of failure of a complex part
<wolfspraul>
when you push a commit into the repository, a 1-line commitlog will show up here
<adamwang>
whole class of parts yes we need to classify it.
<wolfspraul>
I just pushed a small fix in BOOKSHELF
<adamwang>
ha ...ok
<wolfspraul>
these links here help to communicate that people are working on
<wolfspraul>
so once you have committed something locally, it's a good idea to push early
<wolfspraul>
oh, I haven't added you to the xue members yet
<adamwang>
pls add, thanks.
<wpwrak>
wow, that's a heck of a URL. let's see if dsv survives it
<wpwrak>
yup, works :)
<wolfspraul>
done
<adamwang>
tks
<wolfspraul>
adamwang: you need to git clone xue again, this time with git@projects.qi-hardware.com:xue.git
<adamwang>
yeah...ok
<wolfspraul>
just delete the whole folder, then type "git clone git@projects.qi-hardware.com:xue.git"
<wolfspraul>
should we rename this to KSZ8001?
<wolfspraul>
K8001 seems bad, you cannot google it at all and even searching k8001 on the micrel.com site finds nothing
<wolfspraul>
no wonder the link went to a meaningless png :-)
<wolfspraul>
dsv names are case sensitive, should we just accept that and say that schematics references should be written capitalized?
<wolfspraul>
or should we add both capitalized and lower case nicks?
<wpwrak>
K8001 doens't exist. KS8001 or, better, KZS8001. the data sheet starts with "The KSZ8001 [...]" :)
<wpwrak>
naw, i'd just pick one style.
<wolfspraul>
agreed, I change the alias to KSZ8001 in BOOKSHELF
<wolfspraul>
I think case-sensitive and saying that the refs should be capitalized is OK
<adamwang>
i would like the system can recognize/realize either capitalized or lower case.
<wpwrak>
e.g., in bwn-wpan, all the names i expect to type are lower-case. some things have an upper-case "official name" and a lower-case alias
<wpwrak>
e.g., "AN032" with alias "regulations"
<wolfspraul>
how about schematics references?
<adamwang>
but design during developing sch stage, it probably good to keep the same work sync to the 'word' of datasheet.
<wolfspraul>
adamwang: I agree with Werner that it is better to have only one system, as long as we clearly communicate it.
<wpwrak>
dunno. they capital letter there doesn't add much of a burden and may help to keep things apart
<wpwrak>
the annoying ones are long all-caps names or names with many letters
<adamwang>
wow...
<wolfspraul>
sure we will lower case those
<wolfspraul>
how about schematics references?
<wolfspraul>
the reason I am leaning towards capitalization is that they always seem to be capitalized
<wolfspraul>
for example in the .lst bom file eeschema produces
<wolfspraul>
it's always C13, U1
<wolfspraul>
not c13, u1
<wolfspraul>
I think
<wpwrak>
i think capitalizing them is fine
<wolfspraul>
adamwang: you just have been out-voted 2:1
<wolfspraul>
:-)
<wpwrak>
i'd tend to lower-case most things i expect to input (for convenience), but capitalized component references don't look overly inconvenient
<adamwang>
:)...in schematic sheet  or BOOKSHELF...i agreed.
<wolfspraul>
oh great
<wolfspraul>
3:0
<wolfspraul>
even better
<wolfspraul>
done
<wpwrak>
hehe :)
<adamwang>
i was saying that hopefully the system can realized them..well...
<wpwrak>
also, i think we really ought to view the dsv names as quite local. dsv is most useful if you can do things like "dsv fpga" or "dsv antenna"
<wpwrak>
it's a tool that's should give the engineer quick access to information. every second counts ;-)
<wolfspraul>
agree
<wolfspraul>
adamwang: let me explain some background
<adamwang>
simply work on s/w work....then let hackers more works on 'right' keying process. :)
<wpwrak>
of course, this also means that there be no more excuses for not looking up things in the data sheet ;-))
<wolfspraul>
what you are asking for is 'case insensitive' matching, either by listing both U1 and u1 manually, or by having the matching done 'case-insensitive'
<wolfspraul>
when you say anything 'case insensitive', you may not create many new friends in the free software world
<wolfspraul>
they have a long history of saying that 'case insensitive' is bad :-)
<wpwrak>
case-insensitive as a rule isn't too bad an idea. but it's not the unix way, which makes me a bit reluctant.
<wolfspraul>
my #1 worry for Xue is that we basically have a 'random assortment' of chips, but no manpower to get the software to work
<wpwrak>
a broad mix is also bad for the inventory
<adamwang>
hmm..
<wpwrak>
the one in xue is smaller (32 Mbit vs. 256 Mbit)
<wolfspraul>
so I will be going after every smallest difference to m1, try to understand it, and if I have the feeling nobody will support the software for that difference, we either switch to using the same part as on m1, or I will not produce the board
<wolfspraul>
want to be very frank from the beginning. I am not interested in producing a board and 2 years later still struggle to boot it.
<adamwang>
will get pain on my site
<wolfspraul>
but I'm all positive about this, for differences that have a reason and we have software under control it's OK
<wolfspraul>
adamwang: you mean the xue flash chip?
<wolfspraul>
most likely I would think that the way it's addressed and programmed from the fpga is also different
<adamwang>
umm...we need to ask Andres and listen to him first
<wpwrak>
xue is also SPI while the other uses a cpu bus
<wpwrak>
quite different the two
<wolfspraul>
not surprised to hear that :-)
<wolfspraul>
like I said - random assortment of chips, worst case
<wpwrak>
does xue use the jtag adapter of m1 ?
<wolfspraul>
we need to clear that up
<wolfspraul>
no, it had to be different
<wpwrak>
ah, pity
<adamwang>
if the fpga on Xue  can be reconfigured as m1, and won't have too many changes, we should ask to change.
<wolfspraul>
no pity, just a bit more work :-)
<wolfspraul>
I think xue has a ft2232c, whereas m1 uses a ft2232h
<wolfspraul>
I vaguely remember 'h' = high-speed, but need to check
<wpwrak>
hmm, xue has two nands. one is spi the other has a NAND bus
<wpwrak>
the one in MM1 is a NOR
<wpwrak>
U5 also needs a better "value". "NAND" leaves quite a lot open to interpretation :)