VHDL : 아키텍처 명명 및 해석

참고 : Xilinx의 ISE를 사용하고 있으며 스위치 및 조명 등을 사용할 수있는 FPGA 보드가 있으며 지금까지 간단한 프로젝트를 해킹했습니다. 동시에 나는 내가하고있는 일에 대한 기초를 구축하기 위해 여러 자습서를 읽고 있습니다.

필자가 겪은 참조 자료에 언급 된 다양한 엔티티와 해당 아키텍처를 보았지만 종종 이름이 혼동됩니다. 종종 "architecture rtl of .."또는 "architecture structure of ..." 대신 "architecture foo of ..."또는 "architecture arch of ..."가 표시됩니다.

아키텍처 이름이 엔터티 이름 지정만큼 임의적이라는 것을 알고 있지만,이 문제를 피하기 위해보다 일관된 이름 지정 규칙을 사용할 수있는 스타일 가이드가 있습니다. 이것은 몇 가지 질문으로 이어집니다.

• 엔티티를 살펴보면 아키텍처 이름의 힌트없이 사용중인 실제 아키텍처 모델을 어떻게 확인할 수 있습니까? RTL, 행동 적, 구조적 ... 그것들은 내 학습자의 눈과 매우 유사 해 보입니다 (내가 본 예제가 실제로 올바르게 명명되었다고 가정). 간단하지만 명백한 예가 여기에 도움이 될 것입니다 (또는 하나의 포인터).

• 단일 엔터티에 여러 아키텍처를 지정하는 경우 (가능한 것으로 이해합니다) 아키텍처에 동일한 파일에서 다른 이름을 지정합니까?

• 아키텍처 이름이 주어진 엔티티에 국한되어 있습니까 (즉, 여러 엔티티에 동일한 아키텍처 이름을 사용하여 "네임 스페이스"에 문제가 있습니까?)

편집 : 그리고 하나 더 :

• RTL과 행동 사이에는 차이가 있지만 위에서 언급 한 것처럼 실제로 본 예제에서는 그것을 보지 못합니다 (종종 정의 된 아키텍처 만 보입니다). 하나의 아키텍처가 다른 아키텍처보다 일반적입니까?

내가 찾고있는 것은 모범 사례 (적절한 명명, 모든 파일에 포함되지는 않음 등)를 사용하여 작성된 포괄적이지만 단순한 다중 구성 요소 프로젝트 (작은 구성 요소)이지만 아직 찾지 못했습니다. 제대로 제작 된 샘플 프로젝트는 기본 원칙과 모범 사례를 밝히는 데 매우 유용합니다. 그러한 예제 프로젝트를 알고 있다면 그것에 대한 포인터에 감사드립니다. (아무것도, 아마 이것을 알아 낸 후에는 내 자신의 것을 공유 할 수 있습니다 ...)

엔티티를 살펴보면 아키텍처 이름의 힌트없이 사용중인 실제 아키텍처 모델을 어떻게 확인할 수 있습니까?

인스턴스를 생성 하거나 구성 할 때 아키텍처를 지정하거나 (선택할 항목이 둘 이상인 경우) 기본값을 선택할 수 없습니다.

단일 엔터티에 여러 아키텍처를 지정하는 경우 (가능한 것으로 이해합니다) 아키텍처에 동일한 파일에서 다른 이름을 지정합니까?

당신은 그들에게 다른 이름을 부여합니다. 동일한 파일 내에있을 필요는 없습니다 (사실 VHDL은 파일의 내용에 대해 생각하는 것보다 훨씬 덜 중요합니다)

아키텍처 이름이 주어진 엔티티에 국한되어 있습니까 (즉, 여러 엔티티에 동일한 아키텍처 이름을 사용하여 "네임 스페이스"에 문제가 있습니까?)

이들은 엔티티에 "연결되어"재사용 될 수 있습니다.

나는 종종 a1합성 가능한 모든 것을위한 나의 아키텍처로 사용 한다

• rtl 내가 쓰는 것보다 낮은 수준 (많은 독자에게)을 의미합니다.
• behavioural 종종 합성 할 수 없음을 암시합니다 (일부 독자에게)
• synth 신디사이저가 모델에 사용합니다 (그렇지 않으면 사용했습니다)

a1 지금까지 충돌하지 않았으며 혼란을 유발하지 않습니다.)

실제로 두 개 이상의 건축물이있는 경우, I (예를 들어 자세하게 그 이름을하는 경향이 hard_multipliers와 lut_multipliers- 여부 - MUL18 차단하는 인스턴스 필터).

종종 하나의 아키텍처 만 있으므로 중요하지 않습니다. 좋은 엔티티 이름이 훨씬 더 중요합니다.

RTL과 행동 사이에는 차이가 있지만 위에서 언급 한 것처럼 실제로 본 예제에서는 그것을 보지 못합니다 (종종 정의 된 아키텍처 만 보입니다). 하나의 아키텍처가 다른 아키텍처보다 일반적입니까?

역사적으로- "동작"코드를 합성 할 수 없었습니다 (한 번에 추가와 같은 것을 포함했습니다!). 따라서 가산기 등을 인스턴스화하는 RTL 버전을 만들었습니다. (그것이 이해하는대로-1999 년경 VHDLing을 시작한 이래로 행동 적이지만 여전히 합성 가능한 코드를 작성했습니다!)

