ADRV9002 FH-TDD solutions

Hello gstou,

You present us with an interesting use-case, however it certainly is possible to support your application.

The Automated TDD state machine that we provide as part of our SDK and TES implementations can be used to go from evaluation of the product all the way through to production, however it is always important to note that the Auto TDD State Machine exists on the FPGA, not on the device. While using our Eval setup (eval board and ZC706 or ZCU102) you can use the automated TDD feature to evaluate the products performance under auto TDD, as well as determine device timing requirements.

However, when migrating to your own custom platform, you're free to design your own Auto TDD state machine however you wish. If you write custom code to handle this custom state machine, your own APIs can be integrated with our own (not by modifying our SDK, only by modifying our produced sample code from TES). This method gives you complete control of the state machine's behavior, freeing you from the constraints put in place in our software. It's certainly not a trivial undertaking, but for your application it will probably yield the most satisfactory results.

To answer your questions about our Auto TDD state machine:

1. No, I'm fairly certain our state machine timings are fixed after initialization.
2. Again no, after initialization our TDD frames are fixed. As for assigning a GPIO pin to the autoTDD enable, I'm actually not certain. I've never seen this done nor heard of an application that needed it. I don't believe it makes the most sense either, as the autoTDD enable signal exisits on the FPGA platform, not on the device. Using the device to control it is similar to getting the platform to tell the device to tell the platform to enable auto TDD, which is a very roundabout way of doing it.
3. Handling enablement delays is among the harder parts of designing state machine timings. We provide two different guides on how to approach this issue:
   https://ez.analog.com/wide-band-rf-transceivers/tes-gui-software-support-adrv9001-adrv9007/w/documents/15627/automated-tdd
   https://www.youtube.com/watch?v=huufF5c_hOY&t=1s
   As to your second question, there's no real reason why you use a GPIO pin to control a DMA signal. The DMA is the control of data transfer to and from the platform. Essentially it's a second enable signal that you can use to avoid blank or useless data from being sent over Tx or read over Rx. It is essential to note that this signal is a platform signal, not a device signal. Just like before, using a GPIO to control this would be like telling the platform to tell the device to tell the platform when it should exchange data. Does this make sense?
4. For the reasons outlined above, it may be best to explore building your own state machine for your platform. You can experiment using the Eval platform, FH doesn't rely on Auto TDD to operate. once your desired setup is programmed, with hop tables loaded, you can control the Hop signal and the Enable signals manually, which also means you can design a block of code to control them for you.

I understand that I'm recommending a fairly large undertaking, but I do believe that investing in this custom state machine will lead to the best results for your application, rather than attempting to circumvent the limitations of our SW. Do let me know if you have any further questions in the meantime!

Best Regards,
Oisín.