Forum Discussion

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

Cyclone IV GX PCIe SOPC design

Hello all,

First I would like to inform you that I am new to this forum as I am to FPGA development.

I am trying to create an FPGA based PCIe endpoint device using Altera's Cyclone IV FPGA Development Kit. The design also includes a NIOS II processor instance and some memory mapped peripherals. I successfully generated the SOPC based system, all configurations are correct ( at least I hope they are). I know that I need to instantiate the SOPC generated entity in a top level design file and because my VHDL knowledges are limited I choose the easy way (at least I think this is thea easy way ) using a schematic entry to define the top level design file and instantiate the SOPC generated system and other needed componenets.

My problem is that I cannot see the PCIe device after loading the SOF into the target board. I think my problem is due to some unconnected or improperly connected signals to/from the PCIe compiler block in my SOPC design. The connections I use are as follows (attachment contains pcie compiler part and its connections):

IN:

- fixedclk_serdes -> 100 Mhz ( driven directly by an onboard clock source)

- pipe_mode -> connected to '0' (Virtual Pin)

- reconfig_clk -> connected to '0' (Virtual Pin)

- reconfig_togxb [3..0] -> connected ro '2' (Virtual Pins)

- refclk -> 100 Mhz (settings in PCIe compiler match witch clock sources)

- rx_in0 -> RX pins ( I use PCIe x1, both differential signals are properly connected )

OUT:

- tx_out0 -> TX pins

All other pins are defined as Virtual pins. Searching through the forum I found a post with a similar problem and the solution was found in AN532 where one was adviced to connected reconfig pins and pipe_mode unfortunately it doesn't work ( at least not yet ).

Please advice me if this is correct or if there are other unconnected pins which should be connected.

Thank you !

3 Replies

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

    Good luck, this is one are where the documentation is simply not good enough.

    Come on Altera, sort this out.

    :mad:

    I ended up working through a few example builds trying to derive a list of rules as to what should be connected and what shouldn't, but these

    weren't all consistent.

    There should be explicit rules in the user guide as to what all the ports should be tied to, or QSYS shouldn't expose them to the implementation victim.

    IMHO.

    Nial.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Guys, thanks for your posts and I agree with you that Altera didn't do its best to provide a well structured or sufficient documentation for a rapid hands on experience.

    Meanwhile the problem was solved ! The problem was the lack of a RESET signal routed into the PCIe block.

    Here is the solution, maybe there are others who can benefit from it. I will describe only the mandatory connections:

    INPUT connections:

    -> fixedclk ( 100 Mhz clock, NOTE: it must be derived from a source other than the free running PCIe clock ( here refclk ))

    -> reset_n ( reset source for the PCIe hard IP core (active low) it should be bound to high or to an external reset source )

    -> pipe_mode ( connected to '0' (Virtual Pin) )

    -> reconfig_clk ( connected to '0' (Virtual Pin) )

    -> reconfig_togxb [3..0] ( connected to '2' (b0010) (Virtual Pins) )

    -> refclk ( 100 Mhz (settings in PCIe compiler must match clock sources) )

    -> rx_in0 ( RX line(s) - this design uses PCIe X1 )

    -> others -> unconnected

    OUTPUT connections:

    -> tx_out0 ( TX line(s) - this design uses PCIe X1 )

    -> others -> unconnected

    On the forum some remarked that it is needed an external reconfiguration block (ALTGX_RECONFIG) , it seems that this is unnecessary and using the constant values described above for the reconfiguration block pins should be enough.

    Hope this helps.