Re: [Discuss-gnuradio] FPGA / new rx_buffer_inband

[Brian Padalino]

On Mon, Sep 8, 2008 at 2:27 PM, Eric Schneider <address@hidden> 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 (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 top level which would then just instantiate the generic wrapper
with most of the same generics already instantiated.

How many of the models in the megacells directory are we really using?
 Maybe it's time it gets cleaned up.

> 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.

Working with fully synchronous FIFOs, I'd say go and roll your own as
a dpram from the template.  If you're working with dual clocks, I'd
suggest you stick with their implementations unless you want to worry
about the clock boundary.  It's generally not fun and pretty
cumbersome.

> 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.

OK.  I think the interfaces are all broken since they are all
hardcoded and can't be extensible easily at the top level.  Maybe you
could replace those first, and then move on more functionality?

The only thing missing from the current setup is getting the RX and TX
timestamp clocks from the same source.  Change that and I think the
level of functionality promised by the previous inband code is pretty
much completed.  Don't you agree?

Brian