cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
eldrick
Contributor
Contributor
640 Views
Registered: ‎07-24-2018

Bitstream to Bitstream Variability in Functionality

Jump to solution

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?

0 Kudos
Reply
1 Solution

Accepted Solutions
drjohnsmith
Teacher
Teacher
623 Views
Registered: ‎07-09-2009
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,

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>

View solution in original post

2 Replies
drjohnsmith
Teacher
Teacher
624 Views
Registered: ‎07-09-2009
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,

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>

View solution in original post

eldrick
Contributor
Contributor
572 Views
Registered: ‎07-24-2018

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.

0 Kudos
Reply