Showing results for 
Search instead for 
Did you mean: 

JTAG Digital Waveform Library

Please post feedback, questions, and comments on the JTAG Digital Waveform Library in this thread.


- David


(posted by Christian on behalf of David)

authored by
Christian L, CLA
Systems Engineering Manager - Automotive and Transportation
NI - Austin, TX

0 Kudos
Message 1 of 45

Hi Christian,


A customer of mine is looking into a low cost, efficient test platfform to deploy and test embedded systems through JTAG. Questions: is it really possible to implement such solution using one of our M Series device with clocked DIO? Is there any example showing the integration between this library and the DAQmx driver API?

I'm sort of new to JTAG, so any info would be really appreciated. 





0 Kudos
Message 2 of 45

Hi all -


I've published a new Reference Application that should prove useful when working with the IDW, JDW, and SDW libraries: Serial Protocol Communication with Digital Waveform Devices. It explains how to configure an NI-HSDIO or NI-DAQmx based device to work with one of these libraries. Check it out, and please rate it!

David Staab, CLA
Staff Systems Engineer
National Instruments
Message 3 of 45



My company has an NI PXI system with 2 PXI- 6509 DIO controllers.  We would like to perform JTAG and SPI with these devices to test various systems.


The speed is not terribly important (we understand that the 6509 is has slower switching time), but would like a JTAG and SPI VI library that supports this 6509 board.


Can JTAG Digitial Waveform Library work in this environment, or can you recommend a different approach.





0 Kudos
Message 4 of 45

Hi Aaron -


That exact same question -- using a 6509 for serial protocol communication -- was asked over in the SDW thread. You can read the dialogue I had with "sugeo" there. In short, the JDW library is designed to work with a hardware-clocked DIO device and can't be used with the 6509. You'll have to write code to toggle the I/O lines manually from your software application, similar to TomW [DE]'s SPI hack.

David Staab, CLA
Staff Systems Engineer
National Instruments
0 Kudos
Message 5 of 45



I'm wondering what speeds are reachable with this solution..


Let's say I use a NI-PCIe6535 (10MHz HDSIO), well it is in the HSDIO section but it actually uses DAQ drivers if I understood correctly.


What is the data/clock rate I can reach while using the JDW.

Is this the max clock speed of the 6535?


And for the SPI/I2C Waveform libs?

0 Kudos
Message 6 of 45

Hi AintLifeGrand -


You can actually figure this out without needing any hardware. Just open up any JDW or SDW example program and enter the smallest delays possible in the "timing (ns)" cluster. (A 10 MHz sample clock has a period of 100 ns, so this is your smallest value.) Then step the serial clock (TCK or SCLK) frequency up to the maximum value you can get without throwing an error. I found that JDW can create a 5 MHz JTAG waveform with a 10 MHz sampling device.




You can't use IDW with the 6535. Only the 6547/8 and 6551/2 can be used with IDW. These devices support per-cycle tristating.


Remember also that you'll have to remove the "TDO" channel from the waveform when you use JDW with a 6535 device (or "MISO", in SDW).

Message Edited by David S. on 11-13-2009 01:55 PM
David Staab, CLA
Staff Systems Engineer
National Instruments
0 Kudos
Message 7 of 45

Hmm, I am reading these pages for a couple of weeks now, and I believe that I previously did see examples of I2C  'emulated' with the 6535? Has the waveform library, or the "reference manual"  been changed in the meantime?


PS. Can't I read in the TDO data? Or do I just have to remove from the waveform because it is using the hardware compare option?

0 Kudos
Message 8 of 45

Hi AintLifeGrand-


The only edit was to remove the 6533/4 from the list of compatible devices after discovering that it lacks the necessary trigger/event routing capability. Other than that, only grammatical changes have been made to date. IDW relies wholly on per-cycle tristating to create an open-drain output. You can't have bidirectional communication on an I2C bus without it. The 6535 doesn't have this feature, so it can't be used with IDW.


P.S. You just have to remove the TDO channel from the waveform because it uses HWC bit states (X, L, H). You can still configure the DI task to read in the data, though parsing through it won't be as easy or as computationally efficient as it is with HWC. See the reference programs in Serial Protocol Communication for an example.

Message Edited by David S. on 11-13-2009 02:26 PM
David Staab, CLA
Staff Systems Engineer
National Instruments
0 Kudos
Message 9 of 45

Hello David,


Thanks for the quick response.


The I2C functionality I was talking about was in the IDW forum topic (The following is your text) Quote :

You may be able to edit the IDW source code to work with a DAQmx-based device, but you'll have to work with only a subset of the functionality.  Here are some pitfalls and workarounds I can see:

  • The only other clocked DIO device that supports open-collector outputs is the 6534.  If you use a DAQ (E-, M-series, etc.) or another 653x device, you'll be stuck with actively driven outputs.  This means that you won't be able to listen to the slave's responses (data and ACK) while the DO session is active.
  • No other device supports the compare and tristate states (L, H, X, Z, V, T) in a waveform.  You'll have to either edit the IDW code to generate an active-drive waveform (1 and 0 only) or write a find-and-replace function that changes the Z's to 1's.
  • Without per-cycle tristating, you'll have to tell the DO session to tristate the buffers immediately after generating each segment of the waveform, so you don't interfere with the DUT's attempt to respond with an ACK bit or a data byte.
  • You can trigger the acquisiton (DI) task off the generation (DO) task to capture an ACK bit after you've sent data -- or to capture a data byte after the first ACK bit.  Because of the above requirement of ending the DO session after generating the waveform though, this means that you'll have to stop-and-restart the sessions to transfer every byte.  Some chips have a maximum limit to the amount of time between clock pulses; make sure you won't violate it waiting for the software to restart the sessions.
  • Without hardware compare, you'll have to write a bit-banging funciton to parse the acquired waveform and extract the valid bits that were sent by the slave.

It's not an impossible task, but it's largely simplified by the 655x's features.


So that is what I was talking about, so let's call it a glitch in my brains 'lookup table'.


Thnx for the quick response.


Kind Regards, Danny


0 Kudos
Message 10 of 45