DVT IDE for VS Code SystemVerilog User Guide
Rev. 22.1.23, 16 August 2022

33.1 Flow Integration

DVT IDE for VS Code can be integrated into your development flow in multiple ways and these integrations can be fully automated when needed.

Depending on the infrastructure on which DVT IDE for VS Code will be used, there are several recommended configurations with their pros and cons.

To better understand the following configurations and to easily determine which one is best for you it is important to have an architectural view over VS Code and DVT IDE for VS Code extension.

VS Code isolates the extensions in a separate process called Extension Host. This means that a VS Code running the DVT IDE extension is split in two components:

  • The VS Code UI

  • The Extension Host (where the DVT IDE extension runs)

This distinction is important because VS Code allows you to run the Extension Host on a different machine by using the Remote SSH functionality.

The DVT IDE extension is also split in two components:

  • The VS Code specific component which implements the DVT IDE frontend functionality and runs in the Extension Host

  • The Language Server component which implements the DVT IDE backend functionality (compiling the code, serving information to the frontend, etc) and runs as a separate process. This is the heaviest component in the stack because its memory and CPU requirements depend on the size of your project.

Since the Language Server runs in a separate process in also means that these components can run on different machines.

Here are some of the configurations you can use:

Running locally on a Linux, Windows or MacOS host

The best option for running DVT is to run it locally. It offers the best UI responsiveness and the setup is simple. On the other hand it is not an option when the local machine doesn’t have access to the source code, to the license server, or enough resources to compile your project.

One way to overcome some of these drawbacks is to run it on a development server and use a remote desktop application (VNC, NX, etc.) to see the remote application. The major disadvantage in this case is that the remote desktop application adds latency to the UI interaction and can be quite distracting especially when the network connection between the user’s display and the development server is slow.

Running locally with the Language Server dispatched on a more powerful host in a computer farm

If the previous configuration is not an option due to the low resources available on the local computer, you can configure DVT to dispatch the Language Server process on a computer farm host. This will offer good UI performance, with only some actions being affected by the network performance. The disadvantages are that you need to have access to the source code on the local host and on the computer farm host.

Alternatively this can be combined with a remote desktop application (VNC, NX, etc.) that can be used to connect on a development server where the IDE runs and dispatches the Language Server on a computer farm host where more resources are available. The remote desktop application will add latency to the UI interaction and more latency will be added by the network connection between the extension and the Language Server. This option must be used with care, and it should be avoided over slow networks.

Running VS Code UI locally and using Remote SSH to run the extension on a development server.

This option is a better alternative to using a remote desktop application. The UI can run locally while the extension and the Language Server can run on a remote host which has access to the source code, to the license server, and enough resources to compile your project. Since the UI is local its responsiveness is good but the network connection between the UI and the extension can still slow down some operations. The drawback is that you need SSH access to the development server.