Hello, I am a new bie in the custom instruction development for Altera and was looking into the way the CRC method is implemented as per the link altera.com/support/examples/nios2/exm-custom-instruction.html I see the main C file which calls the custom instruction as crc_main.c and the custom instruction is crcCI. That function is defined in the file ci_crc.c. In that function, the macro CRC_CI_MACRO is called with the arguments. The macro is defined in the same file as:# define CRC_CI_MACRO(n, A) __builtin_custom_ini(ALT_CI_CRC_INST_N + (n & 0x7), (A)) The macro is being assigned to a built in gnu gcc custom function (if my understanding is correct). My questions are as follows: Where can I see the gnu built in custom function (I mean, in which file). It should expand like a driver level function I guess. And where is the macro ALT_CI_CRC_INST_N being defined? If all the custom gnu gcc functions are in-built, then how is it really a custom instruction? I am struck at this point of thought, please give me some pointers. That would be a huge help.

The definition of __builtin_custom_ini() is in the gcc sources, there isn't anything 'special' about it you could write it yourself. It expends to a single nios instruction. I've a very similar one: __attribute__((always_inline)) static __inline__ unsigned int custom_inic(const unsigned int op, unsigned int a, const unsigned int b) { uint32_t result; __asm__ ( "custom\t%1, %0, %2, c%3" : "=r" (result) : "n" (op), "r" (a), "n" (b)); return result; } for custom instructions where I use the 'regb' field as a sub-opcode (In particular for supporting all the byte and bit swaps in a single instruction). The custom instruction number is allocated by sopc builder/qsys when you add the instruction, unfortunately you don't seem to be able to choose your own number [1]. The instruction number is then written to one of the generated .h files. [1] This is a problem if you are trying to define multiple nios cpu with different (overlapping) sets of custom instructions. Or want to be able to compile code without the sopc/qsys generated header file.

--- Quote Start --- The definition of __builtin_custom_ini() is in the gcc sources, there isn't anything 'special' about it you could write it yourself. It expends to a single nios instruction. I've a very similar one: __attribute__((always_inline)) static __inline__ unsigned int custom_inic(const unsigned int op, unsigned int a, const unsigned int b) { uint32_t result; __asm__ ( "custom\t%1, %0, %2, c%3" : "=r" (result) : "n" (op), "r" (a), "n" (b)); return result; } for custom instructions where I use the 'regb' field as a sub-opcode (In particular for supporting all the byte and bit swaps in a single instruction). The custom instruction number is allocated by sopc builder/qsys when you add the instruction, unfortunately you don't seem to be able to choose your own number [1]. The instruction number is then written to one of the generated .h files. [1] This is a problem if you are trying to define multiple nios cpu with different (overlapping) sets of custom instructions. Or want to be able to compile code without the sopc/qsys generated header file. --- Quote End --- Thanks a lot for your reply. You mean to say the __builtin_custom_ini() function is in-built and we cannot modify them. One question I have is, how does the application programmer know the macro CRC_CI_MACRO implements the CRC functionality? From his point of view 'ini' can be any function which takes in an integer as the input and returns another integer. So does he look into the generated .h file , take the instruction number and use it for the macro ALT_CI_CRC_INST_N ? Even if he does that how does he know the built in custom ini function implements the CRC? Any comments towards these lines are really appreciated. Thank You, Akhil

There is no point quoting the entire previous message! __builtin_custom_ini() is just a way of getting a 'custom' opcode into your program's object code. There is nothing special about it, it doesn't generate anything different/special by being 'builtin' - there is no requirement to use it to generate a 'custom' instruction, you can use a gcc asm statement of your own with exactly the same effect. Knowing what a particular custom instruction actually does is something that you (as a system designer) need to know. If you build with the altera IDE scripts (etc) then the relevant constants are propogated through the system for you. Otherwise you have to make sure that the values match. For instance you might request the hardware engineer set custom instruction 0 to calculate a crc and instruction 1 to 'frob' (whatever that might be) two values. This is not really any different from defining the register layout for an avalon slave (etc). FWIW, if you actually want to calculate CRC16 (used on most hdlc) there is a simple piece of combinatorial logic to add in a byte. There might we a similar reduction for CRC32 (ethernet).

Hello, Since I am a beginner in Altera and FPGAs I did not understand some of the points you made here. I quote what I did not understand below: --- Quote Start --- Knowing what a particular custom instruction actually does is something that you (as a system designer) need to know. If you build with the altera IDE scripts (etc) then the relevant constants are propagated through the system for you. Otherwise you have to make sure that the values match. --- Quote End --- What do you mean by propagating the relevant constants with altera IDE scripts build? My requirement here, is to implement an arbitrary precision integer logic on Altera DE2 FPGA. So I was wondering with the help of NIOS ii to add some custom instructions which can operate on multi clock cycles. Example usage: RSA algorithm implementation, where the key size can even go to 1024 bits. Since the register size is 32 bits, we can select 32 * 32 bit data chunks. So, is it the hardware engineer who implements the custom instructions on a NIOS ii? If so, on which layer I can see those instructions? (on a C language or a hardware verilog/vhdl). Can I be the one who can write a custom instruction on the NIOS ii core? Kindly excuse me here if I am asking dumb questions, still a learner. Thank You, Akhil

