MMIO FFT Generator

[AnimeshAgrawal]

Type of change: new feature

Impact: other

Testing:
Compile fft-test.c in the FFT Generator Repo and run it using the RocketWithFFT config. Should see close to 0 outputs for all lanes except lane 5, which should be a large, nonzero, value.

Status:
FFT is receiving the passed in input but is not currently not outputting the expected values. Issue is either with the FFT or with the input points.

Release Notes

MMIO-based FFT Generator.

[abejgonzalez]

There should also be some changes to the docs mentioning that this exists. (You should aggregate all the docs used to integrate this in some concise way).

[abejgonzalez]

You also should add to the CI the test for this accelerator. See the .github and .circleci directories

[AnimeshAgrawal]

You also should add to the CI the test for this accelerator. See the .github and .circleci directories

Holding off on this until we have it working since we still don't know what the correct FFT output is.

[lpppeipei]

So what the correct FFT output is ? I run your FFTGenerator project ,the result is
Read 0:
R:0
I:0
Read 1:
R:0
I:0
Read 2:
R:0
I:0
Read 3:
R:65535
I:0
Read 4:
R:0
I:0
Read 5:
R:0
I:0
Read 6:
R:0
I:0
Read 7:
R:1448
I:64087

[AnimeshAgrawal]

So what the correct FFT output is ? I run your FFTGenerator project ,the result is Read 0: R:0 I:0 Read 1: R:0 I:0 Read 2: R:0 I:0 Read 3: R:65535 I:0 Read 4: R:0 I:0 Read 5: R:0 I:0 Read 6: R:0 I:0 Read 7: R:1448 I:64087

The test points sample a 16mhz sine wave at 128mhz so we expect to see Read 5 contain large nonzero real and imaginary values. All other reads should be close to 0 (ideally they would be 0 but imprecision in the fixed point representation adds some error).

Since the FFT itself has been verified and taped out in the past, the issue is likely with the test point generation or due to us misunderstanding the number representation for the FFT input. The script for the test point generation can be found here: https://github.com/ucb-bar/FFTGenerator/blob/02e796d26c38370c737e61dfcee7399c6e5ee76e/test_pts.py

[lpppeipei]

So what the correct FFT output is ? I run your FFTGenerator project ,the result is Read 0: R:0 I:0 Read 1: R:0 I:0 Read 2: R:0 I:0 Read 3: R:65535 I:0 Read 4: R:0 I:0 Read 5: R:0 I:0 Read 6: R:0 I:0 Read 7: R:1448 I:64087

The test points sample a 16mhz sine wave at 128mhz so we expect to see Read 5 contain large nonzero real and imaginary values. All other reads should be close to 0 (ideally they would be 0 but imprecision in the fixed point representation adds some error).

Since the FFT itself has been verified and taped out in the past, the issue is likely with the test point generation or due to us misunderstanding the number representation for the FFT input. The script for the test point generation can be found here: https://github.com/ucb-bar/FFTGenerator/blob/02e796d26c38370c737e61dfcee7399c6e5ee76e/test_pts.py

I noted that " exponent = (-2 * pi * (freq / freq_samp) * complex(0, n) ) ; points.append(e ** exponent)" in test_pts.py. But a sinx=(exp(jx)-exp(-jx))/(2*j). And I am also confused about the number representation of for the FFT input . It is a concat of
real part and imag part in bin format.

[AnimeshAgrawal]

I noted that " exponent = (-2 * pi * (freq / freq_samp) * complex(0, n) ) ; points.append(e ** exponent)" in test_pts.py. But a sinx=(exp(jx)-exp(-jx))/(2*j). And I am also confused about the number representation of for the FFT input . It is a concat of real part and imag part in bin format.

I'm not too familiar with the math behind generating the test points; I'm meeting with someone next week to go over that so I can provide more clarification then.

The number representation can be found on line 95 of Tail.scala. My understanding is that the first 16 bits (specified by IOWidth) are the real component; 8 bits of that (specified by binaryPoint) are the integer component and 8 bits are the decimal component. The next 16 bits are the imaginary component, which follows the same format as the real component.

I tried your suggestion for generating the sample points with the following code:

points = []
for n in points_n:
    numerator = (e ** complex(0, n)) - (e ** complex(0, -n))
    denominator = complex(0, 2)
    sin_n = numerator/denominator
    points.append(sin_n)

and got the following output:

Read 0:
	R:0
	I:58877
Read 1:
	R:13796
	I:59704
Read 2:
	R:30976
	I:33535
Read 3:
	R:25311
	I:38340
Read 4:
	R:0
	I:1025
Read 5:
	R:59419
	I:19145
Read 6:
	R:34560
	I:33535
Read 7:
	R:32544
	I:40509

which still does not look correct since there is no noticeable spike at read 5. I will follow up next week once I meet with someone who has used the FFT code before and can provide some more insight.

[AnimeshAgrawal]

