Qual è la differenza tra un debugger JTAG commerciale e un debugger OpenOCD FT2232H open source?


10

Ho visto alcuni debugger commerciali JTAG come:

  1. Analizzatore su chip iC6000 (con supporto del protocollo Aurora)
  2. Lauterbach - Strumenti di sviluppo a microprocessore

E debugger JTAG basati su OpenOCD FT2232H:

  1. Flyswatter
  2. NGX ARM USB JTAG

Perché questi debugger commerciali sono grandi scatole rispetto ai debugger FT2232H JTAG che hanno solo un PCB di piccole dimensioni di una carta di credito? Quale hardware aggiuntivo è presente all'interno dei debugger commerciali e in quale parte del debug possono essere d'aiuto?


3
Sto votando per chiudere questa domanda come fuori tema perché le informazioni richieste sono sui siti Web dei produttori.
Leon Heller,

Forse dovrei porre la domanda in modo diverso
Robomon,

Risposte:


7

I cavi JTAG possono essere costruiti attorno a tutti i tipi di cose. I cavi Xilinx JTAG, ad esempio, hanno un chip Cypress e un FPGA. I cavi Atmel generalmente contengono un microcontrollore AVR con supporto USB. Di solito conterranno anche alcuni componenti di traduzione / livello di interfaccia / protezione / isolamento. Dipende molto dal produttore, sono tutti proprietari e reciprocamente incompatibili. In genere è necessario disporre del cavo che funzioni con qualsiasi software sia necessario utilizzare. Se tutto ciò che serve è OpenOCD, allora un cavo basato su FTDI va bene. Ma se si desidera utilizzare, dire Xilinx ChipScope? Quindi devi pagare per la cosa reale da Xilinx o un knockoff cinese.

I collegamenti che hai non sono per semplici cavi JTAG, sono molto più specializzati. Personalmente li considero un apparecchio di prova completo. Sono sostanzialmente analizzatori di protocollo specializzati. Sono progettati per interfacciarsi con hardware di traccia specializzato incorporato nel dispositivo in prova. L'hardware di traccia è diverso da JTAG. Lo scopo è registrare la traccia di esecuzione completa del software in esecuzione (ovvero tutti i rami presi) attraverso tutti i core di esecuzione e passarla al sistema di raccolta di tracce esterno (la casella in questione) su un bus ad alta velocità. La traccia viene quindi analizzata offline. Questo NON è lo stesso del debug che può essere fatto su JTAG impostando punti di interruzione e controllando il codice. La raccolta di tracce dovrebbe essere completamente trasparente per il programma in esecuzione (nessun punto di interruzione o codice aggiunto). Poiché il processore in prova può eseguire diverse centinaia di milioni di istruzioni al secondo, la memorizzazione della traccia man mano che viene prodotta richiede molta larghezza di banda e memoria veloce. I dispositivi collegati supportano il protocollo Aurora (probabilmente tra gli altri), che è un protocollo seriale ad alta velocità codificato 8b / 10b, in qualche modo simile a USB 3, ATA seriale, Ethernet gigabit / 10G seriale e PCIe. È in grado di trasferire dati a 6,25 Gbps, significativamente più di quello che può gestire il collegamento USB al PC, quindi i dati acquisiti devono essere archiviati nella RAM integrata per l'analisi offline. Questi dispositivi conterranno FPGA di fascia piuttosto alta con deserializzatori interni ad alta velocità per acquisire i dati insieme a un bel po '(diversi GB) di DRAM veloce,


8 GB di tracce sull'iC6000, molto più del PC di gramma :-) E larghezza di banda di 6,25 Gbps tramite cavo Aurora.
Fizz,

6

La differenza sta nel software e nella funzionalità, che influisce notevolmente sull'hardware.

I cavi FTDI JTAG utilizzano un set di comandi per produrre segnali JTAG. Si tratta di comandi di livello molto basso, che vanno spesso nei dettagli esatti su come funziona la macchina a stati JTAG. La logica di invio dei comandi corretti per la configurazione viene eseguita sull'host di debug sul PC.

Si tratta di hardware funzionale, economico, software gratuito (GNU GCC + GDB + OpenOCD), ecc. È abbastanza flessibile (a causa del set di comandi di basso livello) che ci sono porte per il debug ARM, la programmazione FPGA o la scansione della catena JTAG generica .

I cavi commerciali sono molto più specifici di una piattaforma e spesso contengono logica all'interno del cavo. Ciò consente al programma per PC di comunicare con il dispositivo in un modo più astratto che può essere più veloce.

Ad esempio: guarda il protocollo USB JLINK . Contiene comandi come EMU_CMD_WRITE_MEM_ARM79. Anche i cavi FTDI possono eseguire questo comando, ma viene tradotto sul lato PC nei comandi JTAG di basso livello che il cavo FTDI comprende. Significa anche che il comando di alto livello (scrivere un po 'di memoria) è suddiviso in molti più comandi secondari, che JLINK può eseguire da solo sul cavo. Ciò può comportare una migliore latenza (tenendo conto delle limitazioni di USB) e / o una velocità maggiore.

Spetta anche ai fornitori commerciali IDE quali cavi supportano ed è più probabile che sia supportato un cavo commerciale. D'altra parte, è più probabile che gli IDE gratuiti supportino i cavi di debug FTDI economici.

Alcuni software commerciali contengono anche supporto per i punti di interruzione del codice del software, in cui è possibile impostare più punti di interruzione del codice di quelli consentiti dall'hardware.

L'uso della funzionalità di traccia di alcuni microcontrollori richiede un hardware molto veloce per acquisire un bus parallelo a 4 bit. L'hardware capace di questa funzione spesso contiene un FPGA per farlo.


Per non parlare della larghezza di banda che questi possono gestire; quello per l'Xilinx di fascia alta di cui l'OP indaga (iC6000) può fare tracce da 6.25 Gbps con il protocollo Aurora, che (1) non è supportato da Flyswatters e, anche se lo fosse, quale larghezza di banda gestiranno questi? E la memoria interna ha: 8 GB per tracce sull'iC6000.
Fizz,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.