Honored ContributorI created a custom fifo in sopc builder and i am trying to read data from fifo. However, i got no idea about how to manipulate it .Is it right if i make a pointer which points at the base address of the fifo ?
As i am a starter in FPGA & NIOS,or maybe my question is so simple, i would be so appreciate if some give some advice when i meet this kind of problem... Thanks.
Honored ContributorIs there anyone who can give some advice? I would be so appreciate..
Honored ContributorYou have basically the choice between the IORD/WR macros to directly access hardware, or use pointers to the base address.
If possible it's better to use pointers, as this method is probably more futureproof than the macros, especially if you plan to move to a MMU system one day. There is just one thing to be careful about when using pointers to access hardware: you must avoid using the CPU's data cache. For that the best way is to use the alt_remap_uncached() function (see page 14-47 of this document (http://www.altera.com/literature/hb/nios2/n2sw_nii52010.pdf)) to convert your base address to an uncached pointer.Honored Contributorfor(counter = 0 ;counter < 255 ;counter++)
{
write_buffer = *(alt_16 *) (CUSTOM_FIFO_IP_BASE) ;
} If you have a data cache then this won't work. On the first loop iteration the CPU will read from your FIFO, but for the next iterations it will just read the value again from the cache instead of accessing your FIFO. Something like this would be better (not tested)
#include <sys/alt_cache.h>
alt_16 *my_fifo = alt_remap_uncached((void*)CUSTOM_FIFO_IP_BASE,sizeof(alt_16));
for(counter = 0 ;counter < 255 ;counter++)
{
write_buffer = *my_fifo ;
}A slightly separate issue.
Give your fifo a 32bit interface. Since the fifo itself is 16bits wide set the high bits to zero on reads. As defined you'll find that the actual span is 4 bytes and you'll see two read cycles for every access (the second one will have a different address). Since the nios cpu always asserts all 4 byte enables for reads, both reads will have both byte enables asserted. If you do a 16bit write, one of the writes has no asserted byte enables. I'm not sure the order of the accesses is defined either.
