M-Labs/saymapp
2
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

edits suggested by m-labs as of jan 10 2019

Browse Source
This commit is contained in:
Joe Britton 2019-01-13 18:43:34 -05:00
parent fe1060ea4d
commit cc14a1cf02
1 changed files with 305 additions and 116 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

421
pp.txt
View File

@ -1,8 +1,42 @@
Here's a coherent project plan for Sayma v2. It is informed by extensive discussion on github Issue system over the past year and recent offline discussion with the Sayma v1 developers. This is posted here so everyone knows what the contracts call for in development of Sayma v2. This plan will be updated if contracts differ from the present plan. Please use existing or new Issues for further discussion of technical topics.
This plan defines concrete performance goals, specifies which parties are responsible for specific deliverables and defines a project management structure. The aim is to provide sufficient specification and structure at the outset that all parties feel comfortable with their responsibilities and minimizes conflict.
This plan defines concrete performance goals, specifies which parties are responsible for specific deliverables and defines a project management structure. The aim is to provide sufficient specification and structure at the outset that all parties feel comfortable with their responsibilities and minimizes the role of ARL/UMD in project management.
The plan includes design choices that simplify Sayma and lower costs. The github Sayma Issue tracking contains a long list of bug fixes and modifications to v1 (https://github.com/sinara-hw/sinara). The plan calls out explicit specifications in cases where there is not a clear consensus in the Issues.
The plan includes design choices that simplify Sayma and lower costs. The github Sayma Issue tracking contains a long list of bug fixes and modifications to v1 (https://github.com/sinara-hw/sinara). I call out explicit specifications below in cases where there is not a clear github consensus on how to proceed with Sayma v2. The plan is not meant to substitute for the Issue system except where which-path clarity is required in which case this plan is authoritative. I will annotate relevant github Issues with a link to this Issue so there is clarity about which-path.
## Performers
Three developers will work together on Sayma v2.
- Hardware Developer
- Integration and Timing Developer
- Software and Gateware Developer
ARL will serve as Technical Point of Contact (TPOC) for the contracts.
## Tasks
Developer tasks are labeled HTj, Ojk and Mjk (jk integers) and are not divisible. If a task or feature is not assigned to a Developer then that Developer is not responsible for it.
## Design Review
The design review consists of three steps: HT1, HT1.5 and HT2. The Hardware Developer has primary responsibility for the design review. Certain review tasks are delegated to other Developers as detailed below. Tracking of design review tasks is in a google docs spreadsheet communicated under separate cover.
## Handling Hardware Flaws
The Software and Gateware Developer and Integration and Timing Developer have tasks which depend on proper functionality of the Sayma v2 hardware. The Hardware Developer testing and reporting expectations are detailed in HT3.
### Flaw found in HT3
If the HT3 report indicates a failing component or subsystem, a Developer working on a dependent task may at its option pursue the following options
- cancel dependent task(s)
- renegotiate contract terms for dependent task(s) with TPOC
### Flaw found after HT3
If a component or subsystem receives passing marks on the HT3 report but a Developer finds a hardware problem after receiving the Sayma v2 hardware the following applies. Said Developer shall
- report the problem and work with the Hardware Developer to identify a patch
- budget 24 hours for hardware-flaw related debugging
- apply white wire patches
- budget for two shipments of PCBs back to Hardware Developer for rework
If shipment budget or hardware-flaw budget is exhausted the Developer may
- cancel dependent task(s) and receive payment for up to 50% task cost
- renegotiate contract terms for dependent task(s) with TPOC
# Definitions
Let __TS-MTCA__ be a micro TCA crate configured as follows:
@ -28,39 +62,61 @@ Let __TS7__ be a Sayma test setup consisting of the following
- All RF channels producing 400 MHz sinusoid
- Cards in adjacent slots
__SAWG v1.0__
The original SAWG was developed by M-Labs for Sayma v1.0. Here, "v1" refers to SAWG with the same feature set but targeted at Sayma v2.
- f_rtio = f_dac_ref = 150 MHz
- dac data rate 0.6 GSPS
- f_dac_clk = 2.4 GHz (4X interpolation)
- synchronization: none
- functionality in 1st Nyquist zone
- 240 MHz is max RF out
- f1, f2: +/- 125 MHz modulation, +/- 100 MHz usable within anti-aliasing filter bandwidth
### SAWG v2.0
This is an extension of SAWG v1.0 with a 1 GSPS data rate and with board-board synchronization.
- f_rtio = f_dac_ref = 125 MHz (same as for Kasli)
- dac data rate 1.0 GSPS
- f_dac_clk = 2.0 GHz (2X interpolation)
- synchronization: new Sayma v2 sysref scheme
- support 2 RF channels per DAC
- functionality in 1st Nyquist
- 400 MHz is max RF out
- f1, f2: +/- 125 MHz modulation, +/- 100 MHz usable within anti-aliasing filter bandwidth
### SAWG v2.1
This is an extension of SAWG v2.0 that includes improvements in performance and gateware utilization.
- support for 4 RF channels per DAC
- spurious frequency components due to DSP: < -70 dBc at full amplitude, constant frequency
- improvements detailed in MT1
# Sayma v2 Diffs
When diff also applies for [Metlino](https://github.com/sinara-hw/Metlino/issues) it is noted.
## RTM Synthesizer
- Layout both ADF4356 and HMC830, change capacitors to reroute clocks.
- Use HMC830 as primary synthesizer.
- problem: random lockups at power cycling, possible fix: possibly due to power sequencing
- problem: unsynchronised dividers, fix: Make FPGA measure the output phase and reset the HMC830 divider until synchronised.
- HMC830 lock status exposed on front-panel LED.
- ADF4356 is backup option. No development of ADF4356 until operation with HMC830 is fully tested and succeeds, or HMC830 bug clearly blocks forward progress.
## AMC clock recovery
Discussed in [meta/issues/15](https://github.com/sinara-hw/meta/issues/15). Also applies to [Metlino](https://github.com/sinara-hw/Metlino/issues).
- Use Si5324 as primary approach for Sayma v2.
- Layout both Si5324 and Tom’s WR PLL scheme that uses Si549 in addition to Si5324
- Change capacitors to reroute clocks.
- Confirm that DCXO and the Si5324 can both be shutdown in software (using SFOUTx_REG), otherwise add a FET on power lines.
- Clear delineation on schematics between Si5324 and WR PLL schemes.
- No funding to develop WR PLL support in this contract.
## Clock recovery and synthesizer
[TODO
I don't know how to reconcile requests to freeze the design with well motivated but invasive requests to change the design. Let's discuss how to proceed at a programatic level at the Friday conference call.
https://github.com/sinara-hw/Sayma_RTM/issues/16#issuecomment-452661542
]
## DAC-FPGA Synchronization
Deterministic phase alignment between DACs on separate Sayma PCBs between power cycles is an important design criterion and should be considered at all stages of design. This implies a) SYSREF is aligned with RTIO clock b) DAC clocks are synchronized to local SYSREF edges.
- Follow approach demonstrated by Tom's prototype (Issue #583) using low jitter FF to retime AMC-FPGA SYNC pulse to f_dac_ref. Summarized in Issue #594.
- Follow approach demonstrated in Issue #583 and summarized in Issue #594.
- Remove HMC7043, add components needed to generate MGTREFCLK.
- Test conditions
- SAWG output on all channels on two Sayma boards, 400 MHz continuous RF
- Sayma-local TTL output at 100 MHz
- Sayma-local TTL output at 75 MHz
- using existing RTIO infrastructure and TTL PHY
- laboratory temperature stability +/- 0.5 C
- Cycle crate power 100 times
- Specification
- __ST1__: SAWG-SAWG phase alignment error across
all power cycles: < 1/f_dac_clk
- __ST2__: SAWG-TTL alignment error across all power cycles: < 0.5 ns
- __ST2__: SAWG to TTL alignment error across all power cycles: < 0.5 ns
## DAC Performance
@ -75,8 +131,9 @@ Phase stability between DACs on separate Sayma PCBs is an important design crite
- __ST4__: SAWG-TTL alignment variation < +/-250 ps
### DAC Noise
Low cross talk between adjacent analog channels on same AFE is an important design criterion and should be considered at all stages of the design (particularly layout).
- Goal: at 400 MHz < -80 dBc.
- cross talk goal: at 400 MHz < -80 dBc.
Phase noise at 400 MHz (3 dB margin on AD9154 specification):
- 10 Hz offset, < -94 dBc
@ -84,11 +141,14 @@ Phase noise at 400 MHz (3 dB margin on AD9154 specification):
- 1000 Hz offset, < -120 dBc
- 10,000 Hz offset, < -126 dBc
spurs: < -60 dBc SFDR across operating range, max amplitude
## Reduce complexity of Sayma v2
- Remove fast JESD ADCs from RTM layout
- Reduce complexity of clocking options
- Remove clock mezzanine
- User must supply RTM with DAC reference clock (f_dac) via back-panel SMA
- User must supply RTM with DAC reference clock (f_dac_ref) via back-panel SMA
- f_rtio is obtained from front-panel SMA (if master) or fiber+CDR (if satellite)
- User must ensure that the following are phase locked: f_dac_ref and f_rtio
- Synth on RTM generates f_dac from f_dac_ref
@ -111,28 +171,6 @@ Phase noise at 400 MHz (3 dB margin on AD9154 specification):
## Smart Agile Waveform Generator
Use SAWG v1 with minimal modification to demonstrate Sayma v2 hardware. SAWG v2 will be pursued once Sayma v2 hardware is working.
### SAWG v1
- f_rtio = f_dac_ref = 150 MHz
- dac data rate 0.6 GSPS
- f_dac_clk = 1.2 GHz (2X interpolation)
### SAWG v2
- ARTIQ Python interface to SAWG v2 shall not make implicit modifications to RTIO timeline.
- f_rtio = f_dac_ref = 125 MHz (same as for Kasli)
- dac data rate 1.0 GSPS
- f_dac_clk = 2.0 GHz (2X interpolation) with following expected implications:
- Carrier bandwidth (f0): 500 MHz 1st Nyquist
- Baseband bandwidth (f1, f2): +/- 75 MHz 1st Nyquist
- M-Labs Comment: “To use Sayma with 1 GHz data rate, the parameters of SAWG, the JESD core as well as the clocking setup and DAC configuration code need to be adjusted. This is likely achievable as most of the parts are designed for and were individually already tested at 1 GHz. But it's not straight-forward.”
- __action__: Software and Gateware Developer does study
- Reduce resource consumption
- comment: resource utilization at 1 GSPS may already be acceptable ([link](https://github.com/m-labs/artiq/issues/1144#issuecomment-433447687))
- comment: consider decreasing resolution of f0
- comment: resource consumption of moninj not clear #675
- comment: https://github.com/m-labs/artiq/issues/801 Jordens “imagines several opportunities to improve and simplify SAWG (different DUC scheme as suggested elsewhere, improving and shrinking the spline coefficient representation/serialization, transaction-based SAWG RTIO events which would cut down the number of RTIO channels, raw sample channels, revisiting phase and frequency resolution, study required bit depth/resource usage…”
- feature priority: 1 GSPS data rate, AM for noise eating
- __action__: Software and Gateware Developer does study
## Ethernet
- Replace MAX24287 by M88E1512. This is same family IC as KC705 which is already supported by ARTIQ.
- Configuration of M88E1512 is by static pin strapping: 1 Gbps, GMII, 1000BASE-X.
@ -140,33 +178,50 @@ Use SAWG v1 with minimal modification to demonstrate Sayma v2 hardware. SAWG v2
- Layout so that uTCA Port0 and SFP can be driven by M88E1512 or by GTH transceiver on FPGA. Use coupling capacitors to choose which.
- Also applies to Metlino.
---------------
It is anticipated that there will be three developers working together. Responsibilities and interfaces between developers are discussed in this section. UMD/ARL will serve as Technical Point of Contact (TPOC).
- Hardware Developer
- Integration and Timing Developer
- Software and Gateware Developer
------------
# Hardware Developer
The Hardware Developer is responsible for hardware design and manufacturing. Testing responsibilities of the Hardware Developer are those detailed in HT3. All deliverables include bi-weekly written progress reports. The Hardware Developer has four deliverables HT1 to HT5.
The Hardware Developer is responsible for hardware design and manufacturing. Testing responsibilities of the Hardware Developer are those detailed in HT3.
The Hardware Developer has deliverables designated HTn. Written progress reports
- on the 1st and 15th of the month
## __HT1__ high level design
High-level schematics for all PCBs to include component part numbers, high-level component interconnection, power budget, high-level layout of all PCBs including location of ICs, board-to-board headers, RF shielding, heat sinks, mechanical support and front panel design. Post design files to github and tag. Participate in design review on github.
Layout-related considerations:
- silk screen #589
- __action__: Follow Tom's suggestions to label ICs, test points (power, gnd, signals, I2C, SPI), wide pitch for slow signals, push down pull up on logic lines.
- heat sinking #592
- **action**: Follow Greg's advice and add more vias.
HT1 delivery is complete when the Software and Gateware Developer, Integration and Timing Developer and UMD/ARL sign off on the drawings.
## __HT1.5__ high level design review of interconnections
HT1.5 is a review of connections between components. It consists of the following checks.
- Are design change clearly articulated? (eg IC choice)? Confirm that schematic satisfies Sayma v2 Project Plan section Sayma v2 Diffs.
- Clocks
- GTx, Ethernet
- RTM to AMC connectivity requirements
- qty of LVDS links to AFE for future physicist needs
- Are resources sufficient for WR implementation?
- Front/rear panel connectivity
- power consumption
- Check lead time for key ICs.
- Are any BOM items near end of life?
- Check of newly created symbols in layout software. Reviewer checks all pins against schematic.
https://github.com/sinara-hw/sinara/issues/605
## __HT2__ detailed design
Detailed schematics for all PCBs, finished component interconnections, signal integrity analysis, thermal analysis, power analysis, final PCB routing. Post design files to github and tag. Participate in final design review, accept delegated responsibilities from Software and Gateware Developer Design. Output is layout ready for manufacture.
Hardware Developer shall lead HT2 design review. This design review is in collaboration with scientists and other developers. The review will not be comprehensive. It will focus on differences between v1 and v2 of the hardware. Shall include validation of FPGA pinout.
Interaction with Software and Gateware Developer:
- Hardware Developer delivers FPGA netlist(s) Software and Gateware Developer.
HT2 delivery is complete when Software and Gateware Developer and Integration and Timing Developer sign off on the drawings.
@ -185,22 +240,27 @@ Expectations for testing of all stuffed PCBs.
- https://github.com/sinara-hw/Metlino
- https://github.com/sinara-hw/BaseMod
- thermal test in TS7
- Maximum temperature of any IC 65 C
- goal: maximum temperature of any IC 65 C
- Monitor temperature of several representative ICs using MMC IPMI
- crate power-on with all boards and with arbitrary RTM unplugged in TS7
- hot swap arbitrary AMC and RTM boards in TS7
- power-on with or without RTM unplugged in TS1
- Signal integrity testing on isolated chips, acceptable bit error rate is
- use any suitable IP (eg Xilinx)
- Ethernet, 1 Gb/s
- JESD, 6 Gb/s per lane
- SDRAM
- I2C, SPI, address all ICs and transmit data at full speed
- Signal integrity testing using any suitable IP (eg Xilinx) for all ICs. Tested individually.
- Design and implement test to simulate heavy loading of a system configured as TS2. The test is expected to simultaneously exercise the following subsystems
- I2C, SPI, address all ICs round robin at full speed
- 2 TestMod installed dissipating representative power
- AD built-in DAC JESD PRBS test at 10 Gb/s lane for both DACs
- SDRAM PRBS write-then-read at [TODO ____ data rate]
- AMC backplane ethernet PRBS at 1 GSPS
- SFP loop-back PRBS at 1 Gb/s
- FMC loop-back PRBS [TODO ____ data rate]
- MMC configuration including power supply sequencing and IPMI
- Hardware Developer shall test MMC firmware on TS7 system prior to distribution.
- If errors arise after initial distribution Hardware Developer shall debug and test on TS2 system prior to distribution of the source.
- If errors arise after initial distribution Hardware Developer shall debug and test on TS2.
- Publish MCH configuration configuration file used for these tests with TS-MTCA and NATIVE-R5.
Distribute hardware to system integrators:
- Software and Gateware Developer: 2 AMC, 2 RTM, 4 AFE, 1 Metlino
- Integration and Timing Developer: 2 AMC, 2 RTM, 4 AFE, 1 Metlino
@ -211,7 +271,7 @@ HT3 delivery is complete when the Software and Gateware Developer and Integratio
## __HT4__ documentation and MMC
- Support system integrators by github Issue system.
- Develop and document fixes for hardware bugs.
- If bug fixes are substantial (eg replacing multi-pin SMD), system integrators may at their option return boards to The Hardware Developer for repair. System integrator pays shipping inbound, The Hardware Developer pays shipping outbound.
- If bug fixes are substantial (eg replacing multi-pin SMD), system integrators may at their option return boards to the Hardware Developer for repair. System integrator pays shipping inbound, Hardware Developer pays shipping outbound.
- Each board should have a serial number, and a wiki page where everyone who reworks the board has to document what they did. Other notes about that particular board and its specific bugs can be added there.
- MMC and Exar configuration
- Publish source on github within sinara-hw domain.
@ -233,8 +293,7 @@ Build demonstration system that is fully assembled and tested. The system shall
- 1 Metlino serving as ARTIQ Master
- 2 Sayma v2 (AMC + RTM)
- 4 BaseMod v2
- Test jigs, clock hardware, documentation and ARTIQ Python code needed to demonstrate the following:
- Passage of SAWG-tests written by TPOC; hosted on hithub https://github.com/jbqubit/sinara-testing/tree/master/sayma/repository/sawg-tests
- Test jigs, clock hardware, documentation and ARTIQ Python code needed to demonstrate the following:
- ST1, ST2, ST3 and ST4
- Ship demonstration system to UMD.
- UMD/ARL will return TS-MTCA and clock hardware to the Hardware Developer 1 month after delivery. All other parts will remain property of UMD.
@ -247,23 +306,58 @@ HT5 delivery is complete when UMD confirms receipt of the demonstration system /
# Integration and Timing Developer
An Integration and Timing Developer is responsible for hardware integration and testing. This developer has one deliverable OT1. Bi-weekly written progress reports.
An Integration and Timing Developer is responsible for certain aspects of hardware integration and testing as detailed in this section.
This developer has one deliverable OT1. Written progress reports
- on the 1st and 15th of the month
## __OT1__ integration and timing
- __O11__ implement DAC-FPGA synchronization with 2 GHz DAC clock (1 GSPS data rate).
- __O12__ participate in HT1 design review
- __O13__ participate in HT2 design review
- __O14__ Based on O11, demonstrate ST4 for a pair of AD9154 DACs on a single Sayma v2 board
in configuration TS1.
- Write and document code. Generate pull request.
- Re-test the ARTIQ-integrated version of the code and debug any issues that arise.
- Dependency: Software and Gateware Developer is responsible for supplying AD9154 support at the level of M25 and M32. Integration and Timing Developer will handle debugging of ADF4356 and AD9154 as relates to ST4.
- __O17__ in support of a future clock distribution scheme modeled after White Rabbit, specify layout of Si549 and related components
- __O18__ write and test ADF4356 driver
OT1 delivery is complete when the Integration and Timing Developer completes and documents all tests O11 to O18.
Dependency: Software and Gateware Developer is responsible for supplying AD9154 support at the level of M25 and M32. Integration and Timing Developer will handle debugging of ADF4356 and AD9154 as relates to ST4.
Code submitted for inclusion in ARTIQ shall comply with CONTRIBUTING.rst (https://github.com/m-labs/artiq/blob/master/CONTRIBUTING.rst).
- __O11__ implement DAC-FPGA synchronization with 2 GHz DAC clock (1 GSPS data rate).
- __O12__ participate in HT1 and HT1.5 design reviews
- __O13__ participate in HT2 design review
- __O14__ Based on O11, demonstrate ST4 for a pair of AD9154 DACs on a single Sayma v2 board in configuration TS1.
- Write and document code. Generate pull request.
- __O15__ write and test ADF4356 driver
- Write and document code. Generate pull request.
- __O16__ in support of a future clock distribution scheme modeled after White Rabbit (WR), specify layout of Si549 and related components
[TODO: How to support this if at all? - Write and document code. Generate pull request.]
OT1 delivery is complete when the Integration and Timing Developer completes and documents tasks O11 to O16.
# Software and Gateware Developer
The Software and Gateware Developer is responsible for gateware and software needed to provide ARTIQ support and to implement SAWG. All software and gateware development items include:
- Test benches or unit tests for gateware and software
- Examples for runtime and kernel APIs
@ -271,43 +365,128 @@ The Software and Gateware Developer is responsible for gateware and software nee
- Documentation of design choices
- Documentation of code functionality
The developer’s work consists of three deliverables MT1 to MT3. An asterisk(*) indicates previously funded work. All deliverables include bi-weekly written progress reports.
All MTk items include support of code in ARTIQ for 3 years from start of contract including documentation of public APIs, maintenance of developed CI infrastructure, publication of CI results.
## __MT1__ Sayma v2 Planning
- __M11__ linear ramp problem on Sayma v1
- __M12__ design study to support 1 GSPS data rate on Sayma v2 (SAWG v1)
- __M13__ design study to investigate SAWG v2 (eg limit f_f0 resolution, reduce RTIO channel number, Moninj)
- __M14__ design study to explore reduced resource consumption options in SAWG v2
- __M15__ participate in HT1 design review
- __M17__ participate in HT2 design review
- __M17__ Replace serwb with pure DRTIO.
- __RTM DRTIO__ -- already funded, can be prototyped on Sayma v1 or Kasli
- __distributed DMA__ -- already funded, can be prototyped on Sayma v1 or Kasli
The developer’s work consists of deliverables MTk below. Written progress reports are due
- on 1st and 15th of the month
- on 1st of the month after OT1 and HT5 are complete
## __MT2__ Sayma v2 ARTIQ Support
- __M21__ code review and trouble shooting in support of OT1
- __M22__ update clock tree and do code review for O14
- __M23__ implement, test and document ST1 and ST2 which depend on DRTIO; add to continuous integration
- __M24__ test AFE BaseMod v2 (excluding ADC)
- __M25__ responsible for testing SAWG v1 on Sayma v2
- __M26__ support Hardware Developer’s work on HT5
- __M27__ write ARTIQ-based Sayma v2 test bench to validate for continuous integration and document so it can be reproduced by Hardware Developer.
- __M28__ extend RTIO support to FPGA on RTM
## __MT1__ SAWG
MT1 is a port of SAWG v1.0 designed for Sayma v1 to Sayma v2. Additional improvements in SAWG are also specified. The improvements include consideration of future modulation by RTIO and by Modulation by local DSP.
Each MTk includes a short report and option to implement.
- __M11__ Support SAWG v2.0
- Develop code for Sayma v2 SAWG+JESD+fpga clock tree at 1 GSPS.
- Implement new Sayma v2 sysref synchronization scheme.
- __M12__ SAWG v2.1 element: Measure resource usage and limit number of channels if unable to fit.
- __M13__ SAWG v2.1 element: Evaluate clocking SAWG or parts of it at 250 MHz (2x f_rtio)
- __M14__ SAWG v2.1 element: Determine number of CORDIC stages, width, phase resolution to achieve a specified spur suppression under specified conditions
- __M15__ SAWG v2.1 element: Design transaction based SAWG RTIO protocol (rewrite protocol to stage interpolator settings over one or few non-concurrent RTIO output channels, then activate synchronously with a single RTIO output event). Discuss and determine data partitioning among interpolators and SAWG channels.
- __M16__ SAWG v2.1 element: Design fractional representation of high-order spline interpolator coefficients (i.e. instead of 64 bits, just 16 denominator + 16 numerator bits for the 3rd order spline coefficient). This also allows getting rid of the SAWG clock stretcher that was never officially supported.
- __M17__ SAWG v2.1 element: Evaluate SAWG DUC redesign with 3 or 4 bit frequency and phase resolution based on multipliers instead of parallel cordics.
- __M18__ SAWG v2.1 element: Evaluate resource consumption of modulation ports for after spline interpolators.
- Multiplicative for amplitude, additive and saturating for frequency and phase.
- No support for configurable clipping amplitude at modulation summing junctions. Clipping is always on.
## __MT2__ Sayma v2 Planning
- __M21__ Develop fixed test pattern generator (4-point sine on odd channels and ramps with major carry toggles on even channels) as a compile time alternative to SAWG.
- __MT22__ Review and verify Sayma v2 design from the FPGA perspective. Do this by building a stub ARTIQ target and test compilation -- depends on obtaining netlist for FPGAs from Hardware Developer (HT2). This will verify IO assignments and usage patterns around the following subsystems
- ethernet
- transceivers
- clocking
- SDRAM
- flash
- RTM interface
- AFE ports
- FMC ports
- __MT23__ Review of the scheme for synchronization between pairs of Sayma boards.
## __MT3__ Sayma v2 ARTIQ Support
- __M31__ Review the code emerging from O14 and O15. Support merge into ARTIQ. Aspects included in review: DRTIO-on-RTM, DRTIO clock
recovery on RTM, JESD204B deterministic latency/synchronization.
[TODO: does this include DDMTD?]
- __M32__ Work with TPOC to develop test cases for SAWG v2.1 with ST1 and ST2 in mind. Split into manual test cases and tests amendable to continuous integration (CI). Procure hardware needed for hardware-in-the-loop tests.
- __M33__ Support for Sayma_AMC to include the following
- power up
- boot tasks including JTAG, loading flash & FPGA
- UARTs
- SDRAM
- ethernet
- I2C EEPROM (MAC address and board serial numbers)
- clocking (including DRTIO clock recovery)
- RTIO transcievers
- RTIO SERDES TTL
- FMC connectors
[- TODO anything missing?]
- build infrastructure and packaging
- __M34__ Support for Sayma_RTM to include the following
- power up
- boot tasks including JTAG (slave serial) loading of flash & FPGA
- RTM clocking
- develop DRTIO for AMC FPGA to RTM FPGA link
- SPI to HMC830 and AD9154
- AFE interfaces
- build infrastructure and packaging
[- TODO anything missing?]
- dependency: M33
- __M35__ Support for BaseMod to include the following
- attenuator shift register
- DRTIO control of RF switches using TTL PHY
- dependency: M34
- __M36__ Validate RF output using SAWG v1.0. This tests operation of SAWG as developed for Sayma v1 works on Sayma v2. It tests the following elements.
- clocking of AD9154
- SYSREF syncing of DAC and JESD core
- JESD204B to AD9154
- SAWG v1.0 integration
- dependency: M34
- __M37__ SAWG v2.0
- ensure passage of tests ST1, ST2 and ST4
- Double check ST3 using code supplied under task O14
- dependencies: M36, O14
- __M38__ SAWG v2.1
- ensure proper implementation of features in SAWG v2.1
- confirm that ST1, ST2, ST3 and ST4 tests still pass
- dependency: M37
- __M39__ Documentation
- integrate manual and automated CI tests into ARTIQ infrastructure
- document manual and automated CI tests, hardware-in-the-loop infrastructure
- document CI infrastructure and how to run CI tests
- support Hardware Developer and TPOC in reproducing CI tests
- document Sayma v2 ARTIQ support
- SAWG v2.1 ARTIQ Python API
- document underlying DSP architecture
## __MT3__ Sayma v2 Extension and Other
- __M31__ support code developed in __O18__
- __M32__ build and test SAWG v2 assuming features are 1 GSPS data rate, AM for noise eating
- __M34__ removed
- __M35__ removed
- __M36__ build infrastructure
- Support build for bitstream building for Sayma v1 and SAWG v1 until 6 months after HT3 delivery.
- Support for bitstream building for SAWG v1 on Sayma v2 until 6 months after SAWG v2 delivery.
- Support for bitstream building of SAWG v2 for Sayma v2 for 3 years after SAWG v2 delivery.
----------
# Project Organization
ARL/UMD will fund and manage contracts with @jbqubit serving as technical point of contact (TPOC). In the event of a dispute about interpretation of a contract or about contract execution, the TPOC will have project-level decision making. Note that the legal language in the officially executed contract documents has final authority.
ARL/UMD will fund and manage contracts with @jbqubit serving as technical point of contact (TPOC).
New github repositories were setup for each component of the Sayma system.
- https://github.com/sinara-hw/Sayma_AMC
@ -315,10 +494,20 @@ New github repositories were setup for each component of the Sayma system.
- https://github.com/sinara-hw/Metlino
- https://github.com/sinara-hw/BaseMod
Github Issue tracking will be the authoritative location for test results and bugs. Keep discussion via other channels (email, IRC) to a minimum but when it happens post a summary to the relevant github Issue. Link back to the old sinara-hw/sinara Issues as needed but don’t conduct new discussions in sinara-hw/sinara.
Use github Issue tracking for test results and bug tracking. Link back to the old sinara-hw/sinara Issues as needed but don’t conduct new discussions in sinara-hw/sinara.
Weekly discussions via google hangout during period of performance. Attendance of at least one team member for each collaborator is expected. Discussion limited to 30 minutes per week. Software and Gateware Developer, Hardware Developer and Integration and Timing Developer. UMD/ARL involvement if requested by MC. Responsibilities:
- Strict cycling of responsibilities between teams for each week
- Master of ceremonies (MC): publishes meeting agenda at least 4 hours prior to meeting start, enforces time limits, schedules next weekly meeting (advertised in UTC)
- Clerk: takes meeting minutes, posts to github
Weekly discussions via google hangout during period of performance. Attendance of at least one team member for each Developer team is expected. Discussion limited to 30 minutes per week. UMD/ARL involvement if requested by MC.
Master of Ceremonies (MC) expectations:
- Solicit agenda items from group. Select agenda topics that can be completed in 30 minutes.
- Regulate discussion so that planned agenda items are covered. For technical matters that prove contentious or detailed, shift discussion to github Issue.
- Publish agenda > 4 hours prior to meeting start.
- Launch google hangout > 5 minutes in advance of meeting start.
- Schedule next meeting time using doodle; advertise meeting time in UTC
- Each week rotate responsibilities for MC and minutes-taking between Developers and UMD/ARL
Agenda items must include:
- vote on acceptance of last meeting's minutes
- designate next meeting's MC
- designate next meeting minutes-taker
- ask participants to reflect on how the meeting went and what to do better next week