Thanks for the detailed response! So the dsp_mmcm its in order to not be forced to work at the crystal frequency. But that's odd because when you select to work at the adc_clk in the xsg yellow box you can't modify the frequency, so the whole system (except the dac) is running at 125. I think the zynq ps should generate the axi clock.
El vie., 3 jul. 2020 a las 11:22, Adam Isaacson (<[email protected]>) escribió: > Hi Sebastian, > > Yes, you are correct. The toolflow uses Vivado as its backend and so will > do the same. Jack makes a good point and I think maybe one of the future > requirements for the toolflow will be to clearly indicate if the design has > failed timing or not. I still think it is useful to generate the bit file > even if there are timing failures - sometimes it is useful to still test > the design even with timing failures. The final released version should > never have timing failures though. > > Yes, we have two MMCMs for the Red Pitaya/SKARAB. The reason is that we > are unable to generate all the required frequencies with one MMCM and we > need the MMCM because we are not just using the 125MHz clock for ADC > sampling. We also have a DAC that uses 250MHz and I think the processor and > AXI interface for reading registers runs on 100MHz or maybe lower for Red > Pitaya. I can't quite remember now. It could also be useful to run the DSP > (sysgen) at a higher clock frequency. You will notice that the ADC yellow > block and DAC yellow blocks all have data valid signals and the relevant > FIFO buffering for this. I think the Red Pitaya spectrometer tutorial runs > the sysgen clock at 125MHz. If you do the second tutorial: ADC and DAC you > will see the effects of a toggling data valid signal. Also, even though it > would be great to have one clock frequency for timing purposes, it wouldn't > make sense to run non-critical interfaces such as the AXI comms registers > at a higher clock frequency than it needs to be. It makes sense to use a > lower clock frequency for this. We were running the SKARAB comms interface > at 156.25MHz and in the end dropped this to 40MHz, so that we could meet > timing. > > I hope this helps. > > Kind regards, > > Adam Isaacson > South African Radio Astronomy Observatory (SARAO) > Hardware Manager > Cell: (+27) 825639602 > Tel: (+27) 215067300 > email: [email protected] > > > > On Fri, Jul 3, 2020 at 5:00 PM Sebastian Antonio Jorquera Tapia < > [email protected]> wrote: > >> Yes, Its my own design. I ask because when you run the synthesis and >> implementation in Vivado it lets you continue and generate the bitstream >> even if you have timing violations, so i think the casper tool could do the >> same. >> >> I have another question.. looking at the report my timing errors are >> related to the adc_mmcm. Why does the system use an mmcm if the 125Mhz are >> given by an external crystal and there is no modification to the frequency? >> Its not enough to use a IBUFGDS? >> Also I see a second mmcm named dsp_clk_mmcm feeded by the same adc clock, >> I didnt look very carefully but guided by its name I assume it gives the >> clock to the sysgen model. Why use a second clock, if its running at the >> same frequency as the first mcmm? >> >> >> El vie., 3 jul. 2020 a las 5:38, Jack Hickish (<[email protected]>) >> escribió: >> >>> This is probably a good conversation to have amongst the developers. ISE >>> used to not deliver bitstreams unless you set an environment flag. I'm not >>> sure it wouldn't make sense for the current toolflow to do the same. >>> >>> Timing failure warnings _are_ printed to the MATLAB prompt, but not in >>> as shouty a way as they probably should be. I've tweaked them to be more >>> obvious and this change will probably/hopefully be merged in the next major >>> mlib_devel release. >>> >>> Cheers >>> Jack >>> >>> On Fri, 3 Jul 2020, 8:51 am Adam Isaacson, <[email protected]> wrote: >>> >>>> Hi Sebastian, >>>> >>>> No, the timing analysis is performed during implementation - routing >>>> phase and post routing optimisation phase. Bit generation occurs after this >>>> - whether the design meets timing or not. >>>> >>>> Are you compiling tutorials or your own custom Red Pitaya design? The >>>> tutorials should meet timing. >>>> >>>> Kind regards, >>>> >>>> Adam Isaacson >>>> South African Radio Astronomy Observatory (SARAO) >>>> Hardware Manager >>>> Cell: (+27) 825639602 >>>> Tel: (+27) 215067300 >>>> email: [email protected] >>>> >>>> >>>> >>>> On Fri, Jul 3, 2020 at 5:46 AM Sebastian Antonio Jorquera Tapia < >>>> [email protected]> wrote: >>>> >>>>> >>>>> Hello Casperites, >>>>> Just a little question regarding the order of compilation.. I just >>>>> compile a red pitaya design using the casper tool chain who generates the >>>>> bitstream and says that the backend is completed! But when I open the >>>>> project with vivado I could see that the implementation had a time >>>>> violation of 2.5ns in the setup time of signals related to the adc clock.. >>>>> >>>>> So my question is, the time analysis is made after the bitstream are >>>>> generated? >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "[email protected]" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/4fb01928-987b-4d87-b62c-3ed40cd579f9n%40lists.berkeley.edu >>>>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/4fb01928-987b-4d87-b62c-3ed40cd579f9n%40lists.berkeley.edu?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "[email protected]" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CADTJ%3DnHjK6ELYzZgKCrou4-xUCEFS9svRkkWqFGUFV7abmYy6Q%40mail.gmail.com >>>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CADTJ%3DnHjK6ELYzZgKCrou4-xUCEFS9svRkkWqFGUFV7abmYy6Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "[email protected]" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKS%3DLaWvz%2BfizRb93UhBP8TJk_UMSqck_dLVY0TrfjtQPAw%40mail.gmail.com >>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKS%3DLaWvz%2BfizRb93UhBP8TJk_UMSqck_dLVY0TrfjtQPAw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "[email protected]" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAASoV%3DNvWgLB5py0fsq1jbFxAaJ%2B3kKNAJfkRXqm5J0sOrdrFw%40mail.gmail.com >> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAASoV%3DNvWgLB5py0fsq1jbFxAaJ%2B3kKNAJfkRXqm5J0sOrdrFw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CADTJ%3DnHLrZQeRqq28ZU39QP%3Dp9OFtUFzFURdndq2369rbt9zdg%40mail.gmail.com > <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CADTJ%3DnHLrZQeRqq28ZU39QP%3Dp9OFtUFzFURdndq2369rbt9zdg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAASoV%3DNJoCLzSX7xPN_MxfdgM3zkHwzUum27VLhA-PdFYCArMw%40mail.gmail.com.
