-
Notifications
You must be signed in to change notification settings - Fork 7
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
Kasli v1.2 wishlist #499
Comments
Is there a Kasli v1.2 planned for any time in the future? |
I think we need more experience with it in the field to be able to say that. |
First let's see how v1.1 operates, IMO points in the top post are not worth it right now. |
@jordens Oh come on! You told me to change it from red to green so there are fewer items in the BOM. :D Anyway LOL polarity can be changed in register 22 B1 of Si5324. |
Ah. Right. Then it's perfect. I forgot about both. ;) |
The biggest thing I'd like to see changed on the list above is the heatsink, since the FPGA gets very hot atm. It might be worth going for a heatsink with a clip on fan. |
|
I think we're slowly approaching point when we can think about next revision. Are there any other things we'd like to test before I start implementing changes? What's the consensus on Si5324/Si5369/Si5346? |
@marmeladapk In the long run, I'm still potentially keen to implement WR on Kasli. Probably use a DAC + high-quality VCO for clock recovery. Then either use a LVPECL clock buffer (noise isn't critical here, so there are lots of options) or something like an AD9516-4 to do the fanout. However, we're still doing a design study to make sure we get that right, so we won't have a design for that for another week or two. Until/unless we switch to WR, I'm not fussed about any of the options being discussed. IMHO, the present clocking works well (modulo the stability/phase determinism issues with the Si5324) and none of the options presented above offer a good enough advantage in terms of cost/power/simplicity to be worth changing a working design and risking breaking things. However, if @jordens feels strongly about it, I don't object either. |
I don't think that is accurate and might even be wrong. I'd state how much potential difference we are willing and able to tolerate and what the actual ground paths in the system are. Like it is done on all measurement equipment. @sbourdeauducq wanted to do tests with the Si5326 to guide that decision. And I don't think a big heat sink will cut it. We have been equipping them with fans. |
👍 Something like the heat sink on the KC705 would be nice.
AFAICT, connecting to PCB ground to mains ground is the most fool-proof solution, which should prevent damage in basically all cases (this is what almost all T&M equipment does), so it's an easy, safe recommendation to make -- I'm not aware of any situation where this could be dangerous/lead to damage, even if it's not often/always optimal from a noise perspective. Maybe change must to should, or even just re-word it to say that the potential difference between all grounds must be limited to safe-levels for all equipment, for example by connecting Kasli to mains ground? Having said that, if you have a better suggestion, then feel free to make it (can you give exact text, please, including values for potential differences you want to recommend). |
@jordens @sbourdeauducq I believe the answer to this is "no", but to double check: we don't think that a bigger FPGA/higher speed grade would help with anything we're doing? e.g. for large Kasli designs, we're not close to being limited by FPGA resources, right? and, the higher speed grade wouldn't ease the CPU timing issues? |
After the siphaser system we introduced, I don't think the 5326 would improve anything significantly, it would just save something like one or two MMCMs in the FPGA since we can use the skew control registers instead. And if we start having it on any board, then we need to support both the 5324 and 5326 in the firmware. This family of chips appears to be exceptionally well-designed (case in point: the 5324 and 5326 are pin-compatible) and bug-free, so it's not a big issue if that has to be done, but why should we? |
Note that the 5326 does not have deterministic latency - all it brings to the table is built-in functionality to increase or decrease whatever random skew it has after locking, and higher loop bandwidth. So, it doesn't help with getting deterministic phase from the external clock input to the ARTIQ outputs. I am in favor of either:
|
Thanks @sbourdeauducq. In that case, here is my suggestion:
Everyone happy with that plan? If so, what's the deadline for this decision? |
Do we need this LED at all? Lock status is accessible from the firmware. I've never used that LED personally. |
Agreed that this is the most fool-proof. The default configuration should protect casual end users as well as isolate the manufacturer from liability. The grounding implementation could be made so that it's easy to modify. Then modifications which might cause harm to body or the board itself are at the risk of the end user. |
Sounds fine, but integrating the WR PLL into ARTIQ doesn't sound trivial; we need to plan for the manpower and development time in the firmware and gateware (in addition to the hardware changes). |
Absolutely, yes. That's an essential part of the cost / benefit analysis. But let's get a concrete proposal to discuss first... |
If we do go down the WR route, I'd still want to keep the Si5324 as well for at least the next version. Obviously, we would want to be able to use Kasli even while the WR gateware/firmware is developed and debugged. |
Is it worth considering switching to a Kintex FPGA and maybe increasing the ram width (cf the DMA issues @cjbe reported) for the next version? Speed seems to be by far the biggest complaint of ARTIQ users, and the fact that Kasli is noticeably slower than the KC705 setups we've used in the past seems like a major step in the wrong direction. I'm all for optimising gateware/firmware, but it seems silly not to start from the fastest hardware platform we reasonably can -- I'm not sure about other users (@dhslichter @dtcallcock etc), but I would gladly pay a bit more for HW if it made my setups faster. |
I'm against that. Lets keep kasli at the simple end. It was well known and acknowledged that it would be slower. Wider ram will lead to board space and power, thermal issues and redesigns. You are obviously free to fund a new device with a bigger fpga though. |
"Simple" doesn't have to equal "slow". I'm not convinced that putting a faster FPGA on there makes it not a simple design.
Really? That wasn't my impression. When I discussed this via email with you and @sbourdeauducq before Kasli v1.0's design was finalised I explicitly asked about whether there would be CPU frequency issues with the ARTIQ, and was told that there wouldn't be. In any case, I think this point is largely irrelevant. What matters is whether, having used this in the lab and knowing what we know now, we still think the current design is the right one for the users, or whether changing the FPGA would be better. Let's not get hung up on why decisions were made.
Firstly: I read that to imply that you are funding work on the next Kasli revision. Is that actually true? Does your contract with WUT specify more than the standard two design rounds? If not, is this something that @marmeladapk and @gkasprow are doing on their own steam without and funding? If so, I don't see why you're bringing up funding here. Secondly: I've worked hard to avoid hardware fragmentation in this project because I (still) believe that's the only way we're going to get a set of high-quality, well supported hardware which is stocked at good prices from a commercial vendor. If we all take the line of "this is my project, so if you don't like it then make your own version" then we're going to end up with a multiplicity of shoddy boards. I think we can be a bit more mature than that and work to find solutions that work for everyone. Thirdly: while you may have funded the original version of Kasli, if you want someone like Creotech to stock it then they have to believe that it's what the users want. So, let's have an discussion that focusses on technical points, rather than shutting things down with "this is my project, go away".
You've made this kind of assertion several times in this project only to be contradicted by @marmeladapk, who is actually doing the design work and has done the simulations. If you've done a simulation or have anything concrete to back up these claims then I'd love to hear about them. But, otherwise, I'd rather hear from @gkasprow or @marmeladapk. tl;dr: if other users don't think a bigger FPGA is worth it (maybe this is worth addressing to the ARTIQ mailing list), or if @gkasprow or @marmeladapk think that it would be too much work/cause other issues, then let's leave it as is. But, if there are simple changes that can make Kasli work better for the users then we should consider them. After all, it's not like the current FPGA on Kasli isn't causing problems right now, and that makes me concerned that in the long run it's not a very good choice. |
Again, I'd love to hear from one of the other groups who are actually using ARTIQ to run experiments with (e.g. @dtcallcock @dhslichter) but my feeling is that the current slowness of ARTIQ makes it a massive pain in the neck for most use cases. Anything that makes it even slower is of very limited interest as far as I'm concerned. |
To be a bit more concrete here, my concerns are things like: if we're struggling to make ARTIQ meet timing on Kasli as it is, what will happen when we want to add features like hard floating-point maths? Will we just have to accept that they aren't available on Kasli because we put a slow FPGA on it? |
they need a backplane connector which has high current contact. |
True. Some of them have screw terminals instead of an IEC. |
Seems like if one gets a proper case (e.g. RatioPac Air), it can be purchased with full EMC compliant stuff that includes contacts from the case to the inside surface of the front panels, and between all the metal parts of the case. If you then ensure that the inside surface of the front panels is chromated, and ground the boards to their front panels, then you should be OK for all of this, assuming that you get a C14 connector in the rear panel and ground it to the chassis. This method also means that someone who wants to change out the grounding to their own specification could do so by choosing a different power supply and using the same ground lug inside the chassis that would be normally used for the ground off the C14. |
If we use any of them, we should ensure that all of those fancy power supplies and backplanes can be made completely optional, to avoid being locked into expensive, overengineered and finicky components such as most µTCA stuff. Let's keep Kasli clean and simple. |
They are one order of magnitude more expensive than the current solution, even when using power adapters from reputable brands purchased from a EU/US distributor. |
This was exactly what I proposed some time ago. I'd rather use resonant SMPS since it offers much higher efficiency, lower size and lower EMI. We use such one in Booster design. |
@gkasprow Yes, you did, but we couldn't all agree on what we wanted. having had a play with Kasli for a while, I think that this is the best way to go. If some users don't want it then we can make it optional. Just make sure it has some enclosure so that there is no exposed mains. |
@dhslichter shouldn't the C14 be installed on the front panel? |
@gkasprow C14 in the front panel is OK, but I am nervous in case (for example) the power supply isn't fully inserted, if you are relying on the panel grounding to make contact. If you do it this way, I would still use a wire and screw contact to chassis for grounding, with the idea that one doesn't remove this front panel with the C14. In general, I propose the following:
The downside here is that return currents could flow either through the front panel and EMC gasketing or through the actual ground return wire on the power connectors for each board. I think this is an unavoidable problem, though. And this way you have backup in case the front panel isn't fully inserted because the ground reference is provided through the return wire still. |
Whatever we do, let's make sure we don't have any exposed mains voltages, otherwise our electrical safety guys will complain. |
I'd rather put the C14 on the front panel to enhance compatibility with different models of 3U subracks (multiple sources, half-width racks, shielded/unshielded, etc.) and reduce machining-related headaches and costs. |
Actually, maybe the front panels should not be connected to ground on the EEMs, and grounding/earthing goes through designated cables (are the EEM cables enough?) inside. |
If you want that, I'd go for a Molex Mini-Fit Jr or similar (i.e. the same kind of thing used in ATX supplies). Way more robust than screw terminals for this kind of thing. |
Fine. |
(If you have a strong preference for something else then I don't particularly mind, just saying how I would do it based on my experience with these kinds of things.) |
We can just have an actual ATX connector, since Kasli is also 12V. |
Yep. |
Migrated to sinara-hw/Kasli#5 |
The text was updated successfully, but these errors were encountered: