Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
820 Views

how to read data from FIFO in SOPC

hi,BadOmen or other gurus: 

I write a SOPC component which is connected to AVALON bus.the custom component mainly consist of FIFO,I want to write a large bulk of datas in it and then read the datas out as the slave interface of the SOPC system. 

 

in quartusII: 

FIFO this_fifo(.aclr(~reset_n ), 

. data(active_data), 

.rdclk(clk_50M), 

.rdreq(sl_read & sl_chipselect & out_en & (~rdempty) ), 

.wrclk(clk_27M), 

.wrreq(in_en & (~wrfull) ), 

.q(sl_readdata), 

.rdempty(rdempty), 

.wrfull(wrfull) 

); 

 

In NiosII eclipse software,I write: 

 

while(1) 

read_fifo=IORD_ALTERA_AVALON_PIO_DATA(CUSTOM_FIFO_BASE); 

return 0; 

 

then I wacthed these signals by signaltapII,there are several phenomenons I cannot understand!~ 

 

1: There seems that the sl_chipselect,sl_read pulses are generated automatically,how can I control them,because I want to change the pulse frequences and the times when they need to be generated?? 

(I have try to add a timer in SOPC system and named it "sys_clk_timer",then in NiosII eclipse,I choose the "sys_clk_timer" ,but it cannot play a part) 

 

2: I check the signaltapII waves ,and find that the active_data which is writed in FIFO are not the same as the sl_readdata which is readed from the FIFO(sometimes,the part datas in front of sl_readdata are right,then are wrong)?? 

 

3:I have readed the .pdf of the FIFO,it says that,"aclr" signal should controlled by wrclk,maybe the FIFO component I make is not stable?? 

 

thanks for your patient answer~ 

 

best regards!
0 Kudos
8 Replies
Altera_Forum
Honored Contributor I
126 Views

hi, 

I am happy that the data readed out is OK. 

I only changed the signaltapII acquirment clock to 50MHZ(27MHZ). 

but I am still puzzled at those posted questions~
Altera_Forum
Honored Contributor I
126 Views

The chipselect and read signals are generated by the fabric that connects to your slave port. These are what tell your component that it's being read. Chipselect is a bit redundant since it's going to assert at the same time as read. So when the Nios II core performs the read access to your FIFO slave port you should see the read and chipselect assert 0 or more cycles (dependent on your system topology) after the CPU asserts the read signal. 

 

You have a read request signal so it looks like you are using the FIFO in legacy mode. I recommend putting it into lookahead mode which means that any time empty is low there is valid data at the output of the FIFO. 

 

aclr is the asynchronous reset for the FIFO so it's not really dependent on anything. For timing reasons I can see it being a good idea to assert aclr in sync with the write clock. If it fails timing Timequest will let you know by showing recovery or removal violations.
Altera_Forum
Honored Contributor I
126 Views

Also I take it that 'outen' is wired up to 'slread & ~rdempty'

Altera_Forum
Honored Contributor I
126 Views

BadOmen, 

thanks for your reply~ 

you said :" Also I take it that 'outen' is wired up to 'slread & ~rdempty",yes, it is right,I have changed my code: 

rdreq(sl_read & sl_chipselect & out_en & (~rdempty) ), to rdreq(sl_read & out_en & (~rdempty) ). 

 

thanks to you,now,I can read data correctly from the FIFO ,next ,I want to translate those data to the SDRAM by DMA component,when I add the DMA component to my SOPC system , there are several errors when generating SOPC system in SOPC builder,I have rebuild my SOPC system many times,but the errors always existed... 

 

the following are the errors: 

 

CPU/instruction_master:Base Address for dma_0/control_port_slave must be a multiple of its span 0x40; 

CPU/instruction_master:Base Address for sys_clk_timer conflict with pll; 

CPU/instruction_master:Base Address for jtag_uart must be a multiple of its span 0x40; 

...... 

I add the DMA conponent at last ,the address of it would not be conflict with other components ,but there is the error,I donnot know the reason? 

 

the conflict between 'sys_clk_timer' and 'pll'  

the conflict between sys_clk_timer' and 'sysid' 

and something of this kind are also generated,I have try to changed the base_addresses of them manually and try to get the answer using the internet,but I cannot make it ,so I turn to your gurus help me, thanks~ 

 

 

best regards
Altera_Forum
Honored Contributor I
126 Views

I have try to change my DDR SDRAM attribute, such as ,set 'contoller data rate' Full or Half, then the SOPC builder can generate successfully without any error,but in signaltap ,I cannot watch any wave. 

 

thanks for your kind help~!
Altera_Forum
Honored Contributor I
126 Views

Those messages just mean that you either have an overlap in addresses or the base address isn't aligned to the correct boundary. So if you had a slave port that takes up 16 bytes of address span the only places it can be places in the address space are 0, 16, 32, 48, 64, etc.... 

 

If the signals you have added to the signal tap trace show up in red after you compile the design that means they have been optimized away (and so they won't toggle when you sample them). There are different ways to prevent this but what I typically do is just make a copy of my work and for the nets that I care about I just add the (* keep *) attribute to the net deceleration like these: 

 

(* keep *) wire <net_name>; 

(* keep *) reg <variable_name>;
Altera_Forum
Honored Contributor I
126 Views

I also seem to be getting similar error messages as Hebeiwuyou when trying to generate my design in SOPC (only part of the error message is shown): 

 

Error: pb_cpu_to_io/m1:Base Address for uart_RS232_LRF conflicts with timer_75MHz. 

Error: pb_cpu_to_io/m1:Base Address for uart_RS232_LRF must be a multiple of its span 0x40. 

 

The error messages started to appear when I wanted to change the memory interface controller's (using two altmemddr's) from handling 16 DQ bits, to handle 32 DQ bits.  

 

Reducing the number of DQ bits from 32 to 16 got rid of the error message. 

 

Also, when disabling one of the altmemddr's and using 32 DQ bits for the other, I was able to generate the SOPC system. 

 

Now I'm wondering why auto-assign base address isn't handling this and how to fix the problem ?
Altera_Forum
Honored Contributor I
126 Views

I change the baseaddress of the SOPC component in SOPC builder manually, 

for example: 

Error: pb_cpu_to_io/m1:Base Address for uart_RS232_LRF must be a multiple of its span 0x40. 

 

you can change uart_RS232_LRF baseaddress which can be divided by 0x40
Reply