Nios II problem with DDR core SOPC builder

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

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).

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

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

1. The clocks and resets are being assigned by SOPC builder and I am not su re 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 > Vivek Menon wrote: > Hello all: > > I am currently transitioning a Quartu

s 8.0 (subscription edition) project > to Quartus 12.1 (web edition). Are y ou 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: FAIL ED > Leaving target processor paused That means your FPGA 'doesn't work'. I t 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 th ink 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 thi s > 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 iss ue 1. A basic test would be to put it in BRAM ('On Chip Memory' Qsys compon ent) to start with, so that you know the basic toolchain works. Theo

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

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 i t 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 vers ions 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 n ew 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 yo ur 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), ot herwise they won't have the right drivers on them. You only need to do this once. Theo

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

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

Vivek Men> Mistake: I am using the DDR memory module with NiosII. DO you know if

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