<hedgeberg>
so sb0 i think you had a bit of a misunderstanding last night
<hedgeberg>
im a bit more awake so maybe i can explain a little better
<hedgeberg>
re: latency
<hedgeberg>
but basically there are ways to figure out the latency of all the different paths
<hedgeberg>
you mentioned "common mode" latency, and the thing is that on the FPGA portion, the latency is about as close as it gets to 0
<hedgeberg>
the latency is dominated by delays created by gate charging along the CMOS grains
<sb0>
hedgeberg, can you explain what your latency measurement plan is exactly?
<sb0>
and latency of FPGA designs isn't close to 0 at all
<sb0>
FPGAs are slow
<hedgeberg>
im not talking about a processor in an FPGA, im talking about a simple state machine
<hedgeberg>
?????
<hedgeberg>
what?
<hedgeberg>
do you mean CPLD's?
<sb0>
no, I mean FPGAs
<hedgeberg>
i mean yeah its a little slower on how fast you can clock it, but FPGA's are able to do real time combinational logic
<hedgeberg>
and modern FPGA's work at 800 MHz plus
<hedgeberg>
my virtex IV can be clocked up to 500 MHz and that was a 300/90 nm combined process
<hedgeberg>
modern fpgas in 22 nm or 14 nm nodes are able to handle very high clock speeds
<sb0>
yes, if you toggle a flip flop, you get this sort of freq
<sb0>
add routing and a few LUTs and it goes down
<hedgeberg>
yeah of course
kuldeep_ has joined #m-labs
<hedgeberg>
but it gets slowed down by collective gate delays
kuldeep has quit [Remote host closed the connection]
<sb0>
anyway. how do you want to measure the latency between the Zynq ARM core and the fabric?
<hedgeberg>
there's a few ways
<hedgeberg>
my easiest thought would be to have the fpga programmed with a simple state machine, triggered by a button press. The signal created by the button is captured by both the FPGA and the logic analyzer/oscope being used to measure latency
<hedgeberg>
FPGA state machine catches signal, routes resulting signal out to an external pin and to the arm core
<hedgeberg>
arm core catches signal, does the same
<hedgeberg>
gives a stacked set of resulting signals that can be used to gauge latency at each point
<hedgeberg>
it can also be gauged on the way back out, so arm core signal can also be routed out through some logic and out from another pin
<hedgeberg>
signal timing can be compared, gives each major path's latency
<hedgeberg>
i mean i guess i should ask, what would the FPGA be used for in the case of a zynq SoC other than external modules?
<hedgeberg>
better question, what all is implemented in MiSoc
<hedgeberg>
what are the systems that compose the SoC
<hedgeberg>
i think thats probably where my failure in understanding is actually
<sb0>
hedgeberg, you could skip the button/oscope part and just have a counter inside the FPGA
<sb0>
if that's what you want to measure. but you have a few different things there.
<hedgeberg>
i mean yeah, whats going on in MiSoC that we'd need to keep in mind?
<hedgeberg>
we have the cpu core being used that theoretically id substitute for the Zynq arm core
<hedgeberg>
but what are the other systems that are implemented in the fpga matrix
<sb0>
the usual: uart, sdram memory controller, timer, etc.
<sb0>
like in a microcontroller
<hedgeberg>
ok
<hedgeberg>
does artiq just take advantage of implemented peripherals or does it implement its own too in left over cells?
<sb0>
there are several additional cores for artiq
<sb0>
otherwise, it would not make much sense to use a FPGA
<hedgeberg>
mmmmhm
<hedgeberg>
you could do it on a pretty cheap custom pcb
<sb0>
do what?
<hedgeberg>
artiq
<hedgeberg>
implement the remaining peripherals over MiSoC using a microcontroller and some peripherals
<sb0>
yes, for small artiq systems the requirements aren't high, in fact it runs on pipistrello
<hedgeberg>
so, i guess this is something i should start looking into at this point, so feel free to not answer, but what does artiq do to implement experiment descriptions?
<hedgeberg>
does it modify hardware for each different experiment description?
<sb0>
no, it just loads new code into the softcore cpu
<hedgeberg>
ok
<hedgeberg>
so i dont need to mess with any synthesizing or PaR or compiling, just adjusting parameters
<hedgeberg>
and maybe the instruction set too if i want to make it run on ARM
<hedgeberg>
not to say its easy
<hedgeberg>
but a lot easier than it could have been
<sb0>
if you are porting to a new board or hooking up a zynq core, there will be a lot of messing around with xilinx software. especially for the latter.
ohama has quit [Ping timeout: 260 seconds]
ohama has joined #m-labs
stekern has quit [Ping timeout: 258 seconds]
stekern has joined #m-labs
<GitHub154>
[pythonparser] trotterdylan opened pull request #12: Support chained attribute accesses for decorators (issue #11) (master...master) https://git.io/vMhas
sb0 has quit [Quit: Leaving]
mumptai has joined #m-labs
sb0 has joined #m-labs
<GitHub24>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vMh6H
<GitHub24>
artiq/master f7dec72 Sebastien Bourdeauducq: firmware: give satman whole RAM in linker script
<GitHub48>
[artiq] sbourdeauducq closed issue #456: Connection reset by peer / timeout on core device https://git.io/vMhX1
<GitHub7>
[artiq] sbourdeauducq commented on issue #456: Switch installed. Unit tests still pass and 700 runs of @cjbe's experiment went through without problem. https://git.io/vMhXX
<sb0>
whitequark, "without problem" except that I still got several "WARN(runtime): network error: dropped by socket" in the log
<sb0>
cool, the sfp cable works
mumptai has quit [Remote host closed the connection]
kuldeep_ has quit [Quit: Leaving]
sandeepkr has quit [Ping timeout: 260 seconds]
sb0 has quit [Quit: Leaving]
<GitHub20>
[smoltcp] torokati44 opened pull request #4: examples/server: Rename tcp_6969_active to tcp_6970_active. (master...master) https://git.io/vMjLE
<GitHub24>
[artiq] jbqubit commented on issue #562: What is the development checklist for DRTIO? How is is progressing? https://git.io/vMjMh
cr1901_modern has quit [Ping timeout: 255 seconds]
<GitHub98>
[artiq] jbqubit commented on issue #553: It would be helpful to have a development checklist for keeping track of what the steps are and how things are progressing. Based on [wiki](https://github.com/m-labs/artiq/wiki/DMA). https://git.io/vMjDz
<GitHub6>
artiq/master 8a13c8c Robert Jordens: doc: use minimal conda environment to build
<GitHub82>
[artiq] whitequark commented on issue #653: @jbqubit It is possible to implement automatic coercions for argument passing in ARTIQ Python, but due to the way type inference works, it's a zero-sum game: for every case where I add a possible coercion, there will be another case where a type annotation is now mandatory. Especially since that will break existing code, I think this feature is a net negative, and in any case the added effort would seem t
<bb-m-labs>
build #1243 of artiq is complete: Failure [failed artiq_flash] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1243 blamelist: Robert Jordens <rj@m-labs.hk>, Robert Jordens <jordens@gmail.com>
<GitHub104>
artiq/master b7f6bff whitequark: firmware: fix embedding of software version during build.
<whitequark>
rjo: ^
<GitHub62>
[artiq] jbqubit commented on issue #653: @whitequark Ya, mandatory type annotation isn't desirable. Thanks for the comment. https://git.io/vMj5U
<GitHub199>
[artiq] jordens commented on issue #653: @jbqubit ... https://git.io/vMj5W
<GitHub23>
[artiq] whitequark commented on issue #653: @jbqubit To add to this, automatic coercions for arithmetic operations already result in necessity for type annotations in some cases. E.g. this function is ambiguous:... https://git.io/vMjdq
<GitHub103>
[artiq] whitequark commented on issue #653: @jbqubit To add to this, automatic coercions for arithmetic operations already result in necessity for type annotations in some cases. E.g. this function is ambiguous:... https://git.io/vMjdq
<GitHub>
[artiq] jbqubit commented on issue #562: The scope of DRTIO/DMA funded by Oxford remains obscure to me. ARL is also funding a big chunk of the distributed DMA. It would be helpful to know what subset of the features discussed in the wiki are expected under these combined contracts. My expectation based on past practice is a checklist. For example, ... https://github.com/m-labs/artiq/issues/562#issuecomment-275516953
<GitHub>
[artiq] sbourdeauducq commented on issue #562: @jbqubit As far as your contract goes, everything is in place for phase 2 except changing the frequency to match the DAC and more annoyingly fixing the obscure packet corruption bug (There is the sysref sync as well but this is not DRTIO). Also, this issue is not the best place for your message. https://github.com/m-labs/artiq/issues/562#issuecomment-275539713
hedgeberg|away is now known as hedgeberg
hedgeberg is now known as hedgeberg|away
hedgeberg|away is now known as hedgeberg
sandeepkr has quit [Read error: Connection reset by peer]