Re: [casper] CLKIN1_PERIOD error when building for ROACH II
Checked around for git pull request but did not find one so did the change myself. Untested as do not have access to an install with the latest Xilinx version, could someone check it please at https://github.com/ska-sa/mlib_devel/commit/b40ad47a84507770f8a480ecdedda2bde5ecc133 Regards Andrew On Sat, 2012-07-21 at 08:10 +0200, Wesley New wrote: Great work guys. We are planning porting the libraries to 14.1 as soon as possible and I'm sure we will encounter more similar issues. Wes On 7/21/12, Rurik A. Primiani rprim...@cfa.harvard.edu wrote: Digging into this further it appears that a combination of integer division and the 13.x tools is to blame. The value 10 for CLKIN1_PERIOD works on both 11 and 13 but 1000/100 only works on 11. Weird. In any event 1000.0/CLK_FREQ worked for me too! Rurik On 7/20/2012 6:15 PM, Rurik A. Primiani wrote: Glenn, this changed was introduced rather recently: https://github.com/ska-sa/mlib_devel/commit/828079 Which might explain why the casper-astro fork does not exhibit the odd behavior. For the record, I'm seeing this too on my Windows 7 machine with the 13.x tools. Rurik On 7/20/2012 5:55 PM, G Jones wrote: Good catch. Changing the CLKIN1_PERIOD line to (1000.0/CLK_FREQ) to force it to be floating point seems to have fixed the problem. I'll see if I can generate a pull request for this modification. It's not clear to me why this was not a problem for the casper-astro/mlib_devel branch, but oh well. I suppose the reason people haven't run into the issue using the version 11 era tools is that the type checking became more stringent? Thanks, Glenn On Fri, Jul 20, 2012 at 2:42 PM, Ryan Monroe ryan.m.mon...@gmail.com wrote: Comment: 1000/CLK_FREQ will evaluate to 10 when CLK_FREQ=100. That crazy binary value you see is 0b1010 = 0d10. Looks like a variable casting issue On 07/20/2012 02:39 PM, G Jones wrote: Some more information: The only place the problem value is shown is in XPS_ROACH2_base/synthesis/infrastructure_inst_wrapper_xst.srp Elaborating module MMCM_BASE(BANDWIDTH=low,CLKFBOUT_MULT_F=6,CLKFBOUT_PHASE=0.0,CLKIN1_PERIOD=32'sb01010,CLKOUT0_DIVIDE_F=1,CLKOUT0_DUTY_CYCLE=0.5,CLKOUT1_DUTY_CYCLE=0.5,CLKOUT2_DUTY_CYCLE=0.5,CLKOUT3_DUTY_CYCLE=0.5,CLKOUT4_DUTY_CYCLE=0.5,CLKOUT5_DUTY_CYCLE=0.5,CLKOUT6_DUTY_CYCLE=0.5,CLKOUT0_PHASE=0.0,CLKOUT1_PHASE=0.0,CLKOUT2_PHASE=0.0,CLKOUT3_PHASE=0,CLKOUT4_PHASE=0,CLKOUT5_PHASE=0,CLKOUT6_PHASE=0.0,CLKOUT1_DIVIDE=6,CLKOUT2_DIVIDE=6,CLKOUT3_DIVIDE=32'sb011,CLKOUT4_DIVIDE=32'sb011,CLKOUT5_DIVIDE=32'sb011,CLKOUT4_CASCADE=FALSE,CLOCK_HOLD=FALSE,DIVCLK_DIVIDE=1,REF_JITTER1=0.0,STARTUP_WAIT=FALSE). In the verilog file, CLKIN1_PERIOD is set to (1000/CLK_FREQ) and the CLK_FREQ parameter defaults to 100. The value of CLK_FREQ passed from the .mhs is also 100 In the data/roach_infrastructure_v2_1_0.mpd, CLK_FREQ is set to 100. The data type is indicated as integer which is a bit suspicous, but it's the same in the working casper-astro/mlib_devel Glenn On Fri, Jul 20, 2012 at 2:17 PM, G Jones glenn.calt...@gmail.com wrote: Yep, I agree again, but the MHS file that sets the parameters (as far as I remember) looks OK too. I'll try grepping through the build directory to see if I can figure out where the crazy value is coming from. On Fri, Jul 20, 2012 at 2:15 PM, Ryan Monroe ryan.m.mon...@gmail.com wrote: Ahem, by 'log file', I meant 'HDL file'. On 07/20/2012 02:13 PM, G Jones wrote: I agree, but the mystery is how that crazy binary value is getting in there... I should also note that I was able to build ROACH II designs with the casper-astro/mlib_devel, but the resulting boffiles caused a kernel panic sort of error when reading the registers. Using a known good boffile from Rurik showed that the ROACH II itself was not the cause of the problem. Glenn On Fri, Jul 20, 2012 at 2:09 PM, Ryan Monroe ryan.m.mon...@gmail.com wrote: Hey Glenn, I would guess that the HDL is wrong. Reference the ISE 13.4 / Virtex 6 HDL libraries guide, page 249: http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_4/virtex6_hdl.pdf Looks like it wants a float, representing the input period here. Definitely not a binary value... But I haven't looked at the HDL myself, I'm just going off of the report in this email. Take this all with a pinch of salt. Anyways, how's life? I haven't seen you in awhile--don't I still owe you a beer? :-) --Ryan On 07/20/2012 01:51 PM, G Jones wrote: Hello, I am running into a problem (error message below) when trying to build simple designs for the ROACH II. I am using the ska-sa/mlib_devel freshly cloned from github. I have double checked that my paths only point to this version. I am using ISE 13.4 and MATLAB 2011a. The design is very simple, just a blinking
Re: [casper] CLKIN1_PERIOD error when building for ROACH II
Great work guys. We are planning porting the libraries to 14.1 as soon as possible and I'm sure we will encounter more similar issues. Wes On 7/21/12, Rurik A. Primiani rprim...@cfa.harvard.edu wrote: Digging into this further it appears that a combination of integer division and the 13.x tools is to blame. The value 10 for CLKIN1_PERIOD works on both 11 and 13 but 1000/100 only works on 11. Weird. In any event 1000.0/CLK_FREQ worked for me too! Rurik On 7/20/2012 6:15 PM, Rurik A. Primiani wrote: Glenn, this changed was introduced rather recently: https://github.com/ska-sa/mlib_devel/commit/828079 Which might explain why the casper-astro fork does not exhibit the odd behavior. For the record, I'm seeing this too on my Windows 7 machine with the 13.x tools. Rurik On 7/20/2012 5:55 PM, G Jones wrote: Good catch. Changing the CLKIN1_PERIOD line to (1000.0/CLK_FREQ) to force it to be floating point seems to have fixed the problem. I'll see if I can generate a pull request for this modification. It's not clear to me why this was not a problem for the casper-astro/mlib_devel branch, but oh well. I suppose the reason people haven't run into the issue using the version 11 era tools is that the type checking became more stringent? Thanks, Glenn On Fri, Jul 20, 2012 at 2:42 PM, Ryan Monroe ryan.m.mon...@gmail.com wrote: Comment: 1000/CLK_FREQ will evaluate to 10 when CLK_FREQ=100. That crazy binary value you see is 0b1010 = 0d10. Looks like a variable casting issue On 07/20/2012 02:39 PM, G Jones wrote: Some more information: The only place the problem value is shown is in XPS_ROACH2_base/synthesis/infrastructure_inst_wrapper_xst.srp Elaborating module MMCM_BASE(BANDWIDTH=low,CLKFBOUT_MULT_F=6,CLKFBOUT_PHASE=0.0,CLKIN1_PERIOD=32'sb01010,CLKOUT0_DIVIDE_F=1,CLKOUT0_DUTY_CYCLE=0.5,CLKOUT1_DUTY_CYCLE=0.5,CLKOUT2_DUTY_CYCLE=0.5,CLKOUT3_DUTY_CYCLE=0.5,CLKOUT4_DUTY_CYCLE=0.5,CLKOUT5_DUTY_CYCLE=0.5,CLKOUT6_DUTY_CYCLE=0.5,CLKOUT0_PHASE=0.0,CLKOUT1_PHASE=0.0,CLKOUT2_PHASE=0.0,CLKOUT3_PHASE=0,CLKOUT4_PHASE=0,CLKOUT5_PHASE=0,CLKOUT6_PHASE=0.0,CLKOUT1_DIVIDE=6,CLKOUT2_DIVIDE=6,CLKOUT3_DIVIDE=32'sb011,CLKOUT4_DIVIDE=32'sb011,CLKOUT5_DIVIDE=32'sb011,CLKOUT4_CASCADE=FALSE,CLOCK_HOLD=FALSE,DIVCLK_DIVIDE=1,REF_JITTER1=0.0,STARTUP_WAIT=FALSE). In the verilog file, CLKIN1_PERIOD is set to (1000/CLK_FREQ) and the CLK_FREQ parameter defaults to 100. The value of CLK_FREQ passed from the .mhs is also 100 In the data/roach_infrastructure_v2_1_0.mpd, CLK_FREQ is set to 100. The data type is indicated as integer which is a bit suspicous, but it's the same in the working casper-astro/mlib_devel Glenn On Fri, Jul 20, 2012 at 2:17 PM, G Jones glenn.calt...@gmail.com wrote: Yep, I agree again, but the MHS file that sets the parameters (as far as I remember) looks OK too. I'll try grepping through the build directory to see if I can figure out where the crazy value is coming from. On Fri, Jul 20, 2012 at 2:15 PM, Ryan Monroe ryan.m.mon...@gmail.com wrote: Ahem, by 'log file', I meant 'HDL file'. On 07/20/2012 02:13 PM, G Jones wrote: I agree, but the mystery is how that crazy binary value is getting in there... I should also note that I was able to build ROACH II designs with the casper-astro/mlib_devel, but the resulting boffiles caused a kernel panic sort of error when reading the registers. Using a known good boffile from Rurik showed that the ROACH II itself was not the cause of the problem. Glenn On Fri, Jul 20, 2012 at 2:09 PM, Ryan Monroe ryan.m.mon...@gmail.com wrote: Hey Glenn, I would guess that the HDL is wrong. Reference the ISE 13.4 / Virtex 6 HDL libraries guide, page 249: http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_4/virtex6_hdl.pdf Looks like it wants a float, representing the input period here. Definitely not a binary value... But I haven't looked at the HDL myself, I'm just going off of the report in this email. Take this all with a pinch of salt. Anyways, how's life? I haven't seen you in awhile--don't I still owe you a beer? :-) --Ryan On 07/20/2012 01:51 PM, G Jones wrote: Hello, I am running into a problem (error message below) when trying to build simple designs for the ROACH II. I am using the ska-sa/mlib_devel freshly cloned from github. I have double checked that my paths only point to this version. I am using ISE 13.4 and MATLAB 2011a. The design is very simple, just a blinking LED and a software register. I initially tried clocking off of sys_clk at 100 MHz, but found the same problem when I added an ADC to the design and selected adc0_clk at 200 MHz. The problem occurs during ngdbuild of system.ngd Mark Wagner says he has also seen this problem. I checked the roach_infrastructure.v code in the pcore and it looks reasonable to me. Does anyone have any suggestions? Thanks, Glenn Annotating constraints to design from ucf file system.ucf
[casper] CLKIN1_PERIOD error when building for ROACH II
Hello, I am running into a problem (error message below) when trying to build simple designs for the ROACH II. I am using the ska-sa/mlib_devel freshly cloned from github. I have double checked that my paths only point to this version. I am using ISE 13.4 and MATLAB 2011a. The design is very simple, just a blinking LED and a software register. I initially tried clocking off of sys_clk at 100 MHz, but found the same problem when I added an ADC to the design and selected adc0_clk at 200 MHz. The problem occurs during ngdbuild of system.ngd Mark Wagner says he has also seen this problem. I checked the roach_infrastructure.v code in the pcore and it looks reasonable to me. Does anyone have any suggestions? Thanks, Glenn Annotating constraints to design from ucf file system.ucf ... Resolving constraint associations... Checking Constraint Associations... INFO:ConstraintSystem:178 - TNM 'sys_clk_n', used in period specification 'TS_sys_clk_n', was traced into MMCM_ADV instance infrastructure_inst/MMCM_BASE_clk_200_inst. The following new TNM groups and period specifications were generated at the MMCM_ADV output(s): CLKOUT1: TIMESPEC TS_infrastructure_inst_infrastructure_inst_sys_clk2x_mmcm = PERIOD infrastructure_inst_infrastructure_inst_sys_clk2x_mmcm TS_sys_clk_n HIGH 50% INFO:ConstraintSystem:178 - TNM 'sys_clk_n', used in period specification 'TS_sys_clk_n', was traced into MMCM_ADV instance infrastructure_inst/MMCM_BASE_inst. The following new TNM groups and period specifications were generated at the MMCM_ADV output(s): CLKOUT1: TIMESPEC TS_infrastructure_inst_infrastructure_inst_sys_clk_mmcm = PERIOD infrastructure_inst_infrastructure_inst_sys_clk_mmcm TS_sys_clk_n HIGH 50% INFO:ConstraintSystem - The Period constraint PERIOD = 5 ns ; [system.ucf(393)], is specified using the Net Period method which is not recommended. Please use the Timespec PERIOD method. INFO:ConstraintSystem - The Period constraint PERIOD = 5 ns ; [system.ucf(394)], is specified using the Net Period method which is not recommended. Please use the Timespec PERIOD method. Done... ERROR:LIT:374 - Attribute CLKIN1_PERIOD on MMCM_ADV instance infrastructure_inst/infrastructure_inst/MMCM_BASE_inst has invalid value 64'SB1010. The CLKIN1_PERIOD attribute should have a real number, followed by optional time or frequency units; nS are assumed if no units are given. WARNING:NgdBuild:1440 - User specified non-default attribute value (64'SB1010) was detected for the CLKIN1_PERIOD attribute on MMCM infrastructure_inst/MMCM_BASE_inst. This does not match the PERIOD constraint value (100 MHz.). The uncertainty calculation will use the PERIOD constraint value. This could result in incorrect uncertainty calculated for MMCM output clocks. Checking expanded design ...
Re: [casper] CLKIN1_PERIOD error when building for ROACH II
I agree, but the mystery is how that crazy binary value is getting in there... I should also note that I was able to build ROACH II designs with the casper-astro/mlib_devel, but the resulting boffiles caused a kernel panic sort of error when reading the registers. Using a known good boffile from Rurik showed that the ROACH II itself was not the cause of the problem. Glenn On Fri, Jul 20, 2012 at 2:09 PM, Ryan Monroe ryan.m.mon...@gmail.com wrote: Hey Glenn, I would guess that the HDL is wrong. Reference the ISE 13.4 / Virtex 6 HDL libraries guide, page 249: http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_4/virtex6_hdl.pdf Looks like it wants a float, representing the input period here. Definitely not a binary value... But I haven't looked at the HDL myself, I'm just going off of the report in this email. Take this all with a pinch of salt. Anyways, how's life? I haven't seen you in awhile--don't I still owe you a beer? :-) --Ryan On 07/20/2012 01:51 PM, G Jones wrote: Hello, I am running into a problem (error message below) when trying to build simple designs for the ROACH II. I am using the ska-sa/mlib_devel freshly cloned from github. I have double checked that my paths only point to this version. I am using ISE 13.4 and MATLAB 2011a. The design is very simple, just a blinking LED and a software register. I initially tried clocking off of sys_clk at 100 MHz, but found the same problem when I added an ADC to the design and selected adc0_clk at 200 MHz. The problem occurs during ngdbuild of system.ngd Mark Wagner says he has also seen this problem. I checked the roach_infrastructure.v code in the pcore and it looks reasonable to me. Does anyone have any suggestions? Thanks, Glenn Annotating constraints to design from ucf file system.ucf ... Resolving constraint associations... Checking Constraint Associations... INFO:ConstraintSystem:178 - TNM 'sys_clk_n', used in period specification 'TS_sys_clk_n', was traced into MMCM_ADV instance infrastructure_inst/MMCM_BASE_clk_200_inst. The following new TNM groups and period specifications were generated at the MMCM_ADV output(s): CLKOUT1: TIMESPEC TS_infrastructure_inst_infrastructure_inst_sys_clk2x_mmcm = PERIOD infrastructure_inst_infrastructure_inst_sys_clk2x_mmcm TS_sys_clk_n HIGH 50% INFO:ConstraintSystem:178 - TNM 'sys_clk_n', used in period specification 'TS_sys_clk_n', was traced into MMCM_ADV instance infrastructure_inst/MMCM_BASE_inst. The following new TNM groups and period specifications were generated at the MMCM_ADV output(s): CLKOUT1: TIMESPEC TS_infrastructure_inst_infrastructure_inst_sys_clk_mmcm = PERIOD infrastructure_inst_infrastructure_inst_sys_clk_mmcm TS_sys_clk_n HIGH 50% INFO:ConstraintSystem - The Period constraint PERIOD = 5 ns ; [system.ucf(393)], is specified using the Net Period method which is not recommended. Please use the Timespec PERIOD method. INFO:ConstraintSystem - The Period constraint PERIOD = 5 ns ; [system.ucf(394)], is specified using the Net Period method which is not recommended. Please use the Timespec PERIOD method. Done... ERROR:LIT:374 - Attribute CLKIN1_PERIOD on MMCM_ADV instance infrastructure_inst/infrastructure_inst/MMCM_BASE_inst has invalid value 64'SB1010. The CLKIN1_PERIOD attribute should have a real number, followed by optional time or frequency units; nS are assumed if no units are given. WARNING:NgdBuild:1440 - User specified non-default attribute value (64'SB1010) was detected for the CLKIN1_PERIOD attribute on MMCM infrastructure_inst/MMCM_BASE_inst. This does not match the PERIOD constraint value (100 MHz.). The uncertainty calculation will use the PERIOD constraint value. This could result in incorrect uncertainty calculated for MMCM output clocks. Checking expanded design ...
Re: [casper] CLKIN1_PERIOD error when building for ROACH II
Yep, I agree again, but the MHS file that sets the parameters (as far as I remember) looks OK too. I'll try grepping through the build directory to see if I can figure out where the crazy value is coming from. On Fri, Jul 20, 2012 at 2:15 PM, Ryan Monroe ryan.m.mon...@gmail.com wrote: Ahem, by 'log file', I meant 'HDL file'. On 07/20/2012 02:13 PM, G Jones wrote: I agree, but the mystery is how that crazy binary value is getting in there... I should also note that I was able to build ROACH II designs with the casper-astro/mlib_devel, but the resulting boffiles caused a kernel panic sort of error when reading the registers. Using a known good boffile from Rurik showed that the ROACH II itself was not the cause of the problem. Glenn On Fri, Jul 20, 2012 at 2:09 PM, Ryan Monroe ryan.m.mon...@gmail.com wrote: Hey Glenn, I would guess that the HDL is wrong. Reference the ISE 13.4 / Virtex 6 HDL libraries guide, page 249: http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_4/virtex6_hdl.pdf Looks like it wants a float, representing the input period here. Definitely not a binary value... But I haven't looked at the HDL myself, I'm just going off of the report in this email. Take this all with a pinch of salt. Anyways, how's life? I haven't seen you in awhile--don't I still owe you a beer? :-) --Ryan On 07/20/2012 01:51 PM, G Jones wrote: Hello, I am running into a problem (error message below) when trying to build simple designs for the ROACH II. I am using the ska-sa/mlib_devel freshly cloned from github. I have double checked that my paths only point to this version. I am using ISE 13.4 and MATLAB 2011a. The design is very simple, just a blinking LED and a software register. I initially tried clocking off of sys_clk at 100 MHz, but found the same problem when I added an ADC to the design and selected adc0_clk at 200 MHz. The problem occurs during ngdbuild of system.ngd Mark Wagner says he has also seen this problem. I checked the roach_infrastructure.v code in the pcore and it looks reasonable to me. Does anyone have any suggestions? Thanks, Glenn Annotating constraints to design from ucf file system.ucf ... Resolving constraint associations... Checking Constraint Associations... INFO:ConstraintSystem:178 - TNM 'sys_clk_n', used in period specification 'TS_sys_clk_n', was traced into MMCM_ADV instance infrastructure_inst/MMCM_BASE_clk_200_inst. The following new TNM groups and period specifications were generated at the MMCM_ADV output(s): CLKOUT1: TIMESPEC TS_infrastructure_inst_infrastructure_inst_sys_clk2x_mmcm = PERIOD infrastructure_inst_infrastructure_inst_sys_clk2x_mmcm TS_sys_clk_n HIGH 50% INFO:ConstraintSystem:178 - TNM 'sys_clk_n', used in period specification 'TS_sys_clk_n', was traced into MMCM_ADV instance infrastructure_inst/MMCM_BASE_inst. The following new TNM groups and period specifications were generated at the MMCM_ADV output(s): CLKOUT1: TIMESPEC TS_infrastructure_inst_infrastructure_inst_sys_clk_mmcm = PERIOD infrastructure_inst_infrastructure_inst_sys_clk_mmcm TS_sys_clk_n HIGH 50% INFO:ConstraintSystem - The Period constraint PERIOD = 5 ns ; [system.ucf(393)], is specified using the Net Period method which is not recommended. Please use the Timespec PERIOD method. INFO:ConstraintSystem - The Period constraint PERIOD = 5 ns ; [system.ucf(394)], is specified using the Net Period method which is not recommended. Please use the Timespec PERIOD method. Done... ERROR:LIT:374 - Attribute CLKIN1_PERIOD on MMCM_ADV instance infrastructure_inst/infrastructure_inst/MMCM_BASE_inst has invalid value 64'SB1010. The CLKIN1_PERIOD attribute should have a real number, followed by optional time or frequency units; nS are assumed if no units are given. WARNING:NgdBuild:1440 - User specified non-default attribute value (64'SB1010) was detected for the CLKIN1_PERIOD attribute on MMCM infrastructure_inst/MMCM_BASE_inst. This does not match the PERIOD constraint value (100 MHz.). The uncertainty calculation will use the PERIOD constraint value. This could result in incorrect uncertainty calculated for MMCM output clocks. Checking expanded design ...
Re: [casper] CLKIN1_PERIOD error when building for ROACH II
Some more information: The only place the problem value is shown is in XPS_ROACH2_base/synthesis/infrastructure_inst_wrapper_xst.srp Elaborating module MMCM_BASE(BANDWIDTH=low,CLKFBOUT_MULT_F=6,CLKFBOUT_PHASE=0.0,CLKIN1_PERIOD=32'sb01010,CLKOUT0_DIVIDE_F=1,CLKOUT0_DUTY_CYCLE=0.5,CLKOUT1_DUTY_CYCLE=0.5,CLKOUT2_DUTY_CYCLE=0.5,CLKOUT3_DUTY_CYCLE=0.5,CLKOUT4_DUTY_CYCLE=0.5,CLKOUT5_DUTY_CYCLE=0.5,CLKOUT6_DUTY_CYCLE=0.5,CLKOUT0_PHASE=0.0,CLKOUT1_PHASE=0.0,CLKOUT2_PHASE=0.0,CLKOUT3_PHASE=0,CLKOUT4_PHASE=0,CLKOUT5_PHASE=0,CLKOUT6_PHASE=0.0,CLKOUT1_DIVIDE=6,CLKOUT2_DIVIDE=6,CLKOUT3_DIVIDE=32'sb011,CLKOUT4_DIVIDE=32'sb011,CLKOUT5_DIVIDE=32'sb011,CLKOUT4_CASCADE=FALSE,CLOCK_HOLD=FALSE,DIVCLK_DIVIDE=1,REF_JITTER1=0.0,STARTUP_WAIT=FALSE). In the verilog file, CLKIN1_PERIOD is set to (1000/CLK_FREQ) and the CLK_FREQ parameter defaults to 100. The value of CLK_FREQ passed from the .mhs is also 100 In the data/roach_infrastructure_v2_1_0.mpd, CLK_FREQ is set to 100. The data type is indicated as integer which is a bit suspicous, but it's the same in the working casper-astro/mlib_devel Glenn On Fri, Jul 20, 2012 at 2:17 PM, G Jones glenn.calt...@gmail.com wrote: Yep, I agree again, but the MHS file that sets the parameters (as far as I remember) looks OK too. I'll try grepping through the build directory to see if I can figure out where the crazy value is coming from. On Fri, Jul 20, 2012 at 2:15 PM, Ryan Monroe ryan.m.mon...@gmail.com wrote: Ahem, by 'log file', I meant 'HDL file'. On 07/20/2012 02:13 PM, G Jones wrote: I agree, but the mystery is how that crazy binary value is getting in there... I should also note that I was able to build ROACH II designs with the casper-astro/mlib_devel, but the resulting boffiles caused a kernel panic sort of error when reading the registers. Using a known good boffile from Rurik showed that the ROACH II itself was not the cause of the problem. Glenn On Fri, Jul 20, 2012 at 2:09 PM, Ryan Monroe ryan.m.mon...@gmail.com wrote: Hey Glenn, I would guess that the HDL is wrong. Reference the ISE 13.4 / Virtex 6 HDL libraries guide, page 249: http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_4/virtex6_hdl.pdf Looks like it wants a float, representing the input period here. Definitely not a binary value... But I haven't looked at the HDL myself, I'm just going off of the report in this email. Take this all with a pinch of salt. Anyways, how's life? I haven't seen you in awhile--don't I still owe you a beer? :-) --Ryan On 07/20/2012 01:51 PM, G Jones wrote: Hello, I am running into a problem (error message below) when trying to build simple designs for the ROACH II. I am using the ska-sa/mlib_devel freshly cloned from github. I have double checked that my paths only point to this version. I am using ISE 13.4 and MATLAB 2011a. The design is very simple, just a blinking LED and a software register. I initially tried clocking off of sys_clk at 100 MHz, but found the same problem when I added an ADC to the design and selected adc0_clk at 200 MHz. The problem occurs during ngdbuild of system.ngd Mark Wagner says he has also seen this problem. I checked the roach_infrastructure.v code in the pcore and it looks reasonable to me. Does anyone have any suggestions? Thanks, Glenn Annotating constraints to design from ucf file system.ucf ... Resolving constraint associations... Checking Constraint Associations... INFO:ConstraintSystem:178 - TNM 'sys_clk_n', used in period specification 'TS_sys_clk_n', was traced into MMCM_ADV instance infrastructure_inst/MMCM_BASE_clk_200_inst. The following new TNM groups and period specifications were generated at the MMCM_ADV output(s): CLKOUT1: TIMESPEC TS_infrastructure_inst_infrastructure_inst_sys_clk2x_mmcm = PERIOD infrastructure_inst_infrastructure_inst_sys_clk2x_mmcm TS_sys_clk_n HIGH 50% INFO:ConstraintSystem:178 - TNM 'sys_clk_n', used in period specification 'TS_sys_clk_n', was traced into MMCM_ADV instance infrastructure_inst/MMCM_BASE_inst. The following new TNM groups and period specifications were generated at the MMCM_ADV output(s): CLKOUT1: TIMESPEC TS_infrastructure_inst_infrastructure_inst_sys_clk_mmcm = PERIOD infrastructure_inst_infrastructure_inst_sys_clk_mmcm TS_sys_clk_n HIGH 50% INFO:ConstraintSystem - The Period constraint PERIOD = 5 ns ; [system.ucf(393)], is specified using the Net Period method which is not recommended. Please use the Timespec PERIOD method. INFO:ConstraintSystem - The Period constraint PERIOD = 5 ns ; [system.ucf(394)], is specified using the Net Period method which is not recommended. Please use the Timespec PERIOD method. Done... ERROR:LIT:374 - Attribute CLKIN1_PERIOD on MMCM_ADV instance infrastructure_inst/infrastructure_inst/MMCM_BASE_inst has invalid value
Re: [casper] CLKIN1_PERIOD error when building for ROACH II
Glenn, this changed was introduced rather recently: https://github.com/ska-sa/mlib_devel/commit/828079 Which might explain why the casper-astro fork does not exhibit the odd behavior. For the record, I'm seeing this too on my Windows 7 machine with the 13.x tools. Rurik On 7/20/2012 5:55 PM, G Jones wrote: Good catch. Changing the CLKIN1_PERIOD line to (1000.0/CLK_FREQ) to force it to be floating point seems to have fixed the problem. I'll see if I can generate a pull request for this modification. It's not clear to me why this was not a problem for the casper-astro/mlib_devel branch, but oh well. I suppose the reason people haven't run into the issue using the version 11 era tools is that the type checking became more stringent? Thanks, Glenn On Fri, Jul 20, 2012 at 2:42 PM, Ryan Monroe ryan.m.mon...@gmail.com wrote: Comment: 1000/CLK_FREQ will evaluate to 10 when CLK_FREQ=100. That crazy binary value you see is 0b1010 = 0d10. Looks like a variable casting issue On 07/20/2012 02:39 PM, G Jones wrote: Some more information: The only place the problem value is shown is in XPS_ROACH2_base/synthesis/infrastructure_inst_wrapper_xst.srp Elaborating module MMCM_BASE(BANDWIDTH=low,CLKFBOUT_MULT_F=6,CLKFBOUT_PHASE=0.0,CLKIN1_PERIOD=32'sb01010,CLKOUT0_DIVIDE_F=1,CLKOUT0_DUTY_CYCLE=0.5,CLKOUT1_DUTY_CYCLE=0.5,CLKOUT2_DUTY_CYCLE=0.5,CLKOUT3_DUTY_CYCLE=0.5,CLKOUT4_DUTY_CYCLE=0.5,CLKOUT5_DUTY_CYCLE=0.5,CLKOUT6_DUTY_CYCLE=0.5,CLKOUT0_PHASE=0.0,CLKOUT1_PHASE=0.0,CLKOUT2_PHASE=0.0,CLKOUT3_PHASE=0,CLKOUT4_PHASE=0,CLKOUT5_PHASE=0,CLKOUT6_PHASE=0.0,CLKOUT1_DIVIDE=6,CLKOUT2_DIVIDE=6,CLKOUT3_DIVIDE=32'sb011,CLKOUT4_DIVIDE=32'sb011,CLKOUT5_DIVIDE=32'sb011,CLKOUT4_CASCADE=FALSE,CLOCK_HOLD=FALSE,DIVCLK_DIVIDE=1,REF_JITTER1=0.0,STARTUP_WAIT=FALSE). In the verilog file, CLKIN1_PERIOD is set to (1000/CLK_FREQ) and the CLK_FREQ parameter defaults to 100. The value of CLK_FREQ passed from the .mhs is also 100 In the data/roach_infrastructure_v2_1_0.mpd, CLK_FREQ is set to 100. The data type is indicated as integer which is a bit suspicous, but it's the same in the working casper-astro/mlib_devel Glenn On Fri, Jul 20, 2012 at 2:17 PM, G Jones glenn.calt...@gmail.com wrote: Yep, I agree again, but the MHS file that sets the parameters (as far as I remember) looks OK too. I'll try grepping through the build directory to see if I can figure out where the crazy value is coming from. On Fri, Jul 20, 2012 at 2:15 PM, Ryan Monroe ryan.m.mon...@gmail.com wrote: Ahem, by 'log file', I meant 'HDL file'. On 07/20/2012 02:13 PM, G Jones wrote: I agree, but the mystery is how that crazy binary value is getting in there... I should also note that I was able to build ROACH II designs with the casper-astro/mlib_devel, but the resulting boffiles caused a kernel panic sort of error when reading the registers. Using a known good boffile from Rurik showed that the ROACH II itself was not the cause of the problem. Glenn On Fri, Jul 20, 2012 at 2:09 PM, Ryan Monroe ryan.m.mon...@gmail.com wrote: Hey Glenn, I would guess that the HDL is wrong. Reference the ISE 13.4 / Virtex 6 HDL libraries guide, page 249: http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_4/virtex6_hdl.pdf Looks like it wants a float, representing the input period here. Definitely not a binary value... But I haven't looked at the HDL myself, I'm just going off of the report in this email. Take this all with a pinch of salt. Anyways, how's life? I haven't seen you in awhile--don't I still owe you a beer? :-) --Ryan On 07/20/2012 01:51 PM, G Jones wrote: Hello, I am running into a problem (error message below) when trying to build simple designs for the ROACH II. I am using the ska-sa/mlib_devel freshly cloned from github. I have double checked that my paths only point to this version. I am using ISE 13.4 and MATLAB 2011a. The design is very simple, just a blinking LED and a software register. I initially tried clocking off of sys_clk at 100 MHz, but found the same problem when I added an ADC to the design and selected adc0_clk at 200 MHz. The problem occurs during ngdbuild of system.ngd Mark Wagner says he has also seen this problem. I checked the roach_infrastructure.v code in the pcore and it looks reasonable to me. Does anyone have any suggestions? Thanks, Glenn Annotating constraints to design from ucf file system.ucf ... Resolving constraint associations... Checking Constraint Associations... INFO:ConstraintSystem:178 - TNM 'sys_clk_n', used in period specification 'TS_sys_clk_n', was traced into MMCM_ADV instance infrastructure_inst/MMCM_BASE_clk_200_inst. The following new TNM groups and period specifications were generated at the MMCM_ADV output(s): CLKOUT1: TIMESPEC TS_infrastructure_inst_infrastructure_inst_sys_clk2x_mmcm = PERIOD infrastructure_inst_infrastructure_inst_sys_clk2x_mmcm TS_sys_clk_n HIGH 50% INFO:ConstraintSystem:178 - TNM 'sys_clk_n', used in period
