MDSTECH

TRACE32 장비는 평균 기온에서 약 +10°C~+40°C 온도에 적합하도록 설계되었습니다. 해당 범위 보다 낮거나 높은 온도에서 작동할 수 있지만 정상적인 작동을 보장할 수 없습니다.

사용자 임의로 더 높은 온도에서 장비를 사용하려는 경우 다음 사항을 고려해야 합니다.

• 하우징은 85°C 이상의 온도에 노출되어서는 안 됩니다. 하우징은 90°C에서 모양이 변형되기 시작하고 105°C에서 완전히 녹습니다.
• 대부분의 전자 부품은 최소 10°C~70°C(상업적 온도 범위)의 작동 온도 범위에 맞게 지정되어 있습니다. 즉, 주변 온도는 70°C 미만이어야 합니다.

디버그 케이블 연장:

디버그 신호를 CTC(Climatic Test Chamber) 또는 TTC(Temperature Test Chamber)로 전달하기 위해 디버그 케이블을 1~2m 연장할 수 있습니다. 하지만 이 방식은 디버그 속도가 느려집니다. 디버그 케이블 연장에 사용할 수 있는 일반적인 리본 케이블과 커넥터는 최대 105°C의 온도를 견딜 수 있습니다. 그러나 케이블 연장이 길어질수록 오류에 대한 취약성이 높아지므로 TRACE32에서 "debug port fail" 오류가 발생하고 디버그 세션이 종료될 수 있습니다.

디버그 케이블에 대한 확장이 필요한 경우 Lauterbach support에 문의하세요.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 바랍니다.

감사합니다.

리눅스환경에서 사용하기 위한 TRACE32 SW는 리눅스 배포판에 독립적이려고 노력하고 있습니다. 현재 Linux/x86_64(Linux/PPC와 Linux/ARM64은 요청 시)에서만 사용할 수 있습니다. 그럼에도 불구하고 빌드 환경을 통해 일부 요구사항이 있습니다.

2021/02 릴리즈부터 Linux/x86_64의 요구사항은 다음과 같습니다:

glibc >=2.17

motif/openmotif >=2.3.1(Motif/CDE 버전의 경우)

Qt5 >=5.6 (Qt 버전의 경우)

이러한 요구사항은 RHEL >= 7, Suse SLE >= 12 또는 Ubuntu >=18.04에 해당됩니다.

2018/02부터 2020/09 까지의 Linux/x86 및 Linux/x86_64 릴리즈에 대한 요구사항은 다음과 같습니다:

glibc >=2.12

X.org X11 >=7.6

motif/openmotif >=2.3.1(Motif/CDE 버전의 경우)

Qt4(Qt5 아님) >=4.6.2(Qt 버전의 경우)

이러한 요구사항은 RHEL >=6, Suse SLE >=11 또는 Ubuntu >= 10.10에 해당됩니다.

2017/09 및 그 이전 릴리즈의 요구사항은 다음과 같습니다:

glibc >=2.5

X.org X11 >= 6.9

이러한 요구사항은 RHEL >= 5 또는 Suse >=10에 해당됩니다.

어떤 경우든 최상의 디스플레이를 위해서는 배포판의 모든 사용 가능한 X글꼴 패키지(특히 75dpi와 100dpi 버전)를 설치해야 합니다.

일반적으로 PowerDeubg에 연결된 디버그 케이블이 TRACE32 어플리케이션을 지원하지 않는 경우 "Plugged debug cable is not suitable for CPU" 에러 메시지가 표시됩니다.

  e.g. "PowerPC-4xx" 디버그 케이블은 "TRACE32 for Arm (t32marm.exe)"에 적합하지 않습니다.

올바른 TRACE32 어플리케이션을 시작하거나 올바른 디버그 케이블을 PowerDebug에 연결하십시오.

특별한 경우로, R.2018.02 이전의 TRACE32 버전을 사용하고, 해당 버전에서 지원하지 않는 새 디버그 케이블을 사용하는 경우에도 "Plugged debug cable is not suitable for CPU" 라는 에러 메시지가 표시됩니다. 

• Arm 디버그 케이블의 시리얼 넘버가 "C18" 또는, 그 이상의 번호로 시작하는 경우 "ARM Debug Cable V5(2018년 이후 생산됨)" 입니다. R2017.02 또는 그 이상의 TRACE32 버전을 사용하십시오
• Automotive PRO 케이블을 사용하는 경우 R.2018.02 또는 그 이상의 TRACE32 버전을 사용하십시오

TRACE32 하드웨어를 구매하시면 다음 중 하나의 전원 공급 장치를 받게 됩니다: •

1.     Wall Mount Power Supply(7.5V/2.4A): USB 인터페이스가 있는 E40(PowerDebug) 모듈과 MicroTrace(uTrace)에 제공됩니다.

   직류전원장치(7.5V2A): USB 인터페이스가 있는 E40(PowerDebug) 모듈과 MicroTrace(uTrace)에 제공됩니다.

2.     Desktop Power Supply(8.0V/8.12A): X50(Debug PRO), PowerTrace III(PowerTrace II Lite) 및 PowerTrace Serial과 함께 제공됩니다.

반드시 제공된 전원 공급 장치만 사용하십시오. 자세한 내용은 TRACE32 설치 가이드에서 확인할 수 있습니다.

전원 공급 장치의 데이터 시트는 Lauterbach 웹사이트(www.lauterbach.com)에서 

"Wall Mount Power Supply" 또는 "Desktop Power Supply"를 검색하여 다운로드할 수 있습니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주십시오.

감사합니다

* TRACE32 소프트웨어가 여러 프로세서 아키텍처에 대해 동일한 TRACE32 시스템 디렉토리에 설치되었지만, 모든 아키텍처에 대해 소프트웨어 업데이트가 수행되지 않은 경우.

* TRACE32 소프트웨어 설치 없이 업데이트 패키지를 사용하는 경우.

에는 파일 충돌이 발생할 수 있습니다.

