New IP development

Hello Ted,

Thank you for explaining the design! I think I understand what you had been doing with the dual port on chip memory and the way of connecting it to the NIOS II processor. Your design almost works the same way as the one explained by Daixiwen. However I see a gain in the 'read' performance.

In your scenario, the two operands (those are 32 bits) have to be clocked-in for 32 clock cycles into the on chip memory so that the BIGNUM module can read the operands from it. So there will be some latency to get the operands value.

However I see a small issue with the BIGNUM module being a custom instruction. The custom instruction is an instruction which we implement for the NIOS II processor, right ? So is it possible for us to modify the data path for a custom instruction like this? i.e, reading from the On chip memory than from the NIOS II data bus? Also the output from a custom instruction goes to the NIOS II (which is again 32 bit data path, I am not sure it can return 1024 data bits and we might have to wait for 32 clocks), and unfortunately a custom instruction has only one O/P signal port. For an adder there will be two signal outputs, which is the SUM and the CARRY. For the above reasons I had thought of coming up with an IP core like design which is more flexible.

I am really interested in the SGDMA module (thanks for pointing out the ST interface!), using which I think I can clock-in upto 256 data bits in a clock cycle. So if I need to clock in a text (that has to be encrypted) or an operand that is 1024 bits, I think I can do it in just 4 clock cycles. (more efficient than using 32 clocks). Please correct me if I am going wrong.

Thank You,

Akhil

A (non-combinatorial) custom instruction can read/write internal fpga memory just the same as any other logic.

What you could do is dual port some internal memory to the custom instruction logic and a tightly coupled data port.

You custom instruction would then take memory addresses as it's inputs and perform the operation on the shared memory block.

The cpu reads/writes of the memory would be as fast any other way of getting the data into your logic.

--- Quote Start ---

In your scenario, the two operands (those are 32 bits) have to be clocked-in for 32 clock cycles into the on chip memory so that the BIGNUM module can read the operands from it. So there will be some latency to get the operands value.

--- Quote End ---

Correct. It's kind of like a cache, and the "cache miss" penalty is quite large. It only makes sense to use the memory and keep the operands around if you think you will be using them more than once.

--- Quote Start ---

However I see a small issue with the BIGNUM module being a custom instruction. The custom instruction is an instruction which we implement for the NIOS II processor, right ? So is it possible for us to modify the data path for a custom instruction like this? i.e, reading from the On chip memory than from the NIOS II data bus?

--- Quote End ---

My suggestion is to implement a single new IP component which has two interfaces: an Avalon-MM master, and a custom instruction interface. The Avalon-MM is for the data path (1024-bit operands), and the custom instruction is for the control path (opcodes).

--- Quote Start ---

Also the output from a custom instruction goes to the NIOS II (which is again 32 bit data path, I am not sure it can return 1024 data bits and we might have to wait for 32 clocks), and unfortunately a custom instruction has only one O/P signal port. For an adder there will be two signal outputs, which is the SUM and the CARRY. For the above reasons I had thought of coming up with an IP core like design which is more flexible.

--- Quote End ---

It's your component and you can do whatever you like to meet your needs, but in my diagram I had been thinking that the output would have been written by BIGNUM back to the memory, and not traverse the instruction interface. In other words, the NIOS tells the BIGNUM where to put the result.

--- Quote Start ---

I am really interested in the SGDMA module (thanks for pointing out the ST interface!), using which I think I can clock-in upto 256 data bits in a clock cycle. So if I need to clock in a text (that has to be encrypted) or an operand that is 1024 bits, I think I can do it in just 4 clock cycles. (more efficient than using 32 clocks). Please correct me if I am going wrong.

--- Quote End ---

It's only going to theoretically go as fast as the interfaces it is connected to. If you're DMA'ing from an 32-bit SDRAM, the 256-bit DMA will only emit a word on 1/8th of the clocks since it has to buffer them up in 32-bit increments.

Hello,

I am thankful for the reply.!

--- Quote Start ---

Correct. It's kind of like a cache, and the "cache miss" penalty is quite large. It only makes sense to use the memory and keep the operands around if you think you will be using them more than once.

--- Quote End ---

Akhil>> Okay that makes sense. I have to think about the design (sometimes it might be needed to pass the operands just once to the IP module and then

let the IP do the rest). I will take care of it once I have a clear idea about what to do with the core.

--- Quote Start ---

My suggestion is to implement a single new IP component which has two interfaces: an Avalon-MM master, and a custom instruction interface. The Avalon-MM is for the data path (1024-bit operands), and the custom instruction is for the control path (opcodes).

--- Quote End ---

Akhil>> What do you mean by a custom instruction interface? Is it an interface to fetch the corresponding operand (+, - ,..) from the NIOS II? If so how to do

