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 ... >>>>> >>
