PDoA Sync Circuit timing question

Wireless Connectivity Ultra-Wideband
1

Question regarding the PDOA sync circuit of on PDOA beta kit.

The DW1000-Datasheet-V2.09, chapter 5.13 (External Synchronisation) This chapter discusses the minimum time required for the SYNC signal relative to XTAL1. On the rising edge of XTAL1, the sync pulse must be hi at least 10ns before and last at least 10ns after.

On the PDoA Kit Node Miscellaneous Revision 2v2, the clock buffer CLKIN is from a 38.4MHz crystal module. One of the output of the clock buffer goes to each of the DW1000 (XTAL1).

The other output of the clock buffer goes to a NAND gate and then to a flip flop clock input. The output of the flip flop drives the SYNC PIN on each Decawave.

My understanding of the circuit is when the clock transitions form high to low, the flip flop output is driven high until the clock transitions from high to low once more. Given a perfect 0 second propagation delay NAND Gate and flip flop then with a 38.4MHz clock (24ns period) then the SYNC output will stay high for 13ns before the rising edge of the clock and 13ns after the rising edge of the clock and therefore be within the timing constraints of Table 22 (min 10nS either side of the clock high transition).

BUT, NAND gates and flip flops in the real world have delays. For the NAND gate and flip flop used in the PDoA board the maximum propagation delays are 4.3ns and 5.7ns respectively. Therefore worst case after the clock transitions, the output of the flip flop may not transition for 10ns giving only 3ns remaining for the SYNC setup time which is far lower than the required minimum of 10ns.

What am I not understanding?

2

With a 26 ns period (38.4 MHz), you have only 6 ns allowance to transition the SYNC signal after 10 ns hold from the clock edge and 10 ns setup to the next one.

The variations in chip speeds with voltage and temperature make it virtually impossible to design a SYNC circuit that actually meets those requirements in all cases. For example, the 74LVC1G175 flop has a clock to output delay that varies from 1.0 to 5.7 ns, and the 74LVC2G00 varies 0.7 to 4.3 ns. How do you assure 10 ns hold with that uncertainty, 1.7 to 10.0 ns total delay?

Well, you can’t. So now what? You design a circuit that aims to get near the specs as best you can. In reality, the setup and hold times Decawave specify are gratuitously large so it actually works in practice even though you can’t design it assuredly to meet the specs by analysis.

The Decawave circuit on the PDoA kit could be simplified. The NAND serves to clock gate the flop, but that doesn’t really save any power since the NAND input is loading the clock buffer anyway. I’d simply delete the NAND gate and let the flop clock all the time. It won’t draw much power if the D input doesn’t change. The delay the NAND gate was providing can be achieved by using a resistor in the flop clock input, which is an RC delay using the input natural capacitance. Tune the resistor value until you get the SYNC edge right at 13 ns on average and you are all set and this will work well in actual practice.

I’d consider changing to 74AUP1G74 flop. Much lower power under dynamic conditions, about 1/3 the power. An estimated clock input resistor would be about 600 ohms to achieve the pulse location desired given the very small 1.5 pF input capacitance of the AUP parts.

You can do the SYNC circuit without any flop if you want. Simply output it from the processor, asynchronous to the 38.4 MHz clock, and it can be longer than one pulse width without issue. Yes, this violates the setup and hold times most of the time and there will be a chance the SYNC will not happen on the same clock pulse at each DW1000. But that is easily detected when you receive a packet and the RX-TIME will be 26 ns off, way more than is sane for a PDoA device with two closely spaced antennas. Then just SYNC pulse again until you get both DW1000s aligned. We’ve built devices like that with multiple DW1000s and it works fine, less than 5% of the time do you need to resync, and no added parts! Just need to add a little bit of resync code and you are all set.

Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com
+1 812 962 9408

1 Like