that from my IP module? (please note that passing those 1024 bits may not be a good idea if we have to take 32 clock cycles to do that)

--- Quote Start ---

It's your component and you can do whatever you like to meet your needs, but in my diagram I had been thinking that the output would have been written by BIGNUM back to the memory, and not traverse the instruction interface. In other words, the NIOS tells the BIGNUM where to put the result.

--- Quote End ---

Akhil>>Here you mean to say like the way BIGNUM module accepts 1024 bits data from the on chip memory, there should be a way to write 1024 result bits back to the on chip memory and the NIOS II gets to decide the address.

--- Quote Start ---

It's only going to theoretically go as fast as the interfaces it is connected to. If you're DMA'ing from an 32-bit SDRAM, the 256-bit DMA will only emit a word on 1/8th of the clocks since it has to buffer them up in 32-bit increments.

--- Quote End ---

Akhil>> I think I understand the above concept. All my experimentation will be on a DE1 board which has a 16 bit SDRAM. Hence-by a 256-bit DMA transfer will still have to wait for 16 clock cycles (since it has to buffer all those 256 bits in 16 bit increments) and hence the whole 1024 bits will take 1024 clocks. This gives me no such edge over a normal MM interface transfer. The best case scenario is a 64 bit SDRAM (which is the highest data width for an SDRAM in an SOPC builder) and use it as a 64-bit DMA transfer. In the above case I guess it will push 64 bits in a single clock and hence it should take only 16 clocks to clock in the entire 1024 bits. I will specify it as a future enhancement for the time being.

--- Quote Start ---

Akhil>> What do you mean by a custom instruction interface? Is it an interface to fetch the corresponding operand (+, - ,..) from the NIOS II? If so how to do

that from my IP module? (please note that passing those 1024 bits may not be a good idea if we have to take 32 clock cycles to do that)

--- Quote End ---

See this document: http://www.altera.com/literature/ug/ug_nios2_custom_instruction.pdf

and this example: http://www.altera.com/support/examples/nios2/exm-custom-instruction.html

You do not pass the 1024-bit operands through this interface. You supply register references and those 32-bit registers would contain the address locations in RAM of where the 1024-bit operands are located. See Figure 2-1 of the .pdf.

Hello,

Thank you for pointing out the CRC example! I understand what you are trying to say. The dataa and datab register references will go to the custom instructions, and those point to the RAM where 1024 bit operands are stored sequentially.

I was looking into the modules CRC_Custom_Instruction.v and CRC_Component.v. I have some questions on the implementation that I might have to do for my design.

I think that the dataa signal of the module CRC_Custom_Instruction.v has to remain as a signal of width 32 (input [31:0] dataa;) since the NIOS II data width is 32 and the register dataa is in its data path. However the writedata signal in the CRC_Component.v module can be a signal of 1024 bit width so that I can perform operations on the entire 1024 bit. Is this what you are trying to say? There is no other way to refer memory directly (like pointers) from a hardware description language, right?

If this was a language like C/C++ (I know a bit of those) I would have had pointers pointing to the memory locations and would have read sequentially from the memory and done the operations.

I am not an expert in the HDLs , so I have to ask these questions. I am sorry for the trouble.

Hello Ted,

I think when I gave a thought now, I understood what you are trying to say. The NIOS II just gives a control signal to the IP to say which operand to use (like a ADD, SUB etc).

Based on that, the logic to do the corresponding operations can be built in the IP core itself. So the macros like BIGNUM_ADD(&dst, &srcA, &srcB); will be just used to specify the addresses for the IP cores and the corresponding custom instruction essentially does nothing. It just passes those addresses to the IP core and the IP core does the processing (the corresponding operation inside the IP core can be selected with the help of a control signal from the custom instruction, like 'n').

After the processing of data, the IP core can write values to the &dst which is already provided by the custom instruction.

Is this what you were telling or am I going too much? If this is not what you were explaining, please see my above post.

Thank You,

Akhil

If you restrict the operand addresses to a single internal memory block then your IP can directly access the block (rather than having to wait for any avalon transfers to complete).

Also you only have two 32-bit inputs to your custom instruction - so you can't specfy full addresses for all three operands.

Probably worth using the rC field as a sub-opcode.

--- Quote Start ---

Is this what you were telling or am I going too much?

--- Quote End ---

Yes, I think you got it.

Good luck!

Hello dsl and Ted,

Really appreciate for helping me here. I think I will give NIOS II the option to pass the register addresses to the IP core. So I guess custom instruction will look like this: pass addresses of operand_A, operand_B and the result register in each clock cycles to the IP core (custom instruction will be like O/P = I/P) and let the IP core do the rest. And for selecting the specific operator, I can use the 'n' signal (which can take upto 256 values, in my case I need only a few instructions) from the custom instruction to the IP core.

Please correct me if I am going wrong here.

Thank You,

Akhil