Hi, I'd like to know what instructions of Nios C program Do I need for writing and reading data to/from a custom component of sopc system??? I saw in some AN people use IORD() /IOWR() macros or printf() function....Is it correct??? bye

It depends what kind of interface the custom component has. IORD/IOWR are the most common and they are used for memory mapped Avalon slaves. On the other hand printf involves the use of a driver that redirects stdout to the specific component interface; so, at a low level, printf itself is possibly made of IOWRs .

My personal view is that for an embedded system there is little point abstacting access to hardware through either stdio or posix files (ie starting with fopen() or open()). All that does is add extra layers and slow things down. Much better is to just define a set of API calls directly into the 'driver' itself that are optimised for the task in hand. In some cases the operations might be defined as inline functions of# defines for performance reasons. At the lowest level you will need to use uncached bus cycles that access the actual hardware. These can be requested with the IOWR (etc) defines, but it is much more common (look at any unix device driver) to define a structure to map device registers than to use constants for the offsets. The guys who did the gcc port for nios2 should have seriously considered adding an 'attribute' to memory items that would have caused ldio/stio instructions be generated for them. From the fixes I did to the gcc port I don't think it would have been difficult.

So....if i wanted to send a packet(i.e.: 0xaaaa) to my custom component which has MM-avalon interface or read from it....what command do you suggest to use? And the mapped registers address definition where is it?

Start with IORD/IOWR. They are fine for nearly all purposes. Later you can add an abstraction layer if you like, but everything is managed with the same io functions at low level. Regarding the address, you must distinguish: base address: this is arbitrarily defined in sopc builder/Qsys address span: the range of addresses your component is supposed to respond to, from base to base+span register addresses: these are actual memory locations made available in your component; from offset 0 to offset address_span-1. The external bus must add the base address to the offset to access the component memory.

Thanks Cris ....very clear!!! another question..!! In my component...I have clearly to manage the the avalon MM bus signals and so modifying my entity and architecture using an appropriate interface logic block!...Is it correct??? I ask this question..because my initial logic block has 4 signals as control input (Start, Reset, Clock, Configure), 2 signals as control output (conf_done, packet_ready) and a data_packet (32bit) as data output. Hence I should modify the block to adapt it to MM-avalon interface...correct??? So, If ,from Nios, I wanted to make my component start or configure or reset...I should create a number of different register to write in my component in order to allow to show it what it has to do...Am I wrong???

Nios 2 to custom component communication | Altera Community

13 Replies

Altera_Forum
Honored Contributor
14 years ago
The timing depends from a number of factors:
- actual device and speed grade
- system clock frequency
- synthesis result
- placement inside fpga
...
Then you have different timing even for the very same design.
Altera_Forum
Honored Contributor
14 years ago
I tried to program the simple socket server example .sof file doing test using nios2 according to example application explanation...and It works properly....even if there are these critical warnings...Why does it work the same???
Altera_Forum
Honored Contributor
14 years ago
Timequest studies the worst case scenarios. Even with those critical warnings, you could still get a system that works perfectly at ambient temperature, but will start failing it higher temperatures, for example.

Forum Discussion

Nios 2 to custom component communication

13 Replies

Recent Discussions

NiosV µC/OS-II

Recommended Quartus Prime Standard Edition for Nios V Development on MAX 10 FPGA (10M25DAF4817G)

AshlingRISCFree IDE Build system: 'source directory does not appear to contain CMakeLists.txt"

Nios-V on Cyclone IV

Debug Know-How: Ashling* RiscFree* NIOS® V debug using Command Line