Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
r33p [r33p!~rep@bon31-2-89-85-157-97.dsl.sta.abo.bbox.fr] has joined #milkymist
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<azonenberg>
So i'm looking at a bit of code for XC6SLX45 that's failing timing
<azonenberg>
in planahead it looks to be ff -> lut -> ff
<azonenberg>
in the path report i see 2.25ns of delay in a FD
<azonenberg>
how does that make sense?
<cladamw>
will ask what brand & p/n of that liquid.
<wpwrak>
interesting. that basin is too small :)
<cladamw>
the video & picture weren't took by me though. :)
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
<cladamw>
wpwrak, what's liquid when you're using?
<wpwrak>
normally just demineralized water
<wpwrak>
(car supply :)
<cladamw>
wpwrak, ah. you used that? hehe. okay... once I know what they used, I'll tell you. :)
<wpwrak>
isopropyl alcohol should also be safe
<wpwrak>
with other solvents, you have to be careful that they don't eat your PCBA ;)
<wpwrak>
e.g., i wouldn't try paint thinner :)
Gurty` [Gurty`!~princess@ALyon-256-1-203-142.w109-212.abo.wanadoo.fr] has joined #milkymist
n0carri3r [n0carri3r!~nocarrier@184.152.67.214] has joined #milkymist
<n0carri3r>
evening all
wpwrak [wpwrak!~werner@94-163-231-201.fibertel.com.ar] has joined #milkymist
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<stekern>
the mvu pseudo-instruction (ori rX, r0, I) doesn't seem to be mentioned in the lm32 reference manual, is this something that has been added afterwards?
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
mumptai [mumptai!~calle@brmn-4d0ad60d.pool.mediaWays.net] has joined #milkymist
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
Martoni [Martoni!~chatzilla@ip-167-165.evhr.net] has joined #milkymist
wolfspraul [wolfspraul!~wolfsprau@p5B0AB014.dip.t-dialin.net] has joined #milkymist
kristianpaul [kristianpaul!~kristianp@unaffiliated/kristianpaul] has joined #milkymist
qi-bot [qi-bot!~qi-bot@turandot.qi-hardware.com] has joined #milkymist
mwalle [mwalle!~mw@services.serverraum.org] has joined #milkymist
r33p [r33p!~rep@bon31-2-89-85-157-97.dsl.sta.abo.bbox.fr] has joined #milkymist
<wolfspraul>
cladamw: so... :-)
<wolfspraul>
it seems the rc3 production effort is completed?
<cladamw>
yes, the remaining two I'll let minbo to help.
kilae [kilae!~chatzilla@catv-161-018.tbwil.ch] has joined #milkymist
<wpwrak>
cladamw: s/darn/curse/ ? :)
<cladamw>
wpwrak, darn not curse. :) I copied it.
<cladamw>
wpwrak, hmm...just found I typed another word wrong: since an unqualified and unverified with strict reviews after rc2 run we made.
<cladamw>
s/with/without :)
<cladamw>
heart and hand were not synced.
<wpwrak>
ah ;-) well, most people would just call it "an oversight" :-)
<cladamw>
wpwrak, I'll draw rc4 schematic firstly and include 2*2 usb connector and another usb power switch to let house see if have enough space to placement.
<cladamw>
mmm...that's good word of "oversight".
<wpwrak>
(4 x USB) great ! the more, the merrier :)
<wpwrak>
interesting. didn't realize you had more than one type of chips that was fake. so it was schmitt-triggers and USB transceivers. or were the usb transceivers just broken, but from the correct source ?
<wpwrak>
i don't understand the VGA DCC issue. are you saying the cable was defective ?
<cladamw>
unqualified usb transceiver caused impedance short from TP1(3.3V) to GND. the source of it is the same as schmitt-trigger.
<cladamw>
just replugged it or switch to another expendable cable will be also pass. not s/w problem.
<wpwrak>
heh. now we know what they don't test when making those cables :)
<cladamw>
wpwrak, but if you found VGA DDC issue could be caused by s/w then I might be wrong.
<cladamw>
but i just surely a 'replug' or 'exchange' cable will pass it. :-)
<wolfspraul>
rc3 yield is now 88/90? :-)
<wpwrak>
"exchange" sounds like hardware. "replug" could be software. dunno, haven't looked at that at all
<wpwrak>
wolfspraul: if adam makes three more boards work, it's time to get suspicious ;-)
<cladamw>
wpwrak, the correct usb transceiver I soldered now is from Digikey.
<cladamw>
wpwrak, oah...really? so 'exchange' and 'replug' could be different at all?
<wpwrak>
maybe ... or maybe it's the same. some of those statistical errors can be hard to pinpoint.
<cladamw>
i only exchanged one cable once and kept to use it if I found DDC fail then I just 'replug' then pass.
<cladamw>
so from your words: "exchange" >> hardware, "replug" >> s/w, if it does, then it can be s/w.
<cladamw>
Although I bought 3 expendables but only kept to use one cable to test all whole rc3 boards, let's hope not the hardware. :(
<wpwrak>
;-)
<cladamw>
wolfspraul, now yes is 88/90.
<wolfspraul>
good
<wolfspraul>
a little too high but we are not under 'sales pressure' so that's the best use of our time on the manufacturing side
<wolfspraul>
maybe I should say 'demand pressure' :-)
<wolfspraul>
but it's good that we made so many valuable findings in rc3
<wolfspraul>
2 more boards to find out about, right?
<wolfspraul>
so our rc4 target yield rate will be a cool 100% :-)
<cladamw>
yes, two more. let's hope that. M1pre-rc4 already has had big routing there.
<wolfspraul>
wpwrak: how about mechanical stability of the daughterboard which you mentioned several times?
<wolfspraul>
should we do something about that in rc4?
sb0 [sb0!~sb@AAmiens-551-1-119-172.w83-192.abo.wanadoo.fr] has joined #milkymist
<wpwrak>
i think it would be nice to have a second connector, like J21, but as far as possible from it, with no tall components in between, and Jnew and J21 parallel and aligned with each other. so that you can make a "U"-shaped board. kinda like the arduino shields
<wpwrak>
we still have a bunch of unassigned FPGA pins. maybe we could route them there
<sb0>
azonenberg, use fpga editor to get a lower level view
<cladamw>
wpwrak, hmm..."U"-shaped
<wpwrak>
well, inversed U :)
<wpwrak>
so that, if you make a PCB, J21 is on one side, Jnew on the other -> great mechanical stability
<wolfspraul>
ok
<wolfspraul>
cladamw: does that make sense?
<cladamw>
wolfspraul, what would you try to say?
<wolfspraul>
werner just described some ideas for an improved expansion connector
<wolfspraul>
or rather 2, to be both backward compatible and also add mechanical stability to daughterboards
<cladamw>
wpwrak, are you trying to strengthen the mechanical stability between top and bottom case or given an option of arduino shield-alike?
<wpwrak>
the latter. it's not connected to the case. it's just a companion for J21
<cladamw>
wolfspraul, when you said a "daughterboard", did you mean that JTAG/Serial daughter board or the one can plug into this new idea of "U"-shaped?
<wpwrak>
use case: you want to make a small DIY board, say, with some adapter or a small circuit
<wpwrak>
(daughterboard) the latter
<wolfspraul>
no definitely I don't mean the jtag-serial daughterboard
<wolfspraul>
I mean the expansion header
<cladamw>
i see now. phew~ sorry
<wolfspraul>
bbiab
<cladamw>
the idea of "U"-shaped should be placed as close as one of four corner as possible, otherwise if one can bend pcb when he plug a daughter board.
<wpwrak>
good point. or we could add a space in the main pcb near the connector. or at least provide a hole for such a spacer, so that people who need this can add one
<cladamw>
the J21 now is close to fpga,
<cladamw>
but i think we could arrange audio rounte a bit
<cladamw>
the J21 moves to MIC a bit and Jnew placed to C23 C25 area then we have this feature.
<wpwrak>
s/space/spacer/
<wpwrak>
yes, sounds good. J21 can't move a lot, because you need a bit of clearance for connector, pcb border, etc. maybe 1-2 mm.
<cladamw>
wpwrak, yes, also good point either a spacer or a hole, otherwise oneday someone will lose his M1 when plug daughter board.
<cladamw>
yes, may just 1-2 mm.
<cladamw>
wpwrak, btw, so you said that we still use 2-rows connector like J21 now, and the other surely is also 2-rows one? or your minds is like arduino? theirs is 1-row only in one side.
cocoadaemon [cocoadaemon!~cocoadaem@2a01:e35:8a99:e90:20d:93ff:fe3b:868c] has joined #milkymist
<cladamw>
the more the better I read your minds now. :-) so it's 2-rows(the same).
<wpwrak>
yes, 2 rows. i also wouldn't change the pin assignment on J21, so that we can be compatible
<cladamw>
wpwrak, I'll add them into sch. We need 3.3V/GND/other un-used fpga pins, do you think that we need 5V?
<wpwrak>
that's mainly of interest for people like us, who have some "old" M1s ;-)
<cladamw>
i see.
<cladamw>
think about if need 5V?
<wpwrak>
(5 V) hmm, not sure. probably not. if someone really needs 5 V, they can get it from J21 anyway
<cladamw>
even J21 now has two 5V already.
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
<cladamw>
hmm...so another Jnew: another two GNDs and all others are un-used fpga pins. How do you think?
<wpwrak>
maybe also put 3.3 V there
<wpwrak>
the rest sounds good
<wpwrak>
oh, and regarding USB, need to check if our DC input path is good to handle at least continuous ~ 3 A. (1 A for the M1, 4 x 500 mA for USB)
<wpwrak>
most HID and USB-MIDI devices consume far less, but better safe than sorry
<cladamw>
yup...this is must. btw, we can do this after i go to house and to see the placement then we can discuss then.
<sb0>
I guess this will cause issues with the polyswitch fuse, and the zeners which should trip it when the polarity is reversed ...
<wpwrak>
sb0: a "make valgrind" after the last set of patches may be interesting. i'm still not sure what causes all the parser weirdness on your side. it almost seems as if your lemon created parsers that are quite different from the ones mine makes.
<sb0>
or worse, during an overvoltage - because in this case, the zeners dissipate
<cladamw>
if we sure that we go for this, then we need to ask DC adapter vendor to provide 1-2 samples to try.
<wpwrak>
sb0: you mean that the fuse needs to get bigger and then the zeners need to grow too, to still trip the fuse ?
<sb0>
yes
<sb0>
quite messy
<wpwrak>
;-)
<cladamw>
wpwrak, if we sure go for 4 x usb, then we need to do experiment about fuse/zener again. :)
<wpwrak>
maybe for rc5, we can have a local DC-DC frontend. then a lot of problems will disappear :) (and hopefully, not too many new ones will make their appearance)
<cladamw>
this is to decide the trip/hold current of PTC fuse. :)
<sb0>
alternatively, connect the USB ports directly to the power supply, with their own zener and polyswitch
<sb0>
this should alleviate the voltage drop issues, too
<wpwrak>
ah yes, that would be an option. also spreads out the current. i like that idea.
<wpwrak>
yup
<GitHub0>
[flickernoise] sbourdeauducq pushed 3 new commits to master: http://git.io/_iRnxw
<GitHub0>
[flickernoise/master] compiler/compiler.h: include fpvm/fpvm.h for FPVM_MAXSYMLEN - Werner Almesberger
<GitHub0>
[flickernoise/master] compiler: added sanity checks for scanner - Werner Almesberger
<GitHub0>
[flickernoise/master] parser_helper.c: provide valid context with EOF; cleanup - Werner Almesberger
<wpwrak>
btw, would you expect anything nasty to happen if we increase FPVM_MAXERRLEN ?
<GitHub150>
[milkymist/master] milkymist: declare "code" argument of pfpu_dump "const" - Werner Almesberger
<sb0>
the only problem will be that long messages will not fit anymore in the status bar of the patch editor
<wpwrak>
that may be a good idea. i feel a bit sorry for you each time i send off one of these patch collections :)
<sb0>
ok, do you have a github account?
<wpwrak>
yes, the status bar is a bit of a problem. we could perhaps make things a bit more structured there, and let the editor simply jump to the error location, reducing the amount of information to display as text
<wpwrak>
not yet. creating one ...
<wpwrak>
should work now. username: wpwrak
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<sb0>
wpwrak, it is legal to call pixbuf_dec_ref() on a NULL pointer. it just does nothing.
<sb0>
or maybe you just don't want to pull the pixbuf_* functions in the standalone build?
<wpwrak>
yup, that's the main issue
<wpwrak>
i could of course provide my own pixbuf_dec_ref dummy
<sb0>
well... both are ugly. and it's just a small detail...
<wpwrak>
yeah, i wasn't quite sure which of the two would really be the lesser evil in the end :)
<GitHub116>
[flickernoise] sbourdeauducq pushed 13 new commits to master: http://git.io/MuKODw
<GitHub116>
[flickernoise/master] parser.y: use <...> instead of "..." for external includes (by Xiangfu Liu) - Werner Almesberger
<GitHub116>
[flickernoise/master] parser_helper.c: don't leak last "struct id" - Werner Almesberger
<GitHub116>
[flickernoise/master] parser.y: plug various memory leaks in the parser - Werner Almesberger
wolfspra1l [wolfspra1l!~wolfsprau@p5B0ACD1B.dip.t-dialin.net] has joined #milkymist
<wpwrak>
(github additions) thanks a lot !
<sb0>
wpwrak, btw, the tests are passing now
<sb0>
(without valgrind)
<sb0>
trying valgrind now ...
<wpwrak>
funny. the additional freeing should have made things worse if anything :)
<sb0>
passes with valgrind too
<wpwrak>
kewl. how does it look on the M1 then ?
<sb0>
dunno... I'm not at home atm, and my eeepc takes some time to compile rtems ;)
<wpwrak>
aah :)
<wpwrak>
well, let's hope for the best then :)
<wpwrak>
i wouldn't be overly disappointed if that mystery bug just vanished without explanation ;-)
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
<sb0>
grmbl... rtems head breaks FN
<sb0>
thanks to ralf, of course. so this may be difficult ...
<sb0>
ah, and he also broke the DHCP server
<sb0>
s/server/client
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
* sb0
wishes ralf would take care of things like race conditions instead of being anal retentive about coding standards. alas, it takes more effort and it's easier to be wrong...
<lars_>
who is ralf?
<sb0>
one of the RTEMS developers who's always questioning the slightest bit of change or of standard-noncompliance
<sb0>
there was recently a nice ralf-fueled bikeshed thread on the RTEMS ML if you're interested in this sort of things
<sb0>
so, what just happened is ralf declared some non-standard functions that we use static
<sb0>
the problem is it cannot be done otherwise without introducing bugs or duplicating large amounts of code
<sb0>
I'm sure I'll get a flame message telling me this stuff isn't in POSIX and I should not use it
<azonenberg>
the strange thign is, it shows up in the analysis as logic delay and not routing
<azonenberg>
in planahead
<azonenberg>
But in the ISE timing nalysis tool there are a couple of additional LUTs that i dont see in planahead... wtf
<azonenberg>
and in that case it shows up mostly as routing delay... which still leaves me needing to add another FF level to this pipeline in order to make timing
<sb0>
maybe it's a route-thru LUT to enable you to reach the first FF?
<sb0>
though the S6 architecture is supposed to have bypass lines that let you reach directly into half of the slice FFs without going through the LUTs...
<sb0>
note that route-thru LUTs are added by MAP or PAR (can't remember which one) and do not show up in the netlist
<sb0>
you need to use XDL or FPGA Editor to see them. not sure how Planahead handles them, apparently not so nicely maybe ;)
redfire [redfire!~redfire@rny93-3-82-226-84-212.fbx.proxad.net] has joined #milkymist
herve [herve!~herve@ALagny-753-1-74-173.w86-198.abo.wanadoo.fr] has joined #milkymist
<herve>
bonsoir
<sb0>
hi herve
<sb0>
wpwrak, how do you omit per-frame at each equation? does having a line with just 'per-frame' on it make the compiler treat all subsequent equations as per-frame?
<sb0>
or does it have to be 'per_frame=eqn1\n eqn2 ...'?
<sb0>
I prefer the first solution
mumptai [mumptai!~calle@brmn-4d0ad60d.pool.mediaWays.net] has joined #milkymist
<sb0>
wow, Ralf didn't bitch this time. unbelievable :) so I can only swallow my harsh words...
<Fallenou>
nice HDCP man in the middle (overlay on hdmi link) attack using FPGA (spartan 6) at 28c3
sh4rm4 [sh4rm4!~sh4rm@gateway/tor-sasl/sh4rm4] has joined #milkymist
<sb0>
this isn't really an attack, and the HDCP master key is known anyway
<wpwrak>
sb0: yes, per_frame= is "sticky". this causes a minor divergence in semantics, i.e., if you had something like per_frame=foo=bar\nglobal=blah it would now behave as if it was
<wpwrak>
per_frame=foo=bar;global=blah but i guess few people will notice and even fewer will actually depend on such things working ;)
<Fallenou>
sb0: well it's man in the middle, to me it sounds like an attack
<Fallenou>
and indeed master key is known
<Fallenou>
it's just nice that they implemented such a thing (overlay)
<sb0>
well, a legal attack then
<sb0>
a DMCA trolling device
<Fallenou>
yes basically
<wpwrak>
sb0: the new parser doesn't care about whether assignment and per_frame= are on the same line. \n has basically become just another space now
<wpwrak>
sb0: i was thinking of maybe making per_frame= and such act exactly like they did before, and then introducing a per_frame: that would act like a switch. not sure if it's worth the effort, though
<wpwrak>
sb0: even as a 100% alias of per_frame=, the per_frame: syntax may be useful, though, just to set it apart from assignments
<sb0>
hmm... imo the 'switch' is clearer, too
<sb0>
yes
<Fallenou>
(off topic) if someone can tell me why I don't see the same thing in gtkwave and in vvp simulator it would make my headache stop : http://pastebin.com/KDi11THZ :)
<Fallenou>
about the devices_do_ack[] wire
<Fallenou>
-wire/bus
<lars_>
race in your memory controller? bug in vpp? i guess it could be pretty much anything
<Fallenou>
weird thing is that the gtkwave file is generated by vvp
<Fallenou>
I find it strange that vvp $displays() something different than what gtkwave does
<lars_>
one way to track down the problem would be to try another waveform viewer and another simulator
<lars_>
cause right now you don't really know whether it is a problem with gtkwave or vvp
<Fallenou>
OK I just added a $monitor("devices_do_ack == %b at %0d", devices_do_ack, $time); as second statement of initial block