1
0
Fork 0

Compare commits

..

34 Commits

Author SHA1 Message Date
mwojcik 250d759f05 mirny: fix wrong json template 2024-07-18 17:13:43 +08:00
Egor Savkin adf516d310 Small fix
Signed-off-by: Egor Savkin <es@m-labs.hk>
2024-07-18 14:44:59 +08:00
Simon Renblad c45105e56b fastino: add log2_width param 2024-07-17 13:39:31 +08:00
Egor Savkin 2e14232474 Add IP collision case
Signed-off-by: Egor Savkin <es@m-labs.hk>
2024-07-12 17:31:59 +08:00
mwojcik d71bc3a57e update artiq-6 instructions 2024-07-02 11:24:03 +08:00
Egor Savkin 01d479eba3 No CIDR on kasli-soc
Signed-off-by: Egor Savkin <es@m-labs.hk>
2024-06-27 15:27:07 +08:00
Egor Savkin 579749d114 Add mask to IPs
Signed-off-by: Egor Savkin <es@m-labs.hk>
2024-06-27 11:26:49 +08:00
Egor Savkin d8ba6b94ae Remarks on dialout group
Signed-off-by: Egor Savkin <es@m-labs.hk>
2024-06-27 11:15:23 +08:00
Egor Savkin 22222ebdbf To allow impurity add more impurity in nix configuration
Signed-off-by: Egor Savkin <es@m-labs.hk>
2024-06-26 13:12:22 +08:00
Egor Savkin 6d46ed7150 Slight meaning fix
Signed-off-by: Egor Savkin <es@m-labs.hk>
2024-06-20 17:16:35 +08:00
Egor Savkin d44be3dd8e Minor fixes in AFWS
Signed-off-by: Egor Savkin <es@m-labs.hk>
2024-06-20 16:56:35 +08:00
Egor Savkin 9a216f3d51 Add afws instructions
Signed-off-by: Egor Savkin <es@m-labs.hk>
2024-06-20 16:37:27 +08:00
mwojcik 2777676057 stabilizer: how to clear usb settings 2024-06-20 13:21:57 +08:00
Egor Savkin ea1b0b5c56 Avoid over-relience on nix build for building docs
Signed-off-by: Egor Savkin <es@m-labs.hk>
2024-06-18 15:31:09 +08:00
Egor Savkin 49de48aa32 Fix link to git docs
Signed-off-by: Egor Savkin <es@m-labs.hk>
2024-06-17 15:51:52 +08:00
Egor Savkin 98632d7c31 Add setup for building the firmware instructions
Signed-off-by: Egor Savkin <es@m-labs.hk>
2024-06-17 11:59:46 +08:00
Egor Savkin 47d46b7bbd Remove longer way of using git checkout
Signed-off-by: Egor Savkin <es@m-labs.hk>
2024-06-17 10:30:07 +08:00
linuswck 8d1432488f Add assembly instructions for Shuttler (#13)
Add assembly instructions for Shuttler

Reviewed-on: sinara-hw/assembly#13
Co-authored-by: linuswck <linuswck@m-labs.hk>
Co-committed-by: linuswck <linuswck@m-labs.hk>
2024-06-14 17:18:11 +08:00
Egor Savkin cb048ac4aa Update build instructions for new release-8
Signed-off-by: Egor Savkin <es@m-labs.hk>
2024-06-14 17:13:21 +08:00
mwojcik 89173e4f2e mirny: remove binaries, link to hydra 2024-06-14 17:06:59 +08:00
mwojcik df881461e8 mirny: add legacy almazny firmware 2024-06-11 13:51:48 +08:00
mwojcik 5c48363c54 stabilizer - use Hydra builds, remove mentions of the old version 2024-06-07 10:01:52 +08:00
mwojcik 6bdd0b61ac mirny: add firmware 2024-06-05 10:26:59 +08:00
mwojcik 440f687bac clarify Xilinx path, flake 2024-06-04 16:25:36 +08:00
Egor Savkin 1c15fd3941 Fix almazny tip after driver fix
Signed-off-by: Egor Savkin <es@m-labs.hk>
2024-06-03 11:01:17 +08:00
Egor Savkin c1b1af0b0e Add inclusivity/accessibility/user-friendliness tip into `Contributing`
Signed-off-by: Egor Savkin <es@m-labs.hk>
2024-05-16 13:04:05 +08:00
Egor Savkin 32567574fc Overheating issues for DRTIO
Signed-off-by: Egor Savkin <es@m-labs.hk>
2024-04-30 10:35:21 +08:00
mwojcik 68e2015f3a fastino: what to do if output is 10V 2024-04-19 15:21:21 +08:00
mwojcik 27e552f09b stabilizer: add building and flashing instructions 2024-04-17 15:04:50 +08:00
Egor Savkin 5659f5b60a Add a bit more details for the fastino's no gateware issue
Signed-off-by: Egor Savkin <es@m-labs.hk>
2024-03-26 14:47:40 +08:00
Egor Savkin b948ce96de Add artiq start page
Signed-off-by: Egor Savkin <es@m-labs.hk>
2024-03-19 15:51:59 +08:00
Egor Savkin 387e2f85e4 Update hardware instructions to better match real testing processes
Signed-off-by: Egor Savkin <es@m-labs.hk>
2024-03-19 15:02:07 +08:00
morgan 9323039e6a lvds: add DIP switch jpg 2024-02-20 17:23:40 +08:00
morgan 0952e36a84 lvds: expand testing methodology 2024-02-20 17:23:17 +08:00
27 changed files with 723 additions and 79 deletions

View File

@ -2,7 +2,7 @@
Repository with instructions and remarks on assembling and testing Sinara hardware
### Build docs
## Build docs
```shell
nix build
@ -17,7 +17,19 @@ nix develop
mdbook build
```
The output files are in `book` directory.
The output files will be in `book` directory.
### Alternative way
Since the docs builder depends only on mdBook, you may get it from anywhere you like - `nix-shell -p mdbook`,
`snap install mdbook`, `cargo install mdbook` or any other from your OS.
After that you will be able to do:
```shell
mdbook build
```
The output files will be in `book` directory.
## Contributing
@ -33,7 +45,9 @@ Tips for adding hardware instructions:
for images with transparent background)
3. Add link to the new chapter to the `src/SUMMARY.md`
4. Do not forget to tell about all hidden/non-obvious obstacles and pitfalls
5. Add testing steps, even the "obvious" ones
6. Add JSON sample if needed
7. Add hardware setup (e.g. pins, switches) steps if needed
8. View changed and added pages with `mdbook build` (see building instructions above)
5. Avoid using uncommon, complex, or hard-to-understand words, phrases, or grammar (e.g., ❌constituent -> ✔component).
Keep in mind that these guides may be used by people with different backgrounds and levels of English proficiency.
6. Add testing steps, even the "obvious" ones
7. Add JSON sample if needed
8. Add hardware setup (e.g. pins, switches) steps if needed
9. View changed and added pages with `mdbook build` (see building instructions above)