원본 config 파일을 복사하여 사용하는 경우, config 파일에서 시스템 디렉토리를 반드시 수정하십시오.

[config.t32]
OS=
ID=T32
SYS=<새 시스템 디렉토리>
tmp=C:\temp

그렇지 않으면 실행 파일의 버전이 나머지 TRACE32 파일들과 일치하지 않을 수 있습니다.

이 문제는 내부 하위 디렉토리 구조가 변경된 2010년 11월 이후의 소프트웨어 버전으로 업데이트할 때 발생할 수 있습니다.

2010년 11월 이후의 소프트웨어 버전에서는 TRACE32 실행 파일이 bin<운영 체제 유형> 예: binwindows64 하위 디렉토리 내에 위치해 있습니다.

따라서, 새로운 디렉토리 구조를 사용하는 것을 권장하며, 설치 디렉토리에서 직접 TRACE32 실행 파일을 호출하는 바로 가기를 수정하는 것을 권장합니다 (예: C:\T32)."

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주십시오.

감사합니다.

sYnch 창을 사용하면 동기화가 소프트웨어에 의해 약 ms 지연으로 수행됩니다.

그렇지 않으면 칩이 BDGREQ 및 DBGACK 신호를 지원하는 경우 하드웨어 기반 동기화를 얻을 수 있습니다.

이 경우 PODBUS를 통해 두 디버그 모듈을 연결하고 TrBus.Out Break ON 및 TrBus.Set Break ON 명령을 각 PowerView 인스턴스에 사용할 수 있습니다.

그러나 동기화 시작(Go)에서는 이러한 유형의 동기화가 지원되지 않습니다.

이러한 명령어에 대한 자세한 내용은 General Commands Reference Guide를 참조하십시오.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주십시오.

보유하고 계신 케이블 안에 있는 라이선스에 대한 유지보수를 진행하셔야 합니다.

케이블 안에는 최대 각기 다른 다섯 개의 아키텍쳐에 대한 라이선스를 가지고 있을 수 있습니다.

이 다섯 가지의 독립적인 라이선스는 각 각 유지보수를 진행하셔야 합니다.

추가로 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 바랍니다.

감사합니다.

TRACE32는 시작할 때마다 license 유지보수를 확인합니다

( 유지보수 기한은 "Help - About TRACE32" 를 클릭하신 후 생성되는 아래와 같은 창에서 License 부분을 통해 확인하실 수 있습니다)

유지보수 기한이 지난 경우, demo mode로 전환되며 사용시간에 제한이 생깁니다.

License 유지보수 기한을 연장하고 싶은 경우, QnA 게시판을 통해 연락해주시기를 바랍니다.

다른 궁금한 사항은 'TRACE32@mdstech.co.kr'로 문의 주시기 바랍니다.

감사합니다.

"TRACE32 device already in use"라는 메시지가 포함된 Dialog box 가 표시되면, 다음 중 하나가 발생한 것입니다:

1. TRACE32 SW를 실행시켰지만, 다른 TRACE32 GUI 가 여전히 PowerDebug에 독점적으로 연결되어 있습니다.

2. TRACE32 PowerView 가 이전에 제대로 종료되지 않았습니다. (e.g. kill 또는 crash)

3. AMP 멀티 코어 시나리오에 따른 2번째 TRACE32 SW를 실행시켰지만, 두 번째 GUI 가 CORE=2로 구성되지 않았거나 첫 번째 GUI 가 CORE=1로 구성되지 않았습니다.

PowerDebug를 재설정하여 TRACE32를 강제로 연결하고자 한다면, TRACE32 구성 파일(일반적으로 "config.t32")의 PBI= 섹션에 CONNECTIONMODE=AUTOCONNECT 문을 사용합니다.

USB 연결의 예:

TRACE32 가 새로운 TRACE32 세션을 자동으로 닫으려면 TRACE32 구성 파일의 PBI= 섹션에 CONNECTIONMODE=AUTOABORT 문을 사용합니다.

TRACE32는 추가적으로 AUTORETRY 와 QUERYCONNECT 연결 모드를 지원합니다. 다음은 모든 연결 모드에 대한 설명입니다.

모드에 대한 정보는 TRACE32 설치 가이드를 참조하십시오.

t32start.exe 를 사용하여 TRACE32 PowerView UI 를 시작하는 경우, USB 설정 또는 이더넷 설정에서 연결 모드를 변경하여 연결 모드를 설정 할 수 있습니다.

자세한 내용은 T32Start 를 참조하십시오.

다른 궁금한 사항은 'TRACE32@mdstech.co.kr'로 문의 주시기 바랍니다.

감사합니다.

1. TRACE32 소프트웨어 설치를 간편하게 배포하기 위해 네트워크 마운트/드라이브를 사용하고, TRACE32 DVD의 내용을 서버의 특정 디렉토리에 배치합니다.

xcopy D:*.* N:TRACE32DVD_201011 /E /V /L // drive와 directory 이름에 대한 예시입니다

2. 명령어 셸 창에서 다음 지침을 사용하여 TRACE32 설치를 한 번 기록합니다.

N:
cd N:TRACE32DVD_202109filesbinsetup64 // drive와 directory 이름에 대한 예시입니다
// 사용자의 환경에 맞게 변경을 꼭 해주셔야 합니다

setup.exe /r /f1"N:TRACE32DVD_201011binsetup64setup.iss" // /r은 설치 프로세스를 recording함을 의미합니다
// /f1은 설치 recording을 한 파일을 의미합니다

TRACE32 설치 과정을 완료하면, 기록이 setup.iss 파일에 저장됩니다.

3. 다른 PC에서 무인 TRACE32 설치를 다음 명령어로 시작합니다.

setup.exe /s /f1"N:TRACE32DVD_201011binsetup64setup.iss" // /s는 silence installation mode 입니다

만약 InstallShield가 네트워크 드라이브에 기록 파일과 함께 제대로 작동하지 않는 경우, 기본 경로인 C:rulsetup.iss를 대신 사용하십시오.

