@azonenberg sounds good, I'd very much like to have a hand in writing the spec to make sure it's covering more use cases
@whitequark Yep, sounds like a plan.
If you want to follow along and look at the WIP, the debug IPs are at https://github.com/azonenberg/antikernel-ipcores/tree/master/debug and the SCPI bridge server is at https://github.com/ngscopeclient/scopehal-akldebug-bridge
@azonenberg will check
another desire I have: so the toolchain should (in most cases) be able to autodetect the clock domain for signals and group those based on that
will your system have a way to have multiple ILAs in different clock domains, with cross-triggers?
@whitequark So, the clock period in ps is exposed as a queryable register to make the timebase look proper host side.
All of the ILA blocks will have trigger in/out signals, I've already done a demo of cross triggering an external analog scope and decoding the same 8b10b stream both inside the FPGA and from the analog waveform.
You'll need to provided CDC for the trigger pulses yourself, but that should be straightforward to do in a code generation framework (or manually in SV like I do).
ngscopeclient has a concept of "trigger groups". By default, each scope or scope-like instrument is its own trigger group, meaning they're asynchronous to each other and you can either batch arm/stop them all at once, or individually start/stop/single trigger just one.
To set up a cross-trigger simply open the manage-instruments dialog and drag one of the scopes onto another one. This creates a new trigger group with the drag destination as the primary (trigger source) and the scope you're dragging as the first secondary. You can add arbitrarily many secondaries to a trigger group.
When the trigger group is armed, an arm signal is sent to each secondary scope, ngscopeclient waits for the secondaries to all report they're ready to capture, then the primary is armed and they all trigger in lock-step.
Replying to @azonenberg@ioc.exchange
@whitequark When you adjust the trigger position of a secondary scope in a trigger group, it time-shifts the window of the secondary relative to the trigger pulse, but does not shift the alignment between the two scopes. To align the two scopes, you can either manually type a skew value into the skew column of the trigger group table, or use the auto-deskew wizard (which currently only supports analog scopes for both primary and secondary) to cross-correlate a PRBS sampled by both scopes and measure the cross-trigger delay automatically.
@azonenberg it would be very nice if the ILA interface provided an automatic deskew interface, maybe a ping-pong to another trigger group measured with resolution of this ILA's sample rate?
@whitequark Auto deskew between digital channels could definitely be possible to implement. Easiest option would be a low-speed PRBS (several times slower than the slowest clock domain) sampled directly by one and through a synchronizer by the other.
@azonenberg yeah that would also work. it's less complex on the gateware side and more complex on the visualization side; also might have other advantages I'm not seeing?
@whitequark well mostly it would also enable deskewing *arbitrary* LAs not just ILAs.
Or ILAs to analog scopes, etc. Basically just extending the existing cross-correlation based deskew logic to support non-analog signals