Solution
- The frequency of the state machine executing the pattern. A state executes an opcode and uses a time set with a defined vector period. On that vector period each channel can be programmed to do something specific. That something can be as simple as driving a single value at some fixed offset time, but it can do more complex data formats and edge multipliers. This is not measured in bits per second, but in vectors per second or hertz.
- The rate of the data source/capture memories. If a channel needs to drive 2 states on a given vector period and those depend on a source memory, or if it needs to capture values at 2 different times and store them in some capture memory, then those memories need to have a corresponding data rate to allow accessing 2 bits per vector. This is measured in bits per second.
- The rate of the frontend pins. If a channel needs to drive multiple edges on a given vector period, the pin that is driven needs to be able to physically drive the output a digital signal at a corresponding rate. For example, in return to zero (RTZ) data format, only one bit of data is needed per vector period (pulse or no pulse), but that bit may create two transitions (two edges of a pulse). I think this is what can make documents confusing because it is hard to use consistent units depending on whether a clock is being generated/described and whether the data bus with respect to that clock is DDR or SDR or some other data format. Sometimes I explicitly use the units of "edges per second" or "transitions per second" when it helps clarity.
The first limitation translates to vector rate. 6570 runs this at a maximum rate of 100 MHz.
Data rate may be referring to the second one or the third one depending on context. When talking about "the maximum possible" spec, then I think it refers to a scenario where one bit of data corresponds to one transition on the pins and therefore is limited by both but typically dominated by the frontend edge rate (with the extra complication that a corresponding SDR clock pin may need to generate two edges per data pin transition, but doesn't need access to two bits of data for those two transitions).
For the 6570, the details of the frontend are what cause all the caveats about the datarate beyond 100 Mbps (133/160, etc). For the Next Generation Digital Pattern Instruments, frontend technologies capable of higher edge rates are being researched, which is what is shown in that slide deck you referenced.
A data rate higher than the vector rate can be achieved by using the 2x Edge Multiplier feature, allowing two DUT cycles to occur within a single vector period. This feature was introduced in version 18.0 of the driver. The data rate is different from the vector rate because even though two pin states can be driven within a single vector period, that vector can still only have one timeset and opcode. So the maximum vector rate of 100MHz does not change with this feature, but data can be driven up to 200Mbps.
I agree that the "Important Considerations" document you linked appears out of date with respect to this feature. The "SDR vs. DDR" document looks accurate, and I may also recommend looking at this document for another illustration of this feature: How to Create Digital Pattern over 100MHz
(The digital pattern instruments we offer today do not offer data rates of 500Mbps. We can't make any guarantees about what future digital pattern instruments will support.)