다른 궁금한 사항은 'TRACE32@mdstech.co.kr'로 문의 주시기 바랍니다.

감사합니다.

해당 에러 메시지는 PowerView 소프트웨어와 PowerDebug 장비가 USB를 통해 연결이 되지 않았을 때 나타납니다.

• PowerDebug 장치에 전원이 공급되고 있으며, PC에 올바르게 연결되었는지 확인하십시오.

• PowerDebug 장치가 운영 체제에서 올바르게 감지되었는지 확인하십시오.
  예를 들어 윈도우의 경우 장치 관리자에 TRACE32 Device 가 나타나야 합니다.

• PowerDebug 장치를 USB 허브가 아닌 PC의 USB 포트에 직접 연결하세요.

• PC에 여러 PowerDebug 장치가 연결된 경우 TRACE32 configuration 파일에서 각 노드(장치) 이름을 지정해주어야 합니다.
  T32Start를 사용하는 경우 ConnectionType:USB 에서 인터페이스를 구성하고 USB Settings->Device Name 에서 원하는 장치 이름을 입할 수 있습니다.
  그러면 configuration 파일이 다음과 같이 설정된 것을 볼 수 있습니다.

;Connection to Host
PBI=
USB
NODE=

장치 이름은 기본적으로 디버그 모듈의 일련 번호입니다.

다른 궁금한 사항은 'TRACE32@mdstech.co.kr'로 문의 주시기 바랍니다.

감사합니다.

디버거를 타깃에 연결하거나 타깃에서 분리할 때는 항상 타겟의 전원이 꺼져 있을 때만 수행하는 것이 좋습니다.

따라서 권장되는 연결 및 제거 순서는 다음과 같습니다

1. 디버거와 타깃의 전원이 모두 꺼져 있는 상태

2. 디버거 전원 켜기

3. TRACE32 Powerview 시작

4. 디버거를 타깃에 연결

5. 타깃 전원 켜기

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다

설치는 MDS테크에서 제공하는 TRACE32 설치 가이드를 참조하세요.

TRACE32를 제거하려면 시스템 디렉토리를 수동으로 삭제합니다(예: Windows의 경우 C:T32, Linux의 경우 /opt/t32).

Windows의 경우 Windows 설정 또는 제어판에서 프로그램 제거를 추가로 실행해야 합니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr로 문의 주시기 바랍니다.

감사합니다.

자세한 내용은 Lauterbach RISC-V 디버거 매뉴얼의 "Quick Start for Debug Module Configuration" 챕터를 참고 부탁드리겠습니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

자세한 내용은 Lauterbach RISC-V Debugger 매뉴얼의

"Troubleshooting" -> "Communication between Debugger and Processor cannot be established" 장을 참고하십시오.

다른 궁금한 사항은 TRACE32@mdstech.co.kr로 문의 주시기 바랍니다.

감사합니다.

RISC-V 디버그 feature의 일부 사양은 일반적인 사양을 따라가지만 특정 기능이나 구현 유무를 선택할 수 있도록 “optional” 로 분류되어 있습니다. 디버그 모듈(DM)의 여러가지 디버그 레지스터 사용을 위한 레지스터 비트 필드(bitfield) 또는 전체 기능 사용 유무는 “optional” 로 선언되어 있습니다. 다음은 디버그 레지스터 및 “optional” 레지스터 비트 필드를 설명하고 해당 디버그 레지스터가 디버깅에 필요한지 여부를 설명합니다.

주의:

이 목록은 향후 언제든지 변경될 수 있습니다. 레지스터나 비트 필드가 이 목록에 없으면 글 작성자가 추가하는 것을 잊었거나 디버그 사양에서 선택 사항(optional)이 아닌, 이미 포함된 것으로 간주하여 항목을 나열하지 않을 수 있습니다.

l Abstract Data 0 - 11 (data0 - data11):

n 필요한 dataX 레지스터의 개수는 RISC-V 디버그 모듈에 연결된 모든 코어의 base ISA(RV32, RV64 등)와 같은 요인에 따라 달라집니다. 또한 RISC-V 디버그 모듈에서 구현된 기능, 특히 구현된 Abstract command에 따라 달라집니다. 자세한 내용은 RISC-V 디버그 사양을 참조해야 합니다.
대부분의 표준 RISC-V 칩에서는 디버그 모듈이 RV32 코어만 처리하는 경우 최소 data0이 필요하지만 디버그 모듈이 하나 이상의 RV64 코어를 처리하는 경우 최소 data0 및 data1이 필요합니다.

n Scratch memory:

u 특정 상황에서 디버거는 'data' 디버그 레지스터를 "scratch menory"로 사용해야 합니다. 자세한 내용은 아래의 'hartinfo'를 참조하십시오.

u Scratch memory가 필요한 경우, 최소 데이터 레지스터 양은 위에서 언급한 개수보다 더 필요할 수 있습니다(scratch memory가 사용되는 실제 시나리오에 따라 다름). 이 경우 현재 권장 사항은 최소 4개의 데이터 레지스터(RV32 또는 RV64에 관계없이)이지만 시나리오에 따라 실제 필요한 크기가 더 클 수 있습니다.

l Debug Module Control (dmcontrol):

n hasel bitfield: 멀티코어 디버깅에 권장되며, 하드웨어를 통해 여러 RISC-V 코어의 동기화된 start 및 stop 이 가능합니다.
디버그 모듈에 연결된 RISC-V 코어가 여러 개 있고 'hasel'이 지원되지 않는 경우, 디버거는 모든 코어를 동시에 start/stop 할 수 없으며 연속적으로만 start/stop 할 수 있습니다.
디버그 모듈에 연결된 RISC-V 코어가 하나만 있는 경우 hasel bitfield는 불필요 합니다.

l Hart Info (hartinfo):

n 'data' debug register (e.g. scratch memory)

