Thunderscope 更新:我的看法:为什么开源更好
Thunderscope update: My take: Why open source is better

原始链接: https://www.crowdsupply.com/eevengers/thunderscope/updates/revving-up-for-production

Aleksa已完成Rev. 5 PCB布局,这是一项复杂的任务,需要付出巨大的努力来优化性能和屏蔽,包括在带弹簧夹的散热器下安装关键组件。不同的接地策略被应用于前端通道以测试衰减器电路的影响。为了解决KiCad在精确匹配PCB各层信号延迟方面的局限性,Aleksa开发了一个脚本来改写设计规则,从而改善了关键信号(如PCIe通道)的延迟匹配。 由于新的中介层设计、KiCad切换以及个人问题,项目进度有所延迟。Aleksa对此负责,并提供了一个修订后的时间表:Rev. 5电路板将于四月底到货,测试将在两周内完成。如果不出意外,开发者版PCB将被组装,并在7月份向支持者发货。之后将进行大规模生产,目标是在9月份完成全部发货。Aleksa将使用GitHub Issues公开跟踪任务,并鼓励大家通过Crowd Supply、Discord、Matrix、IRC或Mastodon提出问题。Rev. 5测试完成后,将发布另一个更新以确认时间表。

这个Hacker News帖子讨论了Thunderscope项目的更新,以及更广泛的开源与专有设计工具的主题,尤其是在KiCad和Altium的背景下。初始帖子重点介绍了为KiCad开发的一个解决方法,用于匹配PCB各层上的走线延迟,这是Altium中 readily available 的功能。发帖人认为这体现了开源的强大之处:无需昂贵的“选项包”即可规避限制。 评论者们就开源的价值展开了辩论,一些人指出了闭源软件的可扩展性,另一些人则强调了修改源代码以满足特定需求的自由度。一些人指出KiCad正在快速改进,并正成为昂贵专有软件的可行替代方案,而一位评论者则讨论了测量高速USB信号的困难。讨论还包括一条关于硬件测试时间表过于乐观 的谨慎评论。总的来说,该帖子探讨了商业软件中开箱即用功能的便利性与KiCad等开源解决方案提供的灵活性和控制力之间的权衡。

原文
Apr 30, 2025

Project update 11 of 11

by Aleksa B

Hi all,
I’ve spent the last month-and-a-half heads down on the PCB layout for Rev. 5…

I didn’t expect it to take that long, but then again this is the most effort I’ve ever put into a PCB design - it just had to be perfect!

High effort silkscreen aside, I’m especially proud of fitting the ADC, Clock Generator, FPGA and all their power supplies under the heatsink. I added spring clips so the heatsink can function as a shield for the whole acquisition section as well. Here’s some work-in-progress pictures from when I first placed everything (left) and at some point into the layout (right).

I also made the four front ends ever so slightly different from one another to test how the cutouts and grounding affect the elusive attenuator circuit. CH1 has a solid pour to all the components, while the other channels do not. CH3 and CH4 have progressively fewer ground plane cutouts than CH2. I’ve also via stitched the front end as I think that may have caused the wobbliness in the frequency response as dropping down a few layers causes the ground reference to change and, without vias nearby, the return current will have a hard time making it there.

The other change in the front end is the (re)addition of a trim cap (C1059). Since the buffer’s capacitance can vary from part to part, we want to trim it to a known level. This capacitance is about 2.4 pF, while variation in it will be sub 1 pF. This wasn’t much compared to the >100pF lower leg of the attenuator in previous designs, but with this new improved design we need to worry about it again. Trade-offs, trade-offs everywhere!

Teaching KiCad a New Trick - Matching Delays

At time of writing, KiCad only understands the length of traces and pins. When length matching, it takes length as a single number added up across every layer. This leads to delay mismatches, as the signals on the inner layers are slower than the signals on the outer layers. When assigning pin lengths, you need to arbitrarily choose a layer to convert a delay value (given by the manufacturer), to a length. This also results in delay mismatches.

I wanted to do this right, just like Altium does, but I didn’t want to have to calculate and add up all the delay values by hand in a spreadsheet. So I made a script to rewrite custom design rules to try to get KiCad’s length matching to be delay matching (including pad delays).

It was only slightly off from KiCad’s reported lengths, so not bad, as we just need consistency from trace to trace, not absolute accuracy. But then, as soon as I added a curved tuning pattern, it all fell apart.

I found out it was miscounting certain segments because of a small math error (normalizing the angle to [0,2*pi] when it should be [0,pi]) and got it working again! Below is the output of the script when tuning the skews on the PCIe lanes.

The rewriting design rules bit doesn’t work all that well given the slight discrepancy with the KiCad reported lengths and the whole delay-to-length conversion just assuming top layer for everything. However, if you just look at the delay deltas, then it’s pretty usable for tuning! In fact, I did all the delay matching on TS with this tool. If you want to try it yourself, I’ve put the script up in its own separate repo.

Next Steps, Accountability, and New Shipping Estimates

Now to address the elephant in the room, we won’t be shipping on time. The new interposer design, the switch to KiCad, and some personal issues all contributed to this. I take full responsibility and am committed to getting this done as quickly as possible while still holding myself and the project to the highest standards. So first things first, what are the next steps?

  1. Hand Build Rev. 5: Boards arrive at the end of April and I expect to get them built within a day or two of receiving them.
  2. Test Rev. 5: This should take no longer than two weeks.

Once these are done, I can roll any minor changes into a Rev 5.1. If there are any major changes needed, however unlikely, I will repeat the above process with a new rev.

Next up,

  1. Get Dev. Edition PCBs Assembled: send the design to a CM and wait a month or so.

  2. Build Test Fixtures and Assembly Jigs: use the time the CM is working on the PCBAs.

  3. Test and Ship Dev. Edition units: these should reach backers in July.

A month after shipping Dev. Edition units (to give time for any last bugs to be reported), we’ll do the same process as above for the rest of the units. We can improve our fixtures and jigs while the boards are out for fab and assembly, and then we should be able to ship in September.

To keep myself accountable, I will be using GitHub Issues to publicly track the tasks left before shipping, so check those out if you’re ever wondering how things are going between updates. Or, you can ask me directly through the project question form on Crowd Supply, on Discord (bridged to #thunderscope:matrix.org on Matrix or #thunderscope:libera.chat on IRC), or on Mastodon!

I will also be sending out another update right after we test Rev. 5, just to confirm the timeline for you all. I’m looking forward to sharing the results of a whirlwind week of testing!

-Aleksa


联系我们 contact @ memedata.com