> -Original Message-
> From: Brian Padalino [mailto:[EMAIL PROTECTED]
> If it's coming from two different parts of the chip with two
> independent reset signals, then yes there is always suspicion that
> they are unaligned.
I didn't realize there were different resets. It should be change
Eric Schneider wrote:
-Original Message-
From: George Nychis [mailto:[EMAIL PROTECTED]
I'm not sure what code you started from, Eric S. ... I had mentioned I
had some fixes in my own developer branch, one of which was making sure
there was only 1 counter:
http://gnuradio.org/trac/change
> -Original Message-
> From: George Nychis [mailto:[EMAIL PROTECTED]
> I'm not sure what code you started from, Eric S. ... I had mentioned I
> had some fixes in my own developer branch, one of which was making sure
> there was only 1 counter:
> http://gnuradio.org/trac/changeset/8987
> htt
> -Original Message-
> From: George Nychis [mailto:[EMAIL PROTECTED]
>
> Just going to chime in here with nothing really too important, because
> this isn't really my area. But, I am trying to follow discussion here,
> and I appreciate you working on this Eric.
>
> As for your segmentati
Eric Blossom wrote:
On Mon, Sep 08, 2008 at 04:49:23PM -0400, Brian Padalino wrote:
Problems arise when you want to ensure your FIFO is not full and not
empty. As a message passing mechanism, it works pretty well as just a
DPRAM. As the FIFO, there are counters involved which can cause
timin
On Mon, Sep 08, 2008 at 04:49:23PM -0400, Brian Padalino wrote:
>
> Problems arise when you want to ensure your FIFO is not full and not
> empty. As a message passing mechanism, it works pretty well as just a
> DPRAM. As the FIFO, there are counters involved which can cause
> timing issues when
Just going to chime in here with nothing really too important, because
this isn't really my area. But, I am trying to follow discussion here,
and I appreciate you working on this Eric.
As for your segmentation faults, if you e-mail me your RBF where you're
getting these, I can poke at why you
On Mon, Sep 8, 2008 at 4:26 PM, Eric Schneider <[EMAIL PROTECTED]> wrote:
> I have no direct knowledge regarding this, but from reading the Cyclone
> datasheets it seems like the MK4 blocks natively support two fully
> independent asynchronous r/w ports. Where would the problems arise? A
> clock
> -Original Message-
> From: Brian Padalino [mailto:[EMAIL PROTECTED]
>
> No. It just seems silly to have a hard wrapper (fifo_1kx16_dc_la) for
> a generic wrapper (dcfifo). It would be nice if there was an
> identification of the different FIFOs and made those aspects generics
> to a t
On Mon, Sep 8, 2008 at 2:27 PM, Eric Schneider <[EMAIL PROTECTED]> wrote:
> Thanks for the input Brian. A few comments inline.
>
> Are you talking about not using the megacells at all? I see your point, but
> I don't see it as a high priority.
No. It just seems silly to have a hard wrapper (fif
Thanks for the input Brian. A few comments inline.
> -Original Message-
> From: Brian Padalino [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 08, 2008 7:58 AM
> To: Eric Schneider
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] FPGA / new rx_buf
On Sun, Sep 7, 2008 at 6:43 PM, Eric Schneider <[EMAIL PROTECTED]> wrote:
> On that note, I'd like to get refactoring suggestions.
I don't like all the different memory megacells. Wrap the
altsyncram/fifo with the generics you require and pass those in using
the same module underneath. It reduce
> -Original Message-
> From: Brian Padalino [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 07, 2008 3:03 PM
> I am disappointed by the prioritization scheme for the channels and
> would have rather seen a more fair round-robin approach instead of a
> priority encoder.
Man, tough cro
On Sun, Sep 7, 2008 at 4:47 PM, Eric Schneider <[EMAIL PROTECTED]> wrote:
> They were from the 1 channel build.
>
> Here is a snippet from inband_2rxhb_2tx.rbf:
>
> ch: 0 s: 965745 delta: 8064
> ch: 1 s: 965745 delta: 8064
> ch: 0 s: 973809 delta: 8064
> ch: 1 s: 973809
> -Original Message-
> From: Brian Padalino [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 07, 2008 7:21 AM
>
> Were these results for the 2 channel mode?
>
> What is the size difference within the USRP when using 2 channels? Is
> it significant or pretty insignificant?
They were f
On Sun, Sep 7, 2008 at 4:28 AM, Eric Schneider <[EMAIL PROTECTED]> wrote:
> For those interested,
>
>
>
> I've committed my changes to the inband RX buffering subsystem. It is
> available at:
>
>
>
> http://gnuradio.org/svn/gnuradio/branches/developers/ets/inband/usrp/fpga
>
>
>
> Source only at t
16 matches
Mail list logo
