작성
·
151
·
수정됨
1
안녕하세요 맛비님
갑자기 한 발상이 떠올라서 제 방식대로 FIFO를 만들어서(입출력포트는 동일) 챕터 6에 테스트벤치로 시뮬레이션을 돌려보았습니다.
그 결과 피니쉬 타임이 기존 강의내용에서 2435ns 였는데 2305ns 줄어들었습니다.
그리고 rtl.v.txt 파일도 문제없이 0부터 99 차례대로 출력됩니다.
이것이 데이터의 전송 bandwidth가 상승했다고 판단할 수 있을까요?
파형에서는 제가 의도한대로 핸드쉐이크 과정이 일어납니다.
구성하신 테스트벤치에 대한 이해가 아직 부족해 확신이 안들어 질문드립니다..
맛비님 수준의 현업자 입장에서 보았을때 저보다 훨씬 정확한 판단을 들을 수 있을거 같아 질문드립니다.
질문 요약 : 챕터 6의 테스트벤치 기준 피니쉬 타임이 줄어들었고, result 텍스트파일이 강의때와 똑같이 나온다면 데이터 전송 bandwidth를 상승시켰다고 판단할 수 있는건지? 입니다.
더욱이 만약 맞다면 이정도의 속도상승은 현업에서 어느정도의 영향인지도 알려주시면 감사하겠습니다…
설계 선배님으로서 항상 존경하고 감사드립니다!
이상입니다.
답변 2
1
맛비님 답변을 제가 잘 이해한 것인지 확인부탁드립니다. 늦은 밤에 죄송합니다..
register to register는 제가 구성한 combinational 로직이 원래 설계보다 크리티컬 패스의 딜레이가 클 수 있기에 고려해야한다 라는 이해가 맞나요?? 아니면 register 사이에 조합로직이 없는 경우가 있을 수 있기에 이것을 고려하시라는 말씀인가요??
제 설계의 핵심은 원래 empty 상황에서 read가 불가능 한 한계를 극복하는 것입니다. empty 상황에서 FIFO에 write가 일어날 시 read 요구가 동시에 있다면 같은 사이클에 write와 read를 동시에 일어나게 하는 것입니다. 그래서 이러한 상황이 자주 발생할 수록 전송 사이클을 줄여 핸드쉐이크의 초당 발생 수가 증가하는데요. 그럼 초당 유효한 데이터가 자주 발생하니 대역폭을 상승시켰다고 저는 판단했었습니다. 맛비님께서 말씀하신 것은 핸드쉐이크 수가 늘어나는것이 전체 크리티컬 패스 딜레이와는 무관하기에 전체 클럭 주파수가 증가할 여지가 없어 전체 대역폭에는 영향이 없다고 하시는걸까요?
늦은 밤에 다시한번 죄송하고 답변주신것 정말 감사드립니다!
0
안녕하세요 🙂
Pipeline 의 개념을 알고 계시다면, Bandwidth 의 상승은 아니라고 판단됩니다.
Latency 를 줄이신 것은 맞아요. 이 용어는 Season1 에서 다루었기 때문에, 충분한 설명이라 생각됩니다.
그래도 Latency 를 줄이셨기 때문에 훌륭한 수정이라고 생각해요, 대신 Timing 적으로 (Register to Register) 손해가 본 부분이 있는지 확인해보시는 것도 공부에 도움이 될 것 같아요.
즐공하세요 🙂
안녕하세요 🙂
1번은 “register to register는 제가 구성한 combinational 로직이 원래 설계보다 크리티컬 패스의 딜레이가 클 수 있기에 고려해야한다 라는 이해가 맞나요??” 이 문구에 동의합니다.
2번은 비교를 해보시겠어요? waveform 으로 수정 전 후를 확인해보셨으면 합니다. 제가 생각하는 BW 상승은 freq 를 올리기, data width 확장이고요.
empty 상황의 보강은 fifo depth 로 커버할 수 있다고 봐요.
latency 를 줄인 것은 응답시간과 관련이 있다고 생각합니다. 다만 pipeline 으로 인한 한번 data 가 나온 이후의 BW 는 수정 전후가 유사? 하지 않을까? 의 측면에서 답변드렸어요. 생각을 정리해보시고, 그림과 같이 남겨주시면 저도 공부에 도움이 될 것 같아요. (작성하신 글만 보았을때.. 제대로 이해한건가 싶네요. 민성님이 맞다고 생각하시면 맞겠죠.. ㅎㅎ)
즐공하세요 🙂