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_buffer_inband
>
> On Sun, Sep 7, 2008 at 6:43 PM, Eric Schneider <[EMAIL PROTECTED]
> 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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
