Hi All,I'm working on a research project involving NiosII processor. We need to be able to control cache bypass signal. Can any of you guide me how to do that? I need to instantiate the NiosII without cache and instantiate the cache module as another IP connected to Data bus or Instruction bus, depending on my needs.
You can't separate the caches from the processor itself.For systems without the mmu, the cache can be bypassed by either using the ldio/stio instructions or setting the most significant address bit. The altera documentation for the cpu explains all of this.
Instrcutions can only be read from the I-cache or from tightly coupled instruction memory. Even if uncached code accesses were supported they would be very very slow.If you are executing from internal memory you probably ought to make it 'tightly coupled' instruction memory - saving the logic and memory blocks needed for the instruction cache.
--- Quote Start --- I'm doing a research project. And I need to bypass the I-cache at certain points of execution. --- Quote End --- Nios-II is very intuitive and performs very well. I don't wont to go for bugy open source cores. Can Altera makes the cache modules external of the Nios-II core so that we can attache it to the processor with some wrapping logic?
It's not possible with the current core and I don't think it is planned for the future. The only way I can think of would be to invalidate the corresponding entries in the instruction cache to force it to re-read the instruction from memory.
These don't address what you are looking for but they are worth mentioning anyway just in case...1) If you don't want an instruction cache you can instantiate the 'e' core. Note: like others have said the performance will drop as a result. 2) If you place code that you don't want cached in a tightly coupled instruction memory then the instruction cache will not be accessed when the program counter hits that memory region. Note: tightly coupled memories have single cycle access times so if you were looking for higher latency this is not something feasible. If you post why you need to perform instruction fetches that bypass the instruction cache maybe you'll get an answer closer to what you are looking for. Maybe the Cortex-M1 will accomplish what you are looking for: http://www.altera.com/devices/processor/arm/cortex-m1/m-arm-cortex-m1.html
The CPU caches everything that is connected to its data and instruction masters by default. You can either use uncached memory pointers in the software code to avoid the cache, or connect the on chip memories to tightly coupled masters, that will avoid the cache.
--- Quote Start --- I am wondering why on chip memory is cached by nios2? Is on chip memory as fast as nios2? --- Quote End --- As Daixiwen said, Nios caches everything connected to its data and instruction masters. This is consistent, since in general you can have multi-master buses and your cpu would stall when another master is accessing the bus. Using cache also for onchip memory reduces the frequency of such a situation. Tightly coupled memory takes advantage of a dedicated port, so it doesn't need to be cached.
Uncached memory accesses to Avalon slaves are also slower than accesses to cache (and tightly coupled memory - which is a bit like pre-filled cache!)Since internal memory is dual ported, you can give the cpu 'tightly coupled' access and allow other masters to access via the Avalon 'bus'. Give the cpu 'data' access to its own code. This works best if you can separate out the code (without any data) into a separate memory area (the Altera provided linker script doesn't do this, and their gcc4 build directly embeds data (jump tables) in the code segment!). You'll still need an instruction cache if you want to use any of the Altera boot code or JTAG debug - since they don't export both ports of the relevant memory areas so the contained code can't be 'tightly coupled'.
The only time any modern cpu is usually run with the instruction cache disabled is immediately after reset. There is usually no reason to turn it off!Special consideration has to be made for self modifying code (etc). You can certainly run a 68020 with its I-cache disabled! and probably some of the ARM cores. Any x86 chip - especially in 'real' mode. But since disabling the I-cache kills performance, the first thing anyone does is enable it!
--- Quote Start --- You can certainly run a 68020 with its I-cache disabled! and probably some of the ARM cores. Any x86 chip - especially in 'real' mode. ! --- Quote End --- Great. Do you remember which ARM cores have this feature? Do the ARM cores that comes in some Altera's FPGAs support that?