FPGARelated.com
Forums

NIOS 2 memory limitations

Started by George June 1, 2004
I'm converting a NIOS design to a NIOS 2 design.  The end product has
a large number of 256MBit FLASH devices (19).  I've mapped all the
periferrals to low mamory 0x000 to 0x2000 and then one 256 MBit SDRAM
0x0200 0000 (spaces added for clarity)  I then start adding FLASH
devices at 0x0400 0000.  All goes well till I try to place FLASH at
0x1000 0000.  I get a compiler error messages: "Address range of
instruction master crossing a 256 MByte boundary. Not supported"

My questions are:  Did I do something wrong?  Is this a bug or for
real? How can I handle large memory designs?  How can I make some of
the FLASH data and ont instructin memory and will that help?

Thanks
George
"George" <george.martin@att.net> wrote in message
news:e9d879fa.0406010629.27219b22@posting.google.com...
> I'm converting a NIOS design to a NIOS 2 design. The end product has > a large number of 256MBit FLASH devices (19). I've mapped all the > periferrals to low mamory 0x000 to 0x2000 and then one 256 MBit SDRAM > 0x0200 0000 (spaces added for clarity) I then start adding FLASH > devices at 0x0400 0000. All goes well till I try to place FLASH at > 0x1000 0000. I get a compiler error messages: "Address range of > instruction master crossing a 256 MByte boundary. Not supported" > > My questions are: Did I do something wrong? Is this a bug or for > real? How can I handle large memory designs? How can I make some of > the FLASH data and ont instructin memory and will that help? >
You can choose whether the memory banks are connected to the instruction master and/or the data master. It sounds like there is a limitation in the Nios II regarding the width of instruction addresses (probably so that an absolute call or jump can fit within a single instruction), but that should not affect the data access (presumably this range is mostly data?). Deselect the instruction master connection from the data banks, and see if that helps.
"David Brown" <david@no.westcontrol.spam.com> wrote in message news:<c9i4bk$3lg$1@news.netpower.no>...
> "George" <george.martin@att.net> wrote in message > news:e9d879fa.0406010629.27219b22@posting.google.com... > > I'm converting a NIOS design to a NIOS 2 design. The end product has > > a large number of 256MBit FLASH devices (19). I've mapped all the > > periferrals to low mamory 0x000 to 0x2000 and then one 256 MBit SDRAM > > 0x0200 0000 (spaces added for clarity) I then start adding FLASH > > devices at 0x0400 0000. All goes well till I try to place FLASH at > > 0x1000 0000. I get a compiler error messages: "Address range of > > instruction master crossing a 256 MByte boundary. Not supported" > > > > My questions are: Did I do something wrong? Is this a bug or for > > real? How can I handle large memory designs? How can I make some of > > the FLASH data and ont instructin memory and will that help? > > > > You can choose whether the memory banks are connected to the instruction > master and/or the data master. It sounds like there is a limitation in the > Nios II regarding the width of instruction addresses (probably so that an > absolute call or jump can fit within a single instruction), but that should > not affect the data access (presumably this range is mostly data?). > Deselect the instruction master connection from the data banks, and see if > that helps.
Do you know how to do that. I added a 2nd TriState Bus and connected that to the CPU Data Master Bus. The 1st TriSatate bus is connected to the CPU Instruction Master Bus. Is this the best (correct) way?? Thanks George
George,

The Nios I is a Harvard architecture meaning it has a separate Instruction
and Data bus.

You need to connect a memory or bus to the instruction bus only if the cpu
will get/load instructions from that memory.  If not then don't waste the
logic.

Ken

"George" <george.martin@att.net> wrote in message
news:e9d879fa.0406011041.29676c1a@posting.google.com...

> Do you know how to do that. I added a 2nd TriState Bus and connected > that to the CPU Data Master Bus. The 1st TriSatate bus is connected > to the CPU Instruction Master Bus. > > Is this the best (correct) way?? > > Thanks > George
> > You can choose whether the memory banks are connected to the instruction > > master and/or the data master. It sounds like there is a limitation in the > > Nios II regarding the width of instruction addresses (probably so that an > > absolute call or jump can fit within a single instruction), but that should > > not affect the data access (presumably this range is mostly data?). > > Deselect the instruction master connection from the data banks, and see if > > that helps. > > > Do you know how to do that. I added a 2nd TriState Bus and connected > that to the CPU Data Master Bus. The 1st TriSatate bus is connected > to the CPU Instruction Master Bus. > > Is this the best (correct) way?? > > Thanks > George
Hi George, A colleague replied to your inquiry over on the Nios forum website. However just to clarify the above: Each tri-state master will generate a new tri-state bus coming out of your SOPC Builder system. Depending on how your board is designed this probably isn't what you want (you probably should keep the bus setup similar, if not identical, to your Nios I system). As alluded to above, the limitation is in fact in place so that a Nios II call instruction will always fall within a 'legal' range (256MBytes of address space). So for your system I would recommend the following: 1. Tie the Nios II CPU instruction master only to those memories that you wish to have code in. 2. Make sure that the address span between all peripherals that you read instructions out of falls into that 256MB range. This will probably mean altering the base address of your memories to group all instruction memories close together. If the above is not an acceptable solution, feel free to send me an email and I can give you some additional ideas. Regards, Jesse Kempa Altera Corp. jkempa at altera dot com
My guess is that this is the first of many undocumented features for
the upgrade to Nios II. Make sure and back up your previous project.
They even say that in the app note. Be careful.


kempaj@yahoo.com (Jesse Kempa) wrote in message news:<95776079.0406011652.6925b9d@posting.google.com>...
> > > You can choose whether the memory banks are connected to the instruction > > > master and/or the data master. It sounds like there is a limitation in the > > > Nios II regarding the width of instruction addresses (probably so that an > > > absolute call or jump can fit within a single instruction), but that should > > > not affect the data access (presumably this range is mostly data?). > > > Deselect the instruction master connection from the data banks, and see if > > > that helps. > > > > > > Do you know how to do that. I added a 2nd TriState Bus and connected > > that to the CPU Data Master Bus. The 1st TriSatate bus is connected > > to the CPU Instruction Master Bus. > > > > Is this the best (correct) way?? > > > > Thanks > > George > > Hi George, > > A colleague replied to your inquiry over on the Nios forum website. > However just to clarify the above: Each tri-state master will generate > a new tri-state bus coming out of your SOPC Builder system. Depending > on how your board is designed this probably isn't what you want (you > probably should keep the bus setup similar, if not identical, to your > Nios I system). > > As alluded to above, the limitation is in fact in place so that a Nios > II call instruction will always fall within a 'legal' range (256MBytes > of address space). So for your system I would recommend the following: > 1. Tie the Nios II CPU instruction master only to those memories that > you wish to have code in. > 2. Make sure that the address span between all peripherals that you > read instructions out of falls into that 256MB range. This will > probably mean altering the base address of your memories to group all > instruction memories close together. > > If the above is not an acceptable solution, feel free to send me an > email and I can give you some additional ideas. > > Regards, > > Jesse Kempa > Altera Corp. > jkempa at altera dot com