We would like to thank all the reviewers for their helpful comments. We have carefully considered them and improved our article based on the reviewers' suggestions. Detailed responses are as follows:

### Associate Editor
> The paper shows an interesting expansion of the FCCM21 work by introducing a continuous Petri nets that greatly improves the scalability of their prior analysis tool presented in the original FCCM work. The reviewer felt the new contribution is significantly enough to be of interest to potential TC readers. There are some minor concerns raised by the reviewers about the clarity. Please address them in the final version of the manuscript. It would be good to provide some more justifications on the inclusion of a new author Estibaliz Fraca (to editor).

Thank you for your positive reply. Please see below regarding clarity.
Estibaliz Fraca has contributed to the use of Continuous Petri nets instead of Discrete Petri nets. She developed her PhD thesis in the continuization of Discrete Petri nets, including the study of the computational complexity of Continuous Petri net properties. Hence, she brought the theoretical and implementation expertise we needed to co-develop the continuous relaxation we present here.

### Reviewer 1
> The title to section 7 has a typo - it should be "Toolflow" not "TOOFLOW"

Thanks for pointing it out. We've added the missing "l" but the IEEE TC template requires the section titles to be capitalised.

> For table 1, I think it would be helpful to show wall clock time - cycles * frequency - rather than cycles as this would give the reader a better idea of overall performance.

We have now changed the total cycles to the wall clock time as requested.

### Reviewer 2
> I think the paper's evaluation section can be further improved with additional representative benchmarks.

We searched the literature for appropriate benchmarks and made a decision whether to include based on whether they are applicable for our approach. We agree with the reviewer that finding suitable benchmarks is a perennial problem for papers that push the limits of HLS, in part because existing benchmark sets such as Polybench and CHStone tend to be tailored to what HLS tools can already comfortably handle. We have added clarification to the Section 8.1 over benchmark selection.

> Maybe it makes sense to include the main approach of the FCCM 2021 paper as related work. In this case, the Introduction should mention the FCCM 2021 paper but the Relationship to prior publications should move to Section 2.

Thanks for the comments. We have now moved the discussion about prior publication to Section 3.2.

> In 5.2.2 and regarding the modeling of buffers, it is unclear what is meant by a “set of data”, e.g., in “at most one set of data”.

A set of data means a token in the data flow shown in the figures. We have changed the term to "token" for clarity.

> I was expecting that some of the boxes in Fig. 7 were identified as “dataflow graph” instead of LLVM IR.

The dataflow graphs are in the back end of the tool flow (originally indicated as dot). We have changed them to "dataflow graph" in the figure now, for clarity.

> The comparison in terms of scalability of the approach used in the FCCM 2021 paper with respect to the new approach shows significant speedups. Still, it does not fully reveal what happens concerning the sizes of the benchmarks. Including the impact when considering looping unrolling factors for a couple of benchmarks may show that, and I suggest the authors consider such an evaluation.

Thanks for the comments. The results shown in the table have already achieved the maximum performance allowable by the dependence constraints in DASS. Loop unrolling cannot exploit more parallelism because of the memory dependence in the source. We introduced a sentence to explain this in Section 8.2.

> Typos, suggestions regarding some details:
> - “For the in Fig. 1”. Ok
> - “this requires user efforts for pipelining manually.” -> “this requires manual user efforts for pipelining.”. Ok
> - add a caption to the table in Section 2
> - “The toolflow contains following steps” -> “the”. Ok
> - “at software level the front end of DASS” !!!
> - “The font end of Dynamatic translates the LLVM IR into a dataflow graph in dot format.” -> “The font end of Dynamatic translates the LLVM IR into a dataflow graph output in dot format.”?

Thanks for pointing them out. They are now fixed.

### Reviewer 3
> (1) Provide more explanations on Section 6.2 Steady State Formulation, for example, give an example of formulas corresponding to Fig.1 example;

Thanks for your comments. Unfortunately the Petri net for the example in Fig. 1 contains hundreds of places and transitions and is hard to present in the article. Instead, we added a small example of TCPN+i as a new Fig. 7 and explain in Section 6.2 how we get the steady state for the given example.

> (2) The paper mentioned using linear programming formulation on the hardware performance given TCPN+i model, the explanations on the connection between II (initial interval) in this formula needs to be further elaborated.

We have now explained how to obtain II from the terms defined in the proposed linear programming formula. See Section 6.2.