Audio of ad7611 and ad9889b

There are so many modes of audio port AD7611 can output,I'm using the I2S TDM mode now(audio data output from pin ap only),It can output 7.1 and up to 48k(24bit) per channel by reading the datasheet.

It confuses me a lot,the audio mode is decided by the source,If the source outputs higher than 48k(24bit) per channel,for example it's 192k or 88.2k,How AD7611 deal with it?It will delect some words and output 48K per channel?

Can AD7611 output 7.1 and higher than 48k(24bit)?if it dose,how I must do with my PCB?

AD9889B:

32k,44.1k,48k,88.2k,96k,176.4k,192k are all good for ad9889b,Those modes need different frequency of audio clocks,I use plls in FPGA to regenerate the audio clocks,But I find that FPGA can't generate exact freqency of audio clock,for example:AD9889b needs 12.288MHz for 192k,But FPGA only give 12.289MHz,Can AD9889B work?

The 7611 LLC output clock is just the pixel clock rate and is derived directly from the incoming TMDS clock from the source. It is a one to one relationship. The 7611 generates an internal 10 * LLC clock to receiver the 8B/10B stream. The ADF4351 can generate 156.25MHz with jitter ~= 300fs. This should be good enough to use as a clock reference for the serdes generator. You can use the ADF4351 tools to determine the correct parameters for the ADF4351 to do this.

Issue #2: How to package a video frame for serdes transport?

For 1080p60, a frame comes in every 1/60 of a second with a pixel clock of 148.5MHz. You will need to put each frame in a packet so the serdes receiver knows how where start of frame is so it can recreate the 1080p60 format. This packet could be built on the fly to reduce buffer requirements. The 1080p60 blanking intervals contain infoframes and audio packets. I assume you will want to transport these over the serdes link also. Check out the HDMI specficiations, Operating Modes Overview section to see how the audio and infoframes packets are placed in the blanking areas. This will change you calculations a bit.

For this application there's no way to avoid some buffering. Remember the input and output are fixed timing formats which are not a integer multiples of the serdes rate. Variable line lengths are one possible way to fix this.

I found that AD9889B need a SCLK to drive serial data to audio port,the frequency of SCLK must equal to 64*fs,if I want to give ad9889b 192K(24bit) audio,FPGA must drive SCLK running at 12.288MHz,what do you mean the FPGA should not need to generate a 12.288MHz clock?

By reading the datasheet of AD9889b,I found that all modes of audio port must be fed by a fixed times of fs(32 times on standard I2S or 64 times on all other modes),It's hard to derive the TMDS clock to get the exact SCLK,Does the FPGA must make frequency of SCLK right?

If the FPGA does not generate a 12.288MHz SCLK,and drive audio serial data by a fixed SCLK,Does adjusted the number of every L/R channel work?But the datasheet sign out it must 32 cycles or 64 cycles,I'm confused.

The AD1939/ADAU1966 might do what you are looking for. If you only need to generate SCLK & MCLK then the FPGA should be able to do that else there are other chips that can generate those. Just google "audio clock generators"

I've read datasheet of AD1939/ADAU1966 both,but still be confused,In my projiect,they do have a fixed relationship between audio clock and video clock(base on the data band),but their relationship is very complicated.

For example:there must be 534 audio samples in every vertical video when audio fs=32k and video frame rate=60,this might be very strange and be caused by may others reasons of my project.

That why I need a chip to regenerate the audio clock for FPGA.

I think there are two ways to do this in general:

1:A chip which can lock to the Vsync signal and generate a fixed number of clock cycles between rising edges of Vsync.

2:Convert digital audio to analog,then use a audio clock(related to the video clock) to convert analog back to digital.

Maybe I'm wrong,I'm still a learner in the first stage.

Maybe the FPGA must add or delect somewords in my project no matter how hard to try to recover the audio clock.

I want to find a pll which can lock to pixel clock of ADV7611 and output a 156.25MHz clock,and the output mustbe a clean clock,because it's used to drive serdes.

