--- Quote Start ---
OK. Maybe I can help.
-snip-
in assmbly my main program would look like this :
begin : sjmp begin;
nothing more real world than that.
Anyway. before we go off on tangents here is what the system mechanism has to do :
This will also explain why i can not use things like DMA.
I have a main memory ( SRAM ) that will hold program , stack ,heap ,scratchpad, whatever. i dont care what how the compiler stuffs the program in there it can do whatevere it wants.
here is a simplified description :
I have 2 dual port rams ( DPRAM1 and DPRAM2 ). i also have two interrupt sources and 2 io ports.
An external system loads data into dual port RAM 1 at very specific locations. ( hence i need to be able to define absolute addresses in the NIOs program so the program can read this data. )
when the data is loaded this external system tickles interrupt 1. the nios roars to life and starts crunching the data in DPRAM 1. The results are written back to very specific locations of DPRAM 1 ( so that the external hardware can retrieve them). When the NIOS is done it sets io port 1 to '1' signalling the outside world 'i am done , data has been posted , i'm going back to sleep. wake me when you need me '
While the nios was crunching the data in DPRAM using interrupt handler 1 the external hardware was not sitting still either. It has loaded data in DPRAM2. DMA would block bus access and stall the nios ! that would be unacceptable . hence i use dual port ram. problem goes away. maybe my perception of DMA is wrong i don't know. the important bit is the program needs to keep crunching away while i am modifying memory locations that are not in use by that piece of code.)
When the external block sees that the nIOs has set PIO1 it understands that the nios is done. the external hardware now tickles interrupt 2. the nios jumps to attention and interrupt handler 2 jumps to life. crunching data in DPRAM2 with an completely different algorithm. in the mena time the external hardware offloads DPRAM1 and stuffs new data in there.
In the real application there will be tons of DPRAM's and tons of interrupts.
each interrupt i a different algorithm. each dpram has a diffrent memory layout.
to minimize all the shuffling typically associated with a program:
- i hardcode all variables at specific adresses. that way the outside world know what to put where.
- only one interrupt at a time is running. an external hardware scheduler takes care of that (a simple one-hot state machine )
- the processes on the nios do not communicate with each other.
i dont even need a printf. There is a dedicated DPRAM to give me messages. the nios just dumps data there and sets an io flag. the external hardware takes care of reading the bytes and sending them , including handshake, to the uart. the nios does not need to spend time on that.
I can not divulge what the system is for or why it needs to work this way. It suffices to say that it does work. ( i have it running on an 8051. i just lack clockspeed to do 32 bit arithmetic. something i was hoping to solve with this NIOS thing. since i have the FPGA anyway : dream solution. make the system in SOPC builder. map 8 DPRAMs ( each 256 bytes ) 8 interrupts and 8 pios. write half a page of code. attach exisiting algorithm code. compile and run... tops a few days ... its been weeks.....
--- Quote Start ---
All Altera and most vendor IP peripherals have their own drivers as well.
--- Quote End ---
i know and that is all very beautiful if you are a software developer and will use these modules. I don't. all i need is a number cruncher. i prepare data , it crunches, i load other data meanwhile when its done i offload and it begins with next block.
i like to call this 'software assisted hardware'
--- Quote Start ---
The debugger in the IDE knows how to read your elf file (elf is the binary format output on the debugger and flash and SREc and all the other stuff.
--- Quote Start ---
my system doesnt have flash. the program on the nios is loaded dynamically. it can even change a few times a minute. One moment its running this set of algorithms , the next minute it is running a completley different set of algortihms.
The easiest way to do this for me is : disconnect the SRAM from the nios : load the program image in the SRAM , reconnect and release the reset pin from the nios.
This loading happens through a USB port from the PC. The nios is used as a hardware accelerator. PC drops correct program in the nios memory. PC dumps data in DPRAM , tickles nios. pc drops more data in diffrent dpram. and collects when nios is done. 2 seconds later a diffrent program gets loaded.
most programs are small. 1 or 2 kilobyte of code.
--- Quote Start ---
Nios is little endian. You would store
0xddccbbaa into the first word.
--- Quote End ---
thank you. that is what i needed to know. can you believe this has taken 2 weeks to find out ?
--- Quote Start ---
Since you are a beginner I highly recommend you walk before running. Focus on learning the tools.
--- Quote Start ---
beingnner with nios and the toolchain yes. ive been programming this kind of systems for 20 years. using various toolchains and cpu architectures. most of the time switching meant 1 or 2 days of work. this nios has teken me 2 weeks and i still cant synthesize the core in SOPC builder ( some funny error in 7.2 about 2 clocks that worked fine in 7.1 )
I will use jtag debugger for myself yes. but the final system needs to run without. This thing is going in the field an JTAG will be disabled. can't have anyone snooping around in there while it's running ...
--- Quote Start ---
Again, you do not need to place variables at specific locations with the Nios.
--- Quote End ---
not in the main memory. there i don't care. but i need to be able to lock them down in the dpram's.
--- Quote Start ---
In this case you need 2 seperate RAM's. One for the Nios code, heap and stack and the other for your custom implementation. Define the Nios RAM for use with the linker in the <project>_syslib properties dialog box. Note that onchip memory is available to you if you only have a single off chip SRAM/SDRAM/etc.
--- Quote End ---
there we go that is what i am attempting. I figured this out in the linker settings.
--- Quote Start ---
Use the output of objectdump. You can turn it on by going to the Windows menu bar in the ide and selecting the "preferences" menu option. In the dialog box that comes up, click on Nios on the left hand side. On the right side there will be a checkbox for "objdumP" turn it on. The objdump file will reside in the same place as your elf file (typically here: <project>/Debug/<project>.elf.objdump).
This text file has a full link map, symbol map and the 'C' code interspersed with the assembler output.
--- Quote End ---
YES ! wooohooo. that is what i needed thank you thank you thank you ! now i can see what that compiler produces.
got an ADLs modem at home ? thats me .... and the same mechanism sits in the modem there... throw data in a bucket, have cpu crunch it. in the mean time unload the previous bucket and fill the next. when cpu is done tell him what bucket to crunch next.
took half a day to configure an ARM 7 .... one more day to write some verilog and slap it in an ASIC. works like a charm. easy to work with and you can tweak the algorithms.
(which would not be possible with a hard implementation. ) I am essentially using the NIOS to emulate hardware. i know i could write it directly in verilog but the algorithms need to be user modifyable. hence :code in c : compile , upload : run.
user is not allowed to touch FPGA contents nor get the guts of the system ( there is other stuff in the FPGA that needs to remain hidden... )
Honored Contributor
