Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
1,400 Views

HELP!!!Question about Avalon MM Slave Template Use

hi, I'm trying to have a coprocessor (that I built in Verilog and want to deploy on a FPGA) interact with a Nios II Processor System. By now I used the Altera Avalon MM Slave template so I can expose the I/O wires from the Coprocessor as memory locations to the Nios Processor (and to the C program). Now I was wondering....is this enough? I mean, if for example I initialize in C a pointer to the memory location pointed by my avalon slave base address and write something to it (thus writing, I think, into its first register which I selected to be an output register with loopback) It should automatically bring the same bits I wrote into the memory location into the related wires out of the sopc link (by means of the conduit interface wires that i connected to the co-processor), and then let me read the data themself into the Nios Build Tools memory debug viewer (because I set it as Output with Loopback), right?

0 Kudos
6 Replies
Altera_Forum
Honored Contributor I
39 Views

If I remember correctly the loopback feature means that for output registers you can read back the values in software. If you want to be able to write to registers and also read from other registers you'll probably want to go with enabling inputs and outputs instead of using the loopback feature. Also if you need to know when a value is being written or read make sure to enable the synchronization logic as well so that you'll have access to the read and write strobes from the template.

Altera_Forum
Honored Contributor I
39 Views

You can set the behavior of each separate register, so since I only need to read from one of the two I set the other one as write with loopback so I can read what I write into it from the memory debug console (or at least, that's what I think)...but my problem is that when I issue the write command nothing happens. This is the code: 

 

int result=0; 

int* resultpointer=&result; 

volatile int* rsacoprocessoraddress = _rsa_coprocessor_address_reg; 

*rsacoprocessoraddress=resultpointer;  

 

 

from this segment I expect to read the address of "result" into the memory location where tue first register is (_rsa_coprocessor_address_reg is a constant defined with the slave's base address), but nothing happens: the locations where my slave is are just 

 

01000000 00000000 00000000 000000000 

01000000 00000000 00000000 000000000 

01000000 00000000 00000000 000000000 

and so on...
Altera_Forum
Honored Contributor I
39 Views

The write access is probably being cached. Include "io.h" and use IOWR instead (I prefer using IOWR_XDIRECT where X is either 8, 16, or 32). Search the Nios II software developers handbook for the cache information to learn more.

Altera_Forum
Honored Contributor I
39 Views

Ok, with the IOWR I kind of managed getting my data out of the Avalon Slave's first register but it's kind of strange, because I have to put an offset of 1 (thus accessing, if my base address is 0x800, 0x804) to see the data that I write to the register in 0x800 in my memory window. Furthermore I can't access my second register (that I also decided to put in Loopback for easier debugging, while adding a third register for the input only)...what should be the right offsets for the whole register file? I'm using 32 bits registers.

Altera_Forum
Honored Contributor I
39 Views

Ah, another strange thing: actually, when I do IOWR to (0x800,1,data) my data gets written on 0x800, 0x810, 0x820, 0x830 and, even more strangely, it gets written on 0xC10, 0xC20 and 0xC30. I got no clue why this happens, since the Slave template was inserted right from sopc builder and there were really few parameters to set, like interrupt enabling and choosing which registers to enable

Altera_Forum
Honored Contributor I
39 Views

Looking at the files there are spaces between each register bank (since each bank supports different access types). Just use the offsets that come in the include file directory of the IP, then you won't need to do the low level addresses.

Reply