Forum Discussion

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

Qsys16 Custom Peripheral Problem

Hi there folks,

I recently posted a problem I have been having to integrate a custom peripheral into Qsys. The problem seems to manifest itself in both 15.1 and 16. I am using a MAX10SAE144GES device.

Basically I am trying to create a Qsys peripheral from the vhd file attached, that will acts as a basic I2C master.

1.In order to do this I create a new component within qsys, and then analyze the file. and set up the corresponding signals and interfaces that require my attention (ie those not automatically assigned).

2.I then finish this and Qsys creates the HW tcl file I have attached.

3.I then put my new component into my qsys system, which I have also attached (albeit with the .txt extension which will need renaming to .sopcinfo).

4.FOr sanity I also included a GPIO pin that I can toggle to check everything else is ok.

5.The Qsys sytem then generates without any errors.

6.I then import it into my top level bdf file within quartus connect up the relevant pins and compile. Whcih all works fine!

7.I then generated a BSP and APP in the NIOS EDS tools and all that goes swimmingly.

8.In my software I can drive the GPIO pin perfectly however there is no response from the I2C peripheral even though it is present in the system.h file.

SO I then started delving into things a little,

In my VHDL file you will notice a line that outputs the avalon write signal to an output pin, at present this pin is assigned asynchronously but I have also done it under clkd assignment (registering). at no point EVER does this write signal change state (observed externally with a scope) when I try and talk through software to the peripheral. and more to the point if i try and examnine the signal in siognal tap i get no state change either.

It looks to me as though there is a problem with the connection to the avalon bus, but examining the RTL netlist in quartus seems to suggest everything is connected ok.

I would be grateful if someone could take a look at this please as hindering some critical work.

Many thanks

in advance

deBoogle

4 Replies

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

    You could simulate the qsys system using the altera bus functional model? It can also help to create a test bench for the vhdl to check its doing what you expect.

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

    --- Quote Start ---

    You could simulate the qsys system using the altera bus functional model? It can also help to create a test bench for the vhdl to check its doing what you expect.

    --- Quote End ---

    Hi, the VHDL is already proven out as a qsys component as it has been used in an earlier version and with cyclone III and IV devices, this has been in use for a number of years. Unfortunately we now need to move to a MAX 10 device, whcih means using quartus 14 and later, which is where the problem seems to creep in.

    However, it looks as though this problem is not unique to my IP. If i download the Avalon MM Slave Template and use that IP it appears that I have the same problem, what is interesting is that normally the new qsys versions (14+) all complain about having multiple signal types of the same name within a conduit. However the MM Slave template tcl file that is generated has export for every signal in the conduit and qsys does not complain.

    Still not working, and its getting more frustrating!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Hi, further developments.

    It appears that the IP I had for I2C does not want to work with the MIOS f core, only the NIOS e core. Could anybody enlighten me as to why this might be?

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

    Further news on this. It appears that it will not work with the F core in Q16.0.0 build 211. But it works fine in Q16.0.2 build 222.

    Still no idea why, just glad it now works!