Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
Welcome to the next installment in my series about different
ways to use the venerable UART in Virtual Platforms. If you missed the first
two parts you can review the introduction and use case 1, about using xterm in slave mode
for an interactive terminal.
This article explains another way to provide an interactive
terminal. Instead of using the xterm in slave mode we can use a network
connection and the telnet program to connect to a UART and have an interactive
Recall that the UART has a simple byte interface to send characters
into it and receive characters from it. As long we do this, any implementation
is possible to interact with it.
To use telnet as a way to connect to the UART we replace the
xterm we had before with the telnet program as shown below.
As with the xterm, the telnet program is a separate
executable running in its own process. With the xterm we implemented inter-process
communication (IPC) using a series of system calls to send and receive data to
and from the xterm. This time we again provide inter-process communication, but
using a networking socket. The implementation requires a new SystemC model which
replaces the terminal model. Let's see how we can use telnet to add a
connection to a SystemC UART model.
As you can see the flow is very much the same as the xterm
solution; only the implementation of the xterm in slave mode is replaced by a
Below is the implementation of the SystemC method that is sensitive
to characters coming from the UART. It writes those charaters to the network
Below is the implementation of the SystemC thread that polls
the network socket for new characters and upon receiving a character sends it
on to the UART.
There is one additional detail in the code. The readThread()
method doesn't set up the socket communication until the first write to the UART occurs
in the simulation. The idea is that if there are no writes to the UART, then the
interface may not be used at all during simulation, so there is no need to do
anything. The first write to the UART will emit the startReading event and
then the network socket will be setup using a common sequence of socket,
bind, and listen system calls.
In a system running Linux, this first write will come from
the traffic generated by the getty program that is used by
init to open a port and start the login program so users can log in and start a
shell. I will have more on this in the next article that talks about using the
UART for remote debugging with gdb.
One of the configurable parameters of the SystemC telnet
terminal model is the ability to automatically launch the telnet program. This implementation
is different than the xterm from the last article in that it uses the popen
system call to start an xterm which uses the -e option to start telnet.
A screenshot of the automatically launched telnet is shown
This model can also be configured to not launch telnet
automatically, but instead wait for a manual connection from any other machine on the
network. Users can just supply the machine name and port number as arguments to telnet.
A screenshot of the manual connection from another machine
is shown below. In this case I connected to a Linux machine called Pepper on
the Cadence network from my laptop using Windows telnet from the command
Like the xterm in slave mode, there are some tricks to getting the
echo working correctly. This time you will see something called telnetOption
that is a set of characters written into the socket. By experimentation I found
that without this the characters are echoed when typed and the terminal doesn't
work all that well. This gets into the details of the telnet protocol and how
to send commands.
It's too deep for this article, but as always you can dig as
deep as you like into the details of telnet. Here is a table of common telnet
commands. You can see the commands 1 and 3 that are used in
The full details of the code are available in tterm.cpp and
tterm.h. This code is for blogging purposes only, but does work for the
applications I have outlined here. This is another good example of using Linux
system programming to create Virtual Platform models.
Next time I'll cover how this same telnet terminal model can be used to perform
remote application debugging using gdb.