Kontron D3713-V

Info: KONTRON EUROPE GmbH

SLO ⇒

After AMD’s phenomenal Zen series rise, we have finally got an opportunity to see their modern brethrens in versatile compact machines and Kontron, DFI and others that have brought small, frugal but powerful industrial Ryzens into professional applications, too.

We finally have a chance to see economic, small form-factor, low power machines that can serve in very wide gamut of roles, while delivering significant punch, too.

Kontron was so kind to send us their implementation of Ryzen 1807B SoC on mini-ITX board, and we can say straight away that it was pure joy to play with. We can see it in everything from small servers, purpose built machines with (several) LCD panels, kiosks, various industrial controllers, small servers, even office desktops or space constrained machines for specific uses.

1. Board

Even though whole definition of SoC board means using whatever the SoC offers and simply routing it to a connector, it is refreshing to see those small Ryzens giving everything they’ve got.
Well, most, at least. Ryzens have hidden goodies like 10G Ethernet MAC and similar things, but using them would mean losing precious PCIe lanes, so most of that is left inactive in SoC.

Since available PCIe lanes are at premium, Kontron had to do some juggling and compromises in order to get all goodies onboard.

D3713-V shows really focused effort on »function over form« and efficiency, down to the details like lack of »white silk« on board – familiar element designations with white ink. In order to cut costs, all markins are done on top and bottom copper layers and solder mask has been cut-out over the letters. They are cleverly using the fact that copper is tinned and so appears silver, at least on exposed parts. Nice, as long there is space for such marks.

So, we have:

• mini-ITX format board with soldered SoC – Ryzen Embedded V1807B
• Very cool DC 8-36 V input. Board generates 5V and 3V to power small loads ( SSD, HDD etc). Declared max power input is 130W, which, given the APU’s max TDP leaves by my estimate 30-40-ish W for added devices.
• Ryzen Embedded V1807B SoC:
  • 4 CPU cores /8 threads @ 3.35-3.8Ghz
  • GPU: Vega 11(11 computing units, 1300MHz)
  • TDP:35-54W
  • Security Processor
  • 2MB L2 + 4 MB L3 cache
  • junction temp range 0-105°C
  • dual channel DDR4 memory interface, ECC support
  • 4 graphic outputs, each up to 4096*2160 ( HDMI 2.0b / DP 1.4)
  • HW video en/de/code up to 4K@60Hz
  • 16 PCIe3 lanes
  • interfaces: 1xUSB2, 1x USB3.1v1 4 xUSB3.1v2, 10G Ethernet x2, SATA x2 (not all are routed out on board)
  • low speed interfaces: I2C,I2S, GPIO, SD, SPI, UART etc (not all of them are on board)
• Option for other SoCs from »V« and »R« series
• TPM2 on SoC
• 2 x SO-DIMM DDR RAM slots for unbuffered ECC or normal memory up to 3200MHz
• 4 * Displayport 1.4 outputs
• eDP V1.3 graphic output ( if used, excludes one DP output)
• dual channel 24-bit LVDS output (deactivates one DP output) + backlight control signals for direct panel attachment
• 2 * Gig-Ethernet NICs: Intel i210 + Realtek RTL8111H
• 2 * SATA 600
• 1 * PCIe3 x 4 (main slot), 1* mini-PCIe
• 4 COM/RS-232 ports, 2 on back panel, 2 on board, one of them can also do RS-422/485
• PCIe3 x 4, miniPCIe, M.2 Key M + M.2 key B. Available lanes vary WRT to SoC chip and extension combos. PCIe slot shares lanes with M.2/key-M. SATA1 conenctor shares lanes with M.2/key-B SATA lines.
• 3 level watchdog (BIOS POST/BIOS boot/OS)
• GPIO pins
• 2 PWM controlled ventilator connectors
• built-in TPM2 functionality and a slot for discrete TPM2 unit
• onboard vertical USB3 socket for USB stick as a cheap boot/workspace option

