Re: [casper] Weird FFT block problem

[Jack Hickish]

Ah,

I would guess what happens is that you have delay stages being implemented
in bram where the stage delay is fewer clock cycles than the bram latency,
causing an initialization implosion. I suspect if you changed the "minimum
delay implemented in bram" (or whatever it's called) parameter to be a bit
higher you might not get this error. But as you say, >10 is very excessive,
and I'd be surprised if it makes any difference to your timing. I think if
you open your mapped design in planahead/fpga editor you'll find that
almost all that latency is being wrapped up in a single slice as a shift
register. But hey, if it works it works :)

Jack

On Tue, 6 Oct 2015 at 16:42 Michael D'Cruze <
michael.dcr...@postgrad.manchester.ac.uk> wrote:

> Hi Jack,
>
>
>
> After cycling through the settings I think I’ve isolated the issue. I was
> a bit quick to declare a solution….i was able to repeat the problem. The
> problem occurs when the BRAM latency is set to >10. I appreciate this may
> seem excessive in any case however as you know I’m messing with settings to
> get a 2^17 point FFT block to compile at 256 MHz…
>
>
>
> When the problem first arose I grabbed the latest casper-astro-soak-test
> commit, which didn’t solve the immediate issue.
>
>
>
> Perhaps someone could confirm that bram latencies >10 causes this issue?
> It’s a 2^17 point FFT with fanout 1.
>
>
>
> BW
> Michael
>
>
>
> *From:* Jack Hickish [mailto:jackhick...@gmail.com]
> *Sent:* 06 October 2015 15:50
> *To:* Michael D'Cruze; casper@lists.berkeley.edu
> *Subject:* Re: [casper] Weird FFT block problem
>
>
>
> Hi Michael,
>
>
>
> If the initialisation script fails half way through drawing then often
> you'll be left with a bunch of blocks half connected, so I think that's
> (probably) a symptom rather than a cause of the issue. Are you using the
> latest casper-astro branch? Do you remember what FFT parameters you were
> using? Was it a block fresh from the library of one you had previously
> configured? If the latter, do you remember how it was configured?
>
> Gonna be tricky to track this down if it can't be recreated...
>
>
>
> Cheers,
>
> Jack
>
>
>
> On Tue, 6 Oct 2015 at 15:25 Michael D'Cruze <
> michael.dcr...@postgrad.manchester.ac.uk> wrote:
>
> Hi all,
>
>
>
> I had an odd problem while messing about with the FFT block today – on
> setting a new combination of parameters and attempting a new compile, an
> error came up which I’ve never seen before. Something along the lines of an
> initialisation error in the FFT. On inspection, the component blocks within
> the FFT were in pieces and not linked up correctly. In the biplex core
> itself there was nothing except the in/out ports. This is very strange and
> I can’t find anything similar on the mailing list. I’ve solved it by
> erasing and re-cloning the CASPER libraries, however wondered if anyone had
> a clue why this would happen? FYI update_blocks didn’t help.
>
>
>
> Thanks
>
> Michael
>
>

Re: [casper] Weird FFT block problem

[Jack Hickish]

Hi Michael,

If the initialisation script fails half way through drawing then often
you'll be left with a bunch of blocks half connected, so I think that's
(probably) a symptom rather than a cause of the issue. Are you using the
latest casper-astro branch? Do you remember what FFT parameters you were
using? Was it a block fresh from the library of one you had previously
configured? If the latter, do you remember how it was configured?
Gonna be tricky to track this down if it can't be recreated...

Cheers,
Jack

On Tue, 6 Oct 2015 at 15:25 Michael D'Cruze <
michael.dcr...@postgrad.manchester.ac.uk> wrote:

