#milkymist IRC log for Saturday, 2013-05-18

larscdue to dc balance you'll get two patterns, one being the inverse of the other06:04
larscyou could try a dc balanced symbol though like 39 (and hope there is no gamma correction)06:10
lekernelThird, 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 trouble09:43
lekernelwell the receivers implement phase detection and channel bonding, so it's only true if "trouble" means "wasting the time of engineers designing the receivers"09:44
lekerneland SDI clock recovery isn't easy either09:45
lekerneland btw if the max9121 weren't slow, it would be quite straightforward to run HDMI on those praised coax cables ...09:48
lekernelHDMI isn't actually that bad, especially compared to e.g. USB09:49
wpwrakdownloads works again .. here's a more permanent link for the "eye": http://downloads.qi-hardware.com/people/werner/ming/hdmi-si/eye-black-25.20072MMz-100kSa-log.png09:49
wpwraklarsc: 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 bandwidth09:53
wpwrakerr no, 1.25 x of course. need my morning caffeine ...09:55
wpwrakmeanwhile, the fpga seems to pick up the clock well enough: http://downloads.qi-hardware.com/people/werner/ming/hdmi-si/fpga-clkin-hdmi-clk-ok.png09:58
wpwrakthis shows the clock at the hdmi connector (blue) and the fpga echoing dvi0.clk on an mmc pin (yellow)09:58
wpwraktrigger is on the blue channel. this tests whether strange things happen between hdmi clock edges, glitches or such.09:59
wpwraksome 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.10:00
wpwrakhmm, how do create a self.sync.<clock> ? i want to run something off the pll-generated pixel clock10:57
lekernelself.clock_domains.<clock> = ClockDomain()10:57
lekerneland then you drive self.<clock>.clk and self.<clock>.rst10:58
wpwrakthe clock is already defined in clocking. i just want to reuse it.10:58
lekernelyou can also create the ClockDomain() with the reset_less parameter, in which case you don't need the rst signal and it uses bitstream init10:58
lekernelah, then just use the clock name in self.sync.<clock>10:59
lekerneleg self.sync.pix5x += ....10:59
wpwrakfor can i use "pix" ?10:59
wpwraki knew it :)11:00
lekernelpix ... pix5x are only valid for modules that are at the dvisampler level and below11:00
lekernelupwards (in the top level) they are renamed to dvisampler{0,1}_pix*11:01
wpwrakcan i bring them up ? i tried accessing dvi....submodules.etc. but that yielded errors11:01
lekernelself.sync.dvisampler0_pix += ...11:01
wpwrakstraightforward enough .. let's see ...11:01
lekernelor put your logic in the dvisampler module and send the io pin there11:01
wpwrakwhee, made it to the synthesis !11:04
wpwraklet's see what crawls out of this :)11:04
wpwrakthanks !11:04
wpwrakbtw, do you recall if there's a lot of difference between the test points in rc2 and rc3 ?11:04
wpwrakor can we just assume that all boards are more or less like rc3, as far as test points are concerned ?11:05
wpwrak(i don't actually remember what the differences between rc2 and rc3 where. some codec changes, but what else ?)11:06
lekernelhmm, not quite sure... maybe there's some info in the list archives or in the qi hardware wiki11:06
lekernelnote that you may hit S6 clock routing issues if you try using PLL clocks ...11:06
lekerneland it will only tell you during final routing, so that you waste maximum time11:07
wpwrakyeah, all the interesting errors seem to come out at the very end11:08
wpwrakwill it at least give me an error ? or will it be hidden in one of the millions of warnings ?11:09
larscmaybe ;)11:20
wpwrakit'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.11:31
wpwrakand of course, half the number should say something like "please contact a xilinx support representative"11:32
larscdon't they do that already?11:33
Fallenou_masochist :)11:33
wpwrakwell, 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 said11:36
wpwrakand 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."11:38
wpwrakpll output is looking good so far11:42
Fallenou_let the spam begin!13:51
wpwrakinteresting. when there's a lot of display activity, the error rate goes up14:53
wpwrakor at least it seems to. not a perfect match.14:54
wpwrake.g., if i have an xterm and do a find /, the WER increases by some 50%14:56
wpwrakinterestingly, that effect doesn't seem to depend on whether the xterm is actually visible on the HDMI output14:57
wpwraklet's try this with a different card14:57
wpwrakno effect14:58
wpwrakmaybe it's RF riding on top of the signals :)14:58
wpwrakvery 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 worse15:15
wpwrakhere's a particularly bad one: WER:35437 9126 330415:15
larscwhat are those numbers?15:15
wpwraksome symbol error rate. not sure how sebastien calculates it15:16
wpwraksomething like "weird symbols per second"15:16
larscah ok15:16
wpwraklekernel: 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 cool15:17
wpwrakin any case, it seems that hitler was quite right complaining about the difference one degree made15:18
wpwrakthough inside vs. outside air is about 10 C at the moment15:18
wpwraktakes about 30 s before the error rate starts climbing15:26
wpwrakand after a minute, what was 1500-5000 becomes > 10-40k15:27
wpwrakthe average is up by almost 10x (rough estimate)15:27
lekernellarsc, number non control characters that have more than 5 transitions per 2**24 recovered words15:28
lekernelwell, more than 4 transitions in bits 0-915:29
lekernelas we discussed15:29
lekernelwpwrak, 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.15:31
wpwrakfirst WER bow consistently aropund 30-60 k15:35
wpwraknow, m1, meet my heat gun15:36
lekernelI'd heat the max912115:38
wpwrakyes, that's wher i pointed my gun15:40
wpwrakno effect, thougyh15:40
wpwrakfunny. now it's getting low. after i stopped.15:40
wpwrakbut returned to high. now i closed the door, so it should warm up before too long.15:42
wpwrakwhat surprises me is how much the error rate increased because of these few degrees.15:43
Fallenounice article (vjunion)15:43
lekernelwpwrak, hitler isn't mad for no reason15:44
wpwrakat least now i know why i got such a wide range of error rates.15:45
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 .. :)15:48
lekernelI'm thinking about the OLED things15:49
lekernel128*96 4k colors or something like that15:49
lekerneleven slowtan6 should be capable of doing that without breaking a fuss15:49
wpwrakfamous last words ;-)15:51
wpwrakwarming up from the cold treatment takes its own sweet time ... baseline is still high, about 16 k15:51
lekernelanyone knows what the difference is between "bitbang mode" and "gpio mode" on a ft2232h?17:24
larscmaybe bitbang updates multiple pins at one, gpio mode only mode17:33
larsconly one17:33
lekernelhm, seems it's a libmpsse idiosyncrasy17:34
lekernelRTFSing and GPIO enables a dummy MPSSE while BITBANG gives access to all pins17:35
lekernelwhy is it that libftdi can't read the high GPIO pins? WTF?17:44
wpwrakthe ftdi chips are deeply flawed in many ways. stray one mil from the beaten path and you're in a world of trouble.17:46
lekernelgosh everytime I want to do *anything*, even as simple as controlling GPIO pins, I bump into broken shitware issues17:48
wpwrakyou're clearly murphy's favourite :)17:49
lekernelno but come on17:52
lekernelthere are 16 fucking GPIO pins per channel17:52
lekernelnot 817:52
lekernelthere'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 documentation17:54
lekerneland MPSSE command != control transfer, so you can't guess from the ftdi_read_pins code17:55
lekerneldo you think the poor shit would work if I simply increase the control transfer data buffer to 2 bytes?17:58
wpwrakforget it. you can't make an ftdi chip do something that's not been done many times before.17:59
wpwrakthere are a lot of features that look like something that could work but they don't17:59
wpwrakif you want control, get an mcu and write some decent firmware. after all, that's what the ftdi folks did, too :)18:00
larscwpwrak: well except for the decent ;)18:01
lekernelseems they didn't - http://siliconpr0n.org/archive/doku.php?id=azonenberg:ftdi:ft232rl18:02
wpwrakwell, i suppose it works well enough that they can sell the chips. who cares about what happens after that ? :)18:02
wpwrakah, 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.18:04
lekernelgreat, libftdi -> lirc-utils -> mplayer dependency. good job arch linux folks. I thought only debian did that.18:04
wpwrakwhat, no libreoffice ?18:05
lekerneloh yeah, the ftdi chip only returns 1 byte, even if you ask for 218:18
lekernelhow are you supposed to use the GET_* MPSSE commands then?!?!!!18:21
wpwrakmaybe you're not ? :)18:22
lekernel"libFTDI works perfectly" "The library is easy to use" my ass18:22
wpwraki'm sure everything works fine if you use their proprietary library.18:22
lekernelhow did libftdi get written? reverse engineering ftd2xx?18:23
wpwrakpart that, i guess, part using what little documentation is our there. and a lot of trial and error.18:24
lekernelthing 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)18:27
wpwrakjust write a piece of code that accesses the functions you need ? then, later, merge that with libftdi18:30
wpwrakthat is, if you can get it to work. i think reading pins may be possible but setting them is unreliable18:31
wpwrakat least that's roughly what i remember from my adventures in that area18:31
lekernelis there any alternative to ftdi that isn't slow?18:36
lekernelafter seeing that shit I'm going to try to kick that chip out of my boards as much as possible18:36
lekerneland it should not have USB bugs too18:37
larscthat's what in the Logic818:38
lekernelyeah, FTDI is out on the k7 board19:05
lekerneland said function immediately starts with this:19:07
lekernel/ Put in this small delay incase the application programmer does a get GPIOs immediately after a set GPIOs19:07
lekernel  Sleep(5);19:07
lekernelkewl, got the damn thing to do what I want19:24
lekernelthough 5 hours to read 8 fucking GPIO pins is a waste of time, and FTDI sucks19:24
larsc\o/ /o/ /o\19:24
lekernelso the magic sequence is 0x83 0x87 and the FTDI chip sends one byte back with the high GPIO pins values19:26
lekernelmh. no. still doesnt work.20:06
wpwrak(kicking ftdi) a decision that will not make you unhappy :-)20:29
wpwrakand no, it won't work. you're not the first one to go down that road.20:29
wpwrak"small delay increase" ... that's 5 seconds ?20:30
lekernel5 ms20:30
lekernelit's windows only code, of course20:30
lekernelthat's the win32 Sleep() function, not the unix sleep()20:31
wpwrakok. so "small" is not just an oddly misplaced euphemism in this case.20:31
wpwrakthe PLL looks healthy: http://downloads.qi-hardware.com/people/werner/ming/hdmi-si/fpga-pix2-hdmi-clk-ok.png20:38
wpwrakactually, that's not a good name ...20:38
wpwrakimproved name: http://downloads.qi-hardware.com/people/werner/ming/hdmi-si/fpga-2pix-hdmi-clk-ok.png20:39
wpwrakch1 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.20:41
wpwrak850 k good cycles and counting. if the pll would regularly get out of phase, i should have seen one of these events.20:42
wpwrakthe dark blue / dark yellow bands are the persistent traces20:43
wpwrakthe brown "cave walls" are the forbidden area for ch220:44
lekernelfx2 doesn't work with urjtag, right?20:44
lekernelah and the fx2 needs custom firmware too20:46
lekernelwhich no one has written apparently20:46
wpwrakfx2 = the chips from cypress ?20:46
lekernel(except in proprietary jtag cables)20:46
wpwrakyour own firmware = maximum control20:47
wpwrakchasing 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.20:48
wpwrakthe clock monitoring included the temperature experiments. so the clock is actually rather stable.20:50
lekernelfor the mixxeo there is the ftdi+urjtag solution (including nor flash writing) that works, as long as I don't touch it ;)21:24
lekernelftdi chip systems are like sausages, you like them until you learn how they are made21:25
wpwrakthey're like certain fast food restaurants. you enjoy their efficiency, just don't look in the kitchen21:25
wpwrakoh, and what functionality do you actually want to add with the ftdi ?21:30
lekernelit'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 wrote21:34
lekernelthis, 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 it21:36
lekerneland the JTAG port is not connected on that board21:36
lekerneldon't ask me, I didn't design it21:36
wpwrakso you could try using jtag to control program_b ? that's at least an io you know you can control21:37
lekernelprogram_b is under ftdi control, and there is no jtag21:38
lekernelI think you don't realize how badly designed this board is :)21:38
lekernelthe 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_B21:39
wpwrakbut could you run a wire from, say, the pin that usually gets TMS to PROGRAM_B21:39
wpwrakclever :)21:39
wpwraki hope they pay you well to solve these problems :)21:40
lekernelno, the BGA JTAG balls are not even routed21:40
wpwrakis the ftdi on a bga ?21:42
lekernelno, but the fpga is21:43
lekernelactually I can control PROGRAM_B somehow by using ftdi_set_bitmode()21:43
wpwrakbut it's not reliable21:44
lekernelmaybe that will do for now, and then I'll tell them to fix that damn board21:44
wpwrakwhat 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 instead21:44
wpwrakthat is, if this is a 2232. if it's just a 232, then you're out of luck21:45
wpwrak(well, probably out of luck. at least it was like that a few years ago)21:45
lekernelhm, MPSSE pinouts are fixed, no?21:46
lekerneland the problem is also that some other pins in the "high GPIO" range should be floating21:46
lekerneland it appears they are when I use ftdi_set_bitmode() with the lucky parameters... so I may have a workaround... let me try21:47
lekernelwith rework what I could do is use the lower GPIO pins, which appear to be more controllable via software21:48
lekernelnot easy soldering work though21:49
lekernelwpwrak, I need to use MPSSE in SPI mode to write the flash while the GPIO pins are being controlled22:14
lekernelso I can't do the JTAG hack22:14
lekernelbut the ftdi_set_bitmode() hack appears to work, I just managed to read the SPI flash identification number and then release PROGRAM_B22:15
lekerneland no PCB rework, yay22:16
wpwrakwhee :)22:18
wpwrakhmm 75 Ohm termination in the FPGA seems to help a little. other values don't. pity. 50 R looked nice in the simlation.22:31
lekerneldid you see a spec for the maximum dissipation of those terminations?22:36
lekernelif you enable 25 ohm terminations on all IOs at VCCO=3.3V it can reach more than 175W :)22:37
wpwraki have something like 1.5 Vpp :)22:38
lekernelyay! got a LED blinking on that ยง""%()=! board22:47
lekernelbitstream load time: 3 minutes22:47
lekernelthey have *also* picked a slow flash22:49
wpwrakbe thankful that it's not EPROM ;-)22:59
--- Sun May 19 201300:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!