03-22-2012 05:29 PM - edited 03-22-2012 05:37 PM
device: xc6slx150t, tools: 13.4
I have some algorithm working and doing some job. There are specific amount of cycles of processing, while getting data from FIRST BRAM memory. The data to BRAM memory comes from ADC. BRAM memory is true dual port type.
There is another SECOND BRAM memory which holds fixed values, data is loaded during configuration. My processing blocks from algorithm take data both from the FIRST BRAM memory described above, and from this SECOND BRAM memory which has fixed constant values.
What im trying to do now, is optimize my processing algorithm to reduce number of cycles required for each processing block. However, right now i faced a problem that i cannot get data from SECOND BRAM with the next clock cycle after request, my timing score due to constraint violation is: 596516 ps
After i threw in one DFF, it reduced to 322853 ps, eventually i can eliminate it by putting more DFFs. (as it was before)
But im trying to understand why the tools put the SECOND BRAM so far...
So, i have two options readily available:
1) Threw in more DFFs and live with the fact that i need that much cycles to get data from SECOND BRAM.
2) look at AREA GROUP constraints, and maybe force tools to place SECOND BRAM it close to processing blocks
I dont want to mess with option #2 because it ties me to this specific device, i need as easy portable code as possible. ANd make it almost universal.
option #1 is kind of last choice.
So, what other suggestions would be there?
Another thing is, im using only 18 RAMB16BWERs out of 268 Available, and i dont use RAMB8BWERs.
Looking at PlanAhead i see that RAMB8s located to the left of DSPs. Not that far. Im using 8 of DSP48s.
I kind of trying to understand why dont the tools align both SECOND and FIRST BRAMS close to those DSP48s
(FIRST BRAM has no problems, i get data on next cycle after request, and no timing violations, second is problematic)
03-22-2012 11:15 PM
Hello again, radnorc.
I'm having trouble understanding your description of your datapaths. Would it be possible to post a block diagram which shows the datapaths? I think this will help the discussion.
After i threw in one DFF, it reduced to 322853 ps
Please verify: did you intend to write 322 853 pS, or 322.853 nS ?
-- Bob Elkind
03-23-2012 10:20 AM - edited 03-23-2012 10:23 AM
322853 is just number from final timing score.
so basically from the second BRAM i cant get data on the next clock cycle, the data just cant make the timing to the DSP48 which is located in a smartest block ever designed.
of course i can put more DFFs on the way, to solve it. but... its still kind if interesting why the tool cant figure out best placement. afterall im using not that much resources yet.
i can redesign actually to make my algorithm work in a different way. but..still was wondering.