Prototyping Power Electronics Systems with Zynq-Based Boards Using Matlab/Simulink—A Complete Methodology

Round 1

Reviewer 1 Report

This article covers Rapid Prototyping of Power Electronics Systems with Zynq-based boards using Matlab / Simulink and it seems interesting for a fresh researcher, but its already a known method and has been used by many researchers in their research and published too. Authors have given detailed procedure for rapid prototyping.......... that is appreciated but this article lacks the novelty/originality. 

Please answer the following question;

1. Page 15, section 5.3.1, line 600: "HDL code generated automatically by the HDL Coder tool is definitely not as efficient as that produced by a skilled HDL programmer......" Justify this statement. Also, Is this statement always true?

2. Page 16, section 5.3.2: In this explanation, three different sampling periods are used for controller, FPGA and ARM. Any specific reason/limitation behind selecting these specific sampling periods? Also, give explanation about how to select/choose the optimized sampling period because this is one of the important parameter.

3. Spell check required at line number 718, 1079, 1310 and also at the caption of figure 29.

4. In section 6, include the experimental prototype set-up figure and experimental set-up waveforms.

 

Author Response

Reviewer 1:
Comments:
<This article covers Rapid Prototyping of Power Electronics Systems with Zynq-based boards using Matlab / Simulink and it seems interesting for a fresh researcher, but its already a known method and has been used by many researchers in their research and published too. Authors have given detailed procedure for rapid prototyping.......... that is appreciated but this article lacks the novelty/originality. >
Thank you very much for your comment and insight. The authors  sincerely apologize for not being clear about the novelty of the manuscript in the previous version. In fact, the paper is not merely a
guide, as the previous title suggested, but instead proposes a full design methodology for programming Zynq-based devices from Simulink, for the rst time. This methodology includes a detailed programming
philosophy and numerous techniques for surpassing drawbacks of both Zynq chips and Mathworks tools (not previously discussed in the literature). Thus, the manuscript is not a mere collection of available
information, but a proposal of an entirely new development methodology and several new techniques. An extensive explanation of the novelty of the paper and respective changes made to the manuscript can be found in the "General comments regarding the novelty and scientific contribution of the manuscript", at the beginning of this document. The authors hope this text clarifies the reviewer doubts.
<Please answer the following question:>
<1. Page 15, section 5.3.1, line 600: "HDL code generated automatically by the HDL Coder tool is definitely not as efficient as that produced by a skilled HDL programmer......" Justify this statement. Also, Is this statement always true?>
Thank you very much for your comment. You are absolutely right, this statement is not always necessarily true. The authors meant to clarify that since the HDL code generated by HDL coder is generated using automatic tools, it is not necessarily optimized for each specific case. Hence, a skilled HDL programmer can likely produce more optimized code (using less resources, having lower latency, etc.). However, this is not necessarily true. To avoid confusion, the authors have corrected the sentence in the manuscript, to the following formulation: "The HDL code generated automatically by the HDL Coder tool may not be as efficient as that produced by a skilled HDL programmer, since it relies on automatic code conversion tools, which may not produce the simplest or fastest-executing HDL implementation in all cases. However, it does enable non-HDL-experts to successfully program FPGAs."

