M-Labs/artiq-zynq
10
1
Fork 19
Code Issues 12 Pull Requests 1 Releases Wiki Activity

Shuttler: Add Support on Kasli-Soc Platform #268

Merged
sb10q merged 1 commits from linuswck/artiq-zynq:shuttler_kasli_soc_port into master 2024-08-17 17:37:23 +08:00
Conversation 2 Commits 1 Files Changed 6 +245
linuswck commented 2023-10-09 17:44:16 +08:00
Owner
Copy Link

ARTIQ-ZYNQ Pull Request

This PR adds support for shuttler on Artiq-Zynq platform. Code is ported from artiq repo.

Description of Changes

Gateware:
zynq_clocking.rs:

  • Generate sys5x, 208MHz Reference Clock for IDELAYCTRL, IDELAYCTRL instance for EEM Serdes

kasli_soc.py

  • Add EEM_DRTIO gateware

Firmware:
drtio_eem.rs:

  • For init fn, as kasli-soc can be operated without a SD Card. Error related to the absence of SD Card should not halt the core.
  • Other code does not have functional change.

rtio_clocking.rs & main.rs:

  • Add drtio_eem related initialization

Test

Gateware, Firmware and the corresponding frontend scripts are tested on the latest commit.
artiq-zynq: a28a819b18
artiq: 96941d7c04969aed295381e8bee3ca093f84cde8

Generating device_db.py

kasli-soc-master.json:
As kasli-soc has 4 drtio channels, drtio_destination needs to be manually specified to 5.
On kasli-soc, can only be specified on port 0, 1, 8, 9 (LVDS_25 capable).

 {
     "type": "shuttler",
     "ports": [8],
     "drtio_destination": 5,
 }

Running the example code

The whole system functions as expected in normal dma mode.

There is bug with distributed ddma mode.
In the following case,

while not(self.scheduler.check_termination()):
            delay(1*s)
            self.core_dma.playback_handle(example_waveform_handle)

For some reasons, delay(1*s) may be skipped and self.core_dma.playback_handle(example_waveform_handle) is dispatched without delay is being waited. The same code running in normal dma mode functions.

Type of Changes

Type
✓ ✨ New feature
# ARTIQ-ZYNQ Pull Request This PR adds support for shuttler on Artiq-Zynq platform. Code is ported from artiq repo. ## Description of Changes Gateware: zynq_clocking.rs: - Generate sys5x, 208MHz Reference Clock for IDELAYCTRL, IDELAYCTRL instance for EEM Serdes kasli_soc.py - Add EEM_DRTIO gateware Firmware: drtio_eem.rs: - For `init` fn, as kasli-soc can be operated without a SD Card. Error related to the absence of SD Card should not halt the core. - Other code does not have functional change. rtio_clocking.rs & main.rs: - Add drtio_eem related initialization ## Test Gateware, Firmware and the corresponding frontend scripts are tested on the latest commit. artiq-zynq: a28a819b18 artiq: 96941d7c04969aed295381e8bee3ca093f84cde8 ### Generating device_db.py kasli-soc-master.json: As kasli-soc has 4 drtio channels, drtio_destination needs to be manually specified to 5. On kasli-soc, can only be specified on port 0, 1, 8, 9 (LVDS_25 capable). ```json { "type": "shuttler", "ports": [8], "drtio_destination": 5, } ``` ### Running the example code The whole system functions as expected in **normal dma mode**. There is bug with **distributed ddma mode**. In the following case, ```python while not(self.scheduler.check_termination()): delay(1*s) self.core_dma.playback_handle(example_waveform_handle) ``` For some reasons, `delay(1*s)` may be skipped and `self.core_dma.playback_handle(example_waveform_handle)` is dispatched without delay is being waited. The same code running in normal dma mode functions. ## Type of Changes <!-- Leave ONLY the corresponding lines for the applicable type of change: --> | | Type | | ------------- | ------------- | | ✓ | :sparkles: New feature |
sb10q commented 2023-10-09 18:05:39 +08:00
Owner
Copy Link

