Attachment 'review_3.txt'

Download

   1 Reviewer 1
   2 ----------
   3 A nice work demonstrating adaptive overlay construction using unoccupied resources on FPGAs for debug, successfully merging two very important research directions for FPGA application developments. To me, the main contribution here is the design of the overlay and the CAD methodology to map the overlay to the unused resources.
   4 
   5 The power of inserting debug signals into post-place-and-routed design has been demonstrated in multiple occasions before, so the novelty here seems to be more on the overlay. As such, I think the paper can be improved by focusing more on this aspect, e.g. to compare how the use of new CAD mapping algorithm affects the routability/compile time for trigger circuits. The authors have mentioned briefly in Section VII.C, but a more extensive comparison would be beneficial.
   6 
   7 As mentioned below, the only trigger circuit evaluated was comparators of different sizes. While they are useful, it doesn't seem to have captured many considerations for trigger circuits and how they interact with the introduction of the overlay. For example, I could imagine fairly complex triggering pattern, which control traces leading to various different buffers. How would such complex triggering be handled? Would the introduction of the overlay make it less routably than if you directly route on the unused resources? 
   8 
   9 A few points that need clarification:
  10 
  11 * In Section VII.B, the critical path delay was increased in some cases with large comparators and you argued this is due to the new critical paths leading to large amount of trace buffer. However, in Section V last paragraph, you also mentioned
  12 
  13 "Note that it is also necessary to connect the trace signals to the trace buffers as well; although we do not perform this step in this paper, techniques such as those in [8] can be used."
  14 
  15 So do you have the connection or not? Please clarify what's the role of the trace buffers in the overlay and how the interact with the rest of your trigger insertion flow.
  16 
  17 * The signals from user designs need to be routed to the input of the trigger circuits as implemented within the overlay, and the output of the trigger need to be routed to the trace buffers. It is not entirely clear from the paper how this interfacing between the virtual overlay and physical user circuit is handled and how that may affect the placement algorithms of the trigger. It seems to me that a true overlay that is agnostic to the underlying circuit will lack this information about the interface between the two, making it difficult do a decent job on the trigger P&R. In other words, if you P&R the trigger circuits considering the overlay alone, you will have very little information about where the input to the trigger circuits will come from and where the output to send to because the overlay is virtual.
  18 
  19 * Maybe orthogonal to the use of overlay, but it seems as you are tracing triggered signals only, how do you reconstruct the timing information (re. cycle) of each traced data. It seems to me you do need some kind of timestamping of the traced data in order debug. Maybe you should consider a "smarter" overlay that also gives you such information?
  20 
  21 * Only n-bit comparators are used as triggering circuits. It would be a nice if more elaborated trigger designs can be evaluated.
  22 
  23 Reviewer 2
  24 ----------
  25 The paper relates to on-chip debugging. It proposes to use an overlay to realize the trigger circuitry that starts/stops the tracing of design signals into trace buffers. By using an overlay, the user is able to change the trigger functionality rapidly, without doing an incremental compile of the entire user design.
  26 
  27 Why was the overlay architecture designed as a 2D torus, with some 2-hop connections? The architecture seems to be pulled from the air without justification.
  28 
  29 Related to the above question: why the does overlay have to be square? 
  30 
  31 A key issue that I'd like to see discussed is: what variety of trigger functions can be realized in the proposed overlay architecture? The authors experiment with just one style of function: a comparator. Because the overlay is a 2D torus of cells (each of which comprises LUTs with a full crossbar), there may be some limitations on the sorts of trigger functions that can be "done" in the architecture?
  32 
  33 When you create the overlay and allow some connections within to be dropped because they cannot be routed, did you modify the PathFinder router at all? I presume you set some "give up" criteria for the PathFinder router?
  34 
  35 Minor typo on P2: overly -> overlay
  36 
  37 Really well written paper.
  38 
  39 Reviewer 3
  40 ----------
  41 This submission describes a flexible architecture to implement debugging trigger logic. In essence, the authors address the issue of a developer changing trigger logic (which requires recompilation in a traditional system) by implementing the trigger logic in a "virtual FPGA" fabric (although the authors do not state it in quite these terms), which can be "soft" reconfigured.
  42 
  43 Overall, this paper is well-motivated and I believe it would be of interest to the FPT community. I only have a few points of constructive criticism.
  44 
  45 The authors make an argument early in the paper that existing (somewhat) flexible trigger logic is inefficient in terms of resource utilization. The authors never compare (or, for that matter, really state) resource utilization for the proposed approach. How much worse is their virtual cell-based system compared to direct triggering logic? For that matter, stating that they use unused resources is a bit a of a strawman - by definition all debugging frameworks use unused resources, otherwise they wouldn't be able to co-exist with the circuit under test. Similarly, the true "flexibility" of their approach is never really measured or stated. They handwave a bit saying that the approach in [9] couldn't route from time to time, but that is never quantified.
  46 
  47 In the end, I think this is interesting work, but the authors may want to expand the experimental section considerably.
  48 
  49 Reviewer 4
  50 ----------
  51 The paper describes the creation of an overlay network to be used for inserting trigger points an changing trigger points during debugging without rerouting the circuit under test.
  52 
  53 The work assumes there will always be free routing resources and unused LUTs in a design, but this may not always be the case. The approach would still work if the user intentionally leaves unused resources (e.g. uses a larger FPGA) in that case.
  54 
  55 fig. 2 is too small, font size in fig 7,8,9 should be increased.

Attached Files

To refer to attachments on a page, use attachment:filename, as shown below in the list of files. Do NOT use the URL of the [get] link, since this is subject to change and can break easily.

You are not allowed to attach a file to this page.