Review of Engineering Design

N°

Index

Finding Explanation

Findings

Reviewer initials

Action

Remark / Answer

Page

Chap

§

Type

Severity

1

General: There’s nothing about EPICS device support as we have for FlexRIO

The PV list would be more useful with the full db file...so one can see DTYP and INP/OUT fields.

C

1

BBC

A

The information on EPICS device support will be included and the PV list will be modified accordingly.

2

General: The document shall use IDM front page.

W

1

BG

TBD

OK

3

General: no requirements summary

In particular, tuning on Red Hat MRG extension will be required.

1

C

BBC

TBD

A requirements summary will be added.

The entry tuning on Red Hat MRG extension will be added.

4

General: I do not see any mention about the external PCIe CPU and how that will be involved in the Amendment.

My suggestion would be that it is specified, the interconnect and its functions, test plan and so on are specified, preferred HW platform being the same as used by the IO, ref. https://user.iter.org/?uid=6U6H9B

C

1

JS

A

The specification of the interconnect and its functions, test plan and so on are specified will be added accordingly.

5

General: the documentation, test plan and samples are an important part of this amendment. But there is no information about that.

C

1

BG

TBD

This documentation will be delivered separately.

6

General: not enough detail regarding the software design for the products.

C

1

BBC

A

The software design section will be included in the next revision of the document.

7 

General: as it is part of the amendment, I would like to have a section regarding ATCA shelf with full-mesh interconnection to state the current choice and justification.

C

1

AB

A

This section will be added.

8

General: What about MARTe? I would like to know what will be done for this amendment.

C

1

BBC

A

A section about MARTe will be added.

9

General: it is important to state the Open licensing model.

1

C

JS

A

The open licensing model statement will be included  in the next revision of the document.

10

7

1

1.2

The glossary should be revised and include only the required terminology. For instance NetCDF is no more useful…

W

1

BG

A

The glossary will be revised for the next revision of the document.

11

8

1

1.3

The Related Documents should be revised and include only the required ones. For instance [RD9] is no more useful…

Strange by the way that the amendment specifications are not referred: ITER_D_4HVBLJ.

Finally I would prefer that we do not refer any more to the previous specifications [RD1] and [RD8] in order to have a self-explained document.

W

1

BG

A

The Related Documents list will be revised accordingly for the next revision of the document.

12

13

2

2.3

Could be good to reuse the product name from the amendment specifications – in this case, ATCA ADC module

C

1

BG

A

Ok.

13

14

2.3.1

1^st pg

What is the reference to the “Diagnostics Requirements document”?

Q

2

BG

A

This reference will be added to the Related Documents section.

14

15

2.3.1

Last pg.

Samples rejection function is not very clear. Will it be implemented or will it be not implemented? Or do you want to say that the rejection function will be there and it can be used whenever a need arise? In the latter case, please reformulate.

C

2

BBC

A

The phrase will be reformulated.

15

18

2.4

The section praises the virtues of the IPMC implementation. But it is not clear to me will and how the amendment produces the necessary support for the chassis Health Management for the CODAC Core System? This should be the case and it should be stated, from my opinion.

C

1

JS

A

The support for the chassis Health Management will be included.

16

20

3

Same as above, the entire chapter describes the firmware but fails to explain the Linux and EPICS module level support for the CODAC Core System. For example, the timing synchronization with the EPICS time, how it is done? (cf. the NI-SYNC support in current CCS v3.x)?

In general, all the hardware items shall come with Linux/EPICS support for CCS, complete, ready for packaging and with a comprehensive test plan which would allow the setup of fully automated tests 24/7 of the purchased hardware items on any of the new versions of the CODAC Core System.

C

1

BBC

A

The entire chapter will be revised accordingly.

17

23

3

3.2

Why the data flow section is under Firmware chapter?

Q

2

BBC/JS

TBD

This data flow is internal to the FPGA. System data flow is explained in the Beta version documents.

18

23

3

3.2

Up to 48 analogue input channels:

DMA Channel 1 – Real-time data at a programmable sampling rate of 200 kHz to 2 kHz >> does it mean that 48 channels at 2MS/s go through this realtime DMA channel?

Q

1

BBC/JS

TBD

No, the maximum is 200kHz

19

23

3

3.2

Up to 48 analogue input channels: what happen if the user configures only 32 channels for instance? Where the discrimination is done: after the DMA transfer?

Q

1

BBC/JS

TBD

Channel 1 – all channels are transferred to host. The discrimination is made after the DMA transfer

Channel 2 – Descrimination is made on the FPGA.

20

23

• Channel 1 and channel 2: the description is the same... what’s the difference?
• Channel 3: I don’t understand its usage and what the link between the two previous one if any...

Q

2

JS/BBC

TBD

Possibility of having different data rates for RT or scientific data. RT data (CH 1) has less time latency.

Section will be complemented.

Past data is also stored locally in order to allow the system to retrieve data around an event (received from the SDN). This data is retrieved through DMA Channel 3 (a separate DMA channel for operational reasons).