Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
elldekaa has joined #milkymist
cladamw has joined #milkymist
<cladamw> morning :)
<cladamw> wpwrak, 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.
<wolfspraul> good morning
<wolfspraul> every feature adds complexity, cost, etc. needs to be tested, needs to actually work well, and so on.
<wolfspraul> what is this feature about?
<cladamw> btw, I'll finish order on few parts to prepare them for goals about layout need and check real part's package myself and tests.
<cladamw> wolfspraul, for this DDC 5V limiter switch, I'll order few to test first, so not yet edited into draft.
<wolfspraul> the particular EN/Fault pin back to the fpga - what is it for?
<wolfspraul> which use case is this?
<cladamw> since 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.
<wolfspraul> someone plugs in a DVI-I monitor, then what?
<wolfspraul> my feeling (and feeling only) on this switch is that we overdo it a little, just reading from the distance
<wolfspraul> we don't know any actual use case, we just implement stuff based on paper (specs)
<wolfspraul> maybe not a single real-life use case exists? :-)
<wolfspraul> but 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...
<cladamw> my thinking is quite same as Sebastien though but without EN and Fault features just switch itself ( 50mA limit goal )
<wolfspraul> sure
<wolfspraul> who cares about this 'limit' anyway? I don't know
<cladamw> with Fault pin, we can know a real over current happened so fpga can be as indicator then do something
<wolfspraul> seems like just some number written into the spec so that both sides can engineer their power circuit against some number
<wolfspraul> then do what?
<wolfspraul> the m1 is not lab test equipment...
<cladamw> with EN pin, fpga can do re-enable DCC5V after external over-voltage (output > input),
<wolfspraul> but we don't know whether a single such case actually exists
<cladamw> i'm trying to describe what i saw different views on this limit switch though. :)
<wolfspraul> to me it sounds like no value, just sandbagged around a paper spec
<cladamw> like 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."
<wolfspraul> no idea
<wolfspraul> I'm just trying to understand the en/fault line back to fpga
<wolfspraul> and I don't understand it's usefulness (use case)
<wolfspraul> so without use case - don't do it
<cladamw> if 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. ;-)
<wolfspraul> I have no comment on electrical preferences
<wolfspraul> something is 'good', but what is good? :-) you guys have to find out
<cladamw> from my idea to brainstorming with Werner then, we listed three total solutions on this.
<wolfspraul> yes, not again
<wolfspraul> I have no comment on those
<cladamw> :-)
<wolfspraul> maybe they are actually very similar, that's why it's hard to pick :-)
<wolfspraul> no clear pro/con for any one of them... so don't get stuck
<wolfspraul> pick what werner likes
<cladamw> man
<wolfspraul> I was just commenting on the line back to the fpga
<wolfspraul> you say "fpga can reenable 5v after external overvoltage"
<wolfspraul> so what?
<wolfspraul> when does this case happen?
<wolfspraul> it sounds very theoretical, just working along paper
<wolfspraul> oh, this case, oh that case. but do they exist?
<cladamw> you know Werner's thinking. then "pick what werner likes" again.
<wolfspraul> how strongly does werner feel about the fault line?
<cladamw> so i tried to ask Werner that Sebestien's feedabck on EN/FAULT . ;-)
<wolfspraul> yes
<wolfspraul> and since he seems currently offline, we chat a little :-)
<cladamw> phew...
<wolfspraul> I think the fault line provides little value, I don't understand the use case
<wolfspraul> I would do this on a devel board, or if m1 is lab test equipment
<wolfspraul> but how many actual consumer products with dvi-i would have such a 'bring 5v back after external over-voltage' feature?
<wolfspraul> my gut feeling is: none :-)
<wolfspraul> what do you think?
<cladamw> that's why i was trying to ask how's wener's thinking now.
<wolfspraul> sure
<wolfspraul> how many dvi consumer products do you think would have this?
<wolfspraul> I think none, nobody
<cladamw> sure I've had said that I quite same as Sebestien's thinking. Just switch itself but no EN/Fault pins toward/from fpga. ;-)
<wolfspraul> ok
<wolfspraul> so sebastien you me all feel the same
<wolfspraul> my comment is purely gut feeling though
<cladamw> but needs to chat with Werner about this though. :-)
<wolfspraul> so let's see how stronlgy werner feels for it
<wolfspraul> maybe he concedes that it's excessive and facing such overwhelming 3:1 opposition he retreats? :-)
<wolfspraul> or maybe he totally thinks this has to be there...
<cladamw> maybe he went to dentist... he'll head up.
<wolfspraul> dentist, urgh
<wolfspraul> fault line?
<wolfspraul> maybe the dentist needs to rip out some fault lines leeding from his teeth to his brain :-)
<cladamw> no, he said before that he'll go to dentist.
<cladamw> oah...:)
<wolfspraul> cladamw: I am finally looking over the insertion/removal detection at http://en.qi-hardware.com/wiki/Milkymist_One_RC3_Known_Issues#R4_draft_feedback
xiangfu has joined #milkymist
<wolfspraul> so let's see. for ethernet and usb, it's sufficiently built into the protocol at higher levels.
<wolfspraul> "dc power in"? don't understand
<wolfspraul> how could we not detect that - I mean without power m1 will not run at all, right?
<wolfspraul> seems kinda implicit to me, as long as m1 doesn't have a secondary power source like battery or so
<wolfspraul> audio line-in/out - we added it in R4 - great
<wolfspraul> dvi-i, same - great
<wolfspraul> midi, dmx and video-in - seems not
<cladamw> "dc power in" solution for insertion/removal already done in draft sch. ;-)
<wolfspraul> ok
<wolfspraul> but what does it mean?
<cladamw> if I marked "yes" means draft is done. ;-)
<wolfspraul> if there is no cable in dc power, then m1 is off, no?
<wolfspraul> I don't understand the "dc power in" detection
<wolfspraul> if someone unplugs it, m1 will immediately shutoff
<wolfspraul> no?
<cladamw> yes, m1 is off when no cable in dc power.
<wolfspraul> so what is being 'detected' then?
<wolfspraul> the detection is death
<wolfspraul> :-)
<wolfspraul> or we have some milliseconds to turn off something?
<cladamw> if unplugged (no cable) then power LED is off (but hardware) directly, no milliseconds such features. ;-)
<cladamw> if plugging, power led in ON, then fpga can override power led.
<wolfspraul> ok
<wolfspraul> that's what you mean with 'detection'?
<cladamw> yes,
<wolfspraul> ah ok
<wolfspraul> my understanding of the word 'detection' was more that the m1 is running, and then 'detects' something
<cladamw> power is power, when no power in, no such real insertion/removal features though.
<wolfspraul> with the dc power cable being the only power source that's not really possible
<wolfspraul> yes
<wolfspraul> if we would support a battery, then it would be different
<wolfspraul> then m1 could really *detect* the dc cable insertion/removal
<wolfspraul> but ok, I got it. you mean the led and led override...
<cladamw> sure that insertion/removal is exactly the idea same as you when we talk in audio-line-in/out. ;-)
<wolfspraul> ok, that leaves midi, dmx and video-in
<cladamw> yes, overriding.
<cladamw> maybe i seperate "dc power in" out.
<wolfspraul> for video-in, does the adi adc chip have some detect feature?
<cladamw> in that wiki, too confusing you. sorry.
<wolfspraul> oh no problem
<cladamw> yes, video-in decoder can detect it by scanning reg setting.
<wolfspraul> I am editing it
<wolfspraul> scanning reg setting, hmm
<cladamw> ha, 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.
<cladamw> but not real by hardware's insertion/removal, so I currently have no idea on this RCA connector. :(
<wolfspraul> I'm wondering whether software needs to poll that settings constantly, or whether there's a way to generate an interrupt or so upon insertion
<wolfspraul> ok, we will find out that one
<wolfspraul> then dmx and midi
<wolfspraul> for midi, werner should know whether there is value in adding detection
<wolfspraul> adding it would mean that we need to find another connector?
<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)
<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.
<wolfspraul> yes, 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.
<wolfspraul> cladamw: oh, for midi we can sense it on the software side?
<wolfspraul> when werner is back, we can discuss video-in and midi first
<wolfspraul> dmx last, I guess :-) even though I think there are real business opportunities and good use cases in dmx, seems it's always last :-)
<cladamw> (midi TX) no both h/w & f/w
<cladamw> (midi RX) no h/w, but can be done on f/w. ;-)
<wolfspraul> ok, so it's a similar question to video-in, how elegant software can do it, and whether hw can help sw in any way...
<cladamw> okay, let's reviewed them again when werner is back. I always put irc links in that wiki pages.
<cladamw> so sure when werner is back then we item by item to review.
<wolfspraul> ok
<wolfspraul> if he survives the dentist
<cladamw> but how he thought on f/w can do , well. i don't know f/w. ;-)
<wpwrak> (reading backlog) dentist was yesterday. my dental armament has now been fully restored :)
<wpwrak> today's task was bringing the apartment in a presentable shape. a friend is stopping over for a couple of days.
<wpwrak> regarding 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.
<wpwrak> the 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 :)
<wpwrak> midi: 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"
<wpwrak> none of digi-key, farnell, or mouser seem to have din receptacles with a switch
<wpwrak> so i would consider them either exceedingly rare or a myth. or i have to work on my database searching skills :)
<cladamw> (midi DIN 5 pin with switch?) sounds good.
<wpwrak> an 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.
<wolfspraul> I don't consider it likely that there will be "problems with that connector"
<wpwrak> which connector ?
<wolfspraul> cladamw: no, does not sound good, sounds totally unsourcable and leading in the wrong direction.
<wpwrak> dvi ?
<cladamw> (en/fault) wpwrak, so you still want both of them now.
<wolfspraul> dcc5v/ddc (replying to you above)
<wolfspraul> no, we don't have a use case. we just add stuff because we don't know, which is unsustainable imho.
<wolfspraul> if there is a problem, we need to find out about the problem first
<cladamw> (midi connector) wolfspraul, needs to find again, if Mouser have it, still good.
<wpwrak> cladamw: i want fault more than en. if a non-transient short-circuit event happens, we'd be very interested in knowing about it.
<wpwrak> cladamw: enable is in the "why not" category
<wolfspraul> but 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?
<wolfspraul> my gut feeling tells me - nobody
<wolfspraul> we cannot protect against every conceivable electrical oddity
<wpwrak> cladamw: (midi connector) i checked digi-key, farnell, and mouser and didn't find anything that looked right
<wpwrak> cladamw: i didn't check arrow, though
<wolfspraul> question is what dvi-i devices people will typically connect, and how they will typically behave
<wpwrak> wolfspraul: if you expect DCC5V to never fail, just connecting it to 5V and skip all the protection
<wolfspraul> already clear that it's the wrong path...
<wolfspraul> if digikey farnell and mouse all don't have something - big no no :-)
<wpwrak> wolfspraul: worst case: the main fuse trips and/or the connector overheats
<wolfspraul> what does 'fail' mean?
<wolfspraul> what do other consumer electronics do?
<cladamw> wpwrak, phew...oah..sorry i misunderstood, three sources don't have it( not only digikey). got it.
<wolfspraul> worst case a lightning hits your home
<wolfspraul> what do other consumer electronics do?
<wolfspraul> let's say "the best" :-) (=apple :-))
<wolfspraul> (just kidding)
<wolfspraul> wpwrak: what kind of 'failure' do you think about?
<cladamw> but the main fuse get lightning is rarely low i think. also if we use Molex DVI-I connector ( would it be easiler to overheat ?)
<wpwrak> a short to ground
<cladamw> well. although it always have the possibility. ;-)
<wolfspraul> how likely is that to happen?
<wpwrak> if 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.
<wpwrak> no idea
<wpwrak> cladamw: i haven't seen any electrical characteristics in the molex data sheet
<wpwrak> cladamw: the DVI spec you found says 1 A.
<wpwrak> we'd trip at 2 A
<cladamw> seens 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 ?
<wolfspraul> now 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.
<wolfspraul> but the fault lines seem excessive
<wolfspraul> even 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)
<wpwrak> i really don't see why the fault line would be a big deal
<wolfspraul> far 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.
<wolfspraul> maybe m1 should have some circuit to remote-fix the broken equipment on the other side? :-)
<cladamw> wpwrak, oah, yeah...2 A > 1A, then lightning is possible, but would be rarely happened ? ;-)
<wolfspraul> adam needs to know whether the fault line is optional or not, so routing has the option to remove it if needed
<wolfspraul> to me it sounds very very optional, just trying to add my superficial perspective though
<wolfspraul> we are operating in an area where we are multiple indirections removed from actual use cases
<wolfspraul> so I am trying to find out the use cases that drive this as well, but seems there are none
<wolfspraul> which now makes me wonder - what do other consumer electronics do about this?
<wolfspraul> and: we don't know (again)
<wolfspraul> that's all
<wolfspraul> line added or not I don't care, but it seems like a line without value to me
<wolfspraul> can we easily find/compare with schematics of other consumer electronics?
<wolfspraul> oops, disconnected
wolfspraul has joined #milkymist
<wolfspraul> oops, disconnected
<wolfspraul> so I would compare with other consumer electronics, or pull in/find some experience (people who have worked on dvi/ddc before)
<wolfspraul> I think if Adam knows the line is optional, that could help routing if space is tight
<wpwrak> yes, assigning a low priority to is sounds reasonable
<wpwrak> s/is/it/
<wolfspraul> cool
<wolfspraul> and we should keep our eyes open how other well designed consumer electronics handle this
<wpwrak> but 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 matter
<wpwrak> pry open that high-end sony laptop ;-)
<wolfspraul> my feeling is that even most well designed equipment would at least stop working when a voltage-out from that device is shorted to ground
<wolfspraul> the 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.
<wolfspraul> a 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 now
<cladamw> (contact current rating = 1.5 A minimum) wpwrak, yes, in page 50. ;-)
<wolfspraul> cladamw: are we clear on the dcc voltage now? keep the micrel part but the fault line is optional
<wolfspraul> I think that's the bottom line
<wolfspraul> and I still want to understand how others implement this :-)
<wolfspraul> maybe William knows and can have a quick look at some schematics, I will ask him
<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 ?
<wolfspraul> en is already agreed to be really useless
<wolfspraul> en = ability to enable/disable the current switch?
<cladamw> to 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.
<wolfspraul> cladamw: we are talking about 2 lines? 1 is enable, 1 is fault?
<cladamw> yes, two lines (en & fault), 'en' to let m1 to re-enable switch after m1 knows a overcurrent or short happened from 'fault' pin.
<cladamw> so werner actually would like both lines.
<wolfspraul> no I don't think so, he just describes some marginal cases that justify why we even talk about them
<wolfspraul> both are optional, en even less valuable than fault I think
<wolfspraul> cladamw: if the entire switch is gone, and someone shorts the 5V to gnd, will m1 have permanent hardware damage?
<cladamw> when 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.
<wolfspraul> yes but those use cases don't exist
<wolfspraul> it's pure imagination
<wolfspraul> which we will see when we study what other consumer electronics do, surely
<cladamw> if no switch with short, then we see lightning somewhere in m1 board. ;-)
<wolfspraul> permanent hw damage?
<cladamw> it's a RMA issue to sevice people then. ;-)
<wolfspraul> what happens on the m1 board then - which part breaks?
<cladamw> it could be damaged somewhere if main fuse not immedately trips.
<wolfspraul> if?
<wolfspraul> but we have a fuse
<wolfspraul> fuse trips
<wpwrak> just posted a bit of an analysis to the list :)
<wolfspraul> sounds like we don't know whether a 5v to gnd short would permanently damage m1
<cladamw> 5V traces on m1 would be deteriorated if main fuse doesn't trip firstly.
<wolfspraul> *if* again :-)
<wolfspraul> but we have a fuse
<wolfspraul> either we trust our electrical design or not
<wolfspraul> if we don't trust it (another 'if'), then that's something to work on :-)
<wolfspraul> anyway, the micrel part sounds good
<wolfspraul> let's favor speed
<cladamw> before reset ic to reset m1, still could be somewhere failure.
<wolfspraul> yeah but we don't know
<cladamw> wpwrak, ha...saw it.
<wolfspraul> lots of unknowns which we fight with more parts
<wolfspraul> which of course add more unknowns
<wolfspraul> one day we compare with a well designed high-volume electronic, then we have a reference
<wolfspraul> then no guessing around in 'don't know land'
<cladamw> if no witch, overheating could be somewhere then m1 's 5V rail from dc power in to nearby dvi-i connector being deteriorated.
<wolfspraul> maybe the micrel part will not work on some boards? :-)
<wpwrak> (1.5 A) ah, even better
<wolfspraul> you guys decide what is 'good design'
<wolfspraul> I will wait until I have a high-volume schematic to compare with
<wpwrak> gotta run. guest arriving.
<wpwrak> and yes, i would expect the fuse to blow long before anything else happens. else, what's the point :)
<cladamw> sorry i can't wait, since i have to edit schematic firstly then house can evaluate them once I send to them.
<wolfspraul> the ability to provide more power (say 200mA) may even be a feature :-)
elldekaa has joined #milkymist
<wolfspraul> after more thinking, now I wouldn't add the switch at all
<wolfspraul> that way the en/fault problem goes away as well :-)
<wolfspraul> the overheating and 'main fuse doesn't work' cases appear baseless/random
<cladamw> wolfspraul, so i follow you or 'pick what werner likes' ? ;-)
<wolfspraul> what do *you* think?
<wolfspraul> I think about it now... from werner's last mail, I'd say why have this switch at all?
<wolfspraul> removing parts is a big pro in itself, and there doesn't seem to be a strong reason against removing the part
<wolfspraul> cladamw: you have seen plenty of schematics as well, how would a well designed high-volume electronic address this issue, probably?
<wolfspraul> cladamw: maybe leave it open for today, everybody can think about it more over the weekend, maybe we find some additional feedback from someone with experience
<wolfspraul> but if you were the only person on this project, what would *you* decide?
<wolfspraul> if you are building this device only for your own home use...
<cladamw> wolfspraul, 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. ;-)
<wolfspraul> that'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?
<wolfspraul> would you add the micrel part or not?
<cladamw> ha...good question about if 'only' me for this project: then I determine then stick on two 1206s resistors. ;-)
<wolfspraul> aha, that's an answer. thanks!
<cladamw> wolfspraul, phew...man...
<wolfspraul> I feel similar. keep it simple, this dcc5v case is a rare & marginal case, and these cases of overcurrent and short simply will not happen.
<cladamw> but you still can't against all ideas here and there. ;-)
<wolfspraul> unless the monitor is broken itself, and as long as our device (m1) doesn't get a *permanent* damage, I wouldn't go beyond that
<wolfspraul> why not, we are discussing and that is good. one day we may realize this is important.
<wolfspraul> cladamw: can you keep this open over the weekend? werner is out now...
<cladamw> hehe...we surely need to keep minds in commecial thinking/ value/ time/ cost/ ...i know you will lead to this way...
<cladamw> wolfspraul, i'll keep maybe one or half to work others
<wolfspraul> I'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.
<wolfspraul> replied on the list, my 2c :-)
<cladamw> I'll no action now from "maybe leave it open for today, everybody can think about it more over the weekend". ;-)
<wpwrak> almost out :)
<wpwrak> one possible issue could be inrush current. e.g., if someone puts a HUGE cap on DCC5V, it could trip our reset chip
<cladamw> you meant at monitor manufacturer side?
<wpwrak> of course, we have something like 300 uF on our side to fight back
<wpwrak> yes, in the monitor
<cladamw> present draft C188 for J17:14 (DDC5V) in m1 is 1uF.
<wpwrak> btw, wher did that 47 Ohm resistor come from ? is this copied from someone's reference design ?
<wpwrak> yes, but we also have C286 on 5V
<cladamw> 47 Ohm came from Sebestien first version. Don't know if he copied somewhere. good question
<cladamw> mmm...C286
<wpwrak> (47 Ohm) ok. let's find out.
<wpwrak> pity that the DVI spec is so incomplete. doesn't mention inrush current at all. USB is sheer pleasure in comparison.
<wpwrak> okay, now i'm off for a while
<cladamw> cu
<cladamw> good, Xilinx SP605 has DVI circuit, but no DDC5V directly connects to 5V with 0.1uF only.
<cladamw> man~its protections on DVI's differential are more than M1R4. well. we're not doing this way.
<wolfspraul> that's a devel board
<wolfspraul> on a devel board, you can throw all sorts of things on for various reasons, that may increase the value of the devel board
<wolfspraul> we need to compare with high-volume products
<cladamw> yup. we're not doing devel board.
<wolfspraul> on that devel board, dcc5v is just connected to 5V directly with only a 0.1uF on it?
<cladamw> m1r1 should be copied somewhere from xilinx or altera reference design
<cladamw> yes, directly connect. no specific protection on DDC5V.
<cladamw> i'm out now.
<cladamw> back soon.
<wolfspraul> k l8
<wolfspraul> I'll get some lunch as well :-)
cladamw has joined #milkymist
<cladamw> from its VGA sch, the DSUB even NC on its pin 9 of vga connector, mmm...so probably not referenced from it. :-)
<cladamw> (ADV7181CBSTZ) bad news ! out of stocks after found in http://octopart.com/partsearch#search/requestData&q=ADV7181CBSTZ
<cladamw> last time I ordered from AVNET.
<cladamw> we 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.
<wolfspraul> no
<wolfspraul> wrong
<wolfspraul> the B is already super old
<wolfspraul> whatever happened to the C we need to find out, and then move *forward*, not backward
<cladamw> mmm...
<wolfspraul> what is the diff between 7181C and 7180B ?
<wolfspraul> seems the 7180B is in stock, checking datasheet
<wolfspraul> also look on the adi site, maybe they have information on the 7181C
<cladamw> checking...
<wolfspraul> thanks
<wolfspraul> true, but not in stock yet
<wolfspraul> I can only find info about the 7181C status 'in production' on the adi site, nothing about the D
<wolfspraul> if the C is in production, we can try at ADI's china distributors, they should be well stocked I would think
<wolfspraul> going 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.
<wolfspraul> D is also listed 'in production', but tray size 260 instead of 160 for the C
<wolfspraul> can'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.
<cladamw> yup..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.
<wolfspraul> the top feature I see on the C list is "chinese data sheet available" (!)
<cladamw> yup. i saw also
<wolfspraul> from a quick look at octopart, it seems neither C nor D are easily sourcable. so maybe we try at ADI's official china distributor?
<wolfspraul> let's do this: first we study the D datasheet, see whether we prefer C or D
<cladamw> man! just don't know exactly why octopart,
<cladamw> doesn't have it.
<wolfspraul> octopart is just a database aggregator, so those websites just don't have them
<wolfspraul> let's first find out about the D now
<wolfspraul> it's recommended for new designs...
<wolfspraul> then we try to contact ADI's official China distributor on Monday
<cladamw> not sure this condition is the same as firstly we source spartan-6, in digikey they were not preparing it then.
<cladamw> yeah
<wolfspraul> you can try to get the C or D at arrow in taipei
<wolfspraul> do you have a contact there? seems arrow has a lot of ADI stuff
<wolfspraul> but first I think let's study the D datasheet
<cladamw> yes, i still have contact for ADI
<wolfspraul> perfect
<wolfspraul> ask them about C and D status
<wolfspraul> 7181C 7181D
<wolfspraul> let's study D datasheet
<wolfspraul> with the intention being to answer the question "why don't we just skip the C and go to D directly?"
<cladamw> easy, i can write email to know what difference between C & D, and why maybe D is the promotion one later...etc...
<wolfspraul> yes
<wolfspraul> and we need to study C vs D datasheet ourselves in parallel
<cladamw> mail sent. hopefully they(contact here) can feedback soon.
<wolfspraul> we will try in Shanghai on Monday too
<wolfspraul> there are *lots* of distributors in China, easily 3-5 in Shanghai alone
<wolfspraul> meanwhile we need to compare the datasheets and decide whether we prefer C or D
<wpwrak> contacting ADI directly won't work ?
<wolfspraul> sure, also why not
<wolfspraul> but most likely they will refer to a distributor
<wolfspraul> ADI in Shanghai is a development and china headquarter type thing
<wolfspraul> wpwrak: didn't know you were back :-) do you see anything wrong with the D?
<wpwrak> haven't looked at the data sheet yet
<wolfspraul> the C was thought of as a superset/replacement of the B
<wolfspraul> don't know whether that is still the case with C -> D
<wpwrak> funny: SOG/SOY turned into SOY ;-)
<wpwrak> ah, and there's a separate pin for SOG now
<wpwrak> serious reshuffling on the "east" side
<cladamw> yes, 'east' side are different names.
<cladamw> and their package are different too.
<wpwrak> QFN. nice :)
<wpwrak> welcome to the modern age :)
<wpwrak> of course, that means rework and such just got a little harder
<xiangfu> wpwrak, I have a small patch on your werner m1 patches. :) send to you by email.
<xiangfu> wpwrak, it's the video parameters patch. apply to rtems.
<xiangfu> my 7 build on soc.fpg with different map parameter just finished.
<xiangfu> testing....
<xiangfu> wpwrak, hope you don't mind. I just add me to the 'Happy Crew' of wernermisc.git :D
* xiangfu try to collect the NEXT features here: http://en.qi-hardware.com/wiki/Milkymist_One_Firmware#Next
<lekernel> let's not scatter this information all around ...
<xiangfu> lekernel, yes. I will update that page when release done. :)
<lekernel> you can update it now
<lekernel> just don't write the release date yet
<xiangfu> lekernel, ok. it still like draft. not sort. :)
<xiangfu> lekernel, I will improve it. day by day until the release date. :)
<xiangfu> done. updated. also cleanup the 'Other ideas'
<xiangfu> lekernel, you may saw my email. on map -t xxx.
<xiangfu> lekernel, which one do you think it's better?
<lekernel> they're probably the same
<xiangfu> you mean -t 20 and -t 80?
<lekernel> but neither is really a good fix anyway
<lekernel> yes
<lekernel> it can break again at the slightest modification of the verilog source
<xiangfu> I have no idea what those -t 20 and -t 80 means :(
<lekernel> they change the seed of the random number generator that the placer uses
<lekernel> so this results in designs with slightly different I/O timings; some work, other don't
<lekernel> supposedly, it's using the I/O FFs which shouldn't cause this problems, but obviously there is something wrong
<xiangfu> if we fix the issue. I think there is only one last thing to do before next release. the low level usb regression.
<wolfspraul> what is the 'low level usb regression' exactly?
<xiangfu> wolfspraul, some mouse not working. that is why werner bought a lot of mouse.
<xiangfu> I can't re-produce the issue :( since all mouse works fine here.
<xiangfu> even the MS Arc full speed mouse (of cause under the hid branch code)
<whitequark> sorry what.
<whitequark> the timings are affected by PRNG seed?!
* whitequark prepends this to the list of greatest tech wtfs.
<lekernel> yes, of course
<whitequark> err, I meant a bit different thing
<whitequark> why does not PAR calculate the design in such a way that the difference in timings wouldn't signifucantly change the actual modus operandi?
<whitequark> is this a bug?
<lekernel> the placer uses a monte-carlo method to determine a close-enough-to-optimal placement. and the final placement affects timing.
<xiangfu> lekernel, so I just test -t 20 for now. since 'neither is really a good fix anyway'
<lekernel> it does it, as long as the design is properly constrained. which I did about everywhere, but obviously not for the VGA DAC
<xiangfu> lekernel, I will commit the default build from -t 2 to -t 20. is that ok? for ISE 13.4 :)
<lekernel> xiangfu: are the timing constraints met with 13.4?
<lekernel> (in the PAR report)
<xiangfu> lekernel, 13.2 works fine with -t 2, 13.4 works fine with -t 20.
<lekernel> "All constraints were met."
<wolfspraul> lekernel: did you see the question about ADV7181C vs D? any comments?
<lekernel> for all bitstreams
<lekernel> xiangfu: did you test the rescue bitstream for that VGA bug too?
<wolfspraul> we 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 C
<lekernel> but 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 now
<wolfspraul> sure but C availability may be worse than D (may)
<lekernel> we still can source the B so I'm not worried
<wolfspraul> that's how it all got started, because C is basically out of stock anywhere that octopart searches
<xiangfu> lekernel, rescue bitstream with VGA bug. no testing rescu bitstream now.
<wolfspraul> yes we can source them, in fact we need to find out more about that now
<lekernel> and we can make that change at the time we get those sourcing problems
<lekernel> since the C design is already done, the cost is the same if we make that change now or later
<lekernel> and switching to D now will increase R4 delays, which are not critical yet, but may become soon enough
<wolfspraul> old ics never really disappear completely, just the moq goes up and sometimes you buy them from special companies that are re-running old ics
<whitequark> lekernel: ah I got it, thanks for explanation
<wolfspraul> do you see anything technically in the D that may make you not want it?
<wolfspraul> I will find out about sourcing C and D asap (early next week)
<lekernel> I haven't looked at the D
<wolfspraul> the discussion started because adam's first thoughts on sourcing the C failed :-)
<lekernel> mh?
<lekernel> we have C sourcing problems? I thought it was even cheaper than B?
<wolfspraul> not a major issue, but if you just go to octopart, the C (or B or D) look out of stock almost everywhere
<wolfspraul> will get to the bottom of this asap, but that's how we noticed the D...
<lekernel> at first sight it seems very close to the C, except that it's QFN and therefore will require PCB reroute
<wolfspraul> it's friday evening in asia now, can't do much now but monday we know a lot more
<lekernel> the D datasheet was published in december ...
<wolfspraul> also 75mhz adc instead of 110mhz
<wolfspraul> yes, maybe not available yet although adi site says 'production'
<lekernel> Production: 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.
<wolfspraul> I will find out the sourcing stuff monday/early next week, I am not worried at all
<lekernel> and that's what ADI says about C
<wolfspraul> we just ran into the D today, that's all
<wolfspraul> yes, but in octopart the C looks a lot less available than a few months ago, for whatever reason
<wolfspraul> will sort it out
<xiangfu> lekernel, the vga bug also fixed in rescue mode.
<lekernel> well, we never touch the ADCs directly atm
<wolfspraul> to me it sounds like if they can achieve the same video quality with less mhz, that's a good thing?
<wolfspraul> less mhz = less heat, less power, etc?
<lekernel> maybe
<wolfspraul> just guessing
<lekernel> anyway for composite both 75MHz and 110MHz is more than enough
<wolfspraul> the D has less (75mhz)
<lekernel> yes, I saw it
<GitHub84> [milkymist] xiangfu pushed 1 new commit to hid: https://github.com/milkymist/milkymist/commit/df9d9dd44de2bd773be59f0e11327a18ea942d26
<GitHub84> [milkymist/hid] adjust the map -t from 2 to 20 fit for ISE 13.4 - Xiangfu Liu
<xiangfu> 'hid' branch first. :-)
<lekernel> Producing 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 can’t be avoided, customers are notified two years in advance.
elldekaa has joined #milkymist
<xiangfu> we need French translation on Bass, Mid, Treb, Channel (1-16): and Full Screen. try 'http://translate.google.com/
<xiangfu> now
<xiangfu> is those are ok: "Bass, Mid, Treb, Manche (1-16): Plein
rejon has joined #milkymist
<lekernel> channel -> canal
<xiangfu> ok.
<lekernel> where do you have bass/mid/treb in the GUI?
<lekernel> for the level monitors?
<lekernel> I think it's OK to leave them untranslated, since it will match the variable names
<xiangfu> the Audio settings. the level indicator.
<xiangfu> ok.
<lekernel> xiangfu: can you sync with RTEMS upstream before the release?
<xiangfu> lekernel, the latest rtems failed compile with flickernoise.
<lekernel> merge all patches, test the proposed DHCP change, and sort out the header files/exported functions
<lekernel> yes I know, and that's exactly what I'm proposing to fix
<xiangfu> lekernel, ok. so we fix the 'static' under https://github.com/milkymist/rtems.git for now.
<lekernel> can we get it fixed in the official RTEMS repository instead?
<lekernel> this also breaks they very own DHCP client, so ...
<lekernel> their
<xiangfu> lekernel, I will try again. I have sent some email. but no one reply me :-)
<xiangfu> if 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.
<xiangfu> :)
<qi-bot> The firmware build was successful, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120224-1036/
<cladamw> lekernel, 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 ?
<wpwrak> xiangfu: (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 right
<wpwrak> xiangfu: but well, no hurry
elldekaa has joined #milkymist
<wpwrak> (rtems) if we push stuff there, should we also convert the firmware upload to an ioctl ?
<lekernel> that could be a good idea, but then we need a nice place to store it
<lekernel> but one by one
ab5tract has joined #milkymist
<wpwrak> hmm, yes. FN would have to include libhal or at least part of it. which afaik it currently doesn't
<wpwrak> at least it would reduce the general level of dirtiness to that of libfpvm dependency resolution. already a great step forward :)
<lekernel> we should have a read-only mini-filesystem that comes with the FN binary
<lekernel> we'll need it at some point for fonts, icons, ...
<lekernel> would be a nice place for the USB firmware
<lekernel> but it's a bit of work, and there's no clean solution especially with the shitty RTEMS filesystem architecture
<lekernel> I 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 code
<GitHub40> [flickernoise] xiangfu pushed 1 new commit to master: http://git.io/udSROg
<GitHub40> [flickernoise/master] update french translations - Xiangfu Liu
<wpwrak> hmm, 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 data
<wpwrak> of course, if you want to access it, say, with ftp, that approach wouldn't be so nice
* xiangfu waiting next build :)
<qi-bot> The firmware (using branch) build was successful, checkout the VERSIONS for detail, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120224-1216/
sh4rm4 has joined #milkymist
<lekernel> whoa... I missed that one too http://www.xilinx.com/support/answers/41356.htm
<wpwrak> thats related to video issue "fixed" by varying -t N ?
<lekernel> no, absolutely nothing to do
<lekernel> basically it means "our IODELAY2 doesn't work at all on -1L devices" ...
<lekernel> since they require the IODELAY2 for most high speed interfaces, this is quite a limitation
<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 ...)
<lekernel> anyway it seems I'm getting away without it. the problems I have atm with the DDR PHY sound unrelated.
<lekernel> we have a pretty wide timing margin anyway... we have good quality DDR chips :)
<wpwrak> heh ;-)
<wpwrak> it's quite impressive how many bugs those fpgas have. you'd think they're relative simple
<wpwrak> s/relative/relatively/
<lekernel> work 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.
<wpwrak> yeah, or AMD. they eve have powerful GPUs thrown into the mix
<lekernel> by the way, wasn't USB designed by Intel too ? (-:C
<wpwrak> yeah. they've grown enough tough skin wrestling with x86 compatibility that nothing scares them anymore ;-)
<lekernel> seems 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 from
<lekernel> write got worse
<lekernel> let's see if I can do some "adjustment" there as well ...
wolfspraul has joined #milkymist
<larsc> lekernel: seems you are ahead of xilinx. their mig7 ddr core has a very high chance to lock up during calibration...
netru has joined #milkymist
wolfspraul has joined #milkymist
<lekernel> got the write DQS right. now the write data is 1/2 memory cycle too late. hmm...
<lekernel> and unfortunately I can't play with the CAS latency here like I did for reads :(
ab5tract has joined #milkymist
rejon has joined #milkymist
LmAt has joined #milkymist
<GitHub76> [milkymist-ng] sbourdeauducq pushed 2 new commits to master: http://git.io/86hKKg
<GitHub76> [milkymist-ng/master] ddrphy: partly working - Sebastien Bourdeauducq
<GitHub76> [milkymist-ng/master] ddrphy: reads OK, write data coming out 1/2 cycle too late - Sebastien Bourdeauducq
<GitHub154> [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/AOgHaQ
<GitHub154> [milkymist-ng/master] ddrphy: request wrdata_en/rddata_en at the same time as the command - Sebastien Bourdeauducq
wolfspra1l has joined #milkymist
<lekernel> almost there. just a circular permutation of the four SERDES phases and it will work now...
<qi-bot> The firmware build was successful, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120224-1406/
<lekernel> works! :)
<Fallenou> :)
<lekernel> now I just hope too many hideous critters are hidden under the bricolage... but I don't know if I should trust the simulation anyway
<lekernel> the sure way to know would be to hook up some expensive LA/scope to the memory
<lekernel> s/are/aren't/
<GitHub60> [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/H6HsSA
<GitHub60> [milkymist-ng/master] ddrphy: working on hardware, simulation a bit messed up - Sebastien Bourdeauducq
<lekernel> so, 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)
sh4rm4 has joined #milkymist
<wpwrak> what's the per-migen memory bandwith ?
<lekernel> with a reordering controller I think we can have about 80% efficiency
<lekernel> that would be roughly 8Gbps available to the applications
<wpwrak> oh, sorry. i meant "pre-migen". i.e., how much slower is the rest of us today ?
<lekernel> 2-3Gbps :)
<lekernel> but the new design will switch to 32bpp, which will already eat a lot of extra bandwidth
<wpwrak> a factor of two, no ? or are there nonlinear effects ?
<lekernel> since most of the transfers are pixel data, yes, about a factor of two
<lekernel> and going 1024x768 is 2.5 more pixels ... hmm... that's tight
<lekernel> 2.5x
<lekernel> but I think 32bpp will improve the results more than increasing resolution
<wpwrak> 2*2.5*2 = 10, 3*2.5*2 = 15. seems it's either-or anyway.
rejon has joined #milkymist
wolfspraul has joined #milkymist
<wpwrak> having a bit of spare bandwidth would be good. e.g., for a larger overlay. or maybe for more image channels.
<lekernel> we could use two extra DDR chips on the M1
<lekernel> but routing will be difficult, and it won't be compatible with old boards
<lekernel> that's the only difficulty though. DDR 2/3 bring in additional problems.
<lekernel> maybe for M2 :-)
cjdavis1 has joined #milkymist
<lekernel> by the way, we're no longer using the proprietary NWL PHY
<lekernel> it full of bugs anyway
cjdavis has joined #milkymist
cjdavis1 has joined #milkymist
lekernel has joined #milkymist
kilae has joined #milkymist
cjdavis has joined #milkymist
cjdavis2 has joined #milkymist
cjdavis1 has joined #milkymist
cjdavis has joined #milkymist
<qi-bot> The firmware (using branch) build was successful, checkout the VERSIONS for detail, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120224-1546/
cjdavis1 has joined #milkymist
cjdavis has joined #milkymist
cjdavis1 has joined #milkymist
antgreen has joined #milkymist
cjdavis1 has joined #milkymist
cjdavis2 has joined #milkymist
<Hodapp> cjdavis2: wha? you're in here too?
cjdavis1 has joined #milkymist
cjdavis1 has joined #milkymist
cjdavis1 has joined #milkymist
cjdavis1 has joined #milkymist
sh4rm4 has joined #milkymist
abushcrafterforg has joined #milkymist
abushcrafterforg has joined #milkymist
cjdavis has joined #milkymist
<GitHub194> [milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/72d30fa59b3b44eeed824216468de61b6c40d828
<GitHub194> [milkymist/master] adjust the map -t from 2 to 20 fit for ISE 13.4 - Xiangfu Liu
<cjdavis> hodapp: yes
<lekernel> omg the RTEMS DHCP/BOOTP code ...
<lekernel> apparently 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 it
<Hodapp> wtf
<GitHub17> [rtems-yaffs2] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/rtems-yaffs2/commit/1a9b2b8dd64aa54d93afa4b22e159f22f718a2ea
<GitHub17> [rtems-yaffs2/master] Remove fpathconf - Sebastien Bourdeauducq
<wpwrak> lekernel: kinda like OO ? :)
<Hodapp> wpwrak: no, that's for "modularity" or some horseshit like that
<lekernel> I have FN working with upstream RTEMS now
<lekernel> (and some patches ofc)
<lekernel> btw the new VGA timings cause no problems on my screen
<GitHub199> [flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/lf1fqw
<GitHub199> [flickernoise/master] filemanager: use function prototypes from rtems/shell.h - Sebastien Bourdeauducq
abushcrafterforg has joined #milkymist
<qi-bot> The firmware build was successful, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120224-2040/
elldekaa has joined #milkymist
fpgaminer has joined #milkymist
fpgaminer has joined #milkymist
<lekernel> https://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?
<larsc> and O(n**2) running time
elldekaa has joined #milkymist
<GitHub43> [flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/6uuWUA
<GitHub43> [flickernoise/master] Update copyright year in about box - Sebastien Bourdeauducq
<GitHub97> [milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/1631e96039bed2cff26435b98ef969538987442f
<GitHub97> [milkymist/master] README: update - Sebastien Bourdeauducq
<GitHub197> [milkymist] sbourdeauducq pushed 3 new commits to master: https://github.com/milkymist/milkymist/compare/1631e96...6bc8e02
<GitHub197> [milkymist/master] README: update directory structure - Sebastien Bourdeauducq
<GitHub197> [milkymist/master] libfpvm: remove broken depend target - Sebastien Bourdeauducq
<GitHub197> [milkymist/master] softusb-input: make generated include installable - Sebastien Bourdeauducq
<qi-bot> The firmware (using branch) build was successful, checkout the VERSIONS for detail, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120224-2219/
lekernel has joined #milkymist
elldekaa has joined #milkymist
wolfspraul has joined #milkymist
wolfspraul has joined #milkymist