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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>>>> 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'SB0000000000000000000000000000000000000000000000000000000000001010". >>>>>>> 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'SB0000000000000000000000000000000000000000000000000000000000001010) >>>>>>> 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 ... >>>>>>> >
