<GitHub153>
buildbot-config/master 62f9919 Sebastien Bourdeauducq: lab hardware is clock
bb-m-labs has joined #m-labs
sb0 has quit [Quit: Leaving]
<GitHub110>
[artiq] jordens pushed 1 new commit to spimaster: https://git.io/v2wzL
<GitHub110>
artiq/spimaster eb01b0b Robert Jordens: gateware.spi: cleanup doc
sb0 has joined #m-labs
<sb0>
rjo, I'm not sure which backplane we have - QC2 or clock
<sb0>
do you know?
<sb0>
the NIST hardware is very confusing...
<sb0>
whitequark, can you have a look at the backplane and tell me if TTL0 goes to LA00_CC_N (CLOCK) or LA00_CC_P (QC2)?
<sb0>
whitequark, for doing this, since FMC pins are hard to reach and easy to damage, I suggest: the board is currently flashed with CLOCK. toggle ttl0 from the gateware (you may need to update ddb). check if ttl0 (clock) or ttl2 (qc2) is toggling
<sb0>
whitequark, and how many 2-row connectors does it have in total? counting the one which is on the opposite side of FMC
<sb0>
as I understand, it should be 12 for clock and 13 for qc2
<sb0>
rjo, does the clock hardware also have the same connector for TTL, on the opposite side of FMC?
<sb0>
my current understanding of the situation is I have the CLOCK backplane, the QC2 TTL adapter, and the QC2 schematics.
<sb0>
rjo, I suppose the DDB can be an executable python file. then import to include.
<sb0>
not that the python import mechanism is stellar, but it will prevent reinventing some wheels
<GitHub192>
[artiq] jordens pushed 1 new commit to spimaster: https://git.io/v2wiQ
<GitHub192>
artiq/spimaster df7d15d Robert Jordens: runtime: refactor spi into rt2wb
<rjo>
sb0: when did you get it and who dido you get it from?
<sb0>
rjo, AFAIR: June/July from Daniel
<rjo>
sb0: the clock hardware is "Dec 2014" on the board iirc. the qc2 hardware should be last november/december or this year.
<sb0>
okay, so that should be clock. i don't have the schematics for it though...
<sb0>
which hasn't been a problem so far, because the dds bus is the same on the two
<sb0>
and i've been running the ttl loopback tests on the pipistrello, but now it'd be nice to run them on the kc705, preferably automatically
<sb0>
rjo, let's default everything (artiq_flash, targets.kc705, ...) to clock, since this is what we test on.
<rjo>
sb0: clock hw. yes. i have that here as well.
<sb0>
rjo, and a distinctive feature of qc2 is the active chips on the backplane, no?
<sb0>
rjo, is there only one clock revision?
<rjo>
mine has "FMC LPC ZYNQ DDS April 2014" on the pcb. that is nist_clock.
<rjo>
sb0: i think so.
<rjo>
should be.
<sb0>
ok. same marking here.
<sb0>
do you know anything about its TTL pinouts?
<rjo>
should be as Dave Leibrandt listed them.
<rjo>
i can search for the schematics if you need them. maybe i have them somewhere but i don't know.
<sb0>
as far as the artiq source is concerned yes, but this doesn't tell me where I should look for them on the physical connector
<rjo>
sb0: the spi master compiles fine on pipistrello. on kc705 with all the vivados that i have tested with it fails timing in the ethernet core now....
<rjo>
let me search.
<sb0>
did you test it with the buildserver vivado?
<rjo>
yes. 2014.2 and 2015.4 iirc
<rjo>
sb0: schematic on the way.
<rjo>
whitequark: does the compiler strip fully inlined functions from the elf? from my superficial look it seems there are is a lot of code in the kernel elf that is never used because it has been inlined.
<sb0>
rjo, any good idea where we could put a clock generator on the kc705 for testing it?
<sb0>
i want to loop it back to one of the TTLs (directly on the backplane connector)
<sb0>
the CLOCK design does not have a clock generator
<sb0>
rjo, the wb adapter could be rewritten in a way that it does not does not register data. if it still passes gateware timing, that may simplify RTIO timing computations...
rohitksingh has quit [Ping timeout: 246 seconds]
rohitksingh has joined #m-labs
sb0 has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
<rjo>
sb0: yes. but iirc i tested that a while ago and the fifo outputs wanted the registers.
<rjo>
sb0: this sequence of writing channel, address, data, timestamd and then rtio_write_and_process_status() looks refactorable. the cachin penalty of duplicating that code probably outweighs the overhead of writing channel and address even if they have not changed.
<GitHub10>
[artiq] sbourdeauducq pushed 3 new commits to master: https://git.io/v2rzC