Hi Wan
My lack of documentation has caught up with me :)
Each stage in the FFT has a certain number of coefficients as well as a
block that delays input data for a length of samples. These coefficients and
delays can be implemented in distributed RAM or block RAMs (BRAMs). For very
few coefficien
Hi Andrew:
Thanks for your information.
I am still not sure on next two options in fft_wideband_real:
Number bits above which to store stage's coeffcients in BRAM
Number bits above which to store stage's delay in BRAM
Thanks
Wan
From: Andrew Martens [mailto:ma
> On 10GbEv2 it is 8192, plus UDP and IP headers etc. But there would be
> no space for your application headers.
>
> When we specc'd it originally, the thought here was that 8192b is the
> closest power-of-2 for BRAM sizing to that same 9216b limit for most
> NICs. If we wanted to get to 9000, we'
On 10GbEv2 it is 8192, plus UDP and IP headers etc. But there would be
no space for your application headers.
When we specc'd it originally, the thought here was that 8192b is the
closest power-of-2 for BRAM sizing to that same 9216b limit for most
NICs. If we wanted to get to 9000, we'd ha
Hi. Does anybody know the actual limit on packet size for the
original xilinx and the V2 10 GbE cores? The documents say something
vague like "about 8k bytes", but is there a known hard limit to the packet
size in each case?
We want to package up 8K (8192) bytes of data + a few words of framing,
> Hi John,
>
> This is a known problem with the ROACH Linux source tree in which
> the original source had two files of the same name but different
> cases. This isn't a problem if you try to check out that part of
> the tree in Linux, but it makes Windows very unhappy.
I guess it's fair then. Wi
> Fortunately, you don't need those files unless you plan to recompile
> the linux kernel yourself ;)
OK. But it makes me nervous that the SVN doesn't have the whole thing you
need to reproduce the system. Not that I want to, but still...
>
> Are your builds working now though?
No. Still have
Hi John,
This is a known problem with the ROACH Linux source tree in which
the original source had two files of the same name but different
cases. This isn't a problem if you try to check out that part of
the tree in Linux, but it makes Windows very unhappy.
-Henry
John Ford wrote:
Hi all. I
Fortunately, you don't need those files unless you plan to recompile
the linux kernel yourself ;)
Are your builds working now though?
Jason
On 22 Jun 2009, at 12:02, John Ford wrote:
Hi all. I decided to check out the Roach subdirectory:
C:\casper\roach\sw\linux\include\linux\netfilter_ip
Hi all. I decided to check out the Roach subdirectory:
C:\casper\roach\sw\linux\include\linux\netfilter_ipv4\ipt_CLUSTERIP.h
C:\casper\roach\sw\linux\include\linux\netfilter_ipv4\ipt_REJECT.h
In directory 'C:\casper\roach\sw\linux\include\linux\netfilter_ipv4'
Can't open file
'C:\casper\roach\sw\
Hi Wan et al
The 'convert with overflow indication', convert_of is now fixed and the
change propagated to the FFT subsection in the library so the FFT blocks
should now accurately indicate if an overflow occured. Please do an update
to get these changes. Note that the overflow bit does not go high
Hi Wan
The overflow block that generates the overflow output does not currently
work properly, fixing it keeps slipping my mind. I will fix it as soon as I
can.
The FFT needs the same number of bits as there are stages i.e 5 stage = 5
bits. If you give it more it will just slice off the ones it n
Hi Andrew:
Now I can find the OF output from FFT module is high. Does this mean the FFT is
overflow? But I already set all shift bit to '1'.
I an not very sure how many shift bits the FFT module has. I just give it 32
bits width '1'.
Thanks
Wan
From: Andrew M
13 matches
Mail list logo
