Connecting an RSA-Coprocessor to a NiosII System

[Altera_Forum]

Hi, I designed a rsa coprocessor in Verilog which has to take inputs and put outputs directly into Memory (since arguments are quite large, about 5 or 6 and 1024 bit each). So I made the Coprocessor memory-side connections compatible with the user logic template of the Avalon MM Masters templates and wrote a verilog wrapping module which includes the Coprocessor itself plus two Avalon MM Masters (one for reading and one for writing). Now the wrapper module has two Avalon masters interfaces that I connect to the SDRAM in SOPC Builder (I have to test it on a DE2 Board) and a custom interface (with the programming logic of my own coprocessor) which, by now, I have configured as a Conduit. The problem with this is that I would like to expose these programming inputs to the system as a set of "control/status registers" where to put the data address, the data length, the start and ready signal and so on. I don't know how to do this: turning the counduit interface into a Avalon MM Slave would force me to put into account some timing constraints typical of that kind of interface. I thought about setting this interface as a Custom instruction Slave and using the two dataa and datab ports for address and length arguments and the start done and reset ports for their purpose, but I don't know if this is feasible and whether I should write some extra logic or the arguments passed in the dataa and datab arguments of the custom instruction would be straightly passed to the input wires of my processor. 

 What would you suggest? Thanks a lot

[Altera_Forum]

Do you connect to a processor outside of the SOPC builder project or FPGA? In that case yes you should use a conduit interface and you can use whatever signals you want. The other interfaces can only be used inside SOPC builder AFAIK (with the exception of the tristate MM, but I don't think it will help you in this case).

[Altera_Forum]

I have to connect it to other entities within SoPC Builder (i.e. the coprocessor should access to the SDRAM Altera IP core - via the Avalon Masters, I think, and I have connected it with them by now) and on the other side it should be accessible in some way by the processor for programming and control purposes (setting the data address, asserting the start signal, return the done signal and the return value address)...so I think I should have a mechanism to let the processor "see" the coprocessor input and output wires (start, reset, done, DATA_ADDRESS, DATA_LENGTH, RETURN_ADDRESS) in some way...

[Altera_Forum]

Can't you add an MM slave interface and use that to control the logic? 

Since the avalon bus is slave arbited, you can actually stall the slave access until the logic has performed its master accesses to memory.

[Altera_Forum]

I still don't get it... Is your main processor inside or outside your SOPC system? If it's outside, you'll have problems sharing the SDRAM between the processor and coprocessor.

[Altera_Forum]

Well, actually maybe I got it...let me first explain better how the system's configured: I have a previously made NiosII System (made for a DE1 Board, with SDRAM, RS232, LEDs etc.) which performed RSA in software (of course very poorly). I have now designed a Verilog Hardware RSA Coprocessor to perform the operations, which I want to insert INSIDE of the SoPC System, by means of the avalon bus interface. I had a top level entity designed in Verilog which I have adapted so now it is included in a wrapper moduel which comprehends the coprocessor itself, two Avalon Masters (one for reading from the SDRAM and one to write the results in it) and une Avalon Slave, which exposes two registers (one address input register and one input/output control/status register). Now the connections all seemed to work, and I have managed to successfully generate my SoPC Builder System: I just have to know how to expose it to my C NiosII Software Build Tools project. SoPC Builder of course generated the system.h file which contains an alias for the Base address of my coprocessor, which I can use inside of my file for accessing the first register. Now, what should I add to the _regs.h file? Is there some mandatory thing that I haven't considered, or the rest of the "dirty work" is done automatically by the Master and Slave template interfaces that I have inserted? 

 Question# 2, to access the slave register number 1 (which is the second one, since the first is number 0) should I put some kind of displacement inside of the regs.h file? and which one: 32 or 1, (i.e: cause the accesses are always considered as word aligned)? Is there any mechanism to add automatically the displacement to the base address?  Thanks a lot

[Altera_Forum]

Personally I wouldn't use the IORD/IOWR defines that altera provide. 

It is generally much easier to define a C structure that matches the device's registers and then allocate a C pointer to address the structure. In many cases (ie places where driver code is run) it is then save just dereference the pointer, sometimes access functions have to be used.  The nios will need access functions (or# defines) in order to use ldio/stio instructions (since there use wasn't added as an 'attribute' in gcc).  Accidental non-use of the access functions can be eliminated by using a 'struct' to contain the actual value, eg:  struct io_uint32_t { volatile uint32_t io_value };  and only ever referencing the io_value from within the access functions.

[Altera_Forum]

I personally prefer to use the IORD/IOWR macros, so I guess it's a matter of taste ;) It shows in the code that you are in fact accessing some hardware and not regular memory. The macros also automatically bypass the data cache. 

To answer Giorgio's question, the IORD/WR macros can handle an offset to the base address:IORD(BASE_ADDR,0)will read the component's first register and IORD(BASE_ADDR,1)will read the second one.