View File

@ -2,16 +2,16 @@
"nodes": {
"nixpkgs": {
"locked": {
"lastModified": 1697851979,
"narHash": "sha256-lJ8k4qkkwdvi+t/Xc6Fn74kUuobpu9ynPGxNZR6OwoA=",
"lastModified": 1710695816,
"narHash": "sha256-3Eh7fhEID17pv9ZxrPwCLfqXnYP006RKzSs0JptsN84=",
"owner": "NixOS",
"repo": "nixpkgs",
"rev": "5550a85a087c04ddcace7f892b0bdc9d8bb080c8",
"rev": "614b4613980a522ba49f0d194531beddbb7220d3",
"type": "github"
},
"original": {
"owner": "NixOS",
"ref": "nixos-23.05",
"ref": "nixos-23.11",
"repo": "nixpkgs",
"type": "github"
}

View File

@ -1,7 +1,7 @@
{
description = "Sinara assembly and test instructions";
inputs.nixpkgs.url = github:NixOS/nixpkgs/nixos-23.05;
inputs.nixpkgs.url = github:NixOS/nixpkgs/nixos-23.11;
outputs = { self, nixpkgs }:

View File

@ -10,6 +10,7 @@
- [Sinara 2118 BNC-TTL / 2128 SMA-TTL](./hw/bnc_sma_ttl.md)
- [Sinara 2138 MCX-TTL](./hw/mcx_ttl.md)
- [Sinara 5432 DAC Zotino / Sinara 5632 DAC Fastino](./hw/zotino_fastino.md)
- [Sinara 5716 DAC Shuttler](./hw/shuttler.md)
- [Sinara 5518 BNC-IDC / 5528 SMA-IDC adapter](./hw/bnc_sma_idc_adapter.md)
- [Sinara 4410/4412 DDS Urukul (AD9910/AD9912)](./hw/urukul.md)
- [Sinara 5108 Sampler](./hw/sampler.md)
@ -20,6 +21,7 @@
- [Sinara 8451 Thermostat](./hw/thermostat.md)
- [Sinara 2245 LVDS DIO](./hw/lvds_dio.md)
- [Software/Support](./sw_sup/software_support.md)
- [Starting with ARTIQ](./sw_sup/artiq_start.md)
- [Building legacy firmware](./sw_sup/artiq_legacy.md)
- [Networking](./sw_sup/networking.md)
- [DRTIO](./sw_sup/drtio.md)
@ -28,3 +30,5 @@
- [Moninj](./sw_sup/moninj.md)
- [Clocking](sw_sup/clocking.md)
- [device_db.py](sw_sup/device_db.md)
- [Setup your PC for building ARTIQ firmware](sw_sup/setup_build_pc.md)
- [AFWS client](sw_sup/afws_client.md)

View File

@ -39,13 +39,15 @@ Failure to comply with this voids the warranty.
```shell
mkdir <variant>
cd <variant>/
nix develop github:m-labs/artiq\?ref=release-7
nix develop github:m-labs/artiq\?ref=release-8#boards
# master/standalone only
artiq_mkfs -s ip 192.168.1.75 kasli.config
artiq_mkfs -s ip 192.168.1.75/24 kasli.config
artiq_flash storage -f kasli.config
artiq_ddb_template -o device_db.py <variant>.json
python -m artiq.gateware.targets.kasli_generic <variant>.json
python -m artiq.gateware.targets.kasli <variant>.json
artiq_flash --srcbuild -d artiq_kasli/<variant>/
artiq_rtiomap dev_map.bin
artiq_coremgmt config write -f device_map dev_map.bin
```
## Kasli-SoC (zynq)
@ -65,15 +67,18 @@ artiq_flash --srcbuild -d artiq_kasli/<variant>/
```shell
mkdir <variant>
cd <variant>/
nix develop git+https://git.m-labs.hk/m-labs/artiq-zynq\?ref=release-7
nix develop git+https://git.m-labs.hk/m-labs/artiq-zynq\?ref=release-8
artiq_ddb_template -o device_db.py <variant>.json
nix build -L --impure --expr 'let fl = builtins.getFlake "git+https://git.m-labs.hk/m-labs/artiq-zynq?ref=release-7"; in (fl.makeArtiqZynqPackage {target="kasli_soc"; variant="[master, standalone, satellite]"; json=<full path to the json description>;}).kasli_soc-[master, standalone, satellite]-sd'
nix build -L --impure --expr 'let fl = builtins.getFlake "git+https://git.m-labs.hk/m-labs/artiq-zynq?ref=release-8"; in (fl.makeArtiqZynqPackage {target="kasli_soc"; variant="[master, standalone, satellite]"; json=<full path to the json description>;}).kasli_soc-[master, standalone, satellite]-sd'
# copy `results/boot.bin` to the SD card
# insert SD card to the Kasli-SoC and boot
artiq_coremgmt -D 192.168.1.56 config write -s ip 192.168.1.75 # or just place extra/CONFIG.TXT near the boot.bin on SD card
# update firmware (alternative to copy to SD, if ARTIQ already running)
artiq_coremgmt config write -f boot result/boot.bin
artiq_coremgmt reboot
# reboot via power supply
artiq_rtiomap dev_map.bin
artiq_coremgmt config write -f device_map dev_map.bin
```
## Testing (common)

View File

@ -13,8 +13,8 @@
"hw_rev": "vX.Y", // optional
"ports": [<port num>],
"edge_counter": <bool>,
"bank_direction_low": "input",
"bank_direction_high": "output"
"bank_direction_low": "input", // or "output"
"bank_direction_high": "output" // or "input"
}
```

View File

@ -4,20 +4,11 @@
## JSON
Put the `ext_ref_frequency` field into the JSON description if the Kasli is going to use an external frequency:
Not present in the JSON.
```json
{
"hw_rev": "<hw rev>",
"base": "<base>",
...
"ext_ref_frequency": <freq in Hz>,
...
"peripherals": [...]
}
```
On peripherals you should choose `"clk_sel": 2` on connected devices.
Peripherals typically should choose `"clk_sel": 2` for MMCX connection and `"clk_sel": 1` for external SMA connection.
Refer to the [official docs](https://m-labs.hk/artiq/manual/core_drivers_reference.html) by searching for `clk_sel`.
You may also need to add `"refclk": <number>` field to the target card.
## Setup external clocker
@ -41,12 +32,12 @@ Here is example setup for SynthNV RF signal generator:
1. Switch `CLK SEL` pin to `EXT`/`INT` according to customer needs
2. Connect MMCx cables according to the customer needs and boards specifications (see image below for reference):
if the `INT` source is chosen, connect MMCx cable to `INT CLK`, otherwise connect external clocker to SMA `EXT CLK`
3. Connect the Clocker to the Kasli via 30-pin ports
3. Connect the Clocker to the Kasli via 30-pin ports, or via external power supply
![](../img/clocker_ref.jpg)
4. Connect the Clocker's SMA output to the Kasli's `CLK`/`CLK IN` SMA pin
5. After assembling the crates and flashing the firmware, start Kasli and write config as follows:
5. After assembling the crates and flashing the firmware, start Kasli and set config if needed:
`artiq_coremgmt config write -s rtio_clock ext0_bypass`. Please refer to the [official manual](https://m-labs.hk/artiq/manual/installing.html#miscellaneous-configuration-of-the-core-device)
for the details and available options
for the details and available options. In most cases you may skip this step.
6. Reboot either via `artiq_coremgmt reboot` or via power supply if the board's firmware doesn't have such command
## Testing

View File

@ -31,8 +31,49 @@ Be aware of the reversed EEM order on the card:
Switch DIPs in required position per each channel individually. Each RJ45 have 4 channels.
![](../img/lvds_ttl_switches.jpg)
## Testing
You can test channels by connecting Ethernet RJ45 cable. Since the artiq_sinara_tester allows to choose only one DIO
port, you will need to run the test 4 times and choose different output source and track that every 4th is passing the test.
It is also incompatible with other TTL cards, so you will need to use same or other LVDS card for proper testing.
```bash
*** Testing TTL inputs.
TTL device to use as stimulus (default: ttl0): ttl0
Connect ttl0 to ttl4. Press ENTER when done.
PASSED # <--------
Connect ttl0 to ttl5. Press ENTER when done.
FAILED
Connect ttl0 to ttl6. Press ENTER when done.
FAILED
Connect ttl0 to ttl7. Press ENTER when done.
FAILED
...
*** Testing TTL inputs.
TTL device to use as stimulus (default: ttl0): ttl1
Connect ttl1 to ttl4. Press ENTER when done.
FAILED
Connect ttl1 to ttl5. Press ENTER when done.
PASSED # <--------
Connect ttl1 to ttl6. Press ENTER when done.
FAILED
Connect ttl1 to ttl7. Press ENTER when done.
FAILED
...
```
1. Connect a RJ45 output port to a input port
2. Run `artiq_sinara_tester`
3. One TTL will pass while other will fail
4. Run `artiq_sinara_tester` again and increment the stimulus (e.g. `ttl0->ttl1->ttl2->ttl3`) until all channels on the input port passed at least once
5. Plug into to another input port and repeat 2-4 until all input ports are tested
It is incompatible with other TTL cards, so you will need to use same or other LVDS card for proper testing.

View File

@ -9,10 +9,66 @@
{
"type": "mirny",
"almazny": true, // for mirny with almazny only
"ports": [<port num>]
"almazny_hw_rev": "v1.2", // optional, must be provided for legacy (<=v1.1) Almazny
"ports": [<port num>],
"clk_sel": "mmcx", // optional
"refclk": 125e6 // optional
}
```
## Getting the firmware
On Hydra you can find [Mirny 0.3.1 firmware](https://nixbld.m-labs.hk/job/artiq/gluelogic/mirny-cpld-almazny). It contains a single ``.jed`` file that can be flashed following [flashing instructions](#flashing). This firmware supports Almazny v1.2+.
If you are using a legacy Almazny (v1.0-1.1), due to different signals routed, you need to flash the older [0.2.4 firmware with Almazny support](https://nixbld.m-labs.hk/job/artiq/gluelogic/mirny-cpld-legacy-almazny).
### Building firmware (optional)
However, if you need to make chances or build from source, follow these instructions.
Once you get your hands on the firmware source code, you will need to work around few shortcomings of Nix, mainly not being able to run dynamically linked executables.
You will need:
- Xilinx ISE 14.7 installed on your system (this guide is assuming ``/opt/Xilinx`` path),
- an environment with Migen.
One way to do it is to create an FHS environment, like ARTIQ does for Vivado, within ARTIQ's ``flake.nix`` (to leverage Migen already being there), by adding these lines:
```
iseEnv = pkgs.buildFHSEnv {
name = "ise-env";
targetPkgs = vivadoDeps;
};
ise = pkgs.buildFHSEnv {
name = "ise";
targetPkgs = vivadoDeps;
profile = "set -e; source /opt/Xilinx/14.7/ISE_DS/settings64.sh";
runScript = "ise";
};
```
Add them below ``vivadoEnv``. Then add ``iseEnv`` and ``ise`` to the dev shell's build inputs. Call ``nix develop`` on that.
Then you can build Mirny:
```shell
nix develop
ise-env
cd ../mirny # or wherever your source is at
source /opt/Xilinx/14.7/ISE_DS/settings64.sh
python mirny_impl.py
```
### Flashing
For flashing, you will need Xilinx ISE 14.7 installed on your system (here assuming ``/opt/Xilinx`` path), and ``xc3sprog`` with the appropriate HS2 JTAG adapter.
```shell
nix-shell -p xc3sprog
xc3sprog -c jtaghs2 -m /opt/Xilinx/14.7/ISE_DS/ISE/xbr/data -v build/mirny.jed
```
## Testing
### Without Almazny
@ -37,8 +93,8 @@ mirny0_ch3 info: {'f_outA': 1300000000.0, 'f_outB': 10400000000, 'output_divider
After running `artiq_sinara_test`:
1. Install gqrx `nix-shell -p gqrx`
2. Connect bladeRF via USB cable only
3. Run gqrx and choose `BladeRF #<number>...`
2. Connect HackRF One via USB cable only
3. Run gqrx and choose `HackRF HackRF One...`
4. Default settings
5. When gqrx loaded, start DSP processing with frequency at mirnyN_chM freq
6. Connect the probe through attenuator to the Mirny's port
@ -47,7 +103,7 @@ After running `artiq_sinara_test`:
![](../img/mirny_gqrx.png)
### With Almazny
### With Almazny (ARTIQ 7)
At first, `artiq_sinara_test` will prompt you for testing Mirnies as the would be without Almazny.
After that, it will prompt you with testing the Almazny:
@ -95,4 +151,8 @@ You should also see differences in various modes, but that may require disabling
### Tips
Mirnies often fail `ValueError: MUXOUT not high`, in that case restart the tests or reboot the board(s).
~~Mirnies often fail `ValueError: MUXOUT not high`, in that case restart the tests or reboot the board(s).~~ - fixed in [9569cfb](https://github.com/m-labs/artiq/commit/9569cfb26329c0acdc1705d3256d2506b7bccce5)
For Almazny v1.0 and 1.1 support, CPLD firmware 0.2.4 (linked above) must be flashed onto Mirny.
For Almazny v1.2+ support, CPLD firmware 0.3.1+ (with fixes) must be flashed onto Mirny.

View File

@ -25,9 +25,9 @@ phaser0 10+0 10+1 10+2 10+3 10+4 MHz
### Upconverter
1. Install gqrx `nix-shell -p gqrx`
2. Connect bladeRF via USB cable only
3. Run gqrx and choose `Nuand bladeRF SN <number>...`
4. Input rate 20000000, other settings are default
2. Connect HackRF One via USB cable only
3. Run gqrx and choose `HackRF HackRF One...`
4. Default settings
5. Lower the gain in `Input options`
6. When gqrx loaded, start DSP processing with frequency near 2.875 GHz +- DUC frequencies from `artiq_sinara_test`
in `Receiver Options`
@ -39,11 +39,7 @@ phaser0 10+0 10+1 10+2 10+3 10+4 MHz
### Baseband
1. Install gqrx `nix-shell -p gqrx`
2. Connect bladeRF via USB cable only
3. Run gqrx and choose `Nuand bladeRF SN <number>...`
4. Input rate 15000000, other settings are default
5. When gqrx loaded, start DSP processing with frequency near 2.875 GHz (???)
6. Connect the probe through attenuator to the Phaser's ports RF0 or RF1 (not the ADC)
7. You should see 5 tones on `artiq_sinara_test`'s frequencies (???):
![phaser_baseband.png](../img/phaser_baseband.png)
1. Connect the probe through attenuator to the Phaser's ports RF0 or RF1 (not the ADC)
2. Find FTT (Fourier Transform) function in the oscilloscope
3. Start processing with frequency near DUC frequencies from `artiq_sinara_test`
4. You should see 5 tones on `artiq_sinara_test`'s frequencies

View File

@ -33,3 +33,4 @@ PASSED
1. Apply 1.5V (connect the AA-battery) to the `samplerX`'s requested channel
2. Press `Enter`, the `artiq_sinara_test` should output `PASSED`
3. Repeat steps 1-2 for every available channel.
4. Disassemble AA-battery tool as it risks getting corrosion

120
src/hw/shuttler.md Normal file
View File

@ -0,0 +1,120 @@
# Sinara 5716 DAC Shuttler
The Sinara 5716 DAC Shuttler consists of the [Shuttler](https://github.com/sinara-hw/Shuttler), [Remote AFE-Board](https://github.com/sinara-hw/Shuttler), and [EEM FMC Carrier](https://github.com/sinara-hw/EEM_FMC_Carrier) (EFC) Board.
The EFC Board has an FPGA running Kasli Satellite. DRTIO communication is established through the EEM Cable. At first power up, EFC Board and connected Kasli/Kasli-soc calibrate the clock skews on their own EEM transceiver and then store the value into the flash memory/SD Card.
## JSON
```json
{
"type": "shuttler",
"ports": [<port num>]
}
```
## Hardware Configurations and Connections
### EEM Cable Connection
Only the EEM0 port on the EFC board is used. The EEM Cable provides power. You can ignore the barrel jack at the back of the board if it is placed.
### CLK Input
The EFC requires a **common** clock source with the connected device.
For the EFC Board v1.0, please refer to this [issue](https://github.com/sinara-hw/EEM_FMC_Carrier/issues/44).
For the EFC Board v1.1 (or later), there is a DIP switch to select the clock source.
![efc_clk_sel](../img/efc_clk_sel.png)
| Clock Source | CLK_SEL0 | CLK_SEL1 |
|---|---|---|
| Front Panel SMA | 0 | 0 |
| Internal Oscillator(default) | 1 | 0 |
| MMCX | 0 | 1 |
| PE CLK | 1 | 1 |
### VADJ Power
The EFC Board has configurable Digital IO Voltage Level/PSU called VADJ. You should configure VADJ to 1.8V by fitting W1/W2 jumper accordingly.
![efc_vadj_settings](../img/efc_vadj_settings.jpg)
### Remote AFE Board Connections
The Remote AFE Board is not installed in the crate and should be shipped separately. When you test the EFC Board, please connect the Mini SAS Cables in this orientation.
![Mini-Sas Connections](../img/shuttler_afe_connections.jpg)
There is no PSU for the Remote AFE Board at this moment. For testing purposes, you should connect the Remote AFE Board to a lab PSU supplying +15V, -15V, and +5V. Please make sure all voltages share a common GND and check the pinouts carefully. Incorrect power connections can damage the Remote AFE Board.
## Building EFC Board Gateware and Firmware
The EFC Board gateware and firmware are on the [Artiq](https://github.com/m-labs/artiq) repo.
To build the gateware and firmware,
```
python -m artiq.gateware.targets.efc --hw-rev [v1.0, v1.1]
```
## Routing Table Configuration if Shuttler is Connected to Kasli Satellite
When Kasli Satellite is compiled with Shuttler, Shuttler is connected to the Satellite Repeater instance. Therefore, you will need to specify the routing table on the Kasli/Kasli-soc master in order to access the Shuttler hardware. Shuttler locates at DEST 4 connecting to Repeater ID #3. The ID number goes up accordingly if more than one Shuttler is connected.
Here provides an example to configure the routing table.
You have 1 Kasli Master and 1 Kasli Satellite. Kasli Master (SFP1)(DEST1) port is connected to Kasli Satellite(SFP0)(DEST0). Shuttler is connected to Kasli Satellite with DRTIO over EEM Cable(DEST4).
1. Initialize the Routing Table: ``` artiq_route rt.bin init```
2. Add the routing table entry for Kasli Master's Peripherals: ```artiq_route rt.bin set 0 0```
3. Add the routing table entry for Kasli Satellite's Peripherals: ```artiq_route rt.bin set 1 1 0```
4. Add the routing table entry for Shuttler: ```artiq_route rt.bin set 4 1 4 0```
5. Flash the routing table on Kasli Master: ```artiq_coremgmt config write -f routing_table rt.bin```
## Flashing
When you are building a crate with shuttler(s), you should erase the flash/sd card config on both the EFC and Kasli/Kasli-soc. Always flash the EFC Board first before flashing the Kasli/Kasli-soc.
If either of the following elements is changed, you will need to **ERASE** the stored calibrated values on both the EFC and Kasli Master, or the communication between the boards cannot be established:
1. EEM Cable
2. Clock-Related Cable
3. EFC Board Gateware
4. Kasli/Kasli-Soc Master Gateware
5. EFC Board/Kasli/Kasli-Soc PCB
To erase the flash on the EFC board,
```
artiq_flash -t efc erase
```
To flash the gateware and firmware onto the EFC board,
```
artiq_flash --srcbuild -t [efc1v0, efc1v1] -d artiq_efc/shuttler
```
## Testing
1. Connect the Remote AFE Card to the Shuttler
2. Power up the Remote AFE Board and the Kasli/Kasli-Soc with the connected Shuttler.
3. Check all Remote AFE Board Power Indicator LEDs.
4. Run the `artiq_sinara_test`.
```
*** Testing LEDs.
Check for blinking. Press ENTER when done.
...
Testing LED: shuttler0_led0
Testing LED: shuttler0_led1
*** Testing Shuttler.
Testing: shuttler0
Check Remote AFE Board Relay LED Indicators.
Press Enter to Continue.
Testing Shuttler DAC
Voltages: 0.1 -0.1 0.2 -0.2 0.3 -0.3 0.4 -0.4 0.5 -0.5 0.6 -0.6 0.7 -0.7 0.8 -0.8
Press Enter to Continue.
PASSED
...
```

View File

@ -4,13 +4,96 @@
* [QUARTIQ Manual](https://quartiq.de/stabilizer/)
* [Firmware](https://github.com/quartiq/stabilizer)
EEM is used for power only, and it can be alternatively powered by 12V barrel jack or PoE.
## JSON
No JSON modifications required.
Not present in the JSON.
## Getting the firmware
You can get the firmware from [Hydra](https://nixbld.m-labs.hk/jobset/mcu/mcu-contrib).
* ``stabilizer-dual-iir`` supports Pounder v1.2 - probably you should flash this one,
* ``stabilizer-dual-iir-pounder_v1_0`` supports Pounder 1.0 and 1.1 (legacy),
* ``stabilizer-lockin`` is a different application which we do not usually flash.
These all include changes to the mainline code to include Pounder telemetry.
### Building (optional)
Please keep in mind that the firmware from the official Quartiq repository does not include support for Pounder in MQTT, you may need to use a fork for that. But if the stabilizer is without a Pounder, it's also a valid option.
There is no Nix Flake support to make things easier, so you need to set up rust and cargo manually. Start with cloning the stabilizer repository and opening a new shell with dfu-util (for flashing) and rustup (for building).
```
nix-shell -p dfu-util rustup
```
Set up the toolchain, this should be done only once:
```
rustup target add thumbv7em-none-eabihf
cargo install cargo-binutils
rustup component add llvm-tools-preview
rustup update
rustup default stable
```
Building:
```
cargo build --release
cargo objcopy --release --bin dual-iir -- -O binary dual-iir.bin
```
## Flashing
Once you have the binary, you can now flash it.
Without firmware on the device or with older firmware (without USB serial console), you need to use the jumper method:
1. Have the Stabilizer disconnected from power.
2. Use a jumper of some sort to short BOOT pins on the board.
3. Turn on the power.
4. You can remove the jumper after few seconds.
With newer firmware with USB serial console:
1. Connect the Stabilizer to power.
2. Connect USB cable to the Stabilizer.
3. Connect with a serial console emulator, usually at ``/dev/ttyACM0``.
4. Input ``platform dfu`` in the console.
And for both:
5. The device is now in DFU mode.
6. Flash the device with the following command:
```
dfu-util -a 0 -s 0x08000000:leave -R -D dual-iir.bin
```
7. Look for "File downloaded successfully".
For normal usage, the stabilizer must be configured with USB console later (try ``help`` command first), to set its IP address and MQTT broker address. However, for general testing (like the one below), you don't need to configure it any further.
### Clearing settings
In case someone sets some setting wrongly, or updates the firmware and suddenly there's an incompatibility, you may find (firmware, not yourself) in a state of panic, where it will not allow you to change the settings back.
1. Get into DFU mode (described above), probably with jumper method.
2. Use dfu-util to clear the flash completely:
```
dfu-util -a 0 -s 0x08000000:mass-erase:force:leave
```
3. Reflash the target firmware.
## Testing
1. Ensure that the [firmware](https://github.com/quartiq/stabilizer) has been flashed onto the Stabilizer
1. Ensure that the [firmware](#getting-the-firmware) has been flashed onto the Stabilizer
2. Turn on the crate/Stabilizer via EEM cable or power supply
3. Set up the signal generator for an amplitude of 1V, frequency of 10kHz, and a sine wave
4. Use the splitter to connect the generator's output to ADC0 and to the oscilloscope (refer to the picture below)

View File

@ -23,6 +23,28 @@ dfu-util -a 0 -s 0x08000000:leave -D thermostat.bin
Then check that fans are working properly.
You may also check fan controls via `fan` commands (see the firmware documentation).
## Test PID
1. For Zotino: connect 10-pins IDC 2.54mm FC cable from internal Thermostat connector to the Zotino TEC
2. General TEC: connect external connector to the TEC
3. Connect Ethernet and PSU
4. Run:
```shell
git clone gitea@git.m-labs.hk:esavkin/thermostat.git
cd thermostat
git checkout zotino-tec
nix develop
python pytec/tec_qt.py
```
5. In `Output Config`, set limits:
* `Max Cooling Current` - 400 mA
* `Max Heating Current` - 400 mA
* `Max Voltage Difference` - 1 V
6. `PID Config` -> `PID Auto Tune` set desired target temperature, which should be slightly above your room temperature (+10C)
7. Set `Thermistor Config` -> `B` and other values, according to the datasheet of the TEC module, for example for Zotino `B` is `3455 K`
8. Run `PID Config` -> `PID Auto Tune` -> `Run` and check graphs that the measured temperature goes to the target temperature,
and eventually stabilizes at +- 0.01 of the target
## Common problems
### Thermostat doesn't connect or doesn't enter DFU mode

View File

@ -20,7 +20,8 @@
## Setup
Check if [SUServo](./suservo.md) is enabled/disabled respective to customer needs. Connect to the clocker source.
Check if [SUServo](./suservo.md) is enabled/disabled respective to customer needs. Connect to the clock source - either Clocker,
Kasli or external via SMA.
### Synchronization

View File

@ -16,12 +16,12 @@
{
"type": "fastino",
"hw_rev": "v1.2", // optional
"log2_width": <0 to 5, default 0>, // pack multiple (in powers of 2) DAC channels into one RTIO write
"ports": [<port num>]
}
```
Fastino uses two physical EEM channels, but in the JSON file there should be only one channel specified,
and it should be the one connected to Fastino's EEM0.
Fastino uses one physical EEM channel, despite having two EEM ports.
## Setup
@ -57,18 +57,23 @@ Press ENTER when done.
This may happen when power-cycle is too short. Power down the crate, wait at least 30 seconds, and power up again.
[Issue](https://github.com/sinara-hw/Zotino/issues/37).
### Zero voltage output on Fastino
### Zero/meaningless voltage output on Fastino
Some Fastino may not output any voltage during testing, usually that means it has no gateware.
Some Fastino may not output any meaningful voltage during testing, usually that means it has no gateware flashed.
Another common symptom of no gateware is that no LEDs are lit up. Whereas if the gateware has been flashed, the PG and FD LEDs will be lit green.
You can flash the gateware with a standalone Kasli/Kasli-SoC:
You can flash the gateware with a Kasli/Kasli-SoC, be it in the crate or standalone (no specific gateware needed for Kasli/SoC):
1. Download the latest `fastino.bin` release from [quartiq/fastino](https://github.com/quartiq/fastino/releases)
2. Run `git clone https://github.com/quartiq/kasli-i2c.git` and place `fastino.bin` in the kasli-i2c directory
2. Connect the Fastino's EEM0 to any available Kasli/Kasli-SoC EEM port (**do not hot-plug**)
3. Power on the standalone Kasli/Kasli-SoC
4. Run `nix-shell -p python311Packages.pyftdi`
5. Run `cd kasli-i2c; python flash_fastino.py 0 EEM<number> write fastino.bin` where `<number>` is the EEM port number on the Kasli/Kasli-SoC side
6. If PG and FD LEDs are lit green, the Fastino is ready.
1. Download the latest `fastino.bin` release from [quartiq/fastino](https://github.com/quartiq/fastino/releases).
2. Run `git clone https://github.com/quartiq/kasli-i2c.git` and place `fastino.bin` in the kasli-i2c directory.
3. Connect the Fastino's EEM0 to any available Kasli/Kasli-SoC EEM port ([**do not hot-plug**](../build_test_firmware.md#operating-hints-and-warnings)).
You may skip this step if Fastino is connected within a crate.
4. Power on the standalone Kasli/Kasli-SoC and connect it to the PC via data micro-USB.
5. Run `nix-shell -p python311Packages.pyftdi`.
6. Run `cd kasli-i2c; python flash_fastino.py 0 EEM<number> write fastino.bin` where `<number>` is the EEM port number on the Kasli/Kasli-SoC side.
7. If PG and FD LEDs are lit green, the Fastino is ready.
### Fastino output is 10V
Fastinos by default after power up output 10V on all channels if not driven by the test otherwise. Make sure the EEM ports are specified correctly in the JSON and the EEM cable is connected to EEM0 on the Fastino.

BIN
src/img/efc_clk_sel.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 74 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 110 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 81 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 78 KiB

137
src/sw_sup/afws_client.md Normal file
View File

@ -0,0 +1,137 @@
# AFWS client
This article is intended to help with using the `afws_client` command properly.
## Usage
### What is AFWS
AFWS (ARTIQ FirmWare Service) - a service, that allows building customer tailored firmware and gateware (binaries) on M-Labs's servers,
and receive these binaries in ready-to-flash format. Subscription to this service also includes helpdesk support,
and thus is paid on yearly basis (contact sales for prices). It is also typically included when purchasing Carrier (Kasli/Kasli-SoC) for a year,
or one-time when purchasing standalone cards for existing crate. Each variant/carrier requires its own subscription.
### What do I need for obtaining binaries
You'll need to have credentials - username and password, which you can obtain from helpdesk, if you haven't yet.
Don't forget to specify variant (sticker on top of the crate) that you need to obtain binaries for.
### When do I need to update
In most cases there is no need to update the firmware, unless you encountered a bug and the fix was backported to your version.
However, if you: changed the layout of the cards - either moved EEM connections, added or deleted cards;
changed modes/configurations of the cards (e.g. enable/disable SUServo, synchronization, edge counter, SED lanes etc.).
In such cases, these changes need to be authorized through helpdesk.
### How to
The base command looks like this:
```shell
afws_client <username> build <afws_directory> <variant>
```
Where (remove `<` and `>`):
* `<username>` - your username from credentials
* `<afws_directory>` - the directory/folder, into which you wish to save the binaries
* `<variant>` - name of the crate/variant. It's optional if you have only one variant in the account
After running this command, it will ask you for the password (the line will remain blank for security reasons).
If everything matches (username and password are correct, specified variant is in your account and not expired),
AFWS will start building the firmware, which takes 10-15 minutes. Sometimes there might be some problems, in which
case don't hesitate to contact helpdesk.
After the build done, the AFWS client will automatically download the binaries into `<afws_directory>`, from which
you can flash them into your Carrier.
#### View build logs
You may want to view the build logs (for example, in case of problems with configuration).
For this, add `--log` option after build:
```shell
afws_client <username> build --log <afws_directory> <variant>
```
#### Specify version
By default, AFWS client tries to figure out the installed ARTIQ version. However it works only for Kasli, and not Kasli-SoC.
It also may fail to determine ARTIQ version if you are using AFWS client without ARTIQ installation.
Additionally, you may want to specify version regardless of installed version.
In all these cases, you'll need to specify **both** `--major-ver` and `--rev` arguments, so your command will look like this:
```shell
afws_client <username> build --major-ver <MAJOR_VER> --rev <REV> <afws_directory> <variant>
```
Where:
* `MAJOR_VER` - ARTIQ major version, either `7` (legacy), `8` (current stable),
`9` (current beta) or `10` (experimental with `nac3` compiler)
* `REV` - revision from respective branch and repository - i.e. commit hash. You may obtain it either from:
* [ARTIQ repository](https://github.com/m-labs/artiq) (for Kasli 2.0 and earlier) by
[selecting branch](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/viewing-branches-in-your-repository)
and selecting `XXX commits` above list of files. From here, the list of commits in specified branch will appear
and you will be able to choose the commit and press ["Copy full SHA for YYY"](https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/about-commits#using-the-file-tree)
button in the right side.
* [ARTIQ on Zynq repository](https://git.m-labs.hk/M-Labs/artiq-zynq) (for Kasli-SoC). In similar way to GitHub,
you can choose branch, commit history and copy SHA1 of the commit.
The branches currently map as following:
* ARTIQ-7 - release-7
* ARTIQ-8 - release-8
* ARTIQ-9 - master
* ARTIQ-10 - nac3
The binaries you receive are "pure" - if the inputs are the same (same version,
same JSON), the system outputs exactly the same binaries, and if you did it recently, they will be obtained from Nix
cache (i.e. not rebuilt).
#### Change password
After you received credentials from us, we strongly recommend changing the password as soon as possible via
`afws_client <username> passwd` command. This command will ask you for existing password and new desired password.
The passwords are stored in a hashed way (i.e. cannot be decrypted back), however it's your responsibility to choose good passwords.
Just keep in mind, that password may contain only alpha-numeric symbols and underscore `[a-zA-Z0-9_]`.
If you cannot login, we may reset your password if you email us at helpdesk.
#### Get variants
You may get variants, which are tied to your account by using `get_variants` command:
```shell
afws_client <username> get_variants
```
It will ask for password and output the variants and their respective expiry date:
```text
+-----------+-------------+
| Variant | Expiry date |
+-----------+-------------+
| test | 2028-02-08 |
| test3 | 2042-08-08 |
+-----------+-------------+
```
#### Get JSONs
Sometimes you may want to view the JSON description, from which AFWS is building the variant. With the JSON, you can
later build the firmware by yourself and/or generate device_db file. The command looks like this (variant
needs to be valid, i.e. not expired and authorized in your account):
```shell
afws_client <username> get_json [-o <OUT>] [-f] <variant>
```
Specify output file `-o <OUT>`, if you want to save it directly to file `<OUT>`, use `-f` if you want to force
overwrite. If you do not specify any of these options, you'll get the JSON description directly in stdin (i.e. in your
console/terminal).
#### Miscellaneous
You may also specify custom AFWS provider with these options (put them before username):
* `--server SERVER` - server to connect to (default: afws.m-labs.hk)
* `--port PORT` - port to connect to (default: 80)
* `--cert CERT` - SSL certificate file used to authenticate server (default: use system certificates)

View File

@ -1,4 +1,6 @@
# Building ARTIQ-6 and earlier
# Building legacy firmware
## Building ARTIQ-6 and earlier
Pre-flake ARTIQ (that is 6 and earlier) requires slightly different steps for building.
@ -6,9 +8,9 @@ Pre-flake ARTIQ (that is 6 and earlier) requires slightly different steps for bu
The following steps need to be done only once.
First we will need to specify older nixpkg version - 21.05. Open ``~/.nix-channels`` with your favorite text editor.
First we will need to specify older nixpkg version - 21.05. Open `~/.nix-channels` with your favorite text editor.
If there are any ``nixpkgs`` present already, comment them out with ``#``.
If there are any `nixpkgs` present already, comment them out with `#`.
Then add the following line:
@ -18,7 +20,7 @@ https://nixos.org/channels/nixos-21.05 nixpkgs
Save and exit.
Now, we need special ``nix-scripts`` to configure building environment, and a local copy of the artiq repository, in legacy release.
Now, we need special `nix-scripts` to configure building environment, and a local copy of the artiq repository, in legacy release.
```shell
mkdir artiq-legacy
@ -30,6 +32,14 @@ git checkout release-6 # or release-5...
cd ..
```
Keep in mind that ARTIQ-6 scripts have been removed in `nix-scripts`, so you may need to checkout the last commit that still has them.
```shell
cd nix-scripts
git checkout c590df48e0553a670e18ebf9d02047bfcfddb40d
cd ..
```
## Setting up the environment and building firmware
Within ``fish`` shell (others may not work correctly), set up the ARTIQ build environment:
@ -51,7 +61,8 @@ artiq_flash -V <variant> -d artiq_kasli --srcbuild
There's a slight discrepancy from usual command - ``-V <variant>`` option is not present in ARTIQ-7+, but it is necessary here.
If you want to send the binaries to a customer, there's no need packing up the whole build directory - only ``top.bit``, ``bootloader.bin`` and ``runtime.elf/fbi`` or ``satman.elf/fbi`` are necessary. You can use the ``prep_pkg.py`` script from extras to package them up neatly into a zip file for distributions:
If you want to send the binaries to a customer, there's no need packing up the whole build directory - only `top.bit`, `bootloader.bin`
and `runtime.elf/fbi` or `satman.elf/fbi` are necessary. You can use the `prep_pkg.py` script from extras to package them up neatly into a zip file for distributions:
```shell
python prep_pkg.py -v <variant> -d artiq_kasli/
@ -62,3 +73,39 @@ Then the customer can use ``artiq_flash`` easily, after extracting the contents:
```shell
artiq_flash -V <variant> -d .
```
## ARTIQ-7
The process of building firmware for ARTIQ-7 is mostly similar to ARTIQ-8, except there are no named RTIO channels
and no remote reboot functionality on Kasli-SoC. DRTIO set ups are also similar to ARTIQ-8. [See reference](../build_test_firmware.md).
### Kasli, Kasli 2.0
```shell
mkdir <variant>
cd <variant>/
nix develop github:m-labs/artiq\?ref=release-7
# master/standalone only
artiq_mkfs -s ip 192.168.1.75 kasli.config
artiq_flash storage -f kasli.config
artiq_ddb_template -o device_db.py <variant>.json
python -m artiq.gateware.targets.kasli_generic <variant>.json
artiq_flash --srcbuild -d artiq_kasli/<variant>/
```
### Kasli-SoC
```shell
mkdir <variant>
cd <variant>/
nix develop git+https://git.m-labs.hk/m-labs/artiq-zynq\?ref=release-7
artiq_ddb_template -o device_db.py <variant>.json
nix build -L --impure --expr 'let fl = builtins.getFlake "git+https://git.m-labs.hk/m-labs/artiq-zynq?ref=release-7"; in (fl.makeArtiqZynqPackage {target="kasli_soc"; variant="[master, standalone, satellite]"; json=<full path to the json description>;}).kasli_soc-[master, standalone, satellite]-sd'
# copy `results/boot.bin` to the SD card
# insert SD card to the Kasli-SoC and boot
artiq_coremgmt -D 192.168.1.56 config write -s ip 192.168.1.75 # or just place extra/CONFIG.TXT near the boot.bin on SD card
# update firmware (alternative to copy to SD, if ARTIQ already running)
artiq_coremgmt config write -f boot result/boot.bin
# reboot via power supply
```

38
src/sw_sup/artiq_start.md Normal file
View File

@ -0,0 +1,38 @@
# Starting with ARTIQ
This page describes how to start with ARTIQ system for novice users.
## Connecting wires
In most cases the system is shipped with power bricks (PSU), DC splitters and SFPs enough to power and control the whole system.
Connect them in following order:
1. Insert Ethernet SFP into the SFP0 of the master or standalone Kasli/Kasli-SoC (Carrier)
2. Connect these SFPs to the router or PC via Ethernet cable (in some cases, optical cable)
3. Insert optic/direct attach SFPs into the master and satellite Carriers, respective to the numeration, [more info in DRTIO page](drtio.md)
4. Power on PSU or EEM power module, by inserting C14 cable, attach DC splitters if available
5. Some cards may have "External power" setting (check the quotation), in this case, insert DC connector into the port
6. Insert remaining cables into the Carriers (not applicable in case of EEM Power Module).
## Set the network
By default standalone/master Carriers arrive with 192.168.1.75/24 set as their static address. Carrier will try to acquire this address
from your router, and in case of failure, they will be just unavailable from the network. Check the following articles for troubleshooting network issues:
* [Networking](networking.md)
* [Official docs](https://m-labs.hk/artiq/manual/installing.html#setting-up-the-core-device-ip-networking)
## Run first experiment via artiq_run
Before diving in to the repository experiments management and scheduling, it is essential to try run your first experiment
via most basic way - `artiq_run`. For this you need to enter your ARTIQ environment (console) and run:
```shell
artiq_run --device-db path/to/device_db.py path/to/experiment.py
```
In case your directory contains relevant `device_db` file, you may omit the `--device-db path/to/device_db.py` part.
To check this, you may run `ls .` and check if it is in the list.
On pre-installed NUCs, the ARTIQ commands are available everywhere, and you just need to run them.
If you have Nix package manager or NixOS, you will just need to enter the shell with `nix develop github:m-labs/artiq\?ref=release-7`.
If you have installed ARTIQ with Conda, you will need to activate the environment with `conda activate <name of the environment with ARTIQ>`.
You may check for experiments in the [official docs](https://m-labs.hk/artiq/manual/getting_started_core.html).

View File

@ -45,3 +45,9 @@ During the connection, the clock signal is being distributed, effectively making
* Wrong setups - master to master, standalone to standalone. Messing up with SFP ports generally makes it unusable,
but the connection should be established in most cases.
* The fiber adapters are not symmetrical - if one end has 1270/1330 label, another one should be 1330/1270.
### Master-satellite interrupted/unstable connection
This often happens due to overheating issues. Check if the Kasli/SoC fans are working properly and
try installing rack fans to increase the air flow.

View File

@ -8,14 +8,15 @@ a-la `I can't connect, please help`.
1. `device_db.py` has misleading `core_addr` address.
2. PC and the crate are in different subnets. They should be in the same network. Also you may want to directly attach the Kasli to the PC.
3. Network restrictions/problems on your router, either by IP, MAC, protocols or anything else.
4. Wrong configuration of the Kasli. Change IP or MAC address to correspond your network. For ARTIQ-8, add
network mask to the `ip` setting on Kasli, like `192.168.1.75/24`.
4. Wrong configuration of the Kasli. Change IP or MAC address to correspond your network. For ARTIQ-8 and later, add
network mask to the `ip` setting on Kasli (not applicable for Kasli-SoC), like `192.168.1.75/24`.
5. Incompatible Ethernet cables/SFP RJ45. Try different cables and SFP adapters.
We usually test them with CAT6 cables, but lower categories should be supported too.
6. SFP or Ethernet are not pushed til the end.
7. Some weird bugs in Vivado, leading to not working SFP on certain combinations of builds and Kaslis (very rare)
8. Running configured for external reference Kasli without external reference clock signal
9. Using legacy firmware with newer hardware. ARTIQ-6 doesn't support Kasli v2.0.2
10. Some other device in your network already reserved the configured IP address.
## Ways to diagnose
@ -27,6 +28,8 @@ a-la `I can't connect, please help`.
5. `nmap` and `arp` to scan your network to help your Kasli get discovered. May be restricted in your network.
6. Directly connect your Kasli to the PC via Ethernet and set up networking on the PC: `ip addr change 192.168.1.0/24 dev eth0`
7. Become a router and capture all the packets when your Kasli tries to connect to the network.
8. Turn off the Carrier/Kasli and `ping` the configured IP address. If it pings, then you'll need either set different
IP address on your Carrier or somehow deal with that other device - remove, assign different address, move to other network etc.
## Direct connection

View File

@ -0,0 +1,68 @@
# Setup your PC for building ARTIQ firmware
This page should guide you through building the firmware on your own PC.
Unfortunately, the building process is not possible on Windows natively (nor MSYS2),
but you can use [WSL](https://learn.microsoft.com/en-us/windows/wsl/install).
## Prerequisites
You should have a Linux with `nix` and `git` installed. For this purpose you may want to consider NixOS, though it is hard way for everything else.
You should have at least 70+ GB of free space (better 100+ GB) on your `/opt` or `/` - most of this space will be taken
by Vivado.
## Installation
1. Install Vivado 2022.2 from [Vivado archive](https://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/vivado-design-tools/archive.html) into `/opt`.
2. Check that `ls -al /opt/Xilinx/Vivado/2022.2/settings64.sh` exists and has read and execute permissions for all:
```shell
$ ls -al /opt/Xilinx/Vivado/2022.2/settings64.sh
-rwxr-xr-x 1 nobody nogroup 245 Dec 17 2022 /opt/Xilinx/Vivado/2022.2/settings64.sh
```
3. Add following into the `~/.local/share/nix/trusted-settings.json`, by `mkdir -p ~/.local/share/nix/ && nano ~/.local/share/nix/trusted-settings.json`
or with your favorite way (don't forget to save - Ctrl+O in `nano`):
```json
{
"extra-sandbox-paths":{
"/opt":true
},
"extra-substituters":{
"https://nixbld.m-labs.hk":true
},
"extra-trusted-public-keys":{
"nixbld.m-labs.hk-1:5aSRVA5b320xbNvu30tqxVPXpld73bhtOeH6uAjRyHc=":true
}
}
```
4. Enable flakes in Nix and add `/opt` to sandbox e.g. adding following to the `nix.conf` (for example `~/.config/nix/nix.conf` or `/etc/nix/nix.conf`):
```
experimental-features = nix-command flakes
extra-sandbox-paths = /opt
```
5. On Ubuntu, the Nix will conflict with Apparmor. You'll need to disable Apparmor for Nix,
or for the whole system (you can also delete Apparmor completely, but be careful with it).
From here, you should be able to enter ARTIQ development shell directly from URL, or by cloning the repository.
The later will allow you to edit the source code in case of need.
For example for Kasli 2.0:
```shell
git clone https://github.com/m-labs/artiq.git
cd artiq
nix develop #boards
```
For Kasli-SoC:
```shell
git clone https://git.m-labs.hk/M-Labs/artiq-zynq.git
cd artiq-zynq
nix develop
```
For building instructions for your JSON, please refer to the [build and test instructions](../build_test_firmware.md).
The reference uses commands like `nix develop github:m-labs/artiq\?ref=release-8#boards` and `nix develop git+https://git.m-labs.hk/m-labs/artiq-zynq\?ref=release-8`.
You may safely skip such commands if you entered the development shell (`nix develop`) from cloned git repository.
If you want to update the source files, you may use `git pull origin master --rebase`.
Please refer to the [git documentation](https://www.git-scm.com/docs) or other resources of your choice if you are unfamiliar with `git`.
You may also use GUI git tools, like the one integrated into JetBrains IDEs (PyCharm, Intellij and others), VS Code, Sublime Merge or others.

View File

@ -15,6 +15,8 @@ until its fully loaded.
### Older Nix and other Linuxes
Ensure your user is in `dialout` group.
1. Install `cutecom` via `nix-shell -p cutecom` or your package manager
2. Run `cutecom` and follow settings from the picture: ![uart_cutecom.png](../img/uart_cutecom.png)
3. Restart the device with `artiq_flash start`, or by power-cycling it (wait 30 seconds before turning on)