There is a FIFO block that has Avalon interface compatible with Qsys that can be used in Qsys systems. However, in my case there is an external block that generates data that is to be read by a Nios II. The external block has a FIFO interface, thus the signals are basically q, empty and rdreq. I could try to use a PIO block to connect to the external FIFO and write some simple drivers to aid in communication. However, is there a better way to do this? Is it possible to somehow communiate with this external FIFO as if it was in the Qsys block with Avalon MM or Avalon streaming interface?
Electrical – How does one read a FIFO outside Qsys system using Nios II
intel-fpganios-ii
Related Solutions
I've fixed up the design to be work in QSYS. Your error messages:
Error: System.nios2: Reset slave sram_0.avalon_slave_0 not connected to instruction_master.
Error: System.nios2: Exception slave sram_0.avalon_slave_0 not connected to instruction_master.
...were caused by the Properties tab of the nios2
processor - you've evidently selected the SRAM to be the source of the reset/exception vectors, then later renamed the component from sram_0
to sram
. I re-selected the sram with the new name and they cleared. The remaining warnings were trivial wiring issues, and forgot to export the SRAM external side connection.
You also had the SRAM source code both with and without the clock/reset fix we spoke about, I dropped the bad one and renamed the QSYS component + tcl to have matching filenames.
Finally set the name of the top level to match Qsys generated output and replaced the source files in Quartus to be the generated .qip
file. Analysis and fitter both completed. You don't have any pin mapping in your .qsf
file, so the bitstream won't work on any real hardware yet.
You can see the working as I pushed commits along the way.
There's an asynchronous read from memory in the leds module that's preventing a block ram from being inferred, but the device is big enough you can get away without fixing that immediately (would lower resource usage, likely decrease fitter effort if it can be inferred).
The clocks are used as follows:
pll_ref_clk
= The clock which is fed in to the input of the PLL. This has to match whatever setting you have in the IP core so that the correct memory clock frequency will be generated.
afi_clk
= This is the clock used for the Avalon-MM interface. There is a corresponding reset signal afi_reset
which is synchronous (on Deassert I think) with afi_clk
.
afi_half_clk
= This is optional and is enabled by a parameter on the IP core. Basically this is a clock synchronous to afi_clk
but at half the frequency.
So when you are interfacing the Avalon-MM interface you should be using the afi_clk
for your logic.
The frequency of the clocks is dependent on your IP core settings. Basically you specify the memory frequency which is the clock speed used for the physical memory. There is then a parameter which allows you to select a mode of operation for the Avalon-MM interface. You have the following options:
Full Rate
= The Avalon-MM interface operates at the same frequency as the memory. For DDR RAM, you have data clocked on both edges, but internally you cannot do that, so to achieve the same data rate, the output interface is twice the width of the memory.
Half Rate
= The clock frequency of the Avalon-MM interface is half the frequency of the memory. Consequently the output interface is now quadruple the width of the memory.
Quarter Rate
= You get the pattern by now. Quarter the clock frequency, so data width is 8 times the width of the memory.
These different rate settings allow you to run the memory much faster than the core logic of the FPGA can run at (the periphery of the FPGA is much faster than the core). So for example you can have a 32bit 800MHz DDR chip which presents itself internally as a 200MHz 256bit wide data bus.
As to why they were using the PLL reference clock for the Nios processor in the reference design, who knows. There are many little mistakes here and there that you will find with the documentation and example designs from Altera.
Best Answer
FIFOs are typically used with streaming type interfaces. You can actually convert your FIFO signals into an Avalon ST interface quite easily. They map as follows:
~empty
rdreq
q
You don't actually need any other signals to make Avalon ST. The only weird one above is making sure to invert the empty signal.
Once in Qsys you will need to convert from Avalon ST to Avalon MM of which there are a few options. You could for example use a DMA controller to read data from the FIFO into on-chip memory that Nios can then read (e.g. the Scatter-Gather DMA Controller in Qsys).
Alternatively thinking about it, it might be easier to simply build a module to create an Avalon-MM interface. Something like:
In that example, if you read address
0
, it will read the next word from the FIFO. If you read address1
, it will tell you whether or not the FIFO has any data available.I would make a TCL wrapper around this module (you can use the "File->New Component" tool in Qsys to help you).
You should then be able to hook this straight up to Nios, and Qsys will take care of the interconnect fabric for you.
(*) read latency depends on your FIFO latency - i.e. number of cycles between asserting the
rdreq
signal and theq
signal being updated.If you want, you can register the
readdata
signal to improve Fmax, in which case add 1 to the read latency.