On 3/22/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
So the fpga would only use fifo and push the data to next one. It does not work if shared RAM is used to avoid copy between buffers; or I am completely wrong and I fail to understand your point.
You are correct on that one unless you setup an internal linked list of starting packets and their start times, then you can possibly read the values with slight offsets for clock latencies out of the same RAM. This, I would argue, is a bit too complicated for the beginning of the design but may want to be revisited later on. Maybe I should expand on this idea. If we keep a mapping of pointers to packets along with their respective times of interest to start, even if we had something going out at the same timestamp, we could theoretically read the data in a staggered fashion such that if there are multiple packets to process at once, we read one of the pieces of data at a time for each packet and send it along the signal chain until that packet no longer needs servicing. This would cause us to have a finite number of packets we could process at one time (# of channels + control) since we would need 1 clock cycle to read the next packet location for each of the packets, register them all, then send out the "ship these samples off" signal. For packets that have different sizes, we will have to keep track of how many bytes of data are left to read and take them out of the queue when it is all finished. This wouldn't really be a FIFO, but really a RAM mapping that we would manipulate pretty heavily. It's an interesting idea, and can probably be engineered to be pretty cool. It will also be conducive to lowering the resolution of the 32-bit timestamp to do things since we'll have to multiplex the pulling of data out of the RAM. I'll think about this method and what problems there may be, but give me feedback. What do you think of this? See how you can get the reads all done in one large FIFO instead of needing all the little ones? See how much extra complexity it adds to the FSM that reads and feeds the TX chain?
Yes, currently 39 out of 52 M4K blocks are used. A fifo of 8192 bytes takes up 16 M4K whereas a fifo of 32 bytes takes up 2 M4K.
How many TX and RX chains does that include? Can we make a table of how many M4K blocks are used per TX and per RX channel that is added to the USRP? That would be helpful in defining constraints.
Then the two unknown are how many channels there are and how much data to we want to be able to burst.
Right - that somewhat becomes a latency issue. How quickly can we get data down once a flag is sent to the host saying "a FIFO is half full - requesting more data". Does this control really need to be in there? How much memory is within the FX2 for USB endpoints? Could that be a temporary place to store packets and from there is where the request for more data comes? Any ideas Eric? Brian _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
