01signal.com

Vivado로 Partial Reconfiguration 이해하기

中文 | 日本語 | 한국어 | English

이것은 Partial Reconfiguration또는 Xilinx의 Vivado가 포함된 Dynamic Function eXchange (DFX) 에 대한 4개의 시리즈 중 첫 번째 게시물입니다. 이 게시물의 목적은 이 주제의 주요 개념을 설명하는 것입니다. 이것은 Partial Reconfiguration로 FPGA 프로젝트를 설정하기 위한 실질적인 단계를 설명하는 다음 포스트 를 위한 기초를 준비합니다.

소개

Partial reconfiguration은 FPGA의 다른 부품이 정상적으로 작동하는 동안 FPGA의 일부 부품의 logic을 교체할 수 있는 기술입니다. 이것은 전원을 켤 때 기능을 프로그래밍하는 초기 bitstream 와 정확히 같은 FPGA 에 bitstream을 공급하는 것으로 구성됩니다. 그러나 Partial Reconfiguration 용 bitstream은 FPGA를 중지시키지 않습니다. 대신 특정 logic elements에서 작동하고 동작을 제어하는 메모리 셀을 업데이트합니다. 특정 logic blocks의 hot replacement 입니다.

Xilinx의 FPGAs는 Virtex-4 (및 Intel의 FPGAs가 Series-V부터 시작)부터 이 기능을 지원합니다.

이 포스트는 다음 포스트 를 준비하기 위해 실제 기술적인 세부 사항을 다루지 않고 Partial Reconfiguration 이면의 개념을 안내합니다. 모든 것이 이 항목의 모든 것과 관련되어 있으므로 개별 작업으로 나누기 전에 전체 프레임워크를 이해하는 것이 중요합니다.

다시 설명?

Partial Reconfiguration없이 FPGA 의 기능이 어떻게 변경되는지부터 시작하겠습니다. design hierarchy어딘가에 module 의 instantiation이 있다고 가정해 봅시다. 예를 들어, Verilog에서:

moduleA reconfig_ins
     (
      .clk(clk),
      .this(this_w),
      .that(that_w),
 [ ... ]
      );

또는 VHDL에서:

reconfig_ins : moduleA
    port map(
      clk        => clk,
      this       => this_w,
      that       => that_w,
 [ ... ]
      );

분명히, 프로젝트 어딘가에 moduleA.v 또는 moduleA.vhd 라고 하는 module이 있거나 moduleA라고 하는 IP가 있으며 instantiation을 채웁니다( submodules와 함께). 그래서 우리는 프로젝트의 implementation을 수행하고 bitstream 파일을 얻어 FPGA를 로드합니다. 지금까지는 일반적인 절차입니다.

하지만 이제 위의 코드에서 moduleA 대신 moduleB를 작성하고 logic 의 implementation을 수행하여 bitstream 파일을 얻는다고 가정해 보겠습니다. 이것이 작동하려면 design에 moduleB.v 또는 moduleB.vhd또는 moduleB 라는 IP가 있어야 합니다.

이제 reconfig_ins 라고 하는 instance 내부에 있는 logic 와 다른 두 개의 bitstream 파일이 있습니다. 이 두 bitstreams사이를 전환하려면 원하는 bitstream이 있는 전체 FPGA를 로드해야 합니다. 여기에는 FPGA의 작동이 중단됩니다.

Partial Reconfiguration은 중단 없이 한 버전에서 다른 버전으로 변경할 수 있는 기술입니다. FPGA는 계속 정상적으로 작동하는 반면 reconfig_ins 의 logic은 moduleA 에서 moduleB로 또는 그 반대로 변경됩니다. 두 대의 designs 중 implementation 만 따로따로 할 수 있는 것은 아닙니다.

moduleA 및 moduleB는 Reconfigurable Modules (RM)라고 하며, 이는 Partial Reconfiguration덕분에 logic을 FPGA 에 주입할 수 있음을 의미합니다.

동기 부여

Partial Reconfiguration을 사용하는 데에는 다음과 같은 몇 가지 이유가 있습니다.

부분 bitstream

FPGA design에 대한 경험이 있는 경우 간단한 루틴에 익숙해질 가능성이 있습니다. design의 source code (및 IPs)를 약간 수정하고 implementation tools를 시작하고 OK를 통과했는지 확인합니다. 그런 다음 bitstream을 JTAG을 통해 FPGA 에 로드합니다. 또는 bitstream의 image 와 함께 flash device를 로드하십시오.

이것이 우리 모두에게 익숙하기 때문에 bitstream을 각 logic element가 어떻게 작동해야 하는지에 대한 신비한 정보로 전체 FPGA를 채우는 많은 데이터로 착각하기 쉽습니다. 실제로 bitstream은 로드될 때 FPGA 에 의해 순차적으로 실행되는 일련의 명령으로 구성됩니다. 실제로 일반 bitstream은 전체 FPGA 에 정보를 로드하지만 절차의 진행 상황을 제어하는 여러 명령으로 수행됩니다. 이러한 명령의 더 중요한 측면은 각 데이터 조각과 함께 로드되는 logic elements를 결정한다는 것입니다.