D3713-V board is in classic mini-ITX form factor that almost exactly fits in familiar PC casings. Only »detail« is APU cooler. Kontron has supplied us with their copper-aluminum cooler & vent. It’s perfectly useable for demonstrations and test, but at 6cm height you will probably be looking at some other, custom solution. Since APU is directly soldered onboard, heatsink mounts on the board don’t follow anything that you might be familiar on standard PC boards and compressed layout will probably prevent you from retrofitting some off-the-shelf product.

Board is meant to be used as a part in final product and one is expected to take care of the the enclosure, heatsink, additional connectors etc. At least in situations, where no standard parts fit. I have a feeling that for small series product one could adapt low profile copper cooler for servers for this purpose. Actual implementation ofcourse depends on environment, airflow and useage. APU can be configured for TDP from 35W to 54W. Board was obviously meant to be useable in passively cooled systems if needed.

Kontron’s cooler has footprint of roughly 7x7cm with the vent of the same dimensions on top and height of about 6,5cm. It is standard size with a vent that isn’t problematically loud within any load that we could throw at the machine. One could use larger cooler, but it would have to be tailored to available PCB real estate. Board certainly allows for a cooler that would enable it to fit low-profile mini-ITX case, with not much headroom over vertically mounted SO-DIMM RAM slots.

D3713-V is choke full of I/O, which forced mounting components on the bottom side, too. Usually one can see such a thing on conventional mini-ITX boards that have extra M.2 sockets on the bottom side. Here we can see PCIe switches, rectifiers and even significant functions on the bottom side. Normally this wouldn’t be an issue within standard PC enclosure, but in cramped spaces of space constrained applications this might be worth noting.

Another significant feature is simple DC power input. Board has classic »jack« socket that can accept pretty much any standard »power brick« and it has locking thread. Declared maximal power load is 130W, which, given SoC max TDP of 54W should comfortably leave 30-40ish Watts for anything one might wish to power with 12/5V (SSDs, HDDs, DVD etc). There is internal power connector also.

DC input on such board is nothing new even on PC motherboard. But D3713-V has input range from 8-38V, which means that internal VRM can do step-up or step-down conversion, as needed.
I’ve had intention to measure VRM’s efficiency, but now this seems futile.
VRM is cool. It never gets appreciably hot even without a heatsink on it, which means there isn’t much to be seen there. Most of the power used ends up in SoC anyway.

NICs are another peculiarity. Board has two interfaces, but Kontron chose to mix Intel and Realtek bu using one from each. One would expect to see either cheaper (Realtek) or better (Intel) solution, not mix of the two.
On top of that, each NIC chip reserves it own PCIe lane. I think this would be great opportunity to see 4xNIC GiG-e chip hanging on one PCI-e lane. Or better yet, use one of those new-gen chips that can also do 4x o 1G or even 2.5G Ethernet.

One PCIe3 lane should be enough to cover most of that. This would present some great added value in the same space and left user with extra PCIe lane to be used elsewhere or swapped as needed.

D3713-V has main PCIe3x4 connector that is ideal expansion point for various uses.
I tried it with double Gig-Ethernet cards so that I could try it as multi-homed server/firewall. Works great, as expected.
For some uses cheap 2.5G/5G/10G NIC might be great option. Or perhaps simple I/O (couple of serial ports, parallel port), measurement or data acquisition card might be used.

mini-PCIe port is meant for Wi-Fi+Bluetooth combo card, but i’ve discovered that there are small 2xCOM+LPT cards that are simply great upgrade options of scenarios that need a bunch of serial ports. Unfortunately, they need a bit more space and I wish that Komtron managed to find it somewhere.

Finally, we have plenty of what looks like bunch of simple I/O signals for backlight control. I suspect one could use also those as GPIO when LVDS output is unneded or at least when display doesn’t need backlight control.

