FPGA 디자인을위한 구성 관리

Question

임베디드 (마이크로 블레이즈) 소프트웨어를 위해 자일링스 FPGA가 VHDL 및 C로 프로그래밍 된 FPGA 디자인에 가장 적합한 구성 관리 툴은 무엇입니까?

Answer 1

버전 라벨 지정 및 이진 파일을 지원하는 CM 도구를 제안합니다. 대부분의 소프트웨어 CM 응용 프로그램은 ASCII 텍스트 파일로 정상적으로 작동합니다. 그들은 단지 업데이트를 위해 전체 파일이 아닌 "차이"파일을 저장할 수 있습니다.

내 권장 사항 : PVCS, ClearCase 및 Subversion. Microsoft SourceSafe를 사용하지 마십시오. 개정판 당 하나의 레이블 만 지원하기 때문에 나는 그것을 좋아하지 않습니다.

Answer 2

몇 가지 FPGA 집약적 인 회사에서 Perforce와 Subversion을 사용했습니다.

Answer 3

저는 개인적으로 Perforce, Subverion, git 및 ClearCase를 FPGA 프로젝트에 사용했습니다. VHDL과 C는 텍스트 파일이기 때문에 아무 문제가 없습니다. 그러나 다른 프로젝트와 제한 파일 및 사용하는 모든 라이브러리를 캡처해야합니다.

출력에 대해 어떻게 생각하십니까? 예 : 로그 파일과 비트 스트림. 둘 다 크고 비트 스트림은 바이너리입니다.

Answer 4

우리는 퍼포를 사용합니다. 리눅스 토지에 거주하는 코드를 Windows 기반의 스펙 및 문서와 나란히 검사 할 수 있습니다. 그리고 당신은 분기, 라벨 등을 얻을 수 있습니다.

Clearcase에서 RCS로 사용되는 모든 것을 보았습니다. 실제로 이런 종류의 것은 괜찮습니다. 중요한 것은 귀하의 그룹을 위해 수립 된 좋은 체크인 정책을 수립하고 그들이 준수해야한다는 것입니다.

야간 회귀 분석이 자동으로 수행됩니다. 그런 식으로 누군가가 규칙을 어기면 식별하고 공개적으로 부끄러워 할 수 있습니다.

Answer 5

이전에는 Subversion을 사용했지만 2 년 전 git로 전환했습니다. Git은 FPGA 디자인 파일을 처리 할뿐만 아니라 모든 텍스트 및 이진 파일을 처리합니다. 힘내라는 것은 파일과 유물을 제어하는 ​​버전에 필요한 전부이다.

디자인을 구현하려면 ise라는 단일 ISE 프로젝트 ("ise /"라는 하위 디렉토리에 있음)를 사용하는 것이 좋습니다. 파일 레이아웃에 대해서는 매우 겸손한 FPGA open-source project on github을 살펴볼 수 있습니다. 다시 생성하기 쉽기 때문에 ISE 파일을 저장하는 것을 신경 쓰지 않습니다. 내가 저장하는 유일한 것은 Verilog 파일과 일부 ISIM 파형 설정 파일입니다. coregen을 사용하는 다른 프로젝트에서는 coregen.cgp 프로젝트 파일과 코어를 재생성하기위한 모든 * .xco 스크립트를 저장합니다. 그렇다면 실제로 * .xco 파일에서 coregen을 실행하기 위해 Makefile을 사용합니다. * .ucf, * .coe, * .xcf 등

Makefile과 Xilinx 명령 줄 도구를 사용하여 실험했지만 ISE가 수행 한 것으로 나타났습니다. 의존성을 추적하고 올바른 인수를 사용하여 도구를 호출하는 작업이 훨씬 더 효과적입니다. 그냥 ise/project 파일을 버전 제어하려고 시도하면 실수를 저 지르지 마십시오. 그러면 화를 낼 것입니다. 자일링스는 매 릴리스마다 변경되는 300 가지 파일 유형과 같은 것을 가지고있다. 파일을 저장하려면 확장자가 .xise 인 ISE 프로젝트 파일을 사용해보십시오. 당신이 알고있는 황금빛 비트 파일처럼 빌드하기까지 6 시간이 걸렸던 것처럼, 재현하기 어려운 것은 복사하고 명시 적으로 관리하는 것이 좋습니다.

Answer 6

"최상의"것은 아니지만 소프트웨어에서 작동하는 구성 제어 솔루션은 FPGA에서 정상입니다. 흐름은 매우 유사합니다. 나는 직장에서 Subversion을 사용하고 집에서 자식과 wrote a little on 'why' at my blog.

다른 답변으로 바이너리 파일이 계속 언급되고 있습니다. 제가 다루는 바이너리 파일은 컴파일 제품 (소프트웨어 개체 및 실행 파일과 동일합니다)이므로 버전 관리 저장소에 보관하지 않고 zipfile 중요한 모든 (그리고 자극적으로 재현하기가 더디게 느껴지는) 모든 릴리스/태그에 대해

Answer 7

나는 당신이 일반적으로 좋은 것으로 생각하는 어떤 개정 관리 도구를 사용 하느냐가 중요하지 않다고 생각한다. 아마 여기서 괜찮을거야. 저는 개인적으로 Git을 사용하여 상당한 규모의 Verilog + 소프트웨어 프로젝트를 작성했습니다.

당신이 사용하는 버전 컨트롤에 관계없이 무엇이 당신을 엉망으로 만들 것입니다 : 자일링스 툴은 일반적으로 "입력"과 "출력"또는 (인간이 편집 한) "소스"와 (불투명) "바이너리". 대부분의 도구는 마지막 실행 시간이나 해시 값과 같은 일부 상태 정보를 "입력"파일에 저장하는 것을 좋아합니다. 이는 잘못된 변경을 많이하게된다는 것을 의미합니다. Coregen은이를 .xco 파일로 처리하고 프로젝트 탐색기 (기본 GUI)는 .xise 파일로이를 수행합니다. 또한 두 도구 모두 기본 값 매개 변수에 대한 행을 임의로 삽입하거나 제거하는 습관이 있습니다.

내가 만난 가장 큰 문제

은 Coregen에 대한 작업 흐름이다 : 많은 경우에, 적어도 다음 중 하나에 해당하는 :

1. 수동 Coregen에 의해 생성 된 HDL 파일을 편집해야합니다.
2. Coregen에 들어간 매개 변수는 .xco 파일이 아닌 다른 곳 (보통 출력 파일)에 저장됩니다.
3. Coregen의 출력을 최상위 디자인에 복사하여 붙여 넣기해야합니다.

즉, 코어 생성 프로세스에 대한 입력을위한 단일 논리 원본/마스터 위치가 없음을 의미합니다. 따라서 버전 관리하에 .xco 파일이 있어도 실행중인 디자인이 이에 상응 할 것이라는 기대는 없습니다. 공칭 입력에서 "동일한"코어를 다시 생성하면 올바른 출력을 얻을 수 없을 것입니다. 병합에 대해서도 생각하지 마십시오.