As kasli-soc has 4 drtio channels, drtio_destination needs to be manually specified to 5.

I think this could be automated?

> As kasli-soc has 4 drtio channels, drtio_destination needs to be manually specified to 5. I think this could be automated?
sb10q reviewed 2023-10-10 09:14:14 +08:00
src/gateware/zynq_clocking.py Outdated
@ -121,0 +143,4 @@
o_CLKFBOUT=mmcm_fb_clk,
# 500MHz. Must be more than 400MHz as per DDR3 specs.
sb10q commented 2023-10-10 09:14:14 +08:00
Owner
Copy Link

Irrelevant here since the DDR3 is on the PS.

Irrelevant here since the DDR3 is on the PS.
linuswck marked this conversation as resolved
sb10q reviewed 2023-10-10 09:15:51 +08:00
sb10q reviewed 2023-10-10 09:19:08 +08:00
src/gateware/zynq_clocking.py Outdated
@ -121,0 +136,4 @@
p_CLKIN2_PERIOD=period, i_CLKIN2=bootstrap_clk,
i_CLKINSEL=self.clk_sw_fsm.o_clk_sw,
# VCO @ 1.25GHz with MULT=10
sb10q commented 2023-10-10 09:19:08 +08:00
Owner
Copy Link

Remove "with MULT=10"

Remove "with MULT=10"
linuswck marked this conversation as resolved
sb10q reviewed 2023-10-10 09:26:59 +08:00
src/gateware/zynq_clocking.py Outdated
@ -121,0 +106,4 @@
p_CLKFBOUT_MULT=8, p_DIVCLK_DIVIDE=1,
# 200MHz for IDELAYCTRL
p_CLKOUT0_DIVIDE=5, p_CLKOUT0_PHASE=0.0, o_CLKOUT0=pll_clk200,
sb10q commented 2023-10-10 09:26:59 +08:00
Owner
Copy Link

As per DS187, the tolerance on the IDELAYCTRL clock is +/- 10MHz, and using a different clock frequency seems to simply result in different calibrated tap delays that won't really affect us anyway.

Just generate it from the MMCM below with a divide-by-6 (208MHz), and remove that PLL, and remove the enable_sys5x option since it won't really save resources anymore.

(Note that a motivation to have enable_sys5x in misoc was to keep the same clocking structure on release-7 to prevent regressions, but this is not relevant here).

As per DS187, the tolerance on the IDELAYCTRL clock is +/- 10MHz, and using a different clock frequency seems to simply result in different calibrated tap delays that won't really affect us anyway. Just generate it from the MMCM below with a divide-by-6 (208MHz), and remove that PLL, and remove the enable_sys5x option since it won't really save resources anymore. (Note that a motivation to have enable_sys5x in misoc was to keep the same clocking structure on release-7 to prevent regressions, but this is not relevant here).
linuswck commented 2023-10-10 10:11:24 +08:00
Author
Owner
Copy Link

As kasli-soc has 4 drtio channels, drtio_destination needs to be manually specified to 5.

I think this could be automated?

Yes that should be automated. That should be a new PR on artiq repo.

> > As kasli-soc has 4 drtio channels, drtio_destination needs to be manually specified to 5. > > I think this could be automated? > Yes that should be automated. That should be a new PR on artiq repo.
linuswck force-pushed shuttler_kasli_soc_port from a7cc4aa280 to a4d1be00c0 2023-10-10 15:18:15 +08:00 Compare
sb10q merged commit a4d1be00c0 into master 2023-10-11 10:20:42 +08:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
priority:critical

   
priority:high

   
priority:low

   
priority:medium
No Label
priority:critical
priority:high
priority:low
priority:medium
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: M-Labs/artiq-zynq#268
No description provided.
Delete Branch "linuswck/artiq-zynq:shuttler_kasli_soc_port"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?