FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6359 Discussions

Tristate bridge can't read data

Altera_Forum
Honored Contributor II
1,015 Views

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. 

Cris
0 Kudos
3 Replies
Altera_Forum
Honored Contributor II
298 Views

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.

0 Kudos
Altera_Forum
Honored Contributor II
298 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
298 Views

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.
0 Kudos
Reply