n 특정 상황에서 TRACE32 디버거는 " scratch memory " (i.e. 디버그 작업에 사용할 수 있는 메모리)를 사용해야 합니다. 예를 들어 RV32 코어(XLEN=32비트)의 double-precision floating point registers (FLEN=64비트)에 접근할 때가 그렇습니다. 'data' debug register가 hart의 메모리 맵에 shadowed 되어 있으면 scratch memory 로 사용할 수 있습니다.

n 'data' debug register를 scratch memory로 사용해야 하는 경우, 'hartinfo' debug register가 존재하고 그에 따라 'dataaccess', 'datasize' 및 'dataaddr' 필드가 설정되어야 합니다.

n 'data' debug register를 scratch memory로 사용하지 않고, program buffer를 scratch memory로 사용할 수 있습니다. 자세한 사항은 아래 프로그램 버퍼에 대한 내용을 참조하십시오.

n 위에서 언급한 사용 케이스 외에도 RISC-V 디버거에 다른 사용 케이스들이 추가될 수 있으며, 해당 기능을 위해 hartinfo 레지스터가 구현되어야 할 수 있습니다.

l Abstract Command autoexec (abstractauto): Abstract Command autoexec 레지스터는 optional로 선언되어 선택 사항이지만 디버거 입장에서는 구현하는 것이 좋습니다. 'autoexecdata[0]' 비트를 사용하면 여러 개의 연속적인 abstract command를 실행할 때 성능이 향상되는 효과를 볼 수 있습니다. 예를 들어 프로그램 버퍼 또는 abstract command 를 통한 메모리 읽기 / 쓰기 등 광범위하게 사용할 수 있습니다.
TRACE32디버그 드라이버는 선택적 기능을 지원하지 않는 디자인에서도 사용할 수 있습니다.

l Program buffer 0 - 15(progbuf0 - progbuf15): 디버그 상세 사양에서 program buffer 사이즈는 0 ~ 16까지 사용할 수 있습니다. 크기가 0이면 program buffer가 전혀 없음을 의미합니다. 일반적으로 유효한 RISC-V 디버그 IP를 구현하는 두 가지 주요 방법이 있습니다 (두 가지 모두 RISC-V 디버그 사양에 자세히 설명되어 있음).

n Abstract Command Based Approach: 디버거의 모든 주요 작업 및 타깃과의 상호 작용은 abstract command를 통해 수행됩니다. 이 경우 program buffer가 필요하지 않으므로 program buffer 크기는 0이 될 수 있습니다.

n 현재까지 승인된 디버그 사양 v0.13.x/0.14.x/1.0.x에서는 특정 abstract command 유형이 지원되는지 여부와 abstract command 지원 여부를 탐지/검색하는 적절한 메커니즘이 제공되지 않고 있습니다. 이러한 영향성은 TRACE32 가 abstract memory를 지원할 때 제한된 버전에 대해서만 사용 가능 하다는 의미이며 TRACE32 디버거가 시스템 'access memory' 관련 abstract command를 찾아내는데 영향을 미칠 수 있습니다. 자세한 내용은 공식 RISC-V 디버그 workgroup의 discussion 내용을 참조하십시오. Abstract command 관련 시스템 명령어를 찾아내는 것과 관련된 제약 사항으로 인해, system discovery 문제가 해결될 때까지 "Execution Based" 접근 방식을 우회적으로 사용하는 것이 좋습니다.

이러한 이유로 TRACE32 디버거만 유일하게 'access memory' 관련 abstract command를 지원하는 이유입니다. 'aamsize', 'aampostincrement' 및 'write' bitfield의 가능한 모든 옵션과 조합이 타깃 하드웨어에서 지원되는 경우 TRACE32 디버거를 도입할 수 있습니다.

Abstract command를 memory access 시 기본 명령어(default)로 지정하려면 SYStem.MemAccessStop AAM 를 사용하면 됩니다.

n Flexibility: Abstract command기반의 디버깅 적용 검토

u 디버거에 Program buffer가 없으면 실행할 수 있는 작업과 관련하여 유연성이 크게 떨어집니다(비교를 위해 아래 execution based 접근 방식 참조).

n Cache coherency (abstract command 기반): 일반적으로 ‘access memory’ 관련 abstract command의 RISC-V 디버그 사양은 CPU의 명령어 또는 데이터 캐시에 대해 작동하는 표준화된 메커니즘을 제공하지 않습니다.

Program buffer 가 없는 경우 디버거는 자체적으로 캐시 일관성을 보장할 수 없으므로 하드웨어는 자체적으로 캐시 일관성을 자동으로 보장해야 합니다(예: 디버거가 각각의 access memory 관련 abstract commad를 시작할 때 캐시 플러시 flush를 실행 - 필요한 경우).

n Execution Based Approach: 디버거의 주요 작업 및 상호 작용은 부분적으로 program buffer실행에 영향을 받습니다.

n 이 경우 TRACE32디버거는 현재 다양한 시나리오에서 program buffer를 사용하며, 향후 추가적인 시나리오가 추가되거나 버그 수정 또는 개선으로 인해 기존 시나리오 및 동작이 변경될 수 있습니다. 따라서 현재 사용중인 program buffer의 크기가 향후 모든 기능에 충분할 수 있는지 특정할 수 없기 때문에 최적화된 (작은) program buffer크기를 "권장(추천)” 하기는 불가능합니다. 또한 필요한 program buffer의 크기는 '내재된 ebreak' 기능이 구현되었는지 여부(dmstatus.impebreak)에 따라 다릅니다.

디버그 드라이버(2023-05-31)의 현재 구현을 기준으로 프로그램 버퍼 크기 3(implicit ebreak 없음) 또는 2(implicit ebreak 있음)는 현재 사용 가능한 대부분의 기능에 충분한 최적화값입니다.
한 가지 예외 사항으로 program buffer를 scratch memory로 사용하는 것입니다(아래 내용참조).
향후 기능적으로 향상된 드라이버에 대해 더 큰 program buffer가 필요할 수 있습니다.

n 요약.