bitstream 자체가 어떤 logic elements가 영향을 받는지 알려 주기 때문에 일부 logic elements만 변경하고 다른 logic elements는 그대로 두는 bitstream을 만드는 것이 가능합니다. 이것이 Partial Reconfiguration의 초석입니다.

즉, partial bitstream은 FPGA에 이미 로드된 logic 와 호환되어야 합니다. 잘못된 logic elements를 덮어쓰는 것은 단지 문제가 아닙니다. 초기 bitstream은 부분 bitstream와 밀접하게 연결되어 있습니다. 특히 초기 bitstream은 부분 bitstream에 의해 변경된 영역 내부에 있는 logic 및 routing resources를 사용하기 때문입니다. 부분적인 bitstream이 초기 bitstream에 대해 올바르게 설정되면 이 섬세한 춤이 눈에 띄지 않게 흘러갑니다. 그렇지 않은 경우 FPGA는 손대지 않은 상태로 남아 있어야 하는 기능을 포함하여 미쳐버릴 가능성이 높습니다.

부분 bitstream로드

FPGA가 실행되는 동안 프로세스가 완료될 수 있는 한 bitstreams를 로드할 수 있는 모든 인터페이스를 사용하여 Partial Configuration bitstream을 FPGA 로 제공할 수 있습니다. 여기에는 JTAG 인터페이스가 포함되므로 Partial Configuration 용 .bit 파일은 평소와 같이 Hardware Manager 와 함께 로드할 수 있습니다. 그러나 더 흥미로운 것은 전용 Internal Configuration Access Port (ICAP)을 사용하여 FPGA의 자체 logic내부에서 수행할 수 있다는 것입니다. 이 port는 Partial Reconfiguration에만 사용할 수 있습니다. FPGA의 logic fabric 에서 bitstream을 로드하는 부분이 프로세스 내내 그대로 유지되어야 하기 때문입니다.

ICAP은 bitstreams를 로드하기 위한 FPGA의 하위 시스템에 대한 인터페이스일 뿐이며 bitstream의 소스에 대해 지시하지 않습니다. 따라서 bitstream 데이터가 FPGA에 도달하는 방법이나 저장 위치 및 방법에 제한이 없습니다. ICAP을 공급하는 FPGA logic 조각에서 어떻게든 사용할 수 있어야 합니다.

예를 들어, Xillybus 는 보드에 있는 경우 PCIe 또는 USB 3.x 인터페이스를 통해 컴퓨터에서 ICAP 로 bitstream 파일을 보내는 간단한 수단 을 제공합니다.

Static logic

Partial Reconfiguration을 올바르게 수행하려면 반대쪽 부분을 존중해야 합니다. static logic. 손대지 않은 상태로 유지되어야 하는 FPGA design 의 부품에 대한 일반적인 용어이므로 초기 bitstream이 로드되었을 때부터 존재합니다.

이 logic은 두 가지 측면에서 정적입니다. 기능적 측면, 즉 logic은 FPGA의 초기 시작부터 중단 없이 작동할 FPGA design (HDL 및 IP)의 부품으로 구성됩니다. 덜 중요한 두 번째 측면은 이 logic 의 배치가 정적으로 할당된 logic fabric 의 사이트로 제한된다는 것입니다. 이러한 사이트에서는 이후의 조작이 허용되지 않습니다.

실제 design에서는 static logic이 변경되지 않은 상태로 유지되는 것만으로는 충분하지 않지만 FPGA 의 다른 부분이 변경되는 동안 계속해서 제대로 작동하는 것도 중요합니다. 변경되는 static logic 와 logic 사이를 연결하는 nets가 거의 확실하므로 모든 것이 원활하게 실행되도록 하는 것은 FPGA designer의 책임입니다. 이 시리즈의 세 번째 게시물 에서는 이에 대해 설명합니다.

static logic 와 reconfigurable logic의 분리

Partial Reconfiguration이 가능하려면 static logic 와 reconfigurable logic을 엄격하게 구분해야 합니다. 특히 FPGA가 bitstream와 함께 로드될 때 static logic을 포함하는 사이트가 영향을 받지 않도록 FPGA 의 물리적 logic elements를 분리해야 합니다.

이것이 무엇을 요구하는지 이해하기 위해 먼저 우리 모두에게 익숙한 것을 살펴봅시다.

일반 FPGA implementation 프로세스는 HDL design의 synthesis 로 시작한다는 것을 기억하십시오. HDL 에서 modules 의 instantiation은 이들 간의 분리를 의미하지 않습니다. 그 반대가 사실입니다. synthesizer는 instantiations를 logic이 어떻게 작동해야 하는지에 대한 설명으로 취급합니다. 따라서 synthesizer는 design 전체를 하나의 크고 평평한 logic조각으로 간주할 수 있습니다. modules 의 경계를 넘는 최적화는 허용될 뿐만 아니라 원하고 많이 발생합니다. 예를 들어, module X 의 register가 module Y의 완전히 관련이 없는 register 와 동일하게 발생하면 registers 중 하나가 제거되고 나머지 하나는 두 modules 에서 모두 사용됩니다( synthesizer가 이를 자제하도록 특별히 지시하지 않는 한).

