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, Akhil

Hello, Can someone be of assistance to the above question please? That would be a big help. If the question is not clear I can explain it again. Any inputs are appreciated. Thank You, Akhil

Hello, I gentle bounce here. Someone please help me. Thank You, Akhil

The Nios II CPU uses a 32 bit data bus, and a 32-bit data path internally, so it won't be able to process a 1024-bit word with a single instruction. You will have to divide your 1024-bit word in 32*32-bit words when accessing your IP component.

Hello Daixiwen, In the Altera user manual for Avalon interface (sopc builder, not qsys), I have seen the MM interface section. There the 'readdata' and 'writedata' ports can have a data width up to 1024 bits. So does that mean the NIOS II processor (master) can write or read 1024 bit data to the slave component in 32 clock cycles, 32 bit word every clock cycle? Earlier I thought that since the data width is 1024, it might be possible to clock in/out that much data every clock! (I am dumb :( ). And does this also mean that I can have an accumulator (kind of register) in my hardware IP module which keeps sampling the write data for the entire 32 clock cycles? And for read data, which reads the 1024 bits read register, 32 bits every clock cycle, and does the same for 32 clock cycles. I sense a low throughput for performance here (but, with a proper functionality). Please correct me if my assertion is wrong. Thank You, Akhil

You are right that you can have an Avalon MM bus with a 1024-bit data bus size, and if you connect a master and a slave that both have a 1024-bit data bus size, they will be able to transfer 1024 bits on each clock cycle (see, you aren't dumb ;) ). You need to be careful when using such a bus size, as you increase considerably the resources used on the FPGA. The problem in your case is that the CPU itself is 32 bit. So even if you connect it to a component with a 1024 bit data bus, the CPU will only be able to read or write 32 bits at a time (using byte enables). If you have a lot of operations to perform on those big words, an idea could be to implement your IP as a full ALU with a bank of 1024 bit registers. Then the CPU would only need to transfer the actual values at the beginning and end of the algorithm, but for all the intermediary steps it would only need to send instructions, and the values itself would stay in your IP component. Of course it depends entirely on what you want to do and how many intermediary values you need.

New IP development | Altera Community

48 Replies

Altera_Forum
Honored Contributor
13 years ago
Hello Ted,

The operand_A path and operand_B path to on_chip memory is just a tentative design. I can implement an RSA algorithm which generates the two prime numbers (operand_A and operand_B internally (the RSA IP core can take care of that). Just in thoughts of a future enhancement (the thought that BIGDIGITS IP should be an IP core that can be used with any application which can accept two input operands to use) I plan to use the data path.

And as you pointed out, that might be a bottleneck. However I do not need to clock in the operand_A from the body of a nested loop. In fact, I plan to clock-in the data before the algorithm/loops execute. Also please note that if I need to clock-in 1024 bits of data, I need to do that for 32 clock cycles, 32 bits every cycle.
(also please cross check that my understanding of the custom instruction is correct, i.e, the way it passes the addresses to the BIGDIGITS IP core)

Thank You,
Akhil
Altera_Forum
Honored Contributor
13 years ago
--- Quote Start ---
Hello Ted,

The operand_A path and operand_B path to on_chip memory is just a tentative design.

--- Quote End ---

OK, yes in reality your system will likely have additional components as well and they will all fit into the shared 32-bit address space seen by NIOS and SGDMA. It looks fine.

--- Quote Start ---

(also please cross check that my understanding of the custom instruction is correct, i.e, the way it passes the addresses to the BIGDIGITS IP core)

--- Quote End ---

Yes I believe you have got it correct.

Good luck!
Altera_Forum
Honored Contributor
13 years ago
Hello Ted,

Thank you for the kind explanations and the patience.. Really appreciate that.
Now I really need to learn the modules (the SGDMA, the QSYS interconnects, IP core development etc).

Thank You,
Akhil
Altera_Forum
Honored Contributor
13 years ago
Hello,

Off late, I am asking a question which I should have asked some time before. I have seen the way an application code can be accelerated using the C2H compiler at the link http://www.altera.com/literature/ug/ug_nios2_c2h_compiler.pdf
This looks like a promising approach since I have the application code for RSA handy with me and I have to identify the bottlenecks (may be I can use the code profiling method).

So, instead of developing a handwritten IP core design and verilog hardware, will it be a good approach if I can use the C2H compiler for the hardware acceleration? I am not a great programmer in Verilog, however I am okay in C/C++. One trade off I see here is, the C2H compiler cannot create accelerator for QSYS systems, it works only with the SOPC builder.

Is there any altera gurus who can comment on the above concepts and trade-offs, that would be a huge help before I kick start the real implementation.

Best,
Akhil
Altera_Forum
Honored Contributor
13 years ago
The C2H compiler is mostly discontinued - I suspect it didn't really work very well.
More probably people tried to feed it inappropriate C and it generated far too much vhdl to be in anyway useful.
Altera_Forum
Honored Contributor
13 years ago
Even if it were supported / popular, I don't think C2H approach will be a good fit for you.

For starters, I think what it will try to do is generate a non-bursting Avalon-MM Master with 32-bit width for reading, writing your data. So you will spend many clocks loading/storing, and then it will generate possibly a lot of HDL to make your math execute in a single clock.

Overall, I think you would not be satisfied with the result.
Altera_Forum
Honored Contributor
13 years ago
From what I heard you need to write your C code in a special way to limit the poor performance of the generated hardware (i.e. write HDL in C ;). In the best cases it generated not-so-efficient hardware (faster than the software version, but a lot slower than a real HDL implementation) and in the other cases it wouldn't recognize a part of the C code structure and would fail (with a more or less understandable error message). Besides, as others said here it isn't maintained any more and doesn't work with QSys.
I think your two best options for a better performance are either to run the software on a hardcode processor (either outside the FPGA, or by using one of the new Cyclone V with ARM cores) or take the time to convert it to HDL. Converting an algorithm written in C to HDL isn't very straightforward, because you often need to rethink completely the algorithm implementation. With hardware you can have more parallelization, and have a more efficient flow by using pipelining, but on the other hand the order of execution and the data flow can be quite different.
Using a profiler is indeed the first thing to do. If you see that some functions are used a lot more than others, you can start thinking about what kind of hardware could replace them.
Altera_Forum
Honored Contributor
13 years ago
Hello dsl,

So there is no point in spending time on the C2H compiler stuff since that is being discontinued, right?
I believe that is the reason QSYS builder does not have a C2H support.

Thanks,
Akhil
Altera_Forum
Honored Contributor
13 years ago
Daixiwen summed up what little I know of C2H.

You also need to answer the question 'How fast do I need it to go?' not 'How fast can I make it go?'
A single core on a typical desktop system is probably 100 times faster than a niosII. You are very unlikely to 'win' by offloading something - unless it is something that VHDL is good at, or you have real-time constraints.
Altera_Forum
Honored Contributor
13 years ago
Hello all,

For some reason the comments given by Ted and Daixiwen went unnoticed for the last couple of days.
Thank you for the nice explanation ! and thank you dsl for the final summation regarding the assessment
of the C2H and the speed of the NIOS II processor. I think as Daixiwen pointed out, I need to use the profiler
to see the individual function usage profile in the entire algorithm.

Thank You,
Akhil

Forum Discussion

New IP development

48 Replies

Recent Discussions

PCIe stuck at reset Agilex5

LVDS Output of FPGA

Need a AMI Ibis for GXB on a 10AX115N3

Tranceiver Enhanced PCS Basic mode questions

Agilex 5 Reset Sequencer - Design Assitant reports IPC-40038 violation