lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs :: Something to do? https://github.com/milkymist/bugs/issues
Thihi has joined #milkymist
cladamw has joined #milkymist
<cladamw> good morning :)
<wolfspraul> morning
<cladamw> wpwrak, nice mockup !
<cladamw> morning
<cladamw> wolfspraul, do you like that idea ?
<wolfspraul> well I still don't get it, frankly
<wolfspraul> which type of header is on the m1 pcb ?
Jia has joined #milkymist
<cladamw> (J24) currently it's a 2*5 male header with one key. so from mockup shows that need a very small pcb with one female (2*5 receptacle header) and one USB-A receptacle mounted.
<wolfspraul> why do we need that?
<cladamw> J24 is on M1r4 for original internal usb ports E/F
<wolfspraul> I don't even understand what is being discussed and why :-)
<wolfspraul> the 2 internal USB headers are *internal*, we said we want the keyed 2*5 male header
<cladamw> do you mean why we needed internal usb ports header ?
<cladamw> yes, we discussed for a 2*5 male header with one pin keyed. so ?
<wolfspraul> and that's it, no?
<wolfspraul> we are trying to think ahead where to position that header?
<wolfspraul> yeah so?
<wolfspraul> I don't know
<wolfspraul> what is being discussed now?
rejon has joined #milkymist
<cladamw> referenced to J24 which is placed curretly right of DMX TX con. : http://downloads.qi-hardware.com/hardware/milkymist_one/pcb/r4/041012/MILKYMISTONE.pdf
<cladamw> there's with limited space to even plug into 2*5 header if we still have a plan with an extendable usb cable. so 1) hard to plug in 2) don't know how exactly mechanical requirements(space, e.g. a real cable spec.) to plug
<wolfspraul> and?
<cladamw> so i spoke up to Werner that where we should place J24.
<cladamw> then seems yes that we haven't worked out /or found a real usb cable, so J24's problem raised up.
<wolfspraul> I just don't think there is a problem in the first place
<wolfspraul> it seems we are looking for some extra work to do
<wolfspraul> an easy solution is to remove the 2 internal usb
<wolfspraul> all other options are totally hypothetical
<wolfspraul> we don't like the position because we don't know what will be plugged into it !?
<wolfspraul> just think about that for a moment
<wolfspraul> if we don't know what will be plugged into it, then... :-)
<wolfspraul> we can leave the header in that corner there, or if we don't like this just remove altogether and worry about it later
<wolfspraul> lemme look at werner's pics again
<wpwrak> wolfspraul: why are you suddenly against that header ?
<wpwrak> one use case we discussed was for an RF dongle. like the one used by the rii keyboard
<wolfspraul> I'm not against it, I try to unwind the arguments
<wolfspraul> it seems we jump from problem A to solution B to problem C to solution D
<wolfspraul> and so on
<wpwrak> when discussing how to connect things to this header, you brought up the easy to source cables
<wolfspraul> then we have this whole stack, but it's all hypothetical
<wolfspraul> sure I am always looking around a little
<wolfspraul> is this still the latest proposal? http://downloads.qi-hardware.com/people/werner/m1/tmp/iusb-doodle.png
<wolfspraul> so you move the header behind the upper usb?
<wpwrak> therefore, we didn't move forward on the remaining parameters of the interenal USB solution (mainly mechanical)
<wolfspraul> that looks good if it fits
<wolfspraul> I just want to avoid that we go down in a spiral of reasoning away from real value
<wolfspraul> a very good example is "we don't like the position because we don't know what will be in there"
<wolfspraul> so the problem is not the position
<wolfspraul> the problem is that we don't know what goes in there :-)
<wpwrak> now, if we combine the use case with the state of the header, there's a mismatch: if we want to make use of it, and the rii dongle seems ideal, then we need to reach a conclusion about how to make the connection between header and dongle
<wolfspraul> that url from you, is that the latest proposal?
<wpwrak> (latest proposal) yes
<wolfspraul> and what is the problem with that idea?
<wpwrak> it needs agreement :)
<wolfspraul> makes perfect sense to me, if it fits
<wolfspraul> well sure, what are the downsides compared to the one with header on the side?
<wpwrak> very good. we're making progress ;-)
<wolfspraul> if none: take it :-)
<wolfspraul> any known downsides?
<wpwrak> it may make the layout folks sweat a little more
<wpwrak> but only a little :)
<wolfspraul> but not much, yes
<wolfspraul> there is space in the dmx area i believe
<wpwrak> you won't notice amidst the buckets of sweat DVI should cause them ;-)
<wolfspraul> right
<wolfspraul> cladamw: when you compare solution A and solution B, what is *worse* in solution B?
<wolfspraul> A is the one in your PDF
<wolfspraul> B is the one in werner's drawing
<wolfspraul> A = near the edge
<wolfspraul> B = between external USB and dmx chips
<wpwrak> part two of the question: shall we plan to make such an adapter board to be available simultaneously with M1r4, e.g., included in the package, maybe even pre-installed ?
<wolfspraul> adapter board?
<wolfspraul> we ship with a 2*5 male header, that's by far enough I think
<wpwrak> since we don't have a cable :)
<wolfspraul> it won't affect sales on tiny bit as far as I can tell, either way
<wpwrak> but you can't connect the rii dongle to the header
<wolfspraul> those are all just random 'for developer' features
<wpwrak> it's more a "no parts sticking out" feature
<cladamw> worse of A is the difficult scenario would be same as jtag/serial cable to plug, it's mechanical issue. for layout , actually A would be easy.
<wolfspraul> no definitely not. the dongle is tiny and can easily be on the outside
<wolfspraul> the work to move it inside is so much, it just makes no sense *now*
<wpwrak> it's just an adapter board away :)
<wpwrak> but okay, let's wait for the first complaints then ;-)
<cladamw> worse of B is layout, seems (port e/f will cross together with else ports). Too close, I didn't against on this, since I leave this task to let house work out.
<wolfspraul> cladamw: yes but I think the routing of option B is also not too difficult
<wolfspraul> I mean just from the distance
<wolfspraul> maybe the dmx chips can be moved to the left a little
<wolfspraul> and the fallback is to move the header to the edge (option A)
<wpwrak> cladamw: we can also consider using an SMT variant of the header instead of through-hole. that would reduce the impact on routing
<wolfspraul> because the whole reason of moving it still seems a little hypothetical
<wolfspraul> but then you could also argue for removing it, of course
<wolfspraul> difficult to design features with no known use case :-)
<wpwrak> see above :)
<wpwrak> i'll definitely keep my RF dongle on the inside :)
<wpwrak> there's already way too much stuff poking out of M1
<wolfspraul> cladamw: so let's try werner's placement first
<wolfspraul> see what happens
<cladamw> wolfspraul, WORNG, B's routes(ports e/f) will cross heavily to ports c/d. But i agreed that to change to a smd type connector, just need to find it.
<wolfspraul> ok]
<wolfspraul> sorry that I was a little slow in understanding the issue
<wolfspraul> so are we in consensus now?
<cladamw> wolfspraul, wait a moment, let me chat with werner more. :-)
<cladamw> wpwrak, since routes from fpga from here design files, i can see (e/f, J24) >> (c/d, J20) >> (a/b, J16), they(routes) will routed clockwisely.
xiangfu has joined #milkymist
<cladamw> this means even e/f set(two ports) goes bottom, c/d can go internal layer, a/b can go top layer when they reach closely to its connector.
<wpwrak> we can reorder the pins as long as the ones of M1rc3 end up on an external connector
<wpwrak> (pins) FPGA pins
<cladamw> i'm think to try precisely pick what type of connector to prevent such potential messy routes(cross).
<wpwrak> if e/f goes to the bottom, that would suggest that we keep the through-hole connector ?
<wpwrak> otherwise, they should be on top. at least near the connector
<cladamw> like combination: type of J24[smd, through] vs J20[smd, through], J16[smd, through]
<cladamw> man! my brain is messy up, need a calm brain now. :)
<cladamw> wpwrak, wait me for a while. i study a little.
<wpwrak> seems difficult to find a keyed version of the SMT header
<wpwrak> through-hole would of course also be better for mechanical reasons
<wpwrak> ah, and i think it would be okay to have J24 some distance away from the other USB connector. it doesn't have to be as close as i've shown in the doodle or the mockup. so there would be some room for routes
antgreen has joined #milkymist
<cladamw> after calm my brain, now, let's keep the current type through of usb connector, and through hole J24. haha.. :-)
<wpwrak> sounds good to me :)
<cladamw> just illustrate big rough route rule for house, then else let house to overcome.
<wpwrak> yeah. shouldn't be too nasty. the parts on the bottom of the PCB can certainly be moved away, so there's room
<cladamw> btw, so all usb routes from fpga to usb transceiver will all goes internal layers to get strong ground shielding noise mask. :-)
<wpwrak> heh :)
<cladamw> alright, thanks all chats for solving this place problem and also came out a right-angle potential daughter board for RF dongle. ;-) Don't you ?
<cladamw> wpwrak, okay. so i keep working. ping me once you have another discovery.
<wpwrak> the RF dongle should be very easy. i'm just undecided whether to make it SMT for reduced length or though-hole :)
<cladamw> wpwrak, btw, could you draw your atusb dimension roughly so that I can let house to illustrate its suitable visible rectangle block once you decided. Even this is an option use case for m1r4.
<cladamw> i meant liked you did for expansion's dimension.
xiangfu has joined #milkymist
<cladamw> nice, but no length of usb plug ?
<cladamw> the text of 37.6 mm and 17.3 mm you edited by KiCad or else tool ?
<wpwrak> that's kicad, yes
<cladamw> i need to learn.
<wpwrak> i think it's all manually drawn :)
<wpwrak> i don't seem to have any drawing with the connector size :-(
Ladislas has joined #milkymist
<wpwrak> the overall length of my mockup, from antenna to the pins of the USB receptacle (!) is 61 mm
<wpwrak> add maybe 7 mm for the header. so that's ~68 mm total length of adapter board plus atusb
<cladamw> no rush on exactly right length, later you can figure out how to draw.
<cladamw> nice a rough ~68 mm is ref. :-)
<wpwrak> bt let's not make too much out of this - atusb is just a random example
<cladamw> sure.
<wpwrak> i picked it because it's relatively large, larger than the usual USB dongles
<cladamw> since I just need centerize that J24's position, don't want to get surprise later once m1r4 assembled then your atben collides DMX-TX con. or else. :-)
<wpwrak> keep maybe 2 mm of clearance left and right
<wpwrak> USB dongles can be a bit wider than the header, but not much
<wpwrak> now, if i could just find the rii rf dongle, i could tell you how wide that one is exactly ...
<wpwrak> hmm. i'd say, as close to U15 as possible
<wpwrak> preferably without any components between J24 and U15
<wpwrak> then even the nastiest USB sticks i have should fit
<wpwrak> so just shift J24 a bit more to the south and it's perfect
<wpwrak> "nice" dongles won't need all that much space. but some nasty big ones might. of course, the one i used for that measurement is some 15 years old, i think ;-)
<wpwrak> can't find my rii dongle :-( which of course just proves my point that such things are way too easy to lose ...
<cladamw> yeah...i just noitced that J24 needs to close to south. And routes(A/B) may be changed on bottom, E/F goes through Top.
<cladamw> wpwrak, no worries now, I have rii dongle and atben here. :-)
<wolfspraul> atusb
<cladamw> yes, i said wrong, atusb.
sh4rm4 has joined #milkymist
<wpwrak> even better :)
<wolfspraul> wpwrak: how is your flu btw? feeling better?
<wpwrak> wolfspraul: today wasn't so bad. but it's not defeated yet.
<wolfspraul> ok, rest well
<wolfspraul> it seems the kicad schematics is moving nicely
<wolfspraul> even though mostly adam charging ahead, but that's great
<wolfspraul> then bom, then maybe we try to copy over the layout right away too? just as an experiment? I have this urge to try kicad layout more :-)
<wolfspraul> but one by one... :-)
<wolfspraul> maybe we can at least import the gerbers, and start to grasp the layout problem a little
<wolfspraul> that way we can expose bugs or other realizations in kicad that may come hurt us later
<wpwrak> layout need the footprints first. and yes, you can import gerbers .. but that's not much use because you still don't have the connectivity
<wolfspraul> yes I understand
<wolfspraul> but we can start diving into that, as opposed to keeping this big black box
<wolfspraul> btw I was smiling the other day reading a book about IC manufacturing
<wolfspraul> at the end they talked about packaging
<wolfspraul> and at the very end (last 2 pages) they talked about "2nd level packaging"
<wolfspraul> with which they meant the entire pcb! :-)
<wolfspraul> I like it when a problem suddenly shrinks conceptually
<wolfspraul> that whole board is just the 2nd-level packaging anyway
<wolfspraul> the case is the 3rd level packaging
<wolfspraul> the box the 4th level
<wolfspraul> and the store it's sold in (not yet) the 5th level?
<wolfspraul> the cloud must be the 6th level then
<wpwrak> ;-)
pablojavier has joined #milkymist
<wolfspraul> I was trying to understand something conceptually about the fpga
<wolfspraul> so the basis of the fpga are lookup tables
<wolfspraul> why can't the synthesis tool extend this concept say to the nor chip we have?
<wolfspraul> why can't part of the truth tables be outsourced to nor, yet still be part of the digital machine that runs primarily in the fpga?
<wolfspraul> same for sdram
<wolfspraul> is this primarily a limitation of the synthesis tools, or is there some reason nobody would want that anyway?
<scrts> interconnect speed and latency
<wolfspraul> but conceptually one could design a machine that goes beyond the fpga chip and includes the nor or sdram?
<wolfspraul> so the reason to not do that is speed, or lack of advantage for a design at hand?
cladamw has joined #milkymist
xiangfu has joined #milkymist
elldekaa has joined #milkymist
<qi-bot> The firmware build was successful, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120411-0642/
Martoni has joined #milkymist
xiangfu has joined #milkymist
elldekaa has joined #milkymist
<GitHub114> [scripts] xiangfu pushed 1 new commit to master: http://git.io/BgmOhA
<GitHub114> [scripts/master] add compile-milkyminer-firmware.sh - Xiangfu Liu
<lekernel> wolfspraul: this is called a CPU
<lekernel> and it's slow
xiangfu has joined #milkymist
<qi-bot> The firmware (using branch) build was successful, checkout the VERSIONS for detail, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120411-0828/
cladamw has joined #milkymist
rejon has joined #milkymist
<GitHub6> [board-m1] xiangfu pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/2a3f64abdd491bbe149f67c72f9340df364b1da8
<GitHub6> [board-m1/master] add Milkymist components - Xiangfu
<GitHub171> [board-m1] xiangfu pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/7f80878d79f2eccfaf49f616c8760905e150dcee
<GitHub171> [board-m1/master] add NORFlash components - Xiangfu
<GitHub177> [board-m1] xiangfu force-pushed master from 7f80878 to 2f81c3e: https://github.com/milkymist/board-m1/commits/master
<GitHub177> [board-m1/master] add NORFlash component - Xiangfu
<xiangfu> when I add the NORFlash component. all .sch files changed.
<cladamw> xiangfu, hehe ... :-)
<xiangfu> I guess it should be ok. :)
<cladamw> xiangfu, bravo ! Your first schematic editing. :-)
<GitHub156> [board-m1] xiangfu pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/0581cff297b7945aae69abf9dec4ab9499eb7ae6
<GitHub156> [board-m1/master] NORFLAH: add FLASH bus - Xiangfu
Martoni has joined #milkymist
<GitHub113> [board-m1] xiangfu pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/c0513f06b1e0a8411a6d03c82f5954baa3a85b61
<GitHub113> [board-m1/master] NORFLAH: add FLASH D bus - Xiangfu
<GitHub133> [board-m1] xiangfu pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/36a8d6c1577448f0d359420ba85b1cfbbc4a0d05
<GitHub133> [board-m1/master] NORFLASH: fix the label name, adjust the flash bus - Xiangfu
<GitHub28> [board-m1] xiangfu pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/4d339a5ddf5221797d4ee9967a49e77fe0aea770
<GitHub28> [board-m1/master] NORFLASH: add gobal labels - Xiangfu
<wolfspraul> lekernel: hmm, thanks! [cpu]
<wpwrak> xiangfu: you can use "save current sheet only" to avoid updating all the other sheets
<wpwrak> xiangfu: kicad has the annoying habit of keeping timestamps inside its files, and to update them all the time. so if you don't actively avoid this, you get lots of changes that aren't really changes.
voidcoder has joined #milkymist
<GitHub36> [board-m1] xiangfu pushed 3 new commits to master: https://github.com/milkymist/board-m1/compare/4d339a5...5dd3e7f
<GitHub36> [board-m1/master] NORFLASH: add local labels, there is no A8 under JS28F256J3F105 - Xiangfu
<GitHub36> [board-m1/master] NORFLASH: update with correct JS28F256J3F105 - Xiangfu
<GitHub36> [board-m1/master] NORFLASH: finish FLASH_D local labels - Xiangfu
<xiangfu> wpwrak, yes. I just found that. but Ctrl + S is common. sometime just press that.
<xiangfu> :-)
<xiangfu> wpwrak, should be a shortcut for "save current sheet only" :)
<wpwrak> you can submit a patch. see if they like it :)
<wolfspraul> better fix the file format
<GitHub167> [board-m1] xiangfu pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/75880101063d59a402e1bc67e9d0b366b35d71ac
<GitHub167> [board-m1/master] NORFLASH: more wires - Xiangfu
<wpwrak> may be hard to convince people to stop doing that timestamp nonsense. but yes, we can try ...
<wpwrak> it may be one of those "we had to do this on the PDP-11 because the operators often forgot to set the time after resetting the system" things ...
<xiangfu> wpwrak, very easy to get dizzy when I watch so much parallel wires in KiCAD :-D
<wpwrak> it takes some getting used to :)
cladamw has joined #milkymist
cladamw has joined #milkymist
Jia has joined #milkymist
<wolfspraul> that is hard to explain? urgh
<wolfspraul> it breaks *any* concept and meaning of revision control systems
<wolfspraul> as if they all had never heard of such an invention?
<wolfspraul> it creates completely unnecessary merge conflicts in collaborative distributed teams
<wolfspraul> 'open source' anyone?
<wolfspraul> well, scarily you are probably right, so I won't try to explain it either :-)
<xiangfu> wolfspraul, confuse. you mean the " kicad has the annoying habit of keeping timestamps inside its files" ?
<wolfspraul> yes, just ranting :-)
<wolfspraul> actually we should not get dragged into too many kicad bugs, just use the tool...
<wolfspraul> I was just ranting because timestamps inside a file are such an obviously bad idea :-)
<xiangfu> agree.
<wolfspraul> (this kind of timestamp in this kind of file)
<wolfspraul> but just workaround, manually revert changes where only the timestamp has changed
<wolfspraul> otherwise the revision history gets cluttered
<xiangfu> I can do a 'rebase' now fox fix that.
<xiangfu> that needs git push -f.
<xiangfu> better start from now. use "save current sheet only"
<xiangfu> rebase is a little bit time consume. :(
<wolfspraul> sure, what's in the history now doesn't matter, now you know this detail with the timestamps and going forward can find an easy solution
<Fallenou> push -f is evil
<Fallenou> really don't do this
<Fallenou> unless you really don't care that someone who has already cloned your repository has to rm -rf and reclone again
<xiangfu> Fallenou, and dangerous
<xiangfu> what is the different on 3.3V and 3V3. is that same?
<xiangfu> +3.3V and 3V3.
<wolfspraul> it means the same thing but that's one of the many details we are trying to standardize/document better
<wolfspraul> there probably should be a README or STYLE-GUIDELINE document or so in the schematics
<wolfspraul> then we can merge stuff like this into it, and remove from the wiki http://en.qi-hardware.com/wiki/Copyleft_Hardware_Style_Guide#Values_and_Units_in_Schematics
Jia has joined #milkymist
<xiangfu> sounds good
<GitHub41> [board-m1] xiangfu pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/e5a760334eb1ca738f204f3b1b3868d688814039
<GitHub41> [board-m1/master] NORFLASH: add GND and TP - Xiangfu
<GitHub96> [board-m1] xiangfu pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/4e1622e533eb0f0290185040950f0fce69dc2d8f
<GitHub96> [board-m1/master] NORFlash: finish NORFlash - Xiangfu
<GitHub197> [board-m1] wpwrak pushed 1 new commit to master: https://github.com/milkymist/board-m1/commit/73949be6c94d86e8463cd4da25e4957fb0d95046
<GitHub197> [board-m1/master] r4/m1.pro: added ../../kicad-libs/... to LibDir - Werner Almesberger
voidcoder has joined #milkymist
roh has joined #milkymist
hypermodern has joined #milkymist
Gurty` has joined #milkymist
kilae has joined #milkymist
hypermodern has quit [#milkymist]
Alarm has joined #milkymist
elldekaa has joined #milkymist
green` has joined #milkymist
kilae has joined #milkymist
voidcoder has joined #milkymist
<sh4rm4> note the link at the bottom "web us at - milkmymist.in"
elldekaa has joined #milkymist
<lekernel> wpwrak: we have the room for 28-30 december
<lekernel> :)
<wpwrak> whee ! congratulations !
Thorn has joined #milkymist
roh has joined #milkymist
azonenberg has joined #milkymist
voidcoder has joined #milkymist
<wolfspraul> Sebastien will love this - the USB standards will be extended to support all sorts of power profiles up to 100W, at 5V, 12V or 20V - all negotiable between devices :-)
<wolfspraul> one neat thing about a 'standard' is that the user knows "this will just work". "ah, it has USB, so I can use it over here..."
<wolfspraul> but with such a huge range of power profiles, lots of combinations won't work anymore if this standard really becomes widely used
<wpwrak> it'll be a royal mess, with the corresponding pain levels
<wolfspraul> good thing that the general trend of low power is intact, so hopefully those power profiles won't become widely used
<wpwrak> particularly because the higher wattages also increase the voltage :)
<wolfspraul> sure, total mess
<wolfspraul> and like I said, you will have a situation where you first think you can plug device A into B, but then you realize "no, doesn't work"
<wolfspraul> and there are so many combinations that it is essentially impossible to predict whether it will work or not unless you plug in and try
<wolfspraul> a host that can implement *all* power profiles is more like a smart power supply and switch than anything else
<wolfspraul> so many device makers, say like m1, will give a damn about those X power profiles :-)
<wpwrak> yeah, it'll get nasty once there are holes in the set. i.e., if it's not just profiles 0-5, but 0, 1, 4, 5+ :)
Jia has joined #milkymist