#milkymist IRC log for Wednesday, 2013-05-15

azonenbergwpwrak: the problem is that if you route half a net (as part of bga escape etc)05:53
azonenbergthen more of it05:53
azonenbergkicad doesnt know they're the same track05:54
azonenbergso the length reading comes out wrong05:54
wpwrakseems to work fine. maybe they fixed this recently.06:00
azonenbergi'm using 2012-10-0106:44
azonenbergwhich is a little out of date06:44
wpwrakhere: bzr 4150, last commit may 1406:46
wpwraksometimes traces don't quite meet at the right point. then it can take a DRC run before kicad can figure out how things connect. could be you hit this kind of problem. should be fairly rare, though.06:55
lekernelPCI seems to be the USB of signal integrity and timing08:03
lekernelit's just a 33MHz slow bus, but I hear lots of problems with timing etc. :)08:03
lekerneldavidc___, do you have precise ideas about how SDRAM reads (but not writes) affect the HDMI signal received by the FPGA?08:50
lekernelI'd guess it's crosstalk and the SDRAM chips have faster slew rates than the slowtan - tried selecting low drive strength in the EMR, no result08:51
lekerneldesign files are here http://milkymist.org/mmone/old/rc2_design.tar.bz2 / http://milkymist.org/mmone/old/rc2_gerber.tar.bz210:07
lekernelSDRAM is far from the HDMI traces ... I don't get it :(10:07
wpwraknot rc3 ?10:09
wpwrakand yes, crosstalk on the pcb seems pretty much impossible10:10
lekernelso wtf is going on10:15
lekernelagain10:15
lekernelinternal FPGA crosstalk?10:16
lekernelsome weird ISE bugs?10:16
wpwrakif it's crosstalk you should also see it with DC from HDMI, right ?10:17
lekernelgosh this bug has so much potential for horrendous time wastage10:17
lekernelDC?10:17
lekernelsee the lines flicker while they should be at a steady state?10:18
lekernelwell crosstalk can also fuckup the signal transitions - see I2C ...10:18
wpwrakDC = constant signal. i.e., you should see changes even if there are none coming over the HDMI cable.10:19
wpwrak(so, yes ;)10:19
wpwrakin the I2C case, it also increased the number of transitions10:20
lekernelmaybe I need first a quantitative means to measure the bit error rate11:57
lekernelbut how ... hmm11:58
lekernelis there a reliable way to say if a 8b10b word is wrong? eg. it could be encoded with fewer transititions12:00
lekernelsince DVI specifies the encoding algorithm, I guess it is safe to assume that all words that cannot be produced by this algorithm are errors12:01
lekernelthen I can add a bad word counter early on each channel - so that I'm immune to effects caused by eg inter channel synchronization12:02
lekernelcould be a nice debugging aid12:02
larscyea, if the number of transitions is > 4 and it's not a special character it is a error12:03
wpwrakhow about applying DC to HDMI and see if you get a non-zero amount of transitions on any of the color/clock lines ? that would be the easiest case to test12:10
wpwrakif it's nice and stable for "0" and for "1", then try more advanced patterns12:11
lekernelI guess we can try both... the word error rate counter is also nice to leave around in the core as a quick diagnostic tool that can easily be displayed at any time by software12:14
lekernellarsc, does that test catch *all* errors?12:17
lekernelie is the output set of the encoding algorithm exactly all 10-bit words with <= 4 transitions12:18
larscnot all errors obviously12:20
larsce.g. if you have 0011111111 and it is changed to 0011111110 it won't be recognized as an error12:21
wpwrak(keeping the error counter) yeah. your customers will certainly find many ways to produce HDMI troubles ;-)12:21
lekernelsure, but can the algo ever produce 0011111110?12:21
larscI guess12:22
lekernelI know I can't really catch all 8b10b errors - but catching all words that the algo cannot produce is possible12:22
lekernelworst case I can have a 1024-bit lookup table12:22
lekernelbitgen -g EssentialBits12:35
lekernelGenerates essential bits data files in ASCII format (.ebc and .ebd extensions). The EBC file contains device configuration data. The EBD file contains mask data that indicates which bits of the EBC file are essential to the circuitry of the design.12:35
lekernelso far so good, and thenm12:35
lekernelNote The EssentialBits algorithm exhibits moderate false positives (bits marked essential but which do not affect the functionality of the design) with less than 100 PPM false negatives (bits classified as non-essential but which will affect the functionality).12:36
lekernel...12:37
wpwraknice. a biased PRNG ;-)12:42
lekerneloh this is interesting. bitgen -l12:43
lekernelIn some applications, you may want to observe the contents of the FPGA internal registers at different times. The file created by bitgen -l helps you identify which bits12:44
lekernelin the current bitstream represent outputs of flip-flops and latches. Bits are referenced by frame and bit number within the frame.12:44
lekerneldoes this really work?! never heard of anyone doing this12:44
lekernelif it were done correctly (but with the xilinx software tradition I doubt it) that would be awesome12:45
wpwraki suppose murphy is the patron saint of xilinx. if anything can be done wrong, they'll do it :)12:50
lekernelhmm, the output file looks legit... they probably have botched the impact part - but that could be done with urjtag12:51
lekerneloh but wait - it's not output of flip flops, it's current LUT/BRAM content12:57
lekerneland configuration data for PLL, IO etc.12:57
lekernelso that's pretty useless, except for reverse engineering the easy (non routing) parts of the bitstream format, which Wolfgang has already done12:58
wpwrakmurphy inc. vs. lekernel: 1:0 :)12:59
wpwrakat least they're consistent. well, almost. it's kinda irritating that their new synthesis would be so much faster. maybe they also made it more unreliable, to compensate.13:00
lekernelI wonder why the doc says "outputs of flip-flops and latches"... maybe this used to work with old virtex or something13:04
wpwrakor maybe the intern who wrote it didn't know the difference yet13:06
lekernelit could still be used to implement a lightweight LA though... you just add SRL32E's on the signals you want to see, and you can readback the samples without using extra FPGA resources13:18
wpwrakwhat's an SRL32E ?13:22
lekernelit works for virtex413:26
lekernelturns the reconfigurable LUT into a 32-bit shift register connected to the design13:27
lekernelhttp://lists.milkymist.org/pipermail/devel-milkymist.org/2013-April/003332.html13:27
lekernelso for virtex4 you get lines like13:28
lekernelBit   469422 0x000003d4   1038 Block=SLICE_X26Y121 Latch=XQ Net=count_013:28
lekernel0x000003d4 is the frame address (you can issue a readback command to the device via jtag to get the frame) and 1038 the offset in bits in the frame13:29
wpwrakand this shift register is on jtag ?13:29
wpwrakah, you just answered it ;-)13:29
wpwrakdefinitely sounds useful13:30
lekernelthere is a simple frame address <=> position mapping on S6, probably for V4 as well13:30
lekernelSRL32E are not normally on JTAG, but since the FPGA uses the same storage elements for the shift register and the LUT, I'd assume you get the current shift register contents in the LUT content part of a readback frame13:31
lekerneland you don't need to insert SRL32E on virtex4, you get all current flip flop values directly in the readback frames13:31
lekernelwhich is kinda cool13:31
lekernelI wonder if it still works on virtex7 and artix/kintex, let me try13:32
lekernelnevertheless I have a V4 board and it would be easy and fun to readback continuously and display the current FPGA status on screen, similar to visual6502 ;)13:33
wpwrakmake the fpga read back itself, then display the FFs when there's no HDMI input signal ;-)13:34
lekerneloh, it seems virtex7 can run a 11-bit counter over 1GHz13:36
lekernelthat's almost an acceptable speed13:36
lekernelstill works on virtex713:38
lekernelBit 11667075 0x0002011f   2787 Block=SLICE_X0Y193 Latch=AQ Net=count_013:38
lekerneltrying kintex ...13:39
lekernelcounter is just as fast as in v713:40
lekerneland flip flop readback is there13:41
lekernelcool. two more reasons to get rid of s6.13:41
lekernelit seems xilinx finally starts to get their shit together with the 7 series13:42
lekernelartix also has FF readback13:43
lekernelcounter is twice as slow13:43
larscif I want to send the same signal to multiple pins(18 in this case), is there anything special I need to consider, like manually inserting a buffer15:08
larsc?15:08
lekernelio pins?16:07
lekernelthere will be skew, you can limit it by using the iob registers16:07
larscwhat I'm trying right now is to insert a extra fifo for each io pin16:10
larscextra flip flop16:10
larscso it hopefully place it in the io cell16:14
larscbtw. if I wanted to check were it put things, do I have to use fpgaeditor?16:23
lekernelyes, or xdl16:58
larscok, thanks17:06
azonenberglarsc, lekernel: i usually use planahead for looking at placement18:10
azonenbergbut it doesn't show routing18:10
larscazonenberg: how does that work?18:17
azonenbergwhat do you mean, how does it work?18:18
azonenbergyou run it and look at the instances18:18
larscplanahead wants a project file or something18:18
azonenbergoh18:19
azonenbergmake one18:19
azonenbergselect "import ise P&R reuslts"18:19
larscah, thanks18:19
davidc___lekernel: I'll take a look tonight. Its definitely the reads, eh? Is the pattern data-dependant? [IE, if you read 0's does it break differently than 1s?]18:22
lekernelreally seems to be the reads, yes. enabling/disabling the framebuffer with the DAC undriven has a definite impact on the line counter (which does not depend on SDRAM): http://pastebin.com/Nkcqg3gD18:34
lekerneltry with data=0/1: good idea, I will add that error word counter and collect hard data18:34
davidc___lekernel: could be a crappy VCCO line; do the HDMI/SDRAM share a bank?18:38
davidc___[I don't have Altium here]18:38
wpwrak(without looking) should be in different voltage domains18:40
wpwrakbtw, schematics are here: http://milkymist.org/mmone/rc3_schematics.pdf18:40
wpwrakgerbers are here http://downloads.qi-hardware.com/hardware/milkymist_one/gerber/rc3/rc3_gerber.tar.bz218:41
davidc__lekernel: I assume disabling the framebuffer just stops the reads - it doesn't shutdown a PLL / ext clk or anything, does it?18:54
--- Thu May 16 201300:00

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