Like I said before, this bug is very unlikely to have been in the blocks from before.
Here are a couple things to try: 1) I'm concerned that your sync pulse (once at the very beginning of time) may be encountering a simulation boundary-condition. Would you mind delaying that pulse for a short time (10 clks) and see if that helps? 2) Could you turn off unscrambling and see what happens on the output? Without unscrambling, the first polarization comes out of both outputs for 1/2 an FFT window, and then the 2nd polarization. This could help constrain the problem to biplex FFT vs. unscrambler. 3) We have testbenches built for most CASPER blocks (though I don't remember where they are anymore). Could you see if you can reproduce the problem in the FFT testbench design? On Fri, Sep 19, 2008 at 5:15 AM, G Jones <[email protected]> wrote: > I just noticed a bug in the model I sent: I am unpacking a 18_17 complex > number as an 8_7 complex number. However, this does not affect the fact that > the two pol0 outputs are different. I am running the same test with the pink > blocks, and it seems there is a small difference between the two pol0 > outputs there as well, so this may be a very old bug, or it may be something > flawed with my test. > Glenn > > On Fri, Sep 19, 2008 at 12:58 AM, G Jones <[email protected]> wrote: >> >> Attached is a simple 7.1 model that illustrates the problem. The out0 from >> each fft is different even though the pol0 input is the same. The only >> difference is the pol1 input. >> The green block implementation is significantly different from the pink as >> far as the reordering, so this may be difficult to track down >> Glenn >> >> On Thu, Sep 18, 2008 at 6:14 PM, G Jones <[email protected]> wrote: >>> >>> Thanks for clarifying Aaron, I will go through the block carefully >>> tonight and see if I can trace down the "cross-coupling." >>> Glenn >>> >>> On Thu, Sep 18, 2008 at 6:12 PM, Aaron Parsons >>> <[email protected]> wrote: >>>> >>>> Your description of what the FFT block *should* do for n_inputs = 2^0 >>>> is correct. Assuming the output has been correctly descrambled into >>>> to separate the spectra of the two inputs, one input should not >>>> influence the other's spectrum in any way. This has been tested >>>> extensively in the library as I left it last summer. If this is not >>>> the behavior that you are seeing, then I suspect an error in one of >>>> the mask scripts has been introduced during this massive code >>>> migration. >>>> >>>> As for the PFB FIR, it is correct that in "biplex mode" it simply >>>> makes two copies of the same polyphase filter. >>>> >>>> On Thu, Sep 18, 2008 at 8:19 PM, G Jones <[email protected]> >>>> wrote: >>>> > Hello, >>>> > I am trying to use the green FFT block with number of simultaneous >>>> > inputs >>>> > set to 0. My understanding was that this makes a biplex fft that >>>> > processes >>>> > two independant data streams in parallel, thus the pol0 input should >>>> > have x0 >>>> > x1 x2... and pol1 should have y0 y1 y2 and then the pol0 output will >>>> > just >>>> > have frequencies related to pol0. However, when I simulate this, I >>>> > find that >>>> > the two inputs are interacting. If I set one input to a constant, the >>>> > output >>>> > is significantly different than if I connect the two inputs together >>>> > (in >>>> > which case I should get two identical copies at the output. >>>> > I did notice in the packetized correlator iBOB design (using pink >>>> > blocks) >>>> > the pfb_fir block preceeding the fft is set to biplex mode, but I had >>>> > assumed this didn't change the functionality of the block since a >>>> > biplex >>>> > pfb_fir block should be equivalent two single input pfb_fir blocks. >>>> > Can someone more clearly explain the functionality of the FFT block? >>>> > Thank you, >>>> > Glenn >>>> > >>>> >>>> >>>> >>>> -- >>>> Aaron Parsons >>>> >>>> 510-406-4322 (cell) >>>> 787-878-2612 x329 (arecibo office) >>>> 787-721-3991 (home) >>> >> > > -- Aaron Parsons 510-406-4322 (cell) 787-878-2612 x329 (arecibo office) 787-721-3991 (home)
