11-06-2019 11:31 AM
I'm currently running into bitstream-to-bitstream variability in the functionality of my hardware design and would appreciate input on the behavior I am observing.
I have a large design on a ZCU102 which includes a JESD204B RX and TX IP Core, a PL I2C Master to read temperature sensor data for telemetry, and block memories used as storage for filter coefficients. My vanilla design used the block memories as ROMs, initialized with an init file at synthesis - this design was fully functional.
Needing the coefficients to be configurable during runtime, I modified the design to use the block memories as true dual port RAMs, and added an AXI BRAM memory controller. Everything was working as expected, except I found that my system would hang after an indeterminate amount of time (1-60 seconds) due to the I2C Master being stuck at a "Bus Busy" state. I was surprised that modifying my block memory architecture would affect my I2C subsystem - in any case I implemented a fix to change inertial delays on the SCL and SDA lines (166 ns). My system failed to meet timing in some of the DSP pipelines but the change seemed to have fixed the I2C hang.
I then attempted a synthesis with a smaller inertial delay (100 ns) and met timing in all subsystems. However, testing this new bitstream shows that theJESD204B TX core fails to achieve PLL lock (despite the JESD204B RX core achieving PLL lock)! At this point I am thoroughly confused on why changes in certain IP parameters could affect other unrelated subsystems. Any thoughts?
TLDR: Changing BRAM structure affected my I2C subsystem, changing I2C inertial delays prevented my JESD204B TX core's PLL from locking. Why?
11-06-2019 12:44 PM
11-06-2019 12:44 PM
11-07-2019 09:11 AM
Realized I had left the JESD204B device clocks unconstrained with a clock frequency! Surprising how this has worked for so long and this hasnt been an issue until now. I've since added the constraint and will follow up. Thank you.