Hi Sebastian, Apologies, you are indeed correct. The Zynq PS does generate the AXI_CLK (FCLK_CLK0) and it is set to 100MHz for the Red Pitaya. The ADC and DSP MMCMs have nothing to do with it.
Yes, the dsp_mmcm is in order not to be forced to work at the crystal frequency. If I remember correctly, we prevent modification so that the user doesn't need to know the actual ADC sample clock frequency. He just needs to specify "adc_clk" and the toolfllow will ensure everything runs at 125MHz. You could argue that it is important to know this information as well. If you would like to alter the platform yellow block clock frequency then you will need to use "sys_clk". This is a collaboration and if you want to make improvements towards the toolfow then you are most welcome to. The Red Pitaya was created as a CASPER teaching platform and if you feel there are improvements that can be made then why not make them and send a pull request for reviewing - CASPER encourages this and is always looking for new developers :). I am happy to support you in investigating your timing issues, so feel free to send me your design if you are allowed to share it. Kind regards, Adam Isaacson South African Radio Astronomy Observatory (SARAO) Hardware Manager Cell: (+27) 825639602 Tel: (+27) 215067300 email: aisaac...@ska.ac.za On Fri, Jul 3, 2020 at 5:50 PM Sebastian Antonio Jorquera Tapia < sebastian.jorqu...@ug.uchile.cl> wrote: > 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 (<aisaac...@ska.ac.za>) > 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: aisaac...@ska.ac.za >> >> >> >> On Fri, Jul 3, 2020 at 5:00 PM Sebastian Antonio Jorquera Tapia < >> sebastian.jorqu...@ug.uchile.cl> 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 (<jackhick...@gmail.com>) >>> 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, <aisaac...@ska.ac.za> 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: aisaac...@ska.ac.za >>>>> >>>>> >>>>> >>>>> On Fri, Jul 3, 2020 at 5:46 AM Sebastian Antonio Jorquera Tapia < >>>>> sebastian.jorqu...@ug.uchile.cl> 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 "casper@lists.berkeley.edu" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to casper+unsubscr...@lists.berkeley.edu. >>>>>> 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 "casper@lists.berkeley.edu" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to casper+unsubscr...@lists.berkeley.edu. >>>>> 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 "casper@lists.berkeley.edu" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to casper+unsubscr...@lists.berkeley.edu. >>>> 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 "casper@lists.berkeley.edu" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to casper+unsubscr...@lists.berkeley.edu. >>> 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 >> "casper@lists.berkeley.edu" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to casper+unsubscr...@lists.berkeley.edu. >> 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 " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > 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 > <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAASoV%3DNJoCLzSX7xPN_MxfdgM3zkHwzUum27VLhA-PdFYCArMw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CADTJ%3DnE5KpakspEnmUSe%3D1k%3DR66-QOjtSuNmsRRA7gbung1eKQ%40mail.gmail.com.
