• section 1: Multiple comments
  • We've re-written the introduction, so most comments aren't directly applicable. We have however included more background on the current CMS Detector, the HL-LHC, the IT and OT, and the PS tracker (including 2S module)
• section 2.2: suggest to rephrase "center of the sensor"
  • The sentence has slightly evolved: The sensor is read out by two SSAs, with the boundary between the 120 channels connected to each chip located at the center of the sensor.
• section 2.3: Why and wrt what?
  • Prior to a full alignment of the system, it's difficult to be sure which tracks miss the DUT (and thus shouldn't be counted against an efficiency). Once the full alignment is done, we know exactly which tracks to keep or discard (this is what results in the paper use, but not what was used to while taking data). We've clarified this in the text.
• table 1: Add the uncertainty of the fitted parameters in Tab. 1
  • They're now included.
• section 4.2: Section 4.2, L109: "Newly rotated":
  • This a confusing way to say that the rotation is about the y-axis as defined after a rotation in gamma. However, the nominal value for gamma for the entire experiment was 0... so we will just drop this and say that alpha is the rotation around the y-axis.
• Section 4.2, L113: "Both are modeled as straight lines":
  • The track is modeled as a straight line, as is the central axis of each strip. The latter is probably obvious and to avoid confusion we re-stated this to just specify that the track is modeled as a straight line.
• figure 5: Normalized number of clusters
  • Fixed
• section 4.3: Why is this not the default setting? (compare L96)
  • This value of the threshold is just above the noise: where the hit efficiency is essentially 100% without significant effects from the noise itself. With hindsight we might have used the default setting, but we wanted to be absolutely sure any efficiency loss we saw was due to the timing, not the threshold.
• section 4.4: Is there any explanation for this?
  • The HIP thresholds cannot be trimmed, so this may explain it. We have added this information to the paper, but do not go as far as to state that this is the reason for the slight difference.

• Intro: This ref refers to the Tracker upgrade, while you start the sentence with the CMS upgrade. Consider adding more introductory sentences motivating the upgrade of the machine, CMS and eventually discuss the replacement of the Tracker.
  • The intro is re-written to hopefully introduce things more naturally. The correct refernce is now used.
• Intro: At least a reference and brief mention of the Inner Tracker is required (an Outer implies there must be an Inner!)
  • We cite it and mention it now.
• Intro: the other type of module (2S) should be explained for context
  • We now mention it explicitly and cite some papers that describe it.
• around line 19 etc (40MHz): i think you can expand on this - the motivation is not clear at all and deserves an intro (perhaps accompanying the first sentence in this para)
  • The 40 MHz number if not relevant in the re-written introdution
• Experimental setup intro: overall better than last draft but - can we be more specific about the measurement aims? what is purpose of TB? is this the first module/measurement of its kind?
  • We've added a sentence to preview the measurments shown in the paper.
• section 2.1: as i said in last draft - be careful here 1/4 MIP refers to nominal setting - see my other comment... (also MIP can mean many things - define in electrons as well)
  • We've corrected the mistake, 1/4 is the nominal detection setting as you noted. We've also converted it to electrons assuming 75e/um in silicon.
• section 2.1: overall better than last time but still a bit weak, repetitive and occasionally too close in phrasing to the SSA manual . (to repeat! myself again) i still think you should ensure the SSA designers are able to contribute and review this section, and indeed the paper given the results are relevant to them too. (and should be on the shortened internal author list in my opinion too). there is plenty more relevant detail that could be added about the operation of the ASIC, e.g. operational modes, configuration settings, etc.. i see no mention of offset tuning, power, noise, radiation hardness to name a few. the fact that the clustering logic is not described at all leaves the reader with many questions in the later sections.
  • We have tried to beef up this description without needlessly repeating information already in the SSA paper that we cite (this was the preference of the ASIC designers, who have now read and commented on the paper). We do add some description here though. One thing to note: these results do no use the SSA's clustering: we only read out the L1 hits and clustered ourselves offline. We have made a note of this later in the paper when the clustering is brough up (and where a description of the clustering is also laid out).
• section 2.1: this could really do with a dataflow diagram
  • We've added one provided by the chip designers.
• section 2.1: which chip ?
  • The MPA (in the PS module) and another SSA (in the 2xSSA module), that's been made clear in the text now.
• section 2.2: a picture is fine for showing the resulting module, but you definitely should add a diagrammatic figure of the module and its components/structure/connectivity
  • Unfortunately no serious diagram exists, so I've made a cartoonish one that I think nonetheless gets the point across?
• section 2.2: what about sensor biasing? operational settings? there is no mention of the DAQ whatsoever - how is this thing read out? this needs a section at least
  • We've added a section on the readout, as well as mentioned the sensor bias voltage (you may recognize the citation for the FPGA uTCA). For operational setting, since the non-standard operational modes of the SSA aren't brought up anywhere, we haven't specified.
• section 2.3: the strip planes measure one coordinate? or are composed of x and y sensors? what about the DUT - which orientation is it aligned with?
  • Indeed, each strip plane is un-segmented and alternates between x and y. We think this is clear in the paper so we haven't changed the description, but we have noted the (y) direction that the strips of the 2xSSA pointed.
• section 2.3: what frequency? make clear that the clock is asynchronous to the particle ToA. its still not obvious how the timing adjustment discussed in section 4.3 is done (im starting to guess this is done offline? if so make clear here what the telescope records in terms of track info e.g. time!)
  • 40 MHz. The phase of this clock w.r.t. the accelerator clock is constant (indeed the 40 MHz is derived from the beam clock). Hopefully the timing section is now clearler? (clock specifics added to the text)
• section 2.3: actually the OTSDAQ is not the whole DAQ but a part of the software right? this ignores the CAPTAN DAQ hardware for the telescope. however you make no reference to the DAQ for the DUT - how was this integrated? again you should expand here on details, talking to experts if necessary
  • We've added more information to the new DAQ section.
• section 2.3: ended prematurely?
  • Sorry about that. Full sentence now visible.
• section 2: a general point - i think it is not mentioned anywhere in the paper that only the full hit data is recorded/analysed in this BT, and the stubs are ignored or not recorded. this should be clarified somewhere (somwhere in section 2)
  • We now bring this up when we describe the data streams of the module.
• Section 3: this needs to be cleaned up and clarified - you talk about the Landau and reference the original paper, but my guess is you are using the approximation provided in the ROOT TMath libs - is this correct? if so you should say so - being specific about the routines you are making use of would go some way to clarifying non-standard terms like 'location and width parameters' which are specific to this routine. if you are looking for the underlying routine used in TMath it is https://www.sciencedirect.com/science/article/pii/0010465584900857 - however there is no mention of location and width parameters in here (this is ROOT-specific nomenclature). Most probable value is the term most people are familiar with, which "location" is a close approximation of.
  • We've tried to make the text readable to a non-ROOT user, switching to most probable value. We also point out that we use this computational model (thank you for the reference!)
• section 3: location? this is not a standard term
  • We're calling it "most probable valule", and then immediately defining it as \mu
• section 3: personally i would use symbols for location and width (the words mean nothing to the average reader)
  • We now define \mu and \sigma early and use those throughout.
• section 3: by addressing the above comments, i think this would help clarify why your "location" parameter is allowed to be a free parameter. if this were a proper geant simulation for example, the MPV would be a fixed number (based on Si thickness & particle energy etc.). If instead you clarify that you are using a computational function given by TMath to approximate the Landau for example then it makes sense that the parameters do not quite correspond to the underlying physical constants
  • We've made the change you suggest!
• section 3: the MPV for 120GeV protons in 240um of silicon is ~19k electrons so quite close to the fitted x0. you might want to comment or include this to back up the model and resulting fitted parameters
  • We've added a mention of this, as it does indeed build confidence in the simulation!
• section 3: better than the last draft, but i still think a diagram of the various effects simulated to aid the reader would be helpful and interesting. e.g. show the sensor cross section and highlight deltaS, fractions on each strip/gaussians. if not a diagram, then the mathematical models
  • Our attempts at diagrams are more confusing than anything else, but we have implemented equations with each part explained.
