RE: [Discuss-gnuradio] FPGA / new rx_buffer_inband

[Eric Schneider]

> -----Original Message-----
> From: Brian Padalino [mailto:address@hidden
> 

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

OK, I get you now.
 
> How many of the models in the megacells directory are we really using?
>  Maybe it's time it gets cleaned up.

I haven't inventoried them, but I think a lot of them are used, depending on
the particular configuration being built.

> 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 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 boundary buffer would be needed to pass size info but that sounds like
a good generic construct to have handy anyway.  Maybe I'll play around with
it when I don't have anything better to do. E.g not anytime soon.  :-)
 
> 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?

I'll agree when rx and tx timestamps are accurate and the tx scheduling
works well (there is at least one quick fix needed there).  I think the new
rx code still has some issues to be worked out too.  As soon as it "works",
I'm good.

I'm not even too concerned about the dual timestamp counters at the moment.
Is there any suspicion that they are ever unaligned?

There does seem to be a real concern for not meeting timing requirements
too.  I haven't done any in-depth testing but I get worrisome timing
warnings during synthesis.  It seems that the master_clock rates are pushing
the boundaries of the current design.

There are also some inband protocol ambiguities that I think should be
addressed before endeavoring forward on major refactoring.  I'll post more
about that some other time.

--ets