Hello,
I was wondering if there is someplace to get the boundary scan files for the Jetson AGX. Need this to use the JTAG functionality of the chip. I know before someone linked to an application document but I am speaking about the .bsdl files itself.
(Apologies if I’m not super clear. New engineer learning the ropes).
Thanks!
It’s not released yet. Will update to DLC once available.
Bummer. Thank you for the quick response
Should have followed up earlier but is there an ETA for release?
No accurate ETA yet. The doc is in some process for release, will be uploaded to DLC once available.
Hi @Trumany I filed a ticket for this already, but figured I would post here as well.
The boundary scan doc is released and I have the included bsdl files, however the bsdl files are clearly for the SoC itself and not for the Jetson module. i.e., the bsdl includes SoC balls listed in the pinmux document, rather than the CVM connector signal names. All the documentation including the boundary scan doc references the CVM connector pins/names - I don’t see how we can use these bsdl files as-is, especially when a SoC ball listed as a compliance pin (XTAL_IN) is not accessible from the CVM connector.
Table 2 in doc contains the pins required for compliance setting which can be handled on module.
Hi @Trumany, I regret to inform you that none of the pins from Table 2 are present in the BSDL provided with DA-09478-001_v1.1
Here are some excerpts from the bsdl file which illustrate my point:
“JTAG_TCK : V47,” & (DOC says A60)
“JTAG_TDI : V46,” & (DOC says B60)
“JTAG_TDO : V45,” & (DOC says D58)
“JTAG_TMS : V44,” & (DOC says E58)
“JTAG_TRST_N : V49,” & (DOC says G61)
“NVDBG_SEL : V52,” & (DOC says pin G60)
“NVJTAG_SEL : U52,” & (DOC says pin H59)
“PERIPHERAL_RST_N” is not present in the BSDL whatsoever. From DA-09478-001_v1.1, Figure 2, this appears to be because PERIPHERAL_RST_N does not have a connection to Xavier SoC, and the bsdl file is only listing SoC balls.
Finally, XTAL_IN is not a pin I can access from the CVM connector (XTAL_IN is not listed in table 2, but IS LISTED in the bsdl file under compliance pattern…). From the Jetson_AGX_Series_DevKit_Pinmux_Configuration_Template.xlsm file, it is clear this is because XTAL_IN is a “Ball Name” rather than “CVM Connector Signal Name” and has no direct connection to any CVM Connector Pin.
Since none of the pin names in the bsdl match the pin names from the documentation and the physical connector itself, along with the other issues mentioned (missing/extra pins in bsdl), the bsdl file is not usable in its present state.
Table 2 lists the determined pin status as required. No need to set XTAL_IN as it is not routed out and will be set status default. Pin names of V47… etc, are the chip ball names of JTAG signals.
I don’t understand what you said that bsdl file is not usable. You don’t have to handle physical chip pins to do boundary scan. The Jtag pins are all routed out to module connector as you can see in doc. Isn’t it enough to do scan thru Jtag?
The BSDL file is for chip not for module. The pins name in doc are of module pins by which customer can handle Jtag port. I don’t see conflict in that.
@Trumany you’re correct that I just need 4 JTAG pins to “do boundary scan.” However, the point of boundary scan is digital testing. As such, standard JTAG test pattern generation programs utilize a netlist in order to generate test vectors. Since I don’t have a netlist for the Jetson module itself, the provided BSDL is completely useless to me. When I try to generate a test pattern, it’s going to throw red flags everywhere and say “you aren’t connected to JTDO, JTDI, JTMS, or JTCK!” Because it will be looking for pins V44, V45, V46, and V47 which do not exist on my schematic. It also will want to drive XTAL_IN since the bsdl lists it as a required compliance pin. That will not exist in my netlist. The same goes for any kind of open/short testing on the SoC itself. It will have no idea where any signals are going because it will match nothing in my netlist. If I did have the netlist/schematics/BOM for the jetson module, I could easily merge it with my own schematics. However currently the module is a black box. Some pins presumably are directly connected to the SoC balls, but others clearly are not according to figure 2 of DA-09478-001_v1.1.
DA-09478-001_v1.1 advertises JTAG boundary scan as if it works like every other JTAG device. “Simply connect TDO of jetson to TDI of your next device” but it is not that simple. Currently if anyone wants to use boundary scan on the jetson, they will have to create a new BSDL from the ground up which utilizes the CVM pins rather than the SoC balls which are hiding in a black box from the developer/JTAG software.
Maybe this is the standard way NVIDIA does BSDL files. I will consult with my JTAG vendor, Corelis, maybe they have dealt with this type of thing before.
We are checking this internally, will update if any result.