• section 3: "sharing" - still disagree with this so please tell me im wrong. shouldnt cross talk be an additive effect? its a capacitive coupling right?
  • It is a capacitive coupling (we specify that in the paper to make what we're talking about clearer). Maybe now it's clearer? No extra charge is created, it just moves from one strip to another, but it is a different effect than the diffusion.
• section 3: i assume you mean electrical noise - which includes sensor and analogue amplifier noise. please clarify in text
  • Clarified that it's the total noise from sensor and front end
• section 3: measured how?
  • We now describe this in the original description of the SSA.
• section 4.2: can you show gamma in a diagram - perhaps fig 4? which you should refer back to in this paragraph anyway
  • It's been added, and referenced.
• section 4.2: aligned? or determined precisely? rather than optimised
  • we went with "determined precisely".
• section 4.2: dont you mean closest cluster centroid? or do i misunderstand what you are doing here?
  • We do, and we've updated the paper to reflect this.
• section 4.2: the minimisation is performed once on each angle independently or for the entire system in one go. state how this is done.
  • It's done simultaneously for all angles since the parameters are "properties" of the module, not of the geometry. The paper is now explicit about this.
• Figure 5: normalized what?
  • Now it's "normalized number of clusters"
• section 4.2: does this mean you only minimise for a subset of the 6 parameters in this system? or are the results of the fit for parameters which are badly constrained ignored? state what is done
  • Yes, they are simply ignored. We've now stated as such.
• Figure 6: plot should be made larger (or combine with fig 5) - y axis can just be written as \Delta x, x axis need not say (telescope)
  • We made it bigger, but the final size will likely change depending on the journal formating preferences. We did not combine with Figure 5.
• section 4.3: I think you mean ' This can be achieved by adjusting either the trigger arrival time or the pointer to the pipeline location containing the buffered hits. If you dont mean this then i think there is some confusion as to what you are actually doing in this section (possibly because not enough info is given in section 2)
  • It does mean that. We've upated the paper to say exactly this.
• section 4.3: this paragraph is still confusing - i have made comments about this in the previous draft, but i wonder if the issue is that the method here is just not clear (to me at least). perhaps we could discuss this over mail or in a quick call
  • This paragraph has been removed completely. All it did was confuse every reviewer and it adds nothing relevant to the discussion.
• section 4.3: sub-optimal in terms of ? resolution? margin? what?
  • In terms of efficiency, as now noted in the paper.
• Figure 8: can we find a better shorthand? make a parameter and introduce it in the text (and caption)
  • We've defined and used a symbol for this and Figure 8 and in the text ($N_\mathrm{cl}^\mathrm{>1}/N_\mathrm{cl}$)
• Section 4.4: two threshold values... - thinking about this, might be be more convenient to label the two thresholds Lower and Upper or Standard and HIP? or whatever the SSA manual states? this would make talk of thresholds less ambiguous. this should be done early on in the paper. you also have a Q later on - how about simplifying and standardising on the nomenclature
  • We now introduce "standard" and "HIP" thresholds form the start, in section 2, and then stick with those names throught
• section 4.4: use new shorthand symbol
  • We've defined and used a symbol for this and Figure 8 and in the text ($N_\mathrm{cl}^\mathrm{>1}/N_\mathrm{cl}$)
• Figure 9: lets make a parameter for this (see fig 8)
  • We've defined and used a symbol for this and Figure 8 and in the text ($N_\mathrm{cl}^\mathrm{>1}/N_\mathrm{cl}$)
• Figure 9 caption: insert new symbol here to refer to new axis label
  • Done.
• Section 4.4: you introduce Q here - please do this in the text (perhaps even in an earlier section e.g. 4.1 or even before so you dont need to repeat yourself)
  • We now introduce (Q) as the measure of threshold in Section 2.
• Section 4.4: see comment above on labelling the thresholds in this paper consistently
  • We now introduce (Q) as the measure of threshold in Section 2.
• Sectin 4.5: how/where does the fitted width (14.7) come from?
  • The resolution is extracted from the data: it is a free parameter which floats simultaneously across all runs (with the effect of the angle taken care of by the 1/cos term in each fit). The resolution "at the DUT" is varying, so I'll add to the text that this value corresponds to the alpha = 0 case.
• Section 4.5: where is that stated? how does 8um correspond with 14.7 above?
  • Not sure where this came from, but I've confirmed that 14.7 is used, not 8. Fixed in paper as well.
• Section 4.5: even if you are not able to report on this, can you make some comments about analysis that was not performed here, but in my view are important tests to verify performance? e.g. noise performance? trigger path verification? verification of chip-2-chip intercommunication (for the clusters) and so on... seems relevant for a first paper on this ASIC on a module in a beam (that i know of)
  • We are hesitant to make comments on anything outside the scope of the paper, especially if we did not make a formal measurement. Some mentions have been added (throught the paper where relevant, rather than all in this section): the noise in the sensor is shown along with the S-Curves, and a mention of how it was obtained is made in the text. The chip-2-chip is briefly brought up (and it's noted that we dont' do anything with it). I'm not sure what you mean by trigger-path verification: the chips were triggered for all the data taken here, so maybe that is sufficient verification? There are obviously many other measurement we could have made, but we prefer not to include a list of missing items.
• Section 5: conclusions/discussion still short - i repeat - needs some work as reads as slightly irrelevant (which it shouldnt be, given that this is an important study!!). summarise the main results and why the specs (which specs?) are met. what comes next in terms of the PS module prototyping? the SSA verification (beam/SEU tests)? MPA? stub path verification? module assembly? this could even be a separate section.... this should be the first published result of the SSA in a beam right? mention this! the parameterised simulation model seems pretty robust from my perspective. discuss this! a lot of hard work went into this, not just your results in the paper, but also in the design of the chip, the hardware, the DAQ and so on, so try to do this justice for CMS
  • The section has been significantly expanded, including withh some of these items. Again (see above), we prefer not to comment on anything we don't explicitly have data for (this includes in a sense "next steps" since we don't want to outline a plan for the OT that may not be realized: for example the MPA went throughh a similar test beam, but the results were not published).
• Section 5: which specifications? only a subset it seems - see my comment above
  • We didn't find "specs" to direcly compare to, but on the suggestion of Sarah and Katja we've used our simulation (and the great agreement with the data) to make the statement that the SSAs behaved as expected. We've also slightly expanded this sentence to note the efforts in module assembly and software which underpin these measurements. We have removed the word "specification" and replaced it with "expectation".

• abstract: Still very short. Add something like: The prototype module has been characterized at the Fermilab Test Beam Facility using a 120 GeV proton beam.
  • Much longer abstract now written. Please let us know if it is what you had in mind!
• section 1:
  • This section has been significantly re-written, so individual comments don't line up anymore, but we hope the end result is better?
• OK, we've added the usual CAD drawing.
• Figure 1 caption: the modules are composed of many items, not just of the ASICs. Rephrase.
  • The caption has changed a bit so this isn't applicable anymore.
• Introduce the CMS coordinate system in a footnote. You need r, z, eta.
  • We've added this, though maybe it's unecessary?
• Figure 2 caption: seeded?
  • Fixed.
• Move figures to very bottom of the page.
  • We haven't implemented this now, as the final version for the journal will likely have a different format.
• Section 2: I think "timing studies" is quite sloppy. Can you find a better wording?
  • Studies of timing, efficiency and resoltion?
• Section 2.1: I am not convinced by the structure. I see two problems: 1) the SSA architecture and readout is described partly in the intro, partly in 2.1, with some repetitions. 2) Section 2.1 described the general behaviour of the SSA and does not fit well into the Section 2 = "Experimental setup". n order to fix both problems, a new section 2 "The Short Strip ASIC" could be introduced, where you describe the generical behaviour/architecture of the chip.
  • We agree with this structural change: The SSA now has its own section (the new Seciton 2)
• section 2.1: the "path" is not "consisting" of hits, please rephrase this
  • Changed to "which carries".
• section 2.3: along what? I guess not along all 3 axes?
  • Actually it can rotate around x and y, and also move along x and y: we've made this explicit in the text.
• section 2.3: Sorry, but what or who is Monticelli? This needs to be rephrased or explained.
  • Monicelli is a software package. We now specifically say this and include a citation.
• section 2.3: Something seems to be missing here. Differ from what? The offline efficiency, I guess?
  • Yes, the offline efficiency. The text is fixed now.
• Figrue 4: Can the angle gamma also be shown in this sketch?
  • Yes, it's been added.
• Figure 4 caption:
  • Implemented both comments.
