Can I route a RTSI controllable signal on my 6533 to another RTSI Controllable signal on the same card?

[nlthomas]

Hello,

I have two external clock signals, one a read clock for when reading data, and the other for a data request when writing (exporting) data. I need both of these clocks signals to go into REQ1 of my PCI-6533 (High Speed DAQ card) so that I can use port 0 for my data lines. I can't exactly hook them together without causing problems. So I hooked the read clock into ACK1 and my data request into PCLK1. Then internally using the RTSI bus, I route the Read clock to REQ1 when needed (same with the data request). However, when I am reading my data it is incorrect. I previously had the read clock attached directly to the REQ1 pin rather than athe ACK1 pin and I
was receiving the correct data. So I know that the problem is due to some sort of delay.

-How much of a delay does the RTSI bus cause?
-Is there another way to do this?
-I am using the RTSI Control VI to do this, is there
a faster/better way to route the signals?

I do have a PCI-6601 counter card that I can use for inputing the signals but I would rather not have to have two external controls for my final product. But, if I have to, is there a way to bring the signals into this card faster so that the delay would either be non-existant or at least smaller?

Thanks,
Nathan

[rgharrison]

Hi Nathan,

That's an interesting idea. From what I understand you want to make the connection once but use port A as both input during a period time in your program and then output for a period of time. You also have 2 external clocks to be used as the REQ1 clock depending on input and output.

Ideally, you would want to connect your one signal to ACK1 and your second signal to PCKL1 and be able to route them internally to a RTSI line and then choose that RTSI line as your REQ1 signal. Although I haven't tried it myself, I would imagine that would be ok. However...

There could be a case where the internal routing matrix does not permit more than 1 signal to route to a particular RTSI line. This would mean that your second RTSI Control call would over
ride the first call. In this case, you wouldn't see your clock. As a test, perhaps route a pulse train out of the RTSI on your 6601 card and use it as the REQ1 line. If this is possible then you probably programmed correctly but it really can't route multiple signals to the same RTSI line.

One possible solution in this case is to use the 6601 as a switch for you. You could route the ACK1 and PCLK1 to different RTSI lines and have the 6601 route whichever RTSI you are interested to the output of one of the counters then route that signal back through a 3rd RTSI line to be used as the REQ1 clock. This sounds challenging but it should work because I believe the routing matrix in the 6601 allows multiple connections to the same value (basically connecting two RTSI lines to the same output).

Anyway, hope this helps. Have a good day.

Ron
Applications Engineer
National Instruments

[nlthomas]

Hi Ron,

Thanks for your input. Yes, I want to use port A (port 0) as input for a while then I want to use it as output without having to flip an external switch or attached a different clock to the REQ1 line depening input or output.


I really don't need both external clocks attached at the same time. The read operation (using the ACK1 external clock) will happen all at once then I will disconnect the ACK1 line and route the PCLK1 line into it so that both clocks are not routed to ACK1 at the same time.

As I mentioned before, I have tried to route the ACK1 line to the REQ1 through the RTSI bus but I am seeing a delay there that is corrupting my data.

Do you have any ideas on how to decrease this delay?

Thanks,
Nathan

[rgharrison]

Hi Nathan,

Sorry for the late response, I haven't checked my email. If you are dealing with quick edges, it doesn't surprise me that you might get corrupt data due to the delay of the clock. As long as the data skew (the the difference in time between when the first data point transitions to when the last data point transitions) is less than half a clock period, you should be able to either clock your data on the rising edge or the falling edge. Either way, you won't be able to reduce the propagation delay through the system so you will have to work with clocking on the rising or falling edge to get it to work.

An example that changes the edge with which the data is latched by the clock is linked below. Hope that helps. Have a g
reat New Year.

Ron