Re: [Discuss OpenCPI] FSK BER Test

From: Brian Padalino <bpadalino_at_gmail.com>
Date: Fri, 06 Mar 20 13:33:41 -0500

On Fri, Mar 6, 2020 at 1:16 PM Davis Hoover <dhoover_at_geontech.com> wrote:

> Your willingness to inquire as to existing capabilities, and collaborate on
> generic, reusable solutions is much appreciated.
>

Not a problem. I'm pretty impressed with the framework so it's decently
fun getting more into it.


>
> HISTORY OF NON-GENERIC BER CAPABILITIES:
> There are some AD9361-in-the-loop test apps (assets project
> ad9361_adc_test/ad9361_dac_test) which perform BER calculations, but these
> are very AD9361-specific at the moment.
>

Thanks for pointing this out. I saw them previously for testing the
ADC/DAC BIST modes and found them useful.


>
> IDEAS FOR GENERIC BER CAPABILITIES:
> * new xor component (many use cases), new switch component (many use
> cases), new BER calc component
> * example BER app:
> - known-good data source -> xor component input port in0
> - data source on which to calculate BER -> xor component input port in1
> - xor component output port -> some component to count number of 1s,
> number of 0s, BER property= nOnes/(nZeros+nOnes)
> - pattern-switch component only turns the switch "on" to send data to
> xor once a (sync) pattern is observed
> * might this be suitable to fit your use case?
> * I have some preliminary implementations for xor.hdl, and switch.hdl w/
> unit tests - I can commit to a gitlab branch if you think it useful
>

I definitely think they would be useful, though, in the past, I've
implemented this using an LFSR and an FSM which is first UNLOCKED and uses
the input bits to try to feed an LFSR prediction. Once N bits have been
successfully predicted from the data stream, we switch over to LOCKED and
we start counting bits. If we ever get a point where ~50% of the incoming
bits are in error, we transition back to UNLOCKED. This seems to be the
thing that would control the pattern-switch component, with the xor
component being the comparison of total bits to 1 bits. I suppose this
piece would be an LFSR sync which would be the known-good data source as
well as the pattern switch input? Or does it just turn into a single block
with 2 outputs?

When it comes to development, it seemed potentially easier to write it all
as RCC components first and then switch to HDL components afterwards. Is
thsi the way development of most signal processing applications are done,
or does development typically dive directly into the HDL immediately?

I definitely won't say no to a pushed branch with some HDL components to
it. It might even give me a chance to write the RCC components as the
comparison.

Brian


Received on Fri Mar 06 2020 - 18:33:41 CST