Timeline for With IP-Cores without handshake protocol, how can I verify (VHDL assert?) their latency?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 6, 2017 at 0:24 | comment | added | Paebbels | The DSP core should do the same. Vendors create stupid customers/designers by offering everything in generated IP cores. You'll find even simple up/down counters... You should always question yourself: Do I need a core or can I write it down in simple VHDL? Pure VHDL is portable: change the Xilinx FPGA device without reconfiguring the IP core, change the FPGA family e.g. from Spartan to Kintex or change the vendor from Xilinx to Lattice.... | |
| Aug 6, 2017 at 0:20 | comment | added | Paebbels | @JohannesSchaub-litb No, it doesn't need to be in a process. The optimization is down after the language model was transformed into an initial netlist model. The optimizer sees a binary multiplication operation followed by e.g. 4 register stages for the result. First it will split the multiplication into multiple multiplications and additions, because 64 bit down not for into one DSP slice. Now it uses register push down (or back) operations to move registers "over " the multiplication operation. Finally, it groups them and assigns it to a DSP48 slice operation. | |
| Aug 5, 2017 at 16:48 | comment | added | Johannes Schaub - litb | Perhaps it could even have worked better with the RTL approach, because I read that the DSP48 supports cascading on the same DSP column without CLB cells in between. I suppose the synthesizer could have inferred 2 such cascaded DSPs. With the IP cores, I don't have that configuration. | |
| Aug 5, 2017 at 15:52 | comment | added | Johannes Schaub - litb | It appears to me there is absolutely no reason to use a core. I mean, if we can describe the multiplier and accumulator entitely in a way with RTL that makes the synthesizer infer the corresponding DSP primitives, why not use the RTL code directly. | |
| Aug 5, 2017 at 15:49 | comment | added | Johannes Schaub - litb |
@Paebbels thanks. Just for understanding: The initial multiplication must appear in a process(clk) aswell, right? Otherwise, the synthesis tool will not know that the multiplication is intended to be complete within a cycle period. Or does it suffice if "a" and "b" are driven by clk-sensitive drivers?
|
|
| Aug 3, 2017 at 22:55 | comment | added | Paebbels |
Xilinx XST User Guide start at page 98. See the "Advanced HDL Report" at page 106: 4 pipeline level(s) found in a register connected to the multiplier macro output and Pushing register(s) into the multiplier macro.. The newer UG901 doesn't contain logfile examples :(.
|
|
| Aug 3, 2017 at 21:15 | comment | added | Johannes Schaub - litb | @Paebbels is this described anywhere in more detail? Perhaps in a xilinx manual? I would like to read more about it. | |
| Aug 3, 2017 at 20:33 | comment | added | Paebbels | @JohannesSchaub-litb We are talking here about synthesis and optimization not delta-cycle accurate simulation. You specify a delay of 4 cycles from a,b to y, so synthesis has 4 cycles time to do what ever is needed to calculate a*b. However, all multiplication have to be split to the underlying DSP size e.g. 18x18. | |
| Aug 3, 2017 at 16:04 | comment | added | scary_jeff | @JohannesSchaub-litb the result will be defined in any case. If no automatic pipelining is performed, the design will not pass timing at the implementation stage. | |
| Aug 3, 2017 at 15:43 | comment | added | Johannes Schaub - litb | @scary_jeff But if the optimization is not done, the behavior of this pattern is not defined if you use it as a 1-cycle-throughput-pipeline. So after each synthesis one has to check again, or am I missing something? | |
| Aug 3, 2017 at 15:31 | comment | added | scary_jeff | @JohannesSchaub-litb it can work because the code says that there are 4 registers after the multiplication that simply shift the same data through. The tool can take advantage of these 'wasted' clock cycles, and split the multiplication into several stages, with each stage then having a lower minimum clock period. | |
| Aug 3, 2017 at 15:13 | comment | added | Johannes Schaub - litb | But.. I think I see what you did there. The multiplication is not sensitive to the clock, so it's different. | |
| Aug 3, 2017 at 15:10 | comment | added | Johannes Schaub - litb |
I'm confused as to why why the synthesizer can split a*b up into multiple clock ticks if it sees this pattern. The answer at stackoverflow.com/a/13956532/34509 states that "However, the synthesis and back-end tools (place and route) guarantee to either obey this model faithfully, or fail and report why they failed. For example, they will add up all the real delays and verify that the sum is less than your specified clock period. (Unless you have set the clock speed too high!).". Now your answer seem to indicate that instead of failing, it can apply pipelining?.
|
|
| Aug 3, 2017 at 14:32 | history | answered | Paebbels | CC BY-SA 3.0 |