RE: [Discuss-gnuradio] FPGA / new rx_buffer_inband

[Eric Schneider]

Thanks for the input Brian.  A few comments inline.

> -----Original Message-----
> From: Brian Padalino [mailto:address@hidden
> Sent: Monday, September 08, 2008 7:58 AM
> To: Eric Schneider
> Cc: address@hidden
> Subject: Re: [Discuss-gnuradio] FPGA / new rx_buffer_inband
> 
> On Sun, Sep 7, 2008 at 6:43 PM, Eric Schneider <address@hidden
> group.com> 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 reduces clutter for having more of the
> same thing.

Are you talking about not using the megacells at all?  I see your point, but
I don't see it as a high priority.  

However, there are areas that I think fifos are restrictive/inefficient  A
lot of the logic ultimately boils down to maintaining counters to gate the
fifo counters; it seems redundant.  Why not just use the dp-ram directly?
Not to mention that non-sequential access could be handy in some places.

> You shouldn't negate the clock going into the asynchronous FIFOs at
> the rx_channel_buffer level - do it at the input of the module as it
> is more clear what you intend.

I had thought about just inverting usbclock so all the modules would be
posedge.  The negedge logic was a last minute change, I had overlooked that
aspect of the FX2 interface initially.
 
> I'd separate out the FIFO muxing to its own module.  I'd separate out

Yes.

> the banking of the FIFOs (command and data) to be their own individual

I'd like to see the command channel I/O more integrated and away from the
other channels.

> modules.  I'd try to accommodate {1,2,4,8,16} bits per sample.  I'd
> try to accommodate both complex and real sampling for each of the

The issue of I/Q or not is kind of tricky, since it means the difference
between 1 and 2 channels, and the logic would span multiple channel buffers.
I think a new module in front of the buffers is in order.  A sample switcher
of sorts.

> different bit widths used.  I'd make buffer lengths generic at the top
> level.  I'd accommodate for channel loop-back, bypassing the HB/CIC
> filters and simply strobing the samples back to the RX side.

I'm pretty sure that logic would be outside of the channel buffer.  Maybe a
feature of the "sample switcher".
 
> Those are just some ideas.  Make the interfaces as simple as possible
> and most everything should fall right into place.

All good ideas.  FYI, I am focused on getting functionality in the near
term.  I certainly want the architecture to be as well designed as possible,
but getting the functionality with the least changes/time is my first
priority.

--ets