Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorNew IP development
Hello,
I am interested in developing some instructions which can do the bignum operations (like adding two operands of 1024 bit) and hence by plan to implement a simple Full Adder like this: {carry,sum} = OP_A + OP_B; I am a beginner in Altera and realized that I can develop an IP component with Avalon MM slave interface which can talk with the NIOS II processor. I was wondering how to give the bignum values as the operand from the NIOS II processor (master) to the IP component (slave) from the application code? I see only these macros in the generated 'io.h' file: # define IOWR_32DIRECT(BASE, OFFSET, DATA) io_write((BASE_APB_ADDR) + __AVL_TO_APB((alt_u32)((BASE) + (OFFSET))), DATA, (BASE) + (OFFSET)) # define IORD_32DIRECT(BASE, OFFSET) io_read((BASE_APB_ADDR) + __AVL_TO_APB((alt_u32)((BASE) + (OFFSET))), (BASE) + (OFFSET)) I guess these are the 32 bits write and read instructions. So, do I get to clock in the 1024 bits as a single instruction? Or do I have to wait for 32 clock cycles (sampling the 32 bits in a clock cycle, do for 32 clocks. Please say a no to this..) ! Hope that question is clear and someone can respond. Really appreciate it. Thank You, Akhil48 Replies
Altera_ForumI would use the 5 bit C field (with writerc == 0) to select the operation.
That way you only need one custom instruction.- Altera_Forum
Hello all,
After giving it several thoughts, I have decided on to have some sort of implementation like this: BIGNUM IP core: With a 1024 bit Avalon master interface with on-chip memory to read the operands into the operand registers as suggested by Ted. With a 32 bit Avalon master interface with NIOS ii to decide on the address from which we can read the operands. The 1024 bit on-chip memory interface will copy the value from memory onto the registers only if valid addresses are read using this 32 bit interface first and the values will be read from those valid addresses. This 32-bit interface also gives the 'opcode' interface for an operation to perform, as requested by the NIOSII. Like if the data read is 0, it corresponds to BIGNUMADD, if the data read is 1, it corresponds to BIGNUMSUB etc. So I will add a user note saying please exclude the 'opcode' values from being used as the operand read addresses. I did not see any edge of using a custom instruction with the IP core for the below reasons: 1) If the IP core has to get values from the custom instruction, then the NIOS II should talk with the custom instruction first, then the custom instr. send the output to the NIOS II and then the NIOS II has to give those values to the IP core. 2) I did not see any such custom instruction interface in the Avalon Interface spec. (I saw clock, reset, interrupt, MM, ST, tristate etc) 3) The custom instruction does not do anything specific in this scenario, O/P = I/P. So we can avoid an overhead. Instead, I plan to use another 32 bit MM master interface in the IP core as described above. Please correct me if I miss something here. I really appreciate everyone's patience. Thank You, Akhil - Altera_Forum--- Quote Start --- Please correct me if I miss something here. --- Quote End --- There is no technical reason why you can't use a secondary Avalon-MM Slave port for the control activity, and that may very well be a better starting point for you, since you only have to learn one interface (Avalon-MM, but two different directions). The main reason (I see) for using custom instructions is the higher performance you should be able to achieve. (as dsl noted in post# 8 of this thread, NIOS IORD_ and IOWR_ macros [and the underlying hardware interactions] are relatively slow). In the end, for this component the control aspect is a relatively small portion of where your development time is going to be spent, so it is definitely something you can easily revisit later for performance or other reasons.
- Altera_Forum
Hello Ted,
Thank you for the reply! Now I understand that the custom instruction is faster than an IP core. I have just one more question here. How is it possible to create a custom instruction interface (?) in an IP core? I think in your design you plan to have such an interface (if my understanding is correct) I have read the Avalon interface manual (for sopc) and I do not see any interface of that sort. I have seen clock, reset, interrupt, MM, ST, Tristate etc. Thank You, Akhil - Altera_Forum--- Quote Start --- How is it possible to create a custom instruction interface (?) in an IP core? I think in your design you plan to have such an interface (if my understanding is correct) I have read the Avalon interface manual (for sopc) and I do not see any interface of that sort. --- Quote End --- Yes I see the details are "light" to "non-existent" on how to do it via TCL. Probably the easiest way is to use Qsys (File->New Component) and then from the component editor use the Templates menu to add the type of instruction you would like to add. For what it's worth, I personally like editing the TCL manually, so I would just get the tool to generate the first round of port definitions and then copy&paste that into my own .tcl file. (I have had trouble with the Component Editor in the past, and I do not like it).
- Altera_Forum
Thank you for the reply! I think it is high time for me to move on from SOPC to QSYS, right? I guess SOPC builder may not have the above feature.
(The templates menu to add the type of instruction to the IP core). I checked the SOPC and I could not see that tab. And you mean to say you rely on the hw_*.tcl file scripting than the GUI based SOPC builder? Thank You, Akhil - Altera_Forum--- Quote Start --- Thank you for the reply! I think it is high time for me to move on from SOPC to QSYS, right? I guess SOPC builder may not have the above feature. (The templates menu to add the type of instruction to the IP core). I checked the SOPC and I could not see that tab. --- Quote End --- Yes, you should use Qsys. I believe even if you launch SOPC Builder in the latest edition, it will give you a "Not recommended for new designs" type of message. --- Quote Start --- And you mean to say you rely on the hw_*.tcl file scripting than the GUI based SOPC builder? --- Quote End --- Yes, but this is only my personal preference. If you search on here, you will find people having trouble using the graphical Component Editor so I know I am not alone. The TCL is not complicated (but unfortunately for custom instructions, I can't find a TCL reference).
- Altera_Forum
Thank you for the explanation, Ted! Glad that I met you here who knows how to explain clearly, for a beginner in Quartus II like me.
So I am just confirming the tentative design to make sure we on the same page. Please see the attached diagram which shows the entire design for a typical RSA application. The NIOS II core uses the RSA IP core to implement the RSA in hardware. The RSA IP core talks with the BIGDIGITS IP core to get the desired bignum functionality. The control path will be from NIOS II -> RSA -> BIGDIGITS. And as you pointed out, the BIGDIGITS will have a custom instruction interface for the control signal to increase the speed. The functionality of that custom instruction is, output = input. It just passes along the address (for both the operands) and the 'opcode' to perform for the BIGDIGITS. The data path will be from the on chip memory to the BIGDIGITS IP core. Hope the above design is an okay one for me to start implementation in Qsys (I need to learn that as well, huh ! I had so far been an SOPC guy.) Thank You, Akhil - Altera_Forum
A gentle bounce.
Thank You, Akhil - Altera_Forum
Your block diagram looks OK. The bottleneck is going to be the "operand A" path from NIOS to onchip memory. I'm not familiar with the specific algorithm you are implementing: is "operand A" going to be generated from the body of a nested loop, or is it going to be generated only once (as an input parameter) before the algorithm/loops execute?