Now I want to use a pll to lock pixel clock of ADV7611 and use the output of pll to drive serdes(transmitter),there are so many kinds of frequencies of pixel clock depending on the resolution of the source,but the serdes must be drived by a fixed and clean clock.

I want to know the parameters of pixel clock,actually ±50 ppm was appeared in the datasheet,it's very impotent.and I want to know the parameters of jitter and skew,I didn't find them in the datasheet.

could I ask a simple question?Will the input clock of pll cause the output clock more jitter and skew?

By the way,I do trust ADI,and could you please recommend some ICs to me?Maybe ADI's is the best.

I've read ADF4002 and ADF4360-9,ADF4002 is more complicated in my oppinion,I have to build the external loop filter and VCO if I use ADF4002,but it's a very truble thing to pick up these parameters.So I decide to use ADF4360-9 to test first.

There are many tested results to be signed out with frigures in the datasheet of ADF4360-9,the freqencies of PFD are all about 1MHz and the jitter of output clock is exceptable.How about the jitter is when the frequency of PFD runs at about 60KHz?Did you tested that situation before?

I do know higher frequency of PFD can cause higher performance to reduce jitter on output,The situation of my project was talked to you earlier,can the serdes be drove by the output clock of ADF4360-9 and work normally?

I know the situation is very special and cause fewer options,if ADF4360-9 can't do this,can anyothers do?

Can you specifiy the input clock frequency to the PLL, I may have missed it in the preceeding messages, I understand that you wish to generate 156.25Mhz, but I am not clear on what input frequency is available for the PLL, can yo uadvise?, Regards,

There are so many kinds of frequencies of the input clock,which depend on the resolution of the source.adv7611can support hdmi and VGA,we planed to pass through both of hdmi and VGA from adv7611 to ad9889b,and use serdes to connect the transmitter pcb and receiver pcb the serdes runs at 3.125Gbps which is drived by a 156.25MHz clock.

For saving the area of pcb and the cost,we don't want to use DRAMs in this project,that why I want to lock the pixel clock of adv7611 to 156.25MHz.

Our product will be used to transmit video and audio for a long distance,there will be some errors on the line,and there is not any standard interface protocol which runs at 3.125Gbps and has valid band above 95%,so we have to design the interface by ourselves .it is a good way to transport video line by line and one line time of serdes equal to one line time of adv7611.

Sometimes one line counter of serdes do have division with one line counter of adv7611,and the others does not,the worst case is that I have to send HSYNC to PFD,that's why I talk about the frequency of PFD running at about 67Hz.

Attachments

By the way,the frequency of pixel clock of adv7611 is between 25MHz to 150MHz,if the pixel clock of adv7611 is not connected to the refclk pin,the pixel clock can be divided by the FPGA.if it is directly connected to,the input frequency is between 25M to 150M.these two ways are all allowed on my pcb.

1) Is 3.125Gbps the target frequency? Not the absolute must have frequency. FPGAs, like the Spartan 6, have a Gigabit Transceiver with data rates up to 3.2Gb/s. This doesn't mean it has to run at 3.125Gb/s. Your link could run at something close to 3.125Gb/s.

2) HDMI transceivers are serdes devices with conversion ratios of 8 bits using 8B/10B encoding. Since video pixel rates range anywhere from 13.5Mhz to 162MHz, the HDMI clock is adjusted to handle whatever is feed into it. It is not a fixed frequency.

3) HDMI has a minimum clock rate of 25Mhz. When CVBS with a 13.5Mhz clock rate is encoded, the HDMI transmitter will do pixel repetition to get the effective clock frequency above 25MHz (or to 27MHz). The receiver will then drop every other pixel and output the correct 13.5Mhz video stream.

4) Although the HDMI clock rate is equivalent to the pixel rate and since the transceiver does 8B/10B encoding the data rate is 10 * pixel rate, i.e. VGA60 --> 25.175MHz * 10 --> 251.75MHz.

In my opinion your serdes bit rate needs to be 25.175MHz * 24bits * 10B / 8B --> 755.25MHz. You could run your serdes at 755.25MHz or do 4x pixel repetition rate and run the serdes clock at 3.021Gbps.

