FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
5950 Discussions

Tristate bridge can't read data

Honored Contributor II

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. 

0 Kudos
3 Replies
Honored Contributor II

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.

Honored Contributor II

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. 


Honored Contributor II

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.