Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

Tristate bridge can't read data

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

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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.