<2. Page 16, section 5.3.2: In this explanation, three different sampling periods are used for controller, FPGA and ARM. Any specific reason/limitation behind selecting these specific sampling periods? Also, give explanation about how to select/choose the optimized sampling period because this is one of the important parameter.>
Thank you for your comment. The description of each sampling time on the paper was altered to include a brief description of the criteria that must be considered for its selection.
In the case of the controller sampling period, it must be selected considering the needs of the control strategy. For example, if a modulation stage is used, the sampling period is typically equal to the modulation period. Otherwise, it must be selected to provide an acceptable compromise between waveform quality, efficiency and computational load (a lower controller sampling period will typically improve waveform quality, but increase switching and reduce the time available for computation and ADC sampling (which makes implementation more demanding and may increase ADC cost). Since control technique optimization is not the objective of this paper, the actual sampling period selection is not further discussed.
In the demo, a period of 70 µs was used for consistency with the presented application example. In the case of the UPS inverter, this specific period was used for consistency with other control platforms used in the laboratory (which could not execute with lower values), to allow some degree of comparison in the lab.
In the case of FPGA sampling period, a lower period reduces algorithm latency, increases throughput and enables higher peripheral speed. However, it makes it harder for FPGA timing constraints to be fulfilled during the synthesis. Thus, a compromise needs to be made. The used value of 40 ns corresponds to the default value for the Zedboard in Simulink and produces good results in the shown cases. In the case of the ARM sampling period, it must be selected to ensure reliable code execution. Some testing is typically required to ensure this. As now stated in the manuscript, from the long testing with the Zedboard it was found that sampling periods below 150 to 200 µs tend to execute unreliably (this was confirmed by the Mathworks support team, but may vary for different platforms or algorithms). The used value of 210 µs is the lowest multiple of the controller sampling period that executes reliably (as described in section 5.7).

<3. Spell check required at line number 718, 1079, 1310 and also at the caption of Figure 29.>
Thank you for your comment. The document has been revised and several typos have been corrected, including those found at the listed positions.

<4. In section 6, include the experimental prototype set-up Figure and experimental set-up waveforms.>
Thank you for your comment. The experimental setup has now been included in section 6. All presented results previously shown in the manuscript are results obtained experimentally, acquired in real-time using the Zedboard. Nonetheless, experimental results obtained with an oscilloscope have also been included for the same cases, for direct comparison.

Reviewer 2 Report

It is very difficult to judge this article. The authors say "This paper has presented a complete guide on how to program Zynq-based boards for power electronics prototyping, using Matlab / Simulink and the HDL Coder and 1330 Embedded Coder tools ", which is true. The article has some value, as showing a suitable workflow using Zynq to potential readers may be valuable.

From the scientific point of view, however, it has fundamental disadvantages, such as: very limited results of experiments (in chapter 6 the authors only provide an example of a single application - it is difficult to assess its effectiveness, it is impossible to compare it with other solutions) and a very general approach to the key elements of each article (the authors often, instead of a diagram, they use photos when connecting key peripheral elements, eg Fig. 22 and Fig. 23. There are also missing references to the literature in key places (page 6: Pmod AD1, SI8237 etc., page 7 S7 min from Trenz).

Overall, the article is practical (and valuable in this regard). However, it is difficult to talk about any innovative approach fully confirmed by the results of experiments. 

It is difficult for me to judge whether these types of articles are acceptable in MDPI Electronics.

Author Response

Comments:

• <It is very difficult to judge this article. The authors say "This paper has presented a complete guide on how to program Zynq-based boards for power electronics prototyping, using Matlab / Simulink and the HDL Coder and Embedded Coder tools ", which is true. The article has some value, as showing a suitable workflow using Zynq to potential readers may be valuable.>

Thank you very much for your kind comment. As stated in the "General comments regarding the novelty and scientific contribution of the manuscript", at the beginning of this document, the authors realize that the way the manuscript was first presented (including the title) lead the reviewers to believe that it was a mere guide on how to use existing software tools. However, this is not true, since the manuscript provides
(for the first time) a complete design methodology for power electronics development using Zynq-based boards and Simulink. The authors have altered the paper to describe the new contributions in greater detail. This is explained at the beginning of this document.

• From the scientific point of view, however, it has fundamental disadvantages, such as: very limited results of experiments (in chapter 6 the authors only provide an example of a single application - it is difficult to assess its effectiveness, it is impossible to compare it with other solutions)>

Thank you for your comment. The application example in section 6 is merely an example to demonstrate the application of the proposed design methodology. The true contribution of this manuscript is the design methodology in itself, which had never been defined. This methodology includes a complete design philosophy, adapted to the characteristics of both Zynq-based solutions and the Simulink tools, and
includes several new techniques to overcome drawbacks of these platforms (which had never even been described in the literature). Hence, since the contribution of the manuscript is not the implementation of this specific application, the authors believe a longer analysis of its performance or a comparison with other platforms would not significantly add to the value of the manuscript. In this case, the path to obtain this solution (the programming methodology) is the true value of the manuscript, not the performance of the implemented control algorithm (which is merely the final product and not the novelty of the paper).

• <and a very general approach to the key elements of each article (the authors often, instead of a diagram, they use photos when connecting key peripheral elements, eg Fig. 22 and Fig. 23.>

Thank you very much for your comment, it has definitely improved the paper. This has now been corrected in the manuscript. The wiring diagram is now presented for all peripherals and should make the connection clearer.

• <There are also missing references to the literature in key places (page 6: Pmod AD1, SI8237 etc., page 7 S7 min from Trenz).>

Thank you for your comment. References to all used hardware and ICs have been included in the manuscript.

• <Overall, the article is practical (and valuable in this regard). However, it is difficult to talk about any innovative approach fully confirmed by the results of experiments. It is difficult for me to judge whether these types of articles are acceptable in MDPI Electronics.>

Thank you for your comment. The authors would like to apologize, since they now realize the previous formulation of the manuscript did not effectively convey the novelty and true contribution of the manuscript. The authors have addressed in the paper. For a detailed description, please refer to the "General comments regarding the novelty and scientific contribution of the manuscript", at the beginning of this document. 

Reviewer 3 Report

 The authors present a detailed explanation about the use of Mathworks tools for the design of SoC systems. In particular, the paper is focused on the use of the Zynq architecture, an SoC composed of an FPGA and a microprocessor.
The article sounds more like a technical guide rather than a scientific paper. The paper is well-written ad very clear however it is not a research paper. There is no novelty or innovation although I think it would be useful for all these people that are interested in the use of the Zynq Processor without any HDL language knowledge

Author Response

• Comments:
  <The authors present a detailed explanation about the use of Mathworks tools for the design of SoC systems. In particular, the paper is focused on the use of the Zynq architecture, an SoC composed of an FPGA and a microprocessor. The article sounds more like a technical guide rather than a scientific paper. The paper is well-written ad very clear however it is not a research paper. There is no novelty or innovation although I think it would be useful for all these people that are interested in the use of the Zynq Processor without any HDL language knowledge>

Thank you very much for your kind comment and insight. The authors sincerely apologize for not being clear about the novelty of the manuscript in the previous version. In fact, the paper is not merely a guide, as the previous title suggested, but instead proposes a full design methodology for programming Zynq-based devices from Simulink, for the first time. This methodology includes a detailed programming philosophy and numerous techniques for surpassing drawbacks of both Zynq chips and Mathworks tools (not previously discussed in the literature). Thus, the manuscript is not a mere collection of available information, but a proposal of an entirely new development methodology and several new techniques. An extensive explanation of the novelty of the paper and respective changes made to the manuscript can be found in the "General comments regarding the novelty and scientific contribution of the manuscript", at the beginning of this document. The authors hope this text clarifies the reviewer doubts.

Round 2

Reviewer 3 Report

In my opinion, this is not a research paper. I am not able to notice differences between the traditional Mathworks Soc Builder flow and the proposed flow. I suggest to the authors to put in evidence the novelty introduced by the paper that in my opinion is not clear

Author Response

Please see attachment.

Author Response File: Author Response.pdf

Round 3

Reviewer 3 Report

In my opinion it is not very clear the difference between the methodology described in 

5. Proposed Zynq-based Development Methodology using Simulink

 

and the Soc Builder traditional flow

https://it.mathworks.com/help/soc/getting-started-with-soc-blockset.html?s_tid=CRUX_lftnav

 

I think this aspect must be putted better on evidence

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Round 4

Reviewer 3 Report

Tha paper has been improved and for this reason I recommend the acceptance.