On top of that, there is currently empty connector footprint at the edge. Kontron says it’s for possible PoE module. On boards such as this I/O lines are at premium and I suspect that they have alternative uses for driving various on-board peripherals. On such boards I/O signals are often used for simple stuff and old LPT would be great addition for such stuff. Most SuperIO chips support the protocol and it can be used to either wiggle individual pins or use whole interface for bidirectional byte-wide data transfer that needs minimal CPU intervention, can be controlled quite precisely if needed and can talk to simplest electronic at the other side. If SuperIO’s interface that could implement LPT is used for this, it would be nice to offer it for apps that don’t need PoE but could use something like IEEE-1284.

It wouldn’t surprise me if one could use existing PWM vent control (there are two outputs) in a passive system to control vents for other parts of the system etc. Everything on board can be put to a good use.

D3713-V is so choke full of interfaces that it looks like an agressive connector advert.

TPM2 functionality seems to be implemented with SoC with parts coded in FLASH on the board as well as a connector for discrete TPM2 module as an option. All TPM2 documentation I’ve seen lists former option as inferior as the SoC presents much greater attack surface.

OTOH, discrete TPM2 module cost $10 or so and are usually made by names that user don’t know anything about. So I guess the final choice depend on circumstances and threat model.

Finally, we have watchdogs. On normal desktops they tend to be peripheral feature. On SoCs such as this, they are much more important. I couldn’t discern from Kontron’s materials whether they are implemented in SoC or SuperIO chip, but as long as they are available and implemnted in actual hardware, I guess that either are fine. Details are in Technotes for the board, which are at the moment inaccessible without a password.

Last but not least, since there are already quite a few passive switches/multiplexers for high speed signals, I wonder if they could have made a few more combinations so that we could have 8,12 or 16 PCIe lanes in main PCIe connector and switch them back to it from M2 slots (both M- and B-key), miniPCIe etc when they are not used.
In such applications we could have available full PCIe3x16 on the main slot, which could be nice for more than few applications. And it would be nice to have matching option for PCIe bifurcation in UEFI.

Kontron says that this would bring up signal quality problems and/or extra layers, but for such board customer would be expected to cover such costs. Board should effectively expose what SoC has to offer. Ryzen Embedded is limited WRT PCIe lanes and PCIe transceviers churn power and pins. Also, mini-ITX isn’t all that big, so one would think that extra costs for two layers wouldn’t be all that much…

Another quibble goes to COM ports. Only COM2 has an RS-422/485 and full/Semi-duplex option. COM ports are obviously meant to be used on such boards and RS-485 etc are often used. Why not offering those options on all the ports?

It would appear that current board version is at 4, while I have PCB version 3. So, when making a purchase, check for the board version and potential issues.

2. FIRMWARE – UEFI

D3713-V uses customized version of Aptio ® V UEFI. It contains all the options that one expect from such setup. Periphery can be configured and switched (RS-232/422/485 for COM2, SATA lines between M.2 and SATA 1 etc). It also contains varous security functions, including control of the built-in TPM2 functionality. I had a board with UEFI version 1.0.0

Naturally, there is not much to see WRT performance settings/tweaks, memory timings etc on a board like this. Only setable parameter is SoC TDP and that is in the range of 35-54W, as intended by AMD.

That being said, I do miss RAM setting tweaks. By that I don’t mean timings for memory overclocking etc but setting address swizzling, bank interlace etc. For some applications it might be optimal to set both channels so that they follow each other in memory map and so that CPUs can use one DRAM controller for their access and let GPU and display refresh hang on the other DRAM controller.

In other cases, it would be better to have them »striped« – interlaced with certain block size for greater aggregate bandwidth. X86_64 has wuite a few MSR registers for such things.

That being said, I’ve noticed quite a few bugs and quirks. From what I can hear, that is not all that unusual in UEFI world. 

I had some problems with my active DP-DVI converter, various UEFI settings and periphery etc. For example Samsung’s NVMe M.2 »970 EVO« works perfectly in Ryzen system, but on D3713-V it worked with only 50% speed. After sniffing around, it became apparent that the system uses just two PCIe lanes for communication. Which is a bummer, but it’s probably just a UEFI glitch.
These were fixed with newest UEFI version 1.3.0.

