Bitstream to Bitstream Variability in Functionality

[eldrick]

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?

[drjohnsmith · Accepted solution]

This has feeling of constraints.
Vivado runs till it meets constraints and stops,
If you have failing constraints, then the deisign may or may not work on hardware, next time you change something, the tools approach the deisng ina different direction and come up with a different set of logic.
which will if you have not constrained or have failing constraints, either fail or work on the hardware,

Bottom line, if you have none or in correct constraints, or you have failing constraints, then it does not matter if the design works this time on hardware , its still wrong and you need to sort out the falling constraints,

[eldrick]

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.