I don't use the IDE.... but the ALT_CI_CRC_INST_N constant is defined with the value qsys/sopc assigned to the custom instruction when it was added to the cpu definition. So if you# include the correct header, and the custom instruction opcode is generated with that constant, and you've downloaded the correct fpga image it will work. I'm not sure how you'll get any help with RSA though. The custom instructions can't access memory (not strictly true since their logic could contain an Avalon master! - but you can't interwork with the data cache). The only inputs (from the cpu) are the 32bit opcode word, and the values of two 32bit registers indexed by the 'A' and 'B' fields. A combinatorial custom instruction could use the value of other vhdl registers (etc) but it can't have any side effects because it executes every clock (or rather the logic is fed the relevant inputs on every clock, and the output value is fed into a big mux and used if the opcode actually selects the relevant custom instruction). Possibly you could use a clocked, multi-cycle (single-cycle) custom instruction to latch values into some logic - use the 'C' field (with readrc unset) to determine where to write (you can write both the A and B register values). With 'readrc' set you return a value, use the 6 bit 'A' and 'B' register numbers to determine what to read (or use a 32bit value and the 'B' rg number). Using a separate combinatorial custom instruction for the reads would save the 2 clock 'late result' penalty on the result - making coding easier.

Help in CRC custom instructions please. | Altera Community

29 Replies

Altera_Forum
Honored Contributor
13 years ago
Hello,

Can someone be of help to me in this please. I am looking for a simple SOPC builder component example.
I looked in the forum, however could not find any. Do I need to start a new thread asking for the same?
Kindly let me know.

Thank You,
Akhil
Altera_Forum
Honored Contributor
13 years ago
I don't think there is any simpler example available from Altera. But basically you need to read the www.altera.com/literature/manual/mnl_avalon_spec.pdf]avalon (http:[url) specification[/url], mostly the part about the memory mapped slave interface. Then you can create your component with such an interface, and use the component creator in SOPC Builder or QSys to make the .tcl file for you.
You don't actually need to create a sw.tcl file in most cases, but you will need to write some C to access your component. The IORD and IOWR macros can be used to read or write the different registers.
There shouldn't be anything preventing you from using the example checksum component in a DE1 project with Nios II EDS, it should work just as is.
Altera_Forum
Honored Contributor
13 years ago
Hello Daixiwen,

Really appreciate for the inputs. I was thinking the checksum hardware accelerator was hardware dependent. I have read the readme.doc
in the zip folder (which contains the entire package for the checksum) and ran through the usage instructions. It states the batch script accomplishes
the following steps:
- Hardware programming file (.sof) downloads to the board
- Application and BSP make files generation
- Software compiles
- Software (.elf) downloads to the board
- Terminal is opened
What I thought was the first step will be dependent on the board (once I had some issues with the JTAG cable ID when I tried to download some example programs onto the altera DEI board).

I shall try the instructions from the NIOS II command shell and will update you.

Thank You,
Akhil
Altera_Forum
Honored Contributor
13 years ago
The bash script itself is probably hardware dependent, indeed. You will probably have to do all those steps manually:[list][*]copy all the custom component files to your DE1 project (in a folder called "ip" in your main project folder, so that SOPC builder finds it automatically)[*]add the component to your SOPC project in SOPC builder[*]recompile the Quartus project[*]download the .sof file to the DE1 board[*]update/recreate your BSP in Nios II EDS[*]compile the software[*]run it[/list]
Altera_Forum
Honored Contributor
13 years ago
Hello Daixiwen,

Really appreciate the help. I did the connections in the SOPC builder as you asked me and I am attaching the screenshot here.
I am getting an error (which I think I can understand) which states the dma master source port does not has a startpacket signal
of 1 bits where as the sink port has.
I have checked the read_mashttps://www.alteraforum.com/forum/attachment.php?attachmentid=7000 ter.v and the hw_*.tcl file which has the interface for the signal. I dont understand why an error like this pops up.

Please help me in fixing this error.

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

Eventually I was able to fix it. The DMA Read Master SOPC component had a parameter in the streaming options 'Packet Support Enable' which has to be checked so that
it will create the interface ports in the read_master_hw.tcl file. Now the SOPC build is through.

Thank You,
Akhil
Altera_Forum
Honored Contributor
13 years ago
Glad you found the solution. The error messages from SOPC builder aren't very explicit when you aren't used to them.
Altera_Forum
Honored Contributor
13 years ago
Yeah! I took a long time to fix those. Google search did not help much.
Now I am able to build the application code for CRC HW in my NIOS II IDE, however issues pop up when I run the code.

Error: Attempting to start the checksum accelerator while it is busy... exiting
Is the error that I get while running the code.

I have tried to build an SOPC system that looks like the sopc system given in the CRC example, did the SOPC and the Quartus II build and then did the NIOS II IDE build.

I see in the application code that for the hardware checksum they are registering an ISR. Was wondering these will work or not if I do not have a proper SOPC system.
As of now the code is getting issues while it calls the following function: write_to_add_len_ctrl_registers()

Thank You,
Akhil
Altera_Forum
Honored Contributor
13 years ago
The busy error message is strange. Either the component isn't reset properly (do you have a correct reset signal fed to your SOPC component?) or the CPU is not reading the correct address.
For the second point, see if the system.h file in the BSP defines the correct base address for your component (it should be a# define xxx_BASE where xxx is your component name) and that it is used correctly in the code. You can also use some SignalTap probes on the component's Avalon bus to check that it is accessed correctly.

Forum Discussion

Help in CRC custom instructions please.

29 Replies

Recent Discussions

NiosV and juart-terminal

NIOS V/m dbg_reset_out signal (Q25.1 Std, MAX10)

licensing.altera.com never worked

JTAG_UART stuck in printf

Ashling IDE scripted project creation