The input clock frequency of the axi_clkgen was changed from 200 MHz to
100 Mhz. Update the divider settings accordingly to keep the standard
default output frequency of 148.5 MHz.
The incorrect divider settings did not affect operation of the design since
software reprograms them at startup anyway, but changing them avoids the
following warning:
[DRC 23-20] Rule violation (AVAL-46) v7v8_mmcm_fvco_rule1 - The current computed target frequency, FVCO, is out of range for cell i_system_wrapper/system_i/axi_hdmi_clkgen/inst/i_mmcm_drp/i_mmcm. The computed FVCO is 445.455 MHz. The valid FVCO range for speed grade -1 is 600MHz to 1200MHz. The cell attribute values used to compute FVCO are CLKFBOUT_MULT_F = 49.000, CLKIN1_PERIOD = 10.00000, and DIVCLK_DIVIDE = 11 (FVCO = 1000 * CLKFBOUT_MULT_F/(CLKIN1_PERIOD * DIVCLK_DIVIDE)).
This violation may be corrected by:
1. The timer uses timing constraints for clock period or clock frequency that affect CLKIN1 to set cell attribute CLKIN1_PERIOD, over-riding any previous value. This may already be in place and, if so this violation will be resolved once Timing is run. Otherwise, consider modifying timing constraints to adjust the CLKIN1_PERIOD and bring FVCO into the allowed range.
2. In the absence of timing constraints that affect CLKIN1, consider modifying the cell CLKIN1_PERIOD to bring FVCO into the allowed range.
3. If CLKIN1_PERIOD is satisfactory, modify the CLKFBOUT_MULT_F or DIVCLK_DIVIDE cell attributes to bring FVCO into the allowed range.
4. The MMCM configuration may be dynamically modified by use of DRP which is recognized by an ACTIVE signal on DCLK pin.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
For the M2K standalone version we run the interface clock at a lower rate
to reduce the power consumption. While this is not necessary on the ZED
board we also run the interface at a lower rate for consistency.
Currently the video DMA on the ZED board uses the interface clock for the
data path as well. This is now too slow to support 1080p@60Hz so move it
over to a faster clock.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
At the moment the PS7 is using three PLLs to generate its clocking tree.
One for the DDR, one for the ARM and one for the IO. This allows to run all
components at their respective maximum clock and extract maximum
performance from all components.
With some slight modifications it is possible to trade maximum performance
for a reduction in power consumption by using the same PLL for all three
sets of components and disabling the other two PLLs.
The CPU is now running at 500MHz rather than 666MHz and the DDR memory at
500MHz rather than 533MHz. This reduces power consumption by ~125mW.
This is OK since neither of them is a bottleneck for overall system
performance.
In addition software will downclock the CPU to 250MHz when full performance
is not required.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The 200 MHz clock was only used as the IODELAY controller clock. Since the
design does not use any IODELAYs anymore this clock can be removed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The debug register logic for the DMA take up a fair amount of resources.
Disabling them frees up space in the FPGA and also helps a bit with power.
Since those registers are mainly useful in development and not so much in
production the change shouldn't have any visible external effects.
It is possible to re-enable the debug registers by setting DEBUG_BUILD=1.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The global reset signals are only asserted for a short moment during system
startup and deasserted during normal operation, which is the case we care
about for power analysis. Giving them a static switching probability
indicating that they are always de-asserted will yield better results for
power analysis.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The RX datapath has a lot of things (IQ correction, DC filter, ...) that
take up a lot of space which are all not really needed in this project. So
disable the RX datapath.
It was previously enabled because the ad9963 core did not perform
sign-extension on the ADC data signal when the datapath was disabled. But
this has now been addressed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
At the moment the register map fabric and DMA system memory side are
clocked by the 100MHz sys_cpu_clk. While this works fine that is a lot
faster than the clock has to run. There are only a few 100 register map
accesses per seconds at most and they are not on timing critical paths. The
penalty from clocking them at a lower rate is negligible for the overall
system performance.
The maximum clock rate for the DMAs is determined by the throughput
requirements. This is 200 Mbytes/s for the logic analyzer, pattern
generator and each of the DAC DMAs and 400 Mbytes/s for the ADC DMA.
The DMA datapath width is 64-bit so the required clock rates are 25MHz and
50MHz respectively. Some headroom is required to accommodate for occasional
bubble cycles on the data bus and the difference in reference clocks for
the converter and processing system.
The sys_cpu_clk is reduced to 27.8MHz which is fast enough for all but the
ADC DMA. For the ADC DMA a new clock domain running at 55.6 MHz is
introduced.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The MMCM generating the logic analyzer clock unfortunately consumes a
disproportionately large amount of power compared to the rest of the
design.
Replace it by sourcing the logic analyzer clock from one of the Zynq FCLKs.
The IO PLL is running anyway so the power requirement is much lower.
For the time being this means we loose the ability to source the clock from
an external pin. But that feature is not supported by software at the
moment anyway. We'll bring it eventually when required.
This changes reduces power consumption by roughly 100mW.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
We always have both ADC channels enabled and the cpack core takes up a fair
amount of space, so remove it for now. Might come back later when we really
need it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new axi_rd_wr_combiner module to ... the read and write DMA
interfaces into a single interface. This allows the AXI interconnect
completely optimize itself away and reduce the overall resource utilization
of the project.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
ad_cpu_interconnect will make sure to connect the clock and the reset of
the AXI interface. Remove the redundant manual assignments.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Rejeesh Kutty
Adrian Costina
Lars-Peter Clausen