<wolfspraul>
aw: good morning :-) I guess you are reading up on Werner's and Sebastien's latest findings already.
<wolfspraul>
10k pullup, diode, remove r60
<aw>
wolfspraul, keep reading...I'll do experiment after I interpret solutions well. ;-)
<aw>
phel~read finished...;-) some background knowledge may not understand..but it's okay...preparing to do this solution now. ;-) stay tuned.
<wolfspraul>
fully tuned :-)
<wolfspraul>
my mind is just wandering into marketing land. if we see m1 in the continuum of computers, what are its ancestors?
<wolfspraul>
(aw - no worry, I'm not asking you :-))
<wolfspraul>
I'm trying to think of a chart of the history of computing basically, and where m1 would show up
<aw>
hmm..R157 sit at bottom side. hehe not bit deal.
<wolfspraul>
how big is the component you need to add there? remember we have very little space on the bottom side
<wolfspraul>
essentially nothing, maybe 1mm height only would be best :-)
<aw>
small 0402 only, which not influence
<wolfspraul>
ok
<aw>
back soon,lunch
<wolfspraul>
so I think we need to explain m1's relationship to earlier computers, whether that's the workstation/desktop/notebook/pda/smartphone/tablet line, or video synthesizers, or embedded computers (which?)
<wolfspraul>
I will talk with Jon about it
<wolfspraul>
m1 is the successor of ?
<wolfspraul>
"the employees didn't get a paycheck. in fact, they contributed 5 dollars each month to buy parts"
<aw>
h/w patches on rc3: R30(10K), R157(10K), R60(remove), reset IC(stay), D16(stay), added a new diode which same as D16: negtive terminal to reset ic's output
<aw>
results: reconfiguration ok, can't boot up. But can still boot when I used prober(1:1) at program_b pin.
<aw>
next: changed my prober to 1:10 and take scopes. ;-)
<wolfspraul>
I'm also still curious whether your rc2+reset ic+diode can boot or not (fully boot to gui/rendering)
<aw>
hmm...seems I can't use 1:10 scale to take scope @ div/50mV
<aw>
wolfspraul, yes...good idea...let's try my rc2 now and also let without D16 to see if several times work well. my last rc2 with 0x2c mac has reset + diode, that one is done with reconfiguration 1000 times.
<wolfspraul>
please no tests without D16
<wolfspraul>
we've said this many times now, it's a waste of time and just completely random test that makes no sense at all. then we could also try dozens of other random ideas.
<aw>
sure, my current rc2 0x1e can do this test again...second though. ;-)
<aw>
yes
<wolfspraul>
D16 in correct polarity always stays on, always, 100%
<wolfspraul>
unless we have a real analysis/idea/theory that says we should remove it
<aw>
and keep rc2 with the same value R30(4.7K) and R60(4.7K) to try to compare.
<wolfspraul>
keep rc2 exactly as it was before, no changes at all
<wolfspraul>
that was the basis of our design decision for rc3
<wolfspraul>
so we must have overlooked something there
<aw>
yeah...second
<wolfspraul>
let's go back to rc2 and verify
<wolfspraul>
don't even reflash it, just power-on and boot
<aw>
sorry the rc2 R60 is 10K (that I wrote wrong above)
<wolfspraul>
whatever it is, don't change, just boot :-)
<wolfspraul>
aw: and?
<aw>
added, results: ten times with reconfiguration success without boot up at all, then once everytimes I put prober at program_b after let reconfiguration done firstly then all can goes to boot up.
<aw>
i am wondering to put an equivalent capacitor at C238 which rc2 & rc3 is not mounted.
<wolfspraul>
wait wait
<aw>
Can this C238 be activated as an prober's equivalent capacitor?
<aw>
okay ...wait..go on
<wolfspraul>
we really have to slow down and think more
<wolfspraul>
so let me confirm: when you go back to your rc2, with reset ic + diode, you now find that you actually cannot boot it at all?
<wolfspraul>
(without any probes attached, just a regular boot)
<aw>
yes, now seems to be that.
<aw>
yes, regular boot, but ten times i just tested.
<wolfspraul>
do you remember whether in the past it may have booted fully to gui/rendering, even when reset_ic+diode were already there?
<wolfspraul>
or maybe in the past you always had a probe connected so you didn't see the problem?
<aw>
seems no, because my boards are different one. the 1000 times with h/w patches on rc2, that one eventually i can't let it even recofiguration was because I suddently used a 'fast' power cycling..then 'dead'
<wolfspraul>
I cannot follow
<aw>
yes, that 1000 times, I always & remembered to use a prober to count 1000 times at that time.
<aw>
can follow? or ?
<wolfspraul>
let's try to answer this precise question, even if the answer is "don't remember"
<wolfspraul>
here is my question:
<aw>
go on
<wolfspraul>
Do you remember whether you ever saw an rc2+reset ic+diode, without probes attached, do a full boot to GUI?
<aw>
no,
<wolfspraul>
ok
<aw>
i only used no h/w patches on rc2.
<wolfspraul>
and if you now test with such a board, you can consistently _not_ boot it
<wolfspraul>
well at least that's stable
<wolfspraul>
so that means when we verified the reset ic + diode improvement on rc2, we didn't test well. we didn't test whether the board can actually boot.
<aw>
yes, now i feel rc2 & rc3 are consistently from reset ic & diode patches.
<wolfspraul>
and we see the exact same behavior on rc3 now
<wolfspraul>
yes, perfect
<aw>
exactly
<aw>
i didn't test if can boot up. :(
<wolfspraul>
yes :-)
<wolfspraul>
but instead you did a mostly irrelevant test 1000 times
<aw>
well...no excuses.
<wolfspraul>
but that can happen
<wolfspraul>
in hindsight vision is always 20/20
<wolfspraul>
aw: do you know that expression?
<wolfspraul>
"in hindsight vision is always 20/20"
<wolfspraul>
for me it's more important that we stay in control of the project and our discoveries
<wolfspraul>
so now... back to rc3
<aw>
that 1000 times is for reconfiguration, was think it's no problem at all.
<wolfspraul>
yes
<wolfspraul>
but if you would have tried to boot even once, you would have seen the problem :-)
<wolfspraul>
but that's ok now, we understand it now and are trying to recover
<aw>
yes, exactly i should have tested for boot up and the results will be the same.
<wolfspraul>
so the latest is, in rc3, even with the new fixes (10k, second diode, remove r60), we cannot boot
<wolfspraul>
and you are unable to take a scope picture?
<wolfspraul>
meanwhile when you connect a probe, you can boot
<wolfspraul>
until lekernel or wpwrak_ get back and read the results, I am wondering what we can do to collect some interesting data points
<aw>
i must to use 1:1 prober to capture but this seems not react as actually pulse we want.
<wolfspraul>
first of all - please - do not experiment with removing D16
<wolfspraul>
I think that's clear now
<aw>
but I still can scope 1:1 to see if big difference there.
<wolfspraul>
if you want you can try the C238 idea, it sounds a bit hacky though :-)
<wolfspraul>
that idea does not seem to come from an understanding of the circuit and how to design that well, but rather trying to imitate the probe's effects :-)
<wolfspraul>
but ok, fine. probably it cannot damage the board, I think.
<aw>
because that C238 is exactly stay at program_b there, seems can be acted as a prober's equivalent capacitor.
<wolfspraul>
you can also do the tests on the rc2 board, why not
<wolfspraul>
since it shows the same problem
<wolfspraul>
I mean the rc2 board with reset_ic + diode
<wolfspraul>
maybe test on the rc2 board first? so in case anything goes wrong the only rc3 we have is safe
<wolfspraul>
try C238, why not, we have to wait for new ideas from Werner or Sebastien anyway
<wolfspraul>
and try to find a way to take scope pictures, I'm sure they would want to look at them
<wolfspraul>
that's probably all
<wolfspraul>
what do you think?
<aw>
yes it indeedly I just feel C238 is a good chance with h/w patches. even I have no hard knowledge now. ;-) second...
<wolfspraul>
are you testing this on rc2 or rc3 now?
<wolfspraul>
since we have the exact same behavior on rc2, I suggest we move all further experiments to rc2
<wolfspraul>
up to you though...
<aw>
yes, i am now using rc2 board
<aw>
checking my prober's data about input capacitance. :-)
<wolfspraul>
remember to first apply the other changes from rc2, 10k/second diode/remove r60
<wolfspraul>
sorry I meant "the other changes from rc3"
<wolfspraul>
so that the rc2 board exactly implements our latest best bet for a correct circuit
<aw>
it said about 10pF, compensation range is 10 ~ 35pF
<aw>
umm..also inlcudes a 10M ohm there in a parallel with 10F...way to try this.
<aw>
hmmm...wrong data, that is for X10,
<aw>
for X1 is 1M ohm with 47pF
<lekernel>
aw, what delay did you use for the test in rc2?
<lekernel>
(reset ic delay)
<lekernel>
the same as now, or a smaller delay?
<aw>
hi same delay with 200ms
<wolfspraul>
lekernel: rc2 with reset_ic+diode never booted, ever
<wolfspraul>
so we shot ourselves in the foot assuming that what we had there was what we would want for rc3 :-) Now we have to fix it after the fact...
<wolfspraul>
aw: did you test the C238 idea?
<aw>
second..rc2 doesn't have footprints place for reset ic and diode...and else...a little difficulty. ;-)
<lekernel>
sorry, bad connection ...
<wolfspraul>
sometimes I think your German DSL connection is worse than my openvpn tunnel through the Chinese firewall
<wolfspraul>
:-)
<wolfspraul>
lekernel: when you weren't online yet, we had the idea of trying to simulate the probe by putting a capacitor on C238
<lekernel>
yeah it doesn't work at all atm... i'm connecting via GSM
<wolfspraul>
that's not systematic at all of course, but better than just wait and do nothing
<wolfspraul>
whenever Adam connects the probe, the board will boot
<lekernel>
where does it connect the probe?
<lekernel>
program_b?
<wolfspraul>
yes, 1:1 probe on program_b
<wolfspraul>
will make it boot
<lekernel>
ok
<lekernel>
that (pesky) diode has 115pF capacitance
<lekernel>
could be enough to glitch PROGRAM_B when the flash reset goes low ...
<lekernel>
I'm starting to see the good sides of the logic gates Werner recommended
<lekernel>
connecting a 1:1 probe likely adds some 200pF capacitance which compensates and filters out the glitch
<lekernel>
aw, would it be difficult to cut the trace between the reset IC and PROGRAM_B (leaving its 4.7k pullup)?
<lekernel>
that's the clean way to fix it... otherwise using some 1nF on C238 should also get it to work
<aw>
lekernel, no problems I just reworks on rc2 boards. ;-) and also I have really really good NEWs. :-)
<lekernel>
yeah, the time constant with 115pF and 4.7k is 540ns... enough to cause problems...
<lekernel>
we'll use the logic gates
<aw>
rc2 with h/w patches: R30(10K), R60(remove), R157(10K), reset ic + 2 diodes(one is for flash reset, one is for init_b)
<aw>
and C238 footprint ( with 1M ohm & 47pF in parallel)
<aw>
now I tested 10 times can boot up
<aw>
so here's my feedback:
<lekernel>
in the meantime, maybe it's best to use 1nF on PROGRAM_B - which would block glitches on flash reset from INIT_B going low
<lekernel>
do not use 1M resistor and use more capacitance
<lekernel>
1nF
<wolfspraul>
lekernel: do you still want to do the cut trace experiment?
<lekernel>
no, forget about that
<lekernel>
it's a bit hard to do and it would only solve half of the problem
<aw>
1. before I go for further h/w patches on rc3, we need to analysis on why an equivalent capacitance (1M ohm + 47pF) can make this okay.
<wolfspraul>
already done
<aw>
no no...
<wolfspraul>
plus, you can remove the resistor and try 1nF instead
<wolfspraul>
but go on, write first...
<aw>
surely i can reduce those its value and 1M ohm which I just made them as a prober though. ;-)
<lekernel>
the 1M resistor is unnecessary. 1nF gives more safety margin than 47pF.
<aw>
2. I'll go for directly rework those h/w patches on rc3 boards
<aw>
alright . ;-)
<wolfspraul>
wait wait. first let's do the test again without resistor and with 1nF
<aw>
okay...
<lekernel>
with 47pF you probably are close to the limit of the "working" zone
<lekernel>
1nF is one order of magnitude larger than the diode's capacitance, so the latter can no longer cause any trouble
<wolfspraul>
I don't want to speculate about the next steps now, let's verify this first.
<aw>
alright
<lekernel>
btw, the capacitance of a 1:1 probe is typically a lot more than 47pF, since you have to take into account the capacitance of the coaxial cable that goes to the scope as well
<wolfspraul>
just for fun, whether he replies or not I just said hello and pointed him to Milkymist One :-)
<lekernel>
"In all only eight machines were ever produced."
<lekernel>
wow
<wolfspraul>
yeah well
<wolfspraul>
economically I hope there will be no parallels to our endeavor
<wolfspraul>
I think I need to develop a routine of writing random mails/tweets to people from the visual field, or journalists, to introduce m1. just a few a day or so, it's actually fun to find people doing this or that...
<wolfspraul>
btw Adam sent me a PM because he's taking a short break, so the test results will come in a little later
<wolfspraul>
I may go for a run as well...
<wolfspraul>
lekernel: do you think program_b/r30 should be 4.7k or 10k?
<lekernel>
10k
<wolfspraul>
we iterated between those two a number of times
<wolfspraul>
ok
<wolfspraul>
so if the 1nF test works, that would be the solution for rc3 then
<wolfspraul>
for rc4 we can either continue to use it then, or switch to the gate
<wolfspraul>
I hope those manual rc3 fixes will not look too ugly, but it sounds like they should not...
<aw>
no, after test with 1 nF, i power nap. ;-) moment.
<aw>
with 1nF on C238, can boot up but when starts to rendering a couple seconds, D2/D3 dimly lit..then screen is OFF. :(
<wolfspraul>
he :-)
<lekernel_>
amazing ...
<aw>
:(
<wolfspraul>
aw: you also removed the resistor, right?
<aw>
yes, removed 1M ohm
<lekernel_>
aw, but PROGRAM_B still has its 10k pull-up, right?
<lekernel_>
and same for INIT_B?
<aw>
yes, R30(10K), R157(10K)
<lekernel_>
aw, can you cut the trace between the reset IC and PROGRAM_B?
<lekernel_>
PROGRAM_B should be connected only to the 10K resistor to 3.3V
<lekernel_>
and the output of the reset IC, to INIT_B and its pull-up directly (no diode) and to the diode that goes to the flash reset
<aw>
let me think a little to how arrange my rework. ;-)
<wolfspraul>
aw: from now on, when doing a bootup test, always let it render for a minute or two
<wolfspraul>
once we have a solution we believe works, we let it render for an hour or longer, just in case :-)
<wolfspraul>
just saying
<wolfspraul>
but for now - always let it render for a full minute, as part of the 'boot' test
<lekernel_>
if we need to test this ~1000 times to check reliability, this will take forever
<wolfspraul>
no no
<aw>
after cut connection between reset ic and program_b, reconfiguration normally then D2 goes ON couples seconds then start to dimly lit... :(
<aw>
then I power cycle again...then can't reconfigure more. ..now 'dead' . :(
<aw>
just listed my rework in details:
<wolfspraul>
lekernel_: (you saw this? - checking whether your connection is up...)
<aw>
1. R30(10K) 2. R60(remove) 3. R157(10K), reset ic's output directly connected to an negative diode then its positive to init_b(thus the R157's pad), reset ic's out directly connected to an negtive diode then its positve terminal to flash reset pin(which is thus R60's pad)
<wolfspraul>
aw: I think for these tests now, when you can't reconfigure anymore, you just reflash the entire software. That's because if the flash does get corrupted, there is no point to analyze this until we have a stable boot circuit.
<wolfspraul>
after we have that, yes, we should watch and if it cannot reconfigure anymore that's a serious issue
<wolfspraul>
but until we have that, I think you can always just reflash everything
<aw>
4. no connection between reset ic's output and program_b.
<aw>
there's one strange thing is:
<aw>
why has connection between reset ic's output and program_b and this connection is also connected to the negative terminal of diode then init_b, also 47pF can boot up 10 times though. I think that I saw it was rendering at least maybe 3 ~ 5 seconds each time.
<lekernel_>
aw, connect directly the reset IC to INIT_B (no diode)
<lekernel_>
and what's the deal with 47pF? do not add a capacitor
<aw>
man! i was wrong!
<aw>
do again.
<wolfspraul>
lekernel_: I think he wanted to say that when he had 47pF on C238 (and a resistor too), it did boot
<aw>
hehe...now i got it. totally let's forget about previous email's connections. ;-)
<aw>
good...now do again.
<wpwrak_>
lekernel_: so PROGRAM_B_2 is completely unnecessary ?
<lekernel_>
wpwrak_, it's only there to clear FPGA _after_ configuration, from my current understanding it reacts to falling edges
<lekernel_>
INIT_B should be used to delay configuration; PROGRAM_B cannot be used for this purpose
<wpwrak_>
lekernel_: okay, so it's more a case for one of these "reset holes" you find on some devices
<lekernel_>
and it may seem that because of the diode's capacitance, when the flash is reset at SoC boot, there is a glitch on PROGRAM_B that clears the FPGA
<lekernel_>
so we added a 47pF capacitor, which seems to work
<lekernel_>
but it seemed too small, so we tried 1nF, which causes an unexplained configuration loss several seconds after boot (maybe this has to do with slow rise time on PROGRAM_B which the FPGA doesn't like..?)
<wpwrak_>
yeah, 1 nF seems uncomfortably large. that can cause all sorts of weird things
<lekernel_>
i've read all sorts of horror stories about INIT_B, PROGRAM_B, etc. now I'm experiencing them first hand
<lekernel_>
nice
<wpwrak_>
heh ;-)
<wpwrak_>
what i didn't get was why adam can't use the scope with 1:10. apparently, that didn't change the system's behaviour, did it ?
<lekernel_>
no, 1:10 doesn't cause problems
<lekernel_>
Adam made a mistake and used a 1:1 proble
<lekernel_>
if all else fails, we'll use 47pF. done :)
<wpwrak_>
but he also said he can't use 1:10 "for 50 mV". and it sounded as if this made 1:10 a complete no-go. not sure what he meant
<lekernel_>
the diode's capacitance is 115pF btw
<wpwrak_>
yeah, saw it. quite the sucker
<wpwrak_>
maybe the next project should be the making of some active probes ;-)
<lekernel_>
and the fall time on the flash reset is very small... I can also make it larger
<wpwrak_>
i have some resistive probes. they're great, but of course suck evil amounts of current
<lekernel_>
we already have SN74LVC1G17 gates
<lekernel_>
but they're push pull... oh well
<wpwrak_>
and they're no AND ...
<lekernel_>
AND?
<lekernel_>
ah
<lekernel_>
right, you want to do it entirely with gates...
<lekernel_>
I thought of them as switching diodes without irritating leakage current or capacitance
<wpwrak_>
you can get most of the 74xx logic family as 1G. some 40xx as well. all the old stuff is coming back ;-)
<aw>
too bad! can't restore now.
<aw>
even can't reflash though.
<wpwrak_>
have we killed JTAG ?
<lekernel_>
aw, what happens?
<lekernel_>
is your JTAG connector correctly inserted? I got all sorts of weird behaviours which simply originated from a poorly inserted JTAG dongle ...
<aw>
from my lastest wrong rework on adding second diode to init_b. when power on , D2D3 stay dimly lit. then i tried to reflash then stop at:
<aw>
Bitstream information:
<aw>
Design: system-routed.ncd;UserID=0xFFFFFFFF
<aw>
Part name: 6slx45fgg484
<aw>
Date: 2011/02/24
<aw>
Time: 22:33:26
<aw>
Bitstream length: 1484404
<lekernel_>
I'd guess your JTAG dongle isn't inserted correctly
<aw>
hum...no
<lekernel_>
what is the output of the "detect" command?
<lekernel_>
on JTAG?
<aw>
i always keep my JTAG daughter board inserted my m1. ;-)
<aw>
moment
<lekernel_>
yes but it can move
<lekernel_>
"from my lastest wrong rework on adding second diode to init_b" wtf?
<aw>
but before this, i already made wrong reworks on the email I replied to you guys. ;-)
<wpwrak_>
wolfspraul, aw: (trace cut) it seems yes. the trace between reset IC (and diode and cable to INIT_B) and PROGRAM_B_2
<aw>
no problem...just need to do the same rework about fix.png on rc3.
<wolfspraul>
why can't we get this to work on the rc2 board?
<aw>
be noticed that I was all using rc2 board not rc3. ;-)
<wolfspraul>
how come when I ask "do we want the trace cut" that Adam says 'no' but Werner says 'yes'?
<aw>
so I already did this reworks about fix1.png for surely
<aw>
wolfspraul, i guessed werner said that is for rc3 board. ;-)
<wpwrak_>
wolfspraul: phase effects ;-) the trace was cut, then not cut, then cut again :)
<wolfspraul>
rc2 and rc3 should be the same
<wolfspraul>
well OK :-) I just wait and see how it settles...
<wolfspraul>
I would first try to make it work on rc2, unless we believe that for some reason the reworks damaged rc2 beyond repair.
<wpwrak_>
(rc2 vs. rc3) i would also think they should be the same. but i don't know rc2 well enough to tell if this makes sense.
<lekernel_>
this is what we had with the 1nF capacitor and was the closest to working: http://milkymist.org/fix2.png
<wolfspraul>
all the same
<aw>
wolfspraul, werner is right on instructions on rc3 board with fix1.png lekernel_ sent. ;-)
<aw>
then I am using rc2 boards with h/w reworks patches. ;-)
<lekernel_>
aw, go back to http://milkymist.org/fix2.png but try using a smaller capacitor to avoid configuration loss when rendering
<aw>
well... i go for dinner first then I back to work on rc3.
<lekernel_>
(between 47pF and 1nF)
<wpwrak_>
lekernel_: i think we should let the dust settle first. make sure adam has exactly fix1 implemented, etc. then see how things go
<aw>
lekernel_, man! go back... ;-)
<wolfspraul>
yes I agree, I think fix1 hasn't even been tried yet
<wpwrak_>
lekernel_: if you put half a dozen rework variants in his pipeline, you'll never know what he's actually testing and he'll just wear down the board
<wolfspraul>
"smaller capacitor to avoid configuration loss when rendering" sounds scary, just on the surface. If people report that after an hour of rendering the board suddenly turned off, you will forever suspect an issue with that capacitor.
<aw>
hey guys no problems...pls figure which .png i need to use when i back. meanwhile you can discuss a bit though. ;-)
<aw>
i do need to do 'power nap';
<wolfspraul>
that's me saying without much understanding of the circuit, it just feels like asking for trouble
<aw>
see you guys later.
<lekernel_>
aw, fix2.png
<wpwrak_>
wolfspraul: even now, we don't really know if this is even related to the reset problem, do we ? :) (i.e., has M1rc3 ever run doing rendering for some time ?)
<lekernel_>
wpwrak_, I have run mine for 6 days continously, no problem
<wpwrak_>
lekernel_: (fix2) what ?? so you want PROGRAM_B_2 back even if you think it can only get in the way ?
<lekernel_>
it should be easier to rework, maybe?
<wpwrak_>
yes, that could be. but .. :)
<lekernel_>
the proper way to fix it would be to use gates... but difficult rework
<wolfspraul>
how can we judge on fix1 if I think we have never actually tried it? (just read the backlog again, I do not believe Adam actually tried fix1 yet)
<wpwrak_>
agreed, also about the difficulty
<wpwrak_>
has M1rc3 ever done rendering beyond the point where adam saw it fail now ?
<wpwrak_>
and we don't even know you actually need the cap. if it's just to avoid a kickback on PROGRAM_B_2, fix1 would do that too
<wpwrak_>
i kinda like the idea of separating PROGRAM_B_2 from the rest. seems that INIT_B is fairly passive most of the time, so whatever evil may happen on the FLASH_RESET side, it won't be able to cause much trouble there
<lekernel_>
wpwrak_, we need the cap. there _is_ a problem without, starting the soc will deconfigure the fpga instead of resetting the flash
<wpwrak_>
wolfspraul: (rendering) let's ask him when he's back
<lekernel_>
wpwrak_, fix1 doesn't work (we just tested) because INIT_B is driven low sometimes by the FPGA and resets the flash
<wpwrak_>
lekernel_: also in fix1, where PROGRAM_B is not connected to the diode ?
<wpwrak_>
lekernel_: no, i don't think we tested fix1
<lekernel_>
we tested fix1
<wpwrak_>
i think adam tested some confused mixture on his rc2, but not exactly fix1
<lekernel_>
this is what made Adam unable to reflash with JTAG because the FPGA kept asserting the flash reset
<lekernel_>
so INIT_B needs a diode, period
<wpwrak_>
from what adam said, in his fix1 attempt, his INIT_B may have had a diode ;-)
<wpwrak_>
i see what scenario you have in mind
<wpwrak_>
but i don't think we have a useful result for fix1 for now. it's just noise.
<wolfspraul>
we never tested anything properly after cutting the trace
<wolfspraul>
just read the backlog
<wolfspraul>
there was an extra diode after cutting the trace, and after removing that Adam was unable to reflash (until now)
<lekernel_>
didn't adam do that?!?
<lekernel_>
wtf
<wpwrak_>
yes, around then adam desynchronized :)
<wolfspraul>
you replied to it yourself
<wpwrak_>
just a bit of patience :)
<wpwrak_>
i'm also a bit suspicious when people do rework so quickly that they can hardly have time to even check the connectivity of what they've reworked :)
<wolfspraul>
lekernel wrote "now that PROGRAM_B is disconnected there should be no diode between reset IC and INIT_B"
<wolfspraul>
and Adam didn't react to that yet, because right now he cannot reflash
<wolfspraul>
so from just following the thread, I propose to stay on the rc2 board for now, and to first try fix1 properly
<wolfspraul>
unless some new theory already dismisses fix1 without having tried it
<wolfspraul>
wpwrak_: do you think Adam's fix1 attempt with diode may have caused permanent damage?
<wolfspraul>
that would be the only reason that would make me say "ok, let's try on the rc3 board". But in this style we can grind through a lot of boards quickly :-)
<wpwrak_>
pity all this isn't in kicad. otherwise, we could quickly make a schematics diff. that may help to clarify the changes
<wpwrak_>
wolfspraul: so far, i don't see a reason why the board would be permanently damaged
<wolfspraul>
ok, then like I said, when Adam is back I propose to continue on rc2, and to test fix1
<wpwrak_>
wolfspraul: if problems persists, we may want to get pictures, though. i don't know how messy the rework is at the moment
<wolfspraul>
you guys vote me down if you like, I'm just following the conversation
<wolfspraul>
does fix1 still include a capacitor on C238?
<wpwrak_>
i don't think it should for now
<wpwrak_>
too many moving parts
<wolfspraul>
hmm. but the fix1.png is meant to bring clarity. before Sebastien posted fix1.png, there was a 47pF capacitor on C238 (and also a resistor), and then 1nF (without additional resistor).
<wolfspraul>
with the 47pF+resistor on C238, actually everything worked fine
<wolfspraul>
but then Sebastien thought 47pF is too small and too close on the functioning boundary, so we tried to increase it to 1nF
<wpwrak_>
wolfspraul: (cap on C238) but that was the scope, no ?
<wolfspraul>
which made it boot, but only last for a few seconds
<wolfspraul>
no no
<wolfspraul>
Adam tried to imitate the scope
<wolfspraul>
by putting a 47pF + 10MOhm resistor there
<wolfspraul>
and it worked, booted, rendered
<wolfspraul>
then Sebastien came online and thought it all through properly as a circuit, rather than just imitating the scope.
<wolfspraul>
and he said 47pF is too small (and he also said to remove the resistor)
<wolfspraul>
so we increased to 1nF - it still booted - but now rendering wouldn't last
<wolfspraul>
then the idea of cutting the trace, which adam didn't execute properly because he forgot to remove the diode
<wolfspraul>
can you follow? he he. this is how I understood the sequence of events, at least :-)
<wolfspraul>
sorry it was 47pF + 1M Ohm resistor, that was the winning combination earlier
<wolfspraul>
an attempt to imitate the scope's probe, that's all. no circuit thinking at all.
<wolfspraul>
ah I got it now. Sebastien thinks the removal of the diode (after cutting the trace) is causing Adam's inability to flash.
<wolfspraul>
which means the entire cut-trace/remove diode idea doesn't work
<wpwrak_>
wolfspraul: (47 pF + 1 M) ah yes, right. probe simulation apparently did something good :)
<wpwrak_>
(cut trace didn't work) if adam didn't remove the diode, then i don't think lekernel's error scenario exist
<wolfspraul>
and yes, reading the backlog carefull I think fix1.png is meant to be used without any capacitor on C238
<wolfspraul>
but now he did remove it, and cannot reflash
<wolfspraul>
and lekernel_ says that's because of the removed diode (I guess, try to follow the logic here)
<wolfspraul>
so fix1 is already impossible because it breaks flashing
<wpwrak_>
if he removed the diode on INIT_B, then that could explain the failure. but i'm not sure he did
<wolfspraul>
let's see. I become an expert at backlogs.... :-)
<wolfspraul>
ha ha. if anybody has capacity for humor, look at this - Adam writing "same rework about fix.png on rc3"
<wolfspraul>
fix.png - NO NUMBER! :-)
<wolfspraul>
human communication...
<wpwrak_>
perhaps that was before the fixes went > 1 ? :)
<wolfspraul>
he did remove it. 10:35 "now do again" 10:51 "can't restore now"
<wolfspraul>
in those 16 minutes he took off the diode and made sure he was exactly in line with fix1.png - maybe with the exception of C238 since I'm not sure it was clear to him to remove those, but probably he did that as well.
<wpwrak_>
yes. but did he try to restore before or after removing it ?
<wolfspraul>
with 'restore' he means reflash, I think
<wpwrak_>
yeah, the jtag thingy
<wpwrak_>
and i also don't know what else was out of sync at that time
<wolfspraul>
so... maybe we are indeed finished with fix1.png, because we have shown it to block jtag reflashing already
<wolfspraul>
that means we go to fix2.png, but this time with 100nF (and no resistor)
<wolfspraul>
and I still think we should do that on the rc2 board, not the rc3 one
<wpwrak_>
if fix1 was every fully applied
<wolfspraul>
wpwrak_: I'm piecing it together, I think I'm clear now :-)
<wpwrak_>
sure. burn rc2 before starting to burn rc3 :)
<wolfspraul>
it was, eventually
<wolfspraul>
well, that's our last rc2, so it has value too
<wolfspraul>
but we get another 89 rc3 soon
<lekernel_>
wolfspraul, btw, bearstech is totally out of stock
<wolfspraul>
but I don't want to jump around without reason
<wolfspraul>
great!
<wolfspraul>
lekernel_: sorry we are a bit slow here. if it's painful just ignore all the babble...
<wolfspraul>
lekernel_: I think I've almost caught up with you now, logically :-)
<wolfspraul>
we are done with fix1.png and can proceed with fix2.png, and 100nF
<wolfspraul>
sorry 100pF
<wolfspraul>
:-)
<wolfspraul>
I get something to eat before Adam is back...
<wolfspraul>
l8 guys
<lekernel_>
on rc4 we'll use gates
<wpwrak_>
lekernel_: after the FPGA has configured for the first time. when you pulse PROGRAM_B_2, will INIT_B become an input then again, to allow delaying ? or is this only during the first reset ?
<lekernel_>
with proper prior testing on rc3, of course - but later
<lekernel_>
right now I want an easily applied rework so we can sell those 90 boards
<lekernel_>
wpwrak_, that's a good question, I don't know
<lekernel_>
if it behaves like the virtex4, I'd tend to think it becomes an input again, since the virtex4 reads the MODE pins again
<lekernel_>
but as far as I remember the virtex4 wouldn't configure with PROGRAM_B low, while the spartan6 does ... so, there seems to be some changes there
<wpwrak_>
good. can you command the equivalent of a PROGRAM_B_2 pulse via JTAG ? and if yes, is this something you already do before flashing ?
<lekernel_>
nah I don't want such dirty fixes
<wpwrak_>
;-))
<lekernel_>
we want to keep compatibility with the proprietary Xilinx JTAG software too
<wpwrak_>
sure. so that's not something that would already be part of the process
<lekernel_>
I don't know
<lekernel_>
apparently not
<wpwrak_>
hmm. i'm trying to construct the fix1 failure scenario. i think what you think is happening is that the FPGA tries to configure, gets a CRC failure, maybe does a few retries, then sits there with INIT_B permanently low, and then you try to flash, which doesn't work due to the reset being asserted via INIT_B and the diode, correct ?
<lekernel_>
yes
<lekernel_>
also, it can easily gets a CRC failure if INIT_B glitches low during the configuration process
<wpwrak_>
what effect does INIT_B have then ?
<wpwrak_>
btw, do you really need the 10k on the output of the reset chip in fix3 ?
<lekernel_>
reset of the flash in the middle of the configuration readout, corrupted data read by the FPGA, CRC failure, flash reset permanently asserted
<wpwrak_>
(glitch) aah, in a fix1 scenario. yes.
<lekernel_>
yeah, maybe that resistor could go
<wpwrak_>
also the 47 pF cap may be unnecessary. the theory was that the capacitance of D16 would let FLASH_RESET contaminate PROGRAM_B_2. but in fix3, this path is already closed
<wpwrak_>
and as i understand things, INIT_B doesn't mind a bit of distortion
<wpwrak_>
note that i indicated that R30 could stay at 4k7. i think adam has it reworked now to 10k, so he'd better just leave it. but for future rework, there's no point in changing it. agreed ?
<lekernel_>
we should be able to remove the flash reset resistor too
<lekernel_>
yeah those diodes give new meaning to the word 'pesky'
<aw>
hi i'm back. ;-)
<wpwrak_>
(diodes) *grin*
<lekernel_>
wpwrak_, nice diagram :)
<wpwrak_>
thanks :)
<aw>
about fix2.png this I got 10 times boot up on rc2. ;-)
<wpwrak_>
now, let's simulate those capacitances ... i don't quite trust them yet
<aw>
now check my rc2 if can restore again. ;-)
<lekernel_>
aw, and no other issues?
<aw>
lekernel_, what does you mean?
<lekernel_>
wpwrak_, remove the 10K resistor on flash reset
<lekernel_>
wpwrak_, otherwise it's perfect (and even good looking)
<lekernel_>
thanks :)
<wpwrak_>
fix2 would be even a little simpler than fix4
<lekernel_>
aw, you did not notice any problem?
<lekernel_>
aw, only 10 successful attempts?
<aw>
this afternoon i used fix2.png on my rc2. then can boot up 10 times and rendering.
<aw>
then I followed to change 47uF to 1nF and remove 1M ohm (which is located with C238 in parallel)
<lekernel_>
??????
<lekernel_>
fix2 doesn't have 1M or C238
<lekernel_>
s/or C238//
<lekernel_>
and you already tried with 1nF, no? and it caused a problem after a few seconds rendering, no?
<aw>
yes, i knew. ;-) fix2.png with a little difference is only I still added  1M ohm besides C238(47pF)
<aw>
slow down a bit...
<aw>
1. I used fix2.png with another 1 M ohm besides C238(thus is 47pF) to simulate a prober. then IÂ Â got 10 times of rendering
<aw>
2. then followed to remove 1 M ohm and change C238 to 1nF, then rendering a couples seconds then D2/D3 dimly lit then OFF...screen is also OFF surely
<lekernel_>
ok, results are consistent then
<aw>
all items 1. and 2. are done on my rc2 board. ;-)
<lekernel_>
ok
<aw>
3. then I used fix1.png on my rc2 boad, then dead...
<aw>
;-)
<aw>
let me see fix4.pdf ;-) moment.
<lekernel_>
yes, we understand how fix1 totally screws up the flash
<lekernel_>
aw, no please
<lekernel_>
aw, try fix2 without the 1M resistor and with a 100pF cap
<lekernel_>
if it works, use that
<lekernel_>
it's a simpler fix than fix4
<lekernel_>
no trace to cut etc.
<wpwrak_>
lekernel_: you still want R60 gone in fix2 ?
<aw>
let me interpret fix4.pdf firstly, okay or you are still discuss on determine to use which fix?
<aw>
so in fix4, R30 can be 4.7K? correct? or use 10K.
<wpwrak_>
aw: in fix4, if can be either
<aw>
wpwrak_, in fix2 I didn't use R60.
<aw>
wpwrak_, alright
<wpwrak_>
aw: (r30 in fix4) i.e., 4k7 would be closer to xilinx' reference design, but we think 10k will work as well, since you've already reworked it to 10k, there would be no point in reversing the change
<aw>
btw. i check if i can restore my rc2. if not , then i use rc3 with fix4.
<wpwrak_>
aw: (fix2) so did you remove r60 ? or leave it as it was ?
<aw>
as i know I need to use fix2.png with a C238(100pF) to rework now. ;-)
<wolfspraul>
yes
<wolfspraul>
aw: why does that URL not work for you?
<wolfspraul>
close and restart your browser
<aw>
maybe my two roomates are using then network is bad.
<lekernel>
aw, check your inbox
<aw>
lekernel, thanks, received.
<wolfspraul>
he :-) no way your two roommates can be related to this :-)
<aw>
lekernel, great . now the fix2.pdf is only the difference about 100pF. ;-)
<aw>
now..go rework...stay tuned. ;-)
<lekernel>
yes, that's what I was saying
<wpwrak_>
my simulation says that 100 pF should give us a worst-case drop of about 1.2 V (down to ~2.1 V)
<wpwrak_>
that is, if i modeled the diode correctly. the model uses a Cj0, which would be the zero-bias capacitance
<wpwrak_>
actually, it's larger than 115 pF. (fig. 5 on page 2) hmm. remodeling ...
<wpwrak_>
~1.3 V :-(
<lekernel>
wpwrak_, also, this would depend on the slew rate at the other side of the diode
<lekernel>
and driver impedance
<lekernel>
i'd tend to say that if it works on some tests with 47pF, then 100pF is safe
<wpwrak_>
what driver impedance should i use ? i have 50 Ohm right now, which is a bit aggressive
<lekernel>
phew, that's complicated... you can find IBIS models of the FPGA I/Os at the Xilinx website if you want
<lekernel>
I'm sure there are such models for regular I/Os like flash reset (they're typically used for high speed DRAM interfaces), for INIT_B and PROGRAM_B I'm not sure
<wpwrak_>
;-)
<wpwrak_>
i'll just stick with 50 Ohm then :) should be on the safe side. besides, even 100 Ohm or such wouldn't make much of a difference
<wpwrak_>
how long shall the INIT_B glitch last ? right now, it's infinite
<wolfspraul>
if you logout, it will show the read-only one
<wpwrak_>
wolfspraul: yeah. having to log out, reset the password i've of course long forgotten, etc., sucks :)
<wolfspraul>
git clone git://projects.qi-hardware.com/wernermisc.git should do it
<wpwrak_>
switched to a fixed voltage scale, so it's easier to see how good or bad the upset is
<wpwrak_>
would be good to check the voltage on PROGRAM_B_2 with a scope when everything is done. that'll tell is how close the model is to reality, and let us guesstimate the parameter stability.
<lekernel>
aw, so, what's happening with 100pF?
<wpwrak_>
simulation says we drop to ~1.3 V
<aw>
rc2 goes back to reflashing now. ; -)
<wpwrak_>
in real life, it'll be a bit better because i didn't model parasitic capacitances and all that
<aw>
still reflashing...
<wpwrak_>
i also don't know how accurate my diode model is. e.g., they also have a "linear capacitance" which is different from the "zero-bias junction capacitance"
<wolfspraul>
aw: ok good, so we are testing the latest idea on your rc2 board first, right?
<aw>
rc2 + fix2, yes
<aw>
reflashed done.
<aw>
umm..no..some err shows.
<aw>
wait
<aw>
Error: intel.c:371 intel_flash_program_buffer() flash program: unknown error while programming; command 'flashmem  0xD20000 data.flash5.bin noverify'
<aw>
i guessed maybe caused by my last 'dead' status?
<aw>
and D2 and D3 is still dimly lit after reflash shows err.
<aw>
i think that i need to directly use rc3 with fix2? since i don't trust my rc2 board's status. ;-)
<wpwrak_>
aw: can you show us the signal with scope on TP37 and ...
<wpwrak_>
.. TP36 (FLASH_RESET_B and PROGRAM_B_2)
<wpwrak_>
grr. FLASH_RESET_N
<aw>
well...i am not sure if this is meaningful to you to scope my rc2 board....if you still insist. ;-) because I used fix1.png then failed..not sure flash chip is completely restored though.
<wpwrak_>
maybe connecting the scope will magically fix things :)
<aw>
now I powered cycle, then D2 & D3 dimly lit so didn't reconfigure.
<aw>
alright
<wpwrak_>
and of not, it'll still show how well the 100 pF cap works
<wolfspraul>
I think you should stay on that rc2 board
<wolfspraul>
you cannot always jump around boards out of fear that 'something' may be broken
<aw>
moments
<wolfspraul>
especially not since we are basically doing a design and design verification here
<wolfspraul>
so you stay on that rc2 board, and make sure it behaves as we think it should, on all pins/test points
<wolfspraul>
if the flash failed, just try flashing a second time first
<wpwrak_>
wolfspraul: of course, what adam isn't saying explicitly is just how badly damaged the board looks now after all the rework, cutting then restoring traces, etc. ;-)
<wolfspraul>
yes but I don't think we should base decisions on fears of "flash broken" pretty much after every work step
<wolfspraul>
with that logic we should have a supply of 100 fresh boards, and we throw each one away after the very first work step we did on it
<wolfspraul>
so it also helps Adam to remember that we are in control of this board (in theory :-)), and we don't need to be afraid at 'breaking' something even when we run a simple flashing script (for example)
<wolfspraul>
so we want to pin this down, understand and fix the reset/reconfigure/boot behavior
<wolfspraul>
that's even better to do on a slightly worn out board than a new one :-)
<wolfspraul>
and once we are clear, we are moving to the nicer rc3 board and hopefully it all works like a charm then
<wolfspraul>
otherwise we are simply spreading our confusion (=design work) to multiple boards. nothing gained, just more confusion.
<wpwrak_>
wolfspraul: (throw away after each test) and get a new sterilized and and vacuum-wrapped one from the freezer ;-)
<wolfspraul>
we are in control of these boards, and this design. even if it may not look like that right now ;-)
<wolfspraul>
but anyway I'm just sitting here, Adam is at the front line with the board
<wolfspraul>
I would try to pin this down on one board, and stay on that board.
<wpwrak_>
it's less a question of being in control of the design but just the amount of trouble you amass during rework. boards to get worse when being reworked. and at some point, you just don't trust your board anymore. maybe it's still okay and what you see is the real problem. maybe you've long ago stopped making progress and are just chasing ghosts. you basically have to trust your instincts there.
<wolfspraul>
and in my experience, sometimes the operator is worn out, not the board.
<wolfspraul>
these kinds of reworks are more stressful on the human doing them, than the board. that's my experience.
<wolfspraul>
so it may be better to sleep over it, rather than to move the worn out operator to a new board. just my experience, that's all.
<wolfspraul>
electrons still don't know whether they flow on a board that was reworked many times or a new one :-)
<wpwrak_>
i like to have 2-3 "identical" boards. when one acts funny, i try another. if they both do the same, i probably see a real problem. if both act differently and i can find no differences in the rework, i try on the 3rd.
<wolfspraul>
yes sure, I understand
<wolfspraul>
I am not against it, we are just chatting
<wolfspraul>
Adam will decide what he thinks is right
<wolfspraul>
but you understand my point about fear and confusion spreading
<wolfspraul>
that can also happen
<wpwrak_>
(tired operator) yes, human factors are important too :)
<wpwrak_>
yes yes, you can get lost for no good reason, that's true
<wolfspraul>
it's always in the last 1-2 hours of the day that the biggest mistakes are made
<wolfspraul>
"oh, let's quickly try this one last thing, on that board over here"
<wolfspraul>
when I hear that I already know what's going to happen next
<wpwrak_>
things will be better with a larger supply of boards from SMT. then adam can switch if he feels uncertain. we should be converging rapidly now anyway
<wpwrak_>
;-)
<wolfspraul>
boards = boards - 1
<wolfspraul>
that's what's going to happen
<wpwrak_>
;-)
<wpwrak_>
btw, the scanimate guy could perhaps also help with a by-cc* picture of that system. you could use that for talks and such. "before" and "after" :)
<wolfspraul>
wpwrak_: what is Adam doing now? :-)
<wolfspraul>
hopefully he's not distracted reading up on our chatte
<wolfspraul>
chatter
<wpwrak_>
probably connecting his scops. maybe trying to reflash again. we'll see :)
<wolfspraul>
about the Scanimate by-cc - sure, I agree. but I'm taking this slowly. These kinds of people are into their 'thing' for decades. I will reply, maybe I will sell an m1 to him (he asked already), we start some chit chat about the Scanimate and Milkymist One.
<wolfspraul>
maybe distributor deal? of course that'd be great
<wolfspraul>
once those things are established, questions of 'licenses' for pictures completely disappear by themselves
<wpwrak_>
yeah. you can just ask for a picture :) i don't think the license is a big deal
<wolfspraul>
but if I come with these nasty little things now - not good. I wouldn't want that myself. Many people rightfully think this copyrightization of everything is a disease.
<lekernel>
wpwrak_, why did you use 250pF for the diode capacitance?
<wolfspraul>
so my focus is to get to know people, what interests them, where the overlap with m1 is, how I can sell an m1 to them, and then grow from there
<wpwrak_>
no no ... the problem with licenses we have at the moment is simply that the pics you find on the net have unknown status. if you ask someone to send you a picture, they'll usually assume you do whatever you want with it (unless they're professional photographers)
<wpwrak_>
lekernel: that;s the zero bias junction capacitance. see fig. 5 on page 2 of the data sheet. it's higher than the 4V capacitance from page 1
<wpwrak_>
lekernel: (i hope i got all this right. i don't know nearly enough about junction modeling for more than educated guesses :)
<lekernel>
but bias voltage is 3V, no?
<lekernel>
3.3
<lekernel>
mh
<lekernel>
in fact it depends
<lekernel>
rha, those diodes really are tiny bits of crap
<wpwrak_>
the diode model in qucs only has the zero bias capacitance. i suppose it adjusts it for the actual bias (which varies during the simulation)
<lekernel>
200pF, 2mA reverse currents at 100C, and what not
<wpwrak_>
;-)
<lekernel>
even diodes that are _meant_ to be used as varicap have less capacitance
<aw>
my program_b and flash reset pin is all below 200mV, there's somethings wrong but D2 &D3 keep dimly lit. strange so i can't capture from trigger power up.
<aw>
checking...
<wpwrak_>
things like 1N4148 are less crazy. but schottky gets evil. and the old Si ones don't work so well at modern low voltages. that's why these clever solutions from yesteryears suddenly become trouble if you try to apply them to modern circuits.
<aw>
hmm...jtag's 'detect' commands replys well.
<lekernel>
aw, if program_b stays below 200mV your circuit is not correct, period
<lekernel>
no need to use JTAG
<lekernel>
it should be below 200mV during the first 200ms then go high
<lekernel>
anything else is wrong
<lekernel>
as long as you do not get this, no need to look any further
<lekernel>
is the polarity of the diodes correct?
<aw>
yes, i didn't find program_b goes high..maybe reset ic I soldered in failure. ..should not be that. ..checking.
<aw>
since my reset ic doesn't work now...so its output keeps low and the also causes init_b & flash_reset always low. bad...but it just still was reflashing ...and i can see D2 & D3 are flashed.
<aw>
bad. need to replace a new reset ic again. ;-)
<wolfspraul>
wait, one second
<wolfspraul>
aw: so you think in some of the reworks or tests, the reset ic broke? and now you will replace it for a new one?
<wolfspraul>
that sounds good! at least you keep overview.
<wolfspraul>
we still may not know why it 'failed', but that doesn't matter, at least it's localized, we swap it for a new one, and move forward. sounds right to me so far.
<aw>
now i just disconnect my reset ic's output and program_b. Power-up, then reset ic's output is 3V3, RP# is HI, init_b also HI
<aw>
and found fpga's program_b is Low though. this approves my reset ic can still work well.
<aw>
so don't know why fpga's program_b can't release its pin to be HI, thus it's always pull low. :(
<aw>
got my points?
<wpwrak_>
sounds very fishy indeed
<aw>
read my sentences carefully. ;-) although my english still no t good to explain.
<wolfspraul>
aw: move to rc3 board? :-)
<wpwrak_>
could C238 be shorted ?
<wpwrak_>
wolfspraul: *grin*
<aw>
if there's something you still doubt, let me know
<aw>
hmm..maybe...moment
<wpwrak_>
wolfspraul: see what you get for micro-managing ;-)
<wolfspraul>
Adam won't let me influence him, I'm not worried :-)
<wpwrak_>
hehe, that's also true :)
<aw>
wpwrak_, i remembered I measured if C238 is short.
<aw>
well...check if short again
<aw>
40 ohm almost short. but this is not right. i did measure it's ok and also i have been reflashed it even it had have err.
<aw>
btw, now take apart C238 to see if that program_b still short to gnd. ;-)
<aw>
hmm only program_b,  has 7.5K ohm..so probably C238 I soldered not good enough. go to solder a new one. ;-)
<aw>
yeah...replaced a new 100pF and all good on soldering. but program_b now is only 0.5V roughly...still doesn't pull high.
<wpwrak_>
i suspect death by rework. you could try to undo the various changes, clean the board, etc. then try again. but may be faster to give fix2 a try with rc3
<aw>
seems fpga inside failed indeedly...now go to rc3
<wpwrak_>
great minds think alike :)
<aw>
yeah...too many reworks at same parts. :(
<aw>
reflashing now...
<aw>
rc3 + fix2 reflashed successfully. ;-)
<aw>
now to press middle btn.
<aw>
boot up...
<aw>
D3 ON, rendering now...
<aw>
keep more minutes...
<aw>
rendering ...with my camera...;-)
<aw>
enough...
<lekernel>
ok, power cycle it many times now
<aw>
now go to count how many times we can power cycle
<aw>
wait..
<aw>
should i go to gui to use shut down to press 'Power off' then press 'middle btn'?
<aw>
i do now...wait
<wolfspraul>
every way should work
<lekernel>
you can try it to check it still works, yes
<lekernel>
but also power cycle
<lekernel>
this is the most important
<aw>
good..now  start to boot up...ing...
<lekernel>
on rc2 i've never had issues with the power button in the GUI
<aw>
yeah... ;-)
<wolfspraul>
imagine you are the user. if something does not come up and render graphics, it's wrong.
<aw>
good now..also rendering...now directly power off and power on
<wolfspraul>
wpwrak_: does your simulation suggest that 100pF on C238 is safe?
<aw>
2nd  boot up...
<wolfspraul>
should we measure any values to give you more input data?
<aw>
rendering...wait...a little...
<wolfspraul>
wait 2 minutes at least
<aw>
2 minutes?
<aw>
alright..;-)
<wolfspraul>
sure
<wolfspraul>
later you can let it render through the entire night
<wolfspraul>
it must still work in the morning when you get up
<lekernel>
you can also power cycle many times and check that the LEDs go fully off (without booting)
<wolfspraul>
I want to run a 1h render test on each board of the rc3 run anyway, but that's for later...
<aw>
lekernel, yes..now i am very carefully on LEDs.. ;-)
<aw>
3
<aw>
yes let it render through entire night.
<lekernel>
aw, wait, power cycle many times before
<aw>
sure ...
<lekernel>
aw, and just check the LEDs go fully off
<aw>
i am thinkging at least before i sleep to 30 times ~ 40 times...
<lekernel>
yes, do not boot, it should be fast
<aw>
wait...
<aw>
do not boot? to test many times firstly?
<aw>
just reconfiguration at least 100 times. is it ok? is that your meaning?
<aw>
;-)
<lekernel>
yes, that's what i mean
<lekernel>
of course, try booting later
<aw>
hmm...different to Wolfgang
<aw>
alright..let count 100 times to reconfiguration now...
<aw>
good ..10 now
<aw>
20
<aw>
30
<aw>
40
<aw>
50
<wolfspraul>
100 is definitely enough, after that we do some tests where we boot all the way to rendering
<aw>
60
<aw>
70
<aw>
this test is a must i think. also testing our new DC adapter. ;-)
<aw>
i actually power cycle by my power cord's switch...not to plug-in & out DC plug. ;-)
<aw>
80
<wolfspraul>
in general it's a good idea to test in the same way a user would use the product
<aw>
90
<aw>
100
<aw>
good
<lekernel>
great
<aw>
now we to see if still can boot up...
<wolfspraul>
yes, all the way to render, and let it render for 30 seconds.
<wolfspraul>
or 20 maybe :-)
<aw>
umm...set my second alarm
<wolfspraul>
if it works 30, 40, 50 times in a row, that's definitely better than before.
<wolfspraul>
ha ha :-)
<wolfspraul>
well, I mean don't immediately turn if off again. let's try to make our test behavior at least a little closer to real users.
<aw>
4
<wolfspraul>
also I think you can try to physically unplug the DC jack, rather than flipping the switch on your lab supply
<aw>
ok
<wolfspraul>
when we can, and when we don't have a reason to not do so, we should always try to imitate real user behavior when testing
<wolfspraul>
of course if we have a programmed lab supply and let it run over night with thousands of cycles, that's another thing
<wolfspraul>
so I say "when we don't have reason to not do so", then you can imitate normal user behavior, it's better I think
<aw>
yes...this sounds reasonable...user usually may turn on power adapter first then plug in...
<wolfspraul>
depends. you can test both :-)
<wolfspraul>
but that's exactly my point. let's try to imitate our users.
<wolfspraul>
not just flip switches on lab supplies...
<aw>
5
<aw>
6
<lekernel>
sounds good so far, let's hope it's reproducible across the entire batch
<lekernel>
when do you get the boards back from SMT?
<wolfspraul>
I suggest Adam can do a full boot-to-render cycle let's say 100 times on this board. for the entire run, we can go down to 10 first, and if there are no problems on the first 20 boards, go down to 5, etc.
<aw>
7
<aw>
seems they won't be done until Tuesday evening...
<aw>
i called supervisor yesterday
<aw>
but it's all fine. i'd like they do their good internal job.
<lekernel>
tuesday? good
<aw>
8
<lekernel>
this gives a little more time to test this one board
<aw>
this may means I only receive them in Wednesay
<wolfspraul>
once Adam knows for sure which additional fixes we need (post-rc3), he can try to have the factory do it
<wolfspraul>
but since it's not their mistake, they will ask for an extra payment and may not want or be able to do it at all (depends on their load)
<aw>
now i m thinking how a good way to rework all batch.
<lekernel>
I hope this fix2 is not too ugly... with the r158 on the bottom side
<wolfspraul>
of course we will try to have the factory do it, but they have to agree, find staff, and they will charge extra (which is OK)
<aw>
it's not good idea to ask for smt factory to rework all which is we added parts and one wire need soldered from top side to bottom side.
<wolfspraul>
a wire all around the board?
<aw>
i couldn't answer this question now..i need to deal and ask them tomorrow.
<wolfspraul>
yes sure
<wolfspraul>
I am just explaining for Sebastien
<lekernel>
if there's a wire all around the board, we must make sure it still fits in the case
<wolfspraul>
aw: continue the boot-to-render testing until we are at 30 or so, better 50
<aw>
program_b to init_b, this connection I used a long wire. ;-)
<wolfspraul>
there's a wire around the whole board?
<wolfspraul>
that's pretty gross :-)
<aw>
yes
<aw>
9
<lekernel>
electrical engineering is intrinsically gross
<wolfspraul>
can't we get rid of this wire?
<aw>
can't
<lekernel>
as long as it fits in the case, i'm fine with that wire
<wolfspraul>
can you upload a picture of the reworked rc3? both sides
<aw>
which that pad directly go to fpga area, no pad or else i can solder from top. ;-)
<aw>
yes. tomorrow I upload two pictures. ;-)
<aw>
10
<aw>
so i don't think Minbo will do. surely i need to deal with them.
<aw>
11
<wolfspraul>
aw: do you have an assembled acrylic case there?
<lekernel>
other than that, it should be a simple fix
<aw>
12
<lekernel>
aw, also be careful when picking a diode, if you change it
<wolfspraul>
if not, please take one of the cases you have and assemble it, and make tests that the wire is run in such a way that it fits in the case, and that the wire goes down in a somewhat protected place, maybe between connectors or so, don't know
<aw>
i currently put wire between both DMX connector which is not good.
<wolfspraul>
I take it we can't drill a new hole in the pcb? :-)
<wolfspraul>
I mean not right in the middle, but somewhere are the side maybe? don't know. maybe not a good idea.
<lekernel>
it'll definitely fit behind the front plate
<lekernel>
there is extra space for the buttons
<aw>
haha..i checked this afternoon...
<lekernel>
we have 4 good millimeters, more than enough for a small wire
<aw>
no suitable hole to directly though this wire from top to bottom. :(
<wolfspraul>
you mean drill a hole? don't understand what you mean with "behind the front plate"
<lekernel>
no i'm talking about using wire
<lekernel>
I don't want to drill a hole in a 6 layer PCB
<lekernel>
messy
<wolfspraul>
yes me too. but I'm wondering whether we can drill a hole somewhere to avoid that it is running over the edge of the pcb.
<aw>
me either...must not drill the pcb!
<wolfspraul>
maybe there's an unused space somewhere on the sides... I'm just thinking.
<wolfspraul>
alright, no drill, done
<wolfspraul>
:-)
<aw>
13
<lekernel>
there are the power planes everywhere, and it's going to be too easy to short circuit two with e.g. fillings from the drill
<aw>
exactly
<wolfspraul>
understood
<aw>
14
<lekernel>
just use a long wire, it's low frequency anyway... glue it in place, make it go behind the front plate of the case, done
<aw>
yeah
<aw>
15
<aw>
16
<aw>
17
<aw>
you guys can keep chatting..otherwisw i am a little nervous. haha
<aw>
18
<wolfspraul>
ha, superstitious
<wolfspraul>
I wanted to ask Sebastien a question about rc4, but I thought it's bad luck until the test is at least at 30 :-)
<wolfspraul>
so this time I will wait, until we have final data, and then I will proceed
<aw>
19
<wolfspraul>
you can reduce the render time a little, 20 seconds is enough
<aw>
20
<wolfspraul>
if it stays solid, reduce to 15
<aw>
ha..i count 30 second...
<wolfspraul>
I just want to rule out this problem we had on the other board with the board shutting down after a few seconds.
<wolfspraul>
alright then
<wolfspraul>
it must work for hours anyway, for days
<wolfspraul>
if this is all positive now, I suggest you keep the board running overnight
<wolfspraul>
tomorrow morning it should still render...
<aw>
21
<aw>
alright...now reduce to 15 seconds.
<aw>
22
<wolfspraul>
yes, good [15 secs]
<aw>
23
<wolfspraul>
maybe we do 30 today, that's enough
<aw>
24
<wolfspraul>
then another 70 tomorrow, which brings us to 100 and is enough as a 'design verification'
<aw>
well..good is good, bad is bad
<aw>
25
<aw>
a continuous test keeps boards warm. a temperature...well time here is later. ;-)
<aw>
26
<aw>
ok
<aw>
after 30 times, i let it rendering through whole night. ;-)
<aw>
27
<aw>
28
<aw>
29
<aw>
30
<aw>
oaky..finished fisrt 30 times
<wolfspraul>
ok good
<wolfspraul>
now, here is my proposal:
<wolfspraul>
1) let it render through the whole night, check that it's still running tomorrow
<aw>
put it well and rendering all night with mixing camera's source
<wolfspraul>
if it is not running tomorrow, measure some test points to try to understand in which state it is (let's hope this is not needed)
<wolfspraul>
2) if lekernel or wpwrak_ want any more measurements to verify fix2, they need to speak up. otherwise you can just measure yourself whatever you want to know to confirm or understand fix2
<aw>
dispalyed title and auto switch
<wolfspraul>
yes, it will do that
<wolfspraul>
3) tomorrow you do another 70 test cycles of the full power cycle, and boot to render, let it render 15 seconds or so
<wolfspraul>
if you want you can try to recover your rc2, or maybe write it off :-) your choice...
<aw>
tomorrow after tests, i still need capture RP# and program_b for records.
<wolfspraul>
it's your last rc2 so a little unfortunate if we loose it
<wolfspraul>
4) if all goes well, document fix2 as rc3 known issues
<aw>
'temporarily' loose rc2. one day...don't know ..;-)
<wolfspraul>
5) think about how to best do the rework for the other 89 boards, factory and/or you
<wolfspraul>
6) for bootup testing on the other 89 boards, I propose that we start with something like 10 boot-to-render cycles on the first boards, say 10 or 20. And if that is good, we reduce the cycles to 5, then maybe 2.
<wolfspraul>
that's about it from me, I think
<wolfspraul>
oh
<wolfspraul>
7) take pictures of your reworked rc3, both sides
<wolfspraul>
that's all
<wolfspraul>
makes sense?
<aw>
got it.
<wolfspraul>
1 am - thanks a lot for your great work today!
<aw>
thanks a lot all of you guys here the contributions. thanks!
<aw>
see you guys tomorrow. ;-)
<lekernel>
gn8
<wolfspraul>
cu
<aw>
cu
<lekernel>
mh, is it possible to map read-through RAMs to block RAMs on spartan6? or does this generate extra logic (and more importantly, extra timing problems)?
<lekernel>
?! xst infers flip flop and a _asynchronous_ ramb16bwer primitive
<lekernel>
ah, no, it was just for CE
<wpwrak_>
wolfspraul: (100 pF enough) according to my simulation, it's insufficient. but i'd need to see a real life scope trace to tell how close the simulation is to reality
<wpwrak_>
wolfspraul: in general, this extra cap should be as small as possible, or it could develop a life of its own
<wpwrak_>
checks the time. my, that siesta was quite long :)
<wolfspraul>
wpwrak_: scope trace of what?
<wpwrak_>
wolfspraul: of PROGRAM_B_2 when FLASH_RESET_N is driven low
<wolfspraul>
for 'insufficient', we already know with 47pF it seems to work as well (though not extensively tested)
<wolfspraul>
so with 100 we are about twice that much
<wolfspraul>
and still far away from the 1nF we know causes a very bad 'life of its own' after a few seconds of rendering
<wpwrak_>
you could still be in the middle of the meta-stable range. that's a place you don't want to be if you can avoid it :)
<wolfspraul>
so if I just look at these numbers, no simulation, no scope traces, 47 < 100 < 1000, looks OK :-)
<wolfspraul>
oh I am totally interested in more hard calculation of the 'correct' value
<wolfspraul>
ideally one would think we have a hard lower boundary, and a hard upper boundary, and with all tolerances and what not hopefully there is space between those two
<wpwrak_>
i'd also prefer 100 pF over 1 nF. but ... a real-life measurement should prove that. sometimes, we get what we want. sometimes, murphy has other plans for us :)
<wolfspraul>
we know 1nF is bad, will cause an auto-shutdown after a few seconds of rendering (not sure this was with fix2, but with 1nF for sure)
<wolfspraul>
OK, Adam will definitely provide a scope trace for program_b_2 when flash_reset_n is low tomorrow...
<wpwrak_>
you also have to bear in mind that we don't know when exactly the rc2 board developed it fatal flaw. so a number of "this doesn't work well" results already before fix4 may be flawed as well.
<wolfspraul>
no I think the first 1nF test was on rc3 still
<wolfspraul>
could be wrong though
<wolfspraul>
let's just take the scope trace tomorrow
<wolfspraul>
empirically, 100pF is ok right now :-)
<wolfspraul>
we will definitely do serious boot-to-render testing on all rc3 boards, no worries
<wpwrak_>
that's a good result in any case. we know in which direction to look for a fix that doesn't appear to have any ill side-effects and that is still of acceptable complexity
<wolfspraul>
well, a wire around the entire board is pretty ugly :-)
<wolfspraul>
but that's ok
<wolfspraul>
it should be stable, that's the most important thing
<wpwrak_>
regarding the extra wire, you can just fix it on the board with a drip of silicone/elastic glue every few 1-2 cm. then it will be as good as any other permanent feature of the board.
<wpwrak_>
s/drip/drop/
<wolfspraul>
wpwrak_: you are right, the original 47pF and 1nF C328 tests were already done on rc2, not rc3
<wolfspraul>
that's a crazy long backlog today, but that's what it says up there...
<wolfspraul>
ok we will spend some more time tomorrow to verify the 100 pF value, it's worth it I think
<wpwrak_>
i don't know how easy it is to force FLASH_RESET_N low. if it's difficult to do this from the FPGA, just touching a 47-100 Ohm resistor between ground and FLASH_RESET_N (TP37) would have the same effect
<wpwrak_>
the scope should show FLASH_RESET_N/TP37 for verification and PROGRAM_B_2 (TP36)
<wpwrak_>
probes should be all 1:10, to add as little parasitic capacitance as possible. (parasitic capacitance makes the result look better)
<wolfspraul>
ok
<wpwrak_>
simulation predicts that PROGRAM_B_2 should drop from 3.3 V to ~1.7 V, with slow recovery (about 1 us until 2.5 V)
<wpwrak_>
so the scope should be set to about 100 ns/div, falling edge trigger on FLASH_RESET_N
<wpwrak_>
if the minimum in the drop stays above 2.5 V (or if no drop is visible at all), that would mean green light. 2.2-2.5 V, yellow (i.e., you're close enough to the limit that without the scope, the drop may be too deep to meet specifications). < 2.2 V, red (i.e., you're at or below)
<wpwrak_>
oh, wait. no, sorry. got the wrong spec. you have a bit more tolerance
<wpwrak_>
< 1.7 V = red, 1.7-2.0 V = yellow. > 2.0 V = green.
<wpwrak_>
if you drop below 1.65 V, you enter the unspecified zone of the chip, where it may or may not react, and its reaction may not be entirely predictable. if you drop all the way down to <= 1.1 V, you're in the specified range again, but it'll do something you don't want it to do (i.e., reset). simulation predicts that the measured drop will be around 1.4-1.6 V, while the drop without measurement would be even a little lower.
<wolfspraul>
understood
<lekernel>
'half reset' can be pretty nasty I guess
<lekernel>
e.g. some parts of the chip get reset, other don't
<wolfspraul>
my feeling is that the numbers we measure will be better than this (because we doubled from a value that was already known to work), but let's see
<wolfspraul>
what does your simulation show for 47 pF?
<lekernel>
there can be a great amount of PVT variations on such a fix
<lekernel>
unless we get zero problem with it on the run 3, it'll be wise to switch to AND gates on run 4
<wolfspraul>
somehow I'm optimistic that we find a stable value, or that we have it already in 100 pF
<wolfspraul>
that's a total guess of course, I understand both lekernel and wpwrak_ feel a little more uneasy...
<kristianpaul>
wpwrak_: i'm curioos, what software are you using for simulation?
<kristianpaul>
and the 'fpga pins model' for the analog simulation came from...
<kristianpaul>
in any case, nice work indeed, i had learn much just reading your chat :)
<wpwrak_>
(47 pF) for 50 pF, i get a drop all the way down to 0.8 V. but that's of course not realistic, because it doesn't take into account any parasitic capacitances.
<lekernel>
" For most individuals and most small scale technical startups, any involvement whatsoever with the patent system is virtually certain to end up as a net loss of time, energy, money, and sanity" http://www.tinaja.com/glib/hackar3.pdf
<lekernel>
btw, is it just me, or was "hardware hacking" better in 1992?
<wpwrak_>
the good old times :)
<wpwrak_>
please remind me, how much was a decent fpga back then ? :)
<mumptai>
and remember schematic-entry designs
<wpwrak_>
gEDA may have ben around back then. at least it feels that old :)
<wpwrak_>
and for simulation spice, of course ;-)
<mumptai>
typing in netlists .. arg
<lekernel>
well, it's still hard to find articles on e.g. EDM today
<lekernel>
or radar modulation
<wpwrak_>
i never had the stomach to figure out spice ;)
<kristianpaul>
i 1992, you can get ie, a gpsreceiver and take apart correlator from mcu, so i should said yes it was better :)
<mumptai>
what do you want to know about radar modulation?
<kristianpaul>
well, not that i did that, but i read soem gps hacker used too, and wonder what else...
<lekernel>
mumptai, atm, how I could modulate electronically the frequency of those 24GHz gunnplexers I scavenged from door openers
<wpwrak_>
mumptai: as an evil overlord, you have to know about radar. make death rays. to destroy ze enemy :)
<mumptai>
ahh
<lekernel>
those critters have a second slot for a detection diode, I wonder if I could put another one in the slot and use it as varactor
<mumptai>
yeah, deathrays impotant, i like lasers more
<lekernel>
moment, let me upload some pictures
<kristianpaul>
wpwrak_: i wonder if in that time, what we're requirements in FPGA world, ie to get a soc like milkymist..or and quivalent (8/16 bits cpu i guess..)
<mumptai>
i'm not sure if dc-bias is a good way to moudlate a gunn oscillator, i might just give very little modulation depth
<wpwrak_>
kristianpaul: well, 1992 was around the time then pentium I appeared. we bought a few PI@90Mhz in 94, so it must have come out around 93. i think i bought a laptop with a 486 in '93. my joy and pride. even had a color display ;-)
<wpwrak_>
lekernel: does that project have any specific objective ? or are you just exploring ?
<lekernel>
just exploring
<lekernel>
and try to do a SAR
<kristianpaul>
wpwrak_: ha,lucky, i got my first computer a PII, by 2001 :)
<mumptai>
if i remember that typ of oscillator correctly, it need a resonant cavitoy or circuit
<lekernel>
yes, there is a cavity
<lekernel>
but this thing is one piece cast metal
<mumptai>
you might just add the modulation there
<lekernel>
how?
<mumptai>
really old radar user a mechanicaly changing cavity
<mumptai>
but a intoducing some varying capacitive load might to the trick
<lekernel>
the only ways I can access the cavity is through the "IF2" slot (I don't know its intended purpose), which would be convenient if it worked with the same detection diode
<kristianpaul>
(radar) there are radards for motorcyles btw?
<mumptai>
the tricky part is find a good spot to integrate it
<lekernel>
and with the tuning screws at the other side (not pictured)
<lekernel>
do you think it could work 1) in the IF2 slot 2) with a detector diode (which has the right mechanical dimensions to fit in IF2)?
<lekernel>
I don't want to mechanically modify the cavity, as I would most probably break it
<mumptai>
i would a asume only a low coupling between emiter and detector, but i might be wrong
<mumptai>
so detuning it from the detector might not work
<lekernel>
then, use a stepper motor (or similar) on the tuning screws? :)
<mumptai>
that would work
<lekernel>
it'd be slow though...
<lekernel>
any rough figure on the frequency change I could get per step?
<mumptai>
doesn't need to be
<mumptai>
tuningrange depends on the cavity, and the placemant of the screws
<lekernel>
I should also get myself a 24GHz frequency counter.. phew
<mumptai>
if you get engouh power a these standing wave thingys with the sliding voltage probe might also work
<mumptai>
and a full-em simulation might also help with work on the cavity
<mumptai>
and an extra supply of coffee while you are waiting for sim .. how i hated that part
<wpwrak_>
mumptai: or a soft bed ? :)
<lekernel>
that critter consumes some 450mW... what's the typical output of a Gunn oscillator?
<mumptai>
sounds like a lot, but i've got no idea
<mumptai>
maybe placing a biased varactor in place of the tuning rod might work, but its hard to do experimental work without some way of measuring the system
<lekernel>
the fastest prescaler I can easily order only goes to 14GHz, and that's already a 50E chip
<lekernel>
this is frustrating
<mumptai>
and the cable to hook up an experiment to an analyser is like 300¤ a piece
<mumptai>
would have been nice for my laser rangefinder, but that is history now
<kristianpaul>
laser? :-)
<mumptai>
yeah, a modulated laser diode
<wpwrak_>
kristianpaul:Â Â meanwhile, he moved on to "slow" neutrons. easier to detect when they hit something :)
<wpwrak_>
laser rangefinders are fun, though. even the commercial ones :)
<mumptai>
actually the project was doomed without money for a decent coaxial optics assembly
<mumptai>
the commercial ones usually have custom build off-axis optics which are a lot nicer, but even more expensive to start with
<wpwrak_>
i suppose the numbers bring the cost down there as well
<mumptai>
yes, and they can use it to lower the requirements on the signal chain's dynamic-range too
<mumptai>
got to go
<mumptai>
bye
<mwalle>
pfew, qemu mm softusb and vgafb is broken
<wpwrak_>
mwalle: that sounds fairly comprehensive. is c still roughly at the same order of magnitude ? :)
<mwalle>
wpwrak_: like what?
<wpwrak_>
roughly 300Mm/s in vacuum :)
<wpwrak_>
of course, once you get to confirm the speed, we have to question the meter and the second :)
<mwalle>
ah you mean c = speed of light
<mwalle>
wpwrak_: are you talking to the wrong person? :)
<wpwrak_>
naw, just observing that you seem to suffer fairly widespread failure :) but having had a discussion about more basic physics helped to shape the joke :)