Brian Padalino wrote:
On 3/29/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
"This way we don't
need a dual clock fifo that can skip, only a single clock one"
Yes, that's wrong, I wanted to say that we need only standard dual clock
fifo or single clock fifo that can skip packets but we don't need a dual
clock fifo that can skip.
Agreed. I suppose we can always optimize later on. The only
reservation I have is in regards to the latency involved with doing
such a thing. When considering commands that may have small payloads,
we'd be able to send a command every 4us ( 256 / 64e6 ) since we'd
have to traverse through every location of the 512 byte packet. I'd
like to be able to process those faster.
Well I thought that we would use the same implementation of a fifo for
both tx_chan_fifo_X and tx_cmd_fifo so we can also use the skip
functionality there.
Do you want to use Megafunctions or write it out? You will need to
use an Altera LPM for the different bus widths, that's for sure. I'd
prefer to use a RAM instantiation in the tx_channel FIFOs and write my
own skipping functionality - but that's just because I completely
loathe forcing myself to stick to a specific architecture.
I would rather use Megafunctions for tx_usb_fifo and write my own for
tx_chan_fifo_X and tx_cmd_fifo. But I think it's better to first get the
whole thing working without skipping, and then optimize by writing out a
skipping fifo.
On a different note, I am also wondering what should be the course of
action if a command is sent down and it arrives late. Obviously the
command was supposed to be written, but is writing it late better than
not writing it at all? Is this more up to the implementation? Should
there be a command register guideline to write when dealing with this
sort of thing?
Yes, it looks like it could be a useful functionality that is not hard
to implement: we can add a register in the command block controlled by
the SPI bus that define if we drop or execute outdated commands.
Brian
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
