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

[RFC] Fast Servo HDL/Software features and specification #6

Open
jmatyas opened this issue Jun 1, 2020 · 8 comments
Open

[RFC] Fast Servo HDL/Software features and specification #6

jmatyas opened this issue Jun 1, 2020 · 8 comments

Comments

@jmatyas
Copy link

jmatyas commented Jun 1, 2020

Hi All,

I was asked to develop software/HDL support for the Fast Servo (I'm going to use FS as a shortcut), which I happily agreed upon.

I've tried to gather specs and use-cases that have been already discussed to start designing implementaion worfkflow but what I found was mostly hardware specification or that FS should be "like stabilizer but faster", wich is rather vague desctiption. I created this issue, to clarify Fast Servo's specs/features that are needed to be implemented.

Features

Fundamental questions: what FS should do, should be capable of (in terms of software/HDL)? What should be implemented? What are the needs? What is top priority?

And apart from the above:

  • what is it's desired mode of operation - standalone board capable of communicating with Kasli or FS as Kasli's "slave" board? (or both?)
  • if communicating with Kasli - what kind of communication is needed - logs, alerts, etc? Will basic configuration of the loops be enough?
  • running 2 independent voltage loops only? or maybe 1 input 2 outputs as well?
  • what kind of feedback control loop is needed - PID, PI, PD, PIID, etc?
  • what other features are needed?
  • what kind of control is needed (only "set coefficients, turn on, off", or something more?)
  • what kind of software/HDL support for Stabilizer mezannines is needed?
@hartytp
Copy link

hartytp commented Jun 1, 2020

I've tried to gather specs and use-cases that have been already discussed to start designing implementaion worfkflow but what I found was mostly hardware specification or that FS should be "like stabilizer but faster", wich is rather vague desctiption

Indeed! I'd really love to gather use cases here before we start developing gateware/firmware. So far this project has had way too little input from other users. I'd really like to hear more "end-user" voices.

The main use-case I had in mind for FS was laser frequency servos with ~1-3MHz BW. This would be a standalone card controlled via Ethernet.

running 2 independent voltage loops only? or maybe 1 input 2 outputs as well?

I think that 2 independent loops is sufficient, but ideally with a mux to allow flexible mapping between ADCs and IIRs (assuming we have room in the timing budget).

what kind of feedback control loop is needed - PID, PI, PD, PIID, etc?

PIID would be nice.

what other features are needed?

Streaming ADC/IIR output samples for diagnostics is really useful.

@dtcallcock
Copy link
Member

There are a couple of use cases detailed in the paper on the NIST design.

The doubling cavity use case is probably already well covered by Stabilizer though as only ~10kHz of bandwidth is needed.

In practice, the NIST box is also used a lot for laser intensity servo-ing. SU-Servo, Phaser, and Sayma have this capability built-in though so that use case is probably already covered in Sinara too.

So far this project has had way too little input from other users.

That's kind of an issue for Sinara in general. You'd think with all those crates out there we'd be getting a bit more feedback.

@jmatyas
Copy link
Author

jmatyas commented Jun 3, 2020

The main use-case I had in mind for FS was laser frequency servos with ~1-3MHz BW. This would be a standalone card controlled via Ethernet

OK, so ARTIQ control (SU-Servo style) or something else? (This question may be derived from another one: do we want to integrate FS with ARTIQ software?)

Streaming ADC/IIR output samples for diagnostics is really useful.

Oh, definitely! Seems like a nice feature.

And regarding features - do we want FS to work with some kind of external phase-frequency detector, or auto-locking/phase detection system should be available in gateware as well?

@hartytp
Copy link

hartytp commented Jun 3, 2020

OK, so ARTIQ control (SU-Servo style) or something else? (This question may be derived from another one: do we want to integrate FS with ARTIQ software?)

For the "standalone" use-case I imagine this being non-real time, so just any convenient ethernet interface (c.f. stabilizer). Once it has a python driver it's ARTIQ-compatible.

And regarding features - do we want FS to work with some kind of external phase-frequency detector, or auto-locking/phase detection system should be available in gateware as well?

There are a bunch of nice additional features once could imagine, including auto-relock/LD (@jordens has made some proposals for Stabilizer and elsewhere).

For laser locks, there would usually be an external mixer. e.g. on Pounder.

@gkasprow
Copy link
Member

gkasprow commented Nov 6, 2021

@jordens does it make any sense to synchronize ADC and DAC using a low jitter clock from Kasli? I can add an MMCX clock input

@jordens
Copy link
Member

jordens commented Nov 7, 2021

Yes. For all non-DC precision applications this is very useful.

@gkasprow
Copy link
Member

gkasprow commented Nov 7, 2021

OK, I added MMCX input to the clock distribution IC input.

@kaolpr
Copy link
Member

kaolpr commented May 11, 2022

Together with @jmatyas we're looking for some synergy for sw development for this project. I see two main directions:

  • Port linien. This should be pretty straightforward, however up to my understanding (please correct me if I'm wrong) it is less generic than our original "reference" - NIST Digital Servo.
  • Use PYNQ as system base and port NIST Digital Servo architecture creating sort of a tool set that can be (more) easily adjusted to the particular application. As an example application we'd implement original NIST Servo so that one could use it as (almost) drop-in replacement.

Do you have any thoughts on that? Which option do you prefer?

EDIT: it seems that I've misunderstood Linen a bit. It really looks like the right way to go. But still I'd be very happy to have someone else’s opinion on that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants