Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

Real Time LVDS Hardware Compare

I would like to solicite advice on a problem I am having.

 

I am trying to do real time hardware compare on LVDS channels using a single 6552 board.  My DUT is a CODEC where data is clock in and out.  I have setup the 6552 such that I am able to do LVDS generation and acquistion.

 

The problem I am running into is that I am using the DDC clock  out signal, looped back onto the the strobe of the same device.  To generate the LVDS clocks I have to use the DIO of the board.  I am using the onboard clock thus making the clocks I generate 1/2 (at the fastest) that of my onboard clock becuase the 6552 cannot do DDR.   The strobe for acquisition session needs to be free running so I cannot hook it up to an output of the generation session.  This all causes the acquistion to occur at twice the rate of the generation session. 

 

I cannot oversample my compare data to fake it out either because the drive and compare waveforms have to be the same size to do hardware compare.

 

Any thoughts?

 

 

 

Message Edited by BrianPack on 08-14-2009 04:03 PM
Message Edited by BrianPack on 08-14-2009 04:04 PM
0 Kudos
Message 1 of 4
(3,900 Views)

In general, if you generate a clock on a DIO for wrap back, the constraint is that it must be toggling when the Acquisition session is commited or initiated.  If you use scripting and triggering, you can start your generation, repeat a pattern (that toggles the DIO) until a script trigger.  you can export the Acquisition read for start or start trigger events to then kick out of the repitition loop and start your pattern can pick up where you need it.

 

Specifically to your application, I'm a little confused as to why your acquisition is "twice as fast".  You're generating data twice as fast too so your acq and gen should be consistent (albeit doubled up).  If you interleave "X" (don't cares) with your expected response, you should have matching waveforms depths.

 

Could you give a little more detail into your application and needs.

0 Kudos
Message 2 of 4
(3,891 Views)

The problem is in the fact that if your onboard clock is 10 Mhz you can only generate a 5 Mhz clock on the DIO port.  Do I understand that right?  The only way you could get a 10Mhz clock on a DIO pin is if you do DDR, which the 6552 cannot do?  (I have to use the DIO lines to clock data in and out of my CODEC because I am doing LVDS with the 6552.) 

 

So on the acquisition side I am using the strobe running off an the exported generation sample clock that is running at twice the frequency as I am able to clock the data out of the CODEC, and into the 6552.

 

 

0 Kudos
Message 3 of 4
(3,868 Views)

Brian,

 

You're correct then.  Stimulus response mode is going to require that both engines are running at the same rate.  Instead of using Strobe, you can use OnBoard clock as your source and stuff don't cares in every other sample.  You may need to play with RTD to compensate for the round trip delay of your data path.

 

There's an exmple of using the "Delayed Data Active" event to compensate for your data path:

http://zone.ni.com/devzone/cda/epd/p/id/5993

 

This example uses TCLK to do multi board synchronization as well so you can strip that stuff out.

 

Additionally, if you are running at 10MHz, the data delay will not be supported.  You can use rising edge / falling edge data position to help with timing margins.  Alternately you can run faster than 25MHz and duplicate samples to get access to the data delay feature of the 655x.

0 Kudos
Message 4 of 4
(3,864 Views)