Andrew, this commit works for me on 13.3. Thanks!

On 7/23/2012 6:59 AM, Andrew Martens wrote:
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 <[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 ...





Reply via email to