Forum Discussion

Ric2's avatar
Ric2
Icon for New Contributor rankNew Contributor
2 years ago

Deadlock while filling pipe for simulation

Hi, following best practice as descibed here we run into trouble with stalled writes. When you create a testbench for a oneAPI kernel that you intend to compile as an IP core, write all your data...
High-level Design Tools
Kevin_Xu_Intel's avatar
Kevin_Xu_Intel
Icon for New Contributor rankNew Contributor
2 years ago

Hi Ric,

I was able to reproduce this error. But i think it might be due to different reason.

If we change the while loop condition to be never to enter it, the compiler would optimized it way.

If I change the while condition to:

    // while (!end_of_packet) {
    for (int i = 0; i < 1; i ++){

To allows one packet to go though, the error goes away.

Do you have a different reproducer for the sporadically write issue?

Thanks,

-Kevin

Ric2's avatar
Ric2
Icon for New Contributor rankNew Contributor
2 years ago

Hi Kevin, you are right, the very simple reproducer did not show the effect. Same for the simple i++ loop as this will end the component without having consumed more data from the input pipe at a later time.

The updated reproducer is consuming input data with a large gap. I designed the gap to be large enougth to show that:
1) TB is pushing data to the input pipe until the related tread stalls as the write command is not correctly signalling FULL (the WR STALL print is never shown).
2) Simulation continuosly generates output data, restarts consuming input data after the gap but comes to a dead end as the input pipe is corrupted.
3) The final error comes from vsim but I guess the root cause is in the TB WR handling.

WR ... Input: 17000      Output: 51      Diff: 16949
WR ... Input: 18000      Output: 60      Diff: 17940
^CExiting simulation due to Interrupt
vsimk: src/hls_cosim_ipc_socket.cpp:133: virtual void IPCSocket::send(const void*, int): Assertion `0 && "send() failed"' failed.

Expected behavioural is that the TB WR thread hold on as long as WR pipe is full but restarts pushing data to it when the kernel has consumed some.

Regards, Ric.