Nios II problem with DDR core SOPC builder

[Vivek Menon]

Hello all:

I am currently transitioning a Quartus 8.0 (subscription edition) project to Quartus 12.1 (web edition).

I am facing couple of problems:
1. The NIOS II Eclipse tool does not run the code correctly. I see the following error:
Pausing target processor: not responding
Resetting and trying again: FAILED
Leaving target processor paused

I searched for this error and saw a lot of replies talking about generating the BSP using the BSP editor and not the context menu in Eclipse. I tried both methods and this problem is not resolved.
One thing I have observed is that when I create a Hello_world_small project from scratch, it runs on NiosII. Once I start adding my code or modify the file to start using system.h the project does not run on NiosII and I see the error above.

2. In my SOPC builder I am using the DDR2 module and I don't know if this core requires the subscription edition to work correctly.

Please advise if you have seen similar issues.

Thanks.

P.S: I have posted similar thread on the Altera forum as well http://www.alteraforum.com/forum/showthread.php?t=41581 (No replies there !)

 

[Theo Markettos]

Vivek Menon <vivek.menon79@gmail.com> wrote:

Hello all:

I am currently transitioning a Quartus 8.0 (subscription edition) project
to Quartus 12.1 (web edition).

Are you using SOPC Builder or Qsys (probably better to bite the bullet and
port to Qsys at some point)?

I am facing couple of problems:
1. The NIOS II Eclipse tool does not run the code correctly. I see the following error:
Pausing target processor: not responding
Resetting and trying again: FAILED
Leaving target processor paused

That means your FPGA 'doesn't work'. It means that Quartus couldn't talk to
the NIOS II in your design. It could be any kind of problem, but often that
the clocks or resets are wrong (I think SOPC Builder inserted clocks/resets
automatically, which Qsys doesn't).

2. In my SOPC builder I am using the DDR2 module and I don't know if this
core requires the subscription edition to work correctly.

I imagine you'd get a license error if so. I've had trouble porting the
DDR2 controller into a newer Qsys version. Try deleting it and re-adding
(using DDR2 UniPHY if possible). Is your code in DDR2 or BRAM? This could
be the cause of issue 1. A basic test would be to put it in BRAM ('On Chip
Memory' Qsys component) to start with, so that you know the basic toolchain
works.

Theo

 

[Vivek Menon]

1. I tried looking at Qsys and transitioning from SOPC to Qsys. Unfortunately only the clock and reset signals were instantiated as ports to this design. I suspect some transition issue and left it at that.

2. The clocks and resets are being assigned by SOPC builder and I am not sure if the reset should be connected if it was not available as an option in v8.0

ALso, I am using the Altera Cyclone III dev kit DK-DEV-3C120N

Thanks in advance.

On Tuesday, July 23, 2013 11:25:55 AM UTC-4, Theo Markettos wrote:
> Vivek Menon wrote: > Hello all: > > I am currently transitioning a Quartus 8.0 (subscription edition) project > to Quartus 12.1 (web edition). Are you using SOPC Builder or Qsys (probably better to bite the bullet and port to Qsys at some point)? > I am facing couple of problems: > 1. The NIOS II Eclipse tool does not run the code correctly. I see the following error: > Pausing target processor: not responding > Resetting and trying again: FAILED > Leaving target processor paused That means your FPGA 'doesn't work'. It means that Quartus couldn't talk to the NIOS II in your design. It could be any kind of problem, but often that the clocks or resets are wrong (I think SOPC Builder inserted clocks/resets automatically, which Qsys doesn't). > 2. In my SOPC builder I am using the DDR2 module and I don't know if this > core requires the subscription edition to work correctly. I imagine you'd get a license error if so. I've had trouble porting the DDR2 controller into a newer Qsys version. Try deleting it and re-adding (using DDR2 UniPHY if possible). Is your code in DDR2 or BRAM? This could be the cause of issue 1. A basic test would be to put it in BRAM ('On Chip Memory' Qsys component) to start with, so that you know the basic toolchain works. Theo

 

[Theo Markettos]

Vivek Menon <vivek.menon79@gmail.com> wrote:

1. I tried looking at Qsys and transitioning from SOPC to Qsys.
Unfortunately only the clock and reset signals were instantiated as ports
to this design. I suspect some transition issue and left it at that.

2. The clocks and resets are being assigned by SOPC builder and I am not
sure if the reset should be connected if it was not available as an option
in v8.0

TBH you're probably better recreating the design in Qsys and starting from
there. There's far too many gotchas involved in porting old files to newer
versions that it's often just simplest to build it again, particularly if it
isn't a complex design. DDR2 memory is often troublesome here - it builds,
but it doesn't work.

Q12.1 to Q13.0 seems to be better than previous versions in this respect.
One tip, if you are porting forward (or back), is to load and resave your
..qsys file before trying to generate a system in the new version, otherwise
it tries to instantiate the old version and sometimes gets it wrong.

You'll have to explicitly wire clocks and resets but that's probably safer
than it guessing and getting it wrong.

Another tip: once your built your system in Quartus, go into the synthesis/
directory and there's a TCL script for assigning DDR2 pins. You need to run
this from Quartus so that the attributes on the pins are set correctly (and
then rebuild), otherwise they won't have the right drivers on them. You
only need to do this once.

Theo

 

[Vivek Menon]

Mistake: I am using the DDR memory module with NiosII. DO you know if there's a tcl scriptfor assigning DDR pins.


On Tuesday, July 23, 2013 7:09:12 PM UTC-4, Theo Markettos wrote:
TBH you're probably better recreating the design in Qsys and starting from there. There's far too many gotchas involved in porting old files to newer versions that it's often just simplest to build it again, particularly if it isn't a complex design. DDR2 memory is often troublesome here - it builds, but it doesn't work. Q12.1 to Q13.0 seems to be better than previous versions in this respect. One tip, if you are porting forward (or back), is to load and resave your .qsys file before trying to generate a system in the new version, otherwise it tries to instantiate the old version and sometimes gets it wrong. You'll have to explicitly wire clocks and resets but that's probably safer than it guessing and getting it wrong. Another tip: once your built your system in Quartus, go into the synthesis/ directory and there's a TCL script for assigning DDR2 pins. You need to run this from Quartus so that the attributes on the pins are set correctly (and then rebuild), otherwise they won't have the right drivers on them. You only need to do this once. Theo

 

[Theo Markettos]

Vivek Menon <vivek.menon79@gmail.com> wrote:

Mistake: I am using the DDR memory module with NiosII. DO you know if
there's a tcl scriptfor assigning DDR pins.

If you're using the DDR controller with UniPHY, there probably is. I never
looked for such a thing on the older AltMemPHY controller.

Theo

 

[scrts]

There's also for AltMemPHY.
Quartus: Tools -> TCL Scripts...


"Theo Markettos" wrote in message
news:jMd*jobFu@news.chiark.greenend.org.uk...

Vivek Menon <vivek.menon79@gmail.com> wrote:

Mistake: I am using the DDR memory module with NiosII. DO you know if
there's a tcl scriptfor assigning DDR pins.

If you're using the DDR controller with UniPHY, there probably is. I never
looked for such a thing on the older AltMemPHY controller.

Theo