<sb0>
int_rtio should be the same clock as sys, no?
<sb0>
ah, not on ppro
<sb0>
yes, putting lots of TIGs between unrelated clocks is generally what works to fix those timing analyzer problems ime
<sb0>
I haven't tested amp + rtlink. but amp + old-rtio and up + rtlink work.
<rjo>
ok. then i suspect that amp+rtlink is broken ;) that's fine. just wondering wether i broke something.
<rjo>
and the symptom for those missing TIGs is that ise tries very hard to improve something and packs the registers into the BRAM thereby completely locking itself into an unresolavble situation.
<rjo>
it is pretty stupid. TIGing the path between the output of the BUFGMUX and sys_clk is not sufficient. even though the docs state that TIG paths have ultimate precedence.
travis-ci has joined #m-labs
<travis-ci>
m-labs/artiq#114 (master - d6f47b3 : Robert Jordens): The build has errored.
bentley` has quit [Remote host closed the connection]
<larsc>
and here I'm sitting fighting with Vivado's constraint managment
bentley` has joined #m-labs
bentley` has quit [Remote host closed the connection]
bentley` has joined #m-labs
antgreen has quit [Ping timeout: 265 seconds]
aeris_ has quit [Ping timeout: 250 seconds]
aeris_ has joined #m-labs
aeris_ has quit [Ping timeout: 264 seconds]
aeris_ has joined #m-labs
<mindrunner>
i investigated my uart problems further. it seems that i am not losing bytes, but having an additional byte in my fifo. it is always '0', but it should not be there. Anyone has an idea where this might come from?
<ysionneau>
we also experience(d?) some extra 0 bytes
<mindrunner>
ah
<mindrunner>
what did you do against it?
<ysionneau>
usually we read those 0 out, until it's not 0 anymore, and then they when you flushed the zeros, it seems they don't come again
<mindrunner>
but i dont know if this is a zero I sent, or a zero which i dod not
<ysionneau>
those extra 0, those I saw, are coming at the start of the communication
<ysionneau>
when they are removed then it's OK
<mindrunner>
what exactly means "start" for you?
<mindrunner>
after booting, the first couple of bytes?
<sb0>
papilio pro?
<mindrunner>
jap
<sb0>
try patching the ground planes...
<mindrunner>
whats that mean exactly?
<mindrunner>
im not really an hw expert, so i might need some advice, what to do :)
<GitHub52>
[artiq] sbourdeauducq pushed 3 new commits to master: http://git.io/vvzPH
<larsc>
does anybody know what should happen to the REGCB signal on a Xilinx blockram when using it in SDP mode?
aeris_ has quit [Ping timeout: 264 seconds]
aeris_ has joined #m-labs
FabM has joined #m-labs
<mindrunner>
sb0, does that mean that something with the ppro hardware is faulty, in particular the ground plane? is there any information resource on how to find out, what exactly i have to do?
<ysionneau>
there was some picture of a hack to fix the ground plane, but I can't find it right now
<mindrunner>
ysionneau, ooh, that would be amazing to have
<mindrunner>
lemme know if you gonna find it again :)
<ysionneau>
yep sure!
<mindrunner>
nice
mindrunner is now known as mindrunner_off
<sb0>
rjo, if the DDS override is disabled in the middle of a register update sequence by the kernel, the FTW/PTW values will be wrong
<sb0>
rjo, to prevent this, we might have to make the gateware issue the FTW/PTW programming sequence atomically...
FabM has quit [Quit: ChatZilla 0.9.91.1 [Firefox 37.0.1/20150402191859]]
aeris has joined #m-labs
<rjo>
sb0: i think that's fine. afaict in the three different cases of race conditions: a) enable override during rtio-kernel write: inconsistent registers (but no fud), then override writes new consistent registers and fud latches them. b) override disable during write: inconsistent register values written and fud-ed by rtio-kernel, will glitch but is acceptable c) monitoring read during write: inconsistent values, acceptable.
<rjo>
sb0: rtlink looks good. two things: i would not implement latency compensation there but do it in software in the experiment. latency compensation at the fpga pins is not relevant. the timing at the pins is not a "natural" timing reference for us in the lab.
<rjo>
and i would suggest counter_width = 64 - fine_ts_width so that the entire time word fits into 64 bits. even if we have fine timestap at 10ps, we have 6 years.
<mindrunner>
I tried the serial communication stuff completely without Misoc. In flashed a vanilla ZPUino and did some tests. Same problem! :( I also tried another library on the other side for the reading. (pyserial). Still gettin '0'-bytes. So looks pretty much that something is not alright with the HW.
<mindrunner>
ysionneau, did you find the picture by any chance?
<mindrunner>
does anyone have a recommendation which board I might get as an alternative?
mog has left #m-labs ["Leaving"]
<rjo>
mindrunner: pipistrello is nice.
<rjo>
mindrunner: but for papilio pro, one problem is the segmented ground plane on the underside. just stitch it together with a bunch of short bridges across signal traces.
<rjo>
mindrunner: also during bitstream config the uart tx pins are not driven. that might fill the uart fifo with crap.