HDL 의 synthesis가 완성되면 synthesized netlist는 design의 IPs (있는 경우)와 혼합됩니다.

다음으로, 이 큰 logic elements 덩어리는 FPGA의 logic fabric전체에 배치되고 와이어는 timing constraints 및 기타 목표를 달성하는 방식으로 라우팅됩니다. design 의 다른 부분에 속하는 Logic은 동일한 slice또는 FPGA의 반대쪽 부분에 패킹될 수 있습니다. design 의 가장 작은 변경이라도 배치가 크게 달라질 수 있습니다. 이것은 각 implementation이 독립적이고 logic이 FPGA의 logic fabric에 어떻게 흩어져 있는지 신경쓰기 때문에 혼란스럽지만 무해합니다.

Partial Reconfiguration로 돌아가기: 방금 언급했듯이 이 기능을 가능하게 하려면 static logic 와 reconfigurable logic을 분명히 구분해야 합니다. 이를 보장하기 위해 Hierarchical Design 라는 기술이 사용됩니다. 아이디어는 전체 design을 PCB의 물리적 구성 요소와 같은 구성 요소 모음으로 보는 것입니다. 이것의 한 측면은 각 구성 요소(즉, instantiated module)가 logic fabric의 특정 영역에 할당된다는 것입니다. 그리고 각 구성 요소를 분리해야 하므로 구성 요소를 별도로 생산하는 것처럼 synthesis를 별도로 수행하는 것이 좋습니다.

따라서 이 개념을 Partial Reconfiguration와 연결해 보겠습니다. 이는 design작업에서 두 가지 주요 차이점으로 요약됩니다.

Pblocks

floorplanning unit 에 대한Vivado의 용어는 Pblock로, Vivado내부 정보의 자리 표시자에 불과합니다. Pblock을 만들고 logic cells를 추가한 다음 FPGA logic sites의 그룹(sets)을 추가하는 Tcl 기능이 있습니다. Vivado는 이것을 Pblock 에 추가된 logic cells가 할당된 sites 에만 배치할 수 있도록 요구하는 placement constraint 로 해석합니다. 따라서 결국 Pblocks는 XDC 파일의 다른 constraints 와 같습니다.

Pblocks는 종종 synthesized design 또는 implemented design을 열고 FPGA의 그래픽 표현에 직사각형 영역을 그려 Vivado의 GUI를 사용하여 정의됩니다. 그러면 그려진 사각형에 모든 logic elements가 포함된 Pblock이 생성됩니다. 보다 정확하게는 모든 유형의 logic elements가 포함되지 않고 floorplanning (해당 FPGA 제품군의 경우)에 허용되는 유형만 포함됩니다. 따라서 Vivado는 사각형을 logic elements의 범위로 변환합니다.

XDC 파일을 편집하여 이러한 범위를 수동으로 설정하는 것도 괜찮습니다. 또한 여러 직사각형으로 구성된 영역을 생성할 수 있으므로 모양이 하나의 직사각형보다 더 복잡할 수 있습니다. 그러나 Xilinx의 문서(UG909)는 routing의 어려움을 피하기 위해 모양을 단순하게 유지하도록 제안합니다.

다음은 Kintex-7용 XDC 파일의 예입니다.

create_pblock pblock_pr_block_ins
add_cells_to_pblock [get_pblocks pblock_pr_block_ins] [get_cells -quiet [list pr_block_ins]]
resize_pblock [get_pblocks pblock_pr_block_ins] -add {SLICE_X118Y0:SLICE_X153Y99 SLICE_X118Y250:SLICE_X145Y349 SLICE_X0Y0:SLICE_X117Y349}
resize_pblock [get_pblocks pblock_pr_block_ins] -add {DSP48_X5Y100:DSP48_X5Y139 DSP48_X5Y0:DSP48_X5Y39 DSP48_X0Y0:DSP48_X4Y139}
resize_pblock [get_pblocks pblock_pr_block_ins] -add {RAMB18_X4Y0:RAMB18_X6Y39 RAMB18_X4Y100:RAMB18_X5Y139 RAMB18_X0Y0:RAMB18_X3Y139}
resize_pblock [get_pblocks pblock_pr_block_ins] -add {RAMB36_X4Y0:RAMB36_X6Y19 RAMB36_X4Y50:RAMB36_X5Y69 RAMB36_X0Y0:RAMB36_X3Y69}

아래 이미지는 implemented design에서 어떻게 보이는지 보여줍니다. reconfigurable partition (이 예에서는 logic이 거의 포함되지 않은 pblock_pr_block_ins로 명명됨)는 자주색으로 그려집니다. 그 모양은 세 개의 직사각형(위의 각 resize_pblock 명령에 나열된 세 가지 범위)의 union 로 생성됩니다.

이 도면에서 모든 placed logic은 청록색으로 그려져 있습니다. logic 의 대다수는 static region에 속하며 작은 영역에 국한되어 있음이 분명합니다.

Example of device view with Pblock partition

