Occasional Contributor
Occasional ContributorThe documentation is confusing to understand.
These are the registers I see when I export the in_csr port from the FIFO:
1) wrclk_control_slave_address[2:0]
2) wrclk_control_slave_read
3) wrclk_control_slave_writedata[31:0]
4) wrclk_control_slave_write
5) wrclk_control_slave_readdata[31:0]
In the documentation, it only mentions status register. Is wrclk_control_slave_readdata the status register? Does it mean that when:
bit 0 (when high) - FULL
bit 1 (when high) - EMPTY
bit 2 (when high) - ALMOST FULL
bit 3 (when high) - ALMOST EMPTY
Bit 4 (when high) - OVERFLOW
bit 5 (when high) - UNDERFLOW
If so, what do the rest of the registers do?
Thank you
Super ContributorYou are using the word "registers" incorrectly. Those are signals, not registers, that make up the in_csr Avalon interface for checking the input side of the FIFO (writing data into the FIFO). They control reading and writing the CSR (control and status registers) of the write side of the FIFO.
In the document, table 269 is showing you the entire register map of this interface. So if you do a word (32-bit) read on this interface at the base address you've set for the in_csr interface in Platform Designer, you'll read the 32-bit fill_level register which is described in table 270.
If you do a read on this interface at the base address + 1 (which may be plus 4 if your host interface is using byte addressing which is the default in Platform Designer), you advance to the next 32-bit word which only includes the 6-bit i_status register where each bit is documented in table 271. The upper 26 bits are unused.
This is how basic memory-mapped addressing works and how it is documented everywhere, so if you are not familiar with this, you may want to do a little googling.
You can also look at the Avalon interface spec here: https://www.intel.com/content/www/us/en/docs/programmable/683091/22-3/introduction-to-memory-mapped-interfaces.html.
Occasional ContributorUnderstood. So then, the only way to access these registers would be to then create a C file that does the memory mapping and then does a read operation to read from the FIFO?
Can I monitor the registers in SignalTap?
Can you also share the link in the documentation where it mentions how to use the control and status signals? The ones that I mentioned in my previous question.
P.S. Thank you for the quick response and detailed explanation.
Super ContributorWell when you're talking about C, you're going to a higher level language and assuming that you have a processor that can interpret that code and access the registers. The document goes into that with the API: https://www.intel.com/content/www/us/en/docs/programmable/683130/24-1/intel-fpga-avalon-fifo-memory-api.html
You can monitor the interface *signals* in Signal Tap like you've already done. You may be able to tap the registers themselves but that can be hit or miss with an IP. You looked at the wrclk_control_slave_readdata signal which, depending on the address put on the interface (wrclk_control_slave_address), would show the data stored in one of the registers in the register map, like i_status as I mentioned. So the idea is to, in Signal Tap, correlate between the address put on the address signal and the data retrieved on the readdata signal.
The Avalon specification I already shared details the signals that make up the Avalon interface and it includes timing diagrams to understand their use.
Occasional ContributorGotcha! Thanks.
Where can I find more info on the wrclk_control_slave_readdata signal and other such signals?
The link you shared mentions about the in_read/in_write and in_readdata/in_writedata.
I would like to know about the csr_readdata and csr_read signals. I read somewhere that different bit of the in_csr_readdata represents levels such as full, empty, almost full etc. So I just wanted to know if I can use it to control the write operation from the FPGA end in the FIFO.
Thank you!
