03-15-2017 05:01 AM
I'm working on an Spartan 6 (xc6slx45csg324-2) Evaluation-Board and i'm trying to implement the AES3 Serial Digital Audio Interface from xapp1014.
The AES3 In and Outputs are connected like specified in the AES3-Spec. My Audiotest-System is a PrismSound dScope Series 3.
For the In- and Output Signals i connected an VmodBB-Board, two Oscillators with 24,576MHz and 100MHz.
At first I connected a 100MHz Oscillator and adjusted the seettings of the Rate-Detection Module etc. but that didn't work properly. Means the FPGA just worked with 48kHz.
Then I implemented an DCM and raised the Frequency to 150MHz. Now the FPGA syncs at 48 and 96kHz, but 192kHz is missing.
In iSim, the Code works well up to 192kHz Sample-Frequency. In ChipScope it doesn't.
After some research I saw that the Problem lies in the DRU-Module.
When the FPGA gets a 48 or 96kHz Signal, the DRU-Module samples the Bitstream right. That means the Data-Valid-Output gets high 3x while the Sync-Width, 2x for a "0" signal, 1x for a "1" signal.
The Sampling-Intervalls are calculated by the "min_hold"-Value.
At 192kHz I observed that the "min_hold"-Value sometimes gets too small. With a value that's too small, the bitstream gets sampled too often. So it happens that the Sync-Width of the AES3-Signals is sampled 4, instead of 3 times. Due to this, the Code can't see the Preamble-Sequences. With my setup, the min_hold Value sometimes drops to 4.
If I set the "min_hold"-Value to "5" it works just well and I get a clean AES3 Bitstream In and Out.
Has anyone had the same problem and a good workaround to share?
Thanks in advance,
08-09-2017 04:03 PM
I was able to confirm exactly what Sebastian had reported. At 192kHz the min_hold value in the DRU module gets set too low due to the smaller ratio of the system clock to the AES3 unit interval. In my test I was running a 120MHz system clock and when the min_hold value was set to 3 I saw the failure. Limiting the minimum value of min_hold to 4 fixed the issue.
It seems that the generation of the min_hold value could be made more robust - possibly by using a first-order filter instead of looking for a minimum value every 1024 AES edges. This is something I may investigate.
Good catch Sebastian!