Since the close of the campaign, the NeTV2 PCB design has gone through some minor revisions in preparation for full production status, including:

• Beefed up 1.0 V regulator. This voltage powers the core FPGA fabric
  and block RAM domains, and needed to be amped up in case a developer
  decides to go nuts and use every last bit of a 100T FPGA's logic
  capabilities.
• Beefed up 5.0 V regulator. The 5 V domain was originally designed to a
  10 watt power envelope; however, this needed to be increased to
  accommodate the 100T FPGA's potentially higher power draw. The
  re-design was also necessitated by the phase-out of the original
  buck regulator; the aging design was using parts that were
  increasingly hard to source. The new design, based on the TPS54327,
  maintains the same wide input voltage range (allowing the system to
  be powered off of everything from 2-3 lithium cells to an automotive
  mains), adds 50% to the mainline power capacity while solving a
  potential EOL issue on the supply chain.
• Direct support for fan control was added. Again, the higher power
  consumption of the 100T indicated a fan for improved heat
  dissipation.
• Minor improvements to decoupling and trace routing.
• Rework of EMI shielding architecture – improved EMI performance at
  the expense of potentially greater susceptibility to ESD events
  (non-damaging susceptibility: an increased risk the device would
  reset if zapped with several kilovolts).
• Swap-out of DDR3 parts from Micron to Samsung. Changes in
  global trade policy have made it very difficult to source US-made
  Micron parts in China, therefore the design has migrated to
  Korean-made Samsung DDR3 parts.

Of all the modifications made, it turns out the last one was the most difficult and problematic. While all DDR3 parts are built to JEDEC standard, they use fundamentally different circuit implementations that affect subtle analog issues around timing and impedance control. Small oversights that we got away with on the Micron parts turn out to be a big deal for the Samsung parts. This is not an indictment of the Samsung parts — I suspect the inverse would be true as well if our designs were originally tuned for Samsung and then migrated to Micron.

One of the more fun bugs caused by the DDR3 part swap was that the system would run stably only when the FPGA was hot (above 65°C); below that, the DQS calibration sweep had "holes," rather than a single transition cliff. After a couple weeks of bisecting the litedram github repository and poring over mode register contents, I figured out that basically the board specific tuning parameter defaults were set up for driving a dual-rank DIMM system – a heavily loaded, multi-drop system with long traces – and that this overdrove the lightly loaded, short-trace implementation of NeTV2, causing excess noise and interference. Fortunately this could all be fixed with modifications to the firmware and FPGA design. This also means we can draw an arc connecting Trump’s trade policies to pull requests on the Litex code base!

A lot of time was also spent iterating over the HDMI jumper that runs between the Raspberry Pi and the NeTV2. Originally, the design had called for a flex PCB, thinking that the flex PCB would be necessary for accommodating mounting tolerances. However, initial EMC compliance testing indicated that there is no way a two-layer flex PCB could pass FCC/CE emissions standards. The flex PCB design called for a coplanar waveguide and the nature of the ground routing did not confine the signal sufficiently, causing it to fail FCC/CE standards. So, back to the drawing board – after about three iterations through a 4-layer rigid design with microstrip differential pairs and some tuning resistors, I had arrived at a design that meets both electrical and regulatory compliance; and it turns out my fears of mounting tolerances were much overblown, a rigid PCB works just fine.

That was about a month and a thousand dollars down the drain. It’s a little depressing to spend so much effort on that detail, because I know the first thing users are going to do is plug in a crappy HDMI cable that lacks proper shielding … and that act alone will cause the total system to go out of compliance by a factor of 10, easily (and no, spending more money on HDMI cables doesn’t mean you’re getting a "better" HDMI cable, just a better-looking HDMI cable; it’s just so easy to cheat on the shielding it feels like everyone does). But it’s too hard to explain to lawmakers why the rulemaking and enforcement process is just so broken, and so precious time and treasure is wasted checking boxes just to please The Man’s arbitrary rules.

This also means that all users who backed the “Custom HDMI Flex Jumper” will instead be getting a rigid PCB jumper. It is functionally superior to the original flex PCB concept in just about every aspect.

Firmware

On the firmware front, I continue to be impressed with the competence and engagement of the Litex/Migen community. Since the project started, core primitives, especially litedram (thanks Florent!) have been greatly upgraded, and the on-boarding experience for new users has also been streamlined (thanks Xobs!). I find myself spending most of my firmware development time just keeping up with the latest commits. Normally I would find this annoying, except the quality of the commits are so good it feels more like receiving gifts rather than regression testing patches. I do hope, however, that eventually the community slows down once it hits the “good enough” point so we can tag a stable release for users more interested in running applications than maintaining software.

For intrepid users who want to start building their own firmware, check out the official Alphamax NeTV2 FPGA repository. Xobs did a great job re-working the on-boarding experience and smoothing out some of the pricklier parts of a Python-based dev environment, and we’d appreciate any early feedback about difficulties encountered installing the toolchain on various OS configurations. I also highly recommend using the latest Vivado toolchain – it seems the latest 2018.2 toolchain reduced my build time from about 25 minutes to 8 minutes compared to my previous 2017.3 toolchain install.

As for the out-of-box experience, I’ve settled on using MagicMirror as the default UI. The black-background theme makes compositing seamless, and there are tons of great plug-ins for it. Out of the box, NeTV2 will be configured to tell you the time, statistics on the HDMI feeds, inform you where to access Magic Mirror docs and code, and rotate through a selection of news headlines, assuming you’ve configured the Wi-Fi. Of course, users who have developed their own code bases (e.g., legacy NeTV web pages) can also install and run them as an alternative.

With the out-of-the-box user experience pretty much finalized, most of what remains on the firmware is regression testing with dozens of cable + video source/sink combinations to try and capture any quirks that could hamper a smooth out-of-the-box experience. Furthermore, once the first batch of hardware has gone through SMT, I will probably take a full month (at least) to spot-check samples from the production lot to confirm natural material variances don’t cause regression problems on the firmware. One of the downsides of the Litex/Migen code base is that it’s not official Xilinx IP, and I have found it to be a bit brittle at times accommodating all the real-life variations found in production hardware. Xilinx gets the benefit of internal documentation and institutional knowledge of where their FPGAs are brittle (especially on the analog bits), while the Litex/Migen community has to stumble through the dark bumping into walls. The good news is that so far I’m running a bit ahead of schedule, so I can afford the luxury of bumping into a few walls, thereby saving the userbase of having to crash into any significant walls post-shipment.

Next Steps

Now that the design has reached PVT readiness, steel tooling for the injection molds have been ordered, and the full suite of parts for mass production are being prepared. Hopefully SMT should conclude in a couple months, which means I have to get super-busy preparing the production tester. This is a fairly complex product, so the production tester is likewise going to have to be quite complex. I will of course be using Xobs’ excellent Exclave tester infrastructure, but this is going to require more than a bed of nails to run the full test – it’s going to take some serious effort to build this tester correctly. On that note, I’ll wrap up this update and get my nose back on the gindstone!

Thanks to all the backers for making this happen, and patiently waiting things out as I work through all the validation and certification details. It’s a ton of work, but hopefully it’ll all be worth it in the end.

Happy hacking,

-b.