- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a problem with a tristate bridge which intefaces between Nios and a few ram devices external to the sopc system.
I can correctly write data to the devices but I can't read anything: reads always return all ones. Data is correctly driven onto the bus. I SignalProbed the the_tristate_bridge_avalon_slave|internal_incoming_tristate_bridge_data [*] lines and I see that data levels are correct up here. The problem seems to be in bridging data to Avalon bus. The strange thing is that I copied the design from a former project where everything worked fine: I simply changed something inside the sopc; anyway the tristate bridge module is the same as before, including tristate devices base addresses. Any ideas? Thank you in advance. CrisLink Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could it be a timing problem? If you didn't specify the correct number of read wait states for your external components, the data could be correct but arrive too soon or too late.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Daixiwen,
The same configuration always worked in the previous project, and I changed it recompiled a lot of times in the past. Now I simply copied that project, changed something not related to the bridge and recompiled for a new hardware. Moreover the current target has a better speed grade (-6 vs -8), so I expected it would be even less critical. Am I right supposing this? I will now follow your advice and I'll try to increase the wait states, in order to test if the problem is here. Regards- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I eventually found the problem.
The hold time was nearly zero: when tristate bus deasserted rd signal the data was immediately removed from the bus; that's because the device was actually onchip ram and not a real tristate slave. Indeed the problem was triggered by the faster device: the previous one probably introduced a small hold time which has hidden the problem until now.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page