시스템 설계자가 드라이버의 향후 업데이트를 위해 안전성 유지하려는 경우와, 칩 영역이 그다지 중요하지 않은 경우 program buffer의 크기를 16으로 지정할 것을 권장합니다. 앞서 나열된 상황에 대해 현재 사용중인 최소화된 크기로도 충분합니다. 또한 드라이버가 위에서 언급한 최소 크기보다 큰 크기를 요구하는 기능을 추가할 경우, program buffer 크기가 작은 하드웨어를 위해 기능이 축소된 "fallback" 옵션을 항상 제공할 것입니다. 그러나 program buffer 크기가 위에서 언급한 요구 사항보다 작은 하드웨어는 "execution based approach" 방식을 사용할 경우, TRACE32 디버그 드라이버와 호환되지 않을 수 있습니다.

n Scratch memory:

u 특정 상황에서 TRACE32 디버거는 "scratch memory" (디버그 작업에 사용할 수 있는 메모리)를 사용해야 합니다. 예를 들어, RV32 코어(XLEN=32bit)의 double-precision floating point registers (FLEN=64bit)에 접근할 때가 그렇습니다. program buffer data debug registers (progbuf0, progbuf1, ...)가 hart 의 메모리 맵에 shadowed 되어있고 hart 에 의해 write할 수 있는 경우, program buffer를 scratch memory로 사용할 수 있습니다.

u 이 경우, 디버거는 hart의 관점에서 program buffer의 주소를 결정하기 위해 program buffer에서 'auipc' 명령어를 실행합니다.

u Program buffer를 scratch memory로 사용해야 하는 경우, 최소한으로 요구되는 program buffer 크기는 앞서 언급한 크기보다 클 수 있습니다. 현재 이 경우의 권장 사항은 최소 4개의 program buffer register이지만, 실제로 필요한 크기는 사용 시나리오에 따라 더 클 수 있습니다.

u Program buffer를 scratch memory로 사용하는 대안으로 'data' debug register를 scratch memory로 사용할 수 있습니다. 'Abstract Data' register와 'hartinfo' register에 대한 추가 설명은 위의 내용을 참조하십시오.

n Flexibility: Execution based command기반의 디버깅 적용 검토

u Program buffer에 접근할 수 있으면 디버거는 abstract command의 특정 작업에 제한되지 않고 실행할 수 있는 작업의 유연성(flexibility)이 크게 증가합니다.

n Cache coherency (execution based command 기반): 일반적으로 RISC-V 디버그 사양은 CPU의 명령어 또는 데이터 캐시에 대해 작동하는 표준화된 메커니즘을 제공하지 않습니다. 그러나 program buffer가 존재하면 디버거가 "FENCE" 및/또는 "FENCE.I" 명령어를 실행할 수 있습니다. 이를 통해 디버거는 특정 디버거 작업 전후에 이러한 명령어를 실행하여 캐시 일관성을 보장할 수 있습니다.

n 권장 사항: 디버거 관점에서, Execution based command 접근 방식을 구현할 것을 권장합니다. 이 방식은 디버거에게 훨씬 더 많은 유연성(flexibility)을 제공합니다.

l System Bus Address (sbaddress0/1/2) + System Bus Data (sbdata0/1/2/3): 이러한 선택적 레지스터는 시스템 버스를 통해 메모리에 접근하려는 경우에만 필요합니다(RISC-V 디버거의 'SB:' 접근 클래스 참조). 디버거는 시스템 버스 접근 없이도 작동할 수 있습니다. 시스템 버스 접근이 필요한지 여부는 사용자의 개별 요구 사항과 대상 아키텍처에 따라 다릅니다.

l Halt summary registers:

n haltsum0/1/2/3: 현재 디버거에서 사용되지 않습니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다

RISC-V 디버그 표준은 트리거 세트를 보유하는 모듈을 정의합니다.

각 트리거는 여러 유형(예: 'mcontrol2' 또는 'mcontrol6') 중 하나에 대해 개별적으로 구성할 수 있으며, 트리거 유형에 따라 다양한 옵션으로 구성할 수 있습니다.

디버그 사양은 타 기종 트리거 기능을 갖춘 시스템 설계를 허용하므로 모든 트리거가 동일한 트리거 유형과 동일한 트리거 유형 구성 옵션을 지원할 필요는 없습니다.

다음은 버전 R.2022.02 이상인 RISC-V 디버거와 호환되기 위한 트리거 유형 'mcontrol2' 및 'mcontrol6' 에 대한 요구 사항입니다.

• RISC-V 디버거는 트리거 유형 mcontrol2와 mcontrol6을 모두 지원하지만 디버그 세션에서는 이러한 유형 중 하나만 사용할 수 있습니다.
• 더 많은 트리거가 사용하고 있는 트리거 유형을 자동으로 선택하며, 예를 들어 코어가 4개의 mcontrol2 트리거와 5개의 mcontrol6 트리거를 지원하는 경우 디버거는 mcontrol6 옵션을 사용합니다.

다음은 버전 R.2019.09 이하의 RISC-V 디버거와 호환되기 위한 트리거 유형 'mcontrol2' 및 'mcontrol6' 에 대한 요구 사항입니다.

• 트리거 유형 mcontrol2만 지원됩니다. (mcontrol6 미지원)
• 디버거는 'mcontrol' 유형을 지원하는 가장 큰 연속된 트리거 블록만 사용합니다.
  (예 : 트리거 인덱스 1, 4, 5, 6, 9만 'mcontrol' 유형을 지원하는 경우 인덱스 4, 5, 6의 연속된 블록만 사용합니다.)
• 각 mcontrol 트리거에는 다양한 선택적 구성 옵션(execute, store, load, chain, ...)이 있습니다.
  디버거는 현재 인접한 mcontrol 블록의 모든 트리거에서 지원되는 구성 옵션만 사용합니다(위 참조).
  예외로 해당 블록의 마지막 트리거를 제외한 모든 트리거에서 지원되는 경우 사용되는 'chain' 옵션이 있습니다.

RISC-V 에서 Instruction / Data 캐시

