Re: Are Xilinx tools that bad, or am I missing something?

Discussion in 'VHDL' started by Sean Durkin, Sep 7, 2008.

  1. Sean Durkin

    Sean Durkin Guest

    thutt wrote:
    > Am I misunderstanding something, or is the Xilinx software really that
    > bad? In other words, should removing a completely unused signal cause
    > my design to be synthesized in a way so that it no longer works?
    >
    > If that's the case, then can you explain to me how that can be?


    What you describe very often happens when there are constraints missing,
    usually timing constraints.

    When certain paths are not constrained, they tools just lay them out so
    it's most convenient for them. In many cases and with slow clocks this
    is not a problem. Modern FPGAs are fast, and if it's a slow clock and a
    small FPGA you can basically go around the entire chip twice and not
    have any timing issues.

    If it's a faster clock, you eventually get to the point where a design
    sometimes works and sometimes not, depending on how the tools lay out
    everything. It might happen that between different synthesis runs some
    paths are layed out differently, in one case just short enough that you
    don't get any timing issues and in another case just too long. Things
    like that happen easily if you change the code. It doesn't have to be a
    major change, but every tiny change is enough to modify the starting
    conditions for all the algorithms the tools implement, and then it might
    happen that i.e. the placer decides it's better to place some register
    in the top left instead of the bottom right, and suddenly everything
    around it changes position as well.

    That's what timing constraints are for: the tools should check every
    path and make sure all paths are short enough so you don't get any
    timing issues.

    So I suggest you check if all the clocks in your design are properly
    constrained. The same problems you describe can occur not only if you
    don't constrain at all but also if you under-constrain, i.e. set the
    clock to 25 MHz when it's actually 40 MHz or something similar.

    Xilinx' Timing Analyzer can also help there, there's an option to
    display all unconstrained paths in your design. Ideally, there shouldn't
    be any. Plus, there shouldn't be any timing violations in the Xilinx
    report files, of course.

    HTH,
    Sean
    Sean Durkin, Sep 7, 2008
    #1
    1. Advertising

  2. Sean Durkin

    Alessandro Guest

    thutt wrote:

    > All the I/O is actually constrained, but I have not done anything with
    > timing yet. I guess I'll try to check out information about timing.
    > Thanks for the info. Hopefully this will pan out.


    I totally agree with what Sean said.

    I recently ran into *exactly* the same type of problem, on a project based
    on the "small" 100K gates 3E fpga.

    Just assigning a signal or not to an output spare pin for debug purposes had
    the power to make the entire design totally inusable. The SPI port
    communicating to an external device used to crash within a few seconds after
    power-on.

    I've been instructed to add a "timing constraint" and now is seems (it
    seems!) that the design is more stable and changing that assignment no
    longer affects reliability. This is what I've added:

    NET clk_pin TNM_NET = clk_ref_grp;
    TIMESPEC TS01 = PERIOD : clk_ref_grp : 20.00 : PRIORITY 1; # 50.00 MHz

    This was for the main 50MHz clock. "clk_pin" is the name of the net where
    the 50MHz osc is attached. This did not bring any improvement. But when I
    added another constraint, to the signal output from DCM (75MHz) then the
    problem disappeared:

    NET clk_pll TNM_NET = clk_ref_grp_pll;
    TIMESPEC TS01 = PERIOD : clk_ref_grp_pll : 12.00 : PRIORITY 1; # 75.00 MHz

    I also added this:
    TIMESPEC TS11=FROM:pADS:TO:FFS : 30 ns;
    TIMESPEC TS12=FROM:FFS:TO:pADS : 30 ns;

    because it was included on a xilinx 3E-board example. I don't know if is
    useful or not.

    Ciao!
    Alessandro


    >
    > thutt
    Alessandro, Sep 9, 2008
    #2
    1. Advertising

  3. thutt wrote:
    > All the I/O is actually constrained, but I have not done anything with
    > timing yet. I guess I'll try to check out information about timing.
    > Thanks for the info. Hopefully this will pan out.


    If you have not created timing constraints and checked that they are met
    with the static timing analysis tools, then the design can be broken
    in all possible ways. Getting the timing correct is usually a big task
    of the design, might be much bigger than coding the design. And the
    timing closure phase usually requires loops back to the RTL and code
    changes to meet the timing.

    Timing is the biggest difference to software in HW, timing phase is the
    phase where SW guys notice that everything that you code can not be
    realized in HW in a sane way.

    --Kim
    Kim Enkovaara, Sep 10, 2008
    #3
  4. Sean Durkin

    Jochen Guest

    Jochen, Sep 10, 2008
    #4
  5. Sean Durkin

    Alessandro Guest

    thutt wrote:

    >> NET clk_pin TNM_NET = clk_ref_grp;
    >> TIMESPEC TS01 = PERIOD : clk_ref_grp : 20.00 : PRIORITY 1; # 50.00
    >> MHz


    > I'm quite curious about your timing constraint information. I spent
    > time on the weekend trying to find out how to do that, but the Xilinx
    > docs, IMHO, are just as bad as their software -- and I couldn't find
    > anything useful.
    >
    > Where did you find this information about 'NET clk_pin'? To what do
    > you add it? In the VHDL? In the user constraints? I try to avoid


    All the statements are in the .ucf file.
    The "clk_pin" is just the name of the signal attached to the 50MHz clock
    oscillator, specified in a pin constraint in usual way:
    NET "clk_pin" LOC = "C9" | IOSTANDARD = LVCMOS33 ;
    The constraint just tells that this is a 50MHz clock. I don't know exactly
    how it works (and I'll certainly read the two links provided by Jochen), I
    just copied the first one from a fpgaarcade source code (asteroids, if I
    remember).

    I made the second (75MHz) by myself, recalculating timings with the ratio of
    50 to 75 (the difference in frequency). clk_pll is the name of an internal
    signal clock, not a physical pin. I'm not really sure that using "TS01"
    twice is a good practice, I have to learn about it.

    > using ISE as much as possible, so please tell me what document you
    > found this information in, and then I think I can extrapolate to how
    > to control the command line programs (which I drive from a Makefile).


    I found it in the source code of an fpgaarcade game. You will find similar
    things in many xilinx projects (for example the default picoblaze project,
    flashed into the board as a factory default and downloadable from the xilinx
    site): this is what's inside it's .ucf file:

    NET "clk" LOC = "C9" | IOSTANDARD = LVTTL;
    # Period constraint for 50MHz operation
    NET "clk" PERIOD = 20.0ns HIGH 50%;

    > 75MHz? On a Spartan 3E board? What pin is that? Do you have the
    > UCF name?


    The spartan fpga has some "DCM" units (digital clock managers) which will
    generate almost any frequency you need, starting from a given clock source
    (50MHz in our case). A dcm will multiply then divide the frequency in a very
    flexible way.

    You can create an instance for a dcm by running the "Core Generator" under
    the ISE/Accessories program group or, inside ISE, by adding a source file to
    the project then selecting "IP Coremanager" instead of, for example, a new
    ..vhd file).

    You then select "fpga features and design" then "clocking" then the fpga
    family then "single DCM_SP, then "customize".

    The clock manager can simply shift the input clock by 90, 180, 270 degrees
    or generate a different frequency. For the latter, you should check the box
    "CLKFX" (it is a pin on the drawn component on the screen). You input the
    osc clock (50MHz) and the desired output frequency, then the gui will
    calculate the parameters and tell if it could be done or not.

    For example, the zx-badaloc project runs at 85MHz generated by a dcm with
    *17 multiply then /10 divide (50*17/10 = 85).

    You can easily obtain a 300MHz clock by multiplying by 6 the 50MHz input
    clock.

    Then, the gui generates a "component" and a wrapper to be placed in the
    project. I remember I've had problems launching from inside ISE so I prefer
    starting the core manager from the start menu, as described above. The
    wrapper for my 85MHz clock was:

    COMPONENT pll
    PORT(
    CLKIN_IN : IN std_logic;
    CLKFX_OUT : OUT std_logic;
    CLKIN_IBUFG_OUT : OUT std_logic;
    CLK0_OUT : OUT std_logic;
    LOCKED_OUT : OUT std_logic
    );
    END COMPONENT;

    then the "connections" to my signals:

    -- PLL
    mainpll: pll PORT MAP(
    CLKIN_IN => clk_pin, -- oscillatore clock 50MHz
    CLKFX_OUT => clk_pll -- clock sintetizzato 85MHz
    );

    Ciao!
    Alessandro
    Alessandro, Sep 10, 2008
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ted
    Replies:
    6
    Views:
    769
  2. Sergey Katsev

    Xilinx "something's wrong" error

    Sergey Katsev, Oct 31, 2006, in forum: VHDL
    Replies:
    19
    Views:
    2,803
  3. Rich Webb
    Replies:
    2
    Views:
    461
    Muzaffer Kal
    Sep 7, 2008
  4. leo89vjl
    Replies:
    2
    Views:
    4,487
  5. rantingrick
    Replies:
    44
    Views:
    1,199
    Peter Pearson
    Jul 13, 2010
Loading...

Share This Page