Also one note: UEFI has an option of setting the amount of RAM that should be reserved for GPU operations. By default, it is set to »auto«, but it looks that for my setup UEFI has chosen to set it up somewhere around 256-512MB. Setting it to 2GB improved things significantly while still preserving most of my system RAM.
With app that calls for significant GPU perfomance, it seems best to set this manually.

I also really wish that there would be an update that would enable resizable BAR support. As of UEFI version 1.3.0 (latest available at the moment), this is still absent.
For historic reasons, »BIOS« sets window into video memory to just 256MB, which forces configurations with more than that to move that 256MB window across the area as needed. This is nowadays unnecesary anachronism and AMD has just recently patched drivers to make use of that feature, but BIOS has to expose it to OS to be used.
Speed boost can be significant and especially welcome on APU systems that have unified memory in the first place.

Also, as said before, along with hardware support for more extensive PCIe lane switching between main PCIe port and peripherals, it woud be nice to see full UEFI support for this, with bifurcation of main PCIe slot into several x4 ports.
At least, if it is technically feasible within given constraints (lane signal degradation, board layer count etc).
Perhaps it is to come with new generation of Embeddded Ryzens?

3. Real life performance

We had an intention to test this unit for standalone application on custom tailored Linux system. Since we are publishers, we thought about stretching its Displayport outputs and emplying it as a demonstration unit on fairs, presentations etc.

But COVID restrictions have obliterated fairs etc, so these plans were hopelessly delayed. In the meantime, we got to try it in various on-the site roles, from small server, firewall, router to an office and presentation machine.

I thought about posting some benchmark results, but they don’t have a good use here. It’s just a data point with a given, known parameters that is somehow representative for user’s case. But D3713-V is supposed to be used all over very wide range of applications. Doing thousand benchmarks across it would be suicidal and pointless. Board is practically launching ramp for this SoC- Ryzen Embedded V1807B.

And Ryzen is carbon copy of any Ryzen APU in this line, with a bit of TDP tweaks. If you want to know what it can do, look at the things like mobile platforms that contain 3700U. This is basically the same thing, albeight with a bit higher TDP and things like PSP (Platform Security Processor) and ECC RAM support.

Unfortunately, we hadn’t ECC SO-DIMMs available, so we’ll have to take Kontron’s word for ECC support. Even though the thing is capable of using 3200 MHz sticks, we used 2400MHz ones (2* 8GB-2400MHz) and D3713-V performed admirably. With 4 4K@60Hz DP monitors attached.

With my stumbling around with UEFI settings and variables I also didn’t get around to test setting Linux IMA with TPM2 root of trust. I’m new to TPM2 with Linux, so I’ll have another take on it soon, now that I have new firmware.

I did install TPM2 libraries and managed to make a first few steps, confirming that TPM2 units does respond to library calls, but haven’t had the time to get much further than that.

We have installed Gentoo on the board and put it through paces of various use patterns. Whole time, SoC saw significant loads during intended use interspersed with intensive package compiling and it performed without a hitch.

I didn’t expect to see something with this »thin« TDP, being able to run Firefox, Libreoffice (both with many tabs/documents opened and pages with heavy JS), movie and couple of YT videos all while feeding 4x4K monitors and recompiling thousand or so packages in 8 threads working this nicely, quietly and efficiently.

That being said, there are a few quibbles. IOMMUv2 functionality seems to be missing. Latest kernel 5.12 reports is as »unavailable«. IOMMUv1 seems to be working fine, though. Up until recently, Freesync did not work on V1807B, but this was a AMD Linux driver issue.

V1807B in this thing manages to shoot above my expectations constantly. No one expect to be able to use it with the latest games, but frankly, I am constantly surprised to see it working so fluidly during work, even without 3D stuff. Picture generation alone for 4K@60Hz takes around 2GB/s, so that 8GB/s for four displays. Peak transfer rate of two 2400MHz SO-DIMMs is about 38GB/s in dual channel configuration.

