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.