안타깝게도 RISC-V 디버그 사양은 Instruction 또는 Data 캐시를 처리하는 명시적이고 표준화된 방법을 정의하지 않습니다.

하지만, 일부 시나리오에서는 Debugger 또는 Debug IP가 캐시 플러시와 같은 특정 캐시 작업을 실행할 수 있어야 합니다.

Example #1:

Instruction 캐시가 있는 단일 RISC-V 코어를 가진 SoC 를 예로 들겠습니다.

코어의 instruction 메모리에는 RISC-V 명령어 "A" 가 포함되어 있습니다.

RISC-V 코어는 "A"를 실행하기 전에 일부 명령어를 중단합니다.

코어는 아직 "A"를 실행하지 않았지만, 이미 "A"를 instructoin 캐시와 파이프라인에 로드 했습니다.

이제 디버거는 software breakpoint 를 "A"에 설정하는데, 이는 임시로 "A" 를 "EBREAK" 명령어로 대체한다는 것을 의미합니다.

그 이후, debugger는 코어를 다시 시작 시킵니다.

코어가 원래 캐시된 "A" 명령어 대신 새로운 "EBREAK" 명령을 실행하도록 하기 위해서는,

debugger 가 CPU를 다시 시작하기 전, instruction 캐시와 파이프라인을 플러시 해야 합니다.

Example #2:

Data 캐시가 있는 다중의 RISC-V 코어를 가진 SoC 를 예로 들겠습니다.

각각의 코어가 정지됩니다.

각각의 코어는 이미 주소 "B"의 메모리 데이터 "X" 를 해당 data 캐시에 캐시했습니다.

이제 debugger 는 직접 시스템 버스 접근을 사용해 주소 "B"의 데이터 메모리에 새로운 데이터 "Y"를 씁니다.

Debugger 가 코어를 다시 시작시킬 때, 각 코어의 data 캐시에 더 이상 오래된 데이터 "X" 가 포함되어 있지 않은지 확인해야 합니다.

따라서 debugger 는 코어를 다시 시작하기 전, 또는 코어 중 하나의 관점에서 메모리 content 를 읽기 전에 각 코어의 data 캐시를 플러시 해야 합니다.

FENCE/FENCE.I 를 통한 캐시 처리 방법

위의 예제 시나리오와 다른 시나리오를 해결하기 위해서, debugger 는 "FENCE" 또는 "FENCE.I" 명령어의 프로그램 버퍼 실행을 사용합니다.

RISC-V ISA 사양에 따르면, 이러한 명령어는 각각의 칩에 적용 가능하고, 해당 시나리오에서 필요한 경우 캐시 및 파이프라인 플러시가 발생하도록 보장해야 합니다.

다음 항목들은 디버거가 보통 FENCE 및 FENCE.I 명령어를 사용하는 예제 시나리오를 보여줍니다.

물론, 해당 동작이 항상 적용되는 것은 아니며, 향후 debugger 버전에 따라 변경될 수도 있습니다.

• 코어 재 실행 : 디버거가 코어를 재 실행하기 전에, 프로그램 버퍼를 통해 "FENCE" 및 "FENCE.I" 명령어를 모두 실행합니다.
• 코어를 통한 메모리 읽기 : 디버거가 코어의 관점에서 메모리를 읽기 전에(프로그램 버퍼 또는 '메모리 접근' 명령어를 통해), 프로그램 버퍼를 통해 "FENCE" 명령어를 실행합니다.
• 코어를 통한 메모리 쓰기 : 디버거가 코어의 관점에서 메모리를 쓴 후(프로그램 버퍼 또는 '메모리 접근' 명령어를 통해), 프로그램 버퍼를 통해 "FENCE" 명령어를 실행합니다.

위의 디버거 동작은 하드웨어의 디버그 IP가 충분한 크기의 프로그램 버퍼를 가지고 있고, 해당 코어가 FENCE 및 FENCE.I 명령어를 지원하는 경우에만 가능합니다.

이러한 경우, 디버거는 해당 코어에 캐시가 있는지 여부와 관계없이 설명된 단계를 실행합니다.

그러나 하드웨어의 디버그 IP에 프로그램 버퍼가 없거나, 프로그램 버퍼의 크기가 충분하지 않거나, FENCE/FENCE.I를 지원하지 않는 경우, 디버거는 디버그 IP가 모든 관련 시나리오를 자동으로 처리할 것이라고 가정해야 합니다.

"Base Cache Management Operation" (CMO) ISA 확장을 통한 캐시 핸들링

선택적인 '기본 캐시 관리 작업'(CMO) ISA 확장(Zicbom, Zicboz, Zicbop)은 RISC-V 코어의 캐시에 대해 표준화된 작동 메커니즘을 정의합니다.

이 ISA확장에 대한 정보는 https://github.com/riscv/riscv-CMOs 에서 찾을 수 있습니다.

현재 Lauterbach 의 RISC-V 디버거의 disassembler는 이 확장을 지원합니다.

그러나 디버거는 아직 이 확장 명령어를 사용하여 캐시 플러시를 실행하지 않습니다.

(위에서 언급된 시나리오를 다루기 위해) 하지만 앞으로는 이를 고려할 예정입니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

RISC-V ISA 규격은 "ISA 확장"을 정의하며, 이는 기본 ISA를 특정 추가 명령으로 보완할 수 있습니다.

ISA 규격은 표준 ISA 확장 이외에도 핵심 설계자가 자신의 non-standard/custom RISC-V ISA 확장을 정의할 수 있는 방법을 표준화합니다.

TRACE32에서 사용자 지정 비표준 RISC-VISA 확장을 지원하는 방법에는 다음과 같은 두 가지 옵션이 있습니다:

1. Direct intergration
경우에 따라 TRACE32에 특정 사용자 지정 RISC-V ISA 확장에 대한 지원을 직접 추가할 수 있습니다.

이는 주로 disassemble 및 instruction set 시뮬레이터 또는 trace 지원에 영향을 미칩니다.

