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

"Alessandro" <apoppi@email.it> writes:

> 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

It turned out that my problem was due to my own stupidity in trying to
delay a clock signal; I do a bit of work before I want the CPU 'turned
on', so I was delaying the clock signal to the CPU until a state
machine reached a certain state.

Bad idea.  (Hey, I'm a software person learning hardware....)

I should've just used the system clock and added an 'enable' to the
CPU.  In fact, that's what I did and that timeing error went away.

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

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

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

<snip>

thutt

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

> I'm quite curious about your timing constraint information. =A0I 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.

does THIS help ?

http://toolbox.xilinx.com/docsan/xilinx10/books/docs/cgd/cgd.pdf
http://toolbox.xilinx.com/docsan/xilinx10/books/docs/qst/qst.pdf

/Jochen

On 09 Sep 2008 20:56:04 -0700, thutt <thutt151@comcast.net> wrote:

>"Alessandro" <apoppi@email.it> writes:
>
>> 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.
>> 
>> 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
>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).

You can add most constraints in either the VHDL code or the user
constraints. 

In practice things like pin allocations and timing constraints are
usually best added in the user constraint file (.ucf) which is easily
handled in a text editor. It's as important to your project as the VHDL
files, whether you are using the GUI or the command line.

(This keeps the VHDL cleaner and more portable for one thing. There are
a few valid uses for constraints in the VHDL code, but IMO no essential
ones. If you're curious, google for "Death of the RLOC")

It's not a bad idea to try the graphical constraints tool - once - for
adding a few constraints then use these as prototypes for the rest.
Or reading the .ucf for sample projects. Also build the project once
using the GUI, look for the "command_log" file, and extract command
lines from it.

- Brian

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