What are the 3-bit field choices for Hw_Arm_Sel in PCI-6601

[Kirco]

Hi,

I am programming our own driver to operate the PCI-6601. For our application we need hardware arm option. I know it is possible to use 2 counters for that, but NI-TIO should support also hw_arm. Although it is not explained in the registry document at all, after some tedious check in the DDK examples I found that this bits are located in the Gi counting mode register. I know the position of the HW_enable as well as the position of the 3 bits for pin sellect options. What I do not know is What are the 3-bit field choices for Hw_Arm_Sel . I contacted NI support but got no support. How can NI sell boards and when a customer who is not using LAbview or Measurement Studio or DDK, but is implementing his own driver is then so arrogantly turned down from NI? Also, how can NI publish just part of the registers the board support, and when a customer contacs and asks for some registers get not at all support? I can not foretell the missing registers, and it is pretty unprofessional to document just partly the registers of 660x devices. And on request you got nothing.

I hope someone from the community know about this Hw_Arm_Sel 3 pin options. Otherwise, there is just an option of error and trial. Or simply throw the board in the garbage.

Dr. Kirco Arsov

[JoeFriedchicken]

Hi Kirco,

It sounds like there was some mis-communication at some point in your service request. Applications Engineers (AEs) do not have the responsibility of supporting DDK questions, which may explain why you feel that you got no support.

DDK questions are very infrequent because very few customers use the DDK for their applications, and so collecting every question in the same forum (rather than in individual service requests) provides a good living history document of register-level programming for our customers. In addition, the questions that do come up are usually very detailed and low-level, and NI does not expect AEs to know every aspect of every ASIC since their responsibility is to support the mainstream customers. For these reasons, the DDK is directly supported by R&D engineers like myself.

In your case, your branch AE asked an NI headquarters (NIC) AE for help, and the NIC AE asked me in turn. I reiterated that DDK questions should not be addressed by AEs but by R&D in the DDK forum. It appears that these reasons were not relayed back to you.

It's true that the 660x RLP manual is incomplete (as is many of the other manuals for the other ASICs). Although there are other reasons for this, the main one is that it's more efficient for NI to answer questions as they come up than to prepare and release a customer-facing manual. NI has many optimized designs that it wants to protect, and separating the public aspects from the protected takes a significant effort.

With all of that said, I hope we can work together and solve your problem.

The three bits in the Hw_Arm_Sel field of the Gi Counting Mode register do indeed select which signal the TIO uses to arm the counter. However, it's not as simple as selecting which pin on the I/O connector to use as the arm trigger: there are eight internal trigger lines from which to select, and none of them directly connect to external I/O pins. Like all of NI's ASICs, the TIO has a very complex routing matrix for combining and connecting internal and external hardware signals to the counters. Before programming the Hw_Arm_Select bits, you need to program a route from an external I/O connector pin to one of the eight internal trigger lines. After that, you can use the Hw_Arm_Select bits to set the internal trigger line for your counter.

I did not design the TIO ASIC, and so while I know the logic governing the chip's behavior, I am not expertly familiar with the routing registers and matrix. I need to speak with a few colleagues to learn more about programming signal routes in the TIO. There has been some work done before with internal routing [1] and Ed shared good avice, but Frank's end goal doesn't completely match yours. I'll give you updates as I make progress.

[1] how to drive RTSI line with 660x?
http://forums.ni.com/ni/board/message?board.id=90&message.id=1330#M1330

[Kirco]

Hi Joe and thank you for your post. I look forward to more information. It is at least clear from your reply that the RTSI lines inside the board (the connector in the upper part of the board) should be used/sellected (or not? but there is no info on which line is driving what in the manuals....) or rerouted to/from the I/O connector. I  do trully hope we will resolve this problem. With all  time spent for simple bits we could simply programm a small CPLD or a weaker fpga for this task, but now we really want to use the board after so much time spent in this issue.

Br

Kirco

[JoeFriedchicken]

Great, I'm glad to hear you're willing to learn more about TIO programming. I'm still looking into the questions you have.

[JoeFriedchicken]

Hi Kirco,

I have some more information for you 🙂

I haven't been able to speak to the developer who is the most familiar with TIO programming since he's out of the office, but I have come across his notes from when he was writing support for the DAQmx driver.

As I described earlier, the HW_Arm_Sel bits don't select a connector I/O pin, but an internal trigger signal. There are seven internal trigger lines, and the HW_Arm_Sel bits map directly to the internal trigger signal: 0b000 - 0b111 map to 0d0 - 0d7. In order to route an I/O pin to an internal trigger, you must also write to a few more registers.

