@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.
@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)
Replying to @azonenberg@ioc.exchange
@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
Andrew Zonenberg@azonenberg@ioc.exchangeMission accomplished! Still a bunch of rough edges to work out, and I need to build equivalent blocks for other line codings as well as a "generic" ILA that just records waveforms.
But here's a simultaneous cross-trigger of the SERDES ILA and an analog waveform capture of the signal going into the SFP, (manually) deskewed and aligned.
Now imagine extending this to additional debug blocks within the FPGA.
Replying to @azonenberg@ioc.exchange
@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
Replying to @azonenberg@ioc.exchange
@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
@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