@lpppeipei as an update, we have verified that the FFT generator functions correctly. In the latest commit, the method described for generating float representations of the points yields the same output as numpy's fft. This means that our testcase does not function as we originally intended it to, but it still proves the FFT generator produces the correct output.

[abejgonzalez]

Small nits. Waiting on CI to be added but overall this looks pretty good!

[abejgonzalez]

I just remembered that you should also add to the Chipyard docs as well.

[jerryz123]

It seems like there is still issue with doc building and with the tutorial patch

[abejgonzalez]

LGTM!

[lpppeipei]

After run make CONFIG=FFTRocketConfig, ERROR as follows:
[error] Picked up JAVA_TOOL_OPTIONS: -Xmx8G -Xss8M -Djava.io.tmpdir=/home/liupeipei/chipyard/.java_tmp
[error] Nonzero exit code returned from runner: 137
[error] (Compile / runMain) Nonzero exit code returned from runner: 137
[error] Total time: 122 s (02:02), completed Feb 24, 2022, 11:04:43 AM
make: *** [/home/liupeipei/chipyard/common.mk:137: firrtl_temp] Error 1

[AnimeshAgrawal]

Do you have this issue only with FFTRocketConfig? Or does it occur with other configs (for example CONFIG=RocketConfig)?

[lpppeipei]

Do you have this issue only with FFTRocketConfig? Or does it occur with other configs (for example CONFIG=RocketConfig)?

I run it again. It's OK now. Thanks.

[lpppeipei]

Hi AnimeshAgrawal,

Is it possible to run the FFTRocketConfig design on Xilinx Artix-7 ?

[AnimeshAgrawal]

Hi AnimeshAgrawal,

Is it possible to run the FFTRocketConfig design on Xilinx Artix-7 ?

I'm not sure; I haven't tried doing this before. If you search for FPGA in the chipyard documentation you'll find a couple options: https://chipyard.readthedocs.io/en/stable/search.html?q=fpga&check_keywords=yes&area=default

You can check out firesim (berkeley's platform for fpga-accelerated simulation) or look at the docs for more information on running the generated verilog on your own fpga!

[lpppeipei]

Hi AnimeshAgrawal,
Is it possible to run the FFTRocketConfig design on Xilinx Artix-7 ?

I'm not sure; I haven't tried doing this before. If you search for FPGA in the chipyard documentation you'll find a couple options: https://chipyard.readthedocs.io/en/stable/search.html?q=fpga&check_keywords=yes&area=default

You can check out firesim (berkeley's platform for fpga-accelerated simulation) or look at the docs for more information on running the generated verilog on your own fpga!

Thanks a lot!

[lpppeipei]

Hi AnimeshAgrawal,
Is it possible to run the FFTRocketConfig design on Xilinx Artix-7 ?

I'm not sure; I haven't tried doing this before. If you search for FPGA in the chipyard documentation you'll find a couple options: https://chipyard.readthedocs.io/en/stable/search.html?q=fpga&check_keywords=yes&area=default

You can check out firesim (berkeley's platform for fpga-accelerated simulation) or look at the docs for more information on running the generated verilog on your own fpga!

I follow your advice to read the "FPGA Prototyping" part of the chipayard docs. Finally I decided to run the FFTRocketConfig design on VCU118.

And I first add "
class FFTRocketVCU118Config extends Config(
new WithVCU118Tweaks ++
new chipyard.FFTRocketConfig) " in ~chipyard/fpga/src/main/scala/vcu118/Configs.scala

Then I run "make SUB_PROJECT=vcu118 CONFIG=FFTRocketVCU118Config bitstream"

I got a ".bit" file indeed. But when I open the ".xpr" file in vivado 2018.3, it seems not right. The following is the simulation:

Any wrong with my flow ?

[AnimeshAgrawal]

I haven't tried simulating Chipyard SoCs on an FPGA before so I'm not sure how you can fix it. Another approach is you can try is running the simulation with something like:

cd sims/vcs # or cd sims/verilator
make CONFIG=FFTRocketConfig

Then, the verilog for FFTRocketConfig will be in sims/vcs/generated-src. You can copy this verilog to your own project and work with them however you would work with regular verilog to convert it to a bitstream. If you're more familiar with putting verilog on an FPGA, hopefully this will help!

[lpppeipei]

I haven't tried simulating Chipyard SoCs on an FPGA before so I'm not sure how you can fix it. Another approach is you can try is running the simulation with something like:

cd sims/vcs # or cd sims/verilator
make CONFIG=FFTRocketConfig

Then, the verilog for FFTRocketConfig will be in sims/vcs/generated-src. You can copy this verilog to your own project and work with them however you would work with regular verilog to convert it to a bitstream. If you're more familiar with putting verilog on an FPGA, hopefully this will help!

I copied all sims/verilator/* .v files and a "ClockDividerN.sv " file into my vivado(2018.3) peoject, but it worked unwell .

The .v files as follows: