Thanks, John. I am certainly not advocating using -es1. You have production silicon and the only way for the tools to accurately target the device in all aspects is to setup the tool with the correct information. We need that note and ability to support the correct device, thank you for that. I am only curious and looking for more concrete details, if any. Because, I understood from you that the prebuilt 100G .fpg I sent after correctly targeting the MGT reference inputs worked after you increased the MTU on your data capture. Is that right? Because that .fpg was built where the tool would have been configured to target engineering silicon. Certainly you need move beyond the tutorial capabilities and the right way is to configure the tool with the correct part. So, perhaps your application designs using 100G do not pass timing? Or is there some other concrete Vivado error for what was failing?
Mitch On Mar 14, 2024, at 9:45 AM, John Swoboda <swob...@gmail.com> wrote: Hi Mitch, The -es1 removal in the yaml file was something that was brought up by colleagues of mine who have used zcu216s recently. When I did have issues with the 100 Gbe I looked into the Vivado project and found that the part number did have the -es1 tag so that's why I was suspecting that was the issues. Once I removed the -es1 in the yaml file I've been able to get it to work. I will add my updates to the tutorial files and try to add my lessons learned. John On Tuesday, March 12, 2024 at 12:18:54 PM UTC-4 Mitch Burnett wrote: Hi John, On Mar 12, 2024, at 10:00 AM, John Swoboda <swo...@gmail.com> wrote: Hi Mitch, Thanks for the reply. The 100 Gbe is working fine on my end. I also was able to get the into my design. Great to hear! In terms of using the -es1 in the design files, I would suggest that this be noted in the tutorials that this could be an issue for people if they do not have a -es1 board and they should adjust it in the design file if they are having trouble with 100 Gbe. I know it was necessary to remove the -es1 to get my 100 Gbe on my board to work. I would recommend that you can do the same with the tutorials and to have this note added by raising an issue on the tutorial GitHub tutorial. Additionally, if you already had some suggested edits in a branch a pull request against the turorials would be even better. Is there more information you can provide about how removing -es1 was required for 100G to work? Mitch Thanks, John On Monday, March 11, 2024 at 1:21:39 AM UTC-4 Mitch Burnett wrote: Hi John, Now I think the trick is you have to change the block parameters for the yellow block supplying the PPS to be single ended because I ran that and it got rid of my error since in the zcu208/216 use single LVCMOS18 instead of LVDS_25. Am I on the right track here? Yes, this is correct. The `sync_in` from the CLK104 is a single-ended input and so you will need to hint this to the yellow block with the ‘Use as single-ended’ checkbox. Also I may have found more errors in the .yaml file for the zcu208. Thanks! The best thing to do here would be to either make a Github issue on `casper-astro/mlib_devel/` documenting what you have found. Or, if you already have these changes corrected and in a branch you can create a pull request against the `m2021a-dev` branch on `casper-astro/mlib_devel/` and folks can review what you found there. Can we also take the -es1 off of all of the files so the 100 Gbe works out of the box or add a message to the tutorial? What about having `-es1` prevents 100 GbE working? Are you still having issues with 100 GbE? This shouldn’t have had any impact on what you were seeing previously? Removing -es1 is probably fine. I am not sure how widely used zcu208 is (you may be the first — we are patching the errors in the porting process as you report them. What was there was a carryover from zcu216 and not tested due to lack of hardware). A better approach though may be to allow for an -es1 and non-es1 version when making a selection in the yellow block mask. I know this would help folks like me where I have 12 -es1 zcu216 that will need to still be targeted but also will help the folks building on non-es1 hardware and not need to make adjustments to the underlying platform files. Best, Mitch On Mar 10, 2024, at 3:32 PM, John Swoboda <swo...@gmail.com> wrote: Hi All, I've been trying to get my zcu208 to trigger on a pps. I've looked at a snap tutorial<https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/snap/tut_corr.html> that has sync generator example and I tried to model a basic PPS counter from that which is seen here: <simpleppscounter.png> Building it I get the following error though: Traceback (most recent call last): File "/home/swoboj/CASPER_DEV/mlib_devel/jasper_library/exec_flow.py", line 213, in <module> tf.generate_consts() File "/home/swoboj/CASPER_DEV/mlib_devel/jasper_library/toolflow.py", line 657, in generate_consts constraint.gen_physical_const(self.plat) File "/home/swoboj/CASPER_DEV/mlib_devel/jasper_library/constraints.py", line 120, in gen_physical_const pins = platform.get_pins(self.iogroup, index=self.iogroup_index) File "/home/swoboj/CASPER_DEV/mlib_devel/jasper_library/casper_platform.py", line 155, in get_pins raise KeyError('No pin named %s' % name) KeyError: 'No pin named sync_in_p' Error using jasper (line 23) Backend build failed! Check log files for more information Now I think the trick is you have to change the block parameters for the yellow block supplying the PPS to be single ended because I ran that and it got rid of my error since in the zcu208/216 use single LVCMOS18 instead of LVDS_25. Am I on the right track here? Also I may have found more errors in the .yaml file for the zcu208. Can we also take the -es1 off of all of the files so the 100 Gbe works out of the box or add a message to the tutorial? Thanks, John <blockpps.png> -- You received this message because you are subscribed to the Google Groups "cas...@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+un...@lists.berkeley.edu. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/719ac75b-2634-42e6-8c91-d48516b84a72n%40lists.berkeley.edu<https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/719ac75b-2634-42e6-8c91-d48516b84a72n%40lists.berkeley.edu?utm_medium=email&utm_source=footer>. <simpleppscounter.png><blockpps.png> -- You received this message because you are subscribed to the Google Groups "cas...@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+un...@lists.berkeley.edu. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/257109c4-2522-402c-b07d-de6e3ed3bf59n%40lists.berkeley.edu<https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/257109c4-2522-402c-b07d-de6e3ed3bf59n%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<mailto:casper+unsubscr...@lists.berkeley.edu>. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/bde98395-eadd-42cb-9efd-ebdad234f933n%40lists.berkeley.edu<https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/bde98395-eadd-42cb-9efd-ebdad234f933n%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/612CB57D-D4E6-46E0-BB04-1094994B38EA%40byu.edu.