Structured Design of Complex Hardware Microarchitectures Based on Explicit Generic Implementations of Custom Microarchitectural Mechanisms
Round 1
Reviewer 1 Report
A nice paper!
My only objection is that I miss a "bridge" between author's "Standardized (hardware) interfaces" and "common communication protocols"; i.e., on-chip buses. As a matter of fact, I thought such buses would play a role in the article. Hence, author should introduce them in his design flow, or justify why not. Just for instance, Wishbone is a common open-source bus.
Minor issues: figures 1, 3 and 6 are too pixelated; fig. 5 is too small.
Author Response
Please see the attachment.
Author Response File: 
Author Response.pdf
Reviewer 2 Report
The abstract can be improved. It is a bit lengthy. The background has taken half of the abstract. Please revise the abstract.
Examples of technologies in hardware design domain are presented in bullet points in the introduction. They should be better organized. More details and their potential applications should be detailed for each class. The motivation of the paper and the contribution must be better highlighted.
Figure 5 is not readable. I at first printed the paper on A4 papers but had to return to the pdf file to view the words in the figure. Please enlarge the words if possible.
Line 124, Transaction flow control, synchronization, and routing protocols. Since any complex design can be represented as a network of computational subblocks that exchange signals, data words, and messages, integration rules (including multilevel ones) can be specifically formulated. These rules might span the entire hardware structure or the significant part of it. They include various handshaking protocols, pipeline backpressure, buffering, policies of credits allocation and deallocation in credit-based flow control shared resources arbiteringvordering points, points of no return for CPU instructions, etc. These rules can be extended to network-on-chip flow control and routing protocols. This paragraph is very difficult to read. It is not clearly relevant. Please revise.
The experiment design is flawed. The kernel IP cores are not compatiable with the settings. Please revise the collateral optimization part and perform valid highlevel verification.
Reference 8 is not relevant. It should be removed. The discussion part can be better organized with some open directions and shortage of the current method discussed.
Author Response
Please see the attachment.
Author Response File: Author Response.pdf
Reviewer 3 Report
This paper presents a hardware generation tool.
While some experimental results are shown, its benefit is not clearly explained.
I would like to comment as follows.
- What is the most serious issue in current hardware design, and how the proposed tool solve it? Please describe them clearly and simply.
- What is the difference between high-level synthesis and the proposed method.
- In Fig. 2, what kinds the inputs are needed?
- What is Koltin? Please describe the benefit of using Koltin.
Author Response
Please see the attachment.
Author Response File: Author Response.pdf
Reviewer 4 Report
The paper seems to be correct and it meets research paper standards. However, the authors should extend the paper and offer different approaches. Also, the conclusion should discuss used approach more critically.
Author Response
Please see the attachment.
Author Response File: Author Response.pdf
Round 2
Reviewer 2 Report
I have no further comment. The paper can be accepted.