slices, RAMs 및 DSP48 만 constraints에 의해 제한됩니다. 이것은 Partial Reconfiguration이 series-7 FPGAs로 제어할 수 있는 유일한 logic 유형입니다. 실제로 "순수한 logic"를 제외한 나머지는 모두 static design에 속해야 합니다.

Ultrascale FPGAs 이상에서는 거의 모든 logic을 Partial Reconfiguration로 다시 로드할 수 있습니다.

Pblocks에 대한 추가 제한 사항이 있지만 여기에서 UG909 의 6-8장을 반복하는 것은 의미가 없습니다.

어쨌든 implemented design을 열어서 FPGA의 뷰를 확대 및 축소하고 logic elements가 FPGA에서 어떻게 구성되어 있는지 지켜보는 것이 좋습니다. 특히 동일한 유형의 logic 열이 있다는 점에 유의하십시오. 때때로 균일성을 깨뜨리는 열 중간에 몇 개의 logic elements가 있습니다(특히 ICAP 블록, PCIe 블록 등과 같은 특수 logic elements).

Pblocks 의 주제는 Partial Reconfiguration에만 국한된 것이 아닙니다. 예를 들어 이 섹션에서 말하는 모든 내용은 hierarchical design에 Pblocks를 사용하는 경우에도 적용됩니다.

floorplanning에 대한 추가 정보

그리고 여기에 몇 가지 반직관적인 사실이 있습니다. floorplanning 의 그래픽 표현은 FPGA의 지도에 그려진 모양으로 구성되어 있지만 placement constraints에 의해 제어되는 logic 유형에만 적용됩니다. 따라서 FPGA 의 거의 모든 slices가 Partial Reconfiguration에 할당된 경우 이러한 slices 로 완전히 둘러싸인 다른 logic elements 의 섬은 static logic에 매우 잘 속할 수 있습니다. 예를 들어, ICAP 블록 자체가 Partial Reconfiguration에 할당된 사각형의 중간에 있으면 아무 문제가 없습니다.

Partial Reconfiguration bitstream이 특정 logic elements를 향하고 나머지는 그대로 유지한다는 점을 감안할 때 이것은 그렇게 이상한 일이 아닙니다. 그러나 routing은 어떻습니까? ICAP 블록이 reconfigurable logic의 중간에 끼어 있으면 static logic의 slices 에 와이어가 어떻게 그려지나요?

이것은 우리를 두 번째 반직관적인 사실로 이끕니다. static design 용 routing은 reconfigurable region내부의 리소스를 사용합니다. 이 routing은 Partial Reconfiguration 프로세스 전체에서 안정적으로 유지됩니다. 그렇지 않으면 static logic이 아닙니다. 따라서 reconfigurable region내부에서 reconfigurable logic 용 routing은 변경되지만 static logic 용 routing은 변경되지 않습니다. 이 전체 주제에 대해 마술처럼 느껴지는 것이 있다면 바로 이 작은 사실입니다. static logic 와 호환되지 않는 partial bitstream을 사용하는 것이 FPGA를 완전히 방해할 수 있는 이유이기도 합니다.

물론 그 반대는 사실이 아닙니다. reconfigurable logic은 위의 XDC 예제와 같이 명시적으로 나열된 리소스를 제외하고 리소스를 사용하지 않습니다. routing 리소스의 경우 Partial Reconfiguration bitstream이 로드되는 동안 static region 의 아무 것도 변경되지 않으므로 그런 의미에서 reconfigurable logic은 static region에 영향을 주지 않습니다. 거의 사실입니다. reconfigurable region 의 모양이 일반 직사각형이 아닌 경우 Vivado는 routing 가 reconfigurable region외부로 나오게 할 수 있습니다. 이것은 routing을 개선하기 위한 목적으로 Ultrascale FPGAs에서만 발생합니다.

이 시점에서 분명히 해야 할 것은 floorplanning을 그리는 규칙이 간단하지 않다는 것입니다. 좋은 소식은 Vivado가 floorplanning의 규칙 위반에 대한 응답으로 상당히 유익한 Critical Warnings를 생성한다는 것입니다. 따라서 시행 착오를 통해 적합한 floorplan을 찾는 것이 합리적인 작업 방법입니다.

Parent implementations 및 Child implementations

reconfigurable logic의 implementation 와 관련하여 FPGA 의 모든 단일 path는 timing constraints를 달성해야 하며 이는 reconfigurable logic이 로드되기 전과 후에 참이어야 함을 명심하는 것이 중요합니다. 따라서 static logic와 별개인 reconfigurable logic의 implementation은 불가능합니다. 오히려 implementation은 항상 각 reconfigurable module에 대해 전체 FPGA 에서 수행됩니다. timing constraints (및 다른 constraints)는 각 implementation에 적용됩니다.

이 점을 명확히 하기 위해 위에서 moduleA 와 moduleB를 예로 들겠습니다. 이 예에서 Vivado는 moduleA가 포함된 전체 design 의 implementation을 수행한 다음 moduleB에서 동일한 작업을 수행합니다. 부산물로 이 두 옵션 각각에 대한 일반 bitstream 파일이 있습니다.