From what I've read, there are two more register families that need to be programmed: TG_x_LevelEdgeReg and TG_x_CombinationReg, where x is the internal trigger number. In your case, you only need one pin from the I/O connector to be your arm start trigger, so TG_0_LevelEdgeReg and TB_0_CombinationReg will suffice for your application.

TB_0_LevelEdgeReg :: Offset 0x660

TG_0_LevelEdgeReg is only 8 bits wide, and maps as follows:
7..6: EdgeMode
5..0: LESel

LESel selects the I/O connector pin to use as the source for the internal trigger signal. 0d0 - 0d39 will select the I/O pin of the same number. NB: behavior for TG_x_LevelEdgeReg is more limited for triggers 1-7, and only a small subset of the I/O pins can be selected for those trigger signals. Trigger 0 can use any I/O pin. Setting these bits to 0d63 forces the trigger source low, and can be used as a way to 'unroute' it when you're finished with your program.

EdgeMode determines whether the TIO will detect an edge of the incoming signal, or just pass the signal level straight through. When detecting edges, it will latch the signal and generate a single TIMEBASE3 pulse instead. 0b00 sets level mode; 0b01 sets rising edge; 0b10 sets falling edge; 0b11 sets either edge.

TG_0_CombinationReg :: Offset 0x6A0

TG_0_CombinationReg is 32 bits wide, and has three fields of interest:
19..16: CombFunction
5..4: CombTypeB
1..0: CombTypeA

CombTypeA controls which trigger subsystem to use as the source for the trigger signal. Since you're coming from an I/O pin and using the edge/level subsystem, you must set these bits to 0b01.

CombTypeB is similar to CombTypeA, and although you won't be using trigger B, set it to 0b01 to be safe.

CombFunction performs a simple logic function on A and B. Since you're only using a single I/O connector, you only need the A output, so set these bits to 0b1100.

All of the other bits should be set to 0b0.

Unfortunately, I'm unable to test these statements since my test machine is currently being used for another research project. Please let me know what happens if you decide to test.

[Kirco]

Hi Joe and many thanks!

This is the info I was looking initially. Thanks that you took your time and looked the registers info for us. We have at the moment a quick (and diry) solution which works now but not as good as we want it. Namely, we simply read the trigger signal (in our case 1PPS comming from the H.MAser) via the DIO_0 line in a software loop and as far as it changes state we software-arm the counter. This is accurate for the trigger signal within 0.1msec (which is bad for our system) so we must then use a ps event timer to correct for this offset. We do believe that with the HW_Arm we could achieve the arming accuracy within 1ns or better (we achieved that by deriving different frequencies from the H. Maser frequency with 6601 board). I will definitely try your description today as far as I get in the office. We actually for this operation use Counter 1. The terminal block and all wiring has been done in the CA-1000 and is in the rack (together with the dio-96 tb wirings) now. So the triggering signal is connected to DIO_0 pin and we want to use the counter 1 for this operation. Counter 0 is doing another thing, such as ext 10MHz counting, getting abs time synchronization from GPS, sending TC to counter 2, counter2 counts the TCs of counter 0, since 100ns rolls over very fast, so we should get a track of this not to have to read the counter once in each 7 min etc. So if we go for counter 0 as you gave us a description a lot of rewiring, dissasembling the rack work etc is needed. Can you please be so kind and give us the registry addresses for the same operation but counter 1? I will  update you on the test.

Thanks again and best regards

Kirco

[JoeFriedchicken]

Hi Kirco,

Sorry for the confusion, please let me clarify a bit more about the internal trigger signals.

The TIO ASIC has 8 internal trigger lines (enumerated zero through seven) and 4 counter/timers (enumerated zero through three). The internal trigger lines are completely independent from the counter/timers: trigger zero is not associated with counter zero.

If you want to use an arm start trigger for counter one, then use this algorithm:

1. Program a route from the I/O connector pin to internal trigger zero (with registers TG_0_LevelEdgeReg and TG_0_CombinationReg).
2. Program counter one to use internal trigger zero as the arm start trigger (with register G1_Counting_Mode_Register).

[JoeFriedchicken]

I should make a small clarification: "0d0 - 0d39 will select the I/O pin of the same number" should read "0d0 - 0d39 will select the PFI of the same number."

In other words, in the TB_0_LevelEdgeReg register, the LESel field maps 0d0 - 0d39 to PFI 0 - PFI 39, not I/O pin 0 - I/O pin 39.

[Kirco · Accepted solution]

Hi and sory for the slight delay in my reply. It works and it works great thanks to Joe's description, and Joe, thanks for all your great help. I strongly appreciate that. Now we finally have also this option as we wanted it and it works great.

[HortonMA]

Joe,

I'd like to do this as well with one difference.  I'd like to trigger with an internal source.  How would I go about doing this?

Thanks Joe,

Mark Horton