Hi Sebastian, No, please continue to ask these questions. They are good questions and it forces me to think :). There is always room for improvement, but I can only focus on so much at a time.
Yes, that is correct. We use the same red_pitaya.v and red_pitaya.tcl to generate the Zynq block diagram in all configurations. I am going into weekend mode now, so will be happy to respond to any new questions on Monday :). 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 7:32 PM Sebastian Antonio Jorquera Tapia < sebastian.jorqu...@ug.uchile.cl> wrote: > 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 > <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAASoV%3DOaShe1kbAr-L_A4k0oeU8Z1UtKiHBA_bHCA8H9vwTEcw%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%3DnGg1gQ8wrKWGW%3DpMVB78RdDCxXaKc5iRme%2Bqnq9WAqPTg%40mail.gmail.com.