강조할 가치가 있습니다. 모든 implementations는 전체 initial bitstream 와 partial bitstream을 생산합니다. 이는 Parent 또는 Child에 상관없이 모든 implementations 에 해당됩니다. 따라서 FPGA 의 전원이 켜지면 이러한 initial bitstreams와 함께 로드할 수 있습니다.

Partial Reconfiguration을 사용하여 moduleA 에서 moduleB 로 이동할 수 있으려면 static partition 의 모든 것이 정확히 동일해야 합니다. 여기에는 logic 자체, placement 및 routing이 포함됩니다. 이를 달성하기 위해 Vivado는 Parent Implementation로 한 시나리오(예: moduleA포함)에 대해 implementation을 수행합니다. 그런 다음 다른 모든 시나리오에 대해 Child Implementations를 수행합니다(예: moduleB사용). 이 작업이 정확히 수행되는 방법은 이 시리즈의 마지막 게시물에 자세히 설명되어 있지만 긴 이야기를 짧게 하자면 다음과 같습니다.

Vivado는 Hierarchical Design에 대해 평소와 같이 moduleA 에 대해 Parent Implementation을 실행하는 것으로 시작합니다. 즉, static logic 의 synthesis 와 reconfigurable logic은 별도로 수행되며 floorplanning constraints는 placements를 FPGA의 별도 사이트에 적용합니다. 이 두 가지 차이점 외에 일반 implementation이 수행됩니다. 특히 placement 및 routing은 이 특정 시나리오에서 최적의 결과를 위해 수행됩니다( floorplanning constraints 및 별도의 synthesis가 최적의 성능이 아닐 수 있음에도 불구하고).

다음 단계는 moduleB용 Child Implementation을 수행하는 것입니다. Parent Implementation을 대신하여 이미 수행되었으므로 static design의 synthesis가 필요하지 않습니다. 따라서 synthesis는 reconfigurable logic에서만 수행됩니다.

그런 다음 implementation은 Parent Implementation와 동일한 방식으로 수행되지만 한 가지 중요한 차이점이 있습니다. 모든 static logic 의 place and route는 강제로 Parent Implementation의 결과와 동일해야 합니다. 이러한 한계를 감안할 때 reconfigurable logic 의 place and route는 최적의 결과를 위해 수행됩니다.

따라서 Parent 와 Child 사이의 관계에서 핵심은 Child Implementation이 Parent Implementation이 끝나는 지점에서 시작하지만 reconfigurable logic을 자체 logic로 대체한다는 것입니다. 그런 다음 Child Implementation은 평소와 같이 계속되지만 static logic영역에서 아무 것도 건드리지 않습니다.

모든 Child Implementations는 static logic의 placements 및 routes에 적응해야 하기 때문에 design의 일반 implementation 에 비해 timing constraints를 달성하는 것이 더 어려울 수 있습니다. 실제로 두 가지 장애물이 있습니다.

이것은 Parent Implementation에 대해 선택해야 하는 reconfigurable modules를 선택할 때 염두에 두어야 합니다. 예를 들어, timing constraints를 구현하기 가장 어려운 것은 module 일 수 있습니다. 또는 다른 modules를 static logic와 연결하는 방식으로 나타내는 module 입니다. 또는 다른 방법으로: static logic의 중립적인 implementation을 달성하기 위해 logic을 전혀 포함하지 않는 reconfigurable module ("grey box").

bitstreams의 사용과 관련하여 Partial Reconfiguration이 있는 프로젝트의 implementation 에 대한 Vivado의 패러다임은 모든 bitstreams가 최신 상태이고 상호 호환될 때 implementation이 종료된다는 것입니다. 다시 말해서, implementations의 initial bitstreams 중 아무거나 처음에 FPGA를 로드하는 데 사용할 수 있습니다. 그런 다음 implementations의 partial bitstreams를 로드할 수 있습니다.

따라서 첫 번째 "Generate Bitstream"는 Parent Implementation 와 모든 Child Implementations를 시작합니다. 후속 compilations 에서 Vivado는 평소와 같이 업데이트가 필요한 runs 만 수행합니다.

Dynamic Function eXchange Wizard

Tools 메뉴에서 시작할 수 있는 이 Wizard의 목적은 Parent Implementation 및 Child Implementations, 특히 어떤 Implementation 에 어떤 reconfigurable module이 포함되어 있는지 정의하는 것입니다.

Child Implementation을 추가할 때 만드는 Tcl 명령을 보면 이 Wizard를 설명하는 것이 가장 쉽습니다.

create_reconfig_module -name bpf -partition_def [get_partition_defs pr ]
add_files -norecurse /path/to/pr_block1.v  -of_objects [get_reconfig_modules bpf]
create_pr_configuration -name config_2 -partitions [list pr_block_ins:bpf ]
create_run child_0_impl_1 -parent_run impl_1 -pr_config config_2 -flow {Vivado Implementation 2020}

마지막 행에서 첫 번째 행까지 이 Tcl 시퀀스를 거꾸로 살펴보겠습니다.

따라서 마지막 행에서 Child Implementation run이 생성됩니다. 새로운 run 에는 "child_0_impl_1"라는 이름이 지정되고 parent run은 "impl_1"로 선택됩니다. 덜 중요한 것은 이 새로운 run 의 configuration은 "config_2"로 설정됩니다.

