{"id":31815772,"url":"https://github.com/xilinx/xilinxvirtualcable","last_synced_at":"2025-10-11T09:24:02.359Z","repository":{"id":32049839,"uuid":"35621434","full_name":"Xilinx/XilinxVirtualCable","owner":"Xilinx","description":"Xilinx Virtual Cable (XVC) is a TCP/IP-based protocol that acts like a JTAG cable and provides a means to access and debug your FPGA or SoC design without using a physical cable.","archived":false,"fork":false,"pushed_at":"2025-05-22T13:00:24.000Z","size":89,"stargazers_count":243,"open_issues_count":7,"forks_count":84,"subscribers_count":30,"default_branch":"master","last_synced_at":"2025-05-22T14:22:54.940Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Xilinx.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2015-05-14T16:08:28.000Z","updated_at":"2025-05-22T13:00:28.000Z","dependencies_parsed_at":"2022-09-11T07:52:53.642Z","dependency_job_id":"b0538543-d116-4885-98b6-47987678f949","html_url":"https://github.com/Xilinx/XilinxVirtualCable","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/Xilinx/XilinxVirtualCable","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Xilinx%2FXilinxVirtualCable","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Xilinx%2FXilinxVirtualCable/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Xilinx%2FXilinxVirtualCable/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Xilinx%2FXilinxVirtualCable/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Xilinx","download_url":"https://codeload.github.com/Xilinx/XilinxVirtualCable/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Xilinx%2FXilinxVirtualCable/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":279006756,"owners_count":26084178,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-10-11T02:00:06.511Z","response_time":55,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-10-11T09:24:00.904Z","updated_at":"2025-10-11T09:24:02.354Z","avatar_url":"https://github.com/Xilinx.png","language":"C","funding_links":[],"categories":[],"sub_categories":[],"readme":"# XilinxVirtualCable\n**Description**:  Xilinx Virtual Cable (XVC) is a TCP/IP-based protocol that \nacts like a JTAG cable and provides a means to access and debug your \nFPGA or SoC design without using a physical cable. \n\nThis capability helps facilitate hardware debug for designs that:\n* Have the FPGA in a hard-to-access location, where a \"lab-PC\" is not close by\n* Do not have direct access to the FPGA pins – e.g. the JTAG pins are only accessible via a local processor interface\n* Need to efficiently debug Xilinx FPGA or SoC systems deployed in the field to save on costly or impractical travel and reduce the time it takes to debug a remotely located system.\n\n## Key Features \u0026 Benefits\n* Ability to debug a system over an internal network, or even the internet.\n* Debug via Vivado Logic Analyzer IDE exactly as if directly connected to design via standard JTAG or parallel cable\n* Zynq®-7000 demonstration with Application Note and Reference Designs available in XAPP1251 - Xilinx Virtual Cable Running on Zynq-7000 Using the PetaLinux Tools\n* Extensible to allow for safe, secure connections\n\n# Directory layout\n    ├── dpc                          # XVC 1.1 source code for debug through Debug Packet Controller\n    ├── jtag/zynq7000                # XVC 1.0 source code for Zynq-7000 SoC devices\n    ├── jtag/zynqMP                  # XVC 1.0 source code for Zynq-Ultrascale+ SoC devices\n    ├── mem/versal                   # XVC 1.1 source code for Versal SoC devices\n    └── README.md\n\n# XVC 1.0 Protocol\n```\nXVC 1.0 Protocol \nCopyright 2015-2021 Xilinx, Inc.  All rights reserved.\n\nLicensed under the Apache License, Version 2.0 (the \"License\");\nyou may not use this file except in compliance with the License.\nYou may obtain a copy of the License at\n\n    http://www.apache.org/licenses/LICENSE-2.0\n\nUnless required by applicable law or agreed to in writing, software\ndistributed under the License is distributed on an \"AS IS\" BASIS,\nWITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\nSee the License for the specific language governing permissions and\nlimitations under the License.\n```\n\n## Overview\n\nXilinx Virtual Cable (XVC) is a TCP/IP-based communication protocol that acts \nlike a JTAG cable and provides a means to access and debug your FPGA or SoC \ndesign without using a physical cable. In this document are the general details \nof this XVC 1.0 protocol. For source code examples of this protocol please \nvisit:\n\nhttps://github.com/Xilinx/XilinxVirtualCable\n\nThe XVC protocol is used by a TCP/IP client and server to transfer low level \nJTAG vectors from a high level application to a device. The client, for instance\nXilinx's EDA tools, will connect to an XVC server using standard TCP/IP \nclient/server connection methods. Once connected, the client will issue an \nXVC message (getinfo:) to the server requesting the server version. After \nthe client validates the protocol version, a new message is sent to the \nXVC server to set the JTAG tck rate for future shift operations. \n\nThe shift message is the main command used between the client and the server\nto transfer low level JTAG vectors. The client will issue shift operations \nto determine the JTAG chain composition and then perform various JTAG \ninstructions for instance driving pins or programming a device.\n\nIn summary, XVC 1.0 protocol defines a simple JTAG communication method with \nsufficient capabilities for high level clients, like Xilinx Vivado and SDK \ntools,  to perform complex functions like programming and debug of devices. In \nthis document is a basic description of the protocol. The intent of this \ndocument is to provide a blueprint for users of the XVC 1.0 protocol to create \ntheir own custom clients and servers.\n\n## Protocol\n\nThe XVC 1.0 communication protocol consists of the following three messages:\n\n```\ngetinfo:\nsettck:\u003cperiod in ns\u003e\nshift:\u003cnum bits\u003e\u003ctms vector\u003e\u003ctdi vector\u003e\n```\n\nFor each message the client is expected to send the message and wait for a \nresponse from the server.  The server needs to process each message in the order\nrecieved and promptly provide a response. Note that for the XVC 1.0 protocol \nonly one connection is assumed so as to avoid interleaving locking and \ninterleaving issues that may occur with concurrent client communication.\n\n### MESSAGE: \"getinfo:\"\n\nThe primary use of \"getinfo:\" message is to get the XVC server version. The \nserver version provides a client a way of determining the protocol capabilites\nof the server. \n\n**Syntax**\n\nClient Sends:\n```\n\"getinfo:\"\n```\n\nServer Returns:\n```\n“xvcServer_v1.0:\u003cxvc_vector_len\u003e\\n”\n```\n\nWhere:\n```\n\u003cxvc_vector_len\u003e is the max width of the vector that can be shifted \n                 into the server\n```\n\n### MESSAGE: \"settck:\"\n\nThe \"settck:\" message configures the server TCK period. When sending JTAG \nvectors the TCK rate may need to be varied to accomodate cable and board \nsignal integrity conditions. This command is used by clients to adjust the TCK\nrate in order to slow down or speed up the shifting of JTAG vectors.\n\n**Syntax:**\n\nClient Sends:\n```\n\"settck:\u003cset period\u003e\"\n```\n\nServer Returns:\n```\n“\u003ccurrent period\u003e”\n```\n\nWhere:\n```\n\u003cset period\u003e      is TCK period specified in ns. This value is a little-endian \n                  integer value.\n\u003ccurrent period\u003e  is the value set on the server by the settck command. If \n                  the server cannot set the value then it will return the \n                  current value.\n```\n\n### MESSAGE: \"shift:\"\n\nThe \"shift:\" message is used to shift JTAG vectors in and out of a device. \nThe number of bits to shift is specified as the first shift command parameter \nfollowed by the TMS and TDI data vectors. The TMS and TDI vectors are \nsized according to the number of bits to shift, rouneded to the nearest byte. \nFor instance if shifting in 13 bits the byte vectors will be rounded to 2 \nbytes. Upon completion of the JTAG shift operation the server will return a \nbyte sized vector containing the sampled target TDO value for each shifted \nTCK clock.\n\n**Syntax:**\n\nClient Sends:\n```\n\"shift:\u003cnum bits\u003e\u003ctms vector\u003e\u003ctdi vector\u003e\"\n```\n\nServer Returns:\n```\n“\u003ctdo vector\u003e”\n```\n\nWhere:\n```\n\u003cnum bits\u003e   : is a integer in little-endian mode. This represents the number \n               of TCK clk toggles needed to shift the vectors out\n\u003ctms vector\u003e : is a byte sized vector with all the TMS shift in bits Bit 0 in \n               Byte 0 of this vector is shifted out first. The vector is \n               num_bits and rounds up to the nearest byte.\n\u003ctdi vector\u003e : is a byte sized vector with all the TDI shift in bits Bit 0 in \n               Byte 0 of this vector is shifted out first. The vector is \n               num_bits and rounds up to the nearest byte.\n\u003ctdo vector\u003e : is a byte sized vector with all the TDO shift out bits Bit 0 in \n               Byte 0 of this vector is shifted out first. The vector is \n               num_bits and rounds up to the nearest byte.\n```\n\n# XVC 1.1 Protocol\n```\nXVC 1.1 Protocol \nCopyright 2015-2021 Xilinx, Inc.  All rights reserved.\n\nLicensed under the Apache License, Version 2.0 (the \"License\");\nyou may not use this file except in compliance with the License.\nYou may obtain a copy of the License at\n\n    http://www.apache.org/licenses/LICENSE-2.0\n\nUnless required by applicable law or agreed to in writing, software\ndistributed under the License is distributed on an \"AS IS\" BASIS,\nWITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\nSee the License for the specific language governing permissions and\nlimitations under the License.\n```\n\n## Overview\nIn addition to XVC 1.0 capabilities, XVC 1.1 supports the \"mrd\" and \"mwr\" messages \nwhich can be used to read/write debug addresses.\n\n## Protocol\n\nThe XVC 1.1 communication protocol consists of the following five messages:\n\n```\ngetinfo:\nmrd:\u003cflags\u003e\u003caddress\u003e\u003cnum bytes\u003e\nmwr:\u003cflags\u003e\u003caddress\u003e\u003cnum bytes\u003e\u003cdata\u003e\nsettck:\u003cperiod in ns\u003e\nshift:\u003cnum bits\u003e\u003ctms vector\u003e\u003ctdi vector\u003e\n```\n\nFor each message the client is expected to send the message and wait for a response from the server.  The server needs to process each message in the order received and promptly provide a response. Note that for the XVC 1.1 protocol only one connection is assumed so as to avoid interleaving locking and interleaving issues that may occur with concurrent client communication.\n\n### MESSAGE: \"getinfo:\"\n\nThe primary use of \"getinfo:\" message is to get the XVC server version. The server version provides a client a way of determining the protocol capabilities of the server.\n\n**Syntax**\n\nClient Sends:\n```\n\"getinfo:\"\n```\n\nServer Returns:\n```\n“xvcServer_v1.1:\u003cxvc_vector_len\u003e\\n”\n```\n\nWhere:\n```\n\u003cxvc_vector_len\u003e is the max width of the vector that can be shifted \n                 into the server\n```\n\n### MESSAGE: \"mrd:\"\n\nThe primary use of \"mrd:\" message is to read an address. \n\n**Syntax**\n\nClient Sends:\n```\n\"mrd:\u003cflags\u003e\u003caddress\u003e\u003cnum bytes\u003e\"\n```\n\nServer Returns:\n```\n“\u003cdata\u003e\u003cstatus\u003e\"\n```\n\nWhere:\n```\n\u003cflags\u003e ULEB128 bit field for future flag use\n\u003caddress\u003e ULEB128 starting address for memory read\n\u003cnum bytes\u003e ULEB128 number of bytes to read\n\u003cdata\u003e byte vector of data read\n\u003cstatus\u003e byte return code where a non-zero value indicates an error\n```\n\n### MESSAGE: \"mwr:\"\n\nThe primary use of \"mwr:\" message is to write at an address. \n\n**Syntax**\n\nClient Sends:\n```\n\"mwr:\u003cflags\u003e\u003caddress\u003e\u003cnum bytes\u003e\u003cdata\u003e\"\n```\n\nServer Returns:\n```\n“\u003cstatus\u003e\"\n```\n\nWhere:\n```\n\u003cflags\u003e ULEB128 bit field for future flag use\n\u003caddress\u003e ULEB128 starting address for memory write\n\u003cnum bytes\u003e ULEB128 number of bytes to write\n\u003cdata\u003e byte vector to write\n\u003cstatus\u003e byte return code where a non-zero value indicates an error\n```\n\n### MESSAGE: \"settck:\"\nSimilar to XVC 1.0\n\n### MESSAGE: \"shift:\"\nSimilar to XVC 1.0\n\n## Note\nXVC server 1.1 for Versal performs reads and writes (*mrd* and *mwr*) as multi-word transactions. On some platforms performing accesses unaligned to 64-bits addresses may throw \"Bus Error\". In such cases, uncomment *ENABLE_SINGLE_WORD_RW* definition in *xvc_mem.c* to perform single word (32-bits) read/write transactions.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fxilinx%2Fxilinxvirtualcable","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fxilinx%2Fxilinxvirtualcable","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fxilinx%2Fxilinxvirtualcable/lists"}