Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12596 Discussions

Device drivers under niosII IDE

Altera_Forum
Honored Contributor II
1,171 Views

The altera_avalon_uart drivers under niosII IDE contains three files: altera_avalon_uart_regs.h, altera_avalon_uart.h, altera_avalon_uart.c. The source file altera_avalon_uart.c call the function IORD_ALTERA_AVALON_UART_STATUS() . But how does the function IORD_ALTERA_AVALON_UART_STATUS() implement? If I want to develop my own device drivers, how can I manipulate the Avalon bus operation? And where is the description of underlying function? "Avalon Bus Specification Reference Manual" describe kinds of bus operation timing, how the device drivers control bus operation timing? Thanks a lot~

0 Kudos
8 Replies
Altera_Forum
Honored Contributor II
406 Views

 

--- Quote Start ---  

originally posted by warine+aug 2 2004, 08:12 am--><div class='quotetop'>quote (warine @ aug 2 2004, 08:12 am)</div> 

--- quote start ---  

but how does the function iord_altera_avalon_uart_status() implement?[/b] 

--- quote end ---  

 

all those definitions are in altera_avalon_uart_regs.h. 

 

<!--quotebegin-warine@Aug 2 2004, 08:12 AM 

if i want to develop my own device drivers, how can i manipulate the avalon bus operation? and where is the description of underlying function? 

--- Quote End ---  

 

Those questions are a little unclear, but what you&#39;re probably looking for is in Chapter 5 of the Nios II Software Developer&#39;s Handbook: "Developing Device Drivers for the HAL."
0 Kudos
Altera_Forum
Honored Contributor II
406 Views

Found it, thanks. As described in Nios II Software Developer&#39;s Handbook, the use of macro IORD(BASE, REGNUM) is to "Read the value of the register at offset REGNUM within a device with base address BASE. Registers are assumed to be offset by the address width of the bus." And the use of macro IORD_8DIRECT(BASE, OFFSET) is to "Make an 8-bit read access at the location with address BASE+OFFSET." Does the two macros both return a byte value? Are the two macros equivalent?

0 Kudos
Altera_Forum
Honored Contributor II
406 Views

 

--- Quote Start ---  

originally posted by warine@Aug 3 2004, 11:59 AM 

as described in nios ii software developer&#39;s handbook, the use of macro iord(base, regnum) is to "read the value of the register at offset regnum within a device with base address base. registers are assumed to be offset by the address width of the bus." 

--- Quote End ---  

 

They phrase it this way because it&#39;s tricky. Basically, the REGNUM is what will show up on the address[] port of the actual peripheral. Explained in C terms, IORD(BASE,REGNUM) = ((long*)BASE) + REGNUM for 32-bit buses, and ((short*)BASE) + REGNUM for 16-bit buses. 

 

 

--- Quote Start ---  

originally posted by warine@Aug 3 2004, 11:59 AM 

and the use of macro iord_8direct(base, offset) is to "make an 8-bit read access at the location with address base+offset." does the two macros both return a byte value? are the two macros equivalent? 

--- Quote End ---  

 

Explained in C terms, IORD_8DIRECT(BASE, OFFSET) = (char*)(BASE + OFFSET) for all cases. Only this macro returns a byte value.
0 Kudos
Altera_Forum
Honored Contributor II
406 Views

Nios II software developer&#39;s handbook says "The HAL provides the C-language macros IORD and IOWR that expand to the appropriate assembly instructions to bypass the data cache. The IORD macro expands to the ldwio instruction, and the IOWR macro expands to the stwio instruction." And Nios II processor reference handbook says "When using instruction ldw/ldwio, the effective byte address must be word aligned. If the byte address is not a multiple of 4, the operation is undefined." But the definition of macros IORD and IOWR in altera_avalon_uart_regs.h of Nios II IDE cann&#39;t guarantee the byte address is a multiple of 4. How to explain? And the slave read & write transfer on avalon bus has multiple timing, then how the macros IORD & IOWR to use the read & write timing? Thanks.

0 Kudos
Altera_Forum
Honored Contributor II
406 Views

 

--- Quote Start ---  

originally posted by warine@Aug 4 2004, 03:07 AM 

and nios ii processor reference handbook says "when using instruction ldw/ldwio, the effective byte address must be word aligned. if the byte address is not a multiple of 4, the operation is undefined." but the definition of macros iord and iowr in altera_avalon_uart_regs.h of nios ii ide cann&#39;t guarantee the byte address is a multiple of 4. how to explain? 

--- Quote End ---  

 

The Nios I processor had a choice of 16-bit or 32-bit bus width. The Nios II processor is 32-bit only. The UART registers only use 16 data bits each, at most, is backwards compatible with the Nios I (thus the need to support 16-bit buses), and it uses "native" addressing, so each register gets its own 32-bit address; the registers aren&#39;t packed in pairs into 32-bit words. 

 

The physical analog is if you hooked the A4-A2 pins of a regular MCU to the address pins of the UART, and hooked the 16 data pins of the UART to the low-order 16 bits of the MCU&#39;s data bus, and had pulldowns on the other 16 bits of the MCU&#39;s data bus. You would see a set of 32-bit registers, but only the bottom 16 bits would work on any of them. 

 

 

--- Quote Start ---  

originally posted by warine@Aug 4 2004, 03:07 AM 

and the slave read & write transfer on avalon bus has multiple timing, then how the macros iord & iowr to use the read & write timing? 

--- Quote End ---  

 

Timing is determined by the slave; the master (CPU) has no say in that matter. It&#39;s not like, say, the EMIF bus of a TI DSP, where you have to set a bunch of timing registers in order to talk to someone. 

 

The reason this is so is that the Avalon bus isn&#39;t a multidrop bus. It&#39;s more of a switched fabric. There&#39;s a lot of auto-generated logic in that bus module that handles getting the master and slave to talk properly. All the information (such as timing) it is using to generate the bus logic is in the system&#39;s PTF file. 

 

So, to answer your original question (way back), the driver has no control over timing for a custom component, rather, all that information is in the custom component&#39;s class.ptf file. The various PTF settings for the different slave and master bus modes are shown in the Avalon Bus manual, and much more info about what&#39;s in PTF files is in the PTF File handbook.
0 Kudos
Altera_Forum
Honored Contributor II
406 Views

Thanks to your helpful answers sincerely. But I still have someting unclear with the timing of bus transfer. It&#39;s easy to understand the timing is determined by the slave when using "Slave Read or Write Transfer with Peripheral-Controlled Wait States." But when using "Slave Write Transfer with Setup and Hold Time" or "Slave Read Transfer with Fixed Wait States or with Setup Time", how does the master port generate the corresponding timing according to the relevant PTF parameters of Setup_Time & Wait_States, Hold_Time ?

0 Kudos
Altera_Forum
Honored Contributor II
406 Views

 

--- Quote Start ---  

originally posted by warine@Aug 5 2004, 07:47 AM 

but when using "slave write transfer with setup and hold time" or "slave read transfer with fixed wait states or with setup time", how does the master port generate the corresponding timing according to the relevant ptf parameters of setup_time & wait_states, hold_time? 

--- Quote End ---  

 

The master does not generate timing. The bus module generates timing. The master is given a waitrequest line it is expected to obey. That&#39;s all you have to deal with.
0 Kudos
Altera_Forum
Honored Contributor II
406 Views

Yeah, right. I ask a wrong question. My question should be how does the bus module generate the corresponding timing according to the relevant PTF parameters of Setup_Time & Wait_States, Hold_Time? Thanks to your answers.

0 Kudos
Reply