• Section 3: see comment to Tab. 1
  • Here and in the text we're using most probable value, though we immediately define it as \mu and use thhe symbol for legibility.
• Section 4.1: make clear around which axis (can refer to Fig. 4 now).
  • Whole paragraph slightly reshaped, but should be clear now.
• Figure 5: Normalized number of clusters
  • Fixed
• Figure 5: angle
  • Now says Angle \alpha, is that ok?
• section 4.2: Here I realize that you never said how the module is oriented in the beam, i.e. in which direction the strips are actually pointing (x or y). This should be added in Section 2.3.
  • This information is now added.
• section 4.3: what is meant by "shape of the timing scan"? The scan is a method, it cannot have a shape. Please rephrase.
  • We have removed this paragraph completely. It doesn't add any useful information relevant to the results presented and confused everybody who read it.
• section 4.3: I do not understand what you mean with "raw distribution" or "raw timing distribution". Please clarify.
  • We have removed this paragraph completely. It doesn't add any useful information relevant to the results presented and confused everybody who read it.
• section 4.3: I am still confused by this paragraph.
  • We have removed this paragraph completely. It doens't add any useful information relevant to the results presented and confused everybody who read it.
• Figure 7: Can you call this "Trigger delay" or something else that is more specific?
  • Fixed
• Figure 7 caption: for (I am sorry, my earlier comment makes no sense to me now)
  • Fixed
• Figure 8: I think this should be "clusters" and in fact "Number of clusters". I understand that this will make it too long. Maybe it would be better to introduce variables N_clusters and N_clusters (W > 1) so that the label can be consise and correct.
  • We've defined and used a symbol for this and Figure 9 and in the text ($N_\mathrm{cl}^\mathrm{>1}/N_\mathrm{cl}$)
• Section 4.4: thresholds - I found it confusing that you talk about 2 thresholds here. Maybe it is clearer to just say "the threshold" here, and then introduce the other study later separately (as you do)?
  • We now introduce "standard" and "HIP" thresholds form the start, in section 2, and then stick with those names throught
• Figure 9: See earlier comment.
  • We've defined and used a symbol for this and Figure 8 and in the text ($N_\mathrm{cl}^\mathrm{>1}/N_\mathrm{cl}$)
• Section 4.5: I am confused - where actually do the 14.7 stem from now? And why do you write sigma_tele = 14.7m in all plots, irrespective of alpha?
  • The resolution is extracted from the data: it is a free parameter which floats simultaneously across all runs (with the effect of the angle taken care of by the 1/cos term in each fit). The resolution "at the DUT" is varying, so I'll add to the text that this value corresponds to the alpha = 0 case.
• Figure 11: Number of events
  • Fixed.
• Figure 12 caption: This is not well phrased, and confusing. I think what you mean is that at 0m there is the border between two implants, which have their centers at -50m and +50m. Please rephrase this.
  • This now reads: The border between two strips is at 0μm, and the strip implantsare centered at -50μm and 50μm.
• Section 5: In fact, you have not discussed the specifications. So you are just claiming that it is consistent with specifications, you are not proving it. Indeed the paper would profit from mentioning the specs, which is in fact often asked by JINST reviewers. Otherwise, if you cannot do so, it would be better to just say here what was measured and what was the result (but of course then the question comes up: is it good enough?)
  • We do not have “specs” necessarily (other than that the module should be fully efficienct, which we now state clearly in the conclusion). I’m not sure what else we can mention here other than the good agreement with simulation (which we also do now in the conclusion). We've changed the word "specifications" to "expectations".

• OC : possibly also one of the rendered images of the PS module design? Could you please include an image of what the PS module will look like?
  • We've added one.
• I think that it would be worthwhile to strengthen the introduction by including a more complete description of the tracker upgrade and the pT module concept.
  • We've added more information and re-arranged the introdcution. Please let us know if this is better.
• Since this is the introduction to your paper I think its worthwhile to spend some time introducing the reader to the concepts of the upgrade that we ‘take for granted’ in the upgrade community before diving into the details of the PS module. This draft is already a marked improvement on the original in this respect, but I think it can still be further improved. The description of the two data paths in the PS module is much better than in the original draft, but I think it can still be further clarified. Perhaps by simply everything that the SSA does first (hit detection, cluster formation, cluster buffering) , then the role of the MPA ( hit detection, cluster formation, cluster buffering, stub formation, L1 data packet formation). More in-depth technical details about the SSA (two thresholds, buffer depths, max trigger rates, lateral communication, etc.) can then be reserved for a separate section on the SSA.
  • We've done as you suggest: the details of the SSA get their own section and the introduction is more about the PS module and OT upgrade in general.
• OC, L4 : Please be a bit more precise with regards to how this compares to the current LHC (xx fluence, xx current occupancy) Still not precise enough, five-fold with respect to what? Either quote the absolute numbers for the current tracker or the specs for the upgrade
  • Done, we quote the final parameters for the HL-LHC.
• L9 : ‘two types of modules ‘ - you only describe one in the text, and then mention 2S modules in the figure caption. There is no need to go into great detail about the 2S modules, but perhaps re-writing the first couple of sentences to be a bit more ‘generic OT’ and replace part of Figure 2. with a similar picture for a 2S module , and first describing the pT module concept. requirements for the tracker before going into the details of the PS module that are relevant for the paper could strengthen the introduction.
  • We think the same figure is appropriate for the 2S as well as the PS, so we didn't change it, but we make clear in the caption now that it applies to both chips.
• Figure 1 : ‘related 2S modules’ - related to what? Perhaps also reference one of the 2S module beam test papers/notes here.
  • We're not sure which reference you have in mind? Right now we quote [5] and [6] when the CBC is introduced.

Section 2 :

• Perhaps moving the description of the DUT ( SSA description, 2xSSA mini-module etc.) could be moved to a separate section?
  • We've re-orgniazed this to cover the SSA on its own first, then the 2xSSA module, then the beam itself.
• I also realized that nowhere in the paper is there a mention of a test with beam data that verifies the lateral communication between the 2SSAs. I assume that’s why a mini-module with 2SSAs rather than a single SSA was chosen for the beam test. If this wasn’t addressed in the data analyzed for this paper then I think its still worth mentioning something along the lines ‘studies of the efficiency of the lateral communication were either previously shown here (x)’ or ‘studies of the efficiency of the lateral communication will not be addressed here’
  • It's true we don't do anything with the stubs or the lateral communication. We now mention that in the paper, though we do note that we confirmed that the lateral communication works (and that it was rigged to run between the two chips). I think what we have now does it justice?
• L29 : ‘controlled beam’ - what does ‘controlled’ refer to here?
  • Just meant to establish that the beam parameters are under our control, but maybe this is obvious since we specify its parameters further in the section. Will remove.
• L32 : no reference is made to the second threshold after it is first mentioned. Please provide details on that if you would like to refer to it here.
  • We now explicitly name them and can refer to them by name. Hopefully that aleviates the confusion.
• L37 OC : Please be more precise about what the size of the signal from a quarter of a MIP in a fully depleted strip sensor of a PS module. (If you know what the value (in electrons or fC) is expected to be for a fully depleted PS strip sensor then I would suggest including it here.)
  • Done!
• L37 : I think the manual states that the 1/4 MIP is the nominal and not the minimum threshold.
  • Thank you! Fixed!
• L38 : ‘.are latched with an edge sensitive circuit …’ - it took me a while to figure out that ‘latched’ here refers only to the digitization and not the sampling of the comparator output. I know its a minor detail but could you please add another sentence describing the sampling in a following sentence before mentioning the fine adjustment of the sampling phase? I think that could help guide the reader.
  • We've slightly simplified this sentence to make it clear that we are talking about the digitized signal (both of them since we now distinguish the HIP and standard thresholds):

    "Both signals are digitized with an edge sensitive circuit sampled at 40 MHz. In order to maximize the hit detection efficiency, the sampling clock phase is adjustable in steps of 200 ps across the full 25 ns bunch crossing period."
    Is this clear enough now? We no longer use the word "latched" as it obfuscates the meaning of the sentence.

• L42 : ‘the second chip’ - perhaps better to be explicit and say MPA?
  • We agree, fixed.
• L63 : ‘geometry’ - configuration? L68 : ‘readout using OTSDAQ’ - I think technically the DUT is readout by our upgrade firmware + software and OTSDAQ is only used as a final wrapper around the sw that actually communicates with our readout firmware. There is no need to go into the technical details of the uDTC + Ph2ACF, but it would suffice to refer to one of the presentations/theses written on the topic.
  • Actually we have added a bit more information on the readout so we’ll go into the details a bit more.
