User Profile
KianHinT_altera
Frequent ContributorJoined 3 years ago
User Widgets
Contributions
Re: LTC Connector DE10-Standard FPGA
Hi I'm really sorry for the long delay in my reply on this thread. You're still seeing the i2c device 0x53 which is the G-sensor as it is connected on I2C1 line (in the previous comment). On the connection diagram, you wont be able to toggle P14 as the R319 is marked as DNI (do not install) means it is not connected at all thus it is always low at pin14 of the 2x7 header. Instead you should probe this R306 resistor that connects to the pin 1 of TS3A5018, this is where your i2c2 switch and try your switching app When you mentioned you run your app and could see pin 7 of the 2x7 header toggling, this might be due to the HPS_LTC_GPIO now set to 1 (from your app) and toggles all NC -> NO , in this case if you look at the pin 4 (MOSI_SDA that is connected to pin 7 of the jumper) , you're most likely seeing the switching/toggling effect when you set HPS_LTC_GPIO = 1. Is your i2c external device connected to pin 9 and 11 of the 2x7 header? Thanks Regards KianRe: AXI violation on H2F interface of S10
Hi Chris, Based on your setup, I agree that probably that does not apply to your case. I'm wondering whether this is due to the width mismatch where you have the H2F AXI4 128bit while EMIF AvalonMM at 512bit. Most probably you will have the width adapter in Platform designer to handle the width needed (narrow to wide data pack , 4x 128 = 512bits) So happy path when every data in 128bit is aligned and packed into 512bit send to AvMM. The not so happy path is when issues starts occurs, these are some suspected areas 1. The 128bit to 512 bit width and burst adaptation logic can be stressed by unaligned addresses, narrow transfer size, sparse bytes that can flood the memory with many small transactions. Things to confirm: Retest with 64-byte-aligned, full-width transfers (and/or with DMA). If that stabilizes the bus while raw user-space texture copies don't, then we could confirm that adaptation + traffic shape path is the weak link here that causes the issue you're seeing. 2. Memory controller or interconnect backpressure where external memory interface or the soft interconnect is not accepting writes fast enough causing backpressure on the queue and eventually stops accepting new write address transaction. Things to confirm : At hang, are the Avalon wait-request and write-data ready stuck in a backpressure state? Does lowering write rate delay or remove the hang? Try capture the HPS-to-FPGA write-address, write-data, and write-response channels on the HPS-to-FPGA fabric clock, plus the Avalon write and wait-request signals on the memory side. 3. Similar to 2, is there any chance that write addresses/data are accepted faster than the write responses coming back eventually hitting the write limit and stops accepting new write all together. Things to confirm : Count accepted write addresses vs completed write responses at hang. Try setting maximum pending writes = 1 and see what's the behavior, is it stable or instantly stall? Thanks Regards Kian
