lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
Hawk777` has joined #milkymist
juliusb has joined #milkymist
hypermodern_ has joined #milkymist
hypermodern_ has left #milkymist [#milkymist]
Hawk777 has quit [Ping timeout: 245 seconds]
juliusb_ has quit [Ping timeout: 245 seconds]
balrog has quit [Ping timeout: 245 seconds]
balrog_ has joined #milkymist
balrog_ is now known as balrog
dvdk has joined #milkymist
bhamilton has joined #milkymist
lekernel has joined #milkymist
<lekernel>
davidc__, yes it does not touch the PLL
<lekernel>
davidc__, and HDMI is in 3.3V bank while SDRAM in a 2.5V one
<lekernel>
maybe the problem is inside the FPGA, I don't know ...
bhamilton has quit [Quit: Leaving.]
bhamilton has joined #milkymist
azonenberg has quit [Read error: Operation timed out]
<lekernel>
wpwrak, I'm using a rc2 board
<lekernel>
shouldn't make a difference, but of course sdram reads shouldn't mess with hdmi either
mumptai has joined #milkymist
<wpwrak>
ah, i see. maybe try in another board, just to make sure it's not some localized weirdness ?
<wpwrak>
(unlikely, but you never know)
mumptai has quit [Ping timeout: 252 seconds]
lekernel has quit [Ping timeout: 245 seconds]
lekernel has joined #milkymist
bhamilton has quit [Read error: Operation timed out]
bhamilton has joined #milkymist
antgreen has quit [Ping timeout: 245 seconds]
<lekernel>
oh, the bug isn't there on rc3
<lekernel>
or rather, much less marked
<lekernel>
at least to the point where I can make demos without apologizing. great.
<lekernel>
wpwrak, thanks for the good idea :)
<lekernel>
if I'm lucky it will work perfectly on the mixxeo, which will have proper differential pairs all the way to the fpga
<lekernel>
I'm still curious though... what the hell can cause something like that
<wpwrak>
(r3) probably depends on the phase of the moon, too ;-)
<lekernel>
would be great to hear what happens on your board
<lekernel>
there's a little rework - cut the high speed traces near the connector on the HDMI add-on, and insert a 24 ohm series resistor on each
<wpwrak>
do i need to feed both HDMI channels ?
<lekernel>
this appears to improves signal integrity - of course can't tell you exactly how much with the scope I have, but it makes ch B able to synchronize and greatly reduces the noise on the pictures
<lekernel>
no
<wpwrak>
does the SI issues affect ch A and ch B in the same way ?
<lekernel>
ch B seems to be more affected, since you can't even sync without the resistors
<lekernel>
you just get a pixel soup of your original picture
<lekernel>
being put in the blender :)
<lekernel>
if you don't want to connect the pots you can change the readout routine
<lekernel>
otherwise the pot connection is TP20 -> charge, TP16 -> blackout, TP17 -> crossfade
<wpwrak>
hmm, no 24 Ohm in 0402. only 18 and 33
<wpwrak>
i have 22 and 27 in 0603, though
<wpwrak>
could stack 2 x 47, though
<wpwrak>
how precise does it have to be ? also, how did you end up with 24 ?
<wpwrak>
a quick look at rc2 vs. rc3 gerbers reveals nothing suspicious. vga traces cross ext conn traces, but you've already eliminated that. besides, there's a ground plane between them.
<wpwrak>
hmm, that rework will be tricky. i added pin headers on top if the solder side of the connector, so the whole area is difficult to access
<wpwrak>
s/ if / of /
<wpwrak>
let's see if the pixel soup without resistors looks tasty
<lekernel>
(24) just tried random values
<lekernel>
10, 24, 33 and 50
<lekernel>
and 24 seemed to work the best
<lekernel>
use the 22 ohm ones
<wpwrak>
let's try the soup view first
<wpwrak>
hmm, just updated mibuild and migen. the install complains about the "yield from" in file "/usr/local/lib/python3.2/dist-packages/migen-unknown-py3.2.egg/migen/genlib/record.py", line 93
<wpwrak>
is this just a typo or to i need a different version of python ?
<wpwrak>
oops, wrong channel. sorry.
<lekernel>
3.3 yes
<lekernel>
and then you may hit a Xst bug that gets it stuck at "Analyzing FSM xxx for best encoding"
<wpwrak>
phew. as if 3.2 wasn't bleeding edge enough ...
<lekernel>
migen doesn't invoke any python version
<lekernel>
ah the install script
<lekernel>
I don't actually use it :)
<GitHub144>
[migen] sbourdeauducq pushed 1 new commit to master: http://git.io/E4ppQQ
<GitHub144>
migen/master 27accd7 Sebastien Bourdeauducq: setup.py: update required Python version
<lekernel>
you need a bios reflash for supporting the new timer too
<lekernel>
if you want to generate csr.h without waiting for ISE you can do build.py --no-run
<wpwrak>
anf the build instructions fgor milkymist-ng seem incomplete. i guess i need to build some libraries before i can "cd software/bios && make"
<lekernel>
don't this makefile build the libs?
<lekernel>
it should... but of course, it's not like I have time to test all those details
<wpwrak>
much more efficient to have them reported one by one by people who don't actually know what's supposed to happen ;-)
<wpwrak>
the setup.py change doesn't help. now setup.py build fails with Migen requires python 3.3 or greater
<wpwrak>
python3 --version => 3.2.3
<wpwrak>
so i guess you need to make the version explicit
<lekernel>
just run python3.3 setup.py
<wpwrak>
or teach setup.py to look for a matching interpreter
<lekernel>
-ENOTIME
<lekernel>
env python3.3 will fail with python 3.4
<wpwrak>
i would say "change the build instructions then" but there don't seem to be any :)
<wpwrak>
let's see .. i updated mibuild, migen ... now, to milkymist-ng
<lekernel>
well now it clearly says you need python 3.3+, which is good enough, no need to waste more time on this trivial detail
<wpwrak>
"but i have it installed" ;-)
<wpwrak>
ah, something made the dependencies now. funny. maybe it was the csrs, not the library
<lekernel>
interestingly, I have a perfectly still picture by increasing the clock frequency to 75MHz - even though ISE claims the timing isn't met. my first thought, of course, was that it had crashed ;)
<lekernel>
well almost perfectly still ...
<lekernel>
but that's a different bug than the garbled signal during SDRAM reads on my other board
<wpwrak>
in other news, xilinx are now hiring alchemists for their hard sciences department :)
<lekernel>
it could be that the HDMI pixel FIFO overflows sometimes
<wpwrak>
maybe indicate fifo overflow on a led ?
<lekernel>
but that doesn't affect the line counter, which shows the SDRAM read bug on the other board
qi-bot has quit [Ping timeout: 245 seconds]
bhamilton has quit [Quit: Leaving.]
<wpwrak>
if that vivawhatever stuff is so much faster, are you considering using it for mibuild instead of the old synthesis ? or do they have no direct correspondence ?
bhamilton has joined #milkymist
bhamilton1 has joined #milkymist
bhamilton has quit [Read error: Connection reset by peer]
<wpwrak>
(dvi_pots) ah, nice. you can have multiple entries for the same pin
bhamilton1 is now known as bhamilton
<lekernel>
vivado only work for 7 series, not slowtan6
<lekernel>
yes you can have multiple entries for the same pin, with different IO standards etc.
<lekernel>
so typically you'd use an entry crafted for the peripheral you have, rather than mess with existing vectored signals etc.
<wpwrak>
nice. that'll help to avoid packing/unpacking buses and such.
<wpwrak>
(vivado, series 7 only) grmbl.
<lekernel>
yeh, it will be nice to ditch slowtan6, ISE and Altium in one board :)
<wpwrak>
codename "ditcher"
<Fallenou_>
ahah
<Fallenou_>
but then, the price of the bom skyrockets
bhamilton has left #milkymist [#milkymist]
<Fallenou_>
funny, I cannot find 7 series fpga at farnell's
bhamilton has joined #milkymist
<larsc>
well they are not one of the official distributors
<larsc>
the BOM price will probably rise by 1.5 I guess
<larsc>
rise by 0.5 to 1.6
<larsc>
1.5
<Fallenou_>
I wonder who would use such chips for mass production
<larsc>
slowtan or series 7?
<Fallenou_>
series 7
<larsc>
why do you wonder?
<Fallenou_>
maybe 4G antennas
<Fallenou_>
well, it's very expensive so it's very likely that any vendor would try to use anything else but those expensive fpga when going to mass prod
<Fallenou_>
to those using them, I guess it's because they have no other way at all
<Fallenou_>
and doing "small runs"
<larsc>
I think they are so expensive so they can still sell the old ones
<Fallenou_>
so maybe the price will drop soon :)
<Fallenou_>
because they will want to sell theyr Vivado as well !
<Fallenou_>
ther*
<Fallenou_>
their** shitty wifi
antgreen has joined #milkymist
antgreen has quit [Ping timeout: 256 seconds]
<GitHub64>
[milkymist-ng] sbourdeauducq pushed 4 new commits to master: http://git.io/X8Kl7Q
<GitHub64>
milkymist-ng/master a39bf8c Sebastien Bourdeauducq: software/videomixer: support additive blending (enable with SW1, status on LED)
<GitHub64>
milkymist-ng/master ac64701 Sebastien Bourdeauducq: software/videomixer: better pot calibration
<GitHub64>
milkymist-ng/master 71cc2db Sebastien Bourdeauducq: Add GPIO buttons and LEDs
jimmythehorn has quit [Quit: jimmythehorn]
lekernel changed the topic of #milkymist to: Mixxeo, Migen, Milkymist-ng & other Milkymist projects :: Logs: http://en.qi-hardware.com/mmlogs :: Mixxeo preorder lists.milkymist.org/pipermail/devel-milkymist.org/2013-May/003344.html
<Fallenou_>
if they want to sell vivado software I guess they need to sell 7 series chips :)
<Fallenou_>
since it seems the vivado only supports 7 series (or maybe it's because it's the free version of vivado ?)
<lekernel>
I have a full license here, and nothing else than 7 series in vivado
kilae has joined #milkymist
<Fallenou_>
ahah
<Fallenou_>
so I guess they will reduce the price for their chips soon
<Fallenou_>
I hope
<lekernel>
you should look for kintex, which has almost decent performance levels
<lekernel>
and not super expensive like virtex
<lekernel>
artix doesn't really make sense, I agree. it's only slightly better than slowtan6 but much more expensive.
<wpwrak>
do they make their money mainly with vivado or with selling chip ? i would assume it's the latter. so if vivado is much better than ISE, limiting it to the new chips with a big margin sounds like a good strategy
ohama has joined #milkymist
<Fallenou_>
right
ohama has quit [Remote host closed the connection]
jimmythehorn has joined #milkymist
azonenberg has joined #milkymist
<lekernel>
larsc, so a transition count of 5 or above for a non-control word is an error, right?
<lekernel>
larsc, if you count the 10th (inversion) bit, it's normal to have 5 transitions sometimes, right?
<larsc>
yes
<lekernel>
and a better test would be to check for >4 transitions on bits 0-9, since that 10th bit is independent of the transition minimization
<larsc>
yes, I was about to say that
<lekernel>
ok so I get a couple errors per 2**24 words... let me try with the board that doesn't have the 24 ohm resistors
jimmythehorn has joined #milkymist
<lekernel>
interestingly they seem to appear in bursts
<lekernel>
eg it's < 4 errors most of the times, and then suddenly 20 or more
<wpwrak>
maybe a clock problem ?
<lekernel>
could be, the error rates are correlated in the 3 channels
kilae has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949]]
<wpwrak>
maybe count clock cycles over an fpga clock interval
<larsc>
are the burst evenly distributed?
Alarm_ has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949]]
<wpwrak>
you could probably monitor such things on a scope: set an error signal when detecting a problem, reset it if there's no problem or after a while (depending on whether you need to stretch the error indication for your scope)
<lekernel>
without the resistors, channel 1 error rate jumps in the thousands
<lekernel>
that's on chA. on chB, which had more SI problems, it's hundreds of thousands on all channels.
<lekernel>
(all per 2**24 words)
<lekernel>
so far things are consistent
<lekernel>
chB with resistors also show just a couple errors
<wpwrak>
consistency is good :)
antgreen has joined #milkymist
<wpwrak>
meanwhile, my attempts to build a new mixer bios/gateware haven't resulted in success :-(
<lekernel>
let's revisit the SDRAM-induced bug on the other board a little ...
<wpwrak>
i have a system that's almost completely unresponsive. no serial output, no blinking on the DVI clock, no vga output. it does show up on xrandr, though.
<lekernel>
there is no blinking to be expected on the DVI clock
<wpwrak>
okay. is there still serial output ?
<lekernel>
is your BIOS in sync with the gateware? did you rebuild it with a fresh csr.h ?
<lekernel>
yes
<wpwrak>
i did rebuild the bios. maybe the dependencies aren't right. lemme try on a clean tree then.
<lekernel>
http://pastebin.com/sfyT4HwS seems beyond doubt now, that the framebuffer is messing up the HDMI sampling
<lekernel>
at a pretty low level
<lekernel>
wpwrak, and are the serial pins making good contact?
ohama has joined #milkymist
<wpwrak>
the jtag board ? rock solid
<wpwrak>
doing a full rebuild ... let's see where it leads
<wpwrak>
(of milkymist-ng, that is. if that doesn't help, i'll repeat with cleaning out the others too)
<lekernel>
I can send you a known good bios image, ith
<lekernel>
and/or bitstream
<wpwrak>
that would be useful as well :)
<wpwrak>
i rearranged the pot pins to match my sentup, but i guess i should at least get some other signs of life, even if the pots are wrong
<lekernel>
bios + bitstream = serial output, even without the hdmi board
bhamilton has joined #milkymist
bhamilton has quit [Client Quit]
bhamilton has joined #milkymist
bhamilton has left #milkymist [#milkymist]
<GitHub170>
[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/UPrjAQ
<GitHub170>
milkymist-ng/master fb6cd48 Sebastien Bourdeauducq: dvisampler: report the word error rate
<lekernel>
WER increases with pixel clock, so I guess we still have SI problems, even with the resistors
<lekernel>
wpwrak, sent
<wpwrak>
thanks for the files ! what is videomixer.bin ? that's something new
<lekernel>
load that with flterm to start mixing HDMI (and get status info on the console)
<wpwrak>
ah, and for marketing, you should probably solder a nonfunctionsl atmel to the hdmi board, distribute firmware for it, and call is arduino-like subcontroller or such ;-)
<wpwrak>
locating flterm ...
<wpwrak>
first signs of life :)
<wpwrak>
high error rtate without signal. so far so good
<lekernel>
?
Martoni has quit [*.net *.split]
<lekernel>
without signal it should not lock the PLL and not display any error rate
<wpwrak>
if i turn off DVI, it does just that. i probably had dvi on from earlier experiments
<wpwrak>
WER ~ 10 k, ~8 k, ~5 k, without resistors
<lekernel>
what does it do if you turn off the framebuffer? (press 0)
<lekernel>
and 1 to turn it back on
<wpwrak>
screen complains :)
<lekernel>
I mean the WER
<wpwrak>
WER with fb off: ~5 k, ~ 4 k, ~2 k
<wpwrak>
turning it on again oddly doesn't seem to increase the WER
<lekernel>
which M1 revision do you have? rc3?
<wpwrak>
ah, and the serial problem was me picking the wrong device :-( so i guess serial would have been fine. i'd still have tripped over videomixer.bin, though
<wpwrak>
rc3, yes
<lekernel>
ok so right now we have one rc2 board with the SDRAM read bug and two rc3 boards without
<wpwrak>
(rc3 almost genuine. i also have one of the rc3/rc4 hybrids)
<wpwrak>
rebooting the M1 (just pld load) yields a WER of 5/4/2 k again. not sure then why it was higher at the beginning.
<wpwrak>
let's try power cycling
<wpwrak>
naw, the same. maybe it's thermal ;-)
<wpwrak>
btw, there's a bunch of compiler warnings because you're ignoring the return values of read and write. if you don't care about "proper" error handling, maybe abort on mismatch ?
<lekernel>
meh? works for me
<lekernel>
I don't have any warning
<lekernel>
did you modify the makefile to enable extra warnings?
<wpwrak>
(some of) the complains are from mkmmimg.c
<wpwrak>
no, didn't ask for trouble :)
<wpwrak>
and more complaints from flterm
<wpwrak>
gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
<lekernel>
that's mostly old code from 2009-2010 ...
<wpwrak>
but still being used :)
<wpwrak>
weird. the locally built bitstream gets WER 512 (constant), 262xxx (very little variation), 0 (constant)
<wpwrak>
maybe i need to build the videomixer binary, too
<wpwrak>
ah, all that are recent commits. rebuilding ...
<wpwrak>
ise is almost perfect for teleworkers. you can do all sorts of household tasks while it's grinding its bits.
<lekernel>
yeah, I do that...
<lekernel>
:)
<lekernel>
ah, mpeg4 at 640*360 without audio is not too much for the rpi's little cpu ...
<wpwrak>
if all else fails, there would still be ASCII porn ... :-)
<lekernel>
and of course, the rpi video playback has tearing
<lekernel>
maybe I should play the video on the laptop and just show some ascii-art with the rpi xD
<wpwrak>
a nice static background. 8 bit GIF, to avoid stressing the poor little critter too much ...
<wpwrak>
kewl. now everything works great. besides the picture quality, of course.
<wpwrak>
WER is high again. maybe what happened when i got the low WER is that the output was screensaved or such.
<wpwrak>
the colors seem perfectly in sync. so it would appear to be a pixel clock issue.
<lekernel>
low WER: I guess reading from the wrong register addresses
<lekernel>
the bitstream with the added WER counters shifted some of the CSR addresses
<wpwrak>
with a static image (e.g., after disconnecting HDMI), the frame buffer occasionally loses sync for a frame. (every 2-20 seconds or so, not often)
<wpwrak>
yeah, after rebuilding everything, it works fine
<lekernel>
yes, that's another SDRAM issue
<lekernel>
after I had to lower the clock frequency to 62.5Mhz for the poor slowtan
<wpwrak>
SDRAM controller trouble ?
<lekernel>
yes
<lekernel>
some kind of bandwidth/latency/framebuffer fifo underflow I guess
<wpwrak>
chB is considerably worse than ch A
<lekernel>
yes, same here :)
<lekernel>
gn8
<lekernel>
thx for the tests!
lekernel has quit [Quit: Leaving]
<wpwrak>
actually, plugging back into chA, it's now also bad
<wpwrak>
and degrading
<wpwrak>
very interesting effects :)
<wpwrak>
a reload fixes that. so there seems to be some "memory" for brokenness
mumptai has quit [Ping timeout: 248 seconds]
<wpwrak>
" # WARNING: Do not touch the order of those clocks, or PAR fails." hehe ;)
[florian] has quit [Remote host closed the connection]
qi-bot has joined #milkymist
<wpwrak>
i wonder if we can add a termination in the FPGA for the pixel clock