RTL이 릴리즈 되면 펌웨어 쟁이는 기분이 안좋습니다.

알림
|
X

페이지 정보

작성자 에헤라디야 76.♡.210.164
작성일 2024.08.27 08:30
519 조회
7 댓글
0 추천
글쓰기

본문

소프트웨어를 개발한다는 것을 후려쳐서 프로그래밍 언어로 소스 코드를 고치는 과정이라고 말 해도 됩니다.

반도체를 개발한다는 것도 후려쳐서 RTL 코드를 고치는 과정이라고 말해도 됩니다.

후려쳐서 말 한 것이니까 그 외에 엄청나게 많은 과정이 추가로 더 많다는 것을 생략했습니다.


저처럼 SoC를 개발하는 회사에서 펌웨어를 개발하는 일을 하면 하드웨어 팀에서 주기적으로 RTL을 릴리즈합니다. 변경된 RTL에 맞춰서 펌웨어도 바뀌어야 하지요. 대표적으로 레지스터 이름이 바뀌거나 레지스터 어드래스가 바뀌거나 오프셋이 바뀌거나 레지스터의 필드가 다른 레지스터로 이사 간다거나 아니면 레지스터 필드가 없어지는 상황입니다.


이런 일은 대체로 C언어의 여러 추상화 단계를 거쳐서 그냥 적용될 때가 많습니다. 펌웨어 컴파일만 다시하면 되는 것이죠.


때로는 특정 하드웨어 IP의 동작 자체가 바뀌기도 합니다. 이럴 때는 해당 IP를 디자인한 디자이너와 해당 IP를 검증한 DV 엔지니어와 함께 이 동작이 어떻게 바뀌었는지를 확인하고 해당 동작에 맞추어 펌웨어 코드 시퀀스를 수정해야 합니다. 부지런한 하드웨어 디자이너는 바뀐 동작을 미리 문서에 써 놓기도 합니다. 그러면 펌웨어 엔지니어는 번거롭게 여기저기 물어보러 다닐 필요없이 문서만 보고 펌웨어 코드를 수정합니다.


제가 해야하는 많은 업무 중 하나가 이런 작업입니다. 그런데 왜 제목에서 기분이 나쁘다고 언급한 걸까요? 왜냐하면 꽤 귀찮기 때문입니다. 때로는 컴파일 에러가 수백개 단위로 나오기도 하고요.


하드웨어 바뀌었다고 여기저기 물어보는 것도 꽤 귀찮고요. 문서가 업데이트 되었어도 문서 내용이 틀리거나 문서 내용에 모든 정보가 다 없어서 또 사람 찾아서 물어봐야 할 때도 있고요.


그래서 RTL이 릴리즈 되었다고 펌웨어 업데이트 해 달라고 티켓을 받으면 그냥 하기 싫습니다. 왠지 엄청 변경 사항이 많을 것 같거든요. 그리고는 하드웨어 릴리즈 노트를 확인해 봅니다. 대체로는 도움이 안됩니다. 제가 관심있어하는 내용은 그 긴 하드웨어 릴리즈 노트 중에 일부인데 찾아보기도 힘들거든요.


결국 그냥 일을 시작해 봅니다. 그러면 또 대부분은 하루 정도 작업하면 펌웨어 업데이트가 완료 되는 수준입니다. 그냥 괜히 귀찮아 한 것이지요. 그냥 해도 되는데 말이죠.

댓글 7

동독도님의 댓글

작성자 동독도 (198.♡.207.102)
작성일 08.27 09:44
메모리를 설계하는 입장에서 이쪽 업계는 트랜지스터 레벨에서 설계를 합니다.
랭퀴지 레벨에선 어셈블리어 정도쯤의 수준이죠.

분노의다운힐님의 댓글

작성자 분노의다운힐 (27.♡.242.71)
작성일 08.28 16:20
제가 있는 곳도 HW가 우선이라 SW는 치닥거리입니다.. 매번 레지스터나 비트 할당해놓은거 보면 왜 이 모양으로 해놓는지 이해가 안됐는데, 다행이도? 이젠 제가 안해도 되네요. 제일 황당한 건 HW에서 설계 잘 못해서 제대로 동작 못하는 칩을 만들어놓고 SW에 와서 왜 이걸 workaround 못하냐고 성질 부릴 때입니다.

컨텍스트님의 댓글의 댓글

대댓글 작성자 컨텍스트 (125.♡.41.31)
작성일 08.28 22:58
@분노의다운힐님에게 답글 일하다 보면 workaroud가 은근히 많습니다. 칩레벨의 펌웨어 개발 뿐만 아니라 프로토콜 스택과의 인터페이스 오류까지 말이죠~ 다 준비된 의사소통이 없어서 생긴 것 같다는 생각이 스치긴 합니다.

dante2k님의 댓글

