On Mon, Apr 23, 2007 at 10:43:10AM -0400, Brian Padalino wrote:
> On 4/23/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
> >I don't know :) What kind of problem should I expect when trying to go
> >from simulation to reality ?
>
> I'd run more simulations where there are a massive number of pack
On 4/23/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
I don't know :) What kind of problem should I expect when trying to go
from simulation to reality ?
I'd run more simulations where there are a massive number of packets
waiting to be sent, schedule things too close to each other, make the
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:
On 4/22/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
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;
On 4/22/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
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
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
On 4/21/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
Ok, I move the FIFOs outside next time I refactor this.
Perfect.
Yes, it makes much more sense. In the current design, the strobes are
generated by a separated block; would it be more logical to make the
strobes be generated by the tx_c
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
On Fri, Apr 20, 2007 at 07:09:19PM -0400, George Nychis wrote:
> Eric,
>
> Could you check over the Makefile.am and just base template that I checked
> in to my developer branch to make sure I am not missing anything? I
> checked that it successfully builds, but I just want to make sure I'm not
Eric,
Could you check over the Makefile.am and just base template that I checked in to my
developer branch to make sure I am not missing anything? I checked that it successfully
builds, but I just want to make sure I'm not missing anything major before beginning to
write tests.
Also, is the
On 4/20/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
Yes, it's this module. Any suggestion for a better name?
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
On Fri, Apr 20, 2007 at 05:17:36PM -0400, Brian Padalino wrote:
> On 4/20/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
> >Ok, so my usb_chan_reader needs some more work to handle that. I will
> >try to get this and some of the missing functionalities like reporting
> >overrun/underrun done tomo
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
On 4/20/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
Ok, so my usb_chan_reader needs some more work to handle that. I will
try to get this and some of the missing functionalities like reporting
overrun/underrun done tomorrow.
I am not sure this is where the tx_strobe is supposed to occur.
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
On 4/20/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
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 simulat
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
Eric Blossom wrote:
Not very hard.
Awesome.
There is a loopback interface in the current FPGA code. It's enabled
by writing to the FR_MODE register. Grep the verilog for "loopback",
and look at fpga_regs_common.{h,v}
Thanks :D
We want to test out using the loopback eventually, and ov
On Thu, Apr 19, 2007 at 05:17:06PM -0400, George Nychis wrote:
> I'm starting to work out some test code regarding the host end, and I was
> wondering how hard it will be when done testing to actually put a packet on
> the bus? I assume we can reuse some of the previous interface.
Not very hard
I'm starting to work out some test code regarding the host end, and I was wondering how
hard it will be when done testing to actually put a packet on the bus? I assume we can
reuse some of the previous interface.
Question from Thibaud: is the loopback interface working on the USRP, and how
to
20 matches
Mail list logo
