<lekernel>
Third, HDMI runs parallel, not serially. There are three color signals riding on three data pairs in an HDMI cable, with a clock circuit running on the fourth. These signals can't fall out of time with one another, or with the clock, without trouble
<lekernel>
well the receivers implement phase detection and channel bonding, so it's only true if "trouble" means "wasting the time of engineers designing the receivers"
<lekernel>
and SDI clock recovery isn't easy either
<lekernel>
and btw if the max9121 weren't slow, it would be quite straightforward to run HDMI on those praised coax cables ...
fpgaminer has joined #milkymist
<lekernel>
HDMI isn't actually that bad, especially compared to e.g. USB
<wpwrak>
larsc: heh, i think i'll give that part of the investigation a test now :) it's not as if i could obtain a lot of useful data on that end anyway. it's more curiosity of how far i can push my scope. it's actually amazing that i can still sort of figure out what the signal looks like at all, being at 2.5x the scope's analog bandwidth
<wpwrak>
err no, 1.25 x of course. need my morning caffeine ...
<wpwrak>
this shows the clock at the hdmi connector (blue) and the fpga echoing dvi0.clk on an mmc pin (yellow)
<wpwrak>
trigger is on the blue channel. this tests whether strange things happen between hdmi clock edges, glitches or such.
<wpwrak>
some 250 k times everything went well. then my trick to keep the screensaver from blanking the screen didn't work and it turned off. the stray line that's completely off comes from that.
<wpwrak>
hmm, how do create a self.sync.<clock> ? i want to run something off the pll-generated pixel clock
<lekernel>
and then you drive self.<clock>.clk and self.<clock>.rst
<wpwrak>
the clock is already defined in clocking. i just want to reuse it.
<lekernel>
you can also create the ClockDomain() with the reset_less parameter, in which case you don't need the rst signal and it uses bitstream init
<lekernel>
ah, then just use the clock name in self.sync.<clock>
<lekernel>
eg self.sync.pix5x += ....
<wpwrak>
for can i use "pix" ?
<lekernel>
yes
<lekernel>
but
<wpwrak>
i knew it :)
<lekernel>
pix ... pix5x are only valid for modules that are at the dvisampler level and below
<lekernel>
upwards (in the top level) they are renamed to dvisampler{0,1}_pix*
<wpwrak>
can i bring them up ? i tried accessing dvi....submodules.etc. but that yielded errors
<lekernel>
self.sync.dvisampler0_pix += ...
<wpwrak>
straightforward enough .. let's see ...
<lekernel>
or put your logic in the dvisampler module and send the io pin there
<wpwrak>
whee, made it to the synthesis !
<wpwrak>
let's see what crawls out of this :)
<wpwrak>
thanks !
<wpwrak>
btw, do you recall if there's a lot of difference between the test points in rc2 and rc3 ?
<wpwrak>
or can we just assume that all boards are more or less like rc3, as far as test points are concerned ?
<wpwrak>
(i don't actually remember what the differences between rc2 and rc3 where. some codec changes, but what else ?)
<lekernel>
hmm, not quite sure... maybe there's some info in the list archives or in the qi hardware wiki
<lekernel>
note that you may hit S6 clock routing issues if you try using PLL clocks ...
<lekernel>
and it will only tell you during final routing, so that you waste maximum time
<wpwrak>
yeah, all the interesting errors seem to come out at the very end
<wpwrak>
will it at least give me an error ? or will it be hidden in one of the millions of warnings ?
<larsc>
maybe ;)
<wpwrak>
it's actually surprising that they print error messages. error numbers that you have to look up in some registration-only online database would be so much more fun.
<wpwrak>
and of course, half the number should say something like "please contact a xilinx support representative"
<larsc>
don't they do that already?
<Fallenou_>
masochist :)
<wpwrak>
well, they have both. probably there's an option somewhere that lets you disable error N. that's why they need the number. or maybe in a frenzy of political correctness, someone translated the error messages, so you need the numbers to be able to figure out what somebody else's failed build actually said
<wpwrak>
and yes, some messages are more technobabble than anything else. e.g., "INFO:Timing:3386 - Intersecting Constraints found and resolved. For more information, see the TSI report. Please consult the Xilinx Command Line Tools User Guide for information on generating a TSI report."
<wpwrak>
pll output is looking good so far
<Fallenou_>
let the spam begin!
Hawk777` has quit [Ping timeout: 240 seconds]
Hawk777 has joined #milkymist
Fallenou_ has quit [Remote host closed the connection]
Alarm_ has joined #milkymist
Fallenou has joined #milkymist
Hawk777 has quit [Ping timeout: 252 seconds]
<wpwrak>
interesting. when there's a lot of display activity, the error rate goes up
<wpwrak>
or at least it seems to. not a perfect match.
<wpwrak>
e.g., if i have an xterm and do a find /, the WER increases by some 50%
<wpwrak>
interestingly, that effect doesn't seem to depend on whether the xterm is actually visible on the HDMI output
Guest79831 has joined #milkymist
<wpwrak>
let's try this with a different card
<wpwrak>
no effect
<wpwrak>
maybe it's RF riding on top of the signals :)
bhamilton has joined #milkymist
<wpwrak>
very interesting. i opened the balcony door a bit (my desk is right in front of it) and let in some cold air. the WER jumped from things like WER:3590 1478 562 to WER:16931 7374 3883 and worse
<wpwrak>
here's a particularly bad one: WER:35437 9126 3304
<larsc>
what are those numbers?
<wpwrak>
some symbol error rate. not sure how sebastien calculates it
<wpwrak>
something like "weird symbols per second"
<larsc>
ah ok
bhamilton has quit [Ping timeout: 264 seconds]
<wpwrak>
lekernel: if you want to see more errors, it may help to put your system into a fridge ;-) not sure if it's the m1, the pc, or both that go bad when cool
<wpwrak>
in any case, it seems that hitler was quite right complaining about the difference one degree made
<wpwrak>
though inside vs. outside air is about 10 C at the moment
<wpwrak>
takes about 30 s before the error rate starts climbing
<wpwrak>
and after a minute, what was 1500-5000 becomes > 10-40k
<wpwrak>
the average is up by almost 10x (rough estimate)
<lekernel>
larsc, number non control characters that have more than 5 transitions per 2**24 recovered words
<lekernel>
well, more than 4 transitions in bits 0-9
<lekernel>
as we discussed
<lekernel>
wpwrak, colder temperature = faster silicon = steeper rise times = more SI issues on mismatched impedances, which is improved with the series resistors. so far things look consistent.
<wpwrak>
first WER bow consistently aropund 30-60 k
<wpwrak>
funny. now it's getting low. after i stopped.
<wpwrak>
but returned to high. now i closed the door, so it should warm up before too long.
<wpwrak>
what surprises me is how much the error rate increased because of these few degrees.
<Fallenou>
nice article (vjunion)
<lekernel>
wpwrak, hitler isn't mad for no reason
<wpwrak>
;-))
<wpwrak>
at least now i know why i got such a wide range of error rates.
<wpwrak>
"An example of a supported peripheral connected to the I/O port would be a monitor." hmm. considering how bad SI gets already a our rather leisurely speeds, i'd be very careful what to wish for there .. :)
<lekernel>
I'm thinking about the OLED things
<lekernel>
128*96 4k colors or something like that
<lekernel>
even slowtan6 should be capable of doing that without breaking a fuss
<wpwrak>
famous last words ;-)
<wpwrak>
warming up from the cold treatment takes its own sweet time ... baseline is still high, about 16 k
[florian] has quit [Quit: leaving]
[florian] has joined #milkymist
[florian] has joined #milkymist
Alarm_ has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949]]
<lekernel>
anyone knows what the difference is between "bitbang mode" and "gpio mode" on a ft2232h?
<larsc>
maybe bitbang updates multiple pins at one, gpio mode only mode
<larsc>
only one
<lekernel>
hm, seems it's a libmpsse idiosyncrasy
<lekernel>
RTFSing and GPIO enables a dummy MPSSE while BITBANG gives access to all pins
<lekernel>
why is it that libftdi can't read the high GPIO pins? WTF?
<wpwrak>
the ftdi chips are deeply flawed in many ways. stray one mil from the beaten path and you're in a world of trouble.
<lekernel>
gosh everytime I want to do *anything*, even as simple as controlling GPIO pins, I bump into broken shitware issues
<lekernel>
there are 16 fucking GPIO pins per channel
<lekernel>
not 8
<lekernel>
there's a GET_BITS_HIGH MPSSE command that sounds like something that would read the other 8, but of course nothing uses it, and of course there is zero documentation
<lekernel>
and MPSSE command != control transfer, so you can't guess from the ftdi_read_pins code
<lekernel>
do you think the poor shit would work if I simply increase the control transfer data buffer to 2 bytes?
<wpwrak>
forget it. you can't make an ftdi chip do something that's not been done many times before.
<wpwrak>
there are a lot of features that look like something that could work but they don't
<wpwrak>
if you want control, get an mcu and write some decent firmware. after all, that's what the ftdi folks did, too :)
<wpwrak>
well, i suppose it works well enough that they can sell the chips. who cares about what happens after that ? :)
<wpwrak>
ah, interesting. silabs have similar chips that are mcus. could also be that this is a 2nd generation design, where the volume allowed them to go for an asic.
<lekernel>
great, libftdi -> lirc-utils -> mplayer dependency. good job arch linux folks. I thought only debian did that.
<wpwrak>
what, no libreoffice ?
<lekernel>
oh yeah, the ftdi chip only returns 1 byte, even if you ask for 2
<lekernel>
how are you supposed to use the GET_* MPSSE commands then?!?!!!
<wpwrak>
maybe you're not ? :)
<lekernel>
"libFTDI works perfectly" "The library is easy to use" my ass
<wpwrak>
i'm sure everything works fine if you use their proprietary library.
<lekernel>
how did libftdi get written? reverse engineering ftd2xx?
<wpwrak>
part that, i guess, part using what little documentation is our there. and a lot of trial and error.
<wpwrak>
s/our/out/
<lekernel>
thing is - I have a board on which the high GPIO pins are inputs for the FTDI chip. everytime I use this libftdi piece of crap, it sets all those bits as outputs, causing contention and failure (not to mention that I'd actually like to read those pins at some point)
<wpwrak>
just write a piece of code that accesses the functions you need ? then, later, merge that with libftdi
<wpwrak>
that is, if you can get it to work. i think reading pins may be possible but setting them is unreliable
<wpwrak>
at least that's roughly what i remember from my adventures in that area
<lekernel>
is there any alternative to ftdi that isn't slow?
<lekernel>
after seeing that shit I'm going to try to kick that chip out of my boards as much as possible
<wpwrak>
ch1 is pll out (1x) / 2, ch2 is clk on the hdmi board. trigger (it's a bit on the left, hidden under the test counters) on ch1.
<wpwrak>
850 k good cycles and counting. if the pll would regularly get out of phase, i should have seen one of these events.
<wpwrak>
the dark blue / dark yellow bands are the persistent traces
<wpwrak>
the brown "cave walls" are the forbidden area for ch2
<lekernel>
fx2 doesn't work with urjtag, right?
<lekernel>
ah and the fx2 needs custom firmware too
<lekernel>
which no one has written apparently
<wpwrak>
fx2 = the chips from cypress ?
<lekernel>
(except in proprietary jtag cables)
<lekernel>
yess
<wpwrak>
your own firmware = maximum control
<wpwrak>
chasing bugs may be painful, particularly if they're usb bugs. but then, they're _your_ bugs and you can do something about them. still infinitely more rewarding than wrestling with unfixable bugs in someone else's firmware.
<wpwrak>
the clock monitoring included the temperature experiments. so the clock is actually rather stable.
<lekernel>
for the mixxeo there is the ftdi+urjtag solution (including nor flash writing) that works, as long as I don't touch it ;)
<lekernel>
ftdi chip systems are like sausages, you like them until you learn how they are made
<wpwrak>
they're like certain fast food restaurants. you enjoy their efficiency, just don't look in the kitchen
<wpwrak>
oh, and what functionality do you actually want to add with the ftdi ?
<lekernel>
it's another board... and the way to load a bitstream in it is 1) hold PROGRAM_B low with one of those uncontrollable FTDI pins 2) use MPSSE to write to the serial flash 3) release PROGRAM_B and the FPGA reads the bitstream you just wrote
<lekernel>
this, of course, is flawed - very slow (adds a good minute on top of the ISE runtimes), and doesn't even work correctly as the FTDI chip holds PROGRAM_B at board power up until the computer makes it release it
<lekernel>
and the JTAG port is not connected on that board
<lekernel>
don't ask me, I didn't design it
<wpwrak>
so you could try using jtag to control program_b ? that's at least an io you know you can control
<lekernel>
program_b is under ftdi control, and there is no jtag
<lekernel>
I think you don't realize how badly designed this board is :)
<lekernel>
the only way you load a bitstream in it is by writing it to the flash, which is completely useless as the FPGA can't read it without a computer making the FTDI release PROGRAM_B
<wpwrak>
but could you run a wire from, say, the pin that usually gets TMS to PROGRAM_B
<wpwrak>
?
<wpwrak>
clever :)
<wpwrak>
i hope they pay you well to solve these problems :)
<lekernel>
no, the BGA JTAG balls are not even routed
fpgaminer has quit [Ping timeout: 256 seconds]
<wpwrak>
is the ftdi on a bga ?
<lekernel>
no, but the fpga is
<lekernel>
actually I can control PROGRAM_B somehow by using ftdi_set_bitmode()
<wpwrak>
but it's not reliable
<lekernel>
maybe that will do for now, and then I'll tell them to fix that damn board
fpgaminer has joined #milkymist
<wpwrak>
what i suggest is to use an ftdi pin that you already know you can control (from the jtag group) and connect that one to program_b instead
<wpwrak>
that is, if this is a 2232. if it's just a 232, then you're out of luck
<wpwrak>
(well, probably out of luck. at least it was like that a few years ago)
<lekernel>
hm, MPSSE pinouts are fixed, no?
<lekernel>
and the problem is also that some other pins in the "high GPIO" range should be floating
<lekernel>
and it appears they are when I use ftdi_set_bitmode() with the lucky parameters... so I may have a workaround... let me try
<lekernel>
with rework what I could do is use the lower GPIO pins, which appear to be more controllable via software
<lekernel>
not easy soldering work though
mumptai has quit [Ping timeout: 252 seconds]
<lekernel>
wpwrak, I need to use MPSSE in SPI mode to write the flash while the GPIO pins are being controlled
<lekernel>
so I can't do the JTAG hack
<lekernel>
but the ftdi_set_bitmode() hack appears to work, I just managed to read the SPI flash identification number and then release PROGRAM_B
<lekernel>
and no PCB rework, yay
<wpwrak>
whee :)
<wpwrak>
hmm 75 Ohm termination in the FPGA seems to help a little. other values don't. pity. 50 R looked nice in the simlation.