Is it correct that an output change once its ap_vld has gone high?

[cerilet]

Hi guys,

I have created an HLS IP block using raw inputs and outputs (i.e. ap_none and ap_vld protocols). The idea is to control it using the ap_start to start the calculations and wait for ap_done to be asserted to read the results.

However, I am not getting the same results as the ones from the HLS C simulation. I included an ILA in the Vivado design and I see that after starting the calculations (blue arrow number 1), some of the outputs (Ecs0 and Ecs1) change their value (arrow 3) after their ap_vld signals are asserted by the fabric (arrow number 2). How can be this possible? Shouldn't be these signals constant until I lauch again the caculations using ap_start?

A second question I have is if I might have problems when changing the value of the input Vin (arrow 5) once the ap_start (arrow 1) is asserted. Should I keep Vin unchanged until ap_done (arrow 4) has gone high?

Thanks for your help!

Cerilet

[cerilet]

Well, so after several days looking for the problem I finally discovered "the problem". This was it:

Ecs0 = Ecs0 + (float)(PWM & (0x01<<0) ? isdelta_2C : 0.0);

Apparently, HLS does not properly convert this into what it should be, and that was the reason why I was getting changes after the ap_vld signal was asserted. I had to change it to this stupid code in order to let the compiler properly interpret the instructions:

if(PWM & (0x01<<0))
	Ecs0 = Ecs0 + (float)isdelta_2C;

Can anyone from Xilinx explain me why? I have lost a lot of time because of this bug or whatever it is.

I have been working with HLS quite a lot and it has many illogical problems like this one where the C or C++ code is not properly interpreted. It makes me angry.

[baltam · Accepted solution]

Hi Cerilet,

cerilet wrote:

...
> Shouldn't be these signals constant until I lauch again the caculations using ap_start?
...

Strictly speaking from the protocol interface point of view, I believe that HLS is correctly behaving in arrow 3.
This because, if the values of Ecs0 and Ecs1 are the expected ones when their own _vld signals are being asserted anytime during the module execution, then the protocol is satisfied.

Even I don't like that the outputs of the same module become valid/invalid in different times but according to my understanding of the protocol this is admitted.
Changes in the C code can change the time the signals become valid, even should be possible to synchronize them.

Let me know if I'm wrong in interpretation the protocol.

...

> A second question I have is if I might have problems when changing

> the value of the input Vin (arrow 5) once the ap_start (arrow 1)

> is asserted. Should I keep Vin unchanged until ap_done (arrow 4)

> has gone high?

... 

The ap_start asserted means just "Start of execution", you should  keep unchanged the inputs up the ap_ready signals is asserted.
Can't say if you are doing this because ap_ready is not visible in the figure.

See UG902 Interface Synthesis chapter:

...
The input data is read at any clock after the first cycle. Vivado HLS schedules when the reads occur. The ap_ready signal is asserted high when all inputs have been read.

...

Best, Fabio

[cerilet]

Many thanks for your answer Fabio.