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 <[email protected]> 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 >>> <[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 ... >>>>>>>>>> >> > > >