• L69 : ‘In particular the online..’ - I don’t understand the context of the sentence with respect to the rest of the paragraph…
  • The whole sentence has been re-worked. Hopefully now it makes sense?

Section 3 :

• The explicit reference in the text to the usage of data collected at various angles and thresholds to extract the model parameters has been removed, however Figure.9 still shows that data collected at different angles was used. Can you please be explicit in the text as to why you chose to do that? And how the results of the model parameter extraction across the different data sets was performed?
  • The text now explicitly notes the multiple angles are fit simultaneously.
• OC : I still think that some kind of mathematical description of the model would be much easier to follow than the current written description. I see that some of the other referees have also made similar comments on the first draft so please consider adding this. (I would find it very helpful if you could add to this section an illustration which shows two strips , the different mechanisms by which charge is collected by the strips, and a few equations that describe how the charge collected by a given strip is expressed in the model. I know its all in the text, but I personally find it easier to follow the text when there is more information provided. Also, it would be nice if you could show an example output of the simulation for what you expect the nominal parameters to be based on the detector that you are studying. This already prepares the reader for the type of plots you collect at the beam test and I thin can really help make the discussion in the paper much easier to follow.)
  • We've added a math equation for the actual charge collected in each strip. We don't have an "example output" as you suggest, we're not sure what that would look like exactly. At any rate, hopefully things are clearer now (the text has also been improved since the previous draft)?
• OC L73 : At this point in the paragraph I still don’t know which data.. by the end of the paragraph I know that its the cluster size and the efficiency but I would personally rather know at the start. (Which data?)
  • Fixed.
• OC L87 : How is the noise of 830 electrons calculated .. in the first draft of the paper it was 930 electrons and now it is 830 .. why the change? (How is the noise of the sensor determined?)
  • Sorry for the mistake, this was due to a miscommunciaton between contributors but has been fixed. The noise wass 830. We now specify that this measurement was done just before receiving beam (after installation). When the SSA is introduced we now mention how the internal biases are calibrated so that we can calibrate the threshold to electron units.

Section 4 :

• OC L104 : Please define efficiency here. (Please explain here how you will be defining the efficiency in the analysis.)
  • We moved any mention of efficiency from this section since it’s not actually used until the timing studies section. There we explicitly define it before using it.
• A significant amount of time is spent in the section on the alignment explaining to the reader how useless most of these alignment parameters actually are .. but then .. nothing much is mentioned/shown regarding the parameters that can be constrained by minimizing the residual which feels a little strange. Perhaps something can be added that helps balance this out a little?
  • We’re not sure what there is to say: all we do is align our computational model to the actual geometry. We’ve added a sentence about what we do with the unconstrained angles (which is ignore them).
• I think the second paragraph in section 4.3 is still a little vague.
  • We removed it completely, as it didn't add anything valuable and just confused anybody who read it.
• Do you have any explanation for the asymmetry of the shape? Was any attempt made to fit this with a model? Or compare it to a simulation?
  • I don't think we do. Our other simulation doesn't take into account the rise time of the signal, so it would not be sensitive to this. For now we have no comment to make on it in the text.
• L108 : Please also define the rotation angle gamma in Figure.4
  • Added!
• L110 : Please refer to Figure.4 where these angles have now been defined.
  • Done!
• L119 : ‘rotation around z’ - can you please indicate which of the three angles mentioned in Figure.4 this refers to.
  • Done!
• L134 : I agree that Figure.9 shows that the efficiency is high at the threshold mentioned but it doesn’t give any direct indication about the noise. It might be useful to show a single plot, rather than refer to a figure that is used later, that overlays the noise-hit occupancy and hitoccupancy vs. threshold for the module at this point in the text.
  • I think the noise is properly shown on that figure (at least for the purpose of validating this choice of 4800 e)? We think it’s better to use one figure rather than put the same information twice? We could move that figure earlier so the reader doesns’t need to “skip ahead”? For now we’ve left it as it was.
• L135 : ‘almost 100%’ - please be more precise as to the exact value at which you find the efficiency plateau.
  • We specify now that it's 99.75%
• OC L142 : An additional sentence explaining why it is important to maximize the fraction of events with a cluster size greater than one would be good.

  • Such clusters become increasingly likely as the incident angle of the beam increases and charge deposited by the protons is more likely to be recovered across multiple strips.

• L146 : ‘DOT’ or ‘DUT’?
  • DUT! Sorry!
• L146 : if you have the data collected from the online measurements of efficiency here then please include a plot that shows them here.
  • We do not have such a plot, and prefer only to show results properly reconstructed after a full alignment.
• Also, can you be a bit more explicit about how tracks near the edges of the sensors were not properly taken into account? And explain why that affects the efficiency?
  • This online calculation, which uses a less precise geometric alignment of the DUT, did not reject tracks just outside the actual sensor boundary from being considered when computing the efficiency.
• L150 : Please quantify rare. And .. do you know what the source of these ‘extra’ clusters in the collected data is? If so, please include an explanation for them.
  • We've changed this sentence to "Clusters not associated with a track are discarded." We don't want to quote a number since it varies dependong on the threshold (and geometry).
• OC L168 : Perhaps this is obvious, but do you understand why the efficiency is lower for the second threshold?
  • Unfortunately no, not exactly. Ee aren’t sure why it’s lower. These thresholds are untrimmed so it may have to do with that? We aren’t sure what (or if) to comment.
• Figure 10 : Was the scan of the secondary threshold not performed for the same set of thresholds as the primary threshold? Its hard to tell from the plot whether there are points at values below 15ke or not.
  • There are no points below 15ke.
• Also, can you please mention the primary threshold used for those scans? What value was it fixed at?
  • The primary threshold is not fixed to 30 DAC units below (except for one point where it is 25, not sure why). We prefer not to mention this since they aren’t supposed to depend on each other and we don’t want to imply they do.
• L175 : 14.7 um is the width of a fit to what?
  • The resolution is extracted from the data: it is a free parameter which floats simultaneously across all runs (with the effect of the angle taken care of by the 1/cos term in each fit). The resolution "at the DUT" is varying, so I'll add to the text that this value corresponds to the alpha = 0 case.
• Figure 9 : I personally still find the title of the y-axis very confusing. Not all the data points there describe the same thing, and its a busy plot.
  • It is a rather busy plot, but we’re not sure what else to label the axes. The left axis is definitely the efficiency since it’s events / triggers. The right axis is the noise occupancy (in different units). Is there a better way to represent these?

Section 5 :

• OC This is a bit.. terse as a conclusion. Perhaps include a table that shows the properties of the DUT studied with the data collected at the test beam and compare those with the specs?
  • Indeed: we have significantly expanded it. We don't have a table, as there aren't really stated "specs" to compare to for most measurements, however, we do compare to the simulation to drive home the point that the SSAs and sensor are behaving like they are supposed to.
• Also - given that you spend quite some time describing the simulation used to analyze the data collected a sentence or two about its use would also be useful.
  • Added.

Responses from authors on some comments (all other comments implemented without issue):