"config_2"는 세 번째 행에 정의되어 있으며 "bpf"는 "pr_block_ins"라는 reconfigurable partition 용 reconfigurable module 입니다. "pr_block_ins"는 위에서 언급했지만 "bpf"는 무엇입니까?

첫 번째 행에서 reconfig_module이 생성되고 "bpf"라는 이름이 지정됩니다. 이것은 logic이 하는 일을 알려주는 데 편리한 이름입니다. 두 번째 행에는 이 reconfigurable module에 특정 Verilog 파일이 추가되었다고 나와 있습니다.

따라서 전체적으로 이 4개의 행은 새로운 Child Implementation을 생성하고 특정 Verilog 파일의 synthesis가 reconfigurable module을 생성하는 데 필요하다고 말합니다. 또한 Tcl environment 에는 "bpf" 및 "config_2"라는 두 개의 objects가 생성됩니다.

이제 Dynamic Function eXchange Wizard로 돌아가십시오. design sources, reconfigurable modules, configurations 및 implementation runs간의 관계를 나타내는 GUI 도구입니다. 위에 표시된 것과 같은 Tcl 명령을 생성하기 위한 정보를 전달하는 편리한 방법일 뿐입니다.

이 도구는 지나치게 복잡해 보일 수 있지만 그 이유는 예제가 간단하기 때문입니다. 실제 design에서 reconfig_module 에는 여러 source files가 있고 IPs가 할당되어 있을 수 있습니다. 따라서 GUI는 작업을 더 쉽게 만듭니다.

그러나 configuration ("config_2")가 필요한 이유는 무엇입니까? create_run 명령으로 "bpf"와 "pr_block_ins"가 연결되지 않는 이유는 무엇입니까? 다시 한번 말하지만, 이 게시물은 reconfigurable partition하나만으로 제한되어 있기 때문에 정당한 질문입니다. 이러한 partitions가 여러 개 있는 경우 configuration은 어떤 partition이 어떤 reconfigurable module을 가져오는지 정의하므로 각 조합에 config_*와 같은 이름을 지정하는 것이 좋습니다.

따라서 partitions가 여러 개 있는 경우 reconfigurable modules의 가능한 각 조합에 대해 implementation을 만들어야 합니까? 이 질문은 이 게시물 시리즈와 관련이 없으므로 다음 섹션으로 건너뛰어도 됩니다.

Vivado의 implementation은 전체 design, 즉 static logic 와 reconfigurable logic이 함께 만들어지며 전체적으로 timing constraints를 충족한다는 것을 기억하십시오. 따라서 partitions가 여러 개 있는 경우 Partial Reconfiguration을 사용하는 안전한 방법은 모든 partitions를 해당 partial bitstreams와 함께 로드하여 모든 partial bitstreams가 동일한 implementation run의 결과가 되도록 하는 것입니다. 즉, 모든 partial bitstreams는 동일한 configuration (예: "config_2")로 생성되었으며, 따라서 이러한 partial bitstreams 의 조합은 도구에 의해 검증된 implementation 의 결과입니다. 특히 이번 implementation은 timing constraints를 구현한 것으로 알려졌다.

그러나 reconfigurable modules 에 상호 상호 작용이 없는 경우(즉, reconfigurable modules 의 모든 top-level ports가 static logic에 연결되어 있고 서로 연결되어 있지 않은 경우) 각 partition을 개별적으로 처리하면 무엇이 잘못될 수 있는지 알 수 없습니다. 실제로 Vivado는 다른 runs 의 partial bitstreams가 혼합 사용되는 경우 FPGA 의 timing 전체를 명시적으로 승인하지 않았습니다. 하지만 static logic이 탑재된 모든 paths가 timing constraints를 달성했고 static logic이 모든 implementation runs에서 완전히 동일하기 때문에 충분하지 않습니까? 공식 문서는 이 문제에 대한 정보를 제공하지 않는 것 같습니다.

Routing 및 Partition Pins

퍼즐에 아직 한 조각이 빠져 있습니다. static logic 와 reconfigurable logic을 연결하는 routing . Parent Implementation은 관련 configuration에 포함된 reconfigurable logic 에 대해 최적의 방식으로 design 의 place and route를 수행한다는 것을 기억하십시오. 그러나 child의 reconfigurable module은 동일한 reconfigurable partition에 맞고 static design와 연결되어야 합니다. routing 의 적어도 일부는 static logic에 속하므로 변경할 수 없습니다.

여기에서 Partition Pins가 등장합니다. 개념적으로 reconfigurable logic은 물리적 구성 요소로, partition pins는 PCB에 연결된 금속 핀으로 생각할 수 있습니다.

그러나 실제로 partition pins는 routing에 대한 FPGA리소스의 좌표계에 있는 위치일 뿐입니다. static logic의 routing이 끝나고 reconfigurable logic의 routing이 이어지는 곳입니다. 이들의 유일한 중요성은 Parent Implementation 와 Child Implementations가 일치하는 위치에 있다는 것입니다.

