Closed pathfinder49 closed 3 years ago
@hartytp I gather you are in favor of option 2. if it proves feasible?
Broadly, yes. We now have pretty strong evidence that series termination is preferable (gives better SFDR) if it can be done without adding vias near any analog channels.
So, the question is how much work it would take / what compromises we'd have to make to achieve that. Once we know that we can make a decision about whether it's worth it. I suspect that we will end up scrapping the series termination in the end, but let's see what our options are before making a decision.
@gkasprow what options can you see for getting the vias away from the analog channels?
I think we can scatter the termination resistors on both PCB sides and move them away from the CH9 (CH8).
I don't think it is only an issue with termination resistors proximity, but the slot in the PCB. The vias are placed in such a way that they cut the GND plane on L2, L3. The vias have some inductance and the return current is passing under the problematic channel. Of course, there is a solid P4, P7 plane, but the via of C3_9 is connected to this polygon segment.
This hypothesis can be verified by desoldering of C3_9 and moving it to an alternative location
Scattering the vias will help with GND integrity.
Another thing that can be done is the increase of distance between pin 3 of IC5_9 and via DAC_LDACn29. This can be easily done by cutting a piece of IC5_9 pad using a sharp blade. Pin 3 of IC5_9 is a high impedance input and even small coupling is critical.
Yet another place where crosstalk can be reduced is the GND slot placement
If we change the way the track is routed, the return current from neighboring channel won't pass via the via of this channel
This should be fixed in every channel
Once we do the experiments above, we will know more about the coupling mechanisms and what actions to take during the redesign.
I played a little bit and moved most of the resistors and vias away from CH8
It can be optimized further. There is plenty of space to place the resistors properly - much closer to FPGA then they are now.
Great! 😃 The series termination may need to be even further way though. In V1.1 the second row of series termination vias still cause -70 dBmV spurs (a 10 dB improvement over the first row). I have circled the termiantion resistors I mean in the image below.
Of cause this might be improved by a better ground pour arrangement.
There are also some more termination resistors that will need addressing. | The series termination resistors in this image cause significant crosstalk. In paticular, ch17 (ch18 in altium) gives the worst crosstalk to the ch8 (ch9 in altium) analogue output. | I haven't looked at the crosstalk from these series termination resistors. We might need to back them off somewhat, though they may prove to be fine. |
---|---|---|
![]() |
![]() |
Edit: I've taken a quick look at digital to analogue crosstalk into channel 3. Writing to channel 3 causes a -83 dBmV digital spur in its own analogue output. Writing to channel 1 causes a -79 dBmV digital spur in the analogue output of channel 3 (4 in altium) . It's probably worthwhile moving the series termination resistors in the image on the right.
I have a hypothesis that these are not the termination resistors which cause such effect but not properly terminated net segments. In some cases, the termination resistors are placed on the wrong side of the line. It may cause voltage overshoot at the resistor terminal since the first segment of the line sees much higher impedance. Sorry I didn't catch it during the review.
I think I managed to move them all - some cannot be moved because they are already very close to the FPGA pins
Fantastic! That looks very promising 😃 Good call moving more of the digital traces to L8.
Is there also space to move the vias further from the analogue channels? From my measurements I think the ones I've circled below would cause crosstalk.
With the series termination moved, it seems plausible to get ground pour and via stitching between most of the series termination vias and channel 8 (channel 9 in Altium). It would be great if we can find the space for that!
I can try to move the entire FPGA
no way to move the FPGA. I moved some vias and added guard
nice!
I implemented all the changes; I also fixed a few issues with FPGA power distribution network.
I've had a quick look over the changes and this looks great! Definitly a huge improvement 😄
I've got a few nit-picks. I'd do them myself, but I'm only availible from the 14th. I'll list them here for reference.
[ ] These vias seem like they could be moved further from ch8 (altium ch9). More of a peace of mind change in case the guard does not kill the crosstalk.
[x] Probably just aestetic, why not include ground pour here?
[x] It seems like a good idea to fixup the ground via arrangement in every channel. Evidently I gave this too short a look, this is fine.
[x] The version number should be updated. IIRC, there is one on the top and one on the bottom of the board.
in case of vias, the ones on the left side can be moved. But the ones on the right side cannot.
@gkasprow have you finished your work on this?
@pathfinder49 are you okay to have a final review when you return on the 14th? Let's target getting v1.2 sent for manufacture by Friday 18th. Were there any other tests you were planning?
@vnegnev we're aiming to finalize v1.2 next week. Any feedback/change requests before then gratefully received!
@hartyp No major feedback from us - we'll only start on more thorough tests in a few weeks. Length-matching the tracks from the RTIO headers to the FPGA would be nice, but probably best left to v1.3 since our prototype PCB already compensates for the current lengths.
Thanks!
If you do any more characterization work, please do let us know how you get on
It's worth checking if we won't have issues with SSO limit of FPGA. Just run all channels with full frequency and see with the scope how the logic levels look like before the termination resistors.
I've had a play with moving the vias and was able to increase the distance to the analogue channels further.
I've included this and the other changes mentioned above in #79.
Thanks! Is this ready for a final review by @gkasprow
It is
Thanks again for the work on this @pathfinder49 !
@gkasprow can you perform a final review before we send these off to manufacture?
Sure, hold my beer :)
:)
please change the rule priority - the LVDS line should be isolated fom GND, otherwize the impedance will be affected seriously
some cosmetic isues
separate the output signals
improve P1V2 polygon
move away LVDS from I2C
I don't like this noisy 3V3 running under DACs
Move it to the L3 or BOT and route alongth board edge. Like this:
reduce coupling of the output signal and 13V rail
just add local keepout fence or modify the polygon
move the DAC track away from noisy polygon
no justification for GND slot - there are SPI lines below, it must be continuous. Just move the edge
the board revision should ve 1.2 I believe
Other than that, it looks good.
please change the rule priority - the LVDS line should be isolated fom GND, otherwize the impedance will be affected seriously
Which rule do you mean speficically?
the board revision should ve 1.2 I believe
I've already changed this in the two labels i can see on the boards. Are we both looking at the version in my PR?
I'm adding the other changes to my PR #79
@pathfinder49 I mean rules priority. For the moment general clearance has higher priority than diff lines clearance, moreover diff clearance is disabled
I fixed these diff lines clearance
The digital vias associated with the series termination cause significant (capacitive?) crosstalk to nearby analogue circuitry (see #76). This should be addressed in a new revision. Naively, I can see two approaches:
@gkasprow What are your thoughts to expanding the board? Looking at the sparse component and track density on the EEM connector side of the FPGA, it seems like it's possible to move the FPGA several cm towards the EEM connectors. Are there other constraints on the FPGA position space? How much time would such a rework take?
@hartytp I gather you are in favor of option 2. if it proves feasible?