12:11 <cladamw> wpwrak, (VGA DDC failed :: 6 / 90) wpwrak, I'm thinking this problem...even you mentioned that intermittent problem, possibly

12:11 <cladamw> caused by software.

12:11 <cladamw> wpwrak, but i'm not sure and don't know if existing another potential reason, why i'm thinking this? since i reviewed R2 known issues and compared to R3 known issues about L3 and L19 shorted to fix frozen problem, would it be also likely to "ground problem" to cause noises?

12:12 <cladamw> wpwrak, you can see my http://lists.milkymist.org/pipermail/devel-milkymist.org/2011-March/001289.html

12:15 <cladamw> seems that I'm editing DVI-I sch, so just thought up if this un-suitable 'ground' arrangement may cause DDC failed? not just only re-plug.

12:57 <cladamw> (R4: DVI-I single link sch) http://downloads.qi-hardware.com/hardware/milkymist_one/sch/tmp/Milkymist%20One%20R4%20-%2020120117.pdf

12:58 <cladamw> hot plug detect pin 16 on J17 hasn't been added.

13:00 <cladamw> the sch is not draft yet.

17:09 <wpwrak> hmm, DDC indeed looks fishy

17:10 <wpwrak> but more in a "this can't work" way than in a "this sometimes doesn't work" way

17:10 <wpwrak> lekernel: what version of DDC does M1 implement ?

17:11 <larsc> the one which uses i2c probably

17:12 <wpwrak> the hardwre looks DDC1-ish. wikipedia says "Very few display devices implemented this protocol."

17:12 <larsc> what makes you say so?

17:13 <wpwrak> and I2C would need bidirectional SDA. unless i'm missing another instance of VGA_SDA, it's only an input

17:13 <wpwrak> hmm. or maybe not

17:14 <larsc> why is it input only?

17:14 <wpwrak> not sure what to make of that circuit. haven't seen such a thing

17:14 <larsc> thats a common thing on i2c busses

17:14 <larsc> is a level converter

17:14 <larsc> it is

17:15 <larsc> some cheap trick, don't ask me how it works

17:15 <wpwrak> ;-)

17:16 <wpwrak> brr. gives me headache :) but maybe that's just from last night's party

17:20 <lekernel> DDC2

17:20 <lekernel> The most common version, called DDC2B, is based on I²C, a serial bus

17:20 <lekernel> that's what we have

17:21 <lekernel> and yes, the mosfet hack is a bidirectional level translator, which so far has always worked fine (except for that time when resistors weren't properly placed during production of course ...)

17:30 <wpwrak> interesting bug :)

17:32 <lekernel> he

17:32 <lekernel> it's not a bug

17:32 <lekernel> the mosfet is operating within specs

17:33 <lekernel> what it does is pull the other line low when the voltage drops to ground on one line

17:34 <wpwrak> no, i mean improperly places resistors

17:34 <wpwrak> placeD

17:37 <wpwrak> hmm, nothing calls vga_read_edid in FN. maybe time for another shell command. the more we can do from a "standard" FN environment, the better

17:38 <lekernel> yeah, DDC is totally unsupported beyond dumping the EEPROM in the demo firmware and checking its header in the production test software

17:38 <wpwrak> larsc: how many hours did that little issue cost the customers of your employer ?

17:40 <larsc> wpwrak: probably none. it's a xilinx board

17:41 <wpwrak> so you knew the resistors were missing when you go it ?

17:41 <larsc> no

17:41 <larsc> had to find it out the hard way

17:42 <larsc> but luckily they weren't in the schematics either

17:42 <larsc> so it was quite obvious what was wrong

17:44 <lekernel> a xilinx devboard? which?

17:44 <larsc> ml605 rev.d

21:38 <wolfspra1l> wpwrak: do we have a final plan on the new u-shape expansion system header assignments?

21:38 <wolfspra1l> I think now that J3 is solved and Adam is working through the schematics would be a good time to finalize the proposal, unless it happened already?

21:39 <wolfspra1l> or are we waiting on a bit of pin counting to find out how many free pins even still exist on the fpga?

21:40 <wpwrak> i don't know where adam is with rearranging things. does he already have an idea how much space will be there ?

21:40 <wolfspra1l> my last understanding was that we change the J21 header to female. Does this mean we are also OK with changing the pin assignments of that connector? Or we still keep the same?

21:40 <wpwrak> i would keep it the same

21:47 <larsc> hm, why do you want to change it to female?

21:49 <wolfspra1l> that was proposed because, lemme see

21:49 <wolfspra1l> a) easier to mechanically insert the daughterboard

21:50 <wolfspra1l> b) more expensive part (mechanical connector) is on m1, making the daughterboard cheaper

21:50 <wolfspra1l> c) less open pins sticking up from m1, creating shorting opportunities

21:51 <wolfspra1l> the downside of course is that we break compatibility with pre-R4 boards, which I felt about strongly, but seems at that point I was the only one

21:51 <wolfspra1l> if we leave all pins the same, we at least have some degree of backwards compatibility because we can make or send around a small male-to-female adapter/cable

21:52 <wolfspra1l> sorry b) was "more expensive part (female connector) is on m1"

21:52 <larsc> hm, right now i'm using the j3 to interface with external peripherals using jumperwire

21:52 <wolfspra1l> anything else but a-c ?

21:53 <larsc> but ok

21:53 <wolfspra1l> wpwrak: I think for the space we also in parallel need to specify what we want

21:54 <wolfspra1l> space can be created, in easier or harder ways

21:54 <wolfspra1l> so I don't think Adam will have any opinion on space. his plan is to finalize schematics, and after review go to the layout folks and then worry about space.

22:06 <wpwrak> well, we can make a draft spec, as a guide for the direction things should take

22:15 <wolfspra1l> I don't think we can finalize the R4 schematics before chinese new year, so we have a bit of time

22:41 <wpwrak> alright. we can make the draft this week, then collect comments.

22:46 <wolfspra1l> sure. I think from Adam's perspective, two things are still open: 1) J21/u-shape 2) leds

22:48 <wpwrak> ah yes, the leds

22:51 <wolfspra1l> ok, let's confirm with Adam tomorrow where the whole thing stands

22:52 <wolfspra1l> and then before Friday (his vacation), we need the overview on used and available pins

22:52 <wolfspra1l> with that data, we can finalize the expansion system and leds next week, without space considerations

22:52 <wolfspra1l> then when adam comes back we finish and review the schematics

22:53 <wolfspra1l> after that it goes to the layout house where space may come back, and we may have to remove a few things

22:53 <wolfspra1l> that's the process as I understand it right now...

22:54 <wolfspra1l> for the layout house, I think we remove the 8-layer pcb as an option (that was discussed at some point when we also thought about dvi dual-link)

22:55 <wolfspra1l> so we first try to work with the 6-layer pcb constraint, and only if that fails miserably (after layout feedback), we would open that option up again

22:55 <wpwrak> so still 6 layer. nicer (as long as things still fit)

22:55 <wolfspra1l> well I'm just describing the process, things go back and forth between a number of people

22:55 <wolfspra1l> so there may always be surprises :-)

22:55 <wolfspra1l> but this sounds about right?

22:58 <wpwrak> yeah, sounds good. but we should put some estimates for the space in the draft

22:58 <wolfspra1l> don't understand

23:00 <wpwrak> the J21 draft should indicate what dimensions we think it may/should have

23:00 <wolfspra1l> oh, I thought it's already clear that it's a 100mil female header?

23:00 <wolfspra1l> same as the current one, so 2*9 ?

23:02 <wpwrak> ah, but there's much more :)

23:02 <wolfspra1l> oh

23:03 <wolfspra1l> I'm behind :-)

23:03 <wolfspra1l> so then yes, we should specify that along with the schematics for the layout house

23:04 <wpwrak> space between the two headers. space available/reserved for the board. position of projection on the side wall. the current rating of the pins (e.g., copy & paste from xilinx docs)

23:05 <wpwrak> and, related, placement of a hole for a spacer (for strain relief) on the main pcb

23:05 <wpwrak> (strain) e.g., insertion pressure. wouldn't be so nice if the main pcb flexed and chips popped off