Line 69: The 4.5k electrons mentions in section 2 is the threshold intended at the HL-LHC, while 6.2k electrons is what was used for the timing optimization at the beam test. The idea was to be "well above" the noise so there was no ambiguity about the definition of efficiency (since the online reconstruction isn't perfect, as noted later). To try and clarify this point, I've changed how the 4.5k number is introduced (referring to the value expected to be used at HL-LHC rather than some global "standard").

Line 97: The DUT was triggered by the telescope (which is itself triggered by the scintillator). No change to text since it's correct.

Line 105: "SLVS" seems to be the term in wider use (at least if the reader is curious it is what a google search will yield the correct information for). It also aligns with the SSA manual. No change made.

Table 1: It's not clear what plot this would be. Technically the plots presented later show "how good" the model is? No change made, but could make this last point explicit?

Paragraph containing line 180/181: Moved the first sentence to the previous paragraph and deleted the rest.

Line 206: This has been clarified, specifically mentioning that the SSA's HIP threshold is used to flag HIPs (not bound their energy).

Same paragraph, end of line: I think this is no longer relevant? The contribution is binary, so the only relevant information is the efficiency. No change.

Line 192: For now we've left it as Q, but this could be changed if others agree.

Line 215: Sorry, this was very unclear. The telescope resolution is what is being extracted here, with the other model parameters fixed. Text is clarified now.

Line 223: This is a bit difficult as the telescope resolution plays a part in the discussion. For now I haven't changed it, maybe others see a neat way to move things?

End of section (cluster resolution): We aren't sure what number we can cite here, the behavior is expressed in the plots, and depends on the angle. To be sure the reader is able to refer to the figure when reading thhis statement, we've moved it closer to the original statement of the measurement (this way the thought is not broken up by the interstrip discussion).

Line 245: I think it is still worth mentioning: if the module behaved differently than our expectation from such a simple model, it would be indicative of a pathology (i.e. if even at the best fit values, the model and data didn't agree). No change for now, but can try to rephrase.

Line 9 : "The current tracker [4], composed of a pixel layer and a strip layer will be replaced by.." - this makes it sound like the current CMS tracker is made-up of two layers. Please rephrase.

Done

Line 12 : Please also include the expected dose (TID)

Done

Line 24 : "..Concentrator Integrated Circuit (CIC) [10] distributes clock, trigger and control signals .." - the CIC does not distribute cock and trigger (or any fast commands) to the PS front-end ASICs. That is the role of the lpGBT…

Done, including new mention and ref to lpGBT.

Line 27 : "with large ionization (HIP)" - perhaps replace with "from highly ionizing particles (HIP)"; that then also defines the acronym

Done

Figure 1 [Caption] : " The z direction points along the beam " - Perhaps beam axis rather than beam would be more correct .

Done_

Figure 2 [Caption] : "Simultaneous hits (red) recorded by the MPA and SSA only form a stub if the hits in the SSA are within some fiducial region (blue) of the short-strip sensor, seeded by the location of the hit in the macro-pixel sensor" ; I am being kind of picky here but its the clusters (not the hits) that are usd to form the stubs. That's shown quite clearly in the data-flow diagram later in the text so perhaps this caption should be modified to match. Also, the cluster acceptance window .. is that defined as 'n-strips away from the correlated cluster'? Or is it a search window entered on the seed cluster? I thought it was the latter, but maybe that's only in the CBCs?

_This seems needlessly granular for a figure caption in the introduction, especially as theses concept (clusters, centroids) haven’t yet been introduced, so to keep things simple without being blatantly incorrect: Simultaneous hits (or clusters of hits) recorded by the MPA and SSA only form a stub if the hits in the SSA are within some fiducial region (shown in blue) of the short strip sensor, seeded by the location of the hit in the macro-pixel sensor.

Line 34 : "The paper will first describe the SSA chip, two-SSA module under test and the experimental.." - missing article before two-SSA?

Done

Line 50 : "carries up to eight hits or clusters of neighbouring hits" : sorry, again my confusion about consistent use of hits/clusters. The SSA can transmit up-to 8 centroids per 40 MHz clock cycle to the MPA; and a centroid is defined as the geometric center of a strip cluster detected by the SSA. Perhaps the sentence can be re-phrased to clarify that this is what is happening. To me this would, again help the text match what is later presented in Figure.4. I think it would also be helpful if your sentence made it clear that any data compression (clutsering) on the L1 path happens in the MPA. It is kind of alluded to in the text and Figure.4 but not explicitly stated anywhere.

Used this opportunity to define centroid and will try to be consistent with its use going forward.

Line 58 : "detector under test (DUT)" : Personally I've only ever seen "DUT" being used to refer to a device under test and not a detector under test.

Done

Line 69 : "Each chip’s stub data lines, intended to pass cluster locations to the MPA in the PS module, are instead connected to the other chip..." : I realize this isn't relevant to the paper, but for my own curiosity. What then happens to the centroid data from the first chip? Does this mean that using a 2-SSA module to study the centroid formation is only possible from the second chip?

Lateral lines now introduced with SSA chip, and this is now correctly stating that the lateral lines are circularly connected.

Figure 5 [Caption] : "The SSAs are bump bonded (PbSn) to the sapphire interposers through which are in turn bump" : this sentence doesn't sound quite right to me.

Fixed

Figure 5 [Caption] : "HV to bias the sensor is provided by the PCB" : does this mean that there is a component on the SSA test board that produces the -350 V?

Changed to “Transmitted through the PCB.”

Line 78 : "can be tuned against an external reference to ensure a known charge is injected" : nowehere in the text does it explicitly state that the 52 fF capacitor in the charge injection circuit is per front-the end, which makes the point of this step a little un-clear. Also, if the tuning of the external reference was done on the module then please quote what the channel to channel variation in the injected charge was.

Clarified, including that the external tuning is done so that each channel receives the same charge. Unfortunately the pre-tuning values are not recorded.

Line 95 : " The DUT was placed in a 120 GeV proton beam with between 100 000 and 200 000 particles per spill and was triggered by and shared a 40 MHz clock with the telescope" - technically aren't both the telescope planes and the DUT sent a trigger from CAPTAN when the scintillators?

Correct: fixed in text.

Line 98 : "... so that the phase between the beam and telescope clocks remains fixed.." : I don't think that this sentence clearly described the motivation behind obtaining a 40 MHz clock derived from the accelerator clock. My understanding is that the point of using a 40 MHz clock (which is actually used by the FC7 to produce a 320 MHz clock for the SSA; the SSA uses the 320 MHz clock and the incoming T1 stream to generate the on-chip 40 MHz used for sampling) is to ensure that the phase between the sampling clock in the SSA and the incoming particles is fixed. If the FC7 was designed to run on 53 MHz then there would be no need to divide the accelerator clock by anything; but its not. Thinking about it, perhaps its better to move this sentence (and add the necessary explanation) to the following section?

Added a description of the clock details (and motivation). Should be clear now?

I now realize that at no point in the text has the interface card been described. Perhaps its worth adding a short description here?

Added

Line 106 : "Fifteen of these lines are for the cluster centroids which are sent at each 40 MHz clock cycle" : I thought there were 8 centroid lines per SSA; so wouldn't that make sixteen? If the interface card required some of these to be not connected then please explicitly state that. I realize this is a detail that might only be picked up by those familiar with the OT readout chains but its worth pointing out since earlier in the text you also mention that each chip can send up-to 8 clusters to an MPA. Also, I am now confused by the previous statemtent in Line 69 describing what happens to the centroid lines from each chip. Please clarify.

Done. Indeed: not enough connections on the IC --> PCB connector

Line 112 : "Both the DUT and the telescope are read out using the ”Off the Shelf” dataacquisition program" : I thought I mentioned this in a previous draft; but perhaps I forgot. Please re-phrase this to clarify that OTSDAQ is not used to readout the 2-SSA module. I am not sure what is done for the telescope, but I know for a fact that the readout of all OT prototypes is done by the Ph2ACF. OTSDAQ is responsible for controlling the start/stop signals that are sent to the Ph2ACF, but the complete readout chain (SW+FW) is using tools developed by the CMS-DAQ group.

Fixed: (including Ph2 intro in preceding paragraph).

Equation 1 : is possible to make sure that the {N} appearing here matches the {N} that is in the text?

Fixed? I think this is the best we can do?

Line 120 : "The noise {N} is sampled from a gaussian with width 830 electrons" : I find this confusing : is this just a typo and should instead be describing the mean of this gaussian? I would have assumed that the noise would be sampled from a gaussian distribution whose mean corresponds to the mean noise measured on the module, and whose width is proportional to the RMS in the noise measured across all channels in the module? Can you please clarify why that isn't the case?

The noise can also bring down the reconstructed charge, so it is a gaussian centered at 0 with a width of 830 electron. I’ve made this clear in the paper text now.

Table 1 : can you please clarify where the errors in the fit parameters come from?

Done (they are jut fit error)

Line 141 : ".. or which passed through the DUT without registering a hit " : In my opinion this is no longer alignment but an actual part of the data analysis later. To me the point of the alignment is to ensure that you have a good description of where the track is pointing to on the DUT; to then ensure that any subsequent analyses that involve efficiencies are meaningul.

We agree. Removed the last bit.

5.3 Timing efficiency In your response to my previous round of comments you explain that you would prefer to only show results after the full alignment; which I totally understand. However, you also say that you do not have the plot I asked for but in the text you refer to the online calculation of the working point. So I assume there must be a log somewhere with this information? The reason I am insisting is that it might help show the importance of selecting the working point with full tracking rather than just a crude estimate of the efficiency. Also, I understand that the shape of the curve is still not well understood, but I think being clear about that in the text is preferable to presenting the plot as is with no explanation at all.

We really prefer not to show ANY data that didn’t go through the full offline (validated) reconstruction. We have the statement of sub-optimality of using an approximate efficiency calculation, but adding more information here will not lead to a better understanding, especially since the actual efficiency plateau is 95%, had some jitter, and in the end the optimal point is just 1 dac unit off (and is likely to raise as many questions as it answers).

Line 167 : " This trigger signal is provided by the beam telescope" : I think that both the DUT + the telescope receive a trigger from the scintillator.

Done.

Line 168- Line173 : "Since the processing and distribution of the trigger.....of the timing offset" : The way that the text now reads seems to imply that what you show in Figure 9. is somehow related to the latency; whereas the data shown in 9. is on data collected for a fixed latency. Please modify the text to make sure that this distinction is clear.

Done.

Figure 12 : My understanding is that the SSA can indicate up-to 24 clusters with at least one strip that has passed the second threshold; and that the HIP flag indicates that at least one strip in that cluster has passed the second threshold : "The HIP flag generation consists in a fast hit clustering followed by a detection logic able to verify if the high ionizing particle threshold was passed for at least one strip within each cluster" So I am not sure that its clear to me that the two threshold are completely independent as you state in your comments; but I might be wrong there! Can you please clarify? In addition, if its the case that the HIP flag only indicated that one of the strips in clusters has passed the second threshold then I think I need some more explanation for how the 'efficiency' shown here is calculated for multi-strip clusters.

The efficiency is calculated on a per-track basis, not a per strip, so there should be no ambiguity? (i.e. we clearly know for each track whether or not it was flagged as a HIP) The two thresholds are independent. I think this is clear as currently stated, so no changes made.

Line 189 : "pointing towards the sensor", can you please be more precise in how you define this?

Changed to "crossing the sensor".

Line 200 : "A decent qualitative description can be reached based on this simplified model.." : do you have any explanation for why the model seems to systematically overestimate the efficiency at higher thresholds? And underestimate the fraction of 1-strip clusters at low threshold (seems to do a better job of this at 0 degrees compared to to other angles)? Can these two deviations from the data be related and help improve the model? Or point to what physical effects can be included to improve the model itself?

We don't have answers to either question. It's possible they are related.

Figure 11 : If I zoom in on the plot it seems like the points in green (13°) seem to be trending down at low thresholds? If that is the case then why is that happening?

We aren’t sure. A possibility is that the beam shifted during the run, so that the efficiency measurement isn’t perfect? Not sure what to comment.

Line 212 : " The resolutions of the telescope (modelled s a Gaussian distribution) is extracted from the simple model by being fit for simultaneously across all angles" : please clarify, I don't really understand this sentence as written here.

Removed the word “simultaneously” which seems to have confused everybody.

- please check everywhere your distances between number and unit

Done

- please place your figures properly. Even if JINST may move them around (usually they don‘t!), this paper will be public also as CMS Note and there it should look nice also. so please avoid half-empty pages like on page 8, and pages with just 1 plot, like page 9.

Done___________

- „a pixel sensor“ „a macro-pixel sensor“

_Done

- „stacked over each other“ perhaps „stacked on top of each other“ or some other re-phrasing

_Done

- „SSA provides“ „The SSA provides“

_Done

- „with MPA“ „with the MPA“

_Done

- line 1: the comma needs to be removed

_Done

- line 4: „the total“ „a total“

_Done

- line 7: „compared to“ : this makes no sense, maybe you mean „to be compared to“ ?

_Done

- line 9: „composed of a pixel layer and a strip layer” : I think one should talk here of “detectors”, not “layers”

Done

- line 9: comma needed before “will”

_Done

- line 9: reference [4] is a conference report. This is not appropriate. Please replace with Ref. [2] plus the Phase-1 pixel paper: https://iopscience.iop.org/article/10.1088/1748-02221D/16/02/P02027

_Done

- line 10: “from the beam“ : maybe better to say „from the beam line“

_Done

- line 12: distance before „n_eq“ should be a small space

_Done

- line 12: I think the comma is not needed

Done

- line 22: typo „wireboned“

Done

- line 22 and many places: be consistent with hyphenation of „bump-bonding“ and „wire-bonding“; I would prefer with hyphen, please seach for string „bond“ and fix everywhere

Done

- line 24: „Concatenator“ „Concentrator“ !!

Done

- line 26: please refer to Fig. 3 earlier in this paragraph, before you describe the PS module, so that one can look at the figure in parallel already.

Done

- line 26: „diagram“ „drawing“

No longer relevant due to other changes

- line 27: here you introduce HIP but you do not say what the acronym means in words. Either introduce it properly here or introduce the acronym later.

Done

- line 28: „The SSA“

Done

- line 29: „the MPA“

Done

- line 34: „two-SSA module“ „the 2xSSA module“

Done

- Fig. 3: typo „Senor“ in the drawing labels

Done

- Fig. 3 caption:

- I think „diagram“ is not the right word (twice), maybe „Exploded view“ and then „drawing“ or so.

- „pixel sensors“ „the pixel sensor“

- „of PS“ „of a PS“

Done

- in general it is confusing to say „starting from the topmost layer” and then “in the central part of the module”. In fact you are NOT starting in the top-most layer, which shows the hybrids. It would be better to mention all parts.

We didn't label all components but made sure to point out that we are only noting “key” components.

- line 40: „built with 65 nm CMOS technology” “designed in 65 nm CMOS technology” or perhaps “fabricated in 65 nm CMOS technology”

Done

- line 40: 65\,nm

Done

- line 43: “and for the“ „and one for the“

Done

- line 44: it is not clear what Q is, the threshold? in units of charge? It seems also not needed here.

No longer relevant

- line 45: here you introduce MIP again

It seem to be the first. We may have introduced HIP?

- line 49: fix distances in 200\,ps and 25\,ns

Done

- line 53: comma needed before „is shown“

Done

- Fig. 4: You have „1.6 Gb/s“ in the sketch for the stub readout, but in practise this is 5 x 320 Gb/s, correct? I would find this more clear, because on the FEH data are not transmitted at 1.6Gb/s.

Done

- Fig. 4: typo „Stup“

Done

- line 66: „the sensor thickness is 240 µm” : you never say if this is the active or physical thickness. Please clarify this, and quote both numbers.

We’ve specified that this is the active thickness. The physical thickness is essentially identical (the sensor was thinned). We note this as well.

- line 68: fix distance in 350V

done

- line 69: “where” “were”

Done

- line 75: “standard discriminator threshold“ : it is here not very clear what you mean with „standard“. Probably you mean „the one that is not the HIP threshold“. Please find a better way to phrase this, or drop „standard“.

Done

- Fig. 5, caption: - the word „through“ in 5th line should be removed

Done

- in line 5: „which are in turn bump bonded“ : I think this should read „wire-bonded“ !

Done

- line 88: no comma here

Done

- line 89: „and cover an active area”: it is not clear who is covering. Start a new sentence. You are squeezing too much into one sentence here.

Done

- line 94: “which have the better resolution” : this cannot be understood because you never explain in what direction the strips are pointing. Explain in lines 88/89 or so how the strip sensors and pixel sensors or the telescope are oriented.

Done: Should be clear now that the stip planes alternate between horizontal and vertical, and have higher resolution per plane than the pixels (and that our DUT is right in hte middle of them)

- Fig. 6, caption: repetition “at the at the“

Done

Section 3.3

- line 102: „Kinetex“ „Kintex“ !

Done

- line 104: „via I2C “ „via the I2C “

Done

- line 109: please write the x in „2xSSA“ as you do at other places, not as the letter x but as \times I guess

Done

- line 113: „... based on artdaq [14], andmaintained by Fermilab and processed with theMonicelli software package“ : this sentence is grammatically not correct, the data are processed, not the program, you are trying to say too much in 1 sentence. Split in two sentences.

Done

- line 118: typo in „interstip“

Done

- line 118: is the forward ref to Fig. 11 really needed here?

Done

- line 118, page 6, 2nd line: „and an supply voltage“ „and a supply voltage“

Done

- line 118, page 6, middle: „a charges may diffuse“ „charges may diffuse“

Done

- line 18, page 6, lower half: „and subtracting it from the adjacent strip” : I think this should be “and subtracting it from the traversed strip”

Done

- line 18, page 6, 4 lines above formula: typo “Ths noise“

Done

- line 120: „x_e is“ „and x_e is“

Done

- line 121: „gaussian“ „Gaussian distribution“

Done

- Table 1: in 2nd column you may want to add brackets around the values, e.g. (20.6+/-0.2)ke

Done

- line 126: I am not sure „Data preparation“ fits well as a section title. You are also showing nice cluster distributions here...

Done: Changed to "hit clustering"

- line 146: suggest to remove „seen in Fig. 6“ : it does not read well and you are refering to Fig. 6 in line 148, which is sufficient

Done

- line 148: „around the rotated x axis“: I don‘t understand what you mean with „rotated“ here, perhaps the word can simply be dropped?

Done

- Fig. 8, caption: in the last line „of y-position“ „of the y-position“

Done

- line 186: „and counted as a matched hit if they are” : again this is grammatically and semantically not working, what is counted? Perhaps “and hits are counted as matched if they are”. Or simply split into two sentences.

Done

- line 202, line 204: twice “This information”, rephrase one of them

Done

- line 204: “can be combined with data from other modules in CMS” : I think you mean “subdetectors” here instead of “modules”

Done

- Fig. 12: This figure would profit from a more informative legend. Suggestion: 0°, standard threshold ... / 0°, HIP threshold ...

Done

- line 212: typo “s a” “as a”

Done

- line 213: the word “for” needs to be removed

Done

- line 216, Fig. 13, Fig. 14: I am still confused by the factor of 1/cos alpha that is taking into account the angle dependence of the telescope resolution. Why are you quoting the value for alpha = 0° in all sub-figures of Fig. 13 and 14? Should the sigma in those plots not be corrected for the angle?

Done

- Fig. 14, caption: in last line use proper minus sign in “-50µm”

Done

- line 239: spurios space after “18°”.

Done

- add always a comma before the DOI, as you do in [1]

Done

- protect the capitalization of the title, this affects [5], [6], [13]

Done

- you are almost always missing the page number(s) of the article, meaning that your journal reference is incomplete! This affects [2], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [16]

Done

[1] It seems you are just referring to the 1st chapter of the report – why?? It should read: “High-Luminosity Large Hadron Collider (HL-LHC) : Preliminary Design Report”, the report number is CERN-2015-005, and the DOI is also not corret, it should be https://cds.cern.ch/record/2116337

Done

[4] replace this reference, see my comment to the text

Done

[5] remove the text on the conference, not common to mention it

Done

[6] remove text on conference

Done

[8] this should be formated as „PoS(TWEPP-17)031“

Done

[9] Author is not correct, and format as given in [8]

Done

[11] Author is not correct! Remove „jun“

Done

[13] Remove „03“

Done

[16] Remove „no. 1“

Done.

Abstract:

..for the upgrade of the CMS Outer Tracker for the High Luminosity LHC.

Need to introduce „PS-modules“ or just say modules

The SSA provides…

Done

Not sure you can talk about „Level-1 trigger accept“ and „Level-1 trigger primitives“ in the abstract without introducing these terms. I suggest to rephrase to a more generic statement.

Simplified and Unjargoned

Results from the first prototype module..

Done

L4: a total integrated luminosity

Done

L5: is planned to be > will be

Done

L6: Suggest to add a few lines introducing the CMS trigger system.

Done

L8: „these requirements“ now seem to refer to the sentence about the trigger system. Suggest to rephrase.

Done

L8: repetition of „entire“ „entirely“

Done

L9: CMS has several layers of pixels and strip detectors!

Done

L10: write at least „within a radius of 20cm from the beam“

Done

L12: the 2.3x10^16 refer to the IT, so what you write is a bit confusing.

Clarified by adding both numbers for both trackers subsystems.

L19: digitised by a > read out by a

Done

L20: and have been extensively described > , described in Ref.

Done

L25: this is the first time you mention that there are eight chips on each side of the module. Suggest to start by: „A module is read out by two times eight SSAs and MPSs…“ From the sentence it is not very clear whether the CIC is for 8 or 16 SSA/MPA.

Done

Fig 3: Add description of all parts that are shown in the picture to the caption (e.g. CIC, connector, aux chips).

We prefer to keep it to the “main” pieces (the text explains the other structure). To make this work, we’ve noted in the caption that we are describing “key components”. We’ve also noted the CIC, since it’s labeled in the bottom diagram.

L27: no need to stress that it is the only one. Just say: „The SSA is capable of…“

Done

L28/29: The SSA… the MPA…

Done

L30: a sensor

Done

L33: I would argue that the measurements depend on the performance of both, sensor and readout chip.

The measurements do, but we still think the “primary goal” here is the front-end (the sensor itself has been tested elsewhere).

L34: the two-SSA module

Done

L43: L1 has not been introduced.

Done

L43-47: Suggest to split in two sentences.

Done

L56,57: What do you mean by this?

We think this is clear? What isn't understood?

L60: the trajectories are only known once you measure them with a telescope. Suggest to rephrase

Changed to “measured and exploited”.

L69: above you say that the MIP threshold is 4500e. Why do you operate at 6200e?

Discussed in meeting. We chose a higher threshold to be absolutely immune to noise (with hindsight we could have done with a lower threshold, but that’s the data we collected).

L70,71: What do you mean by this?

Should be clear now.

Fig 5: … interposers which… (remove „through“)

Done

Fig 5: Split in two sentences: „… (PCB). The prototype modules has a similar configuration…“

Done

L73: individual channels of the front-ends

Done

L76: using a known signal

Done

L77: not „on-chip“?

Done

L81: remove „Fermilab“ from the sentence. It already says „at the Fermi National Accelerator Laboratory“

Done (although I removed FNAL - technically that is an old term and Fermilab is just Fermilab)

L95: the information about the energy and the number of particles per spill should come earlier (after L82)

Done

L107: I stumbled on this already on

L51.. not sure if the nomenclature is optimal. I would not call the path that is sent based on a L1 accept „L1-trigger data“, as it is not data that is used by the L1 trigger, but offline (if I understand correctly).

Fixed? No longer calling this the “trigger” path, and have defined L1 early on (noting there that it is the data “released” by the trigger)

L110: Add a reference for Ph2ACF.

Done

Page 6, middle of paragraph: „….between two strips charges may diffuse…“

Done

„.. in the adjacent strip (and subtracting it from the actual transversed strip).“

Done

L121: „..Gaussian with a width of 830 electrons.."

Done

L122: What do you mean by "if the proton does not traverse them“?

I’m not sure why we wrote this. Removed. (We had just meant that in theory there is charge sharing even in further strips, but it’s tiny)._

L130/131: I find this statement a bit confusing, as also the L1 hits are from the SSA.

_Fixed by specifying that we are talking about the information missing in the stub data path.

L132: Decide if you want to use consistently „electrons“ or „e-„ in the units and then use it everywhere.

Done

L134: as a function

Done

L175: above 6200e was „the standard threshold“? Suggest to remove „standard“

L191: remove „standard“. I now realise that by „standard“ you mean „not HIP“. Suggest to find a better name.

Done: changed to "detection"

L195: Why „two-strip clusters“? Any larger size clusters as well, no?

Done

L204/205: This sentence should be moved to the paragraph in the introduction where you describe the HIP threshold.

Done

L212: The resolution… is…

Done

L243-245: To me, this conclusion is too strong. There are many more tests needed to fully validate the front-end design and in particular also the Ph2 ACF DAQ system.

Done

Abstract:

L4: The SSA

Done

clarify here that the focus in this paper is on the hit data (triggered) path and not stubs

I think we don’t need to be so specific now: the new text clarifies that the stub performance (as much as can be checked on just an SSA) is ok.

L3: accumulating a total

Done

L6: increased latency of 12.5 us → 'will allow a latency of up to 12.5us' sounds more appropriate

Done

L7: is it not 4.8us max latency at present? (i forget!)... please check

It’s 3.6 or 3.8 us (depends when/who you ask), which I rounded up to 4um (similar to how it was presented in the TDR). I propose we keep it 4um.

L8: remove “entirely”

Done

L9: Pixel and Strip detector

Done (I put "systems")

L20-21: fix formating

Done

L22: wireboned → wirebonded

Done

L24: concatenator → concentrator

Done

L24: i think the lpgbt does that - please check

Done

L26: the SSA is also

Done (though the sentence has changed a bit)

L27: large signals from Highly Ionising Particles (HIPs).

Done

L28: The SSA

Done

Fig 3 caption: not the SSA - the hybrid!

Done

L34: the two-SSA module

Done

L43: and one for hip flagging

Done

L43-44: ...can be programmed - with typical thresholds designed to detect…

Done

L46: “,” after threshold

Done

L52: latencies “of up to”

Done

L53: latter --> on the triggered (L1) data path.

Done_

Figure 4: layers --> something else (several suggestions from ARC)

-->both SSA and MPA readout functionality.

_Done

L56: especially --> including

Done

L56 timing --> synchronization?

Done

L57: various prototypes

Done

L60: “the incoming”

Done

S3.1: mention purpose of interposer

Done

Capt F5: strips are wire bonded! And remove “through”

Done

L75: additional → configurable

Done

L77 Onboard → on chip

Done

L78: to account for process variations.

Done

L85: No need to mention strips aand pixels

Done

L86: remove second half of sentence altogether

Done

L88: with a strip pitch of

Done

L92: beam test COMMA

Done

L97: triggered by the telescope. A 40MHz clock, common to both the DUT and telescope, is obtained…

Done

L98: this yields 39.75MHz, so not fixed phase or...

You’re right, we’ve now been more specific about this (actually we did 25.15ns instead of 25ns, so the phase is fixed, we just stretch the clock a tiny bit)

L101: The DUT data acquisition...

Done

L102: Kintex

Done

L103: through a custom ...FMC

Done

L103++: bit confused about the interface here, certainly worth mentioning early that you have an electrical interface (as opposed to optical). Also instead of taking about the individual chips, its better to refer to the module itself as an 'entity' i think.

Done

L106: on each

Done

L106++: some more confusion here about the stub lines as you mentioned earlier that they werent connected on the interposer?

Should be clear now

L111: reference?

Done

Page 6 - middle of paragraph: ...two strips charge may diffuse...

Done

L124: proton surely?!

Done!

L131: bit confused about this, surely SSAs output this info?

We meant that the SSA centroids (if we had taken them directly from the stub data path) only return position. We’ve added this to the sentence to make it clear what we are talking about.

L173++: there are different effects to take into account here - the latency (which you talk about) and the sub-25ns timing offset (where i cant see any mention of it). Since you show the plot in fig9 i think it needs to be introduced, and then you need to say how this was tuned (ie. using some external delay logic? or post selection if you are able to record TDC info?)

Not TDC, but clock deskewing available on the SSA. Now described.

L202-205: this is fine (if repeating yourself) but probably more relevant in the intro where this thresh is introduced to give it some context

Moved to intro

L212: as a

Done_

L213: being fit for simultaneously ?

_Removed “Simultaneously” which seems to have confused everybody.

L235: performance cant be tested! measured? evaluated?

Done

L244-245: maybe too strong at statement, so best to be specific about what is validated, and what remains to be validated and what the plans in CMS are to do this.

Done?

[1] Use CDS reference instead of these two

Done

[2] JINST 3 (2008), S08004,

Done

[3] surely youre looking for the technical proposal here - rather than the scope document?

Done

[5] Caps - CMS CBC 2S

[5] put the DOI at the end and be consistent with formatting (e.g. ref 4 has no https://doi.org, but the href works, which is nicer)

Done

[6] Caps - CMS CBC HL-LHC ASIC

[6] DOI - same as ref 5

Done (they are different)

[7] (2016), C01054

DOI formatting

Done

[9] fix author list and Phase

Done

[11] (2017, P06018,

And remove jun

DOne

[12] Fermilab Test Beam Facility / DOI format

Done

[13] Caps - FC7 AMC DAQ CMS and remove 03 and (2015), C03036,

Done

[16] Landau and DOI formatting

Done

• Comments by Katja, 2.9.2021: pdf
• Abstract: Fixed
• L7/9: Fixed, with some rephrasing for line 9.
• L19: Fixed
• L25: Fixed
• L30: Fixed
• Fig 1 caption: Fixed
• Fig 2 caption: Fixed
• L58-62: Split into 3 sentences.
• Fig 4: fixed
• L78: Fixed
• L79: Fixed
• L82: Changed
  
• Fig 5 caption: Fixed
• L104: Fixed
• L123: Fixed
• L126: Fixed
• L133: Fixed
• L136, incident angles: I think this is correct as is.
• L136, horizontal angle: now says "horizontal rotation angle $\alpha$ which is what we use elsewhere in the text.
• L136, mismatch: Fixed
• L136, comma: Added
• L136, width: Fixed
• Table 1 caption: Fixed
• Fig 8 caption: Fixed
• L206: Fixed
• L208: we now say "horizontal rotation angle $\alpha$" everywhere in the text. Can be changed to something else if this isn't right.
• L248: Will see how it looks when all other changes are applied.
• References: Fixed!
• Comments by Sarah, 12.9.2021 : pdf
• Intro (just typos): Fixed
• L61: OK, I added a sentence "In the PS module, the L1 data is also transmitted to the MPA, which forms clusters and transmits them (along with the clusters from the pixel layer) to the HLT.".
• L79: We just mean that the "inactive" part. Switched the word physical to inactive to make it clearer (and fixed the typo).
• L123 (part 1): Fixed
• L123 (part 2): We have (deliberately) avoided defining a chip 1 and chip 2 until now. I'm not sure what information this delivers to the reader that they can interpret (since the stub lines are not used for data taking in this paper). Would prefer not to add anything here.
  
• L132-134: Sentence removed from this section (where it was indeed confusing) and we expand a bit more later when it's relevant (where we talk about why the working point for timing isn't perfectly optimal).
  
• Simulation (part 1): Simplified to "is simulated by subtracting a certain fraction of the expected charge in the traversed strip and adding it to the adjacent strip"
• Simulation L139: I've specified now that the noise is applied to each strip individually (i.e. 830 is not divided by 120), and that it is measured from the average across all strips.
• L186: You're right, I oversimplified the whole process into "collected". I've expanded this section a bit to be more cohesive/correct. "In addition, since the digitization of the collected charge by the analog front-end circuit is not instantaneous, the arrival time of the proton within a clock cycle can affect the reconstruction efficiency. In the extreme case, the signal from charge collected in the strip does not reaches the threshold needed to indicate a hit within the 25\,ns window selected in the buffer (in such cases the hit would appear in the next window)."
• L190: I've updated the sentene to "To minimize this effect, the SSAs can be programmed to effectively delay the trigger arrival time by shifting the phase of the sampling clock." The 3.125 vs 200 is now covered in the orignal description of the SSA (back in section 2) and the fact that we step in 3.125 for this measurement is just mentioned when we point to the plot. (We could have I suppose taken a finer scan at the beam, it would have taken a long time to evenly scan across the whole 25 ns)
• L229: I think what I've added now is clearer. Please have a look.
• L240: In this sentence I'm refering specifically to the two-strip clusters. I think your statement is about the resolution in general? Mark noted that the "the" in the sentence should be "their" which I think makes it clearer?
  
• L261: You're right. In the end we can only state that the agreement with the model validates the behavior of the front end. I've removed the statement about CMS requirements and I think the conclusion reads just fine without it (especially now that we have tied it also to previous SSA results).
• Comments by Lea, 12.9.2021 : txt
• L3: Fixed
• L19: Fixed
• Fig 1+2: Increased to \textwidth. Looks pretty good!
• Fig 2: Fixed caption.
• Difference in latencies in Sec 1 and 2: It seems (from the SSA manual) that the SSA has a slightly higher capability than what is needed for HL-LHC. I'll confirm with the chip designer that there isn't a typo in the manual.
  
• L79: Fixed
• L123: Fixed
• Italics for (e): Fixed in text, figures and table.
• Extra space: Nothing visible in the LaTeX, so nothing done. Not sure what the issue is but this line (and paragraph) seem fine in the latest version.
• Figure 8: Fixed! Legend now dodges between the dashed lines.
• L206: Fixed
• Figure sizes (11, 13, 14): I've made them a little bigger. They're now at the limit of what LaTeX can do without making them each their own "row".
• L242: Fixed.
• Comments by Mark, 13.9.2021 : pdf