이러한 앵커 포인트를 설정하는 데 LUTs 또는 flip-flops 와 같은 물리적 리소스가 필요하지 않으며 추가 routing delay에 기여하지 않습니다. partition pins 와 연결되는 routing 세그먼트는 물론 delay을 생성하지만 partition pins 자체는 delay을 추가하지 않습니다.

partition pins 의 위치는 Parent implementation이 수행되는 동안 도구에 의해 자동으로 선택되며 Child implementations는 강제로 적응됩니다. 즉, static logic 와 reconfigurable logic 사이의 routing은 Parent Implementation이 말한 곳에서 시작하고 Child Implementation은 reconfigurable partition내에서만 최선을 다할 수 있습니다. 일부 partition pins가 Child의 reconfigurable logic에 대해 불리한 위치에 배치되어 timing constraints달성에 어려움이 발생할 수 있습니다.

Partition pins는 종종 reconfigurable partition의 주변에 가까운 어딘가에 함께 그룹화됩니다. Vivado는 특정 design에 너무 특화되지 않은 사이트를 선택하도록 설계된 것 같습니다.

그러나 partition pins는 Parent Implementation동안 timing constraints를 달성하는 데 필요한 경우 reconfigurable partition내부 어디에서나 찾을 수 있습니다. static design은 reconfigurable partition내부에 있는 routing 용 리소스를 사용할 수 있습니다. 따라서 static routing의 일부가 reconfigurable partition로 들어가는 데 문제가 없습니다.

timing constraints 및 partition pins의 문제를 방지하려면 reconfigurable module 의 output ports가 registers가 고 inputs 도 registers 에서 샘플링되는 것이 좋습니다. 마찬가지로 static logic은 registers를 비슷하게 적용하는 것이 좋습니다. 사실, 가능할 때마다 design이 복잡하지 않을 때 항상 이 규칙을 따르는 것이 좋습니다.

Greybox

DFX Wizard 에 대한 또 하나의 사항은 greybox입니다. Edit Configuration 창에서 일반 reconfigurable modules대신 greybox를 reconfigurable module로 지정할 수 있습니다. greybox는 Vivado에 의해 생성된 가짜 module 입니다. 실제 reconfigurable module의 ports 에 맞지만 실제 logic대신 모든 port pin에 대해 하나의 LUT가 있습니다. inputs 용으로 생성된 LUTs는 다른 쪽 끝에 아무 것도 연결되어 있지 않으며 outputs 용 LUTs는 0 값을 생성합니다. vector ports의 경우 vector의 각 bit 에 대해 LUT가 생성됩니다.

place and route 프로세스를 너무 쉽게 만들기 때문에 Parent Implementation에서 greybox를 사용하는 것은 좋은 생각이 아닐 수 있습니다. reconfigurable modules가 서로 매우 다르다 하더라도, 도구에 어느 정도 도전하는 간단한 module을 작성하는 것이 더 나을 것입니다.

그러나 최소한의 logic로 initial bitstream 파일을 생성하려면 greybox modules 만 포함하는 child implementation이 유용할 수 있습니다. 모든 implementations는 완전히 동일한 static logic을 가지고 있기 때문에 모두 initial bitstream로 사용할 수 있는 완전한 bitstreams를 생산한다는 것을 기억하십시오.

Clearing Bitstreams (Ultrascale 만 해당)

이것은 Ultrascale FPGAs 에만 관련됩니다( Ultrascale+아님 ).

위에서 언급했듯이 모든 implementations는 두 개의 bitstreams를 만듭니다. 전체 design을 위한 하나의 bitstream . 초기에 FPGA를 로드하는 데 사용할 수 있으며 관련 reconfigurable module이 포함되어 있습니다. 두 번째 bitstream은 동일한 reconfigurable module이 있는 Partial Reconfiguration 용입니다.

Ultrascale 장치에는 각 implementation에서 생성되는 세 번째 bitstream인 "clearing bitstream"가 있습니다. 이 bitstream은 partial bitstream보다 먼저 FPGA 로 보내져야 합니다. FPGA 로 전송되는 clearing bitstream은 로드될 bitstream이 아니라 현재 FPGA내부에 있는 logic 와 일치해야 합니다. 따라서 다른 FPGA 제품군에서는 필요하지 않은 FPGA의 현재 상황을 추적할 필요가 있습니다.

clearing bitstream을 로드하면 logic이 실제로 변경되지 않더라도 reconfigurable module이 종료됩니다. 이 module 의 output ports는 새 partial bitstream이 로드되고 시작될 때까지 값을 표시할 수 있습니다.

UG909에 따르면 잘못된 reconfigurable module 의 clearing bitstream을 로드하면(즉, 이미 FPGA에 있는 logic 와 일치하는 clearing bitstream이 아님) static logic 도 중단될 수 있으므로 reconfiguration 메커니즘의 오작동이 발생할 수 있습니다.

Xilinx의 문서는 clearing bitstream을 먼저 로드하지 않고 partial bitstream을 로드하면 어떻게 되는지에 관해 모호한 것 같습니다. UG909 의 9장에서 먼저 다음과 같이 말합니다. "Prior to loading in a partial bitstream for a new Reconfigurable Module, the existing Reconfigurable Module must be cleared". 따라서 결론은 clearing bitstream이 필수라는 것입니다.

