Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Honored Contributor I
1,307 Views

Problem in Generation of write_n, read_n signals in NIOS-II

Dear all, 

I am facing a peculiar problem while using NIOS. I have written my own custom core, which is having Control register,Status register, Select_reg, TX_register, RX_register and I am trying to write or read these registers using NIOS-IDE, but I am not able to do it. Each of the registers are of 16bit and each of the registers are being configured as Avalon-mm slave devices. In Control register, I am able to write but the same thing I am not able to do in TX and Select registers. When I monitored the 'write_n' and 'read_n' signals in Signal-Tap, I was able to observe 'write_n' signal being generated for Control Register but it is not getting generated for TX and Select registers. Similar is the case with 'read_n' signal, it is also not getting generated and I am ending up reading garbage values for Status Register. 

 

For this I referred in Altera Forum, but I am not able to get any answer. The only answer given was the usage of dynamic addressing instead of native addressing, that I am already doing as I am using IOWR_16DIRECT, IORD_16DIRECT. 

 

I don't know where is the mistake but I suspect it might be during generation by QSYS. Please help me on how to proceed further. 

 

Thanks, 

gupnaval
0 Kudos
4 Replies
Highlighted
Honored Contributor I
17 Views

Hello gupnaval, 

A few days ago, i tried to build a qsys custom component. It was my first experience and not easy.  

What helped a lot was to dig into the qsys system using the RTL netlist viewer from Quartus. 

There i saw the majority of my mistakes: some of the links that were not correct caused by my own verilog errors. 

If qsys makes errors during generation, digging into the design with the netlist viewer can help a lot. 

Some care has to be taken into accont using qsys / Nios II / the component editor.  

After altering your verilog code in the component, if you do not regenerate your Qsys system, the updated .v does not end up in the right directory and the right version does not get compiled. 

Best Regads, 

Johi.
0 Kudos
Highlighted
Honored Contributor I
17 Views

If your component is correctly receiving read_n or write_n strobes for one address, but is not receiving it for other addresses, it sounds like you have an error in how you have specified the address range for your component. 

 

You can quickly check this within Qsys looking at the address map, or you can read your BSP generated system.h and look for your component and it's "#define nnnnnnn_SPAN yyy" attribute. 

 

Basically, Qsys generates the address decode logic and if your address span isn't wide enough it's not going to send you read_n/write_n.
0 Kudos
Highlighted
Honored Contributor I
17 Views

Thanks Johi and Ted for your valuable time and answers. I tried both of your ways and Ted you got it correct.  

 

In my custom core I was using TX_REGISTER, CONTROL_REGISTER, STATUS_REGISTER, SLAVE_SEL_REGISTER, ACK_REGISTER each of which was of 16-bit.  

 

Since I was supposed to do read or write operations in these multiple registers, hence single 'read_n' or 'write_n' signal was not enough. Hence each register, I had to configure as separate Avalon_slaves. But since each of the registers were of 16-bit, hence the combination of two registers were resulting in 32-bit, hence read and write signals were getting generated but only after address gaps of 4bytes(32 bit). So I configured each of the registers as 32-bits. This solved the problem.  

 

Any other info on this matter, please share. 

 

Regards, 

gupnaval
0 Kudos
Highlighted
Honored Contributor I
17 Views

In the past I have designed 8- and 16-bit-wide components on occasion but these days (Quartus 15) it's a lot less headache to design exclusively 32-bit wide components. 

 

You'd think it would be plug-and-play by now (SOPC/QSYS is suppoedly mature now) but it's just broken. :(
0 Kudos