Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
xiangfu [xiangfu!~xiangfu@114.247.10.75] has joined #milkymist
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
xiangfu_ [xiangfu_!~xiangfu@114.247.10.75] has joined #milkymist
sh4rm4 [sh4rm4!~sh4rm@gateway/tor-sasl/sh4rm4] has joined #milkymist
cladamwa [cladamwa!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
cwoodall [cwoodall!~cwoodall@comm575-0301-dhcp011.bu.edu] has joined #milkymist
<cwoodall>
Hello, I got an email about making an FPGA MMU and was told to come to IRC to chat
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
qi-bot [qi-bot!~qi-bot@turandot.qi-hardware.com] has joined #milkymist
Martoni [Martoni!~chatzilla@ip-167-165.evhr.net] has joined #milkymist
<wolfspraul>
what memory bandwidth can the Milkymist SoC achieve right now?
<cladamw>
wolfspraul, , hi good morning !
<cladamw>
Is qi server down now?
<cladamw>
I need to upload files. ;-)
<wolfspraul>
cladamw: it was down earlier, but how about now?
<cladamw>
mmm...good now it's okay
<wolfspraul>
good morning
<wolfspraul>
last day before holiday? :-)
<wolfspraul>
you deserve your holiday!
<cladamw>
oah...yes, i just revised R4 about LEDs multiplexing matrix from Werner.
<cladamw>
so moments...
<wolfspraul>
cladamw: we plan to make it possible to disable the power led from software
<wolfspraul>
do you have that already?
<wolfspraul>
the proposal is somewhere in the backlog
<wolfspraul>
I mean the technical proposal
<cladamw>
yes. i saw that keeping D1 ~ D3 but maybe move D1 to power supply source.
<wolfspraul>
not just 'move', but the idea is that software can disable it
<wolfspraul>
for that we need to do some extra electric circuitry
<cladamw>
and Werner thought current D2 and D3 are good to be as indicator of status of booting or reconfiguration.
<wolfspraul>
if in a totally dark room, someone wants to turn *off* all leds
<cladamw>
yeah...
<wolfspraul>
I think we can remove one of the two (D2/D3), but let's wait for Werner on this
<wolfspraul>
Werner is making experiments, we should follow the results of those, I think
<cladamw>
so I currently doesn't touch exsiting D1 ~ D3.
<wolfspraul>
D1 is special
<wolfspraul>
D1 cannot be software controlled right now
<wolfspraul>
correct?
<cladamw>
we can surely move which one is to somewhere easily later. ;-)
<wolfspraul>
and we want to keep D1, 'power' led - it's good
<wolfspraul>
I am not talking about 'moving'
<wolfspraul>
I am talking about making it possible for software to disable D1
<cladamw>
yes, D1 is not controlled by s/w now.
<wolfspraul>
yes but we want to make that possible
<wolfspraul>
at least to turn it off, override it's natural state
<wolfspraul>
let me see whether I can extract the technical proposal from the log
<cladamw>
yeah....okay..do you want me to revise it again now. hehe... should be no problem
<wolfspraul>
that's unrelated to the other leds
<cladamw>
since D1 is directly driven by 3V3
<wolfspraul>
D1 is a special case
<cladamw>
yes, i know
<wolfspraul>
so I think we can settle that one first
<wolfspraul>
and yes, make it possible for software to disable it
<wolfspraul>
I have yet to hear someone who says that that is a bad idea
<wolfspraul>
so let's do it (cause I think it's a good idea :-))
<cladamw>
in order to give a remotely control also as indicator, so I have to pull one un-used fpga pin to that D1 then we have s/w control and indication feature
<wolfspraul>
wait Werner wrote something, I'm searching it
<cladamw>
but don't know if Werner still want a hardware indicator from direct from 5V or 3.3V. ;-)
<wolfspraul>
we want a hardware indicator
<wolfspraul>
but we want to make it possible to override the on status
<wolfspraul>
if m1 is a box for video artists, they surely may want to control what kind of light it emits
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
<cladamw>
yeah
<wolfspraul>
and not have a bright green forcefully shining upon them - that may be annoying in *certain* (rare or not) situations
<wolfspraul>
so since we work in leds now, let's make it possible for software to turn off D1 manually (overriding it's natural power function)
<cladamw>
okay...overriding needs think a little...;-)
<wolfspraul>
cladamw: not sure now. reading about pullups/npn or equivalent fet
<wolfspraul>
confirm with Werner
<cladamw>
btw, multiplexing matrix: Those are for connectors:
<wolfspraul>
the idea now is that D1 stays the way it is directly from 3V3 power, but in addition it's possible for software to disable it
<cladamw>
<cladamw>
DMX TX/RX, MIDI TX/RX, IR, DVI-I, LINE IN/OUT, VIDEO-IN R/G/B, MEMORY CARD, USB A~F, didn't include MIC now.
<wolfspraul>
oh MIC - good point
<cladamw>
wolfspraul, okay
<wolfspraul>
did we forget about mic before?
<cladamw>
yes, i didn't add MIC before. ;-) just add this morning.
<cladamw>
also included LINE-IN/OUT.
<cladamw>
so maybe we now think more to if needs MIC from saving other.
<wolfspraul>
we wait for Werner on this
<wolfspraul>
I know it's your last day before the holidays, but then next week we have time to review and think, usb, leds, expansion
<wolfspraul>
so maybe the best you can do is if you post a complete schematic PDF, then we have one reference point next week?
<cladamw>
let's uploading newest sch one. so can easily communicate
<wolfspraul>
yes
<wolfspraul>
btw for this type of draft schematic, it would be good if there was a datecode clearly visible on each page
<wolfspraul>
then we have some hope that even later we can still reference discussion and PDF together
<cladamw>
the newest one has not fixed D1 with overriding feature.
<cladamw>
letme see pullups/npn/fet idea...;-)
<wolfspraul>
no rush on the leds, I think the entire led thing is not settled yet
<wolfspraul>
what is still open right now? 1. expansion 2. led
<wolfspraul>
everything else is clear?
<cladamw>
yes, i think so. like wish to change Y1, find other candidate DVI-I connector, F2 PTC new p/n to determine, etc...
<cladamw>
i all record in email firstly.
<cladamw>
the F2 spec needs to be changed since 6 usb ports now ( 6* 0.5mA + 1.0A = 4.0A)
<wolfspraul>
yes, F2 - understood
<wolfspraul>
although werner thinks that 2.0A for all USB is enough, he can tell you more about this
<wolfspraul>
we don't want to overload and overengineer the board
<wolfspraul>
smaller Y1 - always good. in general I always prefer smaller, we just have to watch that we are still sourcing easily available parts, and price doesn't go up too much
<wolfspraul>
and our time to find that smaller Y1 and test it also needs to be considered
<wolfspraul>
cladamw: btw, whenever Werner has finalized the led proposal, do you think we should test the design? or can we directly test in the run?
<cladamw>
yeah. such things as task to test/verify later we pick a real p/n.
<wolfspraul>
also remember that we plan to use boom more for R4 sourcing, not sure to which degree we want to or will automate the selection of crystals...
<cladamw>
wolfspraul, good question on this. I also thought up this. even it's simply implemented by passive parts(led and resitors).
<cladamw>
in M1preR4 we have now two can do this experiment via J21 header firstly. ;-)
<cladamw>
3 column plus 3 row pins can do this multiplexing matrix idea.
<wolfspraul>
I think it also depends on Werner's testing
<wolfspraul>
remember that Werner is testing already
<wolfspraul>
so if he says he is sure it works, we can skip a second verification
<cladamw>
I think that we have to do this experiments firstly by s/w through M1preR4.
<wolfspraul>
let Werner make the first step, then we find out what we have to add
<cladamw>
mm.. don't know how he soldering wire or test each led step-by-step?
<cladamw>
okay
<wolfspraul>
we don't need to test the same simple idea several times either
<wolfspraul>
only because we are working remotely...
<wolfspraul>
but it probably should have been tested somewhere, once
<cladamw>
since the matrix routing in R4 will broadcast in everywhere corner on pcb. hope I don't get surprise in real R4. ;-)
<wolfspraul>
what specifically are you worried about?
<cladamw>
since the matrix idea could be implemented by s/w like scan codes methods, in other words it's not purely DC level, so means variant frequency may on each net of 6 wires.
<cladamw>
i don't know if it will use scanning codes or PWM method to give "Persistence of vision
<cladamw>
" on light.
<cladamw>
should be alright.
<cladamw>
I'll ask wpwrak ;-)
lekernel_ [lekernel_!~lekernel@f052071251.adsl.alicedsl.de] has joined #milkymist
<wolfspraul>
cladamw: reading through your mail
<wolfspraul>
about USB test points - yes, not too many test points
<wolfspraul>
adding test points is nice, but we should also remove once in a while
<wolfspraul>
ask yourself: which ones have you really been using? can we remove some of the others?
<wolfspraul>
removing is harder than adding...
<wolfspraul>
but more worthwhile, often
lekernel [lekernel!~lekernel@f052071251.adsl.alicedsl.de] has joined #milkymist
<cladamw>
this time when surely we have unqualified chip then I always used to meauring TP then i know directly if chip failed. it's easy for me. so surely i'd like they are still there ! but now usb circuit in m1 have already matured. so _IF_ house they 'feel' not good, then we directly remove all TPs but still reserve only ONE set of test points.
<wolfspraul>
wait wait ;-)
<wolfspraul>
my point was: there is an action/thought that triggers adding a particular TP
<wolfspraul>
but which action or thought triggers removing a particular one?
<wolfspraul>
so periodically we should review the ones we have, and quite simply if you remember not having used a TP for a long time, maybe it's a good idea to remove that one?
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
<wolfspraul>
but don't wait until the board is totally crowded and then suddenly remove all. that doesn't sound too good either.
<wolfspraul>
this is just my thinking reading what you say about USB test points
<wolfspraul>
which I agree with - not too many in advance, not good
<wolfspraul>
wasteful, and can cause problems
<cladamw>
four TPs in one usb port is all good for me: OE_N, _RCV, VP, VM which is better than I probe directly on pins of chip.
<wolfspraul>
sure, I'm just explaining my thinking
<wolfspraul>
we are working on a product, not a devel board
<wolfspraul>
so integrate integrate integrate
<wolfspraul>
TPs are good, they come and go, as the product matures
<wolfspraul>
if there is a thought behind a TP, it's a good TP
<wolfspraul>
but if they are sprinkled all over without any use or idea behind them - not good - remove
<cladamw>
All impedance to four TPs nearby usb transceiver are M ohm level. If it's not reachable, then usb port would not work well. i recorded there was to remind myself to cancel them except reserve one set when cowork with house.
<cladamw>
i surely already guessed that high potential possibility will remove out them when thinking them totally crowed. ;-)
<cladamw>
no problem, i just recored actually for myself. ;-) But your points are also good inputs. :-)
<wolfspraul>
cladamw: I think the current consensus is that we want to keep at least one switch of SW1-3
<wolfspraul>
one is minimum
<cladamw>
okay ;-)
<cladamw>
now i realized that overriding by fet, letme draw a draft Misc.SchDoc, then confirm Werner. ;-)
<wolfspraul>
good
<wolfspraul>
dvi-i hotplug - quite important to get it right imho
<wolfspraul>
in fact, talking about hotplugging - if we can do anything to enable the detection of plug-in events on other connectors - great
<wolfspraul>
so in software right now, can we detect cable insertion or removal of: line in/out, vga, ethernet, video-in, midi, dmx, usb?
<wolfspraul>
if not - we should
<cladamw>
(dvi-i hot plug) sure, now I don't know. ;-)
<wolfspraul>
yes, I just give feedback saying that to do insert/removal detection right may be very valuable later on
<wolfspraul>
how about the others - can we detect in sw?
<wolfspraul>
ethernet - probably can
<wolfspraul>
usb - probably can
<wolfspraul>
line in/out, vga, video-in, midi, dmx ?
<wolfspraul>
don't know
<wolfspraul>
we should have a barcode sticker with the serial number glued on each board
<cladamw>
(insert or removal detected by connector) yes, but connector type needs to be different one not the one we have now. or needs to add parts to get function works. then becomes overload and overengineer the board again. ;-)
<wolfspraul>
no overengineer
<wolfspraul>
the ability to detect insertion/removal can make a dramatic difference on later product behavior
<cladamw>
i was thought the led functions are: states: 0) unused (off), 1) ready for use (e.g., permanently on), 2) error (fast regular blink), 3) in use (activity blink)
<wolfspraul>
yes let's work on led first
<cladamw>
do all these trying to 'react' current led work and show them. but yours (auto detect on inserting/removing) relying on h/w itself. ;-) like smart Werner solved in matrix way through very few parts.
<wolfspraul>
let's worry about insertion detection later
<wolfspraul>
it may already work on some ports, and even on the others, if we feel worthwhile, let's finish led work first now
<wolfspraul>
and expansion system
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
wpwrak_ [wpwrak_!~werner@94-163-231-201.fibertel.com.ar] has joined #milkymist
wpwrak [wpwrak!~werner@94-163-231-201.fibertel.com.ar] has joined #milkymist
<wpwrak>
wolfspraul: (45 mm) that's roughly the distance i get when assuming a reasonable placement for J22
<wpwrak>
wolfspraul: (stacking) we'll specify the maximum height of the expansion board. what you do with this height is your choice :)
<wpwrak>
(ptc) there a is a better proposal, i think from lekernel: just duplicate the input protection circuit. so after J11, you would have (F2, D14, etc.) and (F2b, D14b, etc.)
<wpwrak>
(ptc) the F2 branch would be as it is now: supply the internal circuit and two USB ports
<wpwrak>
(ptc) the F2b branch would supply for more ports. that way, each branch is <= 2 A
<wpwrak>
(led matrix testing) ah, lemme commit what i did yesterday ...
<wpwrak>
(usb test points) fwiw, i used pretty much all of them on one port and some of them from the other
<wpwrak>
(usb tps) so i think that, for debugging, we'd want at least two full sets on external ports
<wpwrak>
LEDs: i took some pictures yesterday. lemme prepare them for upload ...
<wpwrak>
in general, there are many difficult placements where it may not be very clear where a led belongs. and we can't use case markings to help to make this clearer (the inscriptions on the case are already basically invisible)
<wolfspraul>
oh, a lot of stuff. lunch first...
<wpwrak>
;-)
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<wolfspraul>
back
<wolfspraul>
I think we are all on the same page about test points
<wolfspraul>
I just tried to formulate our policies a little, maybe one day we can write this up properly somewhere
<wolfspraul>
TPs shouldn't be added frivorously, the ones that are there should be useful etc.
<wolfspraul>
once in a while we should review old TPs to see whether they are still needed
<wolfspraul>
I think we are all in agreements about tps anyway...
<wolfspraul>
leds, yes. awaiting your test results, but no rush. Adam is going into his 1-week vacation anway.
<wolfspraul>
wouldn't write more on case either, yes
<wolfspraul>
expansion stacking was again more about documenting/FAQ
<wolfspraul>
someone asks: Can I stack multiple expansion boards on top of each other?
<wolfspraul>
right now the answer is: We've never thought about that, let us know how it goes :-)
<wolfspraul>
what do we know? if people want to stay inside the case, with normal 100mil headers, I'd say 2 vertically stacked expansion boards won't even fit
<wolfspraul>
maybe barely
<wpwrak>
the (non-)answer is: as long as you meet the height limitation, you can do whatever you please :)
<wolfspraul>
in order to make a stackable expansion board, someone would need to replicate the male/female headers on the top and bottom of their board? that's all?
<wpwrak>
the problem would indeed be the total height, though. those critters add .. checking ...
<wolfspraul>
like I said it's just about thinking ahead
<wolfspraul>
documenting
<wolfspraul>
otherwise 2 years later someone wants to stack and we realize "oh, if we would have made that one little change 2 years earlier, we ..."
<wpwrak>
about 10.5 mm between boards. add 1.6 mm for the board. now, our vertical clearance above main pcb is roughly ...
<wolfspraul>
but someone may a) be willing to keep the case open, developer, etc. or b) use expansion boards that were first developed for m1 on some other milkymist-based board later or c) make a higher case
<wpwrak>
.. 30 mm. so well yes, maybe two layers
<wpwrak>
yes, if you remove the case, anything goes :)
<wolfspraul>
so stacking of exp boards is something that remains an option later on?
<wolfspraul>
anything we can do now to make that easier, or not accidentally make it harder?
<wpwrak>
we also can't pre-specify each possible variation. i also kept the left side a bit on the simple side. we could squeeze out a few cm2 there. but then, that may come back to haunt us later.
<wolfspraul>
fully agree
<wpwrak>
besides, few people will follow an overly complicated outline
<wolfspraul>
what's our 'official' take on stacking? supported? unsupported? recommended? crazy?
<wpwrak>
that;s also why i want a single maximum vertical clearance per side. not regions. that's already giving pilots enough trouble ;-)
<wpwrak>
(stacking) nothing e need to specify. but yes, it seems that it's possible within reason
<wolfspraul>
someone would have to repeat a female header on the top side of their board?
<wolfspraul>
and route the signals upwards?
<wpwrak>
of course, it all depends on what components you use
<lekernel>
unsupported
<wpwrak>
if they want to do 1:1 stacking, yes
<wpwrak>
if they want to do anything else, well, they have to decide :)
<lekernel>
I doubt there will be any serious expansion board within a year, anyway.
<wpwrak>
one issue of stacking is that the stack as a whole has to comply
<wpwrak>
so you can't make stackable modules that will comply when added underneath any other compliant board
<wpwrak>
but you're free to make modules that, when combined with each other in a way you define, will result in a compliant stack
<wolfspraul>
I kinda knew Sebastien's reaction :-)
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
<wpwrak>
i think "unsupported" is too strong. it should just be "not our problem" ;-)
<wolfspraul>
our message should be much friendlier, and will be
<wolfspraul>
but of course, the first board must come before the second one
<wolfspraul>
the likelihood of the first one appearing may depend on the seriousness of the whole endeavor however, including whether anyone is willing to think ahead or not
<wolfspraul>
but I think we are clear already
<wolfspraul>
first - we define vertical clearance
<wolfspraul>
we are not aware of anything right now that would stop someone from making stackable expansion boards
<wolfspraul>
right?
<wolfspraul>
and we are trying to not do anything to make that harder
<wolfspraul>
lekernel: what type of expansion board would you find interesting or helpful for the milkymist platform?
<wpwrak>
one of these days i have to learn how FETs work ... :)
<lekernel>
second video output
<wpwrak>
cladamw: lemme draw what i had in mind (with a BJT). you can then tell me if it's equivalent :)
<lekernel>
or built-in LCD
<wolfspraul>
analog or digital video output?
<lekernel>
doesn't matter - as long as there's some 2nd screen
<cladamw>
wpwrak, okay. i just used existing part 2N7002 we have had now. But I've not calculated limited resistance and intput resistance, i just added roughly firstly. ;-)
<wolfspraul>
wpwrak: the above is our stacking answer?
<wpwrak>
s/build/built/
<wolfspraul>
I just want to put that aside with something a bit friendlier than "unsupported"
<wpwrak>
wolfspraul: "not our problem" ? yes
cladamw_ [cladamw_!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<wolfspraul>
yes, but we are not doing anything right now on purpose or accidentally that would make it harder, right?
<wpwrak>
wolfspraul: it's something we don't specify. someone else if cordially invited to specify some stacking architecture
<wolfspraul>
and if someone sees something that we could do to make it easier, we would like to hear that, right?
<wolfspraul>
the difference whether someone feels invited or excluded can be very subtle :-)
<wolfspraul>
just think how you go around when you compare options...
<lekernel>
if that person has a genuine intent to make good stacked boards and isn't just throwing random ideas into the air, yes
<wpwrak>
wolfspraul: it's like an airline telling you you can have 20 kg of luggage. but whether it's in bags, suitcases, or skis, they don't care. (well, nowadays they increasingly do, but they're a few decades of bureaucratic evolution ahead of us :)
<wpwrak>
cladamw: (d1 switch) untested, of course :)
<wpwrak>
cladamw: would have to check if the pull-up lets through enough current. R2 isn't strictly necessary if we operate only with pull-up vs. "0". it would be necessary if we also want to output a strong "1".
<wpwrak>
cladamw: similarly, don't need a bias resistor unless we output "Z", which , afaik, should never happen
<cladamw_>
wpwrak, hmm? let us sync in same picture firstly: Power On --> (D1 ON), fpga pin normal high --> (D1 ON), fpga pin active low --> (D1 OFF)
<wpwrak>
wolfspraul: a stacking specification would necessarily restrict the choices available to boards that conform to it. restrict beyond what the basic extension board spec specified.
<wpwrak>
cladamw: no, it's active high
<cladamw_>
wpwrak, yes, yours is active high( i know ). hehe...i'm thinking that ours m1 behaviour. ;-)
<wpwrak>
cladamw: possible outputs: "0" = LED off, Z with pull-up = LED on, Z without pull-up = forbidden, "1" = either LED on or forbidden, depending on whether we have R2 (i would place R2, for peace of mind)
<wolfspraul>
I just imagine an FAQ with 'Can expansion boards be stacked?", and I want to give a good answer that shows that we care
<wolfspraul>
but I think we have enough data points for that answer now
<wolfspraul>
done :-)
<cladamw_>
wpwrak, mmm...my answer is we are getting same actions both ways. ;-)
<wpwrak>
wolfspraul: there is a lot you have to take into account when stacking. also how you keep non-shared signals from overlapping, how you manage the current budget of shared signals, etc.
<cladamw_>
wpwrak, yours is also work in theory. alright ! cool.
<wpwrak>
(stacking) i think we can safely leave this work to the XBRD Implementer's Forum, Committee of Stacking and the various workgroups it will spawn ;-)
<wpwrak>
cladamw: (same action) perfect then :) i think a FET may a bit more robust, because it doesn't care so much about the pull-up current. so that's good. i'm not entirely happy about burning 27.5 mA with the LED is off, though.
<wpwrak>
almost 100 mW. at some point, you have to specify the current rating of R41 :)
<cladamw_>
wpwrak, mmm... wait... i forgot Z-input condition, ;-O but my fet with Z-input, the D1 must be still ON unless you send low-input. ;-)
<wpwrak>
i'm not sure we need to consider Z
<cladamw_>
yes, R41 may change to 0603. ;-)
<wpwrak>
the FPGA should reset into pull-up. after that, software has to do the right thing
<cladamw_>
Z-input while only quickly shows after power up, but yes, it doesn't matter though. ;-)
wolfspraul [wolfspraul!~wolfsprau@p5B0AD0B9.dip.t-dialin.net] has joined #milkymist
<wpwrak>
one bug in 201201119:
<wpwrak>
SW_RESET_N shouldn't exist. or, rather, it should replace the FLASH_RESET_N on P22
<cladamw_>
good, when you find somethings while i'm in vacation, just sum up in replying email, tks.
<wpwrak>
ah, you're about to run. a wise decision :)
<cladamw_>
we can use IO_L18P_2 or IO_L30N_GCLK0_USERCCLK_2
<wpwrak>
for D1 ?
<cladamw_>
still no SW_RESET_N, good catch ! ;-)
<cladamw_>
no, can for SW_RESET_N. ;-)
<wpwrak>
oh .. no. SW_RESET_N doens't need a new pin
<wpwrak>
and you already have it, on P21
<cladamw_>
for D1's s/w control , haven't been assigned in 20120120.
<wpwrak>
(U22B)
<wpwrak>
the problem is that what you call SW_RESET_N should replace the old FLASH_RESET_N on the FPGA side
<wpwrak>
so if you delete FLASH_RESET_N on U22B.P22 and move SW_RESET_N up from U22B.P21 to U22B.P22, it'll be right
<wpwrak>
i.e., U25 divides the FPGA and the NOR side of the reset signal (and mixes it with the output of the reset chip)
<cladamw_>
oah..yah...already there i added. ;-)
<wolfspraul>
cladamw_: maybe you make a note on the wiki somewhere about SW_RESET_N
<cladamw_>
yeah
<wolfspraul>
just so we don't forget
<wpwrak>
or just edit it. shold tkae < 5 seconds ;-)
<wolfspraul>
me? sure I always edit but I may get the tech details wrong or link to the irc log instead. so if adam is around that's better...
<wpwrak>
wolfspraul: i mean that it would be considerably faster for adam to edit the schematics than to wiki-document what needs editing :)
<wolfspraul>
true, but the wiki also serves as long-term documentation, which is difficult to do with the Altium files
<wolfspraul>
and we have no kicad/schhist...
<wpwrak>
yeah, kinda sucks. didn't excpect to miss it that much that quickly
<wolfspraul>
once we have it in kicad/schhist, we can retire the wiki, but until then the wiki complements altium, that's better than just having a big altium black box
<wpwrak>
speaking of which, it's a little hard to find. how about having a box/page with useful links ? perhaps similar to what you had on the old site, but without the stubs
<wolfspraul>
and yes, I haven't read the entire thesis yet but I should and will
<roh>
i am missing the big pics on that page
<roh>
had people asking and me not finding them on the new page... highres-pcb shots
<lekernel>
wtf? 6x USB and a LED for each port?
<lekernel>
what's the use for that?
<wpwrak>
i have my doubt about those usb leds. they certainly have no "port is waiting" role. they could work as error indicators, though
<wpwrak>
the 6 x usb is simply to have a sufficient number of placement choices. besides, you can never have to many usb ports :)
<lekernel>
but they're not free. they have a cost in PCB routing effort, mech design, parts, testing and software development.
<lekernel>
and we have that very nice expansion connector, for niche users needing more USB ports ...
<wpwrak>
it's not so much about needing 6 ports at the same time but about needing a few external and then some more internal-or-external ports. but trying to limit the sum < 6 doesn't make things easier
<lekernel>
internal stuff should use the expansion connector
<wpwrak>
yes, it could. but that's probably even more expensive :)
<lekernel>
?
<wpwrak>
making yet another pcb
<wpwrak>
with active components etc.
<lekernel>
I'm not sure many people will need it
<wolfspraul>
we could layout some pins on the new J22 so that the normal 5*1 or 5*2 USB connectors fit right there
<wpwrak>
plus, people would lose the standard keyboard (in case we switch to rf)
<wolfspraul>
but then there would stlil be the problem of transceiver
<lekernel>
actually, right now our problem seems to be more about people using none of the USB connectors than anything else
<wolfspraul>
I think a ready-made USB header including transeiver is better
<wpwrak>
oh, they're trying :)
<lekernel>
but why? who needs that?
<wolfspraul>
people have to believe in the future before they make the first step
<wpwrak>
we're still behind on a few fronts with usb. 1) stack still has issues. 2) official build lightyears behind. 3) new marketing emphasizing on midi(-usb) controls still hasn't really started. 4) the plan to switch to an rf keyboard hasn't led to results yet either.
<wpwrak>
but give it time and the demand will increase
<wpwrak>
and then we'll be very happy if we don't have people banging on the door, desperate for more ports
<lekernel>
only then it'll be appropriate to think about more USB ports
<wpwrak>
patience ;-)
<wpwrak>
if i know i'll want to eat tomorrow and i go shopping today, i usually also buy the stuff for tomorrow ;)
<wpwrak>
even if i could decide to go hungry tomorrow, or eat out ;-)
<lekernel>
I still have trouble understanding what those 3 extra USB ports will be used for
<lekernel>
atm a very small number of people use <10% of the current platform ...
<lekernel>
it seems counter intuitive to me to simply throw in more features without a clear use case
<wpwrak>
we may have 2 x usb-midi + kbd (ext) + mouse (ext)
<lekernel>
that's 4
<lekernel>
not 6
<wpwrak>
or kbd/mouse (int) + external stuff (e.g., usb-midi)
<wpwrak>
yes, it's 4 x external
<wpwrak>
now add one internal
<lekernel>
but why the heck would we want internal USB ports?
<lekernel>
let's say - rather than Firewire, or ...
<wpwrak>
and you're right. i don't see an immediate use case for the 2nd internal port. of course, people will want wlan. but that's a bit further down the road
<wpwrak>
got an rf keyboard. the dongle needs to go somewhere
<wpwrak>
s/got/for/
<lekernel>
the answer seems straightforward to me: into that external USB port freed by the non-RF keyboard
<wpwrak>
risky and inconvenient
<lekernel>
do you see many laptops with an internal USB port for a particular RF keyboard?
<lekernel>
it's similarly "risky and inconvenient" to use the dongle :)
<wpwrak>
risky because dongles have a big lever. often worse than cables. inconvenient since, if it's your main keyboard, you need to unplug, stow, transport, unstow, plug all the time. andhope you never lose it.
<lekernel>
that's not our problem
<wpwrak>
laptops already have a keyboard :) and they have do have internal ports for, say, wlan cards :)
<lekernel>
they have internal PCI-express slots too. want one?
<wpwrak>
in any case, going from 4 external to 6 (4 ext + 2 int) seems a pretty minor hassle. you get one more pair of transceivers, and that's all. you already want to split DC for > 2, so that's no extra cost.
<lekernel>
how will they be tested?
<lekernel>
what if the extra tracks cause SI/EMI regressions?
<lekernel>
and do we really want to increase the BOM cost further?
<wpwrak>
SI/EMI is something we have to test. also when combined with RF.
<lekernel>
"no extra cost" heh :)
<wpwrak>
no extra cost on the DC path. we already swallow that when adding two more external ports
<wpwrak>
the internal ones are cheap :)
proppy [proppy!u1692@gateway/web/irccloud.com/x-qwovqevmjmnhtrxd] has joined #milkymist
<wpwrak>
speaking of elephants in the room. we still have those audio path problems. with apparently quite wrong levels. and some things coming from MilkDrop being poorly defined
<wpwrak>
if we have someone with a good background in signal processing, bringing all this under control should be worthwhile challenge :-)
<wolfspraul>
(true) bom cost next step: boom
<wolfspraul>
EMI regressions - I'd like to hear but needs to be a somewhat educated guess not just total fear that any new anything will cause a regression. then we cannot operate anymore.
<wolfspraul>
plus remember we still do work with an experience layout house
<wolfspraul>
experienced
<wolfspraul>
there is a reason I keep paying these guys, and we can push them a little harder to dig out the last bit of their experience to help us avoid EMI/signal integrity etc. issues
<wolfspraul>
the only thing I regret is that we don't really get their feedback 'unrolled', we only see the result like a black box
<wolfspraul>
that's unfortunate. we'll address that in the future.
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
mumptai [mumptai!~calle@brmn-4d0af487.pool.mediaWays.net] has joined #milkymist
<wpwrak>
the red leds are a bit dimmed, to give a better view of their position. at maximum duty cycle (~12-16%), they're brighter
<wpwrak>
nerdy = good or bad ? :)
<wpwrak>
the green dots on the top are from my function generator that provided the PWM signal (sits on top of the power supply, outside the image)
<wpwrak>
argh. gimp doesn't save the undo history even in .xcf :-((
<wolfspraul>
I think it's nice, plus such a picture will never get the real impression across
<wpwrak>
okay, this is from the best-case side :)
<wolfspraul>
when m1 is in a darker environment without lab power supply etc. around it
<wpwrak>
let me try another one
<wolfspraul>
also I think if all are red (rather than some green and some red), it'll look good
<wolfspraul>
functionality-wise I'm not worried, it's easy to teach users meanings of a led
<wpwrak>
i'd be more concerned with associating LED and connector. e.g., if it's between X and Y, which one does it apply to ? always the one on the left side ? varies ? "see engraving" ?
<wolfspraul>
true
<wolfspraul>
on that picture, I'd say left side of the connectors might be better
<wolfspraul>
(and I know, it was me who said right side before :-))
<wpwrak>
ether was dark because no cable was inserted
<wpwrak>
i put the led under each R/G/B connector, plus once on the left side
<wpwrak>
again, sometimes it crawled in easily, other times not
<wolfspraul>
how many are under the video-in? I cannot really see. is there one to the left of the entire connector? or all underneath?
<wpwrak>
one on the left and one under each RCA
wolfspraul [wolfspraul!~wolfsprau@p5B0AD0B9.dip.t-dialin.net] has joined #milkymist
<wpwrak>
just to illustrate the one for each and one for all alternative
<wpwrak>
and before i wrote: one on the left and one under each RCA
<wolfspraul>
ah ok. I think under is better
<wpwrak>
actually, perhaps the LEDs should go to the bottom of the PCB. that would avoid all the crazy mechanical stacking
<wpwrak>
let's see what the choices for sideways-facing LEDs are ..
<wpwrak>
(stacking) plus they could be perfectly centered, avoiding ambiguities
<wpwrak>
hmm, LTST-S270KRKT
<wpwrak>
USD 67.50 for 1000. about 10% more expensive than the top-facing LEDs.
<wolfspraul>
I think the price is OK
<wolfspraul>
there would still be some on top, like mmc?
<wpwrak>
yes, MMC (if we want one there)
<wpwrak>
not sure if anything else would make sense, though
<wolfspraul>
I'm not sure I do
<wolfspraul>
lemme think :-)
<wpwrak>
MMC is kinda poorly supported anyway :)
<wolfspraul>
don't mention that
<wpwrak>
sw, physical access, ...
<wolfspraul>
if Sebastien is in a very good mood one day, I planned to propose a second - or third (?) mmc?
<wolfspraul>
(JUST KIDDING!!! :-))
<wolfspraul>
yeah, for the mmc one I don't have an opinion just now in chat. I would need to think about it.
<wolfspraul>
we could add one 'just in case', and then if nobody enables it remove in later spins
<wpwrak>
ah, i was thinking of a SIMM slots, so that we can have more memory, with whatever characteristics you find on the market (-:C
<wolfspraul>
I don't know, maybe not strong enough logic.
<wolfspraul>
with that same logic we could add many more, 'just in case'
<wolfspraul>
so maybe not
<wolfspraul>
up to you
<wolfspraul>
on the bottom side is kinda interesting I think
* wpwrak
looks for a coin
<wolfspraul>
I cannot imagine how that looks like
<wolfspraul>
I am worried about the ESD test failing because of that though
<wpwrak>
(bottom) it would eliminate my two main worries: ambiguous location and complicated mechanical stacking
<wpwrak>
hmm. we already have components at the bottom ...
<wolfspraul>
yes but who knows, more parts, more wires, more vias
<wolfspraul>
in some other school of thought I was hoping we could completely clean out the bottom side
<wolfspraul>
but that's difficult because of those caps I think that have to be close to the fpga
<wolfspraul>
plus it all works now...
<wpwrak>
one drawback of sideways facing is that, if you want to go for a retina-engraving ultra-bright LED, the price step is larger than with top-facing. ~USD 94 per 1000.
<wpwrak>
note: 0605 footprint. and 250 mcd (instead of 54 mcd)
<wolfspraul>
but you can still control the brightness?
<wpwrak>
sure
<wpwrak>
making it darker is easy :)
<wolfspraul>
I don't think a price difference between 5 or 10 cents makes any difference to us
<wolfspraul>
even if that's 1-2 USD in total, so what
<wolfspraul>
they are easily removed later
<wpwrak>
well, at some point, you see the PWM at work when you move quickly :)
<wolfspraul>
but we add them now and then find out whether they catch on or not
<wolfspraul>
back to the ESD test - with metal sheet, they would be above the metal
<wolfspraul>
without metal sheet, using joerg's aluminum X stripe (which we haven't tested yet), they would be kinda outside the safe zone, no?
<wolfspraul>
I don't know how effective the 5mm aluminum 'X' idea is if there are lots of components with vias going to the other side
<wpwrak>
(safe zone) hmm, hard to tell
<wpwrak>
i think the idea is that, if you're in an electrostatic field, you want to short out the gradient
<wpwrak>
so it would depend on the shape of your field ...
<wpwrak>
or maybe EM field ... never quite sure which applies in such cases
<wpwrak>
perhaps making sure there's ground around the LEDS would protect them sufficiently. ground would have a reasonably direct connection the the "X", which the takes care of the rest
<wolfspraul>
alright :-)
<wolfspraul>
I am willing to take risks, no worries
<wpwrak>
i.e., in my theory, the upset would be caused by a transient passing the board. much like the L3/L9 issue
<wpwrak>
again, there the problem vanishes if you just short all the places the transient crosses together
<wolfspraul>
about brightness - if we go for this entire idea I vote for the brighter ones, because I understand they are dimmable anyway, and we can cut down later if we find no use for the light
<wolfspraul>
for the amount of light
<wpwrak>
sounds good to me
<wpwrak>
they KRKTs I use are okay but a bit less bright than the green ones we have now
<wpwrak>
that is, at 15% duty cycle
<wpwrak>
the green ones don't stand a chance if i increase the duty cycle :)
<wpwrak>
ah, if we keep the LEDs-for-USB idea, then there would be two more on the top, for ports E and F
<wpwrak>
if we need 18 or less LEDs, then we could do with a 3x3(x2) matrix and increase the LED current from 6 mA to 8 mA
<wpwrak>
if we need 16 or less LEDS, we could go to a 2x4(x2) matrix, leave the current at 6 mA, but increase the duty cycle from ~16% to ~25%
<wolfspraul>
I don't need leds for the internal usb
<wolfspraul>
too hypothetical
<wpwrak>
great
<wolfspraul>
well that's just my opinion
<wpwrak>
we can also write some software for a system status display that shows us what all the peripherlas are doing
<wolfspraul>
it's too many steps out for me, can't see them being used
<wolfspraul>
system status display?
<wpwrak>
they have it in any decent sci-fi movie: spaceship takes a beating. then then bring up an image showing a wire model with all the damaged zones conveniently highlighted
<wpwrak>
you don't have that on PCs because nobody knows where the things are physically located. but in M1, we know _exactly_ where they are :)
<wpwrak>
btw, that's also my plan B: if we should decide against LEDs, then a status display. of course, that would be much more effective with a built-in panel, so it would be an awkward compromise for M1
<wolfspraul>
cannot follow now, too many ifs
<wpwrak>
;-))
<wolfspraul>
leds for ports is an idea I understand, and you see Nate's mail for example, he immediately got it
<wpwrak>
was the "system status" idea clear ?
<wolfspraul>
sort of, but I feel it's quite indirect
<wpwrak>
yes, that's true
<wolfspraul>
it maybe cool in a movie, but to actually operate a device?
<wpwrak>
LEDs are more immediate
<wpwrak>
;-)
<wolfspraul>
nowadays people want to touch everything
<wolfspraul>
the question for me is not how many lights we find funny or can stare at for an extended period of time, but which idea we can communicate to users
<wpwrak>
with M1, it the "ship status" display may work (with an integrated panel), because you a) know exactly where things are, and b) the display also has a well-defined orientation to them
<wolfspraul>
if a led is connected to a port, I can see software making good use of that
<wolfspraul>
so it becomes something the user can easily be trained for, and will like to be trained for
<wpwrak>
:)
<wolfspraul>
yes I think it can easily become very fun to use, with a little logic in software
<wolfspraul>
that's why I'm hesitating with led for mmc or internal usb - can't really connect to that right now
<wolfspraul>
but if you want to dismiss the entire idea and stay with the 3 leds we have, also fine by me
<wpwrak>
MMC is a fumbly mess anyway
<wolfspraul>
it's totally off-limits for users
<wolfspraul>
just internal storage, like a NAND chip
<wolfspraul>
that's how I see it
<wolfspraul>
and that's why I have a 100% tested and working 2 GB chip in every rc3
<wpwrak>
internal USB ... well, there could be a logic: dark if not in use. always on if it enumerates and we have a driver for it. blink if it doesn't enumerate or we don't know what it does.
<wpwrak>
same as for external USB
<wolfspraul>
because I never once want to tell a user how to access that...
<wpwrak>
;-))
<wolfspraul>
fine fine, please feel free
<wolfspraul>
the led idea is your playground, I trust your judgment
<wolfspraul>
something may grow out of it, maybe not on all ports, but maybe on some
<wolfspraul>
it's worth trying!
<wolfspraul>
that's my opinion
<wolfspraul>
another thing - I'm just looking at the mmc under jtag-serial, and wondering whether we can move this slightly in R4
<wolfspraul>
so that a) the mmc can be fully opened without getting in conflict with the jtag-serial daughterboard and b) the jtag-serial daughterboard doesn't need this little cut-off corner (maybe the newer types already don't need that anymore)
<wpwrak>
i'd almost say "any other place would be better" :)
<wpwrak>
just as long as it stay's out of the hair of the expansion connector :)
<wolfspraul>
yeah but I don't feel like moving things around just like that
<wolfspraul>
maybe we just leave as-is
<wpwrak>
do humans with fingers shaped in a way that allows them to open the MMC critter without unconditionally removing the JTAG board exist yet ? ;-)
<wpwrak>
lemme conclude the LED collages, for completeness. then i'll think about how to sneak them under the PCB (for demonstration purposes)...
<wpwrak>
i think it'll be a lot of work. so perhaps only one side
cwoodall [cwoodall!~cwoodall@comm575-0301-dhcp011.bu.edu] has joined #milkymist