On Mon, Mar 26, 2007 at 03:15:22PM -0400, Thibaud Hottelier wrote:
> I updated the wiki page
> (http://gnuradio.org/trac/wiki/UsrpTxModifications) again, added the
> command block FSM and renamed the fifos as Eric proposed. If nobody see
> any major problem, I can start to implement these modifi
On Mon, Mar 26, 2007 at 03:15:22PM -0400, Thibaud Hottelier wrote:
> I updated the wiki page
> (http://gnuradio.org/trac/wiki/UsrpTxModifications) again, added the
> command block FSM and renamed the fifos as Eric proposed. If nobody see
> any major problem, I can start to implement these modifi
Brian Padalino wrote:
Looks cool to me.
32-bits should be OK. What problems do you think you may have an issue
with?
None particularly. There is no 32 bits wide bus in the fpga currently,
so I thought that it might use too many connections.
You will probably have to create your own FI
On 3/26/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
I updated the wiki page
(http://gnuradio.org/trac/wiki/UsrpTxModifications) again, added the
command block FSM and renamed the fifos as Eric proposed. If nobody see
any major problem, I can start to implement these modifications by
working
I updated the wiki page
(http://gnuradio.org/trac/wiki/UsrpTxModifications) again, added the
command block FSM and renamed the fifos as Eric proposed. If nobody see
any major problem, I can start to implement these modifications by
working on the tx_usb_block.
Here is what I think that could
Brian Padalino wrote:
A comment with the USB Block - I believe all the processing going into
the USB FIFO is done within the FX2. Moreover, i don't know why
you're keeping the byte_count around - it's coming in with the packet
header.
Are you sure? I thought the FX2 was only buffering the packe
On Sat, Mar 24, 2007 at 05:59:06PM -0400, Brian Padalino wrote:
> On 3/24/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
> >I updated the wiki paged and added state machines.
> >(http://gnuradio.org/trac/wiki/UsrpTxModifications)
>
> A comment with the USB Block - I believe all the processing go
On Sat, Mar 24, 2007 at 05:03:00PM -0400, Thibaud Hottelier wrote:
> I updated the wiki paged and added state machines.
> (http://gnuradio.org/trac/wiki/UsrpTxModifications)
>
> Here are the issues still unresolved that I am aware of:
>
> - Are the overrun/underrun flag per channel or global? Fro
On Sat, Mar 24, 2007 at 01:46:21PM -0400, Thibaud Hottelier wrote:
> Eric Blossom wrote:
> >On Fri, Mar 23, 2007 at 02:45:54PM -0400, Thibaud Hottelier wrote:
> >I assume that you just copy the received USB packet (including the
> >8-byte header) into the channel FIFO. The underrun processing rea
On 3/24/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
I updated the wiki paged and added state machines.
(http://gnuradio.org/trac/wiki/UsrpTxModifications)
A comment with the USB Block - I believe all the processing going into
the USB FIFO is done within the FX2. Moreover, i don't know why
I updated the wiki paged and added state machines.
(http://gnuradio.org/trac/wiki/UsrpTxModifications)
Here are the issues still unresolved that I am aware of:
- Are the overrun/underrun flag per channel or global? From which fifo
should they be generated?
- When a packet is outdated I still
Eric Blossom wrote:
On Fri, Mar 23, 2007 at 02:45:54PM -0400, Thibaud Hottelier wrote:
Eric Blossom wrote:
On Thu, Mar 22, 2007 at 03:33:08PM -0400, Brian Padalino wrote:
On 3/22/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
I can copy the sample to a fifo, but I still have 3 processes tha
On Fri, Mar 23, 2007 at 03:21:03PM -0700, Eric Blossom wrote:
> On Fri, Mar 23, 2007 at 02:45:54PM -0400, Thibaud Hottelier wrote:
>
> > For each channel fifo, a process would wait for the timestamps to match
> > the time register and then write the next <#samples> to the
> > corresponding chann
On Fri, Mar 23, 2007 at 02:59:37PM -0400, Brian Padalino wrote:
> On 3/23/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
> >So, let me summarize:
> >
> >One dual clock fifo (usb_fifo) to buffer the packet from the FX2. One
> >process store the data from the usb while one other process read them
>
On Fri, Mar 23, 2007 at 02:45:54PM -0400, Thibaud Hottelier wrote:
> Eric Blossom wrote:
> >On Thu, Mar 22, 2007 at 03:33:08PM -0400, Brian Padalino wrote:
> >>On 3/22/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
> >>>I can copy the sample to a fifo, but I still have 3 processes that want
> >>>
Brian Padalino wrote:
On 3/23/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
So, let me summarize:
One dual clock fifo (usb_fifo) to buffer the packet from the FX2. One
process store the data from the usb while one other process read them
and splits commands (stored in cmd_fifo) from data (st
On 3/23/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
So, let me summarize:
One dual clock fifo (usb_fifo) to buffer the packet from the FX2. One
process store the data from the usb while one other process read them
and splits commands (stored in cmd_fifo) from data (stored in
chan0_fifo, cha
Eric Blossom wrote:
On Thu, Mar 22, 2007 at 03:33:08PM -0400, Brian Padalino wrote:
On 3/22/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
I can copy the sample to a fifo, but I still have 3 processes that want
to use the RAM a the same time: One to progressively store the packets
coming from
On Fri, Mar 23, 2007 at 10:15:12AM -0400, Brian Padalino wrote:
> On 3/23/07, Eric Blossom <[EMAIL PROTECTED]> wrote:
> >I think I steered us down the wrong path with the shared RAM idea.
> >We really do want a dedicated read port for each channel in the Tx
> >direction. This is easy if we assigne
On 3/23/07, Eric Blossom <[EMAIL PROTECTED]> wrote:
I think I steered us down the wrong path with the shared RAM idea.
We really do want a dedicated read port for each channel in the Tx
direction. This is easy if we assigned a FIFO (or dedicated RAM) per
channel.
Sounds good. It really should
On Thu, Mar 22, 2007 at 06:44:01PM -0400, Thibaud Hottelier wrote:
> A quick update while I am understanding your previous message.
>
> The Rx and Tx buffers use 16 blocks each.
This is probably overkill. As I mentioned earlier, we weren't using
the memory, so we just assigned it to these buffer
On Thu, Mar 22, 2007 at 04:51:10PM -0400, Brian Padalino wrote:
> 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 fai
On Thu, Mar 22, 2007 at 04:34:49PM -0400, Thibaud Hottelier wrote:
> Brian Padalino wrote:
> >
> >Did you ever compile the design with Quartus II to get a report of how
> >many resources we can use for these FIFOs? It might be a good idea to
> >see how much space we have in block RAM to distribute
On Thu, Mar 22, 2007 at 03:33:08PM -0400, Brian Padalino wrote:
> On 3/22/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
> >I can copy the sample to a fifo, but I still have 3 processes that want
> >to use the RAM a the same time: One to progressively store the packets
> >coming from the usb bus,
A quick update while I am understanding your previous message.
It looks like each Rx chain takes up 3 blocks, but the Tx chains does
not use any memory block. (Actually Tx0 uses one block but not Tx1).
The Rx and Tx buffers use 16 blocks each.
Thibaud
Brian Padalino wrote:
On 3/22/07, Thib
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 setu
Brian Padalino wrote:
On 3/22/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
I can copy the sample to a fifo, but I still have 3 processes that want
to use the RAM a the same time: One to progressively store the packets
coming from the usb bus, one to copy the samples into the corresponding
ch
On 3/22/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
I can copy the sample to a fifo, but I still have 3 processes that want
to use the RAM a the same time: One to progressively store the packets
coming from the usb bus, one to copy the samples into the corresponding
channel fifo and one to c
Brian Padalino wrote:
On 3/22/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
Yes, I forgot that the packet are ordered by timestamps, which solved
the fragmentation issues. However I cannot find an Altera RAM
megafunction that provides more that two independent ports. This is not
enough and wi
On 3/22/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
Yes, I forgot that the packet are ordered by timestamps, which solved
the fragmentation issues. However I cannot find an Altera RAM
megafunction that provides more that two independent ports. This is not
enough and will prevent the FPGA fro
Brian Padalino wrote:
On 3/21/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
So, if I have correctly understood, I would use dual_clock ram component
(altsyncram for instance) and only pass the packet address (and maybe
its length) to the next block. If the whole packet (including padding)
is
On 3/21/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
So, if I have correctly understood, I would use dual_clock ram component
(altsyncram for instance) and only pass the packet address (and maybe
its length) to the next block. If the whole packet (including padding)
is stored in the RAM then
So, if I have correctly understood, I would use dual_clock ram component
(altsyncram for instance) and only pass the packet address (and maybe
its length) to the next block. If the whole packet (including padding)
is stored in the RAM then it's easy because all my memory block are the
same size
On Tue, Mar 20, 2007 at 08:07:04PM -0400, Brian Padalino wrote:
> The length of the packet is built into the packet, isn't it? Do we
> need to keep a count of the packet length, or just take it from the
> packet itself?
>
> Brian
The payload length is in the packet. The total length including t
On Wed, Mar 21, 2007 at 12:52:30PM -0400, Brian Padalino wrote:
> On 3/21/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
> >How do the fpga know is data is interleaved or not ?
>
> I believe all samples sent down is interleaved over USB to 16-bit I
> followed by 16-bit Q samples.
See below for
On Wed, Mar 21, 2007 at 12:45:00PM -0400, Thibaud Hottelier wrote:
> How do the fpga know is data is interleaved or not ?
>
> I am still worried about the number of fifo that will be used and their
> size. The FPGA looks pretty full. Is there a way to have a memory
> separated from the FPGA that
On 3/21/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
How do the fpga know is data is interleaved or not ?
I believe all samples sent down is interleaved over USB to 16-bit I
followed by 16-bit Q samples. These can be concatenated (since they
are of the same sample time) to 1 32-bit number
How do the fpga know is data is interleaved or not ?
I am still worried about the number of fifo that will be used and their
size. The FPGA looks pretty full. Is there a way to have a memory
separated from the FPGA that I could access through a bus?
Thibaud
Brian Padalino wrote:
Something e
Something else I noticed was with the channel definition stating that
the IQ data is to be interleaved. This shouldn't necessarily happen
and there shouldn't be a problem with having the block rams be in a
x32 configuration and each location has an IQ pair associated with it.
This would reduce do
The length of the packet is built into the packet, isn't it? Do we
need to keep a count of the packet length, or just take it from the
packet itself?
Brian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listin
I have updated the wiki page
(http://gnuradio.org/trac/wiki/UsrpTxModifications) to add the processes
description in pseudo-code. If it still looks good to you I will do the
same for the receiving side so we can I have a global view of what's
going on. It will be done tomorrow.
Thibaud
___
Brian Padalino wrote:
On 3/20/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
About the pulling/pushing thing: I though that I would have one process
in the usb block writing the usb_fifo data on the bus and one other
process in the channel block that would read them from the bus and store
them
On Mon, Mar 19, 2007 at 06:24:16PM -0400, Thibaud Hottelier wrote:
> Ok, I will modify it for pushing instead of pulling packets.
>
> Can I assume that the data will arrive ordered by timestamps?
Yes, I think that's a reasonable assumption.
> If not then I have to use one data_queue and one samp
On 3/20/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
About the pulling/pushing thing: I though that I would have one process
in the usb block writing the usb_fifo data on the bus and one other
process in the channel block that would read them from the bus and store
them. This is neither pulli
About the pulling/pushing thing: I though that I would have one process
in the usb block writing the usb_fifo data on the bus and one other
process in the channel block that would read them from the bus and store
them. This is neither pulling nor pushing right ? Can I do this with one
single pr
On 3/19/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
Ok, I will modify it for pushing instead of pulling packets.
Can I assume that the data will arrive ordered by timestamps ? If not
then I have to use one data_queue and one samples_fifo per channel,
isn't that too much?
I am pretty posit
Ok, I will modify it for pushing instead of pulling packets.
Can I assume that the data will arrive ordered by timestamps ? If not
then I have to use one data_queue and one samples_fifo per channel,
isn't that too much?
Thibaud
Brian Padalino wrote:
> A comment on your description:
>
> It's eas
A comment on your description:
It's easier to push the separated data into your FIFOs rather than pull them in.
Brian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hi,
I have created a wiki page describing what USB packet parsing could look
like for the transmit chain:
http://gnuradio.org/trac/wiki/UsrpTxModifications
I am wondering what you think of it; if it is completely wrong or if it
could work with some modifications. I made a wiki page so you can mo
49 matches
Mail list logo
