<GitHub-m-labs>
migen/master 26d77fe William D. Jones: xilinx/ise: Add Cygwin path to Windows conversion in xst files (#88)
<cr1901_modern>
sb0: I have no way of testing Vivado on Windows, and it's currently impossible for me to install it. But I can test diamond (I have diamond improvements in the pipeline in the same vein as the icestorm improvements).
<rjo>
the buffering behavior is pretty important in the case of kinetics mode if that leads to multiple frames arriving very quickly. but i am not sure about the camera's behavior in kinetics and what it emits on clink.
<rjo>
the fragility is the same as with a ttl gate, no? the number of events is uncertain and you can mess it up if it doesn't get closed.
<rjo>
we should probably put a "last roi" bit into the events to signal that all rois of a frame have been received.
<rjo>
delaying until EOF is fine.
<rjo>
it is crucial that the ROI values correspond to the same frame. there will be only one frame per experiment iteration in many cases or one frame for 1<=N<~8 experiment iterations.
<rjo>
the complexity of the fix and the "pain" labeling are orthogonal.
<rjo>
sb0: ^
<sb0>
the ttl gate isn't tied to the camera frame rate, and doesn't have packets of events that need to be kept in sync
<rjo>
in the dominant use case "frame rate" is irrelevant. those are individual frames triggered by artiq.
<rjo>
the level-vs-edge analogy is good. if you want the current "level", then use an api like the ttl get current value, if you want the triggered frame, then gate it.
<GitHub-m-labs>
artiq/master 7fe7642 Sebastien Bourdeauducq: fmcdio_vhdci_eem: commit missing part of previous commit
rohitksingh_work has quit [Ping timeout: 268 seconds]
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1061: That was due to the 26GB of trash in ``/var/lib/buildbot/slaves/debian-stretch-amd64-2/miniconda/conda-bld``. I deleted it and it now "conda build output" takes a more reasonable time. We should clean up that folder regularly. https://github.com/m-labs/artiq/issues/1061#issuecomment-405578103
<rjo>
sb0: i don't think it's important. for spi2 it only matters for half-duplex mosi and saves a bit of power when offline.
<rjo>
sb0: could you paste the warning/error?
<sb0>
rjo, the error is cryptic, ug571 is not: IBUFDS_INTERMDISABLE ... (HR I/O banks only)
<sb0>
the FMC pins on Sayma are on HP
<rjo>
sb0: i guess it might be dcitermdisable on us
<rjo>
... on us hp
<sb0>
the question is, it it worth to add all the different code paths?
<sb0>
*is it
<rjo>
sb0: not if we can avoid it. but on kasli disabling termination on inputs made a big power difference according to greg and pawel. that's why i massaged them in.
<sb0>
hm, ok, so it might cause some kasli overheating
<rjo>
sb0: and i seem to remember that it actually made a bit of a difference but nothing i would go crazy over. we should probably get a proper power consumption datapoint on that with a current system.
<rjo>
i.e. i think it might be worth testing power/temperature without intermdisable and with.
<rjo>
and from re-reading the DS it looks like this is **only** useful for saving power. i.e. on half-duplex lines it's not needed to conform to LVDS and the termination is always disabled with T=0
<rjo>
i.e. it saves a bit of power on: TTLInOut when output, SPI when offline or half-duplex, CLink when offline.
<sb0>
but we're never using urukul or zotino spi in half duplex mode, right?