LabVIEW
NI SPDIF Input Module
Hello Falcon,
Are you compiling your FPGA code for a FPGA clock frequency of 80 MHz instead of the default 40 MHz? The timing values used in the pulse length decoding are based on a 80 MHz clock tick. At 80 MHz the pulse lengths in 48 kHz S/PDIF should be around 13, 26, and 39 clock cycles. Therefore the code uses cutoffs of 20 and 33 clock ticks to differentiate between the three different pulse lengths.
What are you using for your S/PDIF signal source? What is the purpose of your application?
Since the original code that was developed a couple of years ago, we have moved the example to use the LabVIEW FPGA Single Cycle Loop which simplifies and reduces the code a bit. I have attached a LabVIEW 8.0 project with the updated files.
I have two suggestions to try.
In regards to developing your own SPDIF reader; when you only measure the pulse lengths you get the proper readings, but as you add more code to the loop the readings changes and become incorrect. This is most likely a result of the extra code slowing down the loop and causing it to not run fast enough to read each pulse. Using a regular While loop in LV FPGA, each function block you use takes up at least one FPGA clock cycle. In addition the While loop has an overhead of two FPGA clock cycles. So assuming you have a While loop with 5 consecutive functions it will take 7 clock cycles to run each iteration of the loop. If you were to use this loop to measure the pulse length it would give you a measurment with a resolution of 7 ticks, i.e. the pulse length would be 7, 14, 21, 28, etc. As you add more code to this loop the length of each iteration increases and the resolution of the pulse width decreases. In order for us to adequately measure the width of the pulses in the SPDIF signal we need to have a loop iteration time of less than 6 or 7 clock cycles (about half of the shortest pulse we want to measure). This is the reason why the original SPDIF code is set up in three different loops and the first loop that measures the pulse width is kept very simple. It also uses pipelining to further reduce the time of each iteration and we compile the FPGA for a 80 MHz clock rate to get more clock cycles per pulse. I think in your code as you add the Case structure and additional code, you are increasing the loop time above the necessary limit.
One 'easy' solution to this problem is to use the Single Cycle Timed Loop (SCTL) instead of the While loop. This loop is processed differently by the compiler so that all of the code inside the SCTL is executed in one clock cycle. (The SCTL was not available in LV FPGA when the original SPDIF code was developed, otherwise we would have used it then.) So in the updated SPDIF code we use the SCTL and can include all of the SPDIF processing in one loop. There are some limitations on the code that can be included in a SCTL. Information about the SCTL and optimizing FPGA code can be found in this prsentation (Advanced FPGA Programming). I think if you convert your code to the SCTL (right click on the While loop and chose Replace with Timed Loop) you should be able to measure your signal correctly.
Getting back to the SPDIF code I included on my last post. This code does work correctly on my end with a SPDIF signal coming from a Soundblaster sound card. This signal has two raw audio channels with 20-bit data per channel. The 4 AUX bits in the SPDIF packet are not used. I have logged the data to file and can load the file using the Reader VI included in my last post. To play the sound back on a regular sound card in LabVIEW I have to resample the data to 44.1 kHz and then use the upper 16-bits of the 20-bit audio signal. I'm attaching a sample file of logged data on this post that you can open and play back using Read SPDIF Data File.vi.
Is there a chance that the audio data in your signal is formatted differently? Could it be using 5.1 or 6.1 encoding with DTS or Dolby?
If the question is related to SPDIF, please post it in this thread. If it is an unrelated question then please start another thread. By posting this information in the discussion forum, hopefully other people reading here will also benefit and may not have to post similar questions in the future.
Is there a chance that you can take a picture of the raw signal (oscilloscope style) and post it, or can you collect a binary file of the raw data in your signal that is generating the noise you hear and post it? The image of the noise signal is not detailed enough for me to be able to tell much from it.
Message Edited by Christian L on 12-12-2006 09:02 AM