아키텍처 유형은 다음과 같습니다.

행동 :

일반 사항 :

• 도구마다 다르지만 일반적으로 계층 구조는 없습니다 (파일 하나만, 구성 요소를 인스턴스화하지 않음).
• 시뮬레이션이 매우 빠릅니다.
• 신호 동작이 정의됩니다.
• 행동이 시뮬레이션에 사용될 때, 그것은 합성 불가능한 코드를 포함 할 수 있습니다. 합성을위한 행동은 당연히 합성 할 수 있어야합니다.

자일링스 관련 노트

• 일반적으로 핵심 생성기 모델은 사전 합성 .vhd 파일입니다.

구조 :

일반 정의

• 구성 요소를 인스턴스화하고 함께 연결합니다 (계층 적).
• 행동보다 시뮬레이션 속도가 느립니다.
• 최상위 레벨에는 실제 신호 동작 정의가 없습니다.
• 합성 가능한 코드 만.

자일링스 xpecific 노트

• 코어 생성기 모델은 타이밍을 고려하지 않습니다.
• 일반적으로 코어 생성기 모델은 합성 후 넷리스트를 인스턴스화합니다

위는 기본적으로 건축의 주요 두 동물입니다. 매우 일반적으로 "혼합 된"정의가 사용되며, 둘 다의 특성을 포함합니다.

RTL :

RTL은 하루가 끝날 무렵에 실제로 FPGA에 배치되는 내용입니다. 따라서 이것은 시스템의 동작을 정의하는 합성 가능한 코드이며 코드 계층 구조로
구성됩니다. 하단 레이어는 합성 가능한 동작이며, 신호 동작의 핵심은 정의되며 상위 레벨은 구조적입니다. 행동 구성 요소는 함께 묶여 있으면 최상위 최상위 "블록 다이어그램"을 만들 수 있습니다.

여러 아키텍처로 :

아키텍처는 모두 하나의 파일 또는 여러 파일에있을 수 있습니다. 중요한 것은 엔티티가 먼저 컴파일되고 사용될 아키텍처가 지정된다는 것입니다.

이 책 은 매우 편리하며 이런 종류의 내용을 아주 잘 설명합니다.

별개의 행동 및 구조적 모델을 가지고 있거나 단순히 혼합하는 측면에서 어떻게해야하는지에 대한 단단하고 빠른 규칙은 없습니다. 일반적으로 거대한 펌웨어 디자인 (또는 코드를 공유하고 재사용하는 대기업)에서는 문제를 단순화하기 위해 두 가지를 구별하는 것이 유용하지만 하루가 끝나면 어떤 것이 든 문제가 없습니다.

우선, 실제 건축 설계를 그렇게 엄격하게 분류 할 수는 없습니다. 왜 자신을 제한합니까? 다른 엔터티를 인스턴스화하고 "구조적으로"연결하려고 할 수 있지만 여기에 거기에 프로세스 또는 동시 할당을 추가하여 "rtl"논리를 추가하고 "동작"코딩 패턴을 사용하여 신디사이저가 지역 / 파이프 라이닝 / 성능 매개 변수로 가산기를 구체적으로 인스턴스화하지 않고 추가하는 것과 같이 신경 쓰지 않는 세부 사항은 모두 동일한 아키텍처입니다.

더 중요한 것은 현재 asic / fpga 기술에서 합성 할 수있는 것과 그렇지 않은 것을 이해해야하며, 이는 아키텍처 모델과 관계가 없습니다.

엔티티는 여러 가지 방식으로 구현되어 약간 다른 동작을 허용 할 수 있으므로 동일한 엔티티에 대해 여러 아키텍처를 가질 수 있습니다. 또한 "실제"버전보다 더 빠르게 시뮬레이션 할 수있는 시뮬레이션 전용 아키텍처 (일반적으로 합성 할 수 없음)가있을 수 있으며, 이는 큰 디자인을 전체적으로 테스트 벤치 할 때 유용 할 수 있습니다. 이러한 아키텍처 이름을 다른 아키텍처와 다르게 만드는 것을 기억하는 데 도움이되는 이름을 부여 할 수 있으며 실제 디자인의 하이브리드 특성을 고려할 때 bhv / str / rtl은 일반적으로 충분하지 않거나 정확하지 않습니다.

특정 질문과 관련하여 아키텍처 선언은 엔터티 이름과 연결되므로 다른 엔터티에 대해 동일한 이름의 아키텍처와 관련된 네임 스페이스 문제는 없습니다. 동일한 엔터티에 대해 아키텍처에 다른 이름을 사용하십시오.

아키텍처는 다른 파일에 상주 할 수 있으므로 엔티티 선언이 먼저 컴파일되도록해야합니다.

엔티티를 인스턴스화하거나 구성 명령문을 사용할 때 사용할 아키텍처를 선택할 수 있습니다. 그렇지 않으면 기본값은 컴파일러가 주어진 엔티티 선언에 대해 마지막으로 본 아키텍처입니다.