2
\$\begingroup\$

I have a digital audio source that is basically I2S. I need to run the FPGA at the exact clock as the I2S provides. I've got four such inputs required, but I am assuming that the clocks are the same.

Is there an input on the Arty Z7 board that works as an external clock? If not, is there a dev board for zynq that does? Any pointers to how to configure that in the vhdl?

Update: maximum sample rate is 384Khz. maximum bits per channel is 32. maximum channels is two. Consequently, maximum clock is 24MHz. Max z7 clock is ~100Mhz? I do not believe that this is a high enough multiple to avoid clock inaccuracies on the output (but would be happy to be wrong). This is an audiophile application and avoiding jitter is very important.

\$\endgroup\$
  • \$\begingroup\$ As far as I know I2S provides you with a clock. But the normal procedure is to transfer the data to an internal clock of a much higher frequency so you have lots cycles to do any processing. \$\endgroup\$ – Oldfart Nov 21 '19 at 5:50
  • 1
    \$\begingroup\$ Could you explain what you're trying to accomplish a bit more? Is the idea to mix the 4 inputs together to produce one output? There are clock capable pins on U18/U19 as noted in page 9 of the schematic (MRCC stands for mult-region clock capable). These are brought out to JA3P/JA3N. FYI, the max frequency is 464MHz for a -1C speed device based on page 52 of the AC/DC switching datasheet. \$\endgroup\$ – ks0ze Nov 23 '19 at 20:50
  • \$\begingroup\$ Thanks for question. I need to read in I2S and then down sample it to a lower frequency. The lower frequency will be an exact multiple (1/2 or 1/4) of the I2S clock. There are four I2S clocks, but I believe the have a common source. The important issue is the clock, not how many inputs there are. Would have the same problem with just one input. \$\endgroup\$ – jamie Nov 25 '19 at 22:38
  • \$\begingroup\$ Did you look at which pins the I/O inputs are connected to and then see if the chip tells you which pins can be used as clock inputs? \$\endgroup\$ – user253751 Nov 26 '19 at 11:15
  • \$\begingroup\$ @jamie does my answer within your bounty period meet your needs? \$\endgroup\$ – user2943160 Nov 30 '19 at 22:59
1
\$\begingroup\$

Yes, there are pins available on the Arty Z7 that can be used as native clock inputs to the PL fabric. Page 9 of the schematic shows the pin names in each of the banks of the PL used in the design. This Xilinx Forums question about SRCC and MRCC pins gets to the necessary information: the pins labeled SRCC and MRCC are clock input capable pins, some of which are routed directly to user-facing pins on the Arty Z7.

Since you're after external IO, you'll probably use the PMOD or Arduino headers on the Arty Z7. The PMOD pins are prefixed with JA and JB while the Arduino headers use the prefix CK_IO. Assuming single-ended clock inputs for your I2S-like implementation, you have these pins available:

  • IO_L11P_T1_SRCC_13/U7 - CK_IO29
  • IO_L13P_T2_MRCC_13/Y7 - CK_IO37
  • IO_L14P_T2_SRCC_13/Y9 - CK_IO41
  • IO_L12P_T1_MRCC_34/U18 - JA3_P

Of course, other boards will have similar IO features. Depending on your FPGA fabric, processor, and IO needs, a different board will be an option.

For more details from Xilinx, see:

  • UG472 (v1.14) July 30, 2018 section "Clock-Capable Inputs" pg 30 and onward, explaining how to use these inputs
  • UG475 (v1.18) July 16, 2019 "Table 1-12: 7-Series FPGAs Pin Definitions (Cont’d), Other Pins" pg 30-31 providing the definitions for the pin name abbreviations

As for configuring this in VHDL, you'll be using this as one of the clock domains in your design. Your pin assignment constraints will need to place the input clock pin in the correct location given the above information and your choice of how you're connecting. As for the design, it will depend on whether or not your clock input and output rates are constant or dynamic and continuous or discontinuous. If you're looking for the most flexibility, I would suggest having a constant-clock resampler/custom-DSP running on one of the board clocks with FIFOs to/from the different precise and ratio-frequency IO domains.

| improve this answer | |
\$\endgroup\$
5
\$\begingroup\$

If the frequency is low (which is usually the case for audio applications), generally what is done on FPGAs is to use clock enables. The idea is to detect the edges of the input signal with a fast core clock and generate single-cycle pulses. Then use those pulses to sample/latch in the input data and control internal operations. With that setup, there is no need to use a specialized global clock capable input pin to supply the clock. This also means you don't need to deal with clock domain crossing because all of the logic is in the same clock domain. The internal clock can also be much faster, enabling pipelined processing and even time-interleaving processing of multiple channels using the same logic.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Are you saying that "No, you cannot use an external clock"? \$\endgroup\$ – jamie Nov 22 '19 at 17:24
  • \$\begingroup\$ S/he is saying "don't bother." \$\endgroup\$ – user253751 Nov 26 '19 at 11:13
1
\$\begingroup\$

To elaborate on your external clock idea: of course it's possible to use an external input as a clock, it just makes very little sense doing so for audio, unless you can use this clock for the whole design. If you implement a digital circuit with two independent clocks, you will need to create a block which transfers data between clock domains. Such transfers have an inherent problem known as metastability which essentially means if two independent clock edges arrive with a certain timing, they will violate the setup/hold times on your triggers, which can then output an uncertain logic level until the next clock pulse.

As a result, your circuit will never be 100% reliable, and you will have an MTBF (mean time between failures) metric associated with your inter-domain data transfer. To get a working design, people increase this MTBF to a high enough value: 1 failure per billion years sounds acceptable, doesn't it? Increasing MTBF is done by chaining several synchronization stages of flipflops in a sort of FIFO, so it has a price in terms of resources used to implement the flipflops, and the latency in data transfers.

Sampling the clock pin (as @alex suggests) has the same metastability problem: if the edge arrives at an unfortunate time, you can end up missing your single-cycle pulse, or generating two pulses instead of one. However, the problem will be much less visible in the first place, since only 1 bit is affected, and the cost of dealing with it (if needed) in terms of resources will be proportionally smaller: in your case, 4 times as small compared to the 4 data inputs.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Doesn't it make more sense? The audio data is generated with a specific clock, which is supplied. It is this clock that I am proposing to use for the down sampling. The output clock must be exactly 1/2 or 1/4 of the input clock. For example, if the input is running at 88199Hz and we try to perfectly clock the output at 44100Hz, then we're one sample short. We would need to run the output at 44099.5Hz. That's just a simple clock divide, right? \$\endgroup\$ – jamie Nov 27 '19 at 19:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.