cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
guillaumebres
Scholar
Scholar
617 Views
Registered: ‎03-27-2014

Zedboard - Adau1761 placement problem

Jump to solution

Hello,

I just installed the latest version of Vivado (2020.1), and have been investigating the Audio Codec (ADAU 1761) which I think is present on the Zedboard, the Zybo & even the Zc706 dev. platform if I remember correctly.
I am personnaly using a Zedboard.

I am facing issues when trying to route a default design around this audio Codec, regarding the I2S BitClock 'bclk' signal.

The BCLK signal reaches a 3.3V I/O bank, AC-GPIO2 <-> package pin 'AA6' to be precise: you can see it here, on page 9 of the zedboard schematic this matches my example design and my example XDC file. 

However, design implementation fails with:

[Place 30-876] Port 'adau_bclk'  is assigned to PACKAGE_PIN 'AA6'  which can only be used as the N side of a differential clock input. 
Please use the following constraint(s) to pass this DRC check:
set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets {adau_bclk_IBUF}]

I have never seen people handle the I2S clock signal as a differential signal, in any example designs. Usually people directly handle this signal (it's an input for us) directly in the I2S data receiver. Why am I facing this problem? 

Package Pin AA6 is cleary the correct one (schematic, and other people's demo projects).

I don't have placement problems other than this one.

I can see that Vivado 2020.1 calls the 1.4 revision of the zedboard (it's the latest I have seen so far). 

Any advice would be highly appreciated, thank you

gw.
Embedded Systems, DSP, cyber
Tags (3)
0 Kudos
Reply
1 Solution

Accepted Solutions
guillaumebres
Scholar
Scholar
510 Views
Registered: ‎03-27-2014

@surajc , all

I understand what is going on now.

So the clock bit from the audio codec, at least on the zedboard, is routed to pin AA6 which is "IO_L1_4N_T2_SRCC", ie. negative side of a regular 3.3V I/O (input in our case) SRCC Single Region Clock Capable, which is fine, only except that it's a negative side of a pair. It should have been routed to a positive side, in order to be used as a single bit clock. But that is not very important I would say.

The ref. design I am talking about used to be called "hamsterwork" something, people that have inquired the audio codec on the Zedboard probably know what I am talking about about. The audio data bus is an I2S bus, it's totally synchronous like SPI or I2C, one would expect

process (bclk)
   reg(pointer) <= i2s_data_in_bit; -- RX side, general idea
end process;

on the receiver side.

They don't have a process like that in the ref design for the I2S,

they use oversampling instead (which can be fine, we're not talking about super advanced stuff here anyway). Therefore bclk is never used as a clock signal in their design, it's just another I/O.

I discarded their I2S receiver and pretty much anything related to clocking in the ref. design because what they did at some point I would consider pretty poor design practice (I can elaborate on this but I will keep this answer short). That is the main reason why their design probably does not raise this warning, while mine does.

gw.
Embedded Systems, DSP, cyber

View solution in original post

3 Replies
surajc
Xilinx Employee
Xilinx Employee
564 Views
Registered: ‎01-30-2019
0 Kudos
Reply
guillaumebres
Scholar
Scholar
531 Views
Registered: ‎03-27-2014

@surajc ,

thank you for helping me out

at the moment I introduced the set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets {adau_bclk_IBUF}] local constraint. But how do you explain none of the adau1761 example designs require this command?

gw.
Embedded Systems, DSP, cyber
0 Kudos
Reply
guillaumebres
Scholar
Scholar
511 Views
Registered: ‎03-27-2014

@surajc , all

I understand what is going on now.

So the clock bit from the audio codec, at least on the zedboard, is routed to pin AA6 which is "IO_L1_4N_T2_SRCC", ie. negative side of a regular 3.3V I/O (input in our case) SRCC Single Region Clock Capable, which is fine, only except that it's a negative side of a pair. It should have been routed to a positive side, in order to be used as a single bit clock. But that is not very important I would say.

The ref. design I am talking about used to be called "hamsterwork" something, people that have inquired the audio codec on the Zedboard probably know what I am talking about about. The audio data bus is an I2S bus, it's totally synchronous like SPI or I2C, one would expect

process (bclk)
   reg(pointer) <= i2s_data_in_bit; -- RX side, general idea
end process;

on the receiver side.

They don't have a process like that in the ref design for the I2S,

they use oversampling instead (which can be fine, we're not talking about super advanced stuff here anyway). Therefore bclk is never used as a clock signal in their design, it's just another I/O.

I discarded their I2S receiver and pretty much anything related to clocking in the ref. design because what they did at some point I would consider pretty poor design practice (I can elaborate on this but I will keep this answer short). That is the main reason why their design probably does not raise this warning, while mine does.

gw.
Embedded Systems, DSP, cyber

View solution in original post