> Hi all,
>
>
>
> I had an odd problem while messing about with the FFT block today – on
> setting a new combination of parameters and attempting a new compile, an
> error came up which I’ve never seen before. Something along the lines of an
> initialisation error in the FFT. On inspection, the component blocks within
> the FFT were in pieces and not linked up correctly. In the biplex core
> itself there was nothing except the in/out ports. This is very strange and
> I can’t find anything similar on the mailing list. I’ve solved it by
> erasing and re-cloning the CASPER libraries, however wondered if anyone had
> a clue why this would happen? FYI update_blocks didn’t help.
>
>
>
> Thanks
>
> Michael
>

[casper] Weird FFT block problem

[Michael D'Cruze]

Hi all,

I had an odd problem while messing about with the FFT block today - on setting 
a new combination of parameters and attempting a new compile, an error came up 
which I've never seen before. Something along the lines of an initialisation 
error in the FFT. On inspection, the component blocks within the FFT were in 
pieces and not linked up correctly. In the biplex core itself there was nothing 
except the in/out ports. This is very strange and I can't find anything similar 
on the mailing list. I've solved it by erasing and re-cloning the CASPER 
libraries, however wondered if anyone had a clue why this would happen? FYI 
update_blocks didn't help.

Thanks
Michael

Re: [casper] Weird FFT block problem

[Michael D'Cruze]

Hi Jack,

After cycling through the settings I think I’ve isolated the issue. I was a bit 
quick to declare a solution….i was able to repeat the problem. The problem 
occurs when the BRAM latency is set to >10. I appreciate this may seem 
excessive in any case however as you know I’m messing with settings to get a 
2^17 point FFT block to compile at 256 MHz…

When the problem first arose I grabbed the latest casper-astro-soak-test 
commit, which didn’t solve the immediate issue.

Perhaps someone could confirm that bram latencies >10 causes this issue? It’s a 
2^17 point FFT with fanout 1.

BW
Michael

From: Jack Hickish [mailto:jackhick...@gmail.com]
Sent: 06 October 2015 15:50
To: Michael D'Cruze; casper@lists.berkeley.edu
Subject: Re: [casper] Weird FFT block problem

Hi Michael,

If the initialisation script fails half way through drawing then often you'll 
be left with a bunch of blocks half connected, so I think that's (probably) a 
symptom rather than a cause of the issue. Are you using the latest casper-astro 
branch? Do you remember what FFT parameters you were using? Was it a block 
fresh from the library of one you had previously configured? If the latter, do 
you remember how it was configured?
Gonna be tricky to track this down if it can't be recreated...

Cheers,
Jack

On Tue, 6 Oct 2015 at 15:25 Michael D'Cruze 
>
 wrote:
Hi all,

I had an odd problem while messing about with the FFT block today – on setting 
a new combination of parameters and attempting a new compile, an error came up 
which I’ve never seen before. Something along the lines of an initialisation 
error in the FFT. On inspection, the component blocks within the FFT were in 
pieces and not linked up correctly. In the biplex core itself there was nothing 
except the in/out ports. This is very strange and I can’t find anything similar 
on the mailing list. I’ve solved it by erasing and re-cloning the CASPER 
libraries, however wondered if anyone had a clue why this would happen? FYI 
update_blocks didn’t help.

Thanks
Michael

[casper] FFT problems

[Jonathon Kocz]

Hi Casper,

While we're talking weird FFT problems...

I have experienced an interesting problem with the FFT libraries when
compiling for ROACH2, that I'm hoping someone might be able to explain.

I have tried multiple versions of the libraries, and various branches
(latest CASPER, SKA-SA, SMA), on Ubuntu, CentOS, RedHat and Windows, all
using Xilinx 14.7 and Matlab 2012b, but the error stays the same: the FFT
(various sizes/number of inputs/wb/biplex_2x/biplex_4x) simulates fine, but
when I compile I get zeros for some of the outputs.

After various experiments, I found that if I black box the FFT, and then
include it in the design, everything works, so I'm presuming the problem is
something in the system generator options when run by the tool flow.

Can anyone help me out with an explanation for why this might occur?

Thanks,
Jonathon