@whitequark see https://ioc.exchange/@azonenberg/116856901135293906 for an example of a cross-trigger between an ILA (primary) and external analog scope (secondary).

There's no way to do this with any other debug flow I've ever seen - like you can certainly use a xilinx ILA and a GPIO to trigger another scope but you can't view the data all on one timeline like this

@whitequark and ILA integration, to enable exactly this, has been on the wishlist for literal years.

Like the github ticket for REing the Vivado ILA and writing a driver for it was filed in April 2019

@whitequark But the vivado UI was just barely not painful enough to force me to do something about it, so it just sat there until I started playing with efinix stuff and *their* ILA was enough of a disaster that I couldn't tolerate it

@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.

@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.

@azonenberg all of that sounds good

is each ILA block a separate instance of the gateware, with its own control regs, data RAM, and info ROM?

@whitequark Correct.

It's very much a CoreSight-esque architecture, there's a single bridge from JTAG or whatever to the internal memory bus, a root ROM table pointing to the debug IPs, then each debug IP has one or more sets of registers you can interface with.

Each VIO has a single flat register block with both ROM and input/output signal buses in a single space.

The SERDES ILA does not have a ROM since it only works with raw line-coded symbols, but it has one register bank for control/trigger and one for memory readout.

The regular ILA is very similar to the SERDES ILA but it also has a separate region in the control/trigger range for the ROM. (and eventually trigger comparator settings)

@azonenberg okay yeah this all sounds very well designed, my only real issue is the symbol table format and everything else sounds like it can be used as-is

@whitequark yeah i've spent a lot of time fighting with other debug IPs and this is intended to address some of those pain points lol

@azonenberg yeah this is objectively very cool and super useful, I wanted that many times too

@whitequark I really do wonder how the T&M industry stagnated so much to the point that everything I'm doing is super groundbreaking.

Like this seems like an obvious way to do things

@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