작성자 dante2k (115.♡.101.193)
작성일 08.28 18:33
아오... 이 글, 댓글 읽다가 예전에 WIN CE PDA 기기에서 c# 으로 프로그래밍하는데, WIFI 모듈과 RF-ID 모듈을 동시에 사용하면 기기가 간헐적으로 뻗는 증상을 찾은 적이 있어요.
기기 메뉴얼 어디에도 동시에 사용하면 안된다라는 가이드도 없었고, 제조사에도 동시에 사용하는데 문제가 없다라는 답변을 받았습니다. 제조사에 버그 리포팅하니 자기들도 왜 그런지 모르겠다고만 하다가, 결국 모듈 2개가 소모하는 전력을 제대로 제공하지 못한다는 것을 찾았다고 하고 끝이었습니다. 양산된 걸 어쩌냐고 그냥 프로그램에서 동시에 사용하지 않도록 해라라고 하더군요...
RF-ID 에서 정보를 읽어서 실시간으로 출입 통제 프로그램만들어 달라고 했던 건데...... 저를 외주한 업체가 그 기기 생산하던 업체였습니다.
처음 요건은 RF-ID 읽기 -> 카드 정보 전송 -> 출입 가능 여부 확인, 이정도로 간단한 프로젝트였는데, 뭐 기기가 제대로 동작하지 않으니, PDA 에 출입 가능 인원 정보 내려받고, 사용할 때는 WIFI 끄고 출입 통제하고, 나중에 출입 통제 정보를 업로드하는 어정쩡한 오프라인 모드로 개발을 했더랬죠...

Realtime님의 댓글

작성자 Realtime (75.♡.158.112)
작성일 08.31 01:30
그래서 팹리스들 jd 보면 rtl 프론트엔드 + 펌웨어 개발 같이 하는 포지션 많더군요.
rtl 바뀔 때마다 펌웨어 변경을 주도할.... 노예....?

기생충제국님의 댓글

작성자 no_profile 기생충제국 (107.♡.159.23)
작성일 09.15 09:29
FW 개발하다가 지금은 silicon team에서 architect와 front end 언저리 일을 하고 있습니다. backend쪽으로 갈수록 문제가 생겼을 때  앞쪽에서 저질러진 일을 뒤치닥거리 한다는 생각은 피할 수가 없습니다. 화도 나지요. 하지만 어쩔수 있나요. chip은 바꿀 수 없거나 너무 큰 돈이 들어가고 FW/SW로 문제 해결할 수 있다면 그렇게 해야지요.
@컨텍스트 님의 의사소통 언급이 적절한 지적입니다. architecture 단계나 RTL 구현다계에서 FW/SW의 feedback이 굉장히 중요한데, 이쪽 동네와서 경험해보니 변경때마다 모든 feedback을 얻는것도 쉽지 않고 적지않은 경우는 수년뒤에 쓰일 chip의 spec을 SW쪽도 정확히 확답해주기가 어렵습니다. 그렇다고 "전부 다 되게 해줘"만 따라가다 보면 chip의 복잡도나 사이즈가 만들 수 없는, 말하자면 과제가 산으로 가기 쉽더라고요. 어느 분야나 쉬운건 없습니다.
그래도 FW쪽의 장점이라면 잘 못 되어도 고칠 기회라도 있다는 거지요. 수년 뒤에 쓰일 제품을 내가 결정해야 한다는 거 많이 부담되더라고요.

에헤라디야님의 댓글의 댓글

대댓글 작성자 에헤라디야 (76.♡.210.164)
작성일 09.17 01:58
@기생충제국님에게 답글 맞습니다. ㅎㅎ
저도 워크어라운드 넣으면서 '제대로 못하나?' 하는 생각이 들긴하지만 칩 변경에서 비용 생각하면 펌웨어에서 일단 고치고 다음 칩에서 수정하는게 맞지요.
펌웨어 레벨에서 문제로 인하여 소프트웨어 레벨에서도 아마 워크어라운드를 할 지도 몰라요. 저희가 몰라서 그렇지 :)
또는 우리가 다 찾아내지 못한걸 더 뒷단에서 찾아서 자체적으로 처리하기도 하고요.
하드웨어 디자이너에게 피드백을 만들어주는 것 또한 제가 맡은 업무 중 하나이긴 한데 때로는 이 사람들이 피드백을 반영하기는 하는건가 하는 생각이 들 때도 있긴해요. 회사에 개발 프로세스가 있기 때문에 어찌되었든 반영되고 고쳐지게 되어 있긴 하지만 그 시점이 문제거든요. 하드웨어 디자이너가 해당 문제를 테입아웃 직전까지 처리 안하고 있으면 모두가 자잘한 이슈 몇 개 때문에 압박받는 일이 생기기도 해요. 뭐 물론 그사람들도 바빠서 그런것이겠지만요.
글쓰기
전체 검색