Sorry If I push too hard on the mmcm thing jaja. I just wanted to know if there was an underlying reason for using the mmcm (maybe a clock stability across the board or something like that), but I agree it is the right thing to do If you want to be open to work in every possible configuration. I think you use the same red_pitaya.v in every configuration, it's that correct?
Thanks, again for the response! El vie., 3 jul. 2020 a las 13:18, Adam Isaacson (<aisaac...@ska.ac.za>) escribió: > 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 > <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CADTJ%3DnE5KpakspEnmUSe%3D1k%3DR66-QOjtSuNmsRRA7gbung1eKQ%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%3DOaShe1kbAr-L_A4k0oeU8Z1UtKiHBA_bHCA8H9vwTEcw%40mail.gmail.com.