Now lets assume that you are required to run at exactly 3.125Gbps. Can you find a PLL to generate exactly 156.25MHz? Yes, however the multiplier will be a fractional value which will cause problems when trying to figure out how to encode the video stream. As an example for VGA60 the multiplier would be 3125 / 25.175 --> 12.909. So for every incoming frame you could transmits 12.909 frames in the same time interval. Basically you would have to capture a frame, put a little wrapper around it and transmit it over the link. The receiver would just have to reverse this process. This just make handling the video data a bit more complex. Just capturing a VGA60 frame requires 640 * 480 * 24 = 7.3728Mb = 921.6 kB of memory space. Using a 12x pixel repetition might help if you could guarantee that the receiver would know how to throw away 0.909 of a frame and generate the correct output timing.

It's a so hard work for me to explain how I want to run a 3.125Gbps serdes, the hardest thing is not technology but the English!i'm very sad for that.

In spite of this,I still try my best to tell the situation.

I want to transport the source(hdmi/VGA) to destination without any change to resolution and frame rate,and must support the 1080p60 RGB resolution and others resolution,1080p60 RGB is the highest one. it takes almost 3Gbps valid data band while transport 1080p60 RGB. I counter it like this:

1920*1080*24*60=2.98Gbps

The bit width of serdes's user logic interface is 20bit,if I want to use serdes to packet this and don't use DRAM on my PCB,I think I must transport 2200lines to the serdes link and every line time of serdes are equal to 2200 cycles of pixel clock.

1920*24*20=2304

And

3125000000/60/1125/20=2315

It looks like good.

If the pll can output a 156.25MHz clock cleanly,i think every thing will be Ok.because I've counted every resolution before,the o/p of pll has some ppm offset than exact 156.25MHz.if serdes can except this,every thing will be ok.

That's my opinion earlier.

Now I know that maybe a dead way,the data sheet of FPGA did not tell this parameter,so I do not know how many ppm offset will cause serdes out of work.maybe I must test this.

By the way,I am using altera's FPGA,the highest frequency of serdes is 3.125Gbps,I have no choice.

From your calculation 1920x1080x60x24 = 2985984000 = 2.98Gbps. Now the link you have is only 20 bits wides so you are trying to put 24 bits RGB into a 20 bit input. The only way to do this is to interleave the data as it is presented to the 20 input and up the data rate to 2.98Gbps * 24 / 20 = 3.58Gbps. This is over your 3.125Gbps goal.

1080p60 does not have to be transported as RGB. It could be transported as YCbCr 422 color space. A slight lose of color information but it works well. You would have 8 bits of luma and 8 bits of color per clock giving 1920 x 1080 x 60 * 16 = 1990656000 = 1.99Gbps. Now if you do 2x pixel repetition and with the 20 bit interface --> 1.99Gbps * 2 * 16 / 20 = 3.184Gbps, a touch over your goal.

One thing you are forgetting in these calculations is the blanking interval. 1080p60 has a pixel clock of 148.5MHz. 1920 * 1080 * 60 = 124416000, so the blanking overhead is (148.5 - 124.4) / 148.5 ~=16%. This blanking interval contains infoframe blocks and audio. Regardless the output must have the right timing else the monitor will not recognize it as 1080p60.

This is why I brought up the variable serdes clock and it being integer locked to the pixel clock.

You may have to test whether the PLL has low enough jitter for your application.

I didn't expain that clearly enough,I didn't packet all the pixels(2200 pixels per line) to 20bit serdes link but just 1920 pixels per line,it looks like:

1920*24/20=2304

If 20bit serdes link can just packet 1125lines and the lenght of per line >2304 clock cycles,it will do it right.

If serds runs at 3.125Gbps,then one line lenght is:

3125000000/60/1125/20~=2314.814814814

then I decide it 2315 per line.

the offset ppm of clock is:

((3125000000-2315*20*1125*60)/3125000000)*1000000~=-80ppm

the audio data and other information are packeted into the blanking lines.If I packet enough ANC information into just one special line,the receiver can recognize them and recover video format exactly.Yes,I'm doing it like that.

