rohitksingh_work has quit [Read error: Connection reset by peer]
<rjo>
diode as in "AM detector"
rohitksingh has joined #m-labs
<sb0>
how well does this approximate real conditions?
<rjo>
very well
<sb0>
what about eg response time of the AOM?
<sb0>
add some RC filter?
rohitksingh has quit [Ping timeout: 272 seconds]
<rjo>
the AOM is not relevant for functional CI. there is filtering in a diode AM detector and in stabilizer.
rohitksingh has joined #m-labs
<sb0>
okay, so this is just about making a "smoke test" for CI, not testing su-servo in something that is close to real conditions?
<sb0>
how linear is this AOM amplitude -> photodiode signal process?
<rjo>
no. this would be a complete CI for su-servo. everything else is outside the scope. all external non-linearities, loop delays, noise, offsets, laser dying are for the user.
<rjo>
i can't think of any representative or relevant other "real conditions" that would need to be reproduced to fully unittest su-servo.
<rjo>
in practice the rf power to photodiode voltage relation is nicely linear up to certain power (amp compression, aom efficiency roll over). su-servo steers in amplitude, not in power but since you'd use this around a working point this is fine. significantly different working points/setpoints will need different gains in practice. that's one reason for the profiles. other setups even have optical power prop to
<rjo>
squared rf power.
rohitksingh has quit [Ping timeout: 244 seconds]
rohitksingh has joined #m-labs
bluebugs is now known as cedric
m4ssi has quit [Ping timeout: 272 seconds]
<adamgreig>
whitequark: in nmigen I'm getting a bunch of elaboratable unused warnings on things that I'm pretty sure I am using (e.g. top level module which I call elaborate() on and then pass to rtlil.convert), is that a bug or user error?
<adamgreig>
also I learnt I should have been setting transparent=False on my ice40 multi-clock memories, and now I am paying the price as yosys has stopped trying to infer them
<adamgreig>
there's a bit of noise as that's my quick test case for the multiclock thing, but it warns about m being unused unless it manually sets m._Elaboratable__used to True
<whitequark>
.elaborate should not generally be called directly
<whitequark>
because it is legal to return another elaboratable
<adamgreig>
ack
<adamgreig>
I see i mostly use it in test cases
<adamgreig>
mod = bla.elaborate(None); with pysim.Simulator(mod) as sim: sim.run()
<adamgreig>
sort of thing
<adamgreig>
can simulator just take bla directly now?
<whitequark>
yeah, that predates Fragment.get i think?
<adamgreig>
yes
<adamgreig>
this whole codebase does
<whitequark>
Simulator uses Fragment.get yes
<adamgreig>
cool ok
<adamgreig>
thanks!
* adamgreig
goes back to deriving everything from Elaboratable
<adamgreig>
whitequark: previously I called elaborate() to obtain the module, then could add submodules to it before passing it to pysim.Simulator; if I pass the elaboratable directly to pysim or convert it to a fragment first there's presumably no way to add submodules to it?
<adamgreig>
probably sounds like a weird thing to be doing but e.g. my class takes a memory port as an argument and then uses it, so the test case must construct the memory, pass it to the class, then add the memory ports to the submodules for the test
<adamgreig>
I could make a new module for testing and add the memory and the class-under-test to it, I guess
<whitequark>
that would be the normal approach
<whitequark>
in principle it's fixable on the level of Elaboratable but it's a bit gross
<adamgreig>
ack, probably adding submodules to the module under test was a gross thing for me to be doing from the start
<adamgreig>
cool, all tests passing and builds without any warnings and still works on hardware too