Re: [Discuss-gnuradio] FPGA / new rx_buffer_inband

[Brian Padalino]

On Mon, Sep 8, 2008 at 4:26 PM, Eric Schneider <address@hidden> 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 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.  :-)

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 dealing with asynchronous clocks.

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

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.

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

Such as?  Is the design fully constrained?  Yes, 64MHz can be pushing
the limits for that part as it gets full - especially with deep logic.

Are you sure you're currently meeting timing?

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

OK.

Brian