Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
<kristianpaul>
for the new exp system, is posible add a clk signal but if dvi will have it i'm happy with
<kristianpaul>
i dont like borrow clk from the memcard slot, may be not using it (memcard) but i still the chance to make Fatfs work on it someday ;)
<wpwrak>
kristianpaul: suggest it on the list ?
<kristianpaul>
oh moment just arriving..
<kristianpaul>
catching mails..
<kristianpaul>
oops i cc joerg and wonder who else..
<kristianpaul>
tought the thread was more about J3 xD
<wpwrak>
that'll be another 50-100 years in purgatory
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<wpwrak>
cladamw: the chat with joerg was quite productive :)
<cladamw>
wpwrak, he. morning ! yes , i just finished reading the email. :)
<cladamw>
yes, some dc block cap. we didn't follow wolfson's datasheet suggestions and kept lm4550b's design. ;-)
<cladamw>
wpwrak, "Also rename HP OUT to something that doesn't
<cladamw>
suggest a strong amplifier. Maybe LINE OUT ?", what's this meaning?
<cladamw>
wpwrak, "Jx and Jy would be unpopulated footprints for 1x3 100 mil (2.54 mm) headers.", Does the word of "unpopulated" is we usually talked as "DNP"?
<cladamw>
wpwrak, above are the problems of my english comprehensive ability. Help me to clarify, tks. :)
<cladamw>
kristianpaul, hi, about the clk you used now, which clk you are pulled out for purpose ?
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
<kristianpaul>
cladamw: the one from memcard
<kristianpaul>
LOC = A10
<kristianpaul>
mc_clk
<kristianpaul>
s/memcard/memory card
<kristianpaul>
ah, i used the TP :-)
<cladamw>
mmm...i see
<kristianpaul>
TP-19
<kristianpaul>
i needed that extra clock input a lot :)
<kristianpaul>
was the fast way to solve my not very high knowledge to deal with multiple clocks in the same soc.
<kristianpaul>
well i was about to make fifo,but nah too much learning curve again ;)
<wpwrak>
cladamw: (HP OUT) "HP" is for "Headphones". but it seems that the wm9707 doesn't have a headphone amplifier. so we should change the signal name
<wpwrak>
(unpopulated) yes, that's DNP
<cladamw>
kristianpaul, mm... so a header pin of clk would be good for your need.
<cladamw>
wpwrak, okay, tks. maybe we just rename the "HP" to its "LNLVL{_L, _R}".
<cladamw>
"LNLVLOUT{_L, _R}"
<kristianpaul>
well i hope not just for me, and anyone want to add a custom "board" to M1 and provide aditional clock input
<kristianpaul>
i'm OK right now, i just wanted to put my comments... even if are just asking not giving ;)
<wpwrak>
(LNLVLOUT_*) yeah, that would be a possibility. it's very similar to the pin names, though. also, the "LVL" (level) doesn't really seem to add information. but okay, that's a wolfson problem
<wpwrak>
kristianpaul: are those clock outputs only for clocks or can they also be used for other signals ?
<cladamw>
wpwrak, do you think that sd_clk can be wired to new J21?
<wpwrak>
kristianpaul: and how many unused/unconnected clock outputs do we have ?
<wpwrak>
ah, those are *_GCLK*, right ?
<kristianpaul>
(unused/unconnected) well last time i asked here and checked schematics (sorry giveup check layout with altimun) zero
<kristianpaul>
right
<kristianpaul>
i think can be used for other signals as well, let me check..
<cladamw>
kristianpaul, did you modify verilog yourself about that sd_clk pins? or just used it?
<kristianpaul>
modified of course to no used sd_clk for sd related task yes
<wpwrak>
IO_L29P_GCLK3_2 seems available (on U22C)
<kristianpaul>
let see
<kristianpaul>
i have rc2 just in case
<wpwrak>
IO_L31*_GCLK3*_D1*_2 seems a little wasted for FLASH_D1* too. but i guess that's hardwired for booting ?
<kristianpaul>
seems = populated/routed ?
<kristianpaul>
waste yes, i noticed that to time ago..
<wpwrak>
it's unconnected in rc3
<kristianpaul>
and for our loved EDK owners? :-)
<wpwrak>
U22B has a few more: GCLK10 and 11
<kristianpaul>
HE ver yes !
<kristianpaul>
waste!
<kristianpaul>
s/HE/HW
<kristianpaul>
argh, i remenber that..
<wpwrak>
so, seems that we could have at least three clocks
<kristianpaul>
ah moment, on my rc2 dataheet IO_LP29_GCLK3 nor routed it seems
<kristianpaul>
but L29N GCLK2 do
<cladamw>
wpwrak, so can we just list up these requirements firstly on two J21s then determine which should be the rests?
<kristianpaul>
nope sr wpwrak , in my rc2 sch IO_40P_GLCK11 not routed it seems
<wpwrak>
(LN29N) yes. HW_VER_3. i think we can get rid of that ;-)
<kristianpaul>
neither IO_L40N_GCLK10
<wpwrak>
excellent
<kristianpaul>
or i'm confusing signals?
<kristianpaul>
wpwrak: can you confirm what i said for rc2?
<kristianpaul>
i think we're in same page...
<kristianpaul>
let me see rc3 sch
<wpwrak>
i have no idea about rc2. but all these signals look available on rc3. and given that rc3 is the basis for rc4 ... ;-)
<kristianpaul>
!!!! :)
<kristianpaul>
but wait you agree GCLK10 is IO_L40N_GCLK10 ?
<kristianpaul>
in rc3
<kristianpaul>
U22B
<kristianpaul>
cause i still dont see where is in routed to/for
<kristianpaul>
sorry,
<wpwrak>
it's probably not routed
<wpwrak>
it's not routed on rc3
<wpwrak>
what i'm talking about are currently unrouted clocks. i.e., clocks we can bring to the new J21 companion in rc4
<kristianpaul>
ahhh !!!
<kristianpaul>
i tought we're talking about routed gclk ;)
<kristianpaul>
ok
<kristianpaul>
i can rest now
<kristianpaul>
:)
<kristianpaul>
and try to setup this bluetooth kbd :S
<kristianpaul>
route yes :)
<kristianpaul>
wpwrak: had you seen the m1 rc3 layout?
<wpwrak>
well, the pretty-printed version. didn't look much at the gerbers beyond that
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
proppy [proppy!u1692@gateway/web/irccloud.com/x-zqvlggjvbhjhzgvi] has joined #milkymist
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
proppy [proppy!u1692@gateway/web/irccloud.com/x-cdqqufupcjamsyqs] has joined #milkymist
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<GitHub64>
[milkymist/symtab] libfpvm: only access node->label if we have an indentifier - Werner Almesberger
<GitHub64>
[milkymist/symtab] libfpvm: introduce "struct sym" as abstraction for an identifier - Werner Almesberger
<GitHub64>
[milkymist/symtab] libfpvm: rename "struct sym" to "struct fpvm_sym" - Werner Almesberger
<GitHub26>
[flickernoise] wpwrak created symtab (+13 new commits): http://git.io/xYjlcA
<GitHub26>
[flickernoise/symtab] compiler: define op_not such that we don't trigger a warning - Werner Almesberger
<GitHub26>
[flickernoise/symtab] compiler: track reduction of "label" use in libfpvm - Werner Almesberger
<GitHub26>
[flickernoise/symtab] compiler: don't predefine identifiers for function names - Werner Almesberger
<wolfspraul>
wpwrak: so it looks like we have the perfect solution for J3?
<wolfspraul>
cladamw: did you see all of this? is it clear?
<cladamw>
regarding to zener diode, need to find real p/n later. else are clear.
<cladamw>
and also regarding to if add clk pins on new J21, seems kristianpaul and wpwrak talked a lot. so will also ask wpwrak later.
<wolfspraul>
yes, I wanted to ask about that to
<wolfspraul>
too
<wolfspraul>
ok good
<wolfspraul>
cladamw: but I think whatever outcome of the clock discussion, that's unrelated to J3
<wolfspraul>
so you can 100% finish J3 now, I think
<wolfspraul>
true?
<cladamw>
yes, i'll draw firstly
<cladamw>
to draw for J3
<wolfspraul>
good. so we first finish J3, then onto J21
<cladamw>
yeah
<wolfspraul>
(and we find out about kpaul's clock thing as well)
Martoni [Martoni!~chatzilla@ip-167-165.evhr.net] has joined #milkymist
mumptai [mumptai!~calle@brmn-4d0ac2c1.pool.mediaWays.net] has joined #milkymist
cocoadaemon [cocoadaemon!~cocoadaem@2a01:e35:8a99:e90:20d:93ff:fe3b:868c] has joined #milkymist
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
sh4rm4 [sh4rm4!~sh4rm@gateway/tor-sasl/sh4rm4] has joined #milkymist
lekernel [lekernel!~lekernel@g225039004.adsl.alicedsl.de] has joined #milkymist
lekernel [lekernel!~lekernel@g225039004.adsl.alicedsl.de] has joined #milkymist
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
wolfspra1l [wolfspra1l!~wolfsprau@p5B0ADC9C.dip.t-dialin.net] has joined #milkymist
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
<wpwrak>
cladamw: yes ;-)
<wpwrak>
cladamw: i don't think we need to keep footprints for l3, l19. just connect the ground directly
<wpwrak>
cladamw: note that the recommended point for connecting the grounds is across the chip (at least in one case. don't remember whether it was video or audio)
<wpwrak>
cladamw: so the link between the split ground planes should be under the codecs, making sure they have as small a voltage difference between grounds as possible
<cladamw>
wpwrak, yes, i deleted them in sch, then i am thinking that just using directly wire to short those two ground systems(digital&analog) to keep same results as rc3 patch now.
<wpwrak>
cladamw: and l3/l19 disappear for good
<wpwrak>
cladamw: the rc3 solution is sub-optimal. it works, but it could be better. and if you do it properly, there's no place for L3/L19 footprints anyway. problem solved ;-)
<wpwrak>
(properly = connect the ground planes under the chip)
<cladamw>
Connecting the ground planes under decoder may do or maybe not, I'll try to let house do that. since rc3 already pretty works well, if house guy think they will move too much works, then I'll just let them to 'wire' those splitted planes.
<wpwrak>
they should do it cleanly, even if it means 10 seconds more work :)
<wpwrak>
let me put it this way: if connecting the ground planes correctly is difficult for some reason, we probably have a problem elsewhere :)
<cladamw>
wpwrak, ;-)
<wpwrak>
just think of all the generation of poor young engineers who will look at our design, trying to learn from the wisdom of great master adam. they will not understand but honor the example. and in half a century, the world will perish because some black hole containment device at CERN will fail due to an improperly handled surge. because they used a "wire", like great master adam did, instead of connecting split ground planes under the chi
<wpwrak>
p. there will be a lot of angry spirits in the afterlife after that. do you want to risk that ? :-)
<cladamw>
haha...the rules now is always to follow recommended datasheet which needs senior doctor werner to discover its backend stories. ;-)
<wpwrak>
heh, the thing is actually easy to understand. the only surprising bit is the magnitude of the effect. but well, now we know :)
<cladamw>
wpwrak, the current L19 is too far away from decode, according to figure 41, so yes,
<wolfspra1l>
cladamw: try to cleanup L3/L19 properly
<wolfspra1l>
that means move under the chip etc.
<cladamw>
let's move that 'bridge' under chip, current those two planes are splitted very well; so move 'bridge' to there.
<wolfspra1l>
I am not afraid of taking some risks, and rc4 will have a lot of things so if we are afraid of something like that - it feels wrong
<cladamw>
haha... I am not afraid of somethings, you know Taiwanese engineers, to work with them are not always easy like working with western guys. well... so the problems now is on my site.
<cladamw>
you've seen much styles of taiwanese. ;-)
<wolfspra1l>
cladamw: do I understand this correct that you are now editing the rc4 schematics in Altium?
<wpwrak>
where else ? :)
<cladamw>
wolfspra1l, yes...editing rc4 in AD. but meanwhile I'm making notes more for further layout instructions while editing sch.
<wolfspra1l>
ah ok
<wolfspra1l>
nice
<wolfspra1l>
I was *overwhelmed* by how much feedback we seem to have gotten around the elimination/reduction of J3 in just a day ;-)
<wolfspra1l>
buried well, to be resurrected whenever... NICE!
<wolfspra1l>
that was a far better outcome than I would have expected
<wpwrak>
touching audio is always like opening a can of worms from pandora's superstore ;-)
<wolfspra1l>
so are we ready to take on J21 now?
<wolfspra1l>
the new 'U-shape' etc
<wolfspra1l>
or still wait a little until things settle?
<wpwrak>
we have one bit for J21 already: those clock signals. i wonder if there are any other "magic" pins on the fpga ?
<wolfspra1l>
about compatibility, if we switch the header from male to female, is there any hope for pre-rc4 owners?
* wpwrak
looks questioningly in the general direction of lekernel
<wolfspra1l>
I asked yesterday already - are there some types of female-female adapters that one can plug onto a male one to convert it to a female one?
<wolfspra1l>
if so, that would at least be a hackish workaround for pre-rc4 boards, if the future expansion boards don't electrically utilize the 2nd header we are adding
<wolfspra1l>
or they could just swap the male header to a female one, maybe? I mean on the board...
<wpwrak>
wolfspra1l: they have a number of options: 1) brute force - just make an adapter. 2) make a board variant for rc2/rc3, populated with a female connector instead of the cheaper male. 3) since they may be using a cable anyway (remember, only with rc4, you get proper mechanical stability), have an rc2/rc3 cable variant
<wpwrak>
wolfspra1l: ah yes, 4) unsolder J21 (yuck) and put something female there
<wolfspra1l>
are there female-female adapter pieces?
<wolfspra1l>
if we totally break compatibility, we may also change the pins on J21
<wolfspra1l>
although I am not sure whether such freedom would be welcome or not, maybe we will just waste time stirring the pot, without creating value
wolfspraul [wolfspraul!~wolfsprau@p5B0ADC9C.dip.t-dialin.net] has joined #milkymist
<wpwrak>
... searching ...
<wpwrak>
perhaps not
<wpwrak>
but you could make your own. either by soldering receptacles together or with a PCB
<wpwrak>
so, 5) design for rc4+ and make an adapter board for all the of rc2/rc3 customers
<wpwrak>
if we go on like this, we'll soon have more work-arounds than rc2/rc3 owners ;-)
cocoadaemon [cocoadaemon!~cocoadaem@2a01:e35:8a99:e90:20d:93ff:fe3b:868c] has joined #milkymist
<wpwrak>
maybe a bit too short for a good connection. but then, you could also use it as a building block for an low-profile adapter
<wpwrak>
millions of possibilities. no need to worry
<wolfspraul>
ok
<wpwrak>
the most likely outcome is that any "serious" board will require the U anyway, which rc2/rc3 can't do
<wpwrak>
and ad hoc connections (like the usb switch control adam has made for pre-rc4) don't care whether it's male or female
<wolfspraul>
alright then. I just hope we have a long-term expansion system from rc4 on
<wolfspraul>
although I have no illusion that the perfect 'expansion' system cannot exist, because one cannot prepare for the unknown...
<wpwrak>
so do we all. like PCI or more long-lived and more popular ;-)
<wpwrak>
(prepare for the unknown) those who fear change must be quite angry at their ancestors who crawled out of the safety of the primordial mud
<wolfspraul>
I just see them crawling out of primordial mud holding a female expansion header
<wpwrak>
yeah. and then they moved right on to building the pyramids using neutrino beam cutters and antigravity. alas, all that was lost when atlantis drowned.
<lekernel>
wpwrak: there are many restrictions on what FPGA pins can drive what. clock signals with a low and predictable skew dedicated route to the global buffers are just one example.
<lekernel>
but as I told kristianpaul at least 4 times already it's perfectly fine to send any clock through the general purpose routing when there are no tight timing constraints involving that clock and other I/Os
<wpwrak>
clocks seem to be fairly crucial. are there others of similar importance ?
<wpwrak>
(clock on gp) heh :)
<lekernel>
dedicated clock pins are crucial only when such a tightly timed interface exists... which isn't the case today afaik
<wpwrak>
being able to have precise clocks seems to be useful in general. you can never be too precise :) (of course, you can over-obsess ...)
<lekernel>
another area is differential pairs - you can only have differential I/Os on contiguous pins
<lekernel>
then there are length matching and impedance concerns
<wpwrak>
so we should try to have pairs instead of random picks. let's see how we're doing this far ...
<lekernel>
it never ends, so I'm blissfully ignoring those issues unless there's an actual need for this
<lekernel>
but so far this expansion connector has been carefully ignored by most people
<wpwrak>
for now, we're perfect :)
<wpwrak>
not by some who are among those who have the most effect on future M1 development :)
<wpwrak>
e.g., adam put it to good use for the usb switch
<lekernel>
yes, but you don't need global clock buffer capable I/Os for this ...
<wpwrak>
just because we didn't care about exact clock so far doesn't mean we won't in the future :) e.g., this could also be used for diagnostics
<lekernel>
any I/O can reach any global clock buffer through the general purpose routing. only, non-dedicated paths have more skew.
<wpwrak>
and hopefully we'll come across some money in one way or another that will allow us to afford the instruments that will actually let us see those small timing differences ...
<wpwrak>
pretending that the world above 10-20 MHz doesn't exist is arduino engineering ;-)
<wpwrak>
i think i just invented a useful term, "arduino engineering" :)
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
<Fallenou>
it deserves a quote somewhere =)
<lekernel>
oh, we do care about timing where it's needed - on the DDR for example. but I see little use so far on the exp connector
<lekernel>
but yeah, go ahead and add some if you wish
<lekernel>
as long as it doesn't introduce signal integrity or EMI regressions
<wpwrak>
EMI ought to be agnostic to whether we use an "exact" pin or a less exact one. dunno about signal integrity. i'd hope internal buffers don't notice non-abusive use of the expansion header. of course, if someone just shorts one end of a differential pair to ground, all bets are off ...
<wpwrak>
are there any other "special" pins you'd think could be useful on the expansion header ? (be it for expansion or just for access. i'd also say expansion is more convenient than TP)
<lekernel>
no, the problem is you may have to move some existing tracks around the PCB to get those extra pins routed, and this might cause SI/EMI regressions
<lekernel>
especially since you are reaching into the higher-density area around the BGA
<wpwrak>
yeah, the easily accessible ones are already wasted on FLASH_D1* :-(
<wpwrak>
well, we have GCLK0 (AB13) that's not too bad
<wpwrak>
the FLASH_D1* assignment is hard-wired by xilinx, isn't it ?
Gurty [Gurty!~princess@mtg95-7-78-233-26-36.fbx.proxad.net] has joined #milkymist
elldekaa [elldekaa!~hyviquel@vpn2.enssat.univ-rennes1.fr] has joined #milkymist
<lekernel>
yes, most flash pins are hardwired for fpga configuration
mumptai [mumptai!~calle@brmn-4d0ac2c1.pool.mediaWays.net] has joined #milkymist
kilae [kilae!~chatzilla@catv-161-018.tbwil.ch] has joined #milkymist
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
lekernel_ [lekernel_!~lekernel@g226059040.adsl.alicedsl.de] has joined #milkymist
r33p [r33p!~rep@bon31-2-89-85-157-97.dsl.sta.abo.bbox.fr] has joined #milkymist
sh[4]rm4 [sh[4]rm4!~sh4rm@gateway/tor-sasl/sh4rm4] has joined #milkymist
<kristianpaul>
lekernel_: (4 times told abput clock), may i bve wrong but i remenber telling you i was going to use that glck ping to replace milkymist soc main clock
<kristianpaul>
so anyway i dont care if J21 will have gclk or not, really, i'm okay with my very custom setup and fpga internal routing ingnorance
<kristianpaul>
so it works for me now from the memory card clk :)
<wolfspraul>
kristianpaul: ahh, wait please :-)
<wolfspraul>
maybe I'm dumb enough to understand it, I certainly would like to try
<wolfspraul>
you need a clock signal, from m1 going to your sige evb?
<wolfspraul>
and you don't have that on J21 right now so you take it from the memcard?
<wolfspraul>
is that correct?
<kristianpaul>
yes
<wolfspraul>
because I have no idea about that clock, can you tell me what kind of clock it is?
<kristianpaul>
fah wait, from sige evb to m1
<wolfspraul>
what frequence? what's the purpose?
<wolfspraul>
frequency
<kristianpaul>
16384Hz
<kristianpaul>
is gps receiver sampling clock
<wolfspraul>
ok, it's a clock going from sige to m1
<kristianpaul>
yes
<wolfspraul>
and you cannot send that signal in over j21. why not?
<kristianpaul>
xst complains about timing, but i could try again and send proper logs
<wolfspraul>
but when you route it in over the memcard - no xst complaints?
<wolfspraul>
which memcard pin exactly actually?
<kristianpaul>
it complains at first, but the i add to contraint file that this is not a dedicated clock signal, then timing works
<wolfspraul>
so that sige clock becomes your main milkymist clock now?
<kristianpaul>
yes
<wolfspraul>
you run the lm32 at 16 mhz?
<kristianpaul>
no
<kristianpaul>
16Mhz x 4 :)
<wolfspraul>
ah ok :-)
<kristianpaul>
and btw the other xst/ise message with J21 was related to some IO2buffer dont remnber well
<wolfspraul>
which memcard pin do you use to send the clock in now?
<kristianpaul>
but my conclusion at that time was that signal could no be routed to a main clock, may be i dont dig enought..
<kristianpaul>
clk pin
<kristianpaul>
TP 19
<wolfspraul>
hmm
<kristianpaul>
mc_clk
<kristianpaul>
is on the datasheet
<wolfspraul>
so those xst warnings you ran into, maybe there would have been ways to address those warnings?
<kristianpaul>
i remeber it said cant do soemthing related to a buffer
<wolfspraul>
ok
<wolfspraul>
well thanks a lot that was very helpful for me, at least :-)
<wolfspraul>
learning
<kristianpaul>
me too ;)
<wolfspraul>
lekernel says it should be 'perfectly fine' to use the general i/o pins for clocks
<kristianpaul>
but even for milkymist main clock=
<kristianpaul>
?
<larsc>
for output clocks i think
<kristianpaul>
when i was using sige clock for a not main milkymist clock _all_ was gine
<kristianpaul>
s/gine/fine
<kristianpaul>
but as i said, i wanted to have an external clock for milkymist soc
<wolfspraul>
fully understood
<kristianpaul>
i wonder if that fine' to use apply as well
<wolfspraul>
well we are adding a second 2*9 connector. we can add such a clock pin there :-)
<kristianpaul>
if you can and dont disturb nothing, will be nice! thanks !
<larsc>
kristianpaul: wolfspraul only quoted half of what lekernel_ said. he said it is fine for clocks with non critical timings
<kristianpaul>
larsc: indeed !!
<wolfspraul>
yes
<wolfspraul>
well I have no idea about disturbing
<wolfspraul>
but I think I understand what you want
<kristianpaul>
larsc: i dint ask for gclk pin before, until i decide not deal with crossing clock domains, and swtiched soc to single clock, was easier solution :)
<wpwrak>
so the question is basically if you could use a non-GCLK pin as a clock source for the (entire) FPGA itself. correct ?
<wpwrak>
a "master clock" does sound like something that's sensitive to accuracy, skew, etc.
<kristianpaul>
corrct wolfspraul
<kristianpaul>
wpwrak:
<wolfspraul>
so what would go against adding such a gclk pin to the second expansion header?
<wolfspraul>
too risky?
<wolfspraul>
only idiots need it? :-)
<wpwrak>
the only reason against is seems to be potential routing complexity
<wpwrak>
about only idiots needing it, atben may not have needed its own crystal if the ben could have provided a "clean" clock signal :)
<wpwrak>
not sure if the fpga can provide such a clean clock, but at least it seems that gclk is one step closer to that than any arbitrary pin
<wpwrak>
besides, if we ever need to debug clocking issues, we'll probably want access to as raw a clock as possible
<wpwrak>
and i'm not even talking about clock input yet :)
<kristianpaul>
:-)
<lekernel_>
kristianpaul: exactly! and that main clock doesn't have timing constraints wrt I/Os, so it's fine to send it through general purpose routing
<lekernel_>
now if you have to run a synchronous interface with some other pins, that's only where the problems arise. though at 16MHz, you're likely to have wide margins...
<lekernel_>
GP routing may produce some slight duty cycle distortion (something I discovered developing the TDC core...) but the DCM will clean that up anyway
<wpwrak>
lekernel_: so general i/os are also suitable for the master clock input (i.e., what then goes to the PLL) ?
<larsc>
hm, maybe a related question. if i have two clocks which are phase synchronized but one is faster than the other, does that reduce the metastability risk when exchanging sinals between the two clock domains?
<larsc>
and do i need synchronization at all in this case?
<wpwrak>
wolfspraul: btw, how are things going on the MIDI front ? :)
<wolfspraul>
ha
<wolfspraul>
stuff is still standing here, but actually lemme try :-)
<wolfspraul>
icreativ first
<wolfspraul>
my m1 froze, oh well
<wolfspraul>
must have happened in last day or so (screen was off, but I kept it running)
<wpwrak>
rc2 has a bad reputation to uphold in that regard :)
<wolfspraul>
first I had to choose between keyboard and mosue
<wolfspraul>
removed the mouse first - bad decision, didn't know how to navigate the menus anymore
<wpwrak>
setting up midi is easy: let's do it for the tornado rain dance rmx: first, go to the midi dialog
<wolfspraul>
now removed keyboard
<wpwrak>
you need the mouse :)
<wolfspraul>
I notice that the midi settings dialog does not fit in 640x480
<wolfspraul>
the icreativ is powered though and m1 running - that's good
<wolfspraul>
powered from m1
<wpwrak>
btw, a convenient little combo keyboard is the "rii mini remote" something like USD 30-100, depending on where you buy
<wpwrak>
okay, tornado rain dance needs eight controls: 1 = X, 2 = Y, 3 = a fader, 4 = a pot/encoder, 5-8 = faders (don't need to be good quality)
<wpwrak>
for 1 and 2, use the X/Y mode. select with button on the right side of the icreativ
<wpwrak>
then click on midi1 and hold down the mouse button
<wpwrak>
then move the finger horizontally
<wpwrak>
i think the value is 12. when you see that, release the mouse button
<wpwrak>
then repeat for midi2, moving vertically
<wpwrak>
midi3, the mechanical fader on the left side of the icreativ
<wpwrak>
midi4, use one of the four encoders
<wpwrak>
midi5-8, select "control", which gives you 8 faders on the pad. then assign four of them
<wpwrak>
important: you have to close the midi window (OK) before the settings become active
<wolfspraul>
do you see anything under "Latest active controller"?
<wolfspraul>
when I click on midi1 and hold the mouse button, I cannot get any "12" to show up
<wpwrak>
yes, the "latest active controller" should change as you use the icreativ
<wolfspraul>
no, nothing there
<wpwrak>
hmm. then usb-midi isn't working
<wolfspraul>
my notebook shows the icreativ
<wolfspraul>
trying lv3 on m1 now
<wpwrak>
lvl3 doesn't work very well because of the odd channel assignment
<wolfspraul>
nothing under 'latest active controller'
<wolfspraul>
btw, I am using the 2011-11-29 image
<wpwrak>
if you have a serial console, you could see if the bios detects the midi controller
<wolfspraul>
is it even working there?
<wolfspraul>
rebooting m1 with lv3 connected
<wpwrak>
29-11 may be a couple of days too old
<wpwrak>
anything made in december is probably okay
<wolfspraul>
Linux doesn't know the names for either the icreativ or lv3 usb vid/pid - weak
<wolfspraul>
I should help updating linux-usb.org, but also lazy now ;-)
<wpwrak>
it will ... :)
<wolfspraul>
so first thing we need a new release, or I have to build from source
<wolfspraul>
or wait, xiangfu is doing daily builds
<wpwrak>
i added my usb zoo to the linux usb database on nov 29. hasn't been accepted yet, though