Forum Discussion

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

RTL viewer bug Quartus 13.1

Hi all!

There is a strange bug in my Quartus 13.1 Cyclone V E project.

I have a bidirectional 32-bit bus.

A few blocks connected to bidir bus.

If there are blocks, which use not all 32 of bidir bits, but fewer (for example 22 or 8,

as it can be viewed in attached file - test_bidir_1.jpg), then RTL Viewer reports an error and quartus exits after

clicking Ok. In another attachment block (test_bidir_2.jpg) uses all 32 bits and RTL viewer opens correctly. Also I've attached

vhdl + bdf files and screenshot of RTL and error view.

6 Replies

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

    You should raise this in a service request with altera mysupport.

    But you should really do the bidirectional tri states at the top level to translate the bidir signal into deiscrete inputs and outputs, not in each block. Tri state drivers only exist inside the pads for each pin, so each block cannot have it's own tri state driver. They may be converted to muxes in each block, and therefore use more logic than is really required.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Thanks a lot for your answer, Tricky!

    I understand that tristate drivers exist only inside the pads, but that concept works in my design.

    My aim is to use bidirectional bus to connect several slaver blocks. What can you advise in that instance?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    internel bi-directional signals get converted into muxes (ie. discrete in and out) so to make your code look more like the real hardware it is much better to have separate in and out ports to internal blocks with the tri-state at the top level.

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

    I understand bidirectional signals get converted into muxes.

    Could you please explain why should I separate in and out ports in internal blocks?

    As I understand if I don't connect bidirectional bus into I/O, but connect them to internal blocks,

    compiler can't implement 'Z' state and consider it like 'U' state.

    Why should I expect difference in project if I would separate inout ports into in and out?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    It should map fine, but I would consider it bad engineering practice to have an inout signal connected to several internal blocks. You want to try and map your code to the actual hardware as much as possible, and doing this means it cannot use the tri-states on the pins.

    It is also considered bad practice (or even forbidden) in many places to use inout ports at all (unless connecting directly to an external bus that requires bidirection ports), exactly because of the above case (impossible to use the tri-states, muxes are implied and the code doesnt map easily to the real hardware - although behaviour should match).

    It is always much clearer for other engineers to use separate in and out ports.