SystemC에서 배포가능 버전 만들기

SystemC와  Verilog의 가장 큰 차이점 중에 한가지는 배포본 만들기에 있습니다.

C/C++은 각각의 Class에 필요한 함수와 변수등을 Header파일에 선언하고 함수 등을 선언 한 뒤에

cpp파일에서 구현하게 됩니다.

비록 배포 버전에서는 cpp파일을 object로 바꾸어서 전달할 수 있지만 header파일을 찬찬히 보면,

세부 사양은 알 수 없더라도, 어떤 방식으로 구성되어 있는지 등은 알 수 있습니다.  

SystemC도 엄밀하게는 C++위에서 구성되어 있어서 마찬가지로 이런 문제점이 발생합니다.

IP의 생명인 보안성 부분에서는 상당히 취약하다고 할 수 있습니다.  

그래서 귀찮지만 Pointer로 받아서 구현하는 방식을 취합니다.

이 방식은 ME C++에서 설명한 방식입니다만, SystemC에서 응용할 줄은 몰랐습니다.

PIMPL Idiom 구현 방식입니다. 말 그대로 Pointer로 받아서 구현하는 것이므로,  Pointer IMPlementation 구현 방식입니다.

일종의 Pointer Wrapper 방식이라 할 수 있습니다.

위와 같이 DesignModule을 설계하였으면 이것을 그냥 배포하는 것은 곤란하므로

DesignModule_wrapper를 쒸워서 내부 설계 정보를 최대한 Hidden 시켜서 배포하게 됩니다.

Wrapper가 가지는 조건은 다음과 같이 됩니다.

당연하게 포트가 같아야 합니다.

   - 나중에 실제 모듈로 대치하게 된다면 포트 이름도 같이 해두는게 당연히 좋습니다.

그럼 아래와 같이 예를 들어 보겠습니다.

설계한 모듈은

DesignModule이라고 한다면 header파일과 cpp파일을 가지고 있습니다.

DesignModule.h

SC_MODULE(DesigModule)

{

// Port Declaration

PortA ;

PortB ;

PortC ;

// 이하는 뭔가 중요할 것만 같은 .. 중요해야 되는 디자인 정보.. T__T;;

......

......

}

DesignModule.cpp

.....

이것을 쒸울 Wrapper는

DesignModule_Wrapper.h

class DesignModule; // 미리 클래스라고 알려주어서 컴파일 시에 오류가 생기지 않도록 한다.

SC_MODULE(DesignModule_Wrapper)

{

// Port Declaration

        SC_CTOR(DesignModule_Wrapper){

DesignModule_Wrapper_port();

        };

//

private :

DesignModule * pDesignModule;       // 이렇게 하위 클래스의 포인터를 선언해서 받아온다.

virtual ~ DesignModule_Wrapper();  // 포인터로 선언해서 나중에 new 연산으로 할당

                                                                     //  할 것이므로 Destructor에서 반드시 Delete해 주어야 한다.

                void DesignModule_Wrapper_port();

}

DesignModule_Wrapper.cpp

#include "DesignModulle.h"

DesignModule_Wrapper::DesignModule_Wrapper_port()

{

   pDesignModule = new DesignModule;

   pDesignModule->PortA(PortA);

   pDesignModule->PortB(PortB);

   pDesignModule->PortC(PortC);

}

......

DesignModule_Wrapper ::~ DesignModule_Wrapper()

{

delete pDesignModule;

}

 

DesignModule.h파일을 DesignModule_Wrapper.cpp파일에서 불러들인다는 점이 중요합니다.

즉, 실제 디자인에 관련된 정보는 DesignModule.h파일에 있으며 이 것을 Wrapper용 Header File에서 Include하지 않음으로서 Compile 시에 Dependency를 제거해 주는 것이 목적이 됩니다.

따라서 최종 사용자는

DesignModule_Wrapper.h

와

DesignModule_Wrapper.o

DesignModule.o

3개 파일을 받게 되는 것입니다.

물론 Obj들은 Lib으로 묶어 버리면 2개 정도 파일만 가면 되는 것이어서 큰 문제가 없이 잘 됩니다.

최종 유저에게 오픈되어 있는 정보는 DesignModule_Wrapper.h 파일 뿐이므로 실제 디자인 내부 정보는 오픈되지 않습니다.

이 방식은 Wrapper를 거치는 방식이므로, 실제 동작시에는 느려진다고 합니다.

어느정도까지 느려질 지는 테스트 해보지 않아서 잘 모르겠습니다.