Something surprised me in the current rx_buffer code: It seems that if
samples are received from different rx_chains at the same time, they
will be mixed in the next USB packet toward the host. Has the host a way
to separate them? Shall I keep this behaviour or separate samples by
channel when USB
Hello,
Here is a diagram of the Rx side.
http://www.andrew.cmu.edu/user/thottelt/rx.png
I plan to use a fifo to cross clock domains because it's simpler than a
delay cell. Samples and commands will be stored in dual port fifos (one
per channel) A reader will poll them: if there are samples or com
Brian Padalino wrote:
Sounds fun. Are you sure you're ready for a live test?
I don't know :) What kind of problem should I expect when trying to go
from simulation to reality ?
You don't need to do this. Just don't connect up the tx_strobe -
doesn't that solve the problem? You shouldn
Brian Padalino wrote:
I have just refactored the code so that the fifos are out of the
readers. I also added samples format handling (only 16 bits interleaved
complex so far). I am looking forward to testing this; George told me he
will be able to send usb packets on Tuesday.
Perfect.
Yes
According to your diagram here:
http://gnuradio.org/trac/wiki/UsrpTxModifications
Maybe we should have a tx_usb_fifo, tx_usb_fifo_reader, tx_chan_fifo,
tx_chan_fifo reader, tx_cmd_fifo_reader (the tx_chan_fifo and
tx_cmd_fifo are essentially the same thing, but the tx_cmd_fifo_reader
should figu
Brian Padalino wrote:
I am not sure this is where the tx_strobe is supposed to occur. I
think it's in whatever reads your individual channel FIFOs and feeds
the CIC filters (unless usb_chan_reader is the module, and is just
named very strangely).
Yes, it's this module. Any suggestion for a be
Brian Padalino wrote:
> There should be absolutely no glue logic between the modules within a
> top entity possibly called mblock_processing. The inputs should feed
> the specialized USB FIFOs, and the outputs should feed the separate
> CIC channel filters (complex).
>
> Everything else from ther
Hi,
I moved all my small testing blocks from ModelSim to the Quartus source
tree. I am writing the glue code between the modules so we should have
the basic Tx functionality working relatively soon. But before that, I
would like to simulate to whole Tx block in ModelSim, so I need some
inform
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
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
Brian Padalino wrote:
On 3/29/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
My idea was that the process in the fpga that read usb_bus can store the
packet and the total length is reached, ignore the data coming because
we know its padding. That process is the first process in the wik
Brian Padalino wrote:
On 3/29/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
I CC'd the list, so Eric can participate to this discussion.
The more the merrier.
Yes but the only dual clock fifo is tx_usb_fifo, right? For this one we
can use the Altera dual clock fifo. The only
I CC'd the list, so Eric can participate to this discussion.
Brian Padalino wrote:
On 3/28/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
I noticed two things:
The fifo does not need to be dual clock because we only use it for the
tx_chan_fifo_X.
The FX2 directly toggles the w
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
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
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 pro
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) fro
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
, 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 in
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 corresp
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
enou
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 paddi
same size, but if I have different packet length then it becomes hairy
to deal with because there are RAM fragmentation issues. Is it ok to
store the padding to simplify the processing ?
Eric Blossom wrote:
On Wed, Mar 21, 2007 at 12:45:00PM -0400, Thibaud Hottelier wrote:
How do the fpga know is
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
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
process ?
Thibaud
Brian Padalino wrote:
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 c
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
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
Hello,
We (George and me) have added a schedule page to the wiki :
http://gnuradio.org/trac/wiki/InBandSignalingSched
Could you please look it over, add anything missing and suggest
deadline. I can work on the FPGA, but I don't think I will be very
efficient. It would be great if you could sugges
Brian Padalino wrote:
> Hi Thibaud,
>
> Here is my response as to how I understand things to work - which
> could be completely wrong.
>
> On 2/27/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
>> Hi all,
>>
>> First of all, I would like to make sure
Hi all,
First of all, I would like to make sure that I have understood what is
going to be modified. I have made a diagram with the whole Gnuradio
component stack: http://img168.imageshack.us/img168/415/groveralleb2.png
1) The new usb packet will be encoded/decoded in the gnuradio uspr
driver and
Hi all,
I have dived into the fpga code and I have now much clearer picture of
what is going on, but also much more questions :)
The Tx CORDIC is disabled in the code I checked out. Why?
I have failed to find a description of how to control the AD9862 chip on
the Analog Device web site. Where is
35 matches
Mail list logo
