New Contributor
Regular ContributorHello Sumanth,
I am sorry we only have devkits to try.
10CX105YF672I5G - working
10CX150YF672E5G - not working
The only difference is
operating temperature Industry grade (-40'C to 100'C) is working
operating temperature Enhance grade (0'C to 100'C) is not working
From your statement, if you waited approximately 300 µs after busy deassertion, reads and writes work correctly.
So, it is not the IP is not working at all. It will be working correctly if you give some buffer around 300us after busy signal deasserts.
Is this correct?
If you give 300us buffer after busy signal deasserts, will it impact your design implementation?
regards,
Farabi
New ContributorHello Fabri,
Yes, adding ~300 µs delay after the busy signal deassertion does not cause any problem to my project from a functionality or performance perspective.
However, our main concern is understanding the actual root cause of this behavior. Specifically, we are trying to determine why there is a difference between the two part numbers (10CX105YF672I5G – industrial grade working vs. 10CX150YF672E5G – enhanced grade requiring delay), even though the functionality should ideally be consistent.
At this point, we cannot rely on a fixed or “magic number” like 300 µs without a clear technical justification. For a robust design, we need proper guidance on:
What is internally causing this delay requirement
Whether this behavior is documented or expected for certain variants
If there is a recommended way (e.g., status check or handshake) to safely determine readiness instead of using a fixed delay
Could you please provide proper direction or clarification on this?
Regards,
Sumanth S
