lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
jimmythehorn has quit [Quit: jimmythehorn]
jimmythehorn has joined #milkymist
__del__ has joined #milkymist
__del__ has left #milkymist [#milkymist]
sh4rm4 has joined #milkymist
proppy__ has quit [*.net *.split]
Fallenou_ has quit [*.net *.split]
ximian_ has quit [*.net *.split]
ximian_ has joined #milkymist
Fallenou_ has joined #milkymist
proppy__ has joined #milkymist
<azonenberg>
wpwrak: the problem is that if you route half a net (as part of bga escape etc)
<azonenberg>
then more of it
<azonenberg>
kicad doesnt know they're the same track
<azonenberg>
so the length reading comes out wrong
<wpwrak>
seems to work fine. maybe they fixed this recently.
mumptai has joined #milkymist
<azonenberg>
i'm using 2012-10-01
<azonenberg>
which is a little out of date
<wpwrak>
here: bzr 4150, last commit may 14
<wpwrak>
sometimes 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.
Martoni has joined #milkymist
Alarm has joined #milkymist
mumptai has quit [Ping timeout: 245 seconds]
lekernel has joined #milkymist
bhamilton has joined #milkymist
<lekernel>
PCI seems to be the USB of signal integrity and timing
<lekernel>
it's just a 33MHz slow bus, but I hear lots of problems with timing etc. :)
bhamilton has quit [Quit: Leaving.]
bhamilton has joined #milkymist
bhamilton has quit [Quit: Leaving.]
bhamilton has joined #milkymist
<lekernel>
davidc___, do you have precise ideas about how SDRAM reads (but not writes) affect the HDMI signal received by the FPGA?
<lekernel>
I'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 result
<lekernel>
SDRAM is far from the HDMI traces ... I don't get it :(
<wpwrak>
not rc3 ?
<wpwrak>
and yes, crosstalk on the pcb seems pretty much impossible
<lekernel>
so wtf is going on
<lekernel>
again
<lekernel>
internal FPGA crosstalk?
<lekernel>
some weird ISE bugs?
<wpwrak>
if it's crosstalk you should also see it with DC from HDMI, right ?
<lekernel>
gosh this bug has so much potential for horrendous time wastage
<lekernel>
DC?
<lekernel>
see the lines flicker while they should be at a steady state?
<lekernel>
well crosstalk can also fuckup the signal transitions - see I2C ...
<wpwrak>
DC = constant signal. i.e., you should see changes even if there are none coming over the HDMI cable.
<wpwrak>
(so, yes ;)
<wpwrak>
in the I2C case, it also increased the number of transitions
<lekernel>
maybe I need first a quantitative means to measure the bit error rate
<lekernel>
but how ... hmm
<lekernel>
is there a reliable way to say if a 8b10b word is wrong? eg. it could be encoded with fewer transititions
<lekernel>
since DVI specifies the encoding algorithm, I guess it is safe to assume that all words that cannot be produced by this algorithm are errors
<lekernel>
then I can add a bad word counter early on each channel - so that I'm immune to effects caused by eg inter channel synchronization
<lekernel>
could be a nice debugging aid
<larsc>
yea, if the number of transitions is > 4 and it's not a special character it is a error
<wpwrak>
how 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 test
<wpwrak>
if it's nice and stable for "0" and for "1", then try more advanced patterns
antgreen has quit [Ping timeout: 256 seconds]
<lekernel>
I 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 software
<lekernel>
larsc, does that test catch *all* errors?
<lekernel>
ie is the output set of the encoding algorithm exactly all 10-bit words with <= 4 transitions
<larsc>
not all errors obviously
<larsc>
e.g. if you have 0011111111 and it is changed to 0011111110 it won't be recognized as an error
<wpwrak>
(keeping the error counter) yeah. your customers will certainly find many ways to produce HDMI troubles ;-)
<lekernel>
sure, but can the algo ever produce 0011111110?
<larsc>
I guess
<lekernel>
I know I can't really catch all 8b10b errors - but catching all words that the algo cannot produce is possible
<lekernel>
worst case I can have a 1024-bit lookup table
<lekernel>
bitgen -g EssentialBits
<lekernel>
Generates 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.
<lekernel>
so far so good, and thenm
<lekernel>
Note 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).
<lekernel>
...
<wpwrak>
nice. a biased PRNG ;-)
<lekernel>
oh this is interesting. bitgen -l
<lekernel>
In 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 bits
<lekernel>
in the current bitstream represent outputs of flip-flops and latches. Bits are referenced by frame and bit number within the frame.
<lekernel>
does this really work?! never heard of anyone doing this
<lekernel>
if it were done correctly (but with the xilinx software tradition I doubt it) that would be awesome
<wpwrak>
i suppose murphy is the patron saint of xilinx. if anything can be done wrong, they'll do it :)
<lekernel>
hmm, the output file looks legit... they probably have botched the impact part - but that could be done with urjtag
<lekernel>
oh but wait - it's not output of flip flops, it's current LUT/BRAM content
<lekernel>
and configuration data for PLL, IO etc.
<lekernel>
so that's pretty useless, except for reverse engineering the easy (non routing) parts of the bitstream format, which Wolfgang has already done
<wpwrak>
murphy inc. vs. lekernel: 1:0 :)
<wpwrak>
at 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.
<lekernel>
I wonder why the doc says "outputs of flip-flops and latches"... maybe this used to work with old virtex or something
<wpwrak>
or maybe the intern who wrote it didn't know the difference yet
antgreen has joined #milkymist
<lekernel>
it 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 resources
<wpwrak>
what's an SRL32E ?
<lekernel>
it works for virtex4
<lekernel>
turns the reconfigurable LUT into a 32-bit shift register connected to the design
<lekernel>
Bit 469422 0x000003d4 1038 Block=SLICE_X26Y121 Latch=XQ Net=count_0
<lekernel>
0x000003d4 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 frame
<wpwrak>
and this shift register is on jtag ?
<wpwrak>
ah, you just answered it ;-)
<wpwrak>
definitely sounds useful
<lekernel>
there is a simple frame address <=> position mapping on S6, probably for V4 as well
<lekernel>
SRL32E 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 frame
<lekernel>
and you don't need to insert SRL32E on virtex4, you get all current flip flop values directly in the readback frames
<lekernel>
which is kinda cool
<lekernel>
I wonder if it still works on virtex7 and artix/kintex, let me try
<lekernel>
nevertheless 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 ;)
<wpwrak>
make the fpga read back itself, then display the FFs when there's no HDMI input signal ;-)
<lekernel>
oh, it seems virtex7 can run a 11-bit counter over 1GHz
<lekernel>
that's almost an acceptable speed
<lekernel>
still works on virtex7
<lekernel>
Bit 11667075 0x0002011f 2787 Block=SLICE_X0Y193 Latch=AQ Net=count_0
kyak has joined #milkymist
kyak has quit [Changing host]
kyak has joined #milkymist
<lekernel>
trying kintex ...
<lekernel>
counter is just as fast as in v7
<lekernel>
and flip flop readback is there
<lekernel>
cool. two more reasons to get rid of s6.
<lekernel>
it seems xilinx finally starts to get their shit together with the 7 series
<lekernel>
artix also has FF readback
<lekernel>
counter is twice as slow
Guest22510 is now known as zumbi
sh4rm4 has joined #milkymist
antgreen has quit [Ping timeout: 248 seconds]
<larsc>
if 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 buffer
<larsc>
?
azonenberg has quit [Read error: Operation timed out]
<lekernel>
io pins?
<lekernel>
there will be skew, you can limit it by using the iob registers
kilae has joined #milkymist
<larsc>
what I'm trying right now is to insert a extra fifo for each io pin
<larsc>
extra flip flop
<larsc>
so it hopefully place it in the io cell
azonenberg has joined #milkymist
<larsc>
btw. if I wanted to check were it put things, do I have to use fpgaeditor?
antgreen has joined #milkymist
<lekernel>
yes, or xdl
<larsc>
ok, thanks
bhamilton has left #milkymist [#milkymist]
antgreen has quit [Remote host closed the connection]
antgreen has joined #milkymist
<azonenberg>
larsc, lekernel: i usually use planahead for looking at placement
<azonenberg>
but it doesn't show routing
<larsc>
azonenberg: how does that work?
<azonenberg>
what do you mean, how does it work?
<azonenberg>
you run it and look at the instances
<larsc>
planahead wants a project file or something
<azonenberg>
oh
<azonenberg>
make one
<azonenberg>
select "import ise P&R reuslts"
<larsc>
ah, thanks
<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?]
<lekernel>
really 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/Nkcqg3gD
<lekernel>
try with data=0/1: good idea, I will add that error word counter and collect hard data
kristian1aul has quit [Quit: Reconnecting]
kristianpaul has joined #milkymist
kristianpaul has joined #milkymist
<davidc___>
lekernel: could be a crappy VCCO line; do the HDMI/SDRAM share a bank?
<davidc___>
[I don't have Altium here]
davidc___ is now known as davidc__
<wpwrak>
(without looking) should be in different voltage domains