그런 다음 SYSTem.CPU 명령을 통해 해당 CPU 항목을 선택하는 등의 사용자 지정 확장에 대한 지원을 활성화할 수 있습니다.

소프트웨어에 대한 direct integration을 제공할 수 있는 경우와 어떤 상황에서 제공할 수 있는지에 대해 논의가 필요합니다.

2. APU API를 통한 disassembler 플러그인
TRACE32는 ISA 확장자의 비표준 RISC-V 명령에 의해 disassemble 기능을 확장하기 위해 custom "disassemble plugin"(*.dll 또는 *.so와 같은 공유 라이브러리를 통해)을 로드할 수 있는 API를 제공합니다.

이 API는 API for Auxiliary Processing Unit, 보조 처리 장치를 위한 API(APU API)라고 불립니다.

자세한 내용은 APU API(https://repo.lauterbach.com/pdf/api_apu.pdf)에서 확인할 수 있습니다

위 plugin을 사용하면 다음과 같은 이점이 있습니다.
- 사용자는 이미 chip 및 toolchain 개발 초기 단계에 있는 ISA 확장을 테스트할 수 있으며 변경 사항을 제어할 수 있습니다.
- Lauterbach 또는 MDS테크와의 라이선스 계약은 필요하지 않습니다.
- Lauterbach 또는 다른 당사자에 대한 ISA 확장에 대한 자세한 내용을 밝힐 필요는 없습니다.

APU API는 custom instruction과 함께 instruction trace decording을 지원하기 위해 특정 점프 플래그로 프로그램 흐름 제어 명령어를 표시하고 점프 대상 주소를 정의할 수 있도록 합니다. 아래에 언급된 제한 사항을 참조하십시오.

RISC-VAPU API disassemble 플러그인 사용의 제한 사항에 유의하십시오.
- APU API는 TRACE32 instruction set 시뮬레이터에서 지원되지 않습니다.

TRACE32는 시뮬레이터용 API를 제공하지만 이 API는 주변 동작(API for TRACE32 명령 집합 시뮬레이터)만 시뮬레이션할 수 있고 전체 코어의 동작은 허용하지 않습니다.

- 프로그램 흐름 제어 동작이 더 복잡한 사용자 지정 명령이 있는 경우(예를 들어 새 사용자 지정 분기 명령을 추가하는 경우) trace 지원이 APU API의 일반 인터페이스에 의해 적용될 수 있는지 여부와 방법에 대해 논의가 필요합니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

RISC-V는 32비트(RV32), 64비트(RV64), 128비트(RV128) 기본 ISA를 사용합니다.

TRACE32는 일반적으로 RV32와 RV64 기본 ISA를 사용하는 코어 아키텍처를 지원합니다.

하지만 RV128 ISA 코어는 현재 지원되지 않습니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

RISC-V ISA 스펙은 특정 표준 ISA (instruction set architecture) extension을 정의하고, 기본 ISA 세트를 추가 명령어로 보완할 수 있습니다(예를들면 atomic 명령어를 위한 "A" extension).

TRACE32는 RISC-V ISA 스펙에서 정의된 모든 표준 ISA extension을 지원합니다.

'F"와 같은 특수 extension(floating point extensions)의 경우, TRACE32는 추가 floating point registers의 내용을 표시하고 값을 수정할 수 있습니다.

TRACE32는 RISC-V의 표준 ISA 확장의 모든 조합을 지원합니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

디버거는 디버그 모듈의 디버그 레지스터에 액세스할 필요가 없습니다.

제대로 작동하려면 여러 핵심 레지스터(제어 및 상태 레지스터, CSR)도 액세스 가능/구현되어야 합니다.

다음 요약은 디버깅 컨텍스트에 있는 CSR을 나열하고 필요한지 여부를 언급합니다.

Core Debug Registers

• Debug Control and Status (dcsr)
  ① 필수 레지스터입니다. 이 레지스터가 없으면, 디버그 지원이 불가능합니다.
• Debug PC (dpc)
  ① 필수 레지스터입니다. 이 레지스터가 없으면, 디버그 지원이 불가능합니다.
  
• Debug Scratch Register 0/1 (dscratch0/1)
  ① 선택적 레지스터입니다. Lauterbach 디버거는 현재 이 레지스터들을 사용하지 않습니다.
  

Debug/Trace Registers

• Debug/Trace trigger register select (tselect):
  

  ① [debug spec v0.13.x]: 트리거가 구현되었는지와 상관없이 필수입니다.
  ② [debug spec v0.14x and later]: 트리거가 구현된 경우 필수, 그렇지 않은 경우 선택 사항입니다.
  
• First Debug/Trace trigger data register (tdata1):
  ① [debug spec v0.13.x]: 트리거가 구현되었는지와 상관없이 필수입니다.
  ② [debug spec v0.14x and later]: 트리거가 구현된 경우 필수, 그렇지 않은 경우 선택 사항입니다.
  
• Second Debug/Trace trigger data register (tdata2):
  ① 트리거가 구현된 경우 필수, 그렇지 않은 경우 선택 사항입니다.
• Third Debug/Trace trigger data register (tdata3):
  ① 선택적 레지스터(디버거 관점에서)입니다. 현재 디버거는 tdata3이 사용되지 않는 match control 트리거만 지원합니다.
  그러나 나중에 다른 트리거 유형에 사용될 수 있습니다.
• Trigger Extra (textra32/textra64):
  선택적 레지스터(디버거 관점에서)입니다.
  이 트리거의 기능이 mcontrol2 또는 mcontrol6에 필요한 경우에만 필요합니다.
• Trigger Info (tinfo):
  ① 트리거가 구현되고 "trigger type bitfield"(tdata1->type)가 쓰기 가능한 경우 필수입니다.
  그렇지 않으면 선택 사항입니다.
  

• Machine ISA Register (misa):
  ① 이 레지스터는 디버거가 디버깅 중인 코어의 기능을 결정하는 데 도움이 됩니다.
  

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

TRACE32는 RISC-V 공식 디버거 사양을 기반으로 한 디자인을 지원하고 있습니다.

공식적으로 승인된 첫 번째 디버그 사양은 v0.13 버전이었습니다.

따라서 TRACE32는 v0.14, v1.0 등 v0.13.x 이후 모든 버전을 지원합니다.

그러나 첫 번째 승인된 v0.13 이전의 비공식 초안 버전(예: v0.11)은 지원하지 않습니다.

하지만, TRACE32는 RISC-V 공식 디버그 사양외에 다양한 RISC-V 하드웨어 또한 지원하고 있습니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

SYStem.Option.FREEZE 설정은 디버그 관련 레지스터를 사용하여 타깃이 debug halt 상태에 진입할 때 타이머/카운터 동작에 영향을 줍니다.

QorIQ CPU는 일반적으로 RCPM에 CTBHLTCR 또는 TTBHLTCR 레지스터를 제공합니다.

* RCPM: Run Control and Power Management

* CTBHLTCR: Core Time Base Halt Control Register

* TTBHLTCR: Thread Time Base Halt Control Register

이 레지스터의 특정 코어에 대한 비트가

• 1로 설정되어 있다면, SYStem.Option.FREEZE 설정을 통해 코어가 debug halt 상태에 있는 동안 타이머를 실행하거나 중지시킬 수 있습니다.
• 0으로 설정되어 있다면, 타이머는 SYStem.Option.FREEZE 설정에 관계없이 항상 debug halt 상태에서 중지합니다.

"emulation pod configuration error" 의 경우 몇 가지 원인이 있습니다.

1. SYStem 창에서 선택한 CPU와 타깃 프로세서가 다른 경우

- 선택한 CPU와 타깃 CPU가 동일한지 확인해야 합니다.

- SYStem.DETECT CPU 를 통해 타깃 CPU를 확인할 수 있습니다. (SYStem.DETECT CPU 명령어는 PowerPC 아키텍쳐에서만 사용 가능)

2. 디버깅 하고자 하는 CPU 가 현재 사용하고 있는 TRACE32 S/W(PowerView) 에서 지원하지 않는 경우

- 최신 TRACE32 S/W를 통해 지원 여부를 확인할 수 있습니다.

오류 발생 시 자세한 메시지는 B::AREA 창에 출력 됩니다. (View - Message Area 풀다운 메뉴를 통해 실행)

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

JTAG를 통한 디버깅을 사용하려면 e500 코어용 리눅스 커널(PQ3/MPC85XX/QorIQ P10XX/P2020) 패치가 필요합니다.

그리고 arch/powerpc/include/asm/reg_book.h에 정의된 MSR_KERNL 매크로는 MSR_DE 비트를 포함하도록 수정이 필요합니다.

#define MSR_KERNEL (MSR_ME|MSR_RI|MSR_CE|MSR_DE)

추가로 필요한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

SRAM과 로컬 메모리에는 ECC Protection 기능이 있습니다.

Power-On 후 SRAM과 해당 ECC 비트는 랜덤한 값을 유지합니다.

따라서 값의 조합에 따라 ECC 블록(일반적으로 64비트 또는 32비트)이 bus error로 표시되거나 표시되지 않을 수 있습니다.

Application이 플래시로 프로그래밍 되면 부트코드에서 SRAM을 초기화 합니다.

SRAM에서 Application이 동작하는 경우에는(예: 초기 테스트나 플래시 프로그래밍을 위해) 다음 명령을 사용하여 디버거를 통해 SRAM을 초기화해야 합니다.

Data.Set EA:0x40000000--0x4000BFFF %Quad 0x0000000000000000

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

Nexus 프로브를 사용한 에너지 측정시에 active termination을 off 하는 것이 좋습니다.

Analyzer.disable(Nexus trace probe hardware 비활성화)와 NEXUS.OFF(Nexus Cell off)사이에는 큰 차이가 없습니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

디버거에서 SYStem.Up을 실행할 수 없고 대신 전원 오류가 감지되면,

두 개의 디버거(e.g. JTAG 디버그 케이블과, NEXUS 프로브)가 같이 연결되어 있는지 확인해야 합니다.

이는 허용되지 않는 구성으로, JTAG 동글이나 NEXUS 프로브를 디버깅에 사용할 수 없게 만듭니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

MPC5XXX 프로세서들은 censorship feature기능이 구현되어 있습니다.

Censorship 기능이 활성화되면 디버거의 JTAG 접근이 차단되어 디버깅이나 트레이싱이 불가능합니다.

프로세서 내부 JTAG로직을 통해서 MPC5XX 프로세서의 consorship 유무를 감지할 수 없습니다.

Ceonsorship이 활성화되어 있다면 JTAGID 읽기는 가능하지만, 그 이후의 JTAG을 이용한 프로세서 접근이 모두 실패합니다.

TRACE32디버거에서는 “Debug Port Fail”이 발생하며, B::Area 영역에서 다음과 같은 오류가 나타납니다.

l JTAGID=0x______1D

l Error: received invalid OSR (0x000)

l is the device censored?

프로세서가 의도적(사용자 또는 프로세서 자체적으로)으로 검열된 경우, 다음 명령어를 순차적으로 입력하여 JTAG 접근을 재시도 할 수 있습니다:

l SYStem.DETECT CPU

l SYStem.Option.KEYCODE 0xFEEDFACECAFEBEEF

l SYStem.Up

주의: 

• 비밀번호(키코드)를 모르거나 잘못된 경우(예: shadow row를 실수로 지운 이후), 프로세서는 영구적으로 잠깁니다.

플래시 내의 응용 프로그램이 프로세서 해제 기능을 제공하지 않는 한(예: CAN을 통해), 복구할 수 없습니다.

• 일부 프로세서들은 SYStem.Option.KEYCODE 의 상위 및 하위 32비트 부분을 교환해야 합니다.

(예: 0xFEEDFACECAFEBEEF 대신 0xCAFEBEEFFEEDFACE)

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다