하기 바람직한 실시예의 상세한 설명을 첨부 도면들을 참조하여 고려할 때, 본 발명을 보다 잘 이해할 수 있을 것이다.
도1은 본 발명을 따르는 소프트웨어 프로파일링 및 디버그 해결책을 이용하는 소프트웨어 디버그 환경의 블록도다.
도2는 본 발명에 따라 온칩 캐시를 통합한 예시적인 내장형 프로세서 제품의 상세사항들을 제공하는 블록도다.
도3은 본 발명에 따라 예시적인 트래이스 캐시와 내장형 프로세서 제품의 다른 부품들간의 관계를 기술하는 간략화된 블록도다.
도4는 본 발명의 일 실시예에 따라 소프트웨어 디버그 명령의 흐름을 설명하는 순서도다.
도5는 본 발명의 제2 실시예를 따르는 개선된 명령 흐름을 설명하는 순서도다.
도6A는 본 발명을 따르는 성능 프로파일 카운터 시퀀스를 설명하는 도다.
도6B는 본 발명을 따르는 소프트웨어 성능 프로파일링 정보를 보고하기 위한 트레이스 캐시 엔트리(entry) 집합의 일반적인 포맷을 설명하는 도다.
도7A-7G는 명령 실행 정보를 보고하기 위해 다양한 선택적인 트레이스 캐시 엔트리들의 일반적인 포맷을 설명하는 도다.
발명을 실행하기 위한 모드(들)
이제, 도면을 참조하면, 도 1은 본 발명이 고려하고 있는 용도를 나타내는 예시적인 소프트웨어 디버그 환경을 도시한다. 타겟 시스템(T)은 시스템 메모리(106)에 결합된 본 발명에 따른 내장형 프로세서 디바이스(102)를 포함하고 있는 것으로 도시된다. 이 내장형 프로세서 디바이스(102)는 프로세서 코어(104), 트레이스 캐시(200)(도 2) 및 디버그 포트(100)를 통합한다. 비록, 본 발명에서 중요한 것은 아니지만은, 이러한 내장형 프로세서 디바이스(102)는 애플리케이션 특정의 기능을 수행하기 위한 부가적인 회로(미도시)를 통합하거나, 또는 독립형 프로세서나 디지털 신호 프로세서의 형태를 취할 수 있다. 바람직하게는, 디버그 포트(100)는 IEEE-1149.1-1990에 따른 JTAG 인터페이스 또는 다른 유사한 표준화된 직렬 포트 인터페이스를 이용한다.
호스트 시스템(H)을 이용하여 디버그 제어 소프트웨어(112)를 실행시킴으로써, 하이 레벨 커맨드들을 전송하고, 타겟 시스템(T)에 의해 생성되는 디버그 정보의 추출 및 상기 타겟 시스템(T)에 의해 생성된 소프트웨어 성능 프로파일링 정보의 분석을 제어한다. 본 발명의 개시된 실시예의 호스트 시스템(H) 및 타겟 시스템(T)은 직렬 링크(110)를 통해 통신한다. 대부분의 컴퓨터들은 직렬 또는 병렬 인터페이스를 갖추고 있는바, 이러한 인터페이스는 그다지 비용을 들이지 않고 직렬 커넥터(108)에 의해 디버그 포트(100)에 접속될 수 있기 때문에, 다양한 컴퓨터들이 호스트 시스템(H)으로서 기능을 할 수 있다. 대안적으로, 직렬 커넥터(108)는 보다 고속의 JTAG-네트워크 변환 장치로 대체될 수 있다. 또한, 타겟 시스템(T)은 디버그/트레이스 정보를 내부적으로 분석하도록 구성될 수 있다.
도 2를 참조로 하면, 본 발명에 따른 내장형 프로세서 장치(102)의 상세사항들이 제공된다. 프로세서 코어(104) 외에, 도 2는 트레이스 캐시(200)를 이용 및 제어할 수 있는 디버그 포트(100)의 개선된 실시예의 여러 소자들을 기술한다. 당업자이면 명백히 알 수 있는 것처럼 많은 다른 구성들이 가능하며, 아래 기술된 여러 프로세서 장치(102) 부품들은 온칩 트레이스 캐시(200) 제공과 관련있는 이점들을 설명하기 위해 도시된것이다.
본 발명의 개시된 실시예의 트레이스 제어 회로(218) 및 트레이스 캐시(200)는 또한 소프트웨어 성능 프로파일링 정보를 포획하기 위해 협동할 수 있다. 또한, 트레이스 제어 회로(218)는 트레이스 패드(pad) 인터페이스 포트(220)나 트레이스 캐시(200)로의 "트레이싱"을 지원하여, 소프트웨어 성능 프로파일링 데이터의 포획을 선택적으로 활성화하기 위한 사용자 제어를 제공한다. 트레이스 제어 회로(218)에 의해 인에이블되는 다른 특성들은 아래에서 보다 상세히 기술되는 것처럼, 동기화 어드레스 생성의 프로그램 능력 및 사용자가 지정한 트레이스 기록들을 포함한다.
최소한으로서, 본 발명의 개시된 실시예의 소프트웨어 디버그 포트(100)에서는 오직 통상적인 JTAG 핀들 만을 지원할 필요가 있다. JTAG 핀들은 본질적으로 전송 메커니즘이 되는바, 이는 기존의 핀들을 이용하여, 프로세서 코어(104)에 의해 수행될 프로파일링 및 기타 커맨드들을 입력한다. 보다 구체적으로, JTAG 테스트 액세스 포트(TAP) 제어기(204)에 제공되어 이에 의해 구동되는 테스트 클럭 신호(TCK), 테스트 모드 선택 신호(TMS), 테스트 데이터 입력 신호(TDI) 및 테스트 데이터 출력 신호(TD0)는 통상적인 JTAG 지원 신호들로서, 당업자에게 알려져 있는 것들이다. 하기에서 보다 상세히 설명되는 바와 같이, 디버그 포트(100)의 "강화된" 실시예는 커맨드 확인 신호(CMDACK), 브레이크 요청/트레이스 포획 신호(BRTC), 전송 정지 신호(STOPTX) 및 트리거 신호(TRIG)를 표준 JTAG 인터페이스에 부가한다. 이러한 부가적인 신호들에 의해, 매우 정확한 외부 브레이크 포인트의 어서트(assertion) 및 모니터링이 가능해져, 내부 브레이크 포인트에 응답하여 외부 디바이스들을 트리거(trigger)시키고, JTAG 직렬 인터페이스의 상태 폴링(polling)을 제거한다. 이러한 "측파대" 신호들은 추가적인 기능을 제공하여, 디버그 포트(100)를 위한 통신 속도를 향상시킨다. 또한, 이러한 신호들은 개시된 내장형 프로세서 디바이스(102)의 특별한 본드 아웃 버전에 제공되는 임의의 병렬 포트(214)의 동작을 돕는다.
JTAG TAP 제어기(204)는 통상적인 JTAG 신호를 통한 표준 JTAG 직렬 데이터 및 제어를 받아들인다. DEBUG 명령이 JTAG 명령 레지스터에 기록되면, 직렬 디버그 시프터(212)는 JTAG 테스트 데이터 입력 신호(TDI) 및 테스트 데이터 출력 신호(TDO)에 접속되며, 이에 따라 커맨드들 및 데이터가 디버그 레지스터(210)에 로드되고 이로부터 판독될 수 있다. 본 발명의 개시된 실시예에서, 디버그 레지스터들(210)은 2개의 디버그 레지스터들(즉, 데이터를 전송하기 위한 디버그 레지스터(TX_DATA 레지스터) 및 데이터를 수신하기 위한 디버그 레지스터(RX_DATA 레지스터)), 명령 트레이스 구성 레지스터(ITCR) 및 디버그 제어 상태 레지스터(DCSR)를 포함한다.
제어 인터페이스 상태 머신(206)은 직렬 디버그 시프터(212) 및 디버그 레지스터들(210)로의/로부터의 데이터의 로딩/판독을 조정(coordinate)한다. 커맨드 디코드 및 처리 블록(208)은 커맨드/데이터를 디코드한 다음, 이들을 프로세서 인터페이스 논리(202) 및 트레이스 디버그 인터페이스 논리(216)로 디스패치시킨다. 다른 기능들을 수행하는 것 외에, 트레이스 디버그 인터페이스 논리(216) 및 트레이스 제어 논리(218)는 소프트웨어 성능 프로파일링의 통신 및 트레이스 캐시(200)로부터 TAP 제어기(204)로의 다른 트레이스 정보의 통신을 조정한다. 프로세서 인터페이스 논리(202)는 트레이스 제어 논리(218) 및 프로세서 코어(104)와 직접 통신한다. 하기에서 보다 상세히 설명되는 바와 같이, 병렬 포트 논리(214)는 제어 인터페이스 상태 머신(206) 및 디버그 레지스터들(210)과 통신하여, 내장형 프로세서 디바이스(102)의 임의의 본드 아웃 버전들에서 병렬 데이터 판독/기록 동작들을 수행한다.
(통상적인 JTAG 신호들 만을 이용하sms)디버그 포트(100)를 통해 소프트웨어 성능 프로파일링이 통신되기 전에, 이 포트(100)는 공개(public) JTAG 명령(DEBUG)을 TAP 제어기(204) 내에 포함된 JTAG 명령 레지스터 내에 기록함으로써 인에이블된다. 아래에 나타낸 바와 같이, 개시된 실시예의 JTAG 명령 레지스터는 38 비트 레지스터로서, 32 비트 데이터 필드(debug_data[31:0]), 디버그 포트(100)에 의해 제공되는 기능들 및 다양한 내부 레지스터들을 나타내기 위한 4 비트 커맨드 필드, 커맨드 미결 플래그(pending flag) 및 커맨드 완료 플래그를 포함한다. 어떠한 커맨드들은 debug_data 필드로부터의 비트들을 서브 필드(sub-field)로서 이용함으로써, 이용가능한 커맨드들의 수를 늘릴 수 있다.
JTAG 명령 레지스터이러한 JTAG 명령 레지스터는 테스트 모드 선택 신호(TMS)를 토글(toggle)함으로서 선택된다. 이 테스트 모드 선택 신호(TMS)는 스캔 경로 내의 JTAG의 클럭 공급 경로를 변경할 수 있게 하여, 다른 길이의 복수의 경로를 이용할 수 있게 한다. 바람직하게는, JTAG 명령 레지스터는 짧은 경로를 통해 액세스가 가능하다. 이 레지스터는 특정된 시스템 레지스터들 내로 로드되거나 또는 이들로부터 수신되는 값들을 홀딩하기 위한 "소프트" 레지스터를 포함하도록 구성된다.
다음으로, 도 3은 본 발명에 따른 내장형 프로세서 디바이스(102)의 예시적인 트레이스 캐시(200)와 다른 구성 요소들 간의 관계를 도시한 단순화된 블록도이다. 본 발명의 고려되는 일 실시예에서, 트레이스 캐시(200)는 가장 최근의 트레이스 엔트리들을 기록하는 128 엔트리의 선입선출(FIFO) 순환 캐시이다. 트레이스 캐시(200)의 사이즈를 증가시킴으로써, 포획될 수 있는 명령 트레이스 정보의 양을 증가시킬 수 있기는 하지만, 요구되는 실리콘 영역의 양이 증가할 수 있다.
하기에서 보다 상세히 설명되는 바와 같이, 본 발명의 개시된 실시예의 트레이스 캐시(200)는 프로세서 코어(104)에 의해 명령들이 실행되는 순서를 나타내는 다수의 20 비트(또는 이상)의 트레이스 엔트리들을 저장한다. 또한, 태스크 식별자들 및 트레이스 포획 정지/개시 정보 등의 다른 정보가 트레이스 캐시(200) 내에 배치될 수 있다. 트레이스 캐시(200)의 내용은 직렬 또는 병렬 트레이스 핀(230)을 통해 호스트 시스템(H) 등의 외부 하드웨어에 제공된다. 대안적으로, 타겟 시스템(T)은 트레이스 캐시(200)의 내용을 내부적으로 검사하도록 구성될 수 있다.
도 4는 표준 JTAG 인터페이스를 이용할 때의 커맨드 처리 과정의 하이 레벨 흐름도를 제공한다. 단계(400)에서 디버그 모드에 들어가면, 단계(402)에서 DEBUG 명령이 TAP 제어기(204)에 기록된다. 다음으로, 단계(404)에서, 커맨드 미결 플래그가 세트되고, 데이터 필드에 원하는 데이터가 있는 상태(이는 적용가능한 경우이며, 그렇지 않으면 0이다)로, 38 비트 직렬값이 총괄적으로 시프트인된다. 제어는 단계(406)로 진행되어, 미결 커맨드가 로드/언로드되고, 커맨드 완료 플래그가 체크된다. 커맨드의 완료는 전형적으로 데이터 레지스터와 프로세서 레지스터 또는 메모리/IO 위치 사이에서의 값의 전송을 수반한다. 커맨드가 완료된 후, 프로세서(104)는 커맨드 미결 플래그를 클리어하고 커맨드 완료 플래그를 세트시킴과 동시에, dl용가능한 경우에는 데이터 필드에 값을 저장한다. 38 비트 레지스터 전체를 스캔하여, 커맨드 완료 플래그 및 커맨드 미결 플래그를 모니터한다. 미결 플래그가 0으로 리셋되고 완료 플래그가 1로 세트되면, 이전 커맨드는 완료된다. 플래그들의 상태는 제어 인터페이스 상태 머신(206)에 의해 포획된다. 플래그 상태의 슬레이브 카피를 내부적으로 저장하여, 다음 명령을 로드해야 하는 지의 여부를 결정한다. 이러한 슬레이브 카피는 TAP 제어기(204)의 상태들 간에 플래그 상태의 변경 가능성때문에 유지된다. 이에 의해, 프로세서(104)는 다음 명령을 로드하기 전에 이전 명령이 완료되었는 지의 여부를 결정할 수 있다.
단계(408)에서 완료 플래그가 세트되지 않은 것으로 결정되면, 제어는 단계(410)로 진행되어, 38 비트 커맨드의 로드/언로드가 반복된다. 또한, 커맨드 완료 플래그가 체크된다. 그런 다음, 제어는 단계(408)로 돌아간다. 단계(408)에서 완료 플래그가 세트된 것으로 결정되면, 제어는 단계(406)로 돌아가 다음 커맨드를 처리한다. 통상적인 JTAG 프로세스를 통해, DEBUG 모드를 빠져나온다.
도 2를 다시 참조하여, 전술한 임의의 측파대 신호들을 강화된 디버그 포트(100)에 이용하여 추가 기능을 제공한다. 이러한 임의의 측파대 신호들은 브레이크 요청/트레이스 포획 신호(BRTC)를 포함하는바, 이는 디버그 제어/상태 레지스터에 세트되는 비트의 상태에 따라 브레이크 요청 신호 또는 트레이스 포획 인에이블 신호로서 기능할 수 있다. 이러한 브레이크 요청/트레이스 포획 신호(BRTC)가 브레이크 요청 신호로서 기능하도록 세트되는 경우, 이는 프로세서(104)가 디버그 모드에 들어가도록 어서트된다(이 프로세서(104)는 또한 통상적인 JTAG 신호들에 의해 홀트 커맨드(halt command)를 스캔함으로써 정지할 수 있다). 이러한 브레이크 요청/트레이스 포획 신호(BRTC)가 트레이스 포획 인에이블 신호로서 기능하도록 세트되는 경우, 이는 트레이스 포획을 인에이블시키도록 어서트된다. 이 신호를 디어서트(deassertion)시키면, 트레이스 포획이 정지된다. 이 신호는 검출된 후 다음 명령 경계에서 효력을 나타내고, 내부 프로세서 클럭과 동기된다. 브레이크 요청/트레이스 포획 신호(BRTC)는 언제라도 어서트될 수 있다.
트리거 신호(TRIG)는 내부 프로세서 브레이크 포인트가 어서트될 때 마다 펄싱하도록 구성된다. 이러한 트리거 신호(TRIG)는 논리 분석기 등의 외부 포획 디바이스를 트리거시키는 데에 이용될 수 있고, 트레이스 기록 포획 클럭 신호(TRACECLK)와 동기된다. 브레이크 포인트가 생성되면, 그 이벤트는 트레이스 포획 클럭 신호(TRACECLK)와 동기되며, 이후 트리거 신호(TRIG)는 트레이스 포획의 지속 기간에 동안 액티브 상태로 유지된다.
전송 정지 신호(STOPTX)는, 프로세서(104)가 DEBUG 모드에 들어가고, 레지스터 질문/변경, 디버그 포트(100)를 통한 메모리 또는 I/O 판독 및 기록의 준비가 될 때에 어서트된다. 본 발명의 개시된 실시예에서, 전송 정지 신호(STOPTX)는 디버그 제어 상태 레지스터(DCSR)의 비트 상태를 나타낸다. 전송 정지 신호(STOPTX)는 트레이스 포획 클럭 신호(TRACECLK)와 동기된다.
커맨드 확인 신호(CMDACK)는 도 5를 참조하여 설명되는바, 도 5는 도 2의 강화된 디버그 포트(100)에 있어서의 간략화된 커맨드 처리 과정을 나타낸다. 타겟 시스템(T)이 DEBUG 모드에 들어가도록 하기 위해, 단계(502)에서 DEBUG 명령이 TAP 제어기(204)에 기록된다. 제어는 단계(504)로 진행되어, 호스트 시스템(H)에 의해 커맨드 확인 신호(CMDACK)가 모니터되어 커맨드 완료 상태를 결정한다. 이 신호는 커맨드 완료 플래그와 동시에 타겟 시스템(T)에 의해 하이로 어서트되어, 다음 시프트 주기가 시작될 때 까지 하이로 유지된다. 이러한 커맨드 확인 신호(CMDACK)를 이용할 때, 커맨드 완료 플래그 상태를 포획하기 위해 JTAG 명령 레지스터를 시프트 아웃시킬 필요는 없다. 이러한 커맨드 확인 신호(CMDACK)는, 커맨드 완료 플래그가 0에서 1로 변경된 후, 테스트 클럭 신호(TCK)의 다음 상승 에지에서 하이로 천이한다. 강화된 JTAG 신호를 이용할 때, 커맨드 확인 신호(CMDACK) 핀이 하이로 어서트될 때 까지는 호스트 시스템(H)에 의해 새로운 시프트 시퀀스(단계(506))가 개시되지 않는다. 커맨드 확인 신호(CMDACK)는 테스트 클럭 신호(TCK)와 동기된다. 이 테스트 클럭 신호(TCK)는 항상 클럭될 필요는 없지만, 커맨드 확인 신호(CMDACK)의 응답을 기다릴 때에 연속적으로 클럭되는 것이 이상적이다.
디버그 포트(100)를 경유하는 운영체제/응용 통신
디버그 레지스터 블록(210)에는 또한 명령 트레이스 구성 레지스터(ITCR)가 포함된다. 이러한 32 비트 레지스터는 명령 트레이스 디버그 기능들 및 소프트웨어 성능 프로파일의 인에이블링/디스에이블링 및 구성을 제공한다. 하기의 표에 나타낸 부가적인 기능들 뿐 아니라, 다양한 트레이싱 레벨들, 트레이스 동기 강제 카운트, 트레이스 초기화, 명령 트레이싱 모드들, 클럭 분주비 정보를 포함하는 이러한 많은 기능들이 고려된다. ITCR은, 디버그 레지스터 블록(210)의 다른 레지스터들의 경우에서처럼, JTAG 명령 레지스터 기록/판독 커맨드를 통해 또는 예약된 명령에 의해 액세스된다.
비트 |
기호 |
설명/기능 |
31:30 |
Reserved |
지정된 |
29 |
RXINTEN |
RX 비트가 설정될 시 인터럽트를 인에이블한다 |
28 |
TXINTEN |
TX 비트가 설정될 시 인터럽트를 인에이블한다 |
27 |
TX |
타겟 시스템(T)이 데이터를 호스트 시스템(H)에 전송할 준비를 하고 그리고 데이터가 TX_DATA 레지스터에서 이용될 수 있음을 나타낸다 |
26 |
RX |
데이터가 호스트로부터 수신되어 RX_DATA 레지스터에 배치되었음을 나타낸다 |
25 |
DISL1TR |
레벨 1 트레이싱을 디스에이블한다 |
24 |
DISL0TR |
레벨 0 트레이싱을 디스에이블한다 |
23 |
DISCSB |
현 세그먼트 베이스 트레이스 기록을 디스에이블한다 |
22:16 |
TSYNC[6:0] |
동기화 어드레스 기록이 강제되기 전에 트레이스 제어 블록(218)이 출력할 분기 시퀀스 트레이스 기록들의 최대 숫자를 설정한다 |
15 |
TSR3 |
트레이스 모드를 DR3 트랩(TRAP)상에 설정하거나 클리어한다 |
14 |
TSR2 |
트레이스 모드를 DR2 트랩(TRAP)상에 설정하거나 클리어한다 |
13 |
TSR1 |
트레이스 모드를 DR1 트랩(TRAP)상에 설정하거나 클리어한다 |
12 |
TSR0 |
트레이스 모드를 DR0 트랩(TRAP)상에 설정하거나 클리어한다 |
11 |
TRACE3 |
DR3를 이용하는 트레이스 모드 토글링을 인에이블한다 |
10 |
TRACE2 |
DR2를 이용하는 트레이스 모드 토글링을 인에이블한다 |
9 |
TRACE1 |
DR1을 이용하는 트레이스 모드 토글링을 인에이블한다 |
8 |
TRACE0 |
DR0을 이용하는 트레이스 모드 토글링을 인에이블한다 |
7 |
TRON |
트레이스 온/오프 |
6:4 |
TCKL[2:0] |
내부 프로세서 클럭과 TRACECLK 간에 인코딩된 분할기 비율 |
3 |
ITM |
내부 또는 외부 (본드-아웃)명령 트레이싱 모드를 설정한다 |
2 |
TINIT |
트레이스 초기화 |
1 |
TRIGEN |
DCSR에서 디버그 트랩 인에이블 기능을 제외한 어떤 리거시(legacy) 디버그 정지점을 수신한 다음에 외부 트리거 신호(TRIG)의 펄스를 내보내도록 인에이블한다 |
0 |
GTEN |
내부 트레이스 버퍼를 통하여 또는 외부 (본드-아웃) 인터페이스를 통해 명령 트레이싱을 위한 전체적인 인에이블 |
명령 트레이스 구성 레지스터(ITCR)
또 하나의 디버그 레지스터인 디버그 제어/상태 레지스터(DCSR)는 프로세서(104)가 디버그 모드로 들어갔을 시의 표시를 제공하여 프로세서(104)가 개선된 JTAG 인터페이스를 통해 강제로 DEBUG 모드로 들어가게하여 준다. 아래 테이블에 도시된 것처럼, DCSR은 또한 프로세서(104)로 준비된 신호를 강제하고, 디버그 포트를 통해 시작된 액세를 위해서 메모리 액세스 공간을 제어하고, DEBUG 모드로 들어가는데로 캐시 플러시(flush)를 디스에이블하고, TX 및 RX 비트들, 병렬 포트(214) 인에이블, 강제된 중단들, 강제된 전체적인 재설정, 및 다른 기능들과 같은 여러가지 제어 특성들을 인에이블한다. ITCR 또는 DCSR에서 여러 비트들의 배열 또는 존재는 본 발명의 동작에 결정적인 것으로 고려되지 않는다.
비트 |
기호 |
설명/기능 |
31:12 |
Reserved |
지정된 |
11 |
TX |
타겟 시스템(T)이 데이터를 호스트 시스템(H)에 전송할 준비를 하고 그리고 데이터가 TX_DATA 레지스터에서 이용될 수 있음을 나타낸다 |
10 |
RX |
데이터가 호스트로부터 수신되어 RX_DATA 레지스터에 배치됨을 나타낸다 |
9 |
DISFLUSH |
DEBUG 모드로 들어가는 데로 캐시 플러시를 디스에이블한다 |
8 |
SMMSP |
디버그 포트(100)를 통해 시작된 액세스를 위해서 메모리 액세스 공간(정상적인 메모리 공간/시스템 관리 모드 메모리)을 제어한다 |
7 |
STOP |
프로세서(104)가 (정지 전송 신호(STOPTX)와 등가인)DEBUG 모드에 있는지를 나타낸다 |
6 |
FRCRDY |
프로세서(104)로 준비된 신호(RDY)를 강제하여 하나의 프로세서 클럭을 위해 펄스가 발생되게 한다; 프로세서(104)가 비응답 장치로부터 준비된 신호를 기다리면서 정지하여 있는 것이 명백할 시 유용하다. |
5 |
BRKMODE |
중단 요청/트레이스 포획 신호(BRTC(break request or trace capture on/off))의 기능을 선택한다 |
4 |
DBTEN |
엔트리를 디버그 모드로 인에이블하거나 또는 프로세서(104) 레지스터들(DR0-DR7) 또는 다른 리거시 디버그 트랩/장애 메커니즘을 통해 트랩/장애상의 트레이스 모드 인에이블을 토글한다 |
3 |
PARENB |
병렬 포트(214)를 인에이블한디 |
2 |
DSPC |
정지 승낙 상태들에서 내부 프로세서 클럭들의 정지를 디스에이블한다 |
1 |
FBRK |
(외부 BRTC 핀에 펄스를 보내는것과 등가인)다음 명령 경계에서 프로세서(104)를 DEBUG 모드로 강제한다 |
0 |
FRESET |
전체적인 재설정을 강제한다 |
디버그 제어/상태 레지스터(DCSR)
도 1과 같은 교차(cross) 디버그 환경에 있을 때에, 타겟 시스템(T) 상에서 실행되는 페어런트 태스크(parent task)는 이 타겟 시스템(T)을 제어하는 호스트 플랫폼에 정보를 전송할 필요가 있다. 이러한 데이터는, 예를 들어 printf() 호출로부터의 문자 스트림 또는 태스크 제어 블록(TCB)으로부터의 레지스터 정보를 포함할 수 있다. 데이터를 전송하기 위해 고려되는 하나의 방법은 운영 체제가 데이터를 알려진 영역에 배치한 다음, 트랩 명령에 의해, DEBUG 모드에 들어가게 하는 것이다.
이후, 호스트 시스템(H)은 디버그 포트(100) 커맨드들에 의해, DEBUG 모드에 들어간 이유를 결정하고, 예약된 영역으로부터 데이터를 검색함으로써 응답할 수 있다. 하지만, 프로세서(104)가 DEBUG 모드에 있는 동안, 정상적인 프로세서 실행은 정지된다. 상기 설명한 바와 같이, 이것은 많은 실시간 시스템들에 대해서는 바람직하지 않다.
본 발명에 따르면, 이러한 상황은 디버그 포트(100)에 2개의 디버그 레지스터들, 즉 데이터를 전송하기 위한 디버그 레지스터(TX_DATA 레지스터) 및 데이터를 수신하기 위한 디버그 레지스터(RX_DATA 레지스터)를 제공함으로써 대처된다. 이러한 레지스터들은 소프트 어드레스 및 JTAG 명령 레지스터 커맨드들을 이용하여 액세스될 수 있다. 상기 설명한 바와 같이, 호스트 시스템(H)이 JTAG 명령 레지스터에 디버그 명령을 기록한 후, 직렬 디버그 시프터(212)는 테스트 데이터 입력 신호(TDI) 라인 및 테스트 데이터 출력 신호(TDO) 라인에 결합된다.
프로세서(104)가 코드를 실행하고, 이에 의해 데이터를 전송시키면, 먼저 ITCR의 TX 비트를 테스트한다. TX 비트가 0으로 세트되어 있는 경우, 프로세서(104)는 프로세서 명령(메모리 또는 I/O 기록중 어느 하나)을 실행시켜, 데이터를 TX_DATA 레지스터에 전송한다. 디버그 포트(100)는 DCSR 및 ITCR에 TX 비트를 세트시켜, 호스트 시스템(H)에게 데이터를 전송할 준비가 되어 있음을 나타낸다. 또한, STOPTX 핀이 하이로 세트된다. 호스트 시스템(H)이 TX_DATA 레지스터로부터의 전송 데이터의 판독을 완료한 후, TX 비트는 0으로 세트된다. 이후, ITCR에 TXINTEN 비트가 세트되어, 프로세서(104)에 인터럽트 신호를 발생시킨다. 이러한 인터럽트는, ITCR 내의 TX 비트가 0으로 천이될 때에만 발생된다. TXINTEN 비트가 세트되지 않는 경우, 프로세서(104)는 ITCR을 폴링하여, 데이터를 더 전송하기 위해 TX 비트의 상태를 결정한다.
호스트 시스템(H)이 데이터를 전송하기를 원하면, 이는 먼저 ITCR 내의 RX 비트를 테스트한다. RX 비트가 0으로 세트되어 있으면, 호스트 시스템(H)은 RX_DATA 레지스터에 데이터를 기록하고, RX 비트는 DCSR 및 ITCR 모두에서 1로 세트된다. 이후, RXINT 비트가 ITCR에 세트되어, 프로세서(104)에 대한 인터럽트 신호를 발생시킨다. 이러한 인터럽트는, ITCR 내의 RX 비트가 1로 천이될 때에만 발생된다. RXINTEN 비트가 세트되지 않았으면, 프로세서(104)는 ITCR을 폴링하여, RX 비트의 상태를 검증한다. RX 비트가 1로 세트되는 경우, 프로세서 명령을 실행하여 RX_DATA 레지스터로부터 데이터를 판독한다. 프로세서(104)에 의해 RX_DATA 레지스터로부터 데이터가 판독된 후, RX 비트는 0으로 세트된다. 호스트 시스템(H)은 ITCR을 연속적으로 판독하여, 데이터를 더 전송하기 위해 RX 비트의 상태를 결정한다.
이러한 기술에 따르면, 운영 체제 또는 애플리케이션은 프로세서(104)의 실행을 정지시키지 않으면서 호스트 시스템(H)과 통신할 수 있다. 통신은 디버그 포트(100)를 통해 편리하게 이루어짐으로써, 온칩 애플리케이션 자원들에 대한 영향을 최소화한다. 경우에 따라서는, 시스템 인터럽트를 디스에이블시킬 필요가 있다. 이 때문에, 프로세서(104)는 RX 비트 및 TX 비트를 검사할 필요가 있다. 이러한 상황에서, 통신 링크는 폴링 모드로 구동된다.
디버그 포트(100)로의 병렬 인터페이스
일부 내장형 시스템들은 I/O 및 데이터 처리 동작들을 유지하면서 명령 트레이스를 검사할 것을 요구한다. 멀티태스킹 운영 체제를 이용하지 않는 경우에는, 내장형 프로세서 디바이스(102)의 본드 아웃 버전이 트레이스 데이터를 제공하는 것이 바람직한데, 이는 디버그 포트(100)를 통해 트레이스 캐시(200)를 검사하기 위해서는 프로세서(104)를 정지시킬 필요가 있기 때문이다.
본 발명의 개시된 실시예에서는, 병렬 포트(214)가 내장형 프로세서 디바이스(102)의 임의의 본드 아웃 버전에 제공되어, 디버그 포트(100)에 병렬 커맨드 및 데이터 액세스를 제공한다. 이 인터페이스는 16 비트 데이터 경로를 제공하는바, 이는 트레이스 패드 인터페이스 포트(220)에 의해 다중화된다. 보다 구체적으로, 병렬 포트(214)는 16 비트 폭의 양방향 데이터 버스(PDATA[15:0]), 3 비트 어드레스 버스(PADR[2:0]), 병렬 디버그 포트 판독/기록 선택 신호(PRW), 트레이스 유효 신호(TV) 및 명령 트레이스 기록 출력 클럭(TRACECLOCK(TC))을 제공한다. 트레이스 패드 인터페이스 포트(220)에 의해 공유되지는 않지만, 병렬 버스 요청/허가 신호 쌍(PBREQ/PBGNT)이 또한 제공된다. 병렬 포트(214)는 DCSR에 비트를 세트시킴으로써 인에이블된다. 병렬 포트(214)가 인에이블될 때, 디버그 포트(100)를 통한 직렬 통신은 디스에이블되지 않는다.
병렬 포트(214)는 주로 타겟 시스템(T)의 메모리로의/로부터의 고속 다운로드/업로드에 이용하도록 의도된다. 하지만, 이러한 병렬 포트(214)는 프로세서 (104)가 정지했을 때에는 언제라도 타겟 시스템(T)과의 모든 디버그 통신에 이용될 수 있다. (표준 또는 강화된) 직렬 디버그 신호들은, 프로세서(104)가 명령들을 실행하고 있을 때 타겟 시스템(T)으로의 디버그 액세스를 위해 이용된다.
JTAG 표준과 유사한 방식으로, 병렬 포트(214)에 대한 모든 입력들은 테스트 클럭 신호(TCK)의 상승 에지에서 샘플링되고, 모든 출력들은 테스트 클럭 신호(TCK)의 하강 에지에서 변경된다. 개시된 실시예에서, 병렬 포트(214)는 트레이스 패드 인터페이스(220)와 핀들을 공유함으로써, 프로세서(104)가 정지되고 트레이스 패드 인터페이스(220)가 공유 버스로부터 접속이 끊기는 동안에만 병렬 커맨드들의 개시를 요구한다.
병렬 버스 요청 신호(PBREQ) 및 병렬 버스 허가 신호(PBGNT)는, 트레이스 캐시(200)와 병렬 포트(214) 간의 공유 버스 신호의 다중화를 촉진시키기 위해 제공된다. 병렬 포트(214)에 대한 호스트 인터페이스가, 병렬 버스 요청 신호(PBREQ)가 어서트되었음을 결정하면, 이는 병렬 포트(214) 신호들을 구동하기 시작하고, 병렬 버스 허가 신호(PBGNT)를 어서트한다.
병렬 포트(214)가 인에이블된 상태로, DEBUG 모드에 들어가거나 또는 빠져나올 때에는, 직렬 포트(214)를 프로세서 상태 보존(save) 및 복원 주기를 위해 이용한다. 병렬 버스 요청 신호(PBREQ)는, DEBUG 모드에 들어가기전, 상태 보존 순서가 시작되기 직전에 어서트된다. 마지막 복원 상태 주기에 대해, 병렬 버스 요청 신호(PBREQ)는 기록 데이터를 래치한 후 디어서트된다. 병렬 포트(214)의 호스트 인터페이스는, 그 병렬 포트 구동기들을 3 상태로 하고 병렬 버스 허가 신호(PBGNT)를 디어서트함으로써 병렬 버스 요청 신호(PBREQ)의 디어서트에 응답한다. 이후, 병렬 포트(214)는 디버그 트레이스 포트 핀 구동기들을 인에이블시키고, 마지막 복원 상태 주기를 완료하고, 커맨드 확인 신호(CMDACK)를 어서트하고, 그리고 인터페이스의 제어를 트레이스 제어 논리(218)에 리턴시킨다.
병렬 포트(214)를 통해 통신할 때, 어드레스 핀들(PADR[2:0])은 JTAG 명령 레지스터의 필드 선택에 이용되는바, 이는 하기의 표에 나타낸 바와 같이 16 비트 데이터 버스(PDATA[15:0])로 맵핑된다.
PADR[2:0] |
데이터 선택 |
000 |
선택 없음(널(null) 동작) |
001 |
4비트 커맨드 레지스터; PDATA[3:0]상에 구동된 커맨드 |
010 |
상위 16비트의 debug_data |
011 |
하위 16비트의 debug_data |
100 - 111 |
지정됨 |
debug_data[31:0] 레지스터의 한쪽 절반 만이 이용되는 경우(예를 들어 8 비트 I/O 주기 데이터 기록 등), 이러한 debug_data [31:0] 레지스터의 양쪽 절반을 모두 갱신할 필요는 없다. 커맨드 미결 플래그는, 4 비트 커맨드 레지스터에 기록 동작을 수행할 때 자동으로 세트되고, 커맨드 완료 플래그가 어서트되면 클리어된다. 호스트 시스템(H)은 커맨드 확인 신호(CMDACK)를 모니터하여, 완료 플래그가 언제 어서트되었는 지를 결정할 수 있다. 병렬 포트(214)를 이용하게 되면, 프로세서 코어(104)를 감속시키지 않으면서 실행 히스토리를 완전하게 볼 수 있다. 필요한 경우, 트레이스 캐시(200)를 병렬 포트(214)에 대한 버퍼로서 이용하도록 구성하여, 어떠한 대역폭 정합 문제를 제거할 수 있다.
운영체제 및 디버거 통합
본 발명의 개시된 실시예에서, 트레이스 캐시(200)를 포함하는 모든 디버그 지원 특징들의 동작은 디버그 포트(100)를 통해 또는 프로세서 명령들에 의해 제어될 수 있다. 이러한 프로세서 명령들은 모니터 프로그램, 타겟 호스트 디버거, 또는 통상적인 포드 웨어(pod-wear)로부터 비롯될 수 있다. 디버그 포트(100)는 프로세서 명령들에 의해서가 아닌 직렬 데이터 포트 커맨드들에 의해 개시되는 데이터 이동을 수행한다.
통상적인 포드 공간으로부터의 프로세서의 동작은 모니터 프로그램으로부터 DEBUG 모드에서 동작하는 것과 매우 유사하다. 모든 디버그 동작들은 프로세서 명령들에 의해 제어될 수 있다. 이러한 명령들이 포드 공간으로부터 온것이든, 아니면 통상적인 메모리로부터 온것이든 상관없다. 이에 의해, 부가적인 디버그 능력을 포함하도록 운영 체제가 확장될 수 있다.
물론, ptrace() 등의 특권 시스템 호출을 통해, 운영 체제들은 오랫동안 디버거를 지원해왔다. 하지만, 이제는, 온칩 트레이스 캐시(200)를 통합함으로써, 운영 체제는 소프트웨어 성능 프로파일링 및 명령 트레이스 능력을 제공할 수 있게 되었다. 트레이스 능력은 종종 실시간 응용에서 중요한 것으로 고려된다. 본 발명에 따른 디버그 환경에서는, "외부" 논리 분석기 또는 회로내 에뮬레이터를 통합하지 않으면서도, 한정된 트레이스를 지원하도록 운영 체제를 강화할 수 있다.
트레이스 캐시(200)의 내용의 내부 로딩 및 검색을 지원하는 데에 이용되는 명령들의 예로는, 로드 명령 트레이스 캐시 기록 커맨드(LITCR) 및 저장 명령 트레이스 캐시 기록 커맨드(SITCR)를 포함한다. 커맨드(LITCR)는, 프로세서 코어(104)의 EAX 레지스터의 내용과 함께, 트레이스 캐시 포인터(ITREC.PTR)에 의한 지정에 따라 트레이스 캐시(200) 내에 인덱스 기록을 로드한다. 트레이스 캐시 포인터(ITREC.PTR)는, 커맨드(LITCR)의 일반적인 동작이 다음과 같이 되도록 선증가(pre-increment)된다:
ITREC.PTR <_ ITREC.PTR + 1
ITREC[ITREC.PTR] <_ EAX
명령 트레이스 기록(하기의 트레이스 기록 포맷의 설명 참조)이 EAX 기록보다 작은 경우에는, EAX 레지스터의 일부 만이 이용된다.
유사하게, 저장 명령 트레이스 캐시 기록 커맨드(SITCR)는 트레이스 캐시(200)로부터 인덱스 기록을 검색하여 (EAX 레지스터에) 저장하는 데에 이용된다. 프로세서 코어(104)의 ECX 레지스터의 내용은 트레이스 캐시(200) 내의 인덱스를 생성하기 위해 트레이스 캐시 포인터(ITREC.PTR)에 부가되는 오프셋으로서 이용된다. ECX 레지스터는 트레이스 캐시 포인터(ITREC.PTR)는 영향을 받지 않는 동안 후증가(post-increment)되며, 이에 따라 다음과 같이 된다:
EAX <_ ITREC[ECX + ITREC.PTR]
ECX <_ ECX + 1
LITCR 및 SITCR 커맨드들의 포맷에 대한 여러 변형들은 당업자들에게 명백해질 것이다.
운영 체제를 확장하여 온칩 트레이스를 지원하는 것은 통신 산업에서 장점들을 갖는다. 태스크가 트레이스되는 동안, 시스템 I/O 및 통신 활동을 유지하는 것이 가능해진다. 통상적으로, 회로내 에뮬레이터를 이용하게 되면, [ptrace()와 달리] 프로세서의 상태 및 트레이스를 검사하기 위해서는 프로세서를 정지시킬 필요가 있었다. 이 때문에, I/O 데이터 프로세싱의 연속적인 지원이 중단된다.
또한, 트레이스 캐시(200)는 현장(field)의 장치와 함께 이용될 때에 매우 유용하다. 예기치 않은 시스템 고장이 발생하는 경우에는, 트레이스 캐시(200)를 조사하여 고장 이벤트에 이를 때까지의 실행 히스토리를 관찰할 수 있다. 전력 소모가 문제가 되는 휴대용 시스템들 또는 다른 환경들에서 이용될 때, 트레이스 캐시(200)는 필요에 따라 전력 관리 회로에 의해 디스에이블될 수 있다.
모범적인 트레이스 기록 포맷
본 발명의 개시된 실시예에서, 명령 트레이스 기록은 20 비트 폭이고, TCODE(트레이스 코드) 및 TDATA(트레이스 데이터)의 2개의 필드와 유효 비트(V)로 이루어진다. TCODE 필드는 TDATA 필드 내의 데이터의 타입을 식별하는 코드이다. TDATA 필드는 디버그 목적을 위해 이용되는 소프트웨어 트레이스 정보를 포함한다.
본 발명의 고려되는 일 실시예에서, 내장형 프로세서 디바이스(102)는 하기의 표에 나타낸 11개의 서로 다른 트레이스 코드들을 보고한다.
TCODE # |
TCODE 유형 |
TDATA |
0000 |
분실된 트레이스 |
유효하지 않음 |
0001 |
조건 분기 |
분기 시퀀스를 포함한다 |
0010 |
분기 타겟 |
분기 타겟 어드레스를 포함한다 |
0011 |
이전 세그먼트 베이스 |
이전 세그먼트 베이스 어드레스 및 속성들을 포함한다 |
0100 |
현 세그먼트 베이스 |
현 세그먼트 베이스 어드레스 및 속성들을 포함한다 |
0101 |
인터럽트 |
예외 또는 인터럽트의 벡터 번호를 포함한다 |
0110 |
트레이스 동기화 |
가장 최근 실행된 명령의 어드레스를 포함한다 |
0111 |
다중 트레이스 |
복수의 기록들을 갖는 엔트리의 제2 또는 제3 기록을 포함한다 |
1000 |
트레이스 정지 |
트레이스 포획이 정지된 명령 어드레스를 포함한다 |
1001 |
유저 트레이스 |
유저가 지정한 트레이스 데이터를 포함한다 |
1010 |
성능 프로파일 |
성능 프로파일 데이터를 포함한다 |
트레이스 캐시(200)는 한정된 저장 용량을 갖기 때문에, 포획된 트레이스 데이터의 어느 정도의 양이 "압축"되는 것이 바람직하다. 트레이스 데이터를 포획함에 있어서, 하기의 설명은 트레이스되고 있는 프로그램의 이미지가 호스트 시스템(H)에 대해 이용가능한 것으로 가정한다. 프로그램 이미지(오브젝트 모듈)로부터 어드레스를 얻을 수 있다면, 이 어드레스는 트레이스 데이터에 제공되지 않는다. 바람직하게는, 명령 흐름을 중단하고 또한 그 타겟 어드레스가 어떻게든 데이터 의존성인 명령들만이 보고된다. 예를 들면, 이러한 "중단" 이벤트들은, 타겟 어드레스가 데이터 레지스터 또는 스택 등의 다른 메모리 위치로부터 제공되는 호출 명령들 또는 무조건 분기 명령들을 포함한다.
상기 표에 나타낸 바와 같이, 포획되는 다른 트레이스 정보에는, 트랩 또는 인터럽트 핸들러의 타겟 어드레스; 리턴 명령의 타겟 어드레스; 데이터 레지스터에 의존하는(그렇지 않으면, 필요한 모든 것은 분기가 테이큰이었는지의 여부를 나타내는 1 비트 트레이스 뿐이다) 타겟 어드레스를 갖는 조건 분기 명령; 및 가장 빈번하게는 절차 리턴으로부터의 어드레스들이 포함된다. 또한, 태스크 식별자들 및 트레이스 포획 정지/개시 정보 등의 다른 정보가 트레이스 캐시(200) 내에 배치될 수 있다. 트레이스 기록들의 정확한 내용 및 특징은 본 발명에서 중요한 것이 아니다.
도6A을 참조하면, 예시적인 성능 프로파일 카운터 시퀀스들이 에시된다. 본 발명을 따르는 시스템에서, 트리커 제어 레지스터들(219)은 특정 절차에 대해 경과된 실행 시간 측정 카운터를 시작 및 정지 시키도록 구성된다. 본 발명에서는 트리거 제어 레지스터들(219)의 정확한 실행이 중요한 것으로 고려되지는 않지만, 트리거 기능을 실행하기 위해 일반적인(몇몇 이전 마이크로프로세서 코어에 제공된 디버그 레지스터들(DR0-DR7)중 어떤 것과 같은) 정지점 레지스터들을 이용하는 것이 바람직하다. 더욱이, 본 발명의 개시된 실시예에서 일반적인 명령의 실행은 프로파일링 정보가 모이는 동안 인터럽트되지 않는다.
도6A를 보다 상세히 살펴보면, 제1 온칩 트리거 제어 레지스터(219a)는 특정 절차내의 엔트리상에서 제1 카운터를 트리거(시작)하도록 구성된다. 제2 트리거 제어 레지스터(219b)는 특정 절차의 서언내의 엔트리상에 있는 카운터를 정지시키는데 이용된다. 제1 카운터가 시작 트리거에 의해 시작될 때, 제1 카운터는 0으로 초기화된다. 정지 트리거가 제2 트리거 제어 레지스터(219b)가 지시한데로 생성될 때, 제1 카운터의 카운트 값이 TCODE=1010 트레이스 엔트리(도6B)를 이용하는 트레이스 캐시(200)내에 배치된다. 유사한 기술들이 인터럽트 핸들러 실행 시간과 같은 다른 매개변수들을 측정하는데 이용될 수 있다. 상술된 것처럼, 트리거 제어 레지스터(219)는 트리거 신호(TRIG)를 펄싱하기 위해, 그리고 실행 트레이스는 시작 및 정지될 프로그램 어드레스를 선택하는데 이용될 수 있다.
본 발명의 개시된 실시예에서, 제2 카운터가 이용된다. 제2 카운터는 연속적으로 가동하지만, 정지 트리거 이벤트 다음에 0으로 재설정된다. 정지 트리거 이벤트는 또한 제2 카운터 값이 트레이스 캐시(200)내에 배치되게 한다. 이같은 제2 카운터 값은 관심있는 절차의 발생 빈도수를 획득하는데 유용한 반면에, 제1 카운터는 절차의 실행 시간에 대한 정보를 제공한다.
도 6B를 참조하면, 본 발명에 따라 소프트웨어 성능 프로파일링 정보를 보고하기 위한 트레이스 캐시(200) 엔트리의 일반적인 포맷이 도시된다. 도시된 것처럼, 제1 카운터의 카운트 값은 TCODE=1010 트레이스 엔트리를 갖는 16비트 값을 이용하여 트레이스 캐시(200)내에 배치된다. 이 TCODE=1010 트레이스 엔트리는 제2 카운터 값을 반영하는 32비트 카운트 값을 포함하는 TCODE=0111 엔트리 쌍을 수반할 것이다.
본 발명의 일 실시예에서, 제1 및 제2 카운터들의 카운터 주파수(즉, 해상도)는 프로그램 가능하다. 그러한 프로그램 가능도는 매우 낮은 주파수 또는 높은 주파수 이벤트들을 프로파일링하는 경우 보다 더 나은 정확도를 고려해야 할 것이다. 예를 들면, 아래 테이블은 카운터를 위해서 2개의 교류 및 프로그램 가능 누적 주파수들을 설명한다.
카운터 주파수(ⓐ33MHz버스 속도) |
타이밍 해상도(4X 클럭 스케일링(scaling) |
최대 카운터 지속기간 :16비트 |
최대 카운터 지속기간: 32비트 |
1/2 버스 속도 |
60.6ns/8사이클 |
4ms |
260초 |
1/8 버스 속도 |
242ns/32사이클 |
15.9ms |
1,040초 |
특화된 레벨 링(ring) 0 또는 링 1을 입력할 때, 때때로 모든 카운팅(2개의 카운터들)을 정지시키는 것이 바람직하다. 이것이 시스템 호출 그리고 측정된 프로파일링 값들로부터 제거될 인터럽트들을 인에이블한다. 또한 2 이상의 지원 특성들은 인에이블링/디스에이블링 카운팅 수단을 포함하고, 그리고 2개의 카운트 값들을 동시에 재설정하여 병합할 수 있다. 본 발명의 개시된 실시예의 이런 양상은 절차가 감시되는 동안 발생하는 작업 컨텍스트(context) 스위칭을 돕는다. 주기적인 인터럽트 핸들러에 의해, 한번에 하나씩 절차들을 조사하는 것이 가능하다.
선택적인 오프칩 트레이스 포획 하드웨어와 함께 후처리 소프트웨어가 프로파일 데이터를 분석하는데 이용될 수 있다. 따라서, 트레이스 캐시(200)는 선택된 절차에서 소모된 실행 시간과 관련된 정보를 모으는데 활용된다. 일반적으로, 단지 한 절차만이 동시에 프로파일된다. 트레이스 캐시(200)를 조사함으로써, 절차에서 소모된 최소 평균 및 최대 시간이 (모인 샘플들의 한계내에서)결정될 수 있다. 또한 코드 범위 프로파일링 능력들은 시험 가동동안 실행되는 그리고 실행되지 않은 특정 어드레스들을 나타내기 위해서 부가될 수 있다. 트레이스 캐시(200)는 저장될 수 있는 가능한한 많은 수의 샘플을 이용하여 통계 분석이 실행되게한다.
도7A는 조건 분기 이벤트들을 보고하기 위한 모범적인 포맷을 예시한다. 15개의 분기 이벤트들 까지의 결과는 단일 트레이스 엔트리로 그룹화될 수 있다. 16비트 TDATA 필드(또는 "BFIELD")는 1비트 분기 결과 트레이스 엔트리들을 포함하고, 그리고 TCODE=0001 엔트리로서 라벨이 붙는다. TDATA 필드는 1로 설정되는 가장 왼쪽 비트를 제외하고는 초기에 클리어된다. 각각의 새로운 조건 분기를 만날 경우, 새로운 한 비트의 엔트리가 왼쪽에 부가되며, 그외의 다른 엔트리들은 1비트씩 오른쪽으로 이동하게 된다.
128 엔트리 트레이스 캐시(200)를 이용함으로서 320바이트의 정보가 저장될 수있다. 6개의 명령들마다 한 분기의 분기 주파수를 가정하면, 개시된 트레이스 캐시(200)는 따라서 1536개 명령들의 유효 트레이스 기록을 제공한다. 이 계산은 호출, 점프 및 귀환 명령들의 발생을 고려하지 않는다.
트레이스 제어 로직(218)은 프로세서 인터페이스 로직(202)에 의해 명령 실행을 감시한다. 분기 타겟 어드레스가 보고되어야 할 때, 현재의 조건 분기 TDATA 필드내에 포함된 정보는 15개의 엔트리들이 누적되지 않았음에도, 트레이스 제어 로직(218)에 의해 완성된 것으로 표기된다. 도7B에 도시된 것처럼, 타겟 어드레스(32비트 어드레스를 이용하는 프로세서 장치(102)에서)는 타겟 어드레스의 상위 16비트들을 제공하는 제1 엔트리(TCODE=0010) 및 타겟 어드레스의 하위 16비트들을 제공하는 제2 엔트리(TCODE=0111)와 함께 트레이스 엔트리 쌍내에 기록된다. 조건 점프 명령을 위해 분기 타겟 어드레스가 제공될 때, 보고된 분기를 위해서 어떤 1비트의 분기 결과 트레이스 엔트리도 나타나지 않는다.
시작 및 정지 트레이스 포획
도 7C를 참조하면, 예를 들어 태스크 콘텍스트 스위칭이 발생할 때 등의 프로그램 실행의 어떠한 섹션 동안, 트레이스 수집을 개시 및 정지하는 것이 바람직하다. 트레이스 포획이 정지되면, 어떤 트레이스 엔트리도 트레이스 캐시(200) 내에 넣어지지 않고, 트레이스 포트(214)의 본드 아웃 핀에도 나타나지 않는다. 트레이스 포획을 인에이블 및 디스에이블하기 위해 다양한 방법들이 고려된다. 예를 들어, x86 커맨드를 제공하거나, 또는 기존의 x86 커맨드를 이용하여 I/O 포트 위치에 있어서의 비트를 토글할 수 있다. 대안적으로, 온칩 브레이크 포인트 제어 레지스터들(미도시)이 트레이스 포획이 개시/정지되어야 하는 어드레스들을 나타내도록 구성될 수 있다. 트레이싱이 정지되면, 마지막 트레이스 어드레스를 기록하는 트레이스 엔트리(TCODE=1000, TCODE=0111)가 트레이스 스트림에 배치될 수 있다. 트레이싱이 재개되면, 현재 실행하고 있는 명령의 어드레스를 포함하는 트레이스 동기 엔트리(TCODE=0110, TCODE=0111)가 생성된다.
트레이싱이 정지되는 동안 발생하는 세그먼트 변화를 고려하는 것이 중요하다. 이러한 상황은, 도 6C에 나타낸 바와 같이, TCODE=1000 엔트리 직후에 현재 세그먼트 베이스 어드레스 엔트리(TCODE=0100, TCODE=0111)를 오게 하는 옵션을 선택함으로써 부분적으로 해결될 수 있다. 디버그 모드로 들어가기 전에 트레이스의 끝에서 현재 세그먼트 베이스 어드레스 엔트리를 인에이블시키는 구성 옵션 또한 가능하다. 대조적으로, 인터럽트가 발생할 때 등의, 베이스가 변경되지 않을 때에 세그먼트 베이스 정보를 제공하는 것은 바람직하지 않다.
도 7D를 참조하여, 인터럽트 또는 트랩 등의 비동기 또는 동기 이벤트의 발생에 이어서, TCODE=0101 트레이스 엔트리가 생성되어 타겟 인터럽트 핸들러의 어드레스를 제공한다. 하지만, 인터럽트 엔트리 직전에 트레이스 동기(TCODE=0110) 엔트리를 생성함으로써 인터럽트되는 명령의 어드레스, 및 이전 세그먼트 베이스 어드레스(TCODE=0011)를 기록하는 것이 또한 바람직하다. 트레이스 동기 엔트리는 인터럽트 핸들러가 개시되기 전에 퇴거된 마지막 명령의 어드레스를 포함한다.
세그먼트 변경
도 7E는 세그먼트 파라미터들의 변경을 보고하는 데에 이용되는 트레이스 엔트리를 나타낸다. 트레이스 스트림을 처리할 때, 트레이스 어드레스 값들은 명령의 선형 어드레스를 결정하기 위해 세그먼트 베이스 어드레스와 조합된다. 베이스 어드레스 및 디폴트 데이터 오퍼랜드 사이즈(32 또는 16 비트 모드)는 변경될 수 있다. 그 결과, TCODE=0011 및 0111 엔트리들은 명령 흐름을 정확히 재구성하는 데에 필요한 정보를 제공하도록 구성된다. TCODE=0011 엔트리에 대응하는 TDATA 필드는 이전 세그먼트 베이스 어드레스의 상위 16 비트를 포함하고, 관련된 TCODE=0111 엔트리는 (명령이 리얼 모드(real mode)로 실행되는지, 아니면 보호 모드로 실행되는지에 의존하여) 하위 15 비트 또는 4 비트를 포함한다. 또한, TCODE=0111 엔트리는 바람직하게는 현재 세그먼트 사이즈(32 비트 또는 16 비트)를 나타내는 비트, 동작 모드(리얼 모드 또는 보호 모드)를 나타내는 비트, 및 페이징(paging)이 이용되고 있는 지의 여부를 나타내는 비트를 포함한다. 세그먼트 정보는 일반적으로 현재 (타겟) 세그먼트가 아니라 이전 세그먼트에 관련된다. 현재 세그먼트 정보는 프로세서 코어(104)를 정지시키고 그 상태를 검사함으로써 얻어진다.
유저가 지정한 트레이스 엔트리
애플리케이션 프로그램 또는 운영 체제가 트레이스 스트림에 부가적인 정보를 부가하기를 원하는 경우가 있다. 이 때문에, 원하는 실행 위치에서 트레이스 스트림에 16 비트 데이터 값을 넣는 것을 가능하게 하는 x86 명령이 제공되는 것이 바람직하다. 이 명령은 I/O 공간으로의 이동으로서 구현될 수 있는바, 오퍼랜드는 메모리 또는 레지스터에 의해 제공된다. 프로세서 코어(104)가 이 명령을 실행하면, 사용자 특정의 트레이스 엔트리는 트레이스 제어 논리(218)에 의해 포획되어 트레이스 캐시(200) 내에 넣어진다. 도 7F에 나타낸 바와 같이, TCODE=1001 엔트리는 본 발명의 개시된 실시예에서 이러한 목적으로 이용된다. 이 엔트리는, 예를 들어 멀티태스킹 운영 체제에서 태스크 스위치가 발생할 때 이전 또는 현재 태스크 식별자를 제공한다.
트레이스 데이터의 동기화
프로세서 기반의 디바이스(102) 상에서 전형적인 소프트웨어를 실행할 때, 어드레스 값들을 포함하는 트레이스 엔트리는 거의 없다. 대부분의 엔트리들은 TCDOE=0001 포맷을 가지며, 1 비트가 조건 동작의 결과를 나타낸다. 하지만, 트레이스 스트림을 검사할 때, 데이터는 기존의 프로그램 어드레스와 관련해서만 검토될 수 있다. 예를 들어, 트레이스 캐시(200) 내의 가장 오래된 엔트리로부터 시작하여, 어드레스 엔트리까지의 모든 엔트리는 거의 이용되지 않는다. 알고리즘 동기는 전형적으로 타겟 어드레스를 제공하는 트레이스 엔트리로부터 시작된다.
트레이스 캐시(200)가 어드레스를 제공하는 어떤 엔트리도 포함하지 않는 경우, 트레이스 분석은 이루어질 수 없다. 이러한 상황은 드물지만, 일어날 수 있다. 이 때문에, 본 발명의 바람직한 실시예에서는, 동기 어드레스 정보의 주입을 제어하기 위한 동기 레지스터(TSYNC)가 제공된다. 이러한 동기 레지스터(TSYNC)가 0으로 세트되면, 트레이스 동기 엔트리들은 발생되지 않는다.
도7G는 트레이스 동기화 엔트리를 기술한다. 동작시, 카운터 레지스터는, 타겟 어드레스를 포함하는 트레이스 엔트리가 생성될 때 마다 동기 레지스터(TSYNC) 내에 포함되는 값으로 세트된다. 이 카운터는 다른 모든 트레이스 엔트리들에 대해 1씩 감소된다. 카운터가 0에 도달하면, 가장 최근에 퇴거된 명령(또는 대안으로는, 미결 명령)의 어드레스를 포함하는 트레이스 엔트리(TCODE=0110)가 삽입된다. 또한, 동기 엔트리가 트래이스 캐시(200)에 기록되면, 이는 트레이스 핀들(220)에도 나타남으로써, 전기능 ICE 장치에 대해 동기 트레이스 데이터의 충분한 이용가능성을 보장한다.
또한, 트레이스 엔트리 정보를 확장하여, 코드 범위 또는 실행 성능과 관련된 데이터를 포함할 수 있다. 이러한 정보는, 예를 들어 코드 테스트 및 성능 조정 등에 유용하다. 이러한 강화가 없다고 할지라도, 프로세서 코어(104)가 트레이스 캐시(200)를 액세스하는 것을 가능하게 하는 것이 바람직하다. 마이크로제어기 장치의 경우, 이러한 특징은 트레이스 캐시(200)를 메모리 공간 또는 I/O의 일부 내에 맵핑함으로써 달성될 수 있다. 보다 일반적인 방식은, 시스템 메모리로의 트레이스 캐시(200)의 데이터의 이동을 지원하는 명령을 포함한다.
이와같이, 소프트웨어 성능 프로파일링을 제공하기 위한 유연한 고성능의 해결책을 제공하는 프로세서 기반의 디바이스에 대해 설명했다. 이러한 프로세서 기반의 디바이스는 프로세서의 동작을 정지시키지 않으면서 프로세서 상에서의 명령 실행 흐름을 재구성하기 위한 트레이스 정보를 제공할 수 있는 명령 트레이스 캐시를 통합한다. 직렬 및 병렬 통신 채널들 모두를 제공하여, 트레이스 데이터를 외부 디바이스들에 통신한다. 개시된 온칩 명령 트레이스 캐시는 기존의 많은 해결책들에서 발생하는 다양한 대역폭 및 클럭 동기 문제들을 완화하고, 또한 저가의 외부 포획 하드웨어를 이용할 수 있게 한다.
본 발명의 상기의 개시 및 설명은 예시적인 것으로서, 본 발명의 정신을 벗어나지 않으면서 사이즈, 형태, 물질, 구성 요소, 회로 요소, 배선 및 컨택에 대한 다양한 변경 뿐 아니라, 예시되는 회로의 세부 사항, 구성 및 동작 방법에 대한 다양한 변경을 행할 수 있다.