A Better way to Connect: TCF and Simics
How do you actually connect an integrated development environment or a debugger to a target system? This question is more complicated than it might seem to the uninitiated outsider. Traditionally, a range of protocols have been used to connect the development host to a target, most of them vendor-proprietary, and often specialized for a particular purpose (such as debug, downloading code, or uploading profile data). However, there is a better alternative available today, the open-source TCF, Target Connection Framework. The TCF is much more than a debugger connection. Based on decades of industry experience as to what you actually need to do with a target, TCF combines everything on a single connection: analysis, testing, configuration, control, provisioning, inspection, tracing, debugging, and anything else you might think of. Simics is making good use of TCF to simplify the connection between the Simics runtime engine and the Simics Eclipse-based GUI. In this blog post, I will go into how TCF is used with Simics and what it has enabled us to do that would have been very difficult without the TCF.
First, we need a little background on TCF itself. The TCF is a project in Eclipse, with contributions from Wind River, Xilinx, and others. The TCF protocol is service-based, and each target exposes the services that it supports to the host. The host can then activate the appropriate functionality, based on what the target reports. In this way, there is no need for the host to know very much about the target a priori, as all its capabilites are reported dynamically after a connection has been setup.
Anyway, on to Simics and TCF. Given what TCF is, how did we use it with Simics?