작성
·
270
1
우선 vivado tool에 대한 이해도가 상당히 낮습니다 ㅜㅠ 그래도 혼자 최대한 해보자는 마음으로 이것저것 만져보고 있는데 이해가 안되는 점이 있어서 질문드립니다!
강의에서 말씀하시길
wire [5-1:0] hour_val = (r_sec_cnt/(60*60)) % 24;
부분이 critical path라고 말씀하셨는데
vivado에서 bitstream을 생성하던 중에 오류를 보니까
뭔가 느낌상 source, destination 부분을 보면 될 거 같더군요
근데 destination이 o_hour가 아닌 o_min으로 돼있더라구요
혹시나해서 o_hour로 가는 path를 열어보니 거기선 positive slack이었습니다.
그래서 이걸 보고 위 코드가 아닌
wire [6-1:0] min_val = (r_sec_cnt/60) % 60;
해당 코드에서 neg slack이 발생한 거 같은데 맞을까요??
그리고 해결책으론 re-timing을 사용하셨는데 제가 1차원적으로 생각하기엔
clock period를 두배하면, 즉 100MHz가 아닌 50MHz로 바꾸면 뭔가 굳이 코드를 수정하지 않아도 될 거 같은데 맞는 논리일까요..?
답변 2
0
안녕하세요 🙂
critical path 는 Vivado 의 버전에 따른 합성 알고리즘에 따라 변경될 수 있습니다.
따라서 말씀해 주신 부분이 critical path 로 잡힌다면, 그 부분을 해결하시면 됩니다. (캡쳐내용의 분석은 정확하게 잘 보셨어요)
해결책은 말씀해주신대로 Clock freq 를 낮추는 방법이 가장 쉽습니다.
그에따른 수정도 같이 해주셔야 하고요. (당연한거죠?)
즐공하세요 🙂
0
안녕하세요, 인프런 AI 인턴입니다.
먼저, Vivado tool에 대한 질문을 해주셔서 감사합니다. 타이밍 리포트 분석에 어려움을 겪는 건 초보자에게 매우 자연스러운 일입니다. 제시해주신 내용으로 봤을 때, critical path 문제는 실제로 hour_val
이 아닌 min_val
의 계산에서 발생했을 가능성이 높아 보입니다.
주어진 타이밍 리포트의 Slack 값이 -2.120ns라고 한다면, 이는 해당 path가 목표한 클락 주기 안에 데이터를 전달하지 못하고 있음을 뜻합니다. Destination이 o_min
으로 되어 있다면, 이는 분(minute) 값을 계산하는 로직에 문제가 있음을 시사합니다.
코드에서 hour_val
대신 min_val
연산에서 negative slack이 발견된 것 같다고 생각하셨을 때, 그 분석은 맞는 방향으로 진행하고 계신 것입니다.
클록 주기를 늘리는 것은 한 가지 해결책이 될 수 있습니다. 만약 100MHz에서 50MHz로 클록 주기를 두 배 늘린다면, 각 플립플롭(FF) 사이의 데이터가 이동해야 할 시간이 늘어나게 되어 타이밍 문제를 완화시킬 수 있습니다. 그러나 이는 처리 성능을 절반으로 줄이는 결과를 가져올 수 있으니, 성능 저하를 감수해야 합니다.
다른 해결 방법으로는 리타이밍(re-timing)이 있습니다. 이는 로직 레벨을 조정하거나, 배치를 최적화하거나, 다양한 제약 조건을 이용해 디지털 로직을 다시 합성하는 방법을 말합니다.
자세한 해결 방안은 디자인의 목표와 요구사항에 따라 다를 수 있습니다. 때로는 코드 최적화가 필요하거나, 클록 주파수를 조정하거나, 파이프라이닝 기법을 도입하는 등 여러 접근법이 있을 수 있습니다.
프로젝트 목표에 맞게 성능과 시간 제한 사이에서 최적의 균형을 찾는 것이 중요합니다. 추가적인 도움이 필요하시다면 더 자세한 상황 설명과 함께 문의해주시면 감사하겠습니다.
도움되셨길 바라며, 추가적인 질문이 있으시면 언제든지 문의해주세요.