So other than making sure that there are no timing or DRC violations in our design (spoiler: it’s all good!) we are interested in the resource utilization. We already know that our logic works, we tested that both in the C/RTL Co-Simulation in Vitis HLS and in the traditional RTL functional simulation in Vivado. Finally! After all this we definitely want to see our dBFS Converter placed and routed onto the FPGA. At any case, we can see that the result of the dBFS conversion matches the output generated by runing the linear-to-dBFS conversion formula on a desktop PC. Interestingly, setting the radix of the virtual bus to cover the integral and fractional parts of the signal yields a different result than setting the radix of each signal separately. This happens 240 clock cycles after the conversion was started, which is the same latency reported by Vitis HLS after the C Synthesis.īecause we mapped the integer and fractional outputs of the dBFS Converter to two different signals (‘dbfs value integer‘ and ‘dbfs value fraction‘) we will create a virtual bus in the waveform window (dBFS Value) to see the complete result. The right cursor marks the time at which the dBFS Converter finished its processing and generates an output, as signaled by the enabling of the ‘dbfs converter done‘ signal. the ‘absolute mono sum’ signal) holds the value 1135. At this moment, the input of the dBFS Converter (i.e. The left cursor shows the time where the LED Meter logic initiates the conversion of the very first sample of our test audio file by enabling the ‘dbfs converter start’ input of the dBFS Converter core.
LOGICWORKS VS VIVADO CODE
All three updates to the LED Meter module are shown in the code below. We will take the integral part and compare it to the 8-step scala that we have defined for our dBFS LED Meter.
Because of the limited resolution that 8 LEDs provide, we will ignore the fractional part of the resturned dBFS values.
LOGICWORKS VS VIVADO UPDATE
The third and final update to the LED Meter has to do with the comparators that drive the LEDs. But then again, since we are not showing the actual dBFS values in a display but using them to drive the LEDs on the ZedBoard, it will suffice to adjust our RTL description so that a value of zero in the linear scale causes all the LEDs to turn off. While this is correct from a purely mathematical standpoint, we would like to have a linear value of zero be equal to +/-1, that is, produce the most negative dBFS possible. Going back to the second installment of the series, the C Simulation revealed that a value of zero in the linear scale, our conversion formula returns 0 dBFS. Second, we must add logic to handle the case where the input to the dBFS Converter is zero. We also need to wait until it has finished performing the conversion before we can update the LEDs. We now need to perform three updates to our LED Meter code.įirst, we need drive the inputs of the dBFS Converter with the right data at the right time. After Vivado has generated the IP files we can find the top-level module definition for our dBFS Converter and use it to create an instance of it in the LED Meter.
0 kommentar(er)
