#milkymist IRC log for Friday, 2012-02-24

cladamwmorning :)00:48
cladamwwpwrak, seems Sebastien have had different opinion to limiter switch's EN/Fault pins. How's your thinking now ? I've not edited it into latest draft.00:51
wolfspraulgood morning00:53
wolfspraulevery feature adds complexity, cost, etc. needs to be tested, needs to actually work well, and so on.00:53
wolfspraulwhat is this feature about?00:54
cladamwbtw, I'll finish order on few parts to prepare them for goals about layout need and check real part's package myself and tests.00:54
cladamwwolfspraul, for this DDC 5V limiter switch, I'll order few to test first, so not yet edited into draft.00:55
wolfspraulthe particular EN/Fault pin back to the fpga - what is it for?00:56
wolfspraulwhich use case is this?00:56
cladamwsince this switch have two other pins (EN, FAULT) which Werner wrote in email thread already, I also knew those two pins. so my plan is just to order first then test.00:57
wolfspraulsomeone plugs in a DVI-I monitor, then what?00:57
wolfspraulmy feeling (and feeling only) on this switch is that we overdo it a little, just reading from the distance00:57
wolfspraulwe don't know any actual use case, we just implement stuff based on paper (specs)00:58
wolfspraulmaybe not a single real-life use case exists? :-)00:58
wolfspraulbut it's good to start with a little too much protection, later when we have more experience with actual dvi-i monitors, we can remove parts again...00:59
cladamwmy thinking is quite same as Sebastien though but without EN and Fault features just switch itself ( 50mA limit goal )00:59
wolfspraulwho cares about this 'limit' anyway? I don't know01:00
cladamwwith Fault pin, we can know a real over current happened so fpga can be as indicator then do something01:00
wolfspraulseems like just some number written into the spec so that both sides can engineer their power circuit against some number01:00
wolfspraulthen do what?01:00
wolfspraulthe m1 is not lab test equipment...01:00
cladamwwith EN pin, fpga can do re-enable DCC5V after external over-voltage (output > input),01:02
wolfspraulbut we don't know whether a single such case actually exists01:02
cladamwi'm trying to describe what i saw different views on this limit switch though. :)01:03
wolfspraulto me it sounds like no value, just sandbagged around a paper spec01:03
cladamwlike my email replied already, "This assumes for short current at 100 mA, this two * 1206/100 Ohm would reach rated power at 70°C[1] is 1/4 W. Also DDC voltage to monitor will be dropped. Insensitive one could not smell short occurs up and resistors get aged, even PCB surface is still good. Of course shorting on DDC is extremely few chance in the end. Cheapest way(0.022 USD/10pcs), not resetable, no guarantee."01:04
wolfspraulno idea01:04
wolfspraulI'm just trying to understand the en/fault line back to fpga01:04
wolfsprauland I don't understand it's usefulness (use case)01:05
wolfspraulso without use case - don't do it01:05
cladamwif someone speak up that we don't need it, then we don't this protection( via limiter switch ) , then we use two resistors (1206s) then done. ;-)01:05
wolfspraulI have no comment on electrical preferences01:05
wolfspraulsomething is 'good', but what is good? :-) you guys have to find out01:06
cladamwfrom my idea to brainstorming with Werner then, we listed three total solutions on this.01:06
wolfspraulyes, not again01:06
wolfspraulI have no comment on those01:06
wolfspraulmaybe they are actually very similar, that's why it's hard to pick :-)01:06
wolfspraulno clear pro/con for any one of them... so don't get stuck01:07
wolfspraulpick what werner likes01:07
wolfspraulI was just commenting on the line back to the fpga01:07
wolfspraulyou say "fpga can reenable 5v after external overvoltage"01:07
wolfspraulso what?01:07
wolfspraulwhen does this case happen?01:07
wolfspraulit sounds very theoretical, just working along paper01:08
wolfsprauloh, this case, oh that case. but do they exist?01:08
cladamwyou know Werner's thinking. then "pick what werner likes" again.01:08
wolfspraulhow strongly does werner feel about the fault line?01:08
cladamwso i tried to ask Werner that Sebestien's feedabck on EN/FAULT . ;-)01:09
wolfsprauland since he seems currently offline, we chat a little :-)01:09
wolfspraulI think the fault line provides little value, I don't understand the use case01:09
wolfspraulI would do this on a devel board, or if m1 is lab test equipment01:09
wolfspraulbut how many actual consumer products with dvi-i would have such a 'bring 5v back after external over-voltage' feature?01:10
wolfspraulmy gut feeling is: none :-)01:10
wolfspraulwhat do you think?01:10
cladamwthat's why i was trying to ask how's wener's thinking now.01:10
wolfspraulhow many dvi consumer products do you think would have this?01:11
wolfspraulI think none, nobody01:11
cladamwsure I've had said that I quite same as Sebestien's thinking. Just switch itself but no EN/Fault pins toward/from fpga. ;-)01:11
wolfspraulso sebastien you me all feel the same01:12
wolfspraulmy comment is purely gut feeling though01:12
cladamwbut needs to chat with Werner about this though. :-)01:12
wolfspraulso let's see how stronlgy werner feels for it01:12
wolfspraulmaybe he concedes that it's excessive and facing such overwhelming 3:1 opposition he retreats? :-)01:12
wolfspraulor maybe he totally thinks this has to be there...01:12
cladamwmaybe he went to dentist... he'll head up.01:14
wolfsprauldentist, urgh01:17
wolfspraulfault line?01:17
wolfspraulmaybe the dentist needs to rip out some fault lines leeding from his teeth to his brain :-)01:17
cladamwno, he said before that he'll go to dentist.01:18
wolfspraulcladamw: I am finally looking over the insertion/removal detection at http://en.qi-hardware.com/wiki/Milkymist_One_RC3_Known_Issues#R4_draft_feedback01:21
wolfspraulso let's see. for ethernet and usb, it's sufficiently built into the protocol at higher levels.01:22
wolfspraul"dc power in"? don't understand01:22
wolfspraulhow could we not detect that - I mean without power m1 will not run at all, right?01:22
wolfspraulseems kinda implicit to me, as long as m1 doesn't have a secondary power source like battery or so01:22
wolfspraulaudio line-in/out - we added it in R4 - great01:23
wolfsprauldvi-i, same - great01:23
wolfspraulmidi, dmx and video-in - seems not01:23
cladamw"dc power in" solution for insertion/removal already done in draft sch. ;-)01:23
wolfspraulbut what does it mean?01:24
cladamwif I marked "yes" means draft is done. ;-)01:24
wolfspraulif there is no cable in dc power, then m1 is off, no?01:24
wolfspraulI don't understand the "dc power in" detection01:24
wolfspraulif someone unplugs it, m1 will immediately shutoff01:24
cladamwyes, m1 is off when no cable in dc power.01:24
wolfspraulso what is being 'detected' then?01:24
wolfspraulthe detection is death01:25
wolfspraulor we have some milliseconds to turn off something?01:25
cladamwif unplugged (no cable) then power LED is off (but hardware) directly, no milliseconds such features. ;-)01:26
cladamwif plugging, power led in ON, then fpga can override power led.01:27
wolfspraulthat's what you mean with 'detection'?01:27
wolfspraulah ok01:27
wolfspraulmy understanding of the word 'detection' was more that the m1 is running, and then 'detects' something01:27
cladamwpower is power, when no power in, no such real insertion/removal features though.01:27
wolfspraulwith the dc power cable being the only power source that's not really possible01:28
wolfspraulif we would support a battery, then it would be different01:28
wolfspraulthen m1 could really *detect* the dc cable insertion/removal01:28
wolfspraulbut ok, I got it. you mean the led and led override...01:28
cladamwsure that insertion/removal is exactly the idea same as you when we talk in audio-line-in/out. ;-)01:28
wolfspraulok, that leaves midi, dmx and video-in01:28
cladamwyes, overriding.01:28
cladamwmaybe i seperate "dc power in" out.01:29
wolfspraulfor video-in, does the adi adc chip have some detect feature?01:29
cladamwin that wiki, too confusing you. sorry.01:29
wolfsprauloh no problem01:29
cladamwyes, video-in decoder can detect it by scanning reg setting.01:30
wolfspraulI am editing it01:30
wolfspraulscanning reg setting, hmm01:31
cladamwha, thanks, but how s/w to handle on video decoder I don't know. from from datasheet, i can see with setting then s/w should detect.01:31
cladamwbut not real by hardware's insertion/removal, so I currently have no idea on this RCA connector. :(01:32
wolfspraulI'm wondering whether software needs to poll that settings constantly, or whether there's a way to generate an interrupt or so upon insertion01:32
wolfspraulok, we will find out that one01:33
wolfspraulthen dmx and midi01:33
wolfspraulfor midi, werner should know whether there is value in adding detection01:33
wolfsprauladding it would mean that we need to find another connector?01:34
cladamw(polling) yeah...don't know, since if like people use 'blue' RCA connector but suddently decoder detects no video out, then no screen no monitor, but I'm very surely register reading can know (insertion/removal)01:34
cladamw(dmx & midi) for midi rx/tx, no real hardware's insertion/removal features but f/w can do which we already reviewed. for DMX, we haven't reviewed yet.01:36
wolfspraulyes, but I'm wondering how elegant this can be done in software, and if it's not very elegant, whether we can add something in hardware to make it easier in software. we will find out.01:36
wolfspraulcladamw: oh, for midi we can sense it on the software side?01:36
wolfspraulwhen werner is back, we can discuss video-in and midi first01:37
wolfsprauldmx last, I guess :-) even though I think there are real business opportunities and good use cases in dmx, seems it's always last :-)01:37
cladamw(midi TX) no both h/w & f/w01:38
cladamw(midi RX) no h/w, but can be done on f/w. ;-)01:38
wolfspraulok, so it's a similar question to video-in, how elegant software can do it, and whether hw can help sw in any way...01:38
cladamwokay, let's reviewed them again when werner is back. I always put irc links in that wiki pages.01:39
cladamwso sure when werner is back then we item by item to review.01:39
wolfspraulif he survives the dentist01:39
cladamwbut how he thought on f/w can do , well. i don't know f/w. ;-)01:40
wpwrak(reading backlog) dentist was yesterday. my dental armament has now been fully restored :)02:24
wpwraktoday's task was bringing the apartment in a presentable shape. a friend is stopping over for a couple of days.02:25
wpwrakregarding the DCC5V switch, i'd say that, if we consider it likely that there can be problems with that connector, then having the fault line is a good thing, because it will let us diagnose the issue quickly. we already have ton of signals going that way, so one or two more shouldn't really make a bit difference.02:27
wpwrakthe enable pin would be mainly for having a wider choice in case of sourcing issues. i don't really expect to see uses for clearing overvoltage or for switching DCC5V on or off. (which is already in my mail :)02:29
wpwrakmidi: seems that connectors with a mechanical switch exist. but i haven't seen a data sheet yet. only a shop in .de that says something like "DIN 5 pin with switch"02:35
wpwraknone of digi-key, farnell, or mouser seem to have din receptacles with a switch02:36
wpwrakso i would consider them either exceedingly rare or a myth. or i have to work on my database searching skills :)02:36
cladamw(midi DIN 5 pin with switch?) sounds good.02:37
wpwrakan electronic detection of MIDI RX and TX may be possible. but it may be unreliable and might introduce issues. such as defeating the galvanic isolation we have on the RX side. or requiring a complex circuit.02:39
wolfspraulI don't consider it likely that there will be "problems with that connector"02:39
wpwrakwhich connector ?02:39
wolfspraulcladamw: no, does not sound good, sounds totally unsourcable and leading in the wrong direction.02:39
wpwrakdvi ?02:39
cladamw(en/fault) wpwrak, so you still want both of them now.02:39
wolfsprauldcc5v/ddc (replying to you above)02:39
wolfspraulno, we don't have a use case. we just add stuff because we don't know, which is unsustainable imho.02:40
cladamw(midi connector) wolfspraul, needs to find again, if Mouser have it, still good.02:40
wolfspraulif there is a problem, we need to find out about the problem first02:40
wpwrakcladamw: i want fault more than en. if a non-transient short-circuit event happens, we'd be very interested in knowing about it.02:40
wpwrakcladamw: enable is in the "why not" category02:41
wolfspraulbut m1 is not an academic study tool. so then I'm asking - what other consumer electronics would have (or need) the ability to detect such a condition?02:41
wolfspraulmy gut feeling tells me - nobody02:41
wolfspraulwe cannot protect against every conceivable electrical oddity02:41
wpwrakcladamw: (midi connector) i checked digi-key, farnell, and mouser and didn't find anything that looked right02:42
wpwrakcladamw: i didn't check arrow, though02:42
wolfspraulquestion is what dvi-i devices people will typically connect, and how they will typically behave02:42
wpwrakwolfspraul: if you expect DCC5V to never fail, just connecting it to 5V and skip all the protection02:42
wolfspraulalready clear that it's the wrong path...02:42
wolfspraulif digikey farnell and mouse all don't have something - big no no :-)02:42
wpwrakwolfspraul: worst case: the main fuse trips and/or the connector overheats02:43
wolfspraulwhat does 'fail' mean?02:43
wolfspraulwhat do other consumer electronics do?02:43
cladamwwpwrak, phew...oah..sorry i misunderstood, three sources don't have it( not only digikey). got it.02:43
wolfspraulworst case a lightning hits your home02:44
wolfspraulwhat do other consumer electronics do?02:44
wolfspraullet's say "the best" :-) (=apple :-))02:44
wolfspraul(just kidding)02:44
wolfspraulwpwrak: what kind of 'failure' do you think about?02:44
cladamwbut the main fuse get lightning is rarely low i think. also if we use Molex DVI-I connector ( would it be easiler to overheat ?)02:45
wpwraka short to ground02:45
cladamwwell. although it always have the possibility. ;-)02:46
wolfspraulhow likely is that to happen?02:46
wpwrakif it's just a few mA above 50 mA, nobody cares or would even notice anyway. even the proposed switch has a wide tolerance margin.02:46
wpwrakno idea02:46
wpwrakcladamw: i haven't seen any electrical characteristics in the molex data sheet02:47
wpwrakcladamw: the DVI spec you found says 1 A.02:47
wpwrakwe'd trip at 2 A02:47
cladamwseens a fault pin surely can be alternative action when oc or short happens, we know this. but you wanted to let m1 react oc/short to indicate, is that what you want, right ?02:48
wolfspraulnow that we spent so many brain cells on this, keeping the micrel switch sounds like a good idea to me, at least until we gain some more confidence with dvi-i.02:49
wolfspraulbut the fault lines seem excessive02:49
wolfsprauleven the micrel switch may well be removed one day in a "let's remove unnecessary protection stuff" cleanup effort... (just my gut feeling, if m1 takes off)02:49
wpwraki really don't see why the fault line would be a big deal02:49
wolfspraulfar in dreamland. the situation you have is already hypothetical, the protection was added 'just in case' and any reaction to it is even more speculative.02:49
wolfspraulmaybe m1 should have some circuit to remote-fix the broken equipment on the other side? :-)02:50
cladamwwpwrak, oah, yeah...2 A > 1A, then lightning is possible, but would be rarely happened ? ;-)02:50
wolfsprauladam needs to know whether the fault line is optional or not, so routing has the option to remove it if needed02:50
wolfspraulto me it sounds very very optional, just trying to add my superficial perspective though02:51
wolfspraulwe are operating in an area where we are multiple indirections removed from actual use cases02:51
wolfspraulso I am trying to find out the use cases that drive this as well, but seems there are none02:52
wolfspraulwhich now makes me wonder - what do other consumer electronics do about this?02:52
wolfsprauland: we don't know (again)02:52
wolfspraulthat's all02:52
wolfspraulline added or not I don't care, but it seems like a line without value to me02:52
wolfspraulcan we easily find/compare with schematics of other consumer electronics?02:53
wolfsprauloops, disconnected02:59
Last message repeated 1 time(s).03:01
wolfspraulso I would compare with other consumer electronics, or pull in/find some experience (people who have worked on dvi/ddc before)03:01
wolfspraulI think if Adam knows the line is optional, that could help routing if space is tight03:01
wpwrakyes, assigning a low priority to is sounds reasonable03:04
wolfsprauland we should keep our eyes open how other well designed consumer electronics handle this03:04
wpwrakbut i'd make an effort to have it. most likely, it's not a big deal. it can connect to pretty much any pin. it's OC, so the voltage domain doesn't matter03:05
wpwrakpry open that high-end sony laptop ;-)03:05
wolfspraulmy feeling is that even most well designed equipment would at least stop working when a voltage-out from that device is shorted to ground03:07
wolfspraulthe manufacturer would probably want to avoid permanent damage in such a case, but wouldn't care if the device hung up, goes into reset, etc.03:08
wolfspraula device on the other side that shorts to ground is most likely broken/malfunctioning anyway, so even if you continue to run - not much gained in a typical user scenario, as long as the second device will not also break now03:09
cladamw(contact current rating = 1.5 A minimum) wpwrak, yes, in page 50. ;-)03:10
wolfspraulcladamw: are we clear on the dcc voltage now? keep the micrel part but the fault line is optional03:10
wolfspraulI think that's the bottom line03:10
wolfsprauland I still want to understand how others implement this :-)03:10
wolfspraulmaybe William knows and can have a quick look at some schematics, I will ask him03:11
cladamw(en/fault) seems setting a low priority firstly, although placement for routing for house is needed to add all lines firstly, then house can import them, so I'll firstly add en/fault pins to fpga firstly, unless house tell me it's 'Hard' to route., so we set this in advance, okay, ending ?03:13
wolfspraulen is already agreed to be really useless03:14
wolfspraulen = ability to enable/disable the current switch?03:15
cladamwto know if there's consumer schematic about ddc limit idea, i'll keep an eye when i'm in house there. if i know schematic from them.03:15
wolfspraulcladamw: we are talking about 2 lines? 1 is enable, 1 is fault?03:15
cladamwyes, two lines (en & fault), 'en' to let m1 to re-enable switch after m1 knows a overcurrent or short happened from 'fault' pin.03:16
cladamwso werner actually would like both lines.03:17
wolfspraulno I don't think so, he just describes some marginal cases that justify why we even talk about them03:19
wolfspraulboth are optional, en even less valuable than fault I think03:19
wolfspraulcladamw: if the entire switch is gone, and someone shorts the 5V to gnd, will m1 have permanent hardware damage?03:21
cladamwwhen switch detects a oc/short, switch itself cuts power periodly, this way to protect circuits. actually no need en/fault pins, but with both lines, m1 can do something/action to react.03:21
wolfspraulyes but those use cases don't exist03:21
wolfspraulit's pure imagination03:21
wolfspraulwhich we will see when we study what other consumer electronics do, surely03:21
cladamwif no switch with short, then we see lightning somewhere in m1 board. ;-)03:22
wolfspraulpermanent hw damage?03:22
cladamwit's a RMA issue to sevice people then. ;-)03:22
wolfspraulwhat happens on the m1 board then - which part breaks?03:23
cladamwit could be damaged somewhere if main fuse not immedately trips.03:23
wolfspraulbut we have a fuse03:24
wolfspraulfuse trips03:24
wpwrakjust posted a bit of an analysis to the list :)03:25
wolfspraulsounds like we don't know whether a 5v to gnd short would permanently damage m103:25
cladamw5V traces on  m1 would be deteriorated if main fuse doesn't trip firstly.03:26
wolfspraul*if* again :-)03:26
wolfspraulbut we have a fuse03:26
wolfsprauleither we trust our electrical design or not03:26
wolfspraulif we don't trust it (another 'if'), then that's something to work on :-)03:26
wolfspraulanyway, the micrel part sounds good03:26
wolfspraullet's favor speed03:26
cladamwbefore reset ic to reset m1, still could be somewhere failure.03:28
wolfspraulyeah but we don't know03:28
cladamwwpwrak, ha...saw it.03:28
wolfspraullots of unknowns which we fight with more parts03:28
wolfspraulwhich of course add more unknowns03:28
wolfspraulone day we compare with a well designed high-volume electronic, then we have a reference03:29
wolfspraulthen no guessing around in 'don't know land'03:29
cladamwif no witch, overheating could be somewhere then m1 's 5V rail from dc power in to nearby dvi-i connector being deteriorated.03:29
wolfspraulmaybe the micrel part will not work on some boards? :-)03:29
wpwrak(1.5 A) ah, even better03:30
wolfspraulyou guys decide what is 'good design'03:30
wolfspraulI will wait until I have a high-volume schematic to compare with03:30
wpwrakgotta run. guest arriving.03:32
wpwrakand yes, i would expect the fuse to blow long before anything else happens. else, what's the point :)03:32
cladamwsorry i can't wait, since i have to edit schematic firstly then house can evaluate them once I send to them.03:32
wolfspraulthe ability to provide more power (say 200mA) may even be a feature :-)03:34
wolfspraulafter more thinking, now I wouldn't add the switch at all03:36
wolfspraulthat way the en/fault problem goes away as well :-)03:36
wolfspraulthe overheating and 'main fuse doesn't work' cases appear baseless/random03:37
cladamwwolfspraul, so i follow you or 'pick what werner likes' ? ;-)03:37
wolfspraulwhat do *you* think?03:38
wolfspraulI think about it now... from werner's last mail, I'd say why have this switch at all?03:38
wolfspraulremoving parts is a big pro in itself, and there doesn't seem to be a strong reason against removing the part03:39
wolfspraulcladamw: you have seen plenty of schematics as well, how would a well designed high-volume electronic address this issue, probably?03:39
wolfspraulcladamw: maybe leave it open for today, everybody can think about it more over the weekend, maybe we find some additional feedback from someone with experience03:40
wolfspraulbut if you were the only person on this project, what would *you* decide?03:40
wolfspraulif you are building this device only for your own home use...03:40
cladamwwolfspraul, what i could say is that if we add no protection previously then once m1 customer telling us his m1 failed when dvi cable plugged once, then we say 'oah' we should add it then. But 'if' m1 keeping sells like 500pcs without short problem, then you could say we are safe only in the end. ;-)03:42
wolfspraulthat's no answer. what would you do if you are the only person on this project, and you are building this device only once for your own home use?03:43
wolfspraulwould you add the micrel part or not?03:43
cladamwha...good question about if 'only' me for this project: then I determine then stick on two 1206s resistors. ;-)03:43
wolfspraulaha, that's an answer. thanks!03:43
cladamwwolfspraul, phew...man...03:44
wolfspraulI feel similar. keep it simple, this dcc5v case is a rare & marginal case, and these cases of overcurrent and short simply will not happen.03:44
cladamwbut you still can't against all ideas here and there. ;-)03:44
wolfspraulunless the monitor is broken itself, and as long as our device (m1) doesn't get a *permanent* damage, I wouldn't go beyond that03:44
wolfspraulwhy not, we are discussing and that is good. one day we may realize this is important.03:45
wolfspraulcladamw: can you keep this open over the weekend? werner is out now...03:45
cladamwhehe...we surely need to keep minds in commecial thinking/ value/ time/ cost/ ...i know you will lead to this way...03:46
cladamwwolfspraul, i'll keep maybe one or half to work others03:47
wolfspraulI'm relaxed, we will find a good solution. maybe we do too much protection first, maybe we do too little. maybe we hit just the perfect spot on the first run. there is no alternative to starting somewhere, making boards, trying and learning.03:48
wolfspraulreplied on the list, my 2c :-)03:49
cladamwI'll no action now from "maybe leave it open for today, everybody can think about it more over the weekend". ;-)03:55
wpwrakalmost out :)04:03
wpwrakone possible issue could be inrush current. e.g., if someone puts a HUGE cap on DCC5V, it could trip our reset chip04:03
cladamwyou meant at monitor manufacturer side?04:05
wpwrakof course, we have something like 300 uF on our side to fight back04:06
wpwrakyes, in the monitor04:06
cladamwpresent draft C188 for J17:14 (DDC5V) in m1 is 1uF.04:07
wpwrakbtw, wher did that 47 Ohm resistor come from ? is this copied from someone's reference design ?04:07
wpwrakyes, but we also have C286 on 5V04:08
cladamw47 Ohm came from Sebestien first version. Don't know if he copied somewhere. good question04:08
wpwrak(47 Ohm) ok. let's find out.04:11
wpwrakpity that the DVI spec is so incomplete. doesn't mention inrush current at all. USB is sheer pleasure in comparison.04:12
wpwrakokay, now i'm off for a while04:12
cladamwgood, Xilinx SP605 has DVI circuit, but no DDC5V directly connects to 5V with 0.1uF only.04:22
cladamwwpwrak, http://www.xilinx.com/support/documentation/boards_and_kits/xtp067_sp605_schematics.pdf04:28
cladamwman~its protections on DVI's differential are more than M1R4. well. we're not doing this way.04:30
wolfspraulthat's a devel board04:31
wolfspraulon a devel board, you can throw all sorts of things on for various reasons, that may increase the value of the devel board04:32
wolfspraulwe need to compare with high-volume products04:32
cladamwyup. we're not doing devel board.04:32
wolfspraulon that devel board, dcc5v is just connected to 5V directly with only a 0.1uF on it?04:33
cladamwm1r1 should be copied somewhere from xilinx or altera reference design04:33
cladamwyes, directly connect. no specific protection on DDC5V.04:35
cladamwi'm out now.04:35
cladamwback soon.04:35
wolfspraulk l804:35
wolfspraulI'll get some lunch as well :-)04:35
cladamw(ML401) http://www.xilinx.com/support/documentation/boards_and_kits/ml401_2_3_schematics.pdf05:42
cladamwfrom its VGA sch, the DSUB even NC on its pin 9 of vga connector, mmm...so probably not referenced from it. :-)05:44
cladamw(ADV7181CBSTZ) bad news ! out of stocks after found in http://octopart.com/partsearch#search/requestData&q=ADV7181CBSTZ06:50
cladamwlast time I ordered from AVNET.06:51
cladamwwe should keep front filters(C202~C207 and F14~F16) in M1R4, this way we can still have ADV7181B version in case not easily source C version, Not to remove all filter parts.06:55
wolfspraulthe B is already super old06:55
wolfspraulwhatever happened to the C we need to find out, and then move *forward*, not backward06:55
wolfspraulwhat is the diff between 7181C and 7180B ?06:56
wolfspraulseems the 7180B is in stock, checking datasheet06:56
wolfspraulalso look on the adi site, maybe they have information on the 7181C06:56
cladamwseems a new ADV7181D is came: http://www.analog.com/en/analog-to-digital-converters/video-decoders/products/index.html#Video_Decoders07:05
wolfspraultrue, but not in stock yet07:06
wolfspraulI can only find info about the 7181C status 'in production' on the adi site, nothing about the D07:10
wolfspraulif the C is in production, we can try at ADI's china distributors, they should be well stocked I would think07:11
wolfspraulgoing straight to the D is tempting but maybe too rushed and then we have to wait or run into new issues etc. I'd rather accelerate our path to R4.07:12
wolfspraulah here http://www.analog.com/en/analog-to-digital-converters/video-decoders/adv7181d/products/product.html07:12
wolfspraulD is also listed 'in production', but tray size 260 instead of 160 for the C07:13
wolfspraulcan't really see the advantage of the D immediately. D says 10-bit ADCs sampling at 75 mhz, while C is sampling at 110 MHz. D has 10 input channels, C has 6.07:16
cladamwyup..D's package is different from C. but I'm checking if D can possibly put in C footprint. need to carefully see D dimention.07:16
wolfspraulthe top feature I see on the C list is "chinese data sheet available" (!)07:16
cladamwyup. i saw also07:16
wolfspraulfrom a quick look at octopart, it seems neither C nor D are easily sourcable. so maybe we try at ADI's official china distributor?07:17
wolfspraullet's do this: first we study the D datasheet, see whether we prefer C or D07:17
cladamwman! just don't know exactly why octopart,07:17
cladamwdoesn't have it.07:17
wolfsprauloctopart is just a database aggregator, so those websites just don't have them07:18
wolfspraullet's first find out about the D now07:18
wolfspraulit's recommended for new designs...07:18
wolfspraulthen we try to contact ADI's official China distributor on Monday07:18
cladamwnot sure this condition is the same as firstly we source spartan-6, in digikey they were not preparing it then.07:18
wolfspraulyou can try to get the C or D at arrow in taipei07:19
wolfsprauldo you have a contact there? seems arrow has a lot of ADI stuff07:19
wolfspraulbut first I think let's study the D datasheet07:19
cladamwyes, i still have contact for ADI07:19
wolfspraulask them about C and D status07:19
wolfspraul7181C 7181D07:19
wolfspraullet's study D datasheet07:20
wolfspraulwith the intention being to answer the question "why don't we just skip the C and go to D directly?"07:20
cladamweasy, i can write email to know what difference between C & D, and why maybe D is the promotion one later...etc...07:20
wolfsprauland we need to study C vs D datasheet ourselves in parallel07:20
cladamwmail sent. hopefully they(contact here) can feedback soon.08:00
wolfspraulwe will try in Shanghai on Monday too08:03
wolfspraulthere are *lots* of distributors in China, easily 3-5 in Shanghai alone08:03
wolfspraulmeanwhile we need to compare the datasheets and decide whether we prefer C or D08:03
wpwrakcontacting ADI directly won't work ?08:04
wolfspraulsure, also why not08:06
wolfspraulbut most likely they will refer to a distributor08:06
wolfspraulADI in Shanghai is a development and china headquarter type thing08:06
wolfspraulwpwrak: didn't know you were back :-) do you see anything wrong with the D?08:06
wpwrakhaven't looked at the data sheet yet08:07
wolfspraulthe C was thought of as a superset/replacement of the B08:08
wolfsprauldon't know whether that is still the case with C -> D08:08
wpwrakfunny: SOG/SOY turned into SOY ;-)08:12
wpwrakah, and there's a separate pin for SOG now08:13
wpwrakserious reshuffling on the "east" side08:14
cladamwyes, 'east' side are different names.08:17
cladamwand their package are different too.08:18
wpwrakQFN. nice :)08:19
wpwrakwelcome to the modern age :)08:19
wpwrakof course, that means rework and such just got a little harder08:19
xiangfuwpwrak, I have a small patch on your werner m1 patches. :) send to you by email.08:22
xiangfuwpwrak, it's the video parameters patch. apply to rtems.08:23
xiangfumy 7 build on soc.fpg with different map parameter just finished.08:27
xiangfuwpwrak, hope you don't mind. I just add me to the 'Happy Crew' of wernermisc.git :D08:43
Action: xiangfu try to collect the NEXT features here: http://en.qi-hardware.com/wiki/Milkymist_One_Firmware#Next09:09
lekernelxiangfu: there are already pages for it http://www.milkymist.org/wiki/index.php?title=SoC_Roadmap http://www.milkymist.org/wiki/index.php?title=Flickernoise_roadmap09:19
lekernellet's not scatter this information all around ...09:20
xiangfulekernel, yes. I will update that page when release done. :)09:20
lekernelyou can update it now09:20
lekerneljust don't write the release date yet09:20
xiangfulekernel, ok. it still like draft. not sort. :)09:21
xiangfulekernel, I will improve it. day by day until the release date. :)09:21
xiangfudone. updated. also cleanup the 'Other ideas'09:30
xiangfulekernel, you may saw my email. on map -t xxx.09:33
xiangfulekernel, which one do you think it's better?09:33
lekernelthey're probably the same09:36
xiangfuyou mean -t 20 and -t 80?09:37
lekernelbut neither is really a good fix anyway09:37
lekernelit can break again at the slightest modification of the verilog source09:37
xiangfuI have no idea what those -t 20 and -t 80 means :(09:37
lekernelthey change the seed of the random number generator that the placer uses09:37
lekernelso this results in designs with slightly different I/O timings; some work, other don't09:38
lekernelsupposedly, it's using the I/O FFs which shouldn't cause this problems, but obviously there is something wrong09:40
xiangfuif we fix the issue. I think there is only one last thing to do before next release. the low level usb regression.09:42
wolfspraulwhat is the 'low level usb regression' exactly?09:54
xiangfuwolfspraul, some mouse not working. that is why werner bought a lot of mouse.09:57
xiangfuI can't re-produce the issue :( since all mouse works fine here.09:57
xiangfueven the MS Arc full speed mouse (of cause under the hid branch code)09:57
whitequarksorry what.09:57
whitequarkthe timings are affected by PRNG seed?!09:57
Action: whitequark prepends this to the list of greatest tech wtfs.09:58
lekernelyes, of course10:06
whitequarkerr, I meant a bit different thing10:06
whitequarkwhy does not PAR calculate the design in such a way that the difference in timings wouldn't signifucantly change the actual modus operandi?10:07
whitequarkis this a bug?10:07
lekernelthe placer uses a monte-carlo method to determine a close-enough-to-optimal placement. and the final placement affects timing.10:07
xiangfulekernel, so I just test -t 20 for now. since 'neither is really a good fix anyway'10:08
lekernelit does it, as long as the design is properly constrained. which I did about everywhere, but obviously not for the VGA DAC10:08
xiangfulekernel, I will commit the default build from -t 2 to -t 20. is that ok? for ISE 13.4 :)10:09
lekernelxiangfu: are the timing constraints met with 13.4?10:09
lekernel(in the PAR report)10:10
xiangfulekernel, how to check that? there is a BUILD_LOG: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120223-1842/BUILD_LOG10:10
xiangfulekernel, 13.2 works fine with -t 2, 13.4 works fine with -t 20.10:11
lekernel"All constraints were met."10:12
wolfspraullekernel: did you see the question about ADV7181C vs D? any comments?10:12
lekernelfor all bitstreams10:12
lekernelxiangfu: did you test the rescue bitstream for that VGA bug too?10:12
wolfspraulwe will find out soon about D availability etc. but the website says 'recommended for new designs' which leads one to believe that they think the D supersedes the C10:13
lekernelbut they'll probably keep the C for a long while, and we've already tested it and designed for it, so let's keep C for now10:13
wolfspraulsure but C availability may be worse than D (may)10:14
lekernelwe still can source the B so I'm not worried10:14
wolfspraulthat's how it all got started, because C is basically out of stock anywhere that octopart searches10:14
xiangfulekernel, rescue bitstream with VGA bug. no  testing rescu bitstream now.10:14
wolfspraulyes we can source them, in fact we need to find out more about that now10:14
lekerneland we can make that change at the time we get those sourcing problems10:14
lekernelsince the C design is already done, the cost is the same if we make that change now or later10:15
lekerneland switching to D now will increase R4 delays, which are not critical yet, but may become soon enough10:15
wolfspraulold ics never really disappear completely, just the moq goes up and sometimes you buy them from special companies that are re-running old ics10:15
whitequarklekernel: ah I got it, thanks for explanation10:15
wolfsprauldo you see anything technically in the D that may make you not want it?10:16
wolfspraulI will find out about sourcing C and D asap (early next week)10:16
lekernelI haven't looked at the D10:16
wolfspraulthe discussion started because adam's first thoughts on sourcing the C failed :-)10:16
lekernelwe have C sourcing problems? I thought it was even cheaper than B?10:17
wolfspraulnot a major issue, but if you just go to octopart, the C (or B or D) look out of stock almost everywhere10:17
wolfspraulwill get to the bottom of this asap, but that's how we noticed the D...10:18
lekernelat first sight it seems very close to the C, except that it's QFN and therefore will require PCB reroute10:18
wolfspraulit's friday evening in asia now, can't do much now but monday we know a lot more10:18
lekernelthe D datasheet was published in december ...10:18
wolfspraulalso 75mhz adc instead of 110mhz10:18
wolfspraulyes, maybe not available yet although adi site says 'production'10:19
lekernelProduction: At least one model within this product family is in production and available for purchase. The product is appropriate for new designs but newer alternatives may exist.10:19
wolfspraulI will find out the sourcing stuff monday/early next week, I am not worried at all10:19
lekerneland that's what ADI says about C10:19
wolfspraulwe just ran into the D today, that's all10:20
wolfspraulyes, but in octopart the C looks a lot less available than a few months ago, for whatever reason10:20
wolfspraulwill sort it out10:20
xiangfulekernel, the vga bug also fixed in rescue mode.10:20
lekernelwell, we never touch the ADCs directly atm10:20
wolfspraulto me it sounds like if they can achieve the same video quality with less mhz, that's a good thing?10:21
wolfspraulless mhz = less heat, less power, etc?10:21
wolfsprauljust guessing10:21
lekernelanyway for composite both 75MHz and 110MHz is more than enough10:21
wolfspraulthe D has less (75mhz)10:21
lekernelyes, I saw it10:22
GitHub84[milkymist] xiangfu pushed 1 new commit to hid: https://github.com/milkymist/milkymist/commit/df9d9dd44de2bd773be59f0e11327a18ea942d2610:22
GitHub84[milkymist/hid] adjust the map -t from 2 to 20 fit for ISE 13.4 - Xiangfu Liu10:22
xiangfu'hid' branch first. :-)10:22
lekernelProducing the same products decade after decade is a cornerstone of our business and we monitor our revenue by product vintage as a key performance metric. We believe obsolescence should be avoided as long as technology and customer demand exist for a product. And when it cant be avoided, customers are notified two years in advance.10:24
xiangfuwe need French translation on Bass, Mid, Treb, Channel (1-16): and Full Screen. try 'http://translate.google.com/10:43
xiangfu now10:43
xiangfuis those are ok: "Bass, Mid, Treb, Manche (1-16): Plein écran" ?10:44
lekernelchannel -> canal10:52
lekernelwhere do you have bass/mid/treb in the GUI?10:52
lekernelfor the level monitors?10:53
lekernelI think it's OK to leave them untranslated, since it will match the variable names10:53
xiangfuthe Audio settings. the level indicator.10:53
lekernelxiangfu: can you sync with RTEMS upstream before the release?10:54
xiangfulekernel, the latest rtems failed compile with flickernoise.10:54
lekernelmerge all patches, test the proposed DHCP change, and sort out the header files/exported functions10:54
lekernelyes I know, and that's exactly what I'm proposing to fix10:55
xiangfulekernel, ok. so we fix the 'static' under https://github.com/milkymist/rtems.git for now.10:57
lekernelcan we get it fixed in the official RTEMS repository instead?10:58
lekernelthis also breaks they very own DHCP client, so ...10:59
xiangfulekernel, I will try again. I have sent some email. but no one reply me :-)10:59
xiangfuif it needs too much time. maybe we use the rtems commit f80b3a3 'Date:   Wed Nov 30 06:58:36 2011 +0000'. fix those rtems next release.11:01
qi-botThe firmware build was successful, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120224-1036/11:16
cladamwlekernel, Do you know how 47 Ohm for DDC5V came from ? or did you reference to Xilinx ML401 or SP605 schematic of devel board while first initial draft for M1R1? or Altera ?11:23
wpwrakxiangfu: (happy crew) heh ;-) we should actually find a place somewhere in the milkymist-related gits for that patchset. having essential patches live under wernermisc doesn't feel quite right11:59
wpwrakxiangfu: but well, no hurry12:00
wpwrak(rtems) if we push stuff there, should we also convert the firmware upload to an ioctl ?12:13
lekernelthat could be a good idea, but then we need a nice place to store it12:17
lekernelbut one by one12:18
wpwrakhmm, yes. FN would have to include libhal or at least part of it. which afaik it currently doesn't12:27
wpwrakat least it would reduce the general level of dirtiness to that of libfpvm dependency resolution. already a great step forward :)12:28
lekernelwe should have a read-only mini-filesystem that comes with the FN binary12:29
lekernelwe'll need it at some point for fonts, icons, ...12:29
lekernelwould be a nice place for the USB firmware12:30
lekernelbut it's a bit of work, and there's no clean solution especially with the shitty RTEMS filesystem architecture12:30
lekernelI was thinking about concatenating a FAT image, it's not very efficient, but we still have space, and this way we do not have to touch ugly bits of RTEMS code12:31
GitHub40[flickernoise] xiangfu pushed 1 new commit to master: http://git.io/udSROg12:32
GitHub40[flickernoise/master] update french translations - Xiangfu Liu12:32
wpwrakhmm, do you even need a "real" file system ? shouldn't be too hard to cook up something that lets you look up a name and returns offset and length of the corresponding data12:36
wpwrakof course, if you want to access it, say, with ftp, that approach wouldn't be so nice12:36
Action: xiangfu waiting next build :)12:43
qi-botThe firmware (using branch) build was successful, checkout the VERSIONS for detail, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120224-1216/12:56
lekernelwhoa... I missed that one too http://www.xilinx.com/support/answers/41356.htm13:08
wpwrakthats related to video issue "fixed" by varying -t N ?13:09
lekernelno, absolutely nothing to do13:10
lekernelbasically it means "our IODELAY2 doesn't work at all on -1L devices" ...13:11
lekernelsince they require the IODELAY2 for most high speed interfaces, this is quite a limitation13:12
lekernel(I'm actually trying to extract some info from them about doing it without IODELAY2, because even though it works on the M1 FPGA, it is a little lousy too. but they seem to insist on me using it ...)13:13
lekernelanyway it seems I'm getting away without it. the problems I have atm with the DDR PHY sound unrelated.13:14
lekernelwe have a pretty wide timing margin anyway... we have good quality DDR chips :)13:16
wpwrakheh ;-)13:16
wpwrakit's quite impressive how many bugs those fpgas have. you'd think they're relative simple13:16
lekernelwork at Intel must be truly horrible. dealing with the x86 instruction set, having to get all sorts of Chinese DDR3 memory modules work with various motherboard layouts, etc.13:17
wpwrakyeah, or AMD. they eve have powerful GPUs thrown into the mix13:18
lekernelby the way, wasn't USB designed by Intel too ? (-:C13:20
wpwrakyeah. they've grown enough tough skin wrestling with x86 compatibility that nothing scares them anymore ;-)13:24
lekernelseems I got DRAM reads to work perfectly now, by heuristically playing with the command timings... now there's a gross simulation mismatch, but I don't know where it's coming from13:35
lekernelwrite got worse13:35
lekernellet's see if I can do some "adjustment" there as well ...13:35
larsclekernel: seems you are ahead of xilinx. their mig7 ddr core has a very high chance to lock up during calibration...13:42
lekernelgot the write DQS right. now the write data is 1/2 memory cycle too late. hmm...13:56
lekerneland unfortunately I can't play with the CAS latency here like I did for reads :(13:57
GitHub76[milkymist-ng] sbourdeauducq pushed 2 new commits to master: http://git.io/86hKKg14:11
GitHub76[milkymist-ng/master] ddrphy: partly working - Sebastien Bourdeauducq14:11
GitHub76[milkymist-ng/master] ddrphy: reads OK, write data coming out 1/2 cycle too late - Sebastien Bourdeauducq14:11
GitHub154[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/AOgHaQ14:21
GitHub154[milkymist-ng/master] ddrphy: request wrdata_en/rddata_en at the same time as the command - Sebastien Bourdeauducq14:21
lekernelalmost there. just a circular permutation of the four SERDES phases and it will work now...14:40
qi-botThe firmware build was successful, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120224-1406/14:46
lekernelworks! :)14:48
lekernelnow I just hope too many hideous critters are hidden under the bricolage... but I don't know if I should trust the simulation anyway14:48
lekernelthe sure way to know would be to hook up some expensive LA/scope to the memory14:49
GitHub60[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/H6HsSA14:50
GitHub60[milkymist-ng/master] ddrphy: working on hardware, simulation a bit messed up - Sebastien Bourdeauducq14:50
lekernelso, assuming there are no horrendous bugs hidden, we now have 10.6Gbps of potential memory bandwidth. now, let's design a good controller (I'm "bit banging" from software atm)14:53
wpwrakwhat's the per-migen memory bandwith ?15:09
lekernelwith a reordering controller I think we can have about 80% efficiency15:10
lekernelthat would be roughly 8Gbps available to the applications15:10
wpwrakoh, sorry. i meant "pre-migen". i.e., how much slower is the rest of us today ?15:11
lekernel2-3Gbps :)15:12
lekernelbut the new design will switch to 32bpp, which will already eat a lot of extra bandwidth15:12
wpwraka factor of two, no ? or are there nonlinear effects ?15:14
lekernelsince most of the transfers are pixel data, yes, about a factor of two15:14
lekerneland going 1024x768 is 2.5 more pixels ... hmm... that's tight15:15
lekernelbut I think 32bpp will improve the results more than increasing resolution15:16
wpwrak2*2.5*2 = 10, 3*2.5*2 = 15. seems it's either-or anyway.15:17
wpwrakhaving a bit of spare bandwidth would be good. e.g., for a larger overlay. or maybe for more image channels.15:18
lekernelwe could use two extra DDR chips on the M115:19
lekernelbut routing will be difficult, and it won't be compatible with old boards15:19
lekernelthat's the only difficulty though. DDR 2/3 bring in additional problems.15:20
lekernelmaybe for M2 :-)15:20
lekernelby the way, we're no longer using the proprietary NWL PHY15:28
lekernelit full of bugs anyway15:28
qi-botThe firmware (using branch) build was successful, checkout the VERSIONS for detail, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120224-1546/16:25
Hodappcjdavis2: wha? you're in here too?17:15
GitHub194[milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/72d30fa59b3b44eeed824216468de61b6c40d82819:37
GitHub194[milkymist/master] adjust the map -t from 2 to 20 fit for ISE 13.4 - Xiangfu Liu19:37
cjdavishodapp: yes19:50
lekernelomg the RTEMS DHCP/BOOTP code ...20:00
lekernelapparently their developer think it's cool not to use a .h file for function declarations, because then you can redeclare the function with the types that suit you when you want to use it20:01
GitHub17[rtems-yaffs2] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/rtems-yaffs2/commit/1a9b2b8dd64aa54d93afa4b22e159f22f718a2ea20:14
GitHub17[rtems-yaffs2/master] Remove fpathconf - Sebastien Bourdeauducq20:14
wpwraklekernel: kinda like OO ? :)20:15
Hodappwpwrak: no, that's for "modularity" or some horseshit like that20:22
lekernelI have FN working with upstream RTEMS now20:54
lekernel(and some patches ofc)20:55
lekernelbtw the new VGA timings cause no problems on my screen20:55
GitHub199[flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/lf1fqw21:00
GitHub199[flickernoise/master] filemanager: use function prototypes from rtems/shell.h - Sebastien Bourdeauducq21:00
qi-botThe firmware build was successful, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120224-2040/21:19
lekernelhttps://www.rtems.org/bugzilla/show_bug.cgi?id=1841 : 51 lines of patch, 3 bugs. who would have thought removing existing DNS servers on a DHCP request would have been so complicated?22:06
larscand O(n**2) running time22:15
GitHub43[flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/6uuWUA22:28
GitHub43[flickernoise/master] Update copyright year in about box - Sebastien Bourdeauducq22:28
GitHub97[milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/1631e96039bed2cff26435b98ef969538987442f22:37
GitHub97[milkymist/master] README: update - Sebastien Bourdeauducq22:37
GitHub197[milkymist] sbourdeauducq pushed 3 new commits to master: https://github.com/milkymist/milkymist/compare/1631e96...6bc8e0222:50
GitHub197[milkymist/master] README: update directory structure - Sebastien Bourdeauducq22:50
GitHub197[milkymist/master] libfpvm: remove broken depend target - Sebastien Bourdeauducq22:50
GitHub197[milkymist/master] softusb-input: make generated include installable - Sebastien Bourdeauducq22:50
qi-botThe firmware (using branch) build was successful, checkout the VERSIONS for detail, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120224-2219/22:59
--- Sat Feb 25 201200:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!