그러나 몇 줄 아래에 동일한 가이드에 "If a clearing bit file is not loaded, initialization routines (GSR) have no effect"라고 나와 있습니다. 이것은 모든 synchronous elements (원칙적으로RAMs 와 flip-flops)가 알 수 없는 상태에서 깨어나는 것이 괜찮다면 clearing bitstream을 전혀 사용하지 않아도 괜찮다는 것을 의미합니다. clearing bitstream을 건너뛰는 내 자신의 일화적인 실험에서 나는 아무런 문제를 보지 못했지만 아무 것도 증명하지 못했습니다.

따라서 Ultrascale FPGAs를 사용하면 FPGA에 로드된 내용을 추적해야 합니다. 이는 예를 들어 reconfigurable module에 output port를 추가하여 수행할 수 있습니다. 이 reconfigurable module에는 각 reconfigurable module에 대해 서로 다른 상수 값( ID code)이 있습니다. 이를 통해 static logic은 현재 로드된 reconfigurable module을 식별할 수 있습니다. 이와 같은 ID code는 상관없이 좋은 아이디어가 될 수 있습니다.

Plugin 대 Remote Update 사용 사례

Vivado가 채택한 이 parent-child 방법론은 분명히 plugin usage라고 부를 특정 사용 사례를 위해 설계되었습니다. FPGA 내부에 가능한 모든 기능을 항상 포함하는 대신 현재 필요한 reconfigurable module을 로드하여 FPGA의 비용을 줄입니다. 예를 들어 FPGA가 여러 image filters를 구현하는 데 사용되는 경우 Partial Reconfiguration은 각 filter를 reconfigurable module로 구현하고 필요한 filter 로만 FPGA를 다시 로드할 수 있습니다.

Xilinx는 Partial Configuration에 대해 "Dynamic Function eXchange"(DFX)라는 용어를 사용하며 이 기술의 기본 용도를 반영하는 것으로 보입니다.

parent-child 방법이 Partial Reconfiguration의 목적일 때 잘 작동합니다. bitstream files 의 완전한 키트가 생성됩니다. 모든 initial bitstreams는 FPGA를 초기화하는 데 사용할 수 있으며 모든 reconfigurable bitstreams는 나중에 Partial Reconfiguration에 사용할 수 있습니다. 프로젝트의 새 버전이 출시되면 모든 bitfiles로 구성된 전체 키트가 교체됩니다.

그러나 Remote Update라고 하는 또 다른 사용 패턴이 있습니다. 그것은 Partial Reconfiguration이 아마도 먼 미래에 버전 업그레이드를 위한 수단으로 사용될 때입니다. 이 사용 시나리오에서 initial bitstream은 특정 시점에 출시되며 이후에는 변경할 수 없습니다. 나중에 partial bitstreams가 출시되며 initial bitstream와 호환되어야 합니다. 이러한 이후 릴리스는 몇 년 동안 계속될 수 있습니다.

Remote Update의 경우 parent-child 방식은 그대로 사용하기 어려울 수 있습니다. parent의 Implementation을 반복하지 않고 Child Implementation을 실행하여 새 partial bitstream을 얻을 수는 있지만 오랜 시간 동안 이를 수행하는 것은 어려울 수 있습니다. 예를 들어, static logic 의 source code가 우발적으로 변경되면 parent의 design이 무효화되어 Parent Implementation이 반복됩니다. 결과적으로 새로운 static logic은 이전 static logic 와 호환되지 않으므로 이를 기반으로 하는 partial bitstream은 원래 initial bitstream와 함께 사용할 수 없습니다.

따라서 Partial Reconfiguration이 시간이 지남에 따라 FPGA design을 연속적으로 업데이트하는 방법으로 의도된 경우 implementation 절차는 약간의 조작이 필요합니다. 이 항목은 이 시리즈의 마지막 게시물에서 설명합니다.

bitstreams압축

이것은 Partial Reconfiguration와 직접적인 관련이 없지만, 특히 FPGA의 빠른 시작을 보장하기 위해 작은 initial bitstream 파일이 필요한 경우가 있습니다. 이러한 맥락에서 Partial Reconfiguration은 빠른 시작 후 불러오기 프로세스를 완료하는 수단이 됩니다. 이는 동일한 데이터 소스(예: SPI flash) 또는 완전히 다른 소스(예: PCIe 인터페이스)에서 수행할 수 있습니다.

bitstream 압축은 initial bitstream 와 partial bitstreams모두에 허용됩니다.

압축된 bitstream을 요청하기 위해 XDC 파일에 추가할 행입니다.

set_property bitstream.general.compress true [current_design]

이것으로 이론적인 부분을 마칩니다. 다음 게시물 은 Partial Reconfiguration을 사용하도록 프로젝트를 구성하는 실제 단계를 보여줍니다.

이 페이지는 영어에서 자동으로 번역됩니다. 불분명한 사항이 있으면 원본 페이지를 참조하십시오.
Copyright © 2021-2024. All rights reserved. (6f913017)