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???
If you haven't done yet, you need an Avalon MM slave wrapper, for example refer to the Avalon-MM Slave template you find here:http://www.altera.com/support/examples/exm-list.jsp?cat=embedded You must connect your control signals to user_data registers bits, so you will control your block functions by writing or reading the related registers, like a common microcontroller peripheral. For example: user_datain_0 (control register) : bit0=start, bit1=reset .... user_dataout_0 (status register) : bit0=conf_code, bit1=packet_ready user_dataout_1 (data register) : connect to data_packet Regards
Thanks again Cris...I tried to insert this wrapper into Sopc system as explained in application file....but...the connection between my custom VHDL module and the slave wrapper where do I have to do that..??? In Sopc Builder??? Or in Quartus II?
When I did the compilation of the project with this avalon slave wrapper inserted...the compilation completes properly without errors but with three critical warnings: "Timing requirements not met" that are not present without the wrapper....the project is the simple socket server example modified with the addition of this wrapper and of a simple adder/subtractor as custom application...Has anyone any Idea???
You must be more specific about the signals not meeting timing.If your Avalon MM wrapper interface requires waitstates it's likely you need to add multicycle path on involved signals. If it's a real timing problem, you may start following hints provided by the Quartus timing advisor, in Tools menu. Make sure you enabled the "timing driven synthesis" option in Quartus settings.
sorry...I check the simple socket server example without wrapper and there are these Critical Warnings again....so since the SSS is an Altera default example without custom user modifications...is it possible there are these kind of problems????
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.
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???
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.