Re: VXS SD Module

["C. Cuevas" <cuevas@jlab.org>]

Hall D Electronics:

Hi Gerard,

Comments are always welcomed and I offer some feedback buried within the 
text below. 


Gerard Visser wrote:
> Hall D Electronics:
>
> Hi Chris,
>     It's good to see the description/requirements document for the SD 
> module posted. I have been looking forward to this. I have some 
> comments if that's ok...
>     1. Page 3, introduction. The SD module has _nothing_ to do with 
> the trigger output data path from the FADC250 (well, apart from the 
> fact that it needs _some_ clock to do that, of course). I think all 
> that discussion should be removed from this document. On the other 
> hand, the SD does feed trigger/clock to ADC250, ADC125, and F1TDC, 
> probably the latter two should at least be mentioned here.
Chris here:  Synchronizing the clock to the multiple fadc250 is a 
critical function of the SD and while it may have nothing to do with the 
trigger output data on P0, it is an essential to provide synchronization 
for the multiple serial lanes that are collected by the 
Crate_Trigger_Processor.  Leaving the discussion about the trigger data 
path is important because it is a few sentences that emphasize the 
design and implementation of a digital (high speed serial transmission) 
of the trigger information.  I agree that we should add  the ADC125 and 
F1TDC modules in this section.
>     2. Page 3, section 3.0. I'm not clear what is implied by "trigger 
> and sync ... can be dynamically changed before registering".
Chris here:  The signals can be delayed and the delay is programmable.  
Need to clarify the sentence.
>     3. Busy out from SD to TI: In the text P.3 this is LVDS, in fig 2 
> this is LVPECL, so one of these is wrong...
Chris here:  BUSY out is LVDS.  Will correct this in the document.
>     4. Negative ECL is shown for front panel trigger out, yet there is 
> no negative supply voltage listed in table 1, probably this is an 
> omission?
Chris here:  Good catch!  Will add this to the table in the power supply 
section.

>     5. For SD to FEE boards, trigger bits are stated to be LVDS on p.3 
> and in fig 5 and fig 3c, and are stated to be LVPECL in fig 4 ("spec 
> sheet", figure caption omitted) and in p.10 section 4.0.6. As I have 
> previously argued in our meeting some weeks ago, I would still 
> strongly argue to use LVPECL in reality. But whatever your choice, the 
> document is quite confused on this point.
Chris here:  We have discussed the signal levels/technology before and 
had subsequent discussions at our weekly 'trigger' meetings.  I believe 
we have a final document that clearly defines these input and output 
signals.  If this was not put on the portal or at least to the 
halld-electronics mailer, we can send that again.
>     6. Can we just change the name of "STATUS_OUT" from FEE boards to 
> "BUSY". This is what we are using it for, right? I think it is 
> unnecessarily confuing to give the busy lines a name like "status out".
Chris here:  I know on the PO tables we have changed the line to BUSY.  
Consider it done.
>
>     7. Section 4.0.1, I would assume that the clock selection is to be 
> done over I2C just like any other setup parameter... "JTAG" here is 
> probably a typo?
Chris here:  Clock selection is selected through the I2C path.  The JTAG 
port is only for configuring the FPGA.
>     8. p3, bottom - "JTAG port to program the FPGA". Have you 
> considered to do that over I2C? It would be easier if you can make a 
> design change and implement to all boards without physical access... 
> Of course you could have some kind of permanent JTAG connection in 
> mind for the system, but that seems to me more complicated than 
> implementing an I2C controlled design download. Especially the more so 
> if you already plan to have a microcontroller on the board to handle 
> the I2C...
Chris here:  Just had Ben and Hai in the room and we had a good 
discussion on the capability to download a new program(firmware) to an 
FPGA via some other method than the permanent JTAG port.  The fadc250 
has been designed so that a new bit-stream can be downloaded via VME to 
the FPGAs.  The design takes some precaution into account, so that one 
does not disturb the firmware loaded into the VME Fpga(Altera) so that 
in case of an error during a bitstream load, one can recover gracefully. 

I cannot think of many occasions where the SD will need firmware 'on the 
fly' so I would not implement another path for firmware download.  Do 
you have an example?  For the Crate_Trigger_Processor we should review 
this, and we will have to thoroughly test and gain experience with the 
implementation we designed on the fadc250 prototypes.
>     9. What is become of all the "skewing" stuff that was discussed, 
> intended to remove slot-slot skew? I am absolutely quite happy without 
> it, do not get me wrong. But on the other hand if you do still intend 
> to have such a function, it really must be included in the block 
> diagrams fig 3a/b and in the description 4.0.6, and I still would 
> expect/"require" that it be done in a way which does not introduce 
> skew between the clock and the three trigger bits within one FEE 
> (payload) slot. I still expect the three trigger bits to be registered 
> by the clock line as the last thing done in the SD to send to each 
> slot. Do I need my mind changed on this? (I think not, you agree in 
> fig "4".)
Chris here:  "All the skewing  stuff" is still in the plan and it would 
be a good idea to add it to the block diagrams and description as a 
'fixed delay' line.  We have measurements of the slot to slot skew and 
also the trace layout(length) report file from Elma for these pairs.  We 
agree that the trigger bits and sync signals will be registered before 
launching onto the backplane and without added skew.

>     10. Regarding the CBLT token (4.0.5), what causes the token to be 
> set? Is this going to have to be done over I2C? Or is there a hard 
> line for TI to SD to do it? In the latter case, it seems to be missing 
> from the various block diagrams fig 2, 3x... In the former case, is it 
> fast enough?
    11. What is TRIGLINKTX and what is Trigger2??
>     12. Busy mask probably needs to be mentioned under 5.0, just as 
> you have mentioned the CBLT mask.
Chris here:  I will answer 10,11, and 12 here.  Clearly the Token 
passing and Busy mask need more details. I believe we will implement the 
token passing scheme as we did for the F1TDC implementation.  The 1st 
board in the readout chain sends the token and the SD passes the token 
to the next module.  At this stage of the draft spec, we have not 
selected the FPGA yet, but our new design engineer Abhishek Gupta will 
be involved in that selection so we will have to be certain it meets the 
speed requirements.

TRIGLINKTX is a signal that is only present in the Trigger_Supervisor 
crate.  Keep in mind that this SD module will be used in the 
Trigger_Supervisor crate so rather than using the Trigger_2 signal in 
this crate we will use the TRIGLINKTX signal to drive the 
Trigger_Distribution modules(TD).  Note that this TRIGLINKTX signal is 
designed on the SD and the only location it will be selected is in the 
Trig_Supervisor crate.
>
>     Hopefully this is a complete list of questions, I look forward to 
> hearing from you or checking out the revised document. Thanks!
>
>     Gerard
Thanks for the feedback.

Chris