실시간 오류 감지를 할 때엔 일반적으로 타협을 해야하기 마련입니다. 빠르게 샘플링하는 대신 데드 타임이 길거나, 연속적인 데이터를 사용하는 대신 속도가 느리거나 선택의 기로에 놓이게 됩니다. 확실히 말할 수 있는 것은 두 가지 방법 모두 이상적이지 않다는 것입니다. 그러나 테스트 장비를 보다 효과적으로 최적화할 수 있는 방법이 있습니다. VHDL 및 사용자 정의 가능한 테스트 장비를 사용하여 일시적인 오류 감지 프로그램을 직접 프로그래밍하는 것입니다. 그렇게 하면 실시간으로 FPGA에서 오류를 감지할 수 있으며 이미 사용하고 있는 테스트 및 검증 장비 내에서도 이용할 수행할 수 있습니다. 물론 저희도 FPGA 코드 작성이 전통적인 절차적 프로그래밍보다 더 어렵다는 평가를 받고 있다는 것을 알고 있습니다. 그러나 ChatGPT와 같은 차세대 대규모 언어 모델을 사용하면 그쪽 언어를 자세히 알지 못하더라도 쉽게 생산성을 높일 수 있습니다.
기존 방식
테스트 장비는 일시적인 오류 감지에 그다지 맞지 않습니다. 모니터링 및 탐지에는 일반적으로 두 가지 접근 방식이 있습니다.
- 속도는 빠르지만 주기적으로 쉼
- 속도는 낮지만 지속적으로 수행함
옵션 1은 오실로스코프를 사용합니다. 오실로스코프는 일반적으로 20%에서 99.9% 사이의 데드 타임을 가지므로 화면에서 일시적인 오류를 "보는" 것은 거의 불가능합니다. 이를 해결하는 한 가지 방법은 오실로스코프가 오류 감지를 수행하고 결과를 표시하도록 트리거를 설정하는 것입니다. 이 방법에는 몇 가지 단점이 있습니다. 첫째, 트리거 될 수 있는 오류에만 해당된다는 것, 둘째, 오류가 한 번 발생했는지 여부만을 확실하게 알 수 있습니다. 오류 수, 오류 비율, 오류 상태의 총 시간 등과 같은 항목은 확인할 수 없습니다.
옵션 2는 데이터 로거 또는 데이터 수집 장치를 사용합니다. 이 경우 컴퓨터는 모든 관련 신호를 실시간으로 모니터링하고 중간 값을 계산할 수 있습니다. 시스템은 오류 및 관련 매개변수를 감지합니다. 그러나 이 방법에도 단점이 있습니다. 이 방법을 사용하려면 적절한 프로그래밍 환경을 갖춘 컴퓨터가 필요할 뿐더러, 성능적으로 컴퓨터 성능, 계산의 복잡성, 그리고 컴퓨터와 데이터 수집 장치 간 연결 처리량에 따라 제한되는 최대 속도까지만 신호를 모니터링할 수 있다는 것입니다.
두 가지 접근 방식의 장점을 결합하는 것이 최적일 것입니다. 다시 말해, 낮은 샘플링 속도로 제한되지 않고 복잡한 과도 오류 조건을 감지하고 해당 매개변수를 실시간으로 측정하는 것입니다. 편리하게도 Moku 장치는 Instrument-on-Chip 아키텍처와 커스터마이즈 가능한 FPGA를 활용합니다. Moku 장치의 최대 15개 다른 기구(그림 1)와 함께 Moku Cloud Compile(MCC)은 맞춤형 계측을 위한 프로그래밍 환경을 제공합니다. MCC는 자신만의 FPGA 코드를 작성하고 이를 Moku에 배포하는 데 필요한 모든 인프라를 제공합니다.
그림 1: iPad 및 데스크탑 인터페이스를 갖춘 Moku 제품 라인업
예시: 과도한 전력 이벤트 감지
테스터가 일시적인 전원 이벤트에 대해 전원 시스템을 모니터링해야 한다고 가정해 보겠습니다. 시스템은 최대 총 전력으로 평가되지만 실제로 이벤트 비율, 이벤트 시간 및 오류 상태의 총 시간이 임계값 미만인 한 일시적인 과전력을 견딜 수 있습니다. 따라서 우리는 다음을 수행할 수 있는 테스트 장비를 설계하고자 합니다.
- 시스템의 한 지점을 통해 전력을 모니터링합니다. 전압과 전류를 모니터링한 후 전력을 계산합니다.
- 전력이 임계값을 초과하는 횟수를 계산합니다.
- 전력이 임계값을 초과한 총 시간을 기록합니다.
여기에 한 결함의 최대 지속 시간, 결함 조건의 총 에너지 등을 기록할 수도 있지만 지금은 이 세 단계 만으로 제한하겠습니다.
이는 오실로스코프를 사용하여 수행하는 것처럼 간헐적인 모니터링에는 적합하지 않습니다. 오실로스코프에 대한 입력이 전압과 전류일 때 오실로스코프는 전력 레벨에서 트리거해야 합니다. 트리거 회로에 대한 입력으로 실시간 계산을 사용할 수 있는 시스템은 거의 없습니다.
시스템 매개변수에 따라 데이터 수집 방식에도 적합하지 않습니다. 현대 전력 시스템은 고속 과도 전류에 의해 손상될 수 있으므로 높은 데이터 수집 속도가 필요합니다. 하지만 이러한 전력 시스템은 일반적으로 장시간 연속 사용을 위해 설계되므로 시스템의 동작에 대한 확신을 얻기 위해 모니터링해야 하는 시간 또한 매우 길어질 수 있습니다. 이러한 요인들이 결합되어 데이터 양이 매우 증가하고 비용과 복잡성이 증가합니다.
맞춤형 Instrument-on-Chip을 배치하면 최적인 상황입니다. ChatGPT를 사용하면 이를 구축하는 데 어떻게 도움이 되는지 살펴보겠습니다.
맞춤형 오류 감지를 위한 ChatGPT
첫째, ChatGPT는 설명을 매우 구체적으로 제공될 때 최고의 성능을 발휘합니다. 우리가 해결하고자하는 거시적 문제를 미시적인 크기로 나눠서 설명해봅시다. 이렇게 하면 완전 사람 하고 똑같네요!
다음으로 그림 2의 오류 이벤트 수를 계산하는 VHDL 엔터티를 요청합니다.
그림 2: VHDL 기반 오류 카운터에 대한 ChatGPT 프롬프트.
다음으로 결함 상태의 총 시간에 대한 카운터를 추가합니다(그림 3).
그림 3: ChatGPT에 프로그램에 카운터를 추가하라는 메시지 표시.
마지막으로 오류 조건 임계값을 VHDL 엔터티에 포트로 추가하여 런타임에 구성 가능하도록 만듭니다(그림 4). 최종 MCC 구현에서 이 임계값은 제어 레지스터에 연결되므로 전체 계측기를 재구성하지 않고도 설정할 수 있습니다.
그림 4: ChatGPT에 엔터티를 수정하라는 메시지 표시.
이 게시물 끝부분에서 최종 VHDL의 전체 목록을 찾아보세요.
우리는 아직 입력의 힘을 계산하는 작업을 다루지 않았습니다. VHDL 엔터티에 들어가기 전에 전압과 전류 입력을 간단히 곱함으로써 이를 달성할 수 있습니다. 그림 5는 전원을 입력으로 사용하여 MCC에서 이 엔터티를 인스턴스화하는 방법의 예를 보여줍니다.
그림 5: VHDL의 입력 신호 전력 계산
이로 인해 입력 포트의 너비가 16비트에서 32비트로 증가합니다. 여기서 인스턴스화는 낮은 16비트를 버릴 수 있거나(정밀도 손실이 허용되는 경우) 엔터티가 32비트 입력을 직접 사용하도록 업데이트될 수 있습니다. 어느 쪽이든, 당신이 해야 할 일은 물어보는 것뿐입니다! 본 포스트 끝에 있는 프롬프트를 참조하십시오.
요약: ChatGPT 및 Moku Cloud Compile을 사용하여 사용자 지정 일시적 오류 감지 수행
(직접 측정할 수 있는 것과는 달리) 계산된 양에 대해 실시간, 고속, 정지 시간 없는 오류 감지가 필요했었습니다. 단 세 번의 프롬프트 후에 ChatGPT는 FPGA의 고속 데이터 처리를 위해 특별히 설계된 언어인 VHDL에서 이를 구현하는 데 필요한 모든 코드를 제공했습니다. 간단한 잘라내기 및 붙여넣기 작업과 약간의 글루 코드 및 Liquid Instruments의 Moku Cloud Compile을 통해 이를 Moku Instrument-on-Chip에 배포할 수 있는 맞춤형 기구가 되었습니다. 10분 작업으로 나쁘지 않지요!
MCC와 함께 ChatGPT를 사용하는 더 많은 예를 보려면 여기에서 웹 세미나를 시청하세요. https://liquidinstruments.com/webinar-registration-moku-cloud-compile-and-chatgpt-essential-strategies-for-testing-smarter-with-ai/
MCC로 개발하려는 맞춤형 기구에 대해 궁금하신 점이 있으십니까? 다음 주소로 문의주시기 바랍니다. support@liquidinstruments.com 당사 엔지니어와 연결해 드리겠습니다.
부록 1: 코드 리스팅
VHDL 코드:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity RisingAboveZero is
Port (
clk: in std_logic;
reset: in std_logic;
in_value: in signed(15 downto 0);
threshold: in unsigned(15 downto 0);
out_value: out signed(15 downto 0);
out_cycle_count: out signed(15 downto 0)
);
end RisingAboveZero;
architecture Behavioral of RisingAboveZero is
signal counter: signed(15 downto 0);
signal cycle_count: signed(21 downto 0); -- Updated to 22 bits
signal previous_value: signed(15 downto 0);
begin
process(clk, reset)
begin
if reset = '1' then
counter <= to_signed(0, 16);
cycle_count <= to_signed(0, 22); -- Updated to 22 bits
previous_value <= to_signed(0, 16); elsif rising_edge(clk) then if in_value > signed(threshold) and previous_value <= signed(threshold) then
counter <= counter + 1; end if; if in_value > signed(threshold) then
cycle_count <= cycle_count + 1;
end if;
previous_value <= in_value;
end if;
end process;
out_value <= counter;
out_cycle_count <= cycle_count(21 downto 6); -- Output the 16 most significant bits
end Behavioral;
부록 2: 포트 연결 프롬프트
