Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DESY recommendation class D1.4 for RTM connector #29

Open
3 of 4 tasks
kaolpr opened this issue Jun 5, 2020 · 3 comments
Open
3 of 4 tasks

DESY recommendation class D1.4 for RTM connector #29

kaolpr opened this issue Jun 5, 2020 · 3 comments
Assignees
Labels
bug Something isn't working
Milestone

Comments

@kaolpr
Copy link
Member

kaolpr commented Jun 5, 2020

  • Rename at least nets to be compatible with D1.4 recommendation (preferably also ports of the RTM_Connector sheet)
  • Change NOT USED to ASSEMBLY VARIANT, precisely highlight signals that are available in assembly variant
  • J31 / 8-10 / ab do not follow the recommendation, evaluate the possibility of keeping current RTM_FPGA_CFG as an assembly option while routing proper signals to these ports
  • Conider routing RTM_CLK and AMC_CLK to clock cross-bar to enable distribution of clocks from RTM to FMC (e.g. sourcing from uRFB).
@kaolpr kaolpr added the bug Something isn't working label Jun 5, 2020
@kaolpr kaolpr added this to the AFCZ v1.1 milestone Jun 5, 2020
@filipswit
Copy link
Collaborator

I can rout differentially these signals J31 / 8-10 / ab, but from recomendation they should be GTP or CC.
2020-06-09_11h34_40

The RTM_CLK (which from recomendation is AMC_CLK ) actually goes to cross-bar
2020-06-09_11h56_27

Another one is is "RTM_ADC_DAC_SYNC.SYNCOUT11" and it is possible to route it to cross-bar, but please pont which input I can use to make it useful

@gkasprow
Copy link
Collaborator

gkasprow commented Jun 9, 2020

The plan for RTM in AFCZ was to eventually replace the Sayma AMC. But for the moment it's not important

@kaolpr
Copy link
Member Author

kaolpr commented Jun 17, 2020

Up to my understanding, GPTs are just transceiver clocks. In Ultrascale architecture, it is possible to also output signal from the REFCLK pin pair. See #37.

Regarding compatibility - I think generally it would be better to stick to the standard. Even if it's not that widespread. Especially if it does not cost us that much (like f.e. in case of AFCv4).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants