Goolge_adsense_default_ad




AHB 대비 AXI 프로토콜의 장점 몇 가지 칩 설계 지식 공유해요~

지난 번 AHB 프로토콜에 대해서 간단히 글을 썼었는데, 이번엔 좀 더 글의 범위를 넓혀서 AHB 프로토콜과 비교하여 AXI 프로토콜이 가진 장점에 대해서 한 번 정리해 보려고 합니다. AXI 프로토콜은 먼저 발표된 AHB 프로토콜의 단점을 보완하고 변화하는 칩 설계 환경을 반영하기 위해 2003년에 AMBA 3 프로토콜의 일부로 처음 발표 되었고, 2010년 AMBA 4, 2013년 AMBA 5 가 연속해서 발표 되면서 지속적인 업데이트가 이루어 지고 있습니다. (http://en.wikipedia.org/wiki/Advanced_Microcontroller_Bus_Architecture 참조) 각 AMBA 버전에 따른 AXI 프로토콜의 이름은 AMBA의 이름을 따라서 AXI3, AXI4, AXI5 등으로 붙여지는데 이 글에서는 가장 기본적인 AXI3와 AHB를 비교해 보도록 하겠습니다 .
 
AXI 프로토콜이 발표된 배경에는 NoC(Network-on-Chip) 설계 기법의 등장이 있습니다. 2000년대 초반 부터 미세 공정 기술의 발달과 함께 시스템의 주요 기능을 하나의 칩 안에 집적하는 SoC (System-on-Chip) 설계가 널리 퍼지기 시작했고 이와 함께 서로 연결되어야 하는 CPU, 메모리 컨트롤러, DMA, GPU, 기타 등등 기능블럭의 숫자가 점점 늘어나게 되었습니다. (앞으로 이러한 기능 블럭들은 줄여서 IP 라고 부르도록 하겠습니다. IP = Intellectual Property) 연결되어야 할 IP의 갯수가 많다 보니 하나의 버스를 나눠쓰는 방식으로는 확장성에 한계를 느끼기 시작했고, SoC 안에서도 버스 대신에 여러개의 스위치로 구성된 패킷을 주고 받는 네크워크가 필요하다는 공감대가 형성되었지요. 이러한 이유로 NoC설계 기법이 주목받기 시작했는데 NoC의 등장배경에 관심이 있다면 링크의 논문을 읽어 보시기 바랍니다. 1000번 이상 인용된 NoC 연구자들 사이에서는 꽤나 유명한 논문입니다.

이제 본론으로 들어가서, AXI 프로토콜이 가진 장점에 대해 이야기 해 보도록 하겠습니다. 앞에서 이야기한 NoC 설계 기법과 관련이 있는데, AXI 프로토콜의 첫번째 장점은 패킷을 주고 받는 네트워크를 설계하기에 편하다는 점 입니다. AHB 프로토콜의 경우는 address phase와 data phase가 함께 이어져 있어야 하기 때문에 DDR SDRAM 이나 플래쉬 메모리처럼 접근시 초기 latency가 있을 경우 data가 전송되지 않으면서도 버스를 점유할 수 밖에 없는 상황이 발생 합니다. 반면에, AXI 프로토콜의 경우는 address와 data channel을 독립적으로 분리하여 칩상의 네트워크를 쓸데없이 점유하는 상황을 피할 수 있습니다.  간단한 예로 아래의 경우를 한 번 살펴보도록 하겠습니다. (클릭하면 그림이 크게 보입니다.)

 
0x1000 번지의 메모리로 부터 4개의 연속된 data A, B, C, D를 4-burst로 읽어 들이는 상황에서 5 사이클의 초기 latency가 발생하는 경우 AHB와 AXI 인터페이스의 주요 신호들이 어떤 식으로 동작하는지를 비교한 그림 입니다.  AHB의 경우에는 메모리의 5 사이클 latency 동안 (그림의 빨간색으로 표시된 부분) HTRANS 신호의 상태가 SEQ로 유지되어 버스를 점유해야 하지만, AXI의 경우 read address channel을 통해서 1 cycle 만에 address 정보를 보내고 5사이클 이후에 독립된 read data channel을 통해서 data를 읽어 들이기 때문에 메모리의 latency가 발생하는 동안에도 버스 또는 온칩 네트워크의 스위치를 점유하지 않는 장점이 있습니다. Data에 접근할 때 발생하는 latency 동안 온칩 네트워크를 점유하지 않는 특징은 NoC를 설계할 때 엄청난 장점, 아니 필수적인 요소가 되는데 다음과 같은 상황을 생각해 보면 쉽게 알수 있습니다. 


왼쪽 그림의 예와 같이 IP의 개수가 적을 경우에는, Master IP 0와 Master IP 1 사이에서만 버스를 나누어 쓰게 되므로 Slave IP 들의 latency를 기다리면서 data가 전송되지 않음에도 버스를 점유하더라도 성능상에 크게 문제가 되지 않습니다. 하지만 오른쪽의 예와 같이 여러개의 Master IP 와 Slave IP가 여러개의 crossbar switch를 통해 연결된 경우에는 큰 문제가 발생하게 됩니다. Master IP 0가 Slave IP 0를 access 하는 동안 중간의 link를 쓸데 없이 붙잡고 있다면 나머지 Master IP들은 Slave IP1 ~ IP3가 자유로운 상태임에도 중간의 link가 막혀서 접근할 수 없게 되는 것이지요. (그림은 Master IP 0 때문에 Master IP 4가 Slave IP1~3 까지 어느 것도 접근하지 못하는 상황입니다.) 이러한 이유로 AXI 프로토콜은 AHB에 비해 복잡한 온 칩 네트워크를 구성하는데 매우 유리한 장점이 있습니다.

AXI의 또 다른 장점은 multiple outstanding request를 (이하 MOR) 지원 한다는 점입니다. 먼저 설명을 위해 AXI 프로토콜에서 하나의 read/write 동작이 아래와 같은 순서로 이루어 짐을 짚고 넘어 가겠습니다.
 AXI read : Read address channel로 address 전송 --> Read data channel로 data 읽음
                 (AR channel phase)                               (R channel phase)
 AXI write : Write address channel로 address 전송 --> Write data channel로 data 쓰기 --> Write response channel로 쓰기 완료 확인
                  (AW channel phase)                               (W channel phase)                        (B channel phase)

상대적으로 간단한 read 동작의 예를 들어 MOR이 지원될 경우와 지원되지 않는 경우의 AR/R channel phase 순서를 비교하면, MOR 지원 여부에 따라 아래와 같이 동작이 달라지게 됩니다. (0x1000, 0x2000 번지를 순서대로 read 한다고 가정)
 MOR을 지원하지 않는 경우
 AR channel phase (0x1000) --> R channel phase (0x1000) --> AR channel phase (0x2000) --> R channel phase (0x2000)
 MOR을 지원할 경우
 AR channel phase (0x1000) --> AR channel phase (0x2000) --> R channel phase (0x1000) --> R channel phase (0x2000)  
 (참고로 MOR을 지원할 경우 위의 두 가지 방식 중 어느 방식으로 동작하더라도 AXI 프로토콜에 부합합니다.)
즉 MOR을 지원한다면 Master IP는 먼저 보낸 read(또는 write) address에 대한 data 읽기(또는 쓰기)가 완료되었는지 여부에 상관없이 바로 다음에 접근할 read(또는 write) address를 미리 보낼 수 있게 되는 것입니다. 

MOR이 지원 될 경우의 장점은 DDR SDRAM과 같이 throughput은 높지만 초기 접근시의 latency가 큰 메모리에 접근할 때 명확해 집니다. 위의 예에서 0x1000 번지와 0x2000 번지에서 순차적으로 data를 읽어 들이는 경우 메모리 latency 가 50사이클이라고 가정하면, MOR의 지원 여부에 따라 아래와 같은 성능 차이가 발생하게 됩니다. MOR을 지원할 경우에는 첫 번째 read request를 보내고 data가 돌아올 때 까지 기다리는 시간을 낭비하지 않고 바로 두 번째 read request를 보낼 수 있어 53 사이클 만에 두 주소에 대한 읽기 동작이 완료 되지만, MOR을 지원하지 않는 경우 50 사이클의 latency를 두 번 겪을 수 밖에 없어서 똑같은 동작에 대해서 103 사이클의 시간이 걸리게 됩니다.  

AXI의 경우에는 address와 data channel이 독립되어 있어 MOR 지원이 자연스럽지만 AHB의 경우에는 address와 data phase를 분리할 수 없는 프로토콜의 특성상 MOR을 지원할 수가 없습니다. 
 
AXI의 또 다른 장점은 각각의 read/write request에 다른 AXI ID를 사용할 수 있다는 점입니다. AXI 프로토콜에서는 각 request의 ID로 사용될 수 있는 A(R/W)ID (= ARID or AWID) 신호를 정의하고 있는데A(R/W)ADDR 신호와 함께 전송되는 A(R/W)ID신호를 이용하여 시스템 관점에서 다양한 기능을 구현 할 수 있습니다. 아래는 간단한 예인데, AXI ID 정보를 온 칩 네트워크의 Quality-of-Service (QoS)와 연동하는 상황을 가정해 봅시다. 만약 CPU의 Memory Management Unit (MMU)에서 페이지 miss가 발생한다면 MMU는 TLB의 miss가 발생한 부분을 새로 채우기 위해 1~ 3단계에 걸처셔 페이지 테이블을 읽어 들이는 page table walk을 수행해야 합니다. 이 경우 TLB miss 때문에 같은 page에 접근하는 모든 read/write가 잠시 멈추게 되어 전체 동작의 성능이 저하되는 상황을 피하기 위해 시스템 설계자는 page table walk을 수행하기 위한 MMU read request에 특정한 AXI ID를 할당하고 온 칩 네트워크의 QoS 관리정책에서 해당 AXI ID에 우선권을 주는 방법을 설계상의 선택지로 고려할 수 있습니다. 물론 예로 든 이러한 방법이 정말 이득이 있는지는 시스템 구성과 응용분야에 따라 달라지겠지만 AXI의 ID가 제공됨으로 인해 적어도 시스템 설계상의 자유도는 올라가는 것이지요. 

그리고 AXI ID는 memory consistency model 과 관련된 memory ordering을 구현하는데도 도움이 됩니다. AXI 프로토콜에서는 같은 ID를 가진 request에 대해서는 응답이 request를 보낸 순서대로 와야 하지만, 다른 ID를 가진 request들 간에는 응답이 오는 순서가 상관이 없기 때문에 반드시 순서가 유지되어야 하는 메모리 접근의 경우에는 같은 AXI ID를 사용하여 in-order 동작을 강제하고 메모리 접근 사이의 의존성이 없는 경우에는 다른 AXI ID를 사용하여 out-of-order 동작을 허용하여 시스템의 전반적인 성능을 향상 시키면서 시스템 동작의 정확성(correctness)도 잃지 않을 수 있습니다. 반면에 AHB 프로토콜을 사용하면 하나의 master IP에서는 이전 transaction이 끝나야만 다음 transaction을 시작 할 수 있기 때문에 in-order 메모리 접근 이외에는 허용이 되지 않습니다.

그 밖에 AHB에 비해 AXI가 가진 장점이 많이 있겠습니다만, 분량이 너무 많아지는 것 같아 한 가지만 더 언급을 하면서 이번 글을 마무리 하도록 하겠습니다. AXI의 또 다른 장점은 write 동작을 할 때 WSTRB 신호를 사용하여 한 번에 write 하는 data width에 상관없이 자유롭게 byte 단위로 일부분을 선택하여 write를 수행할 수 있다는 점 입니다. 
 
위의 그림과 같이 32-bit data를 byte(8-bit) 단위로 4등분 한 후 그중의 1~4개 부분을 선택적으로 write 하는 경우를 생각해 봅시다. (파란색이 선택적으로 write가 수행되는 부분입니다.) AHB의 경우에는 HSIZE 신호를 이용해 8, 16, 32, 64 ~ 1024 의 단위로 몇 bit 접근인지 만을 표시할 수 있고 주소를 나타내는 HADDR 신호는 HSIZE에 맞춰서 align이 되어야 하는 제한이 있기 때문에  윗 그림의 상단부와 같이 byte가 1, 2, 4개로 연속된 경우에만 한 번에 write를 수행할 수 있습니다. 윗 그림의 하단부와 같이 연속되지 않은 byte를 update 할 경우에는 상단부의 가능한 조합 중에서 하단부의 조합을 만들 수 있는 두 가지 조합을 잘 찾아 두 번에 걸쳐서 write 동작을 수행해야 하지요. 하지만 AXI의 경우에는 WSTRB 신호를 사용하여 32-bit 중에 byte 단위로 어떤 부분을 write 할지 선택할 수 있기 때문에 어떤 경우에도 한 번의 write 동작으로 partial byte update를 수행할 수 있습니다. 이 경우 필요한 WSTRB 신호의 값은 그림에 함께 표시되어 있습니다.  

이제 제가 생각하는 AHB 프로토콜 대비 AXI의 장점을 다시 한 번 정리 하면서 글을 마무리 하겠습니다. 
 1. 복잡한 온 칩 네트워크를 구성하는데 유리
 2. Multiple Outstanding Request를 지원하여 latency가 길게 발생하는 메모리 접근에 유리
 3. AXI ID 지원으로 시스템 레벨에서 다양한 온 칩 네트워크 QoS 구현 가능
 4. WSTRB 신호를 이용하여 partial byte update 동작 수행시 AHB 대비 유리
글을 길게 쓴 것 같은데 간단히 정리하니 몇 가지 되지 않네요. -_-;  물론 이것 말고도 다른 장점이 더 있습니다만, 저는 저의 칩 설계 경험에서 느낀 몇 가지만 정리를 해 보았습니다. 긴 글 읽어 주셔서 감사합니다.


Update : 




핑백

  • 20151105 | gumdaeng 2015-11-05 10:35:26 #

    ... 이유, http://donghyun53.egloos.com/4077209 [4] 김동현, AHB 대비 AXI 프로토콜의 장점 몇 가지, http://donghyun53.egloos.com/4087409 Share this:TwitterFacebookGooglePrintEmailLike this:Like Loading...2015 ... more

  • NIC-301/400 CDAS의 이해 – 호기심이 깊어질 때 – 골수공돌이의 공간입니다. 2017-03-07 00:32:16 #

    ... 픽의 비순차(out-of-order) 진행을 통해 시스템의 전반적인 성능 향상을 기대할 수 있습니다. AXI 프로토콜의 특징에 대해 조금 더 자세한 내용이 궁금하실 경우 제가 예전에 썼던 글을 참고하시기 바랍니다. Master 1개와 Slave 2개가 연결된 간단한 AXI 버스 공학에서는 항상 얻는것이 있으면 잃는것이 있기 마련이라, AXI 프로토콜은 MO ... more

덧글

  • Corpse 2014/03/28 16:24 # 삭제 답글

    조금 자유로워 지시니 이런 좋은정보가 올라오네요. 신입사원에게 필독 시켜야 겠습니다
  • 골수공돌이 2014/03/28 23:31 #

     와우~! 영광입니다 ^^
  • 공돌이2 2014/06/02 23:09 # 삭제 답글

    안녕하세요? 골수 공돌이님.
    ARM Processor 는 그 종류가 M0, M3, R4 등등 여러가지가 있는것으로 알고 있는데요.
    이런 Processor에 붙는 Bus 는 그 종류가 딱 정해져 있는건가요?
    예를들어 M0 는 AHB-Lite, M3, R4 는 AXI 3.0 등 이렇게 정해져 있는것인지 아니면 어떤 기준으로 버스를 선택해서 CPU 에 interface 시키는건지 알려주시면 정말 감사드리겠습니다.
    아 그리고 amba designer kit 으로 생성한 bus rtl 이 바로 arm 에 붙게 interface 되어있나요? 아니면 보통 생성한 버스랑 Processor 랑 어떻게 붙이는지 잘 모르겠습니다.
    요즘 공부할꼐 많은데 알도리가 없던차에 이렇게 덧글을 올려드립니다.

    감사합니다.
  • 골수공돌이 2014/06/02 23:28 #

    ARM사에서 나오는 M0, M3 같은 프로세서들은 ARM사에서 RTL을 제공하는 소프트 IP로 적절한 AMBA interface가 이미 정해져 있습니다.
    예를들어 ARM9 프로세서는 AHB 인터페이스를 사용하고 Cortex-A8 프로세서는 AXI 인터페이스를 가지고 있습니다.
    Cortex 프로세서 중에는 option으로 버스 인터페이스의 개수를 1개로 할지 2개로 할지 정도를 정할 수 있구요.
    보통 super scalar / Out-of-Order(OoO) 프로세서의 경우는 multiple outstanding transaction을 issue 할 수 있도록 AXI 인터페이스를
    채용하고 보다 간단한 single data path/in-order 프로세서의 경우에는 간단한 구현을 위해 AHB 인터페이스를 채용합니다.
    AMBA designer kit으로 버스를 생성할 때 프로세서의 버스 인터페이스 사양과 일치하게 parameter를 잘 정하면 바로 ARM 프로세서에
    붙일 수 있습니다. RTL이 생성되니 RTL에서 module 끼리 연결하듯이 wire 선언해서 연결하시면 됩니다.
    자세한 내용은 ARM사 홈페이지의 각 프로세서 별 Technical Reference Manual을 찾아 보시기 바랍니다~^^

  • 공돌이2 2014/06/02 23:45 # 삭제 답글

    답변 감사드립니다.
    이전에 있던곳은 M0 를 사용하였었는데 그때 기억으로 AHB Lite로 구성이 되어있었던걸로 기억이 나는것 같습니다.
    그때는 궁금하지도 않았는데 돌이켜보니까 왜 AXI 가 아니였을까 했는데..말씀하신바대로 성능에 따라서 정해져 있나보네요.

    골수 공돌이님 혹시 BUS 와 Memory 를 interface 시키는 방법에는 어떤게 있나요?
    지금은 CoreLink NIC-301 IP 를 선택하여 Bus 를 생성을 해보고 있는데요.
    간단하게 Single port sram을 AXI 버스에 붙혀보고 싶은데..도저히 예제나 이런게 없어서 좀 막막합니다.
    보통 이런경우 업체에서 샘플 디자인을 제공하나요? 도저히 ADK 안에아무리 뒤져봐도 해당 내용은 보이지가 않아서.
    BUS에 다이렉트로 붙여서 동작을 시켜보려고하는데요.. 어떤 방법들이 있는지 궁금합니다.
  • 골수공돌이 2014/06/03 23:02 #

    버스와 메모리를 인터페이스 하기 위해서는 메모리 컨트롤러가 필요합니다.
    AXI 프로토콜 신호를 SRAM 제어 신호로 바꾸는 건 그리 어렵지 않으니 직접 짜셔도 되구요
    아니면 PL350 SMC (Static Memory Controller)를 구하실 수 있다면 붙여서 사용하시면 됩니다.
    그리고 ADK는 AMBA 버스 생성용 툴이라 메모리 컨트롤러를 제공하지 않는 것으로 알고 있습니다.
    PL350 SMC에 관한 정보는 아래 링크를 참고 하세요.
    http://infocenter.arm.com/help/topic/com.arm.doc.ddi0380g/DDI0380G_smc_pl350_series_r2p1_trm.pdf
  • 공돌이2 2014/07/14 15:44 # 삭제 답글

    안녕하세요 공돌이님
    Nic301로 버스를 생성하여서 실제 master 와 slave를 붙여보려고 하고 있습니다. master 같은경우 제가 읽고 기다린후 쓰고 이런 일련의 과정의 작업을 쉽게 만들수가 있는데 (슬레이브가 미리 존재하고 있는 디자인만 다뤄서 )그런데 여기서 이제는 슬레이브가 없는 디자인이니까 제가 슬레이브도 만들어야 할ㅇ것 같은데 좀 어떻게 해야하는지 감이 잘 안와서요

    마스터같은경우는 aw ar bready보면서 응답오는데로 데이타를 써주면 끝이였는데요 버스를 생성해보니 이제 슬레이브를 어떻게 만들어줘야할지 감이 안옵니다
    그냥 마스터와같이 뭔가 마스터에서 보면 반응하여 전달하는 로직을 구성하면 될까요?
    이게 좀 감이 없어서 조언 부탁드려 봅니다
  • 골수공돌이 2014/07/14 23:21 #

    일단 AXI slave를 설계하실 때 주의하실 점은 A(R/W)SIZE 신호랑 burst length, wrapping인지 increasing 인지를 보면서 address를 잘 만들어내시는게 중요합니다. address align이 맞지 않을 때 AXI spec.에 명시 되지 않은 부분이 있어서 어떻게 처리할지가 애매할 때가 있는데, NIC-301이랑 붙여서 동작시키면 맞춰가시면 됩니다. 그리고 write일 경우에는 WSTRB 신호도 조심해서 다루셔야 하구요.
    구체적인 질문이 아니라 제가 드릴 수 있는 대답은 여기까지인 것 같습니다. ^^;
  • 공돌이2 2014/07/16 20:31 # 삭제 답글

    안녕하세요? 공돌이님
    Master의 awready나 wready bready신호는 slave의 상태에 따라서 입력이 transition되어서 들어가는거 아닌가요?
    Master 하나에 slave2개를 엮어서 테스트 중인데요 slave는 2개 전부 0신호를 나가게 해주었습니다
    제 생각에는 master가 awvalid신호를 보내도 awready신호가 입력으로 안올줄 알았는데 희안하게 awready가 high로 assert되는데요 이게 정상인가요? 어디를 체크해 봐야 할지 감이 안오네요
  • 골수공돌이 2014/07/16 23:50 #

    말씀하신 현상은 NIC301 버스를 생성하실 때 parameter로 줬던 read/write acceptance capability와 관계가 있을겁니다. 만약에 write acceptance capability를 4로 설정했다면 slave의 ready 신호를 0으로 묶어 놓았더라도 4개의 request까지는 master 쪽에서는 ready가 high로 유지 되다가 5번째 request를 보낼 때야 ready가 low로 떨어질겁니다.
  • 공돌이2 2014/07/17 20:06 # 삭제 답글

    답변감사드립니다 공돌이님 
    일단 master와 slave를 대충 만들어서 돌려보고 있습니다 그런데 개념이 안잡히는게 있어서요

    Master쪽에도
    awid, wid, bid, arid, rid 가 있고
    Slave쪽에도 
    awid, wid, bid, arid, rid가 있는데

    여기 있는 id들은 전부 out of oder를 위해서 존재 하는것 같은데요
    궁금한것은 가령 예를 들어서 지금하고 있는 예제에서처럼 마스터 하나에 슬레이브 2개로 구성된 시스템에서
    마스터가 awid[1:0]이라고 한다면 각각의 슬레이브 즉 첫번째 슬레이브 와 두번째 슬레이브에서awid를 보고 자기 id 인경우 동작하게끔해야한다면 각 슬레이브 안에 2개의 동작 즉 첫번째 슬레이브 안에는 두번째 슬레이브의 동작이 포함되고 두번째 슬레이브에는 첫번째 슬레이브의 동작들이 기술되어야 하나요? 이렇게 되면 너무 봅잡하게 될껏 같습니다 보통은 backbone에 각 슬레이브에 해당하는 id값을 instance module에 밖아 넣나요? 아니면 어떻게 보통 처리를 하는게 똑똑하게 제어하는것인지 궁금합니다. 즉 id를 어떻게 처리 하는지 잘 감이 안와서요.

    제가 알기로는 먼저 온놈을 먼저 처리한다 의 개념으로 알고 있는데 그럼 마스터 안에서 각 id병 동작 케이스들을 전부 다 만들어주어야 하는건가요?
    예를들어서 마스터블럭안에 아이디가 1이 들어오면 제가 queuing하고 있다가 아이디 1에대한 것들이 들어오면 맞춰서 처리한다던지..이게 굉장히 복잡해 보이는 이유가 awid 따로 있고 wid따로 있고 bid따로 있고 이런식이므로 각각에 대한 처리를 어떻게 순서를 맞춰야하는지. . 잘 감이 안와서요

  • 골수공돌이 2014/07/18 10:49 #

    제가 쓰신글을 완전히 이해하지는 못한 것 같습니다. 다만 AXI 버스에 붙어있는 slave IP는 ID를 보고 응답할지 안할지를 결정하지 않습니다. Master IP가 보낸 request가 어느 slave로 전달되는지는 오직 주소에 의해서만 결정됩니다.
    그리고 master에는 ID별로 따로 동작가능한 block이 존재하는게 일반적입니다.
    저의 대답이 크게 도움이 되지는 못한 것 같네요 ^^;;
  • 공돌이2 2014/07/18 14:48 # 삭제 답글

    공돌이님 master에는 ID 별로 따로 동작 가능한 block이 존재한다고하셨는데요
    말씀하신 ID라 하시면 awid와 wid bid를 한세트로 일컫으신 말씀이신거죠?
    즉 awid와 wid bid가 공통적으로 예를 들어 1이면 awid wid bid가 1일때 무슨무슨 동작,
    awid 와 wid bid가 공통으로2 이면 무슨 무슨 동작 이런식으로 생각하면되나요?

    아니면 awid는 1일때 wid의값 1,2,3에 따른 세부 동작 사항을 모두 기술 해야 한다는 말씀이신건가요?
    만약 아래와 같은 방법이라면 그 기술해야하는 갯수가 x^n이 될껏 같은데요.
    제가 이해한게 맞을까요?
  • 골수공돌이 2014/07/18 17:14 #

    네 먼저 말씀하신대로 id별로 address/data/response channel들이 한 세트로 동작한다고 생각하시면 됩니다.
  • 공돌이2 2014/07/21 12:41 # 삭제 답글

    공돌이님 말씀 주신 답변 감사드립니다

    Master IP가 보낸 request가 어느 slave로 전달되는지는 오직 주소에 의해서만 결정됩니다.
    그리고 master에는 ID별로 따로 동작가능한 block이 존재하는게 일반적입니다.
    위와같이 답변을 주셨는데요
    MasterIP가 보낸 request가 어느 slave로 전달되는지는 오직 주소로 결정되지만 그 한주소에 ID값에 따른 다른 처리들이 들어가야 할것 같은데요 예를 들어서 slave0에 acceptance가 4개라고 한다면 slavle0의 주소에 4개의 Id별로 처리를 해주는 동작을 기술해야 될것같습니다.
    그런데 slave0가 갖고 있는 bus interface ports는 하나 이므로 slave0의 각 ID별 동작또한 slave0내부에서 queueing을 직접 작업해줘야 하는거아닌가 싶습니다 (사실 여기서 보통 어떻게 설계가 되는지 궁금합니다 이런방법으로 실제 설계를 하시는지 아니면 슬레이브에 id는 1개만 쓰기로하는대신 슬레이브 개수를 늘린다던지..)
    그래서 먼저끝난 slave0의 각 ID블럭 버스에 알려줘야 될것 같은데요.
    그런데 조금 생각해보니 이런 일련의 과정이 마스 버스의 Arbiter와 많이 닮아 있습니다. 그래서 보통 실무에서 어떻게 작업이 들어가는지 궁금해져서요..
    마찬가지로 답변주신 내용중에 master에는 ID별로 따로 동작가능한 block이 존재하는게 일반적입니다.
    라고 하신 부분도.다시말하면 slave내에서도 id별로 따로 동작 가능한 block이 존재한다고 말할수 있을것 같습니다





  • 골수공돌이 2014/07/21 13:26 #

    acceptance capability는 NIC-301과 관련된 parameter이고 NIC-301의 acceptance capability가 4라고 해서 함께 연결되는 slave IP의 acceptance capability가 반드시 4일 필요는 없습니다. ID별로 독립적인 처리를 위해서 slave IP 내부에서 ID 별로 request queue가 있어야 하는 것은 맞습니다. 그리고 ID별로 독립된 request queue를 구성하는 것이 설계상 많이 어렵지는 않습니다.
  • 공돌이2 2014/07/21 17:46 # 삭제 답글

    공돌이님 답변 감사드려요

    한가지 궁금한게 있는데요
    Nic301버스 생성시 MOR을 지원하게 만들면 멀티MOR issue시 버스 에 queue가 있어서 각 issue를 관리한다고 봤는데요 이부분을 말씀하신건지 헸갈려서요 즉 버스queue가 실제 역활을하는것이 있는지요?

    아 그리고 이건 다른 궁금한점인데요 amba designer로생성한 버스를 이용해서 master와 slave를 붙여서 테스트를 할때 도움 받을수 있는 testbench나 assertion이 있을까요?

    즉 마스터와 슬레이브를 붙일때 이게 제대로 붙인건지 아닌지 확인할수 있는 방법이 궁금한데요 혹시 어떤방법을 주로 사용하시는지 궁금해요


  • 골수공돌이 2014/07/22 10:37 #

    버스에는 ID별로 queue가 있지 않습니다. 버스안의 buffer(queue)는 ID에 상관없이 read/write acceptance capability 만큼 request를 일시적으로 저장합니다. 버스가 AXI ID를 구분해서 다른 우선순위를 주려고 한다면 NIC-301다음 product인 NIC-400에서 QVN (QoS Virtual Network) 옵션을 사용해야 합니다.

    testbench나 assertion은 회사의 엔지니어의 고유한 know-how에 해당하는 부분이라 공개된 것을 찾기가 힘드실 겁니다. 만약에 회사에서 프로젝트를 진행하신다고 하면 Cadence사의 Verification IP (VIP) 제품 중에 AXI conformance test VIP를 구입하시는 방법도 있습니다. 제가 주워들은 가격은 IP별로 하나당 수천만원 정도였던 것 같습니다.

    기본적으로 AMBA designer 에서 생성된 버스가 제대로 동작하는지에 대한 test는 가능합니다. Master/Slave IP가 제대로 붙었는지 확인하려면 사용하려는 다양한 case에 대해서 check list를 작성하시고 일일이 돌려보는 방법이 기본적입니다. Address range, burst size, address alignment, read/write 순서 등을 다양하게 바꿔 가면서 예상한 대로 동작하는지를 확인하셔야 합니다. (노력이 상당히 많이 드는 일입니다.)
  • 공돌이2 2014/07/22 22:18 # 삭제 답글

    답변 감사드려요 공돌이님
    VIP나 이런것들은 시뮬레이션에서 가능한 방법일것 같은데요
    실제 FPGA에서 테스트할수 있는 방법은 없을까요? 예전에 어디선가 TBM?이였나? BMT? 이런게 있다고 했던것 같은데 잘 모르겠네요 실무에서는 어떤 방법을 사용하는지 궁금합니다 (칩나오기 전에 FPGA에서요)
  • 골수공돌이 2014/07/23 09:31 #

    저의 생각으로는 가능한한 모든 test는 시뮬레이션으로 커버하고 실제로 회로의 동작이 필요할 때만 FPGA를 동작시키는 게 좋을 것 같습니다. FPGA에서 NIC-301을 테스트 하기에는 불필요한 일들이 너무 많이 생길 것 같습니다.
  • 공돌이2 2014/08/18 15:06 # 삭제 답글

    골수공돌이님
    혹시 axi lite에서 interleaving기능이 있는것 같은데요 이 interleaving이 실제 디자인에 어떤 부분에 도움을 주는건가요?
  • 골수공돌이 2014/08/18 15:53 #

    AXI lite라기 보다는 AXI 3버전에 write interleaving 기능이 있습니다.
    A, B 마스터 두개가 100MHz로 동작하는 상황에서 AXI버스가 200MHz로 동작하고 있다고 가정해 봅시다.
    A,B 마스터가 AXI 버스의 slave 포트 C로 동시에 4개씩 burst로 write를 한다고 하면 write interleave 기능이 없다면
    버스가 두배의 속도이므로 버스 입장에서는 다음과 같이 data를 전송해야 합니다.
    A->(쉬고)->A->(쉬고)->A->(쉬고)->A->(쉬고)-> B->(쉬고)->B->(쉬고)->B->(쉬고)->B->(쉬고)
    만약에 write interleaving 기능이 있다면 아래와 같이 전송할 수 있습니다.
    A->B->A->B->A->B->A->B
    하지만 구현이 복잡해지는 정도에 비해 성능상의 이익을 보는 경우가 적어 AXI4에서는 기능이 삭제 되었습니다.
  • 공돌이2 2014/11/18 14:53 # 삭제 답글

    안녕하새요? 골수공돌이님 잘지내시죠?
    Amba designer kit에서 Stitching기능에 대해서 혹시 문의 드려도 돨까요?
    AMBA Designer 에 보면 Stitch RTL 이라는 부분이 있는데요. 이게 뭐하는건지 잘 모르겠어서요.

    뭔가해서 버튼을 눌러도 빨간색으로 막대기가 표시되는데 .so 가 없다던지..혹은 bus definition not available이라는 메세지가 나오는데 왜그런건지 잘 모르겠습니다.
    Stitch가 뭐하려고 만들어 논건지 혹시 알수 있을까요?
  • 공돌이2 2014/11/25 13:40 # 삭제 답글

    공돌이님 혹시 말씀하신 AXI 프로토콜 신호를 SRAM 제어 신호로 바꾸는 건 그리 어렵지 않으니 직접 짜셔도 되구요  에서 제어신호로 어떻게 바꾸어야 하나요? 지금 몇일째 이것때문에 계속 사이트 뒤져보면서 관련자료를 찾아보아도 찾을수가 없어서 이렇게 답글 남깁니다
  • 골수공돌이 2014/11/26 08:57 #

    한동안 이직 때문에 정신이 없어 블로그에 신경을 못 썼습니다. 아마 인터넷 상에서 찾을 수 있는 자료는 AXI 프로토콜 spec. 밖에 없을 겁니다. 직접 생각하셔서 코드를 작성해야 한다는 말씀 이외에는 드리지 못하겠네요 ^^;;
  • 공돌이2 2014/11/26 15:56 # 삭제 답글

    아 그렇셨군요. 많이 정신이 없으셨을텐데 대단하십니다.
    공돌이님 혹시 amba bus matrix에서 remap의 개념이 기존의 address map이 있는경우 remap 신호가 들어오면 새로운 map으로 address map이 바뀌는것을 이미하는것 같은데요.
    굳이 이런 remap은 단순히 롬에서 램으로 부팅할때 외는 사용하지 않치 않나요?
    지금 보고 있는 ARM DDI 0243C 문서에서 3.8.9의 Address map부분의 설명을 보면 No remap support라고 나로는데 Example 3-1을 보면 또 remap이 지원되는것 같습니다.

    제가 Example 3-1 에서 궁금한것이 있는데요 address region에서 interface MI0가 2개가 어드레스는 다르지만 interface이름은 동일 한것을 볼수 있는데요이게 무슨 의미인지 잘 모르겠습니다.

    그리고 Address region에서 만약에 remapping 파라미터가 alias나 none으로 셋팅되면 remaping은 새로운 어드레스 공간안에 정의된 영역의 alias를 만든다라고 되어있는데요.
    여기서 설명하고있는 new address space가 어디에 있는 공간인지 모르겠습니다. 기존에 정의하고 남은 address map의 아무 빈공간을 의미하는것인지.
    그리고 만약에 remapping parameter가 move로 set이 되면 original address space가 삭제되고 master interface가 new address space 안에서 remap region에의해 정의된 location에 나타난다고 되어 있는데요 이건 말그대로 기존에 선언한 address map이 삭제되고 다른곳으로 움직인다는것 같은데요 이게 어디에서 사용되나요?

    그리고 여기서 remap_region의 역활이 뭔지 모르겠습니다
  • 골수공돌이 2014/12/02 14:44 #

    기본적으로 AMBA 버스는 remap 기능을 지원하는게 맞습니다. 다만 3.8.9는 command line parameter를 사용해서 버스를 생성하면 remap 기능을 지원할 수 없다는 내용인 것 같습니다.

    MI0와 관련된 부분은 연속하지 않는 두 address region 해당하는 접근이 MI0로 가게된다는 얘기 입니다.
    remap 이 아닐때에는 0x40000000~0x4fff_ffff, 0x7000_0000~0x7fff_ffff 주소에 해당하는 접근이 MI0로 routing 되고
    remap일 대는 0x00000000~0x1fffffff, 0x7000_0000~0x7fff_ffff 주소에 해당하는 접근이 MI0로 routing 되는 식입니다.

    그리고 말씀하신 new_address space는 example 3-1에서 remap_regsion으로 정의된 주소들을 말합니다.
  • 공돌이2 2014/12/05 12:00 # 삭제 답글

    안녕하세요? 공돌이님 
    한가지 궁금한것이 있는데요 amba 의 remap은 이해를 하였는데요. 근데 DDI0243C 문서에서 보면 remap 과 pause controller라는것이 APB Components안에 들어 있습니다. 근데 이름이 remapPause이네요.
    이건 REMAP 이랑은 다른건가요? 이게 왜 APB Components안에 Remap and pause controller라는 이름으로 APB Components안에 있는지 이해가 가질 않아서요.. 설명은 interruput mode를 기다리는 부분에 대해서 system boot behavior와 low power를 control를 제공한다라소 되어 있는데 당쵀 무슨 말인지 모르겠습니다.

    그리고 또 support arbiter pause mode? Support delayed pause action?
    이런 질문이 있던데요 이게 amba bus에서 지원을 하는건가요? 연관된것 같은데 도저히 이 기능들이 뭔지 모르겠어서요. 골수 공돌이님 혹시 이부분에 대해서 설명을 부탁 드려도 될까요?



  • 골수공돌이 2014/12/16 08:49 #

    제가 지난 주 내내 해외 출장중이어서 답글이 늦었습니다. ^^; Remap/Pause controller 모두 system booting 시에 쓰이는 기능입니다. 사실 Pause 기능은 잘 쓰지는 않고 보통은 reset controller를 따로 두어서 시스템을 구현하기는 합니다만, bus의 pause 동작이든 reset controller든 목적은 프로세서가 메모리 컨트롤러가 정상적으로 초기화되기 전에 미리 메모리를 접근해서 잘못된 instruction을 읽어 들이는 것을 막는 것입니다. Pause를 쓰면 버스가 잠시 멈춰있는 거고 reset controller를 쓰면 프로세서가 멈춰있는 차이가 생기지요. Power control 관련은 pause가 들어가면 버스가 쓸데없이 동작하지 않으니 power가 줄어든다는 뜻으로 생각하시면 될 것 같습니다. arbiter pause mode와 delayed pause action은 제가 잘 모르겠습니다. 문서의 어느 부분에 나와 있는지요?
  • 공돌이2 2014/12/19 09:51 # 삭제 답글

    아 예 arbiter pause mode와 delayed pause action verification IP 쪽에 문서에 적혀 있어서 문의 드렸었어요.
    아마도 방금 말씀해 주신 부분을 의미하는것이 아닐까 추측을 해볼께요. 제가 문서를 찾을수 있으면 알려드리도록 하겠습니다.

    감사합니다.
  • 박근우 2016/03/16 01:02 # 삭제 답글

    안녕하세요? 공돌이님 포스팅을 보고 몇가지 궁금한점이 있어서 이렇게 질문드립니다.

    AXI 에서는 Burst Read/Write 을 지원하는데 가령 5개의 master 와 5 개의 Slave 가 존재한다고 했을때.
    m_1, m_2, m_3, m_4, m_5, // s_1, s_2, s_3, s_4, s_5, 이렇게 있다고 할때.
    m_1 은 s_1~s_5 를 전부 컨트롤 할수 있는것으로 알고 있는데요.
    그런데 어떻게 s_1~s_5 를 컨트롤 할수 있는건가요?
    Q1.가령 m_1 에서 10 이라는 데이타를 s_1~s_5 에 각각 저장을 하고 싶다면 m_1 은 s_1 이 어디에 있는지 어떻게 알수 있는건가요?

    Q2.만약 s_1~s_5 가 각각 메모리 어드레스로 구분이 된다면 interconnect 에 연결할수 있는 slave 수는 한정될것 같은데요(maser도 한정될것 같습니다.).
    만약 맞다면 이 한정된것을 어떻게 극복할수 있나요?

    미리 감사드립니다. ^^;
  • 골수공돌이 2016/03/18 00:38 #

    요즘 블로그를 관리할 시간이 없어 간단히 답변 드리는 점 양해 부탁드립니다.

    Q1) 마스터인 m_1은 물리적으로 s_1이 어디있는지 알지 못합니다. 다만 s_1이 영역으로 정해진 address를 access하면 s_1으로 read/write transaction을 보내는 것은 버스나 NoC (NIC-301/NIC-400 등)의 책임입니다. AW/AR channel의 경우 address를 보고 버스 내부의 각 switch 마다 몇 번 port로 routing을 할 지 결정을 하고 W channel의 경우 선행하는 AW channel의 routing 값을 그대로 이용하며 이 path가 닫히는 시점은 B Channel을 통해 response가 돌아올 때 입니다. Read data를 돌려 보내는 R channel의 경우 AXI ID를 이용하여 address 정보 없이도 s_1의 data를 m_1으로 돌려 보냅니다.

    Q2) s_1~s_5 는 각각 address로 구분되며 master/slave수는 한정되는 것이 맞습니다. 왠만한 칩의 경우 address 제약으로 인해 master/slave 수가 한정되더라도 부족한 경우는 거의 없습니다. 그리고 동작 모드에 따라 Memory map을 변경하는 Remap 기능이나 virtual->physical address 변환 등으로 지원되는 master/slave 수를 늘릴수도 있습니다. 보통은 address 영역이 모자라기 보다는 물리적으로 구현하는 부분에서 한계에 부딪힙니다.
  • 이민우 2016/04/06 20:29 # 삭제 답글

    안녕하세요? 골수공돌이님,
    ARM CPU 중에는 캐쉬가 달린 놈들이 있는데요 제가 좀 이해가 안가는 부분이 있습니다.
    CPU 는 각기 버스가 연결되도록 되어 있는것으로 알고 있는데요 캐쉬와 버스는 무슨 관련이 있는건가요?
    제가 아는 캐쉬는 CPU 에서 처리할때 처리속도를 빨리 하기위해서 Cache 라는곳에 미리 자주쓰는 데이타를 채워 넣는곳으로 알고 있습니다. 그런데 제가 좀 이해가 안가는것은 만약에 영상처리를 하는 시스템이라고 한다면 영상데이타가 엄청나게 버스로 들어갔다나갔다를 할텐데 CPU 가 이 영상데이타를 다룬다고 봐야하나요? CPU 에 달려있는 버스와 Cache 가의 상관관계를 혹시 좀 알려주시면 감사드리겠습니다.
  • 골수공돌이 2016/04/18 14:46 #

    해외 출장으로 답글이 늦은 점 양해 부탁드립니다. L1 cache의 경우 CPU와 함께 포함되어 있는 경우가 거의 대부분 입니다만, L2 cache의 경우 CPU 종류에 따라 CPU 외부에 버스를 통해서 연결 될 수도 있습니다. 칩 안에서는 칩과 칩사이의 연결보다 bit-width를 늘리거나 속도를 늘리는 것이 상당히 자유롭기 때문에 수 GB/s정도의 대역폭을 달성하는데 크게 무리가 없습니다. 그런 이유로 CPU를 cache 안에 포함하지 않고 버스를 통해 CPU 밖에 둘 수도 있는 것이구요. 다만 최신의 CPU의 경우 대부분 L2 cache를 내장하고 있으며 GPU나 비디오 Codec등과 공유하는 System Level (또는 L3 cache)를 DDR 메모리 컨트롤러 블럭과 함께 두기도 합니다.
  • SiliconVal 2016/05/11 10:44 # 삭제 답글

    이민우님.
    Multi-core SOC경우에는 많은 CPU, 예를 들면 32 core, 들이 각각 L1/2 cache와 L3 cache를 가지고 있는데, 각 CPU가 같은 주소, cacheline을 access하면, 각 cache들끼리 업데이트가 되어야하는데 write-back, MOSE 프로토콜같은 경우 서로간에 cache 를 업데이트해주는 snoop filter나 directory-based같은 cache 프로토콜들이 있습니다. 그래서 새로운 memory write이 오면 shared되어있는 cache를 invalidation하는 등등의 coherent traffic이 있습니다.

    AMBA ACE protocol specification을 보시면 이런 coherent traffic 에 대해 자세히 알수 있습니다.
    www.gstitt.ece.ufl.edu/courses/fall15/eel4720_5721/labs/refs/AXI4_specification.pdf
댓글 입력 영역