kastnerrg / pp4fpgas Goto Github PK

Hi,

Is there any reason why j > 0 is evaluated twice in the following ?

https://github.com/KastnerRG/pp4fpgas/blob/master/examples/insertion_sort.cpp#L9

The link http://hls.ucsd.edu is broken.

ERR_CONNECTION_TIMED_OUT

I believe there is misleading or even factually incorrect info in "3.5.3 Overflow, Underflow, and Rounding". I think most of that is because in the examples only one bit is dropped and then half of the cases are ties.

In particular: the behaviour of round() and lrint() (for lrint we have to assume FE_TONEAREST mode is set, more info here) are actually rounding to the nearest integer and they only differ in the case of ties.

All the variants are well explained in: https://en.wikipedia.org/wiki/Rounding#Rounding_to_integer

Hi Kastner，
Recently, I'm working with the FFT Project using the baseline code in the book ,but I couldn't find the exact "fft_stage_one", "fft_stage_two" and "fft_stage_three" function files mentioned in the "fft_stages.cpp" file in the examples folder.
My partner is working with the CORDIC Project. There is a top file included in the "cordic.c" file called "cordic.h" which is not included in the examples folder also.
Would you please help us with this issue?
Thank you so much.

The paragraph in https://github.com/KastnerRG/pp4fpgas/blob/master/sorting.tex#L71 refers to the code snippet in Figure 10.2.

Specifically, the text uses the index term. However, by looking at the code, it seems the actual name of the referred variable is item instead.

Is RAW correct
in #pragma HLS DEPENDENCE variable=hist inter RAW distance=2 ?
I think the following is WAR(write after read)
hist[val] = hist[val] + 1;
Could you explain why it is not WAR but RAW?
Is it because of his[val] read at i+1(right-hand side of the equal) after hist[val] write at i(left-hand side of the equal) ?

In this line: https://github.com/KastnerRG/pp4fpgas/blob/master/sorting.tex#L287:

When the merge() function is called, whare are the possible relationships between i1, i2, and i3?

The merge sort program here:

pp4fpgas/examples/merge_sort.cpp

has the following test statement that can fail:

if((f1 < i2 && in[f1] <= in[f2]) || f2 == i3)

When f2 == i3, the in[f2] test fails for array index out of range. The code appears to work if the in[f2] test is separated and not performed when the values are equal.

In this line https://github.com/KastnerRG/pp4fpgas/blob/master/sorting.tex#L26, it is written:

[...] In each case, the fundamental operations of required for sorting and searching are pretty much the same [...]

I guess "of" can be removed.

Hi there,

I just noticed that the book points out that the restructured code for merge sort can achieve II=1 while the current settings in merge_sort.h which define DTYPE as float limit the achievable II to 2.
It might be better to set the default DTYPE to int, so the code would achieve II=1 without any modifications.

In this line https://github.com/KastnerRG/pp4fpgas/blob/master/sorting.tex#L144, it is written:

[...] where each sorting cell only communicates with it's neighboring sorting cells [...].

I think "its" should be used instead.

This repository contains Vivado_HLS_Tutorial_2019.zip and Vivado_HLS_Tutorial.zip and they seem copies of the UG871 official tutorial. They probably are better to be removed from the repository. Other ZIP files in labs/ may also be removed since some of them are already extracted in the same directory.

You can use BFG Repo-Cleaner to remove files from the entire history of a repository.

There is no XXX.gold.8.dat files which will be used in C Simulation !!!

In this line https://github.com/KastnerRG/pp4fpgas/blob/master/fir.tex#L264, I found the following:

The first iteration is equivalent the the non-pipelined version ...

In this line https://github.com/KastnerRG/pp4fpgas/blob/master/sorting.tex#L216, it is written:

The DEBUG constant is used to provided output detailing the execution of the testbench.

In Figure 3.2, we are rotating vector from 1) to 5) with each step rotation from the previous output.
So

1. 0°+45°=45°
2. 45°+26.565°=71.565°
3. 71.565°-14.036°=57.529°
4. 57.529°+7.125°=64.654°
5. 64.64°-3.576°=61.078°

However,
5) didn't start with the previous output from 4) 64.654. But the result 61.078 is calculated from 64.654
So it should change 64.64 to 64.654