Topic for #milkymist is now Milkymist One, Milkymist SoC & Flickernoise development channel (LLHDL/Antares are welcome too) :: Logs: http://en.qi-hardware.com/mmlogs :: JFDI
<wpwrak>
lekernel: just confirmed clock compression / glitches
<wpwrak>
now trying the deglitcher
aw joined #milkymist
aw_ joined #milkymist
wpwrak joined #milkymist
* wpwrak
hates it when X11 and Flash plot against him :-(
xiangfu joined #milkymist
wolfspraul joined #milkymist
rejon joined #milkymist
wolfspraul joined #milkymist
<kristianpaul>
lekernel: about composite inputs
<kristianpaul>
if i undertood u correcly, i cant mix then because a hardware (ADC) limitation?
<kristianpaul>
what force me just to swtich inputs, but not even consider multiplex?
<kristianpaul>
too slow response for that perhaps?
<kristianpaul>
cause my first impresion was, "oh,milkymist is too advance to just mix video wich is so silly"
<kristianpaul>
but i want to clarify,not for me just because i was asked again that
<kristianpaul>
"can i mix video with that M1 thing"
whitequark joined #milkymist
<wpwrak>
grmbl. unearthing something like dpll_ce is outright vicious. system -> usb -> sie -> phy -> rx
<whitequark>
huh. press left button to upgrade?
<whitequark>
are there only two? :D
<wpwrak>
three, which led to major complaints from the binary people :)
togi joined #milkymist
aw joined #milkymist
aw_ joined #milkymist
xiangfu joined #milkymist
wolfspraul joined #milkymist
lekernel joined #milkymist
mumptai joined #milkymist
Martoni joined #milkymist
wolfspraul joined #milkymist
wolfspraul joined #milkymist
Martoni joined #milkymist
whitequark joined #milkymist
r33p joined #milkymist
<lekernel>
wpwrak: btw, dpll_ce is a synchronous clock enable, which means that the data is actually sampled at the rising edge of the 48MHz clock where it is high
<lekernel>
and that rising edge also brings dpll_ce low, so the data is approximately sampled on the *falling* edge of dpll_ce
<lekernel>
also, the data is delayed 2 cycles by the synchronizer in _filter.v, so be careful when examining dpll_ce and the USB signals directly
<wpwrak>
(delay) also with the original filter ?
<wpwrak>
(dpll_ce) yes, i saw that it doesn't act as a clock. the double period is for real, though. i see two of them each time rx_pending is two bits fast, one for one, zero for zero
<wpwrak>
way too consistent to be coincidence :)
<lekernel>
yes... with the glitch filter it's 4 cycles
<lekernel>
hmm... maybe my DPLL design is too simplistic
<kristianpaul>
morning
<wolfspraul>
good morning!
Thihi joined #milkymist
<wpwrak>
the DPLL is indeed a bit simple .. it's more a pacemaker than a real PLL
<lekernel>
new DPLL synthesizing ...
<GitHub173>
[milkymist] sbourdeauducq pushed 1 new commit to master: http://git.io/C5tibA
<GitHub173>
[milkymist/master] Fix assignment to bus_errors_en - Sebastien Bourdeauducq
<lekernel>
still obstinately refuses to work. grmbl.
<wpwrak>
it's happy when it can get your attention :)
<lekernel>
in simulation, the new DPLL tolerates a 5% discrepancy, both ways, between TX and RX clocks
<lekernel>
USB specifies 0.25%, but no no no no no no no! still won't work!
<lekernel>
(on the 0xd2 character, that is. of course, longer periods without transitions can cause more problems)
<lekernel>
0x2d
<GitHub180>
[milkymist] sbourdeauducq pushed 1 new commit to master: http://git.io/p3e4fw
<GitHub180>
[milkymist/master] softusb: new DPLL - Sebastien Bourdeauducq
<lekernel>
wpwrak: can you check if you still have the "double pulse" problem? it should have been fixed now, even if the rest is still being ultrapesky
<lekernel>
it didn't seem to cause regressions with my low speed devices (including the M1 keyboard) so I committed it
Alarm_ joined #milkymist
<lars_>
mwalle: maybe its just a bug in my bitstream
<Alarm_>
I just turn on the m1 kit. I have a problem with my optical mouse, the resolution is not good
lekernel joined #milkymist
<wpwrak>
Alarm_: does it move normally, just slowly ?
<wpwrak>
lekernel: lemme try to merge that with my instrumentation ...
<Alarm_>
wpwrak: it's hard to point to the buttons. The mouse makes small jumps
<wpwrak>
the bad thing about long synthesis is that you start doing something else and then are quite confused about what you've been synthesizing and why :-(
<kristianpaul>
he yes
<kristianpaul>
actually i record a log, most when i have to try 4 different setups and have to wait like on morning..
<kristianpaul>
afaik stuff cant be simulated because need scope measurement etc..
<kristianpaul>
s/on/one
<Artyom>
Kristianpaul: today I'm fighting with flash. I try to use xilinx example program to program flash. And I've noticed strange behavior. The bytes in a word are swept. Have you heard about it? And I can't write to flash from BIOS only read...
<kristianpaul>
oh yes, i think you require some procedure to write flash from bios
<kristianpaul>
let me find right doc
<kristianpaul>
actually i never havent tried that from bios :-)
<kristianpaul>
i use urjtag instead,but let me see
<lekernel>
wpwrak: why do you need to test rx_active before testing rx_pending?
<kristianpaul>
ah lekernel is here may be he can tell us how to write NOR from bios :-)
<lekernel>
the intended purpose of rx_active is to check whether we are at the last byte of the packet or not (i.e. after some rx_pending has been seen)
<lekernel>
kristianpaul: there's no support for it
<lekernel>
use the M1 JTAG cable. if you do not have a M1, buy one.
<Artyom>
ok... Now I now that I can't just write data in flash like in sram :)
<lekernel>
no, you can't... see the flash chip's datasheet
<wpwrak>
lekernel: hmm, but then we still have a race: what if the Navre is fast enough to detect rx_pending, read the byte, then check rx_active ?
<kristianpaul>
Artyom: why you need flash? or just learning ?
<lekernel>
wpwrak: then it would have correctly read a one-byte packet, no?
<kristianpaul>
in my early steps i used to store sampling from the SiGE, but 32Mb are not really that BIG..
<kristianpaul>
may be you have more :)
<wpwrak>
yes, ... the scenario above was missing the last step: , ... and then EOP is seen
<wpwrak>
so it would find rx_active still on after reading the byte, and thus wait for another one (and eventually time out)
<Artyom>
Kristianpaul: Experimenting with every core. And in flash I can write bigger BIOS (not only 16 kB or a little more). You are reading my ideas. I have some plans for far future to use multibit ADC. And the easiest way to store data is to use SDRAM.
<lekernel>
but it keeps testing for rx_active while waiting for the next byte, no?
<lekernel>
so what would happen is that rx_pending doesn't get asserted again, but rx_active deasserts and signals the end of the packet
<lekernel>
no?
<wpwrak>
wait, you can't have it both ways :) either you only test rx_active after clearing rx_pending, then you don't get the race from my mail but the one described above
<wpwrak>
or you test both in the loop, and then you get the race from the mail
<lekernel>
well, the correct way to do it is:
<lekernel>
1. wait for rx_pending (with timeout)
<lekernel>
2. read one byte
<lekernel>
3. wait for either another rx_pending (and read remaining bytes) or deassertion of rx_active (end of packet)
<wpwrak>
Artyom: you should indeed try to get a M1 :) maybe wolfspraul has some discounted unit he could offer you ?
<lekernel>
I think my original code did that, unless I made some stupid mistake
<wpwrak>
but step 3 has the race from the mail
<wpwrak>
what should work, though, would be:
<lekernel>
mh?
<lekernel>
I don't get it
<wpwrak>
1) wait for rx_pending or timeout
<wpwrak>
2) if rx_pending, read one byte
<wpwrak>
3) in both cases, check rx_active and exit if clear
<wpwrak>
4) if it was a timeout, fail too
<kristianpaul>
may be yafs2 from lekernel can be inked to bios ?
<wpwrak>
5) else, loop back for more
<kristianpaul>
yaffs2*
<wpwrak>
lekernel: (race) the problem is that you're testing in the same loop for rx_pending to rise and rx_active to drop, expecting to catch them in sequence
<lekernel>
ah, i see
<wpwrak>
but if they do this faster than you can poll AND you're in the wrong spot in the cycle, this doesn't work
<lekernel>
indeed...
<lekernel>
but your proposed code always takes the time of the full timeout to complete, no?
<lekernel>
on the last byte... when rx_pending never gets asserted
<wpwrak>
it could, if you're fast
<wpwrak>
right now, you're always too slow. by about 100 ns
<wpwrak>
err no, 200 ns even
<kristianpaul>
but but is rtems specifc..
<kristianpaul>
oh well
<lekernel>
wpwrak: hmm... would an atomic read of {rx_pending, rx_active} help?
<wpwrak>
probably, yes
<lekernel>
ok
<wpwrak>
(200 ns) actually, it's about 150 ns. i don't see rx_pending drop less than 150 ns after rx_active dropping
<wpwrak>
but i guess code changes could bring us into the critical region
<lekernel>
well you can remove register 6'h0b
<lekernel>
and have 6'h0a: io_do <= {rx_pending, rx_active};
<lekernel>
then rx_active is 0x01 and rx_pending 0x02 in the bitmask
77CAA2ALN joined #milkymist
<77CAA2ALN>
Hello . . .
<lekernel>
note that 6'h0a reads also clear rx_pending
<lekernel>
hi Technicus
<Technicus>
What is going on here?
<Technicus>
lekernel: :)
<lekernel>
Technicus: this is the milkymist channel, see www.milkymist.org
<lekernel>
currently it's pretty heavy USB debugging
sh4rm4 joined #milkymist
<wpwrak>
does 6'h0a really clear pending ? i think it just reads it, no ?
<wpwrak>
maybe you mean 09
<lekernel>
ah yes, 09 sorry
<lekernel>
and you can have 6'h0b: io_do <= 8'hxx;
<wpwrak>
can i also just stop the clock of navre until something happens ? :)
<wpwrak>
or, rather, block the read
<lekernel>
no
<wpwrak>
pity
<lekernel>
well, in fact yes, but not easily
<lekernel>
and how would you handle the timeout?
<wpwrak>
in verilog :)
<lekernel>
why?
<wpwrak>
move work to the hardware, where it wants to be anyway
<lekernel>
never do anything in hardware that can be done in software
mumptai joined #milkymist
<wpwrak>
yeah, but these things aren't so nice in software, as we can see. it worked well for low-speed because you have plenty of time. but full-speed is hard.
<lekernel>
it isn't so nice in verilog either
<wpwrak>
if it was too easy, that would be bad, too :)
<lekernel>
with this atomic read change applied, I don't see how blocking in hardware would improve things
<wpwrak>
blocking in hw would still give you better timing
<wpwrak>
but anyway, i think we can drag this to the point where it works properly without crc
<lekernel>
and then the timeout would be inflexible, and the whole thing would use resources and potentially cause timing closure problems (ok, maybe not at 48MHz, but reduces the possibility of running at 72)
<wpwrak>
i suspect that the time budget is to tight for squeezing in a software-based crc as well
<lekernel>
then hardware CRC is justified
<wpwrak>
aye. still need to provide the evidence, though. now that i can see rx_pending, that shouldn't be too hard :)
<wpwrak>
but first i want to kill as many of the little problems that happen even without crc
<kristianpaul>
:-)
<wpwrak>
it's already much better. now the main trouble seems to be RX timeout.
<wpwrak>
without rx_active | rx_pending, it happens at about 0.16 Hz. with that tentative change, it happens at about 0.46 Hz. but that may be purely collateral
<Alarm_>
With the command jtag I''ve an error:jtag bathfile
<Alarm_>
jtag: error while loading shared libraries: liburjtag.so.0: cannot open shared object file: No such file or directory
<wpwrak>
we'll see. now i have to prepare my trip to customs, to liberate my LV3 :)
<lekernel>
good luck!
<lekernel>
Alarm_: add /usr/local/lib to /etc/ld.so.conf and run ldconfig
<lekernel>
assuming you installed urjtag in /usr/local, which is the default ...
<Technicus>
What hardware is optimum to operate the software designed for Milkymist on other platforms?
<lekernel>
Technicus: the M1
<lekernel>
:)
<kristianpaul>
Technicus: you meant milkdrop right?
<Technicus>
kristianpaul: I am not completely educated about what software is controling the Milkymist . . .
<Technicus>
I already have a descent computer, and I would like to get a Milkymist box but it stretches the limits of my budget, however if there is any hardware that I can put in my machine for less of an expense I would prefer that.
<Technicus>
Basically need a quality video card, video capture card, and midi interface . . . that is about it right?
<Technicus>
Most of the magic is all in the software isn't it?
<kristianpaul>
i think current laptops can run projectm
<Technicus>
* not all
<kristianpaul>
wich implement milkdrop
<kristianpaul>
yeah i afaik i dont know wich..
<kristianpaul>
Technicus: nt all
<kristianpaul>
well it depends of the poitn of view for this magic
<Technicus>
Well, I am considering add in cards for a desktop.
<Technicus>
It is obvious that the Milkymist hardware is excellant equipment.
<Technicus>
. . . and honestly not too expensive, but beyond the limits of my budget.
<Technicus>
If possible to do the same for less with my desktop, then I must go that route.
<kristianpaul>
the problem is make ir work, of course you are *free* to get alternatives
<kristianpaul>
but consider the turkey solution a bit
<kristianpaul>
turnkey*
<Technicus>
Yeah that is freaking sweet, and worth the price.
<Technicus>
I am familiar with ProjectM, but what is implemented to mix in live video?
<kristianpaul>
dont think so :-)
<kristianpaul>
ok time to lunch, read you later
<kristianpaul>
afaik M1 dont mixvideo
<kristianpaul>
may lekernel want to qoute more why not? iftenically not posible never or justmissing feature?
* kristianpaul
away
<lekernel>
Technicus: nothing, that's what the M1 is good at. :-) as in "mix video into the patch/preset", not "mix two external video sources together"
<Technicus>
lekernel: Is that what Flickernoise does?
<lekernel>
yes
<Technicus>
lekernel: It sort of reminds me of JACK.
<Technicus>
Is only designed to run on the Milkymist hardware?
<kristianpaul>
Technicus: milkymist is not a PC, so yes it is
<kristianpaul>
could be ported surelly but you need more work
<Technicus>
I am starting to get the picture, thanks.
<kristianpaul>
milkymist hardware is specialiced to get those effects run smoth and almost out of the box
lekernel_ joined #milkymist
antgreen joined #milkymist
azonenberg joined #milkymist
ab5tract joined #milkymist
r33p joined #milkymist
<mwalle>
lars_: mh?
<wpwrak>
back from customs. only 1.5 hours wait there. not bad. and because it was at the end of the day, they just wanted people to leave and didn't even ask for money ;-)
<lekernel>
Fallenou: because git-cvs is either buggy or difficult to use. in both cases, it was wasting my time.
<lekernel>
the zlib compilation problem, for example, originated from git-cvs not importing some cvs commits for some reason
<Fallenou>
oh ok
<Fallenou>
so maybe just put in place a http/ftp place to put patches like a staging area
<lekernel>
wpwrak did it
<Fallenou>
oh nice ok :)
<lekernel>
using quilt
<Fallenou>
oh don't know quilt
<Fallenou>
gn
<mwalle>
btw there is guilt, too ;)
<GitHub26>
[flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/nlJ2tA
<GitHub26>
[flickernoise/master] Image support - Sebastien Bourdeauducq
<wpwrak>
mwalle: sounds interesting :) maybe that also gets rid of the need to add files before changing them, which is an endless source of nuisance in quilt
<mwalle>
wpwrak: you have to get used to quilt edit :)
<wpwrak>
i sometimes remember, yes ...
wolfspraul joined #milkymist
<wpwrak>
.. and at other times, i just conclude that throwing it all away and starting over is quicker and safer than trying to unravel the mess i've created
lekernel joined #milkymist
<GitHub186>
[flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/3j5D8Q
<GitHub186>
[flickernoise/master] Images working - Sebastien Bourdeauducq
<wpwrak>
how are images used in a patch ?
<GitHub136>
[flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/Hqrj0w
<GitHub136>
[flickernoise/master] images: fix aspect ratio - Sebastien Bourdeauducq