Forum Discussion
Altera_Forum
Honored Contributor
Honored Contributor"readyfordata" won't work
Hi Guys,
I'm trying to build an MM Slave component with dataflow control and got some problem. It is very important, that if the target is not ready to receive data then NIOS must stop writing data. That is simple, I thought, since there is the "readyfordata" signal for slave write. But it does not have any effect. NIOS continues writing independently of the level of readyfordata signal. See the attachment. If I change that signal to "waitrequest" kind, that works, but the only prolem that the wait request is shared between the read and write part of Avalon Slave interface, and in my case that is not good. Any idea?file:///d:/temp/moz-screenshot.png13 Replies
Altera_ForumDoess NIOS support Avalon-MM flow control?
IIRC, Avalon-MM flow control has been deprecated in favor of Avalon-ST.- Altera_Forum
By the documentation (2009, april) it still support - despite that being deprecated.
I don't think Altera wants to kill Avalon MM, and if so why they should not support some flow control? In several cases the teh ST is not a good solution. IMHO. Not to mention, if there is a function, a selectable signal, why it does not work? - Altera_Forum
Sorry, my reply was too condensed.
Flow control in Avalon-MM rinterfaces is an optional feature: slaves or masters may not support it. So, you need to write your slave in such a way that it works properly with a master that does not support flow control. In particular, I think (but not sure) that the NIOS masters do not support it, that's why you're seeing readyfordata being ignored. The DMA core does support it, so you may want to test your slave with it. This has nothing to do with the fact that it's being deprecated, though. It's always been optional. Avalon-MM isn't going away by a long shot. But Altera has chosen to deprecate the flow control feature in it in favor of adding Avalon-ST interfaces to the components whenever that capability is needed. Not that I'm actually going to argue with you if you prefer to use MM with flow control instead of ST. :) - Altera_Forum
Yup, what rbugalho is stating is the case. I think the old Avalon DMA does support flow control, so if you think you need it, try that. Otherwise, go with Avalon-ST.
Cheers, - slacker - Altera_Forum
Thank you for the answer. I do understand that Altera won't support flow control on MM interface, but here still be questions I do not understand:
1. If "readyfordata" was working before and now does not work anymore, but they let the developers to choose in the component editor, that makes not too much sense. It looks like a hanging-out-not-used wire from the box, what is ugly. 2. If they kept the option because of backward compatibility, that is a wrong solution, because the developer will get no any error message if re-compiles a (complicated) old design, but he will not understand why it does not work. An error message saves very long wasting time. 3. Perhaps I'm greenhorn, but don't know yet how can I use ST for a data connection when the inside target / source is user memory, what will be manipulated by C code. 4. If I want to use DMA, that needs MM interfaces, not ST ones. - Altera_Forum
You didn't understand rbugalho's answer. This feature isn't deprecated or not supported anymore, it is optional. It will only work if both the master and the slave support it. The Nios CPU doesn't support it, so you won't have flow control as long as you use the Nios CPU to access your peripheral.
Furthermore, use of flow control on the MM interface would freeze the CPU until the slave is ready to receive data, which may not be what you want. You can use a DMA engine such as the SGDMA to transfer data between memory and a component on an ST interface. This is the recommended way when you need flow control, and the CPU can do something else while the slave is stopping the flow. - Altera_Forum
>would freeze the CPU until the slave is ready to receive data
:-) Yes, that is true, if anyone has no experience in software writting. So this way: WriteDataSub { while (! peripheria_ready); ...write out data; } is wrong. This really freezes the CPU. But this code: WriteDataSub { if (! peripheria_ready) return; ...write out data; } Uisng timer or IRQ gives the chance to use the 2nd version using very thin slice of CPU time. - Altera_Forum
Your example is software flow control, not hardware flow control.
- Altera_Forum
One more interesting point. Just to discuss about that "readyfordata" locks the CPU. Okay, if we avoid my previous post regading to efficient code writting, moreover let say this option won't work. Here is the point:
Someone should tell me then why "waitrequest" is supported??? And it works even! :-) Using this also locks the CPU, btw. Depending on the C code... The only problem with waitrequest, that it is shared between the READ and WRITE sides, so there is no read_waitrequest and write_waitrequest. Additional logic needs to have them working separately. And what is the final result if you created and applied this additional logic? You have a working dataavailable for READ readyfordata for WRITE signals derived from waitrequest. So now who can explain me why these signals are not working originaly?:) - Altera_Forum--- Quote Start --- Your example is software flow control, not hardware flow control. --- Quote End --- Okay, then here is a hw flow. But honestly I simply have no idea what the hell can I do w/o software, if the source data is in user space, generated by software. Does not matter... Well: process (clk, readyfordata) begin if rising_edge(clk) if (readyfordata = '1') then do your job end if; Other stuffs --what are not locked at all:) end if; end process;