the audio data comes so slowly,and I can use some block RAM to deal with it.I also counted it earlier:

one channel:48K*24/60=19.2Kbit

eight channels:8*19.2=153.6Kbit

The FPGA can store this easily and don't need DRAM.

any other resolution ratio can count like this.

But it still has some problems:

1:I must find a pll which has low enough jitter for serdes,just as you said.

2:The offset of the output clock of pll might change while the resollution ratio changed.the offset value maybe above 200ppm,it's such a big offset may cause serdes out of work.

My boss don't give me enough time to test that,so I have to quit.

I almost forget to tell you my system doesn't have a feedback link from the receiver to the transmitter,if make serdes running at dfference speed when resolution ratio changes,the receiver will lost synchronization and can't capture it again.maybe the receiver can capture it again by scanning every possible speed that serdes could transmit,But that must cost a very long time,and may cause my system more complicated.The simple way is just let serdes running at a fixed speed,maybe a few ppm offset than the fixed speed.then receiver can use a fixed frequency of clock to drive serdes(receiver side).

At first,I want to make an opology to you all,maybe it's not a impolite way to ask so many questions under just one title.I'm very sorry for that!deeply.

The 7611 uses a pll to lock TMDS clk at first,then generates LLC to the outside.I want to know the relationship between the output clock of pll(inside 7611) and the LLC.

Is LLC just divided from the output clock of pll(inside 7611)?if there are some noise on TMDS clk lines,what will happen to LLC?

Becase I want to define a protocol of interface which works like this:

at first,detect the vsync signal of adv7611 and use serdes clock to count and learn how many cycles passed between two edges of vsync,then decide the most lines lenght.for example:

1080P60:

frequency of pixel clock:148.5MHz

frequency of serdes clock:156.25MHz

I assume these frequencies are all perfect(zero ppm offset and no jitter).

1125*2200/148.5=1125*N/156.25,then N=2314.814814,Then I could decide 2315 cycles on 1124 lines with a special line on serdes interface.the special line will have 2106.6666667 cycles base on the calculation.Now the special line maybe have 2106 cycles sometimes or 2107 cycles on the others times.

Sadly, those frequencies are not perfect,So I must test it before working on it in my software. and you mentioned that the LLC is an adjusted clock,and the 156.25MHz clock has some jitter and skew on it.these reasons may cause more possible number of cycles on the special line.But it must have a range.

I can packet information to serdes interface like this:

some head key words at the beginning of one line,then followed by others valid words.then another line...and so on.

One frame has one special line which lenght is not a fixed number.But if it has a just small range,I think every thing will be fine.The only question is how to decide this range,±3cycles?or any others? this range is decided by the jitter and skew of pixel clock and 156.25MHz clock.156.25MHz clock maybe provided by a low jitter and skew crystal oscillator(±50ppm).Could you give me some suggestions?

The 7611 LLC output clock is just the pixel clock rate and is derived directly from the incoming TMDS clock from the source. It is a one to one relationship. The 7611 generates an internal 10 * LLC clock to receiver the 8B/10B stream. The ADF4351 can generate 156.25MHz with jitter ~= 300fs. This should be good enough to use as a clock reference for the serdes generator. You can use the ADF4351 tools to determine the correct parameters for the ADF4351 to do this.

Issue #2: How to package a video frame for serdes transport?

For 1080p60, a frame comes in every 1/60 of a second with a pixel clock of 148.5MHz. You will need to put each frame in a packet so the serdes receiver knows how where start of frame is so it can recreate the 1080p60 format. This packet could be built on the fly to reduce buffer requirements. The 1080p60 blanking intervals contain infoframes and audio packets. I assume you will want to transport these over the serdes link also. Check out the HDMI specficiations, Operating Modes Overview section to see how the audio and infoframes packets are placed in the blanking areas. This will change you calculations a bit.

For this application there's no way to avoid some buffering. Remember the input and output are fixed timing formats which are not a integer multiples of the serdes rate. Variable line lengths are one possible way to fix this.