Real life values are probalby singificantly lower, depending on traffic. Just fluid 2D work probably needs 2x that, which means that in graphic heavy operations we GPU parts eats up to 16+8 = 24G/s. Which leaves 14GB/s to CPU cluster at best. So, even though it works fine on 2400MHz sticks, use 3.200MHz. Don’t skimp on RAM. Price difference is negligeable.

I did use Wayland instead of X11, which does make effort to minimize unnecessary data copying and spare the bandwidth (which is especially great for APU systems like this), but still. Even on Wayland, V1807B does make great use of what it has available.

GPU is decent enough for few Linux games that I cared to try just to see what it can do and it certainly delivers. It also works great for any application with modest OpenGL needs.

With any less demanding setup, this thing shall perform efortlessly.
It can do great job also as a small box server/firewall etc, but I think it’s at it best in mixed roles – compact machines that need to perform a bunch of services while running full blown GUI and applications on it etc.

Even though NIC are different, I did teamed them up as a pair and got transfers as expected for a pair of Gig-Ethernet NICs. That being said, explicit teaming doesn’t seem to be needed anymore. Both NFS4.2 and Samba can detect multiple paths to server share and use them efficiently to share the traffic between them.

Final thoughts

AMD Ryzen family has brought much needed winds of change into x86 world. EPYC and ThreadRipper are formidable, Ryzen line is very effective in the mainstream and Embedded lines have brought new levels of performance at given cost energy constraints into small machines.

SoC boards used to be esoteric lines that were never afforded or even looked at by mere mortals. They were unreachably expensive and their performance was underwhelming for most casual uses. D3713-R/V seem to be a big step toward bringing classic desktop performance into that world, while keeping critical special functions as PSP, ECC etc. No one needs such systems to compete with beefiest deesktops in raw performance, but it certainly helps if they can perform well enough that the OS and applications don’t need extensive rework just to fit them into embedded space.

D3713-V hits that target straight in the center. Yes, it had some »BIOS« snags, but frankly, I’ve never saw UEFI without them. And every snag I had seem to have been fixed. I can’t vouch for deep UEFI workings, though.

But bugs in UEFIs in general aren’t unheard of anyway…

I can totally see such machines in many applications even in non-industrial space.

Even more so these days, when GPU and CPU prices have skyrocketed due to COVID and cryptomining. Even a simple APU might cost you close to what Kontron wants for the whole board.

Only things left on the »wish list« for me are:

• access to existing documentation
  It can be at times frustrating. When dealing with manufacturers of some product, one usually expects free access to technical documentation. With this kind of products end users often have service facilities and product do get to be customized and tweaked to fit in end product. Which means that service documentaiton would be nice to have ( schematics, BoM, PCB with element designations, maybe chip content for programmable components or URL fo their availability etc.)
• Open documentation
  I still remember using small PC embedded PC from PCEngines. It was small and really slow, but really compact, relatively cheap machine and all the documentation that user might want was freely available.
  Even schematics. Which made many things so much easier and has tremendously increased usability of the system. It was much easier to make modifications and even service the system in predictable, cost-effective, safe way. Kudos to designers laying down PCB of D3713-V/R, but the rest of the design is hardly a rocket science. As said before, whole board is mostly platform for V1807B SoC. There seems to be no harm in opening that part of the documentation for free access.
• Open source firmware
  AMD has announced that they plan to open the firmware bits and associated documentation for Ryzen lines and not long ago we had a news about first open-source Coreboot implementation of such systems. It would be really nice to see some of that work reaching this world. It wouldn’t be the first time, either. PCEngines machines had an open-source BIOS versions for years. This could alleviate many problems and snafus with UEFI and put additional tools and controls into users hands. There are plenty ways for things like CoreBoot/LibreBoot to be customized and tweaked to meet individual needs.