Re: [Discuss-gnuradio] FPGA / new rx_buffer_inband

[Brian Padalino]

On Sun, Sep 7, 2008 at 4:47 PM, Eric Schneider <address@hidden> wrote:
> They were from the 1 channel build.
>
> Here is a snippet from inband_2rxhb_2tx.rbf:
>
> ch: 0   s: 965745       delta: 8064
> ch: 1   s: 965745       delta: 8064
> ch: 0   s: 973809       delta: 8064
> ch: 1   s: 973809       delta: 8064
> ch: 0   s: 981873       delta: 8064
> ch: 1   s: 981873       delta: 8064
> ch: 0   s: 989937       delta: 8064
> ch: 1   s: 989937       delta: 8064
> ch: 0   s: 998001       delta: 8064
> ch: 1   s: 998001       delta: 8064
>
> The channels seem well aligned at least.

That looks good.

> Unfortunately, I am getting regular segfaults on 2rx...  :-/

That sounds bad.

> Resource Comparison:
>
> New 2 chan:
> ; Compilation Hierarchy Node                                 ; Logic Cells ;
> LC Registers ; Memory Bits ; M4Ks
> ;    |rx_buffer_inband:rx_buffer|                            ; 983 (59)    ;
> 697          ; 72576       ; 18
> ;       |packet_builder:pb|                                  ; 162 (162)   ;
> 19           ; 0           ; 0
> ;       |rx_channel_buffer:cb[0].chan_buf[0]|                ; 249 (68)    ;
> 209          ; 24192       ; 6
>
>
> Orig 2 chan:
> ; Compilation Hierarchy Node                                 ; Logic Cells ;
> LC Registers ; Memory Bits ; M4Ks
> ;    |rx_buffer_inband:rx_buffer|                            ; 546 (119)   ;
> 318          ; 114688      ; 28
> ;       |packet_builder:rx_pkt_builer|                       ; 137 (137)   ;
> 41           ; 0           ; 0
> ;       |fifo_1kx16:generate_channel_fifos[0].rx_chan_fifo|  ; 43 (0)      ;
> 33           ; 16384       ; 4
> ;       |fifo_4kx16_dc:rx_usb_fifo|                          ; 158 (0)     ;
> 134          ; 65536       ; 16
>
>
> I haven't done any optimization yet, so I'm not sure how much the logic cell
> utilization could be reduced.  I imagine a fair amount of it comes from my
> use of 64 bit wide data paths for header data.  I may try a hybrid version
> where the header data is muxed into a 16b header fifo.  There shouldn't be
> any performance penalty except for very short packets (< 64 bytes, e.g.
> command channel).  The header fifo capacity would be better utilized then as
> well.

There are a lot of different optimization tools built into Quartus
that will let you know where the largest parts of the design are so
you can focus on the points that really matter.

> The new code has 4+2 M4Ks (vs just 4) per channel, but with no usb_fifo (+16
> M4K), so memory comparison is not really apples to apples.  We could split
> the usb_fifo memory between the channels and give each 2-4k per channel.

I am disappointed by the prioritization scheme for the channels and
would have rather seen a more fair round-robin approach instead of a
priority encoder.

I hope you still plan on changing the interfaces of the modules to be
more generic.

Brian