EDK : FSL macros defined by Xilinx are wrong

[Rob Judd]

Jay wrote:

Rob,

In article <3F2E0028.A07801D3@ob-wan.com>, judd@ob-wan.com says...
Add to that the need for an expensive IAR compiler for the AVR core and
it's pretty average. It's difficult to do a meaningful feature
comparison though, owing to the different architectures. I do know that
the EP1C6 and APA150 are very similar in price (when the config chip is
added into the equation). May check out the Atmel too, just to be sure
I'm not missing out on any bargains.

You have alternatives besides IAR.

The CodeVision compiler from http://www.hpinfotech.ro/ looks good, I
have associates who used it and didn't have anything unpleasant to say.
There is a version of the compiler that also supports the FPSLIC too. It
supports a number of optimizations and also includes pragmas so you can
optimize for speed or size.

There is also ImageCraft (www.imagecraft.com). I test drove the 30-day
eval and found it had functionality, but wasn't laid out (in my opinion)
as well as the above. Code produced looked OK I found CodeVision was
better in some instances, but I didn't spend too much time trying to
optimize for my test runs.

There is also AVR-GCC if you feel like dealing with GNU stuff...I have
*major* problems with this toolchain since(among other issues) it does
not support "dead code" removal which should rip out any pieces of
compiled code that aren't referenced in your program. I have a small set
of C routines that I use in many of my projects but often not all
functions in the "common set" C file are used. GCC won't remove those
(even if you mess around with the linker scripts).

Also, there aren't any pragmas for optimization (just your standard -o1
-o2 -o3 switches) which means you have to segment code into seperate
files to get it optimized the way you want (very sub-optimal).

GCC just wasn't meant for 8-bit micros, and I found plenty of fault with
the code it generates too.

Anyway, you have some alternatives.

GCC? Bwahahaha. If only you knew my opinion of that crud.

I hadn't heard of Codevision, thanks for the tip.

Rob

 

[Steven K. Knapp]

[snip]

I read that PCI has really tight timings and is evidently really hard
to design for; it's only 33 MHz. Sure, it's a bus with multiple cards,
but AGP is a single card in a single slot, and only runs at 66 MHz. I
feared that if "real" EEs (instead of us biologists that just play
them when we need equiment that doesn't exist) don't want to push a
card interconnect above 66 Mhz, there must be a good reason.

[snip]

The hard part in "33 MHz" PCI is a 7 ns path on the PCI IRDY# and TRDY#
control signals to output enables on the FPGA. So, instead of a "33 MHz"
problem, you really have a 143 MHz" design challenge. The issue is related
to propagation time within the FPGA and not related to signal integrity
issues.

BTW, Spartan-IIE fully supports 66 MHz and 64-bit PCI and is available in a
proven LogiCORE solution.
http://www.xilinx.com/partinfo/pci/xcvpci64_32ds.pdf

--------------------------------
Steven K. Knapp
Spartan-3/II/IIE FPGAs
http://www.xilinx.com/spartan3
---------------------------------
Spartan-3: Make it Your ASIC

 

[Peter Alfke]

A clock that drives 40 flip-flops should be distributed on a global
clock. Then you do not have to worry about the myriad aspects of clock
skew. Instead you have a delay, but that is a single parameter, and is
much easier to deal with.

Peter Alfke, Xilinx
=========
jean-francois hasson wrote:

Hi,

I have a serial bus coming in a Virtex II -5 in LVDS format at 80 MHZ
with 3 data in parallel. The data change on the falling edge of the
clock. The problem is that the clock is present only when data is
transmitted (no DCM possible) and the pads used for the clock does not
allow the use of a bufgp without an important routing delay. I am
using the MAXSKEW constraint on the received clock and the best I can
get is 450 ps (I can not use the local clock resources described in
xapp609). This clock goes to approximately 40 FFs. I have, on this
clock domain, among other things, a shift register so I have a FF to
FF path. When having the min skew of 450 ps parts of the shift
register are implemented in the same CLB so the output of a FF goes
through the local routing matrix of the CLB and back to the input of a
FF in the same CLB : I believe it must be the shortest and quickest
path to go from one FF to another. My problem is that I wonder if the
skew I have will always be smaller than the clock_to_out + prop_delay
: I believe the max values are ok but what about typical ?

Thank you.

J.F. Hasson

 

[Mike Treseler]

Don S wrote:

I'm a sysadmin looking at a problem that a designer is having with
slow turn around times in Altera Quartus. The turn around time on a
compile is about 1 hr on a AMD 1700+ with 1 gig of memory. Quartus
version is 2.1 running on Win2K SP2.

Gosh. I wish I had a sysadmin. Any openings?

One hour is not bad for synthesis and place+route
on a medium sized FPGA.

There is apparently a way to lock down the layout of certain blocks
and/or do an incremental compile so that everything would not have to
be re-synthesised but the designer says that it doesn't seem to work
correctly.

I haven't even tried the "logic-lock" place+route locker because
things change too much and I don't do that many place+routes.

You should turn on "smart-compile" to save the cache.
Hard drives are cheap.

Any pointers would be greatly appreciated.

A simulation recompile and rerun only takes a few minutes.
You might suggest the designer spend more time on the
testbench and less in synthesis/place+route.

-- Mike Treseler

 

[Bob]

Is the DCM locked?

Bob


"Charles Stuart" <cstuart@cfl.rr.com> wrote in message
newsXhZa.26947$K4.1430387@twister.tampabay.rr.com...

I've looked through the Xilinx site and found some reference to the
problem
I'm having and tried the suggestions, but to no avail. I am using the DFS
function on a DCM, but I get no output from the CLKFX output....... yes I
have also defined the CLKIN_PERIOD. Has anyone seen this problem ?

Thanks in advance
Charlie

 

[Martin Euredjian]

You have to monitor the "LOCKED" output and reset the DCM if lock is not
achieved. My reset sequencing module takes this into account and holds the
rest of the FPGA in reset until all DCM's are up and running. It resets the
DCM's, waits for a period of time and then samples for a lock condition. If
no lock was achieved the sequence repeats (reset, look for lock).


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"





"Charles Stuart" <cstuart@cfl.rr.com> wrote in message
newsXhZa.26947$K4.1430387@twister.tampabay.rr.com...

I've looked through the Xilinx site and found some reference to the
problem
I'm having and tried the suggestions, but to no avail. I am using the DFS
function on a DCM, but I get no output from the CLKFX output....... yes I
have also defined the CLKIN_PERIOD. Has anyone seen this problem ?

Thanks in advance
Charlie

 

[Paul Baxter]

Off the subject but I have been really glad to see Altera's presence in this
forum for the last few months.

For years it seemed that only Xilinx cared about their user community on
here so its nice to see the support. Kudos to Paul, Subroto et al. (and
continuing thanks to Austin, Peter et al from Xilinx)

Mike hit the nail on the head, most work should be done pre-synthesis. Of
course the Altera product (or Xilinx) doesn't really lend itself to doing
this by itself. I'd recommend Active HDL (www.aldec.com) though others swear
by ModelSim

You 'really' need a decent simulator to speed the overall design process.

Paul

"Paul Leventis" <paul.leventis@utoronto.ca> wrote in message
news:f0YYa.127991$hOa.39807@news02.bloor.is.net.cable.rogers.com...

Hi Don,

I have a few questions:

(a) Why is the user iterating through full P&R so much? Is it for timing
closure? Or are they doing post-P&R simulation when they could be using
pre-P&R simulation for the purposes of debugging their HDL?
(b) What device is being used, and how full is it? 1 hr is not
unreasonable
for a medium-sized design, and your observation that Quartus is CPU bound
confirms that the user is not running out of memory for some reason.

There is an option in Quartus known as "Fast Fit" which will make the
fitter
run faster at the expense of a small amount of performance. I'd also
suggest upgrading to the latest version of Quartus II (version 3.0) as I
*think* there has been a bit of a speed up for newer families over the
past
few releases, though I don't have the data handy to confirm this. If the
user is iterating to achieve timing closure, a newer version of Quartus
could do the trick as we are constantly improve the quality of push-button
place and route.

I'm not terribly familiar with the CPU time implications of using logic
lock
or incremental compile and will ask a colleague about this on Monday.

Regards,

Paul Leventis
Altera Corp.



"Don S" <dshesnicky@yahoo.com> wrote in message
news:b9ff9982.0308081117.164f3b3a@posting.google.com...
I'm a sysadmin looking at a problem that a designer is having with
slow turn around times in Altera Quartus. The turn around time on a
compile is about 1 hr on a AMD 1700+ with 1 gig of memory. Quartus
version is 2.1 running on Win2K SP2.

The bulk of the time is spent in Logic Synthesis and the Fitter.
If we just bring up the task manager it shows that we have not tapped
the memory but the cpu is pegged.

There is apparently a way to lock down the layout of certain blocks
and/or do an incremental compile so that everything would not have to
be re-synthesised but the designer says that it doesn't seem to work
correctly.

Any pointers would be greatly appreciated.

Don

 

[Peter Rauschert]

Of course you have to compile it. If you look into the Mentor Support
Net you will find a note how to do this. For Compilation look to the
Xilinx Website :
http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=2561


Peter

 

Aare Tali <atali@cygrp.com> wrote:

: I would expect it to fit. Anything you can do in 2 logic blocks of
: 36V18 can be done in two 54V18.

: I would suggest to place the design into 9536 without XL, save the
: fitter report, run the fitter on 9536XL and compare fitter reports.

The big difference is that the XC9536 report has the 'wire-AND'
option enabled and the XC9536XL has it disabled. My design makes
heavy use of the 'wire-AND' facility, and it has been suggested
that this is not available on the XC9536XL. Is that correct ?

I have raised a Webcase on this issue, but no results so far.

Richard.
http://www.rtrussell.co.uk/

 

[jean-francois hasson]

Hi,

Unfortunatly, I can not drive a global buffer with this clock because the
maximum delay I get when I go by the global buffer is 8 ns which is
incompatible with the fact that data is synchronous to the falling edge of
the 80 MHz clock. I believe I will try something else with a much faster
clock but just if this information is available what is the maximum skew
provided by the clock tree in a Virtex II ? The reason for my question is
that I read in a previous post that is was below 100 ps but when I run the
timing analyzer it seems it is more like 300 ps. Did I miss something ? If
not is my 450 ps skew small enough to consider no extra effort necessary ?

Thanks,

J.F. Hasson

"Peter Alfke" <peter@xilinx.com> a écrit dans le message de news:
3F33D7C6.4086EA39@xilinx.com...

A clock that drives 40 flip-flops should be distributed on a global
clock. Then you do not have to worry about the myriad aspects of clock
skew. Instead you have a delay, but that is a single parameter, and is
much easier to deal with.

Peter Alfke, Xilinx
=========
jean-francois hasson wrote:

Hi,

I have a serial bus coming in a Virtex II -5 in LVDS format at 80 MHZ
with 3 data in parallel. The data change on the falling edge of the
clock. The problem is that the clock is present only when data is
transmitted (no DCM possible) and the pads used for the clock does not
allow the use of a bufgp without an important routing delay. I am
using the MAXSKEW constraint on the received clock and the best I can
get is 450 ps (I can not use the local clock resources described in
xapp609). This clock goes to approximately 40 FFs. I have, on this
clock domain, among other things, a shift register so I have a FF to
FF path. When having the min skew of 450 ps parts of the shift
register are implemented in the same CLB so the output of a FF goes
through the local routing matrix of the CLB and back to the input of a
FF in the same CLB : I believe it must be the shortest and quickest
path to go from one FF to another. My problem is that I wonder if the
skew I have will always be smaller than the clock_to_out + prop_delay
: I believe the max values are ok but what about typical ?

Thank you.

J.F. Hasson

 

[Don S]

Paul,
The device is an EP20K, 1500EBC652-1X, the user said that he
is using <20% in logic and <60% in memory. We've discussed your
info and have decided that the first step is, as you recommend,
upgrading to 3.0.

The reason for the P&R is that we do not have any real lab
equipment and the user is bringing signals out to the 3 on-board
LEDs. I take it that this requires a new P&R everytime.

Don

I have a few questions:

(a) Why is the user iterating through full P&R so much? Is it for timing
closure? Or are they doing post-P&R simulation when they could be using
pre-P&R simulation for the purposes of debugging their HDL?
(b) What device is being used, and how full is it? 1 hr is not unreasonable
for a medium-sized design, and your observation that Quartus is CPU bound
confirms that the user is not running out of memory for some reason.

There is an option in Quartus known as "Fast Fit" which will make the fitter
run faster at the expense of a small amount of performance. I'd also
suggest upgrading to the latest version of Quartus II (version 3.0) as I
*think* there has been a bit of a speed up for newer families over the past
few releases, though I don't have the data handy to confirm this. If the
user is iterating to achieve timing closure, a newer version of Quartus
could do the trick as we are constantly improve the quality of push-button
place and route.

I'm not terribly familiar with the CPU time implications of using logic lock
or incremental compile and will ask a colleague about this on Monday.

Regards,

Paul Leventis
Altera Corp.



"Don S" <dshesnicky@yahoo.com> wrote in message
news:b9ff9982.0308081117.164f3b3a@posting.google.com...
I'm a sysadmin looking at a problem that a designer is having with
slow turn around times in Altera Quartus. The turn around time on a
compile is about 1 hr on a AMD 1700+ with 1 gig of memory. Quartus
version is 2.1 running on Win2K SP2.

The bulk of the time is spent in Logic Synthesis and the Fitter.
If we just bring up the task manager it shows that we have not tapped
the memory but the cpu is pegged.

There is apparently a way to lock down the layout of certain blocks
and/or do an incremental compile so that everything would not have to
be re-synthesised but the designer says that it doesn't seem to work
correctly.

Any pointers would be greatly appreciated.

Don

 

[Aare Tali]

news@rtrussell.co.uk wrote in message news:<bh8el4$24l$1@nntp0.reith.bbc.co.uk>...

Aare Tali <atali@cygrp.com> wrote:

: I would expect it to fit. Anything you can do in 2 logic blocks of
: 36V18 can be done in two 54V18.

: I would suggest to place the design into 9536 without XL, save the
: fitter report, run the fitter on 9536XL and compare fitter reports.

The big difference is that the XC9536 report has the 'wire-AND'
option enabled and the XC9536XL has it disabled. My design makes
heavy use of the 'wire-AND' facility, and it has been suggested
that this is not available on the XC9536XL. Is that correct ?

XC9500 uses FASTCONNECT switch matrix that is documented to have
wired-AND capability. XC9500XL uses FASTCONNECT II switch matrix that
doesn't have it documented, so I would think it's not there. The only
option is to use pin-compatible XC9572XL part, I guess...

 

[Marc Guardiani]

I've seen weirdness when using gates with a large number of inputs. Try
breaking the 8 input gates into cascaded 4 input and 5 input gates. The
synthesizer should turn this into a single 8 input gate.


Jon Elson wrote:

Hello,

I have Xilinx ise 4.1.03i, and ran into a wierd problem I haven't seen
before.

I have a multi-page schematic that I'm trying to compile to an XC95xx
CPLD. It has
2 8-input or gates on one sheet, and another one on a different sheet. I
get the following
message when doing the synthesize process :

ERROR:HDLParsers:3340 - Project file master.prj names two source files,
D:/nchem/mothbrd/Motherboard/mb2.vhf and D:/nchem/mo
thbrd/Motherboard/mb1.vhf, that both define the same primary unit,
work/OR8_MXILINX
ERROR:HDLParsers:3340 - Project file master.prj names two source files,
D:/nchem/mothbrd/Motherboard/mb2.vhf and D:/nchem/mo
thbrd/Motherboard/mb1.vhf, that both define the same primary unit,
work/OR8_MXILINX/SCHEMATIC

Looking into the .vhf files, I see the OR8_MXILINX is defined as an
entity, and later as a component, in
both of these files. This doesn't seem to be out of the ordinary, it
looks just like the other standard library
definitions.

Does anyone have any suggestions?

Thanks,

Jon

--


Marc Guardiani

To reply directly to me, use the address given below. The domain name is
phonetic.
fpgaee81-at-eff-why-eye-dot-net

 

[Martin Schoeberl]

If a 50K gate FPGA (1,536 logic cells in the XC3S for example) could be
put in a 48 pin TQFP, and include Flash on die, then that would be a
great product! I know that the chip designers would have a hard time
figuring out how to do this, but it would be a CPLD killer! I have

What I'm missing (besides a Flash) is memory! All this SOPC talk forgets
that for a decent CPU you need external memory. I don't need additional
single cycle, synchchronous, fast memory. Keep the block rams and add a
'slow' 128 kB block (perhaps only 8 bit port is ok) with let's say 30 ns
access time. This would also help for large FIFOs.
A summery for a 'dream' SOPC FPGA:

3000 - 5000 LCs
5 kByte block ram
128 kB 'slow' async ram
512 kB flash (for configuration AND user data)
48 - 100 pin TQFP (with pad distance > 0.5mm => cheaper production)
price below EP1C6

That would be REALLY cool

my 2c
Martin

----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/

 

[Uwe Bonnes]

Atif <atif@kics.edu.pk> wrote:
: Can anyone please tell me what is the price of Xilinx platform Flash
: PROM XCf01s? Is this available?
: From where can I see its price and purchase it?

Enter "XCF" as search string at
"http://www.avnetmarshall.com/dynamic/search" or www.nuhorizons.com.

I guess the XCF parts are only avaiable to selcted customers as engineering
samples.

Bye
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

 

[Brannon King]

The & is used to allow identifiers to begin with an _ or a number. Make sure
your files are purely structural. EDIF2NGD only supports EDIF 2.0.0. What's
worse: the error messages can be off by thousands of lines either direction.
What's worse than that: the memory efficiency of the tool is terrible. As
far as a "conversion tool" is concerned, get the parser from www.edif.org
for the 2.0.0 files. Run your code in and out of there. The pretty printed
version from that should work better. I have plenty of EDIF files that will
work with the EDIF2NGD tool Xilinx ships. Here's an example:

(edif Test
(edifVersion 2 0 0)
(edifLevel 0)(keywordMap (keywordLevel 0))(status(written
(timeStamp 2003 5 20 15 25 35)(author "SBS")(program "SBS" (version
"Whoopee"))))
(library Test (edifLevel 0) (technology (numberDefinition ))
(cell GND (cellType GENERIC)
(view net (viewType NETLIST)
(interface
(port G (direction OUTPUT))
(property LEVEL (string "XILINX"))(property LIBVER (string "2.0.0"))
)
)
)

(cell VCC (cellType GENERIC)
(view net (viewType NETLIST)
(interface
(port P (direction OUTPUT))
(property LEVEL (string "XILINX"))(property LIBVER (string "2.0.0"))
)
)
)

(cell OR2 (cellType GENERIC)
(view net (viewType NETLIST)
(interface
(port I0 (direction INPUT))
(port I1 (direction INPUT))
(port O (direction OUTPUT))
(property LEVEL (string "XILINX"))(property LIBVER (string "2.0.0"))
)
)
)
(cell someOr (cellType GENERIC)
(view net (viewType NETLIST)
(interface
(port In1 (direction INPUT))
(port In2 (direction INPUT))
(port Out1 (direction OUTPUT))
)
(contents
(instance I234OR2 (viewRef net (cellRef OR2)))
(net N1727(joined(portref O(instanceRef I234OR2) ) (portRef Out1)))
(net N1728(joined(portref In1 ) (portRef I0(instanceRef I234OR2))))
(net N1729(joined(portref In2 ) (portRef I1(instanceRef I234OR2))))
)
)
)
) (design Test (cellRef someOr (libraryRef Test))(property PART(string
"xc2v6000ff1152-4") (owner "Xilinx"))))


"Jon Elson" <jmelson@artsci.wustl.edu> wrote in message
news:3F4524C3.2020408@artsci.wustl.edu...

Hello,

Has anyone had any success with creating schematic pages with other
tools and then getting ise 4.1.03i to accept it (preferably as an edif
file)?

I'm using Protel 99SE, which has a schematic entry package that I much
prefer to the GHASTLY xst. There are some differences in the way
they like to see schematics, though. Protel insists on ipads and opads,
while ise insists on just having ports on the top level sheet.

There are some other problems, like Protel puts a '&' before every symbol
and pin name. Well, I just strip them in the editor. Oddly, Protel
makes the
ibuf and obuf parts disappear, so I'm converting the unwanted ipad and
opads
to ibuf and obuf. It is close, but not quite there, yet.

Does anyone know of a freeware solution, have written a converter or
have a procedure of what to do to make the conversion?

Or, as another possibility, does anyone have a complete EDIF file that
is completely acceptable to ise? (There is exactly one EDIF file in the
entire examples dir, and it is a very complicated design, and not very
good to use as a reference on how to construct a valid edif.

Thanks much for any help you can offer!

Jon

 

[Nicholas C. Weaver]

In article <3F4A3E1E.E3A9E335@xilinx.com>,
Peter Alfke <peter@xilinx.com> wrote:

Looking at our recent Virtex-IIPro metastability tests, I figured out
the metastability capture window:
Using a 300 MHz clock, and a roughly 50 MHz data rate, we get one 1.5 ns
delay ( that is clock-to-Q plus short routing plus set-up time) per
second. And similarily one 2.0 ns delay per million seconds.

Does this mean that, thanks to routing delay, you could just do a 3
flip-flops in parallel for capturing, voting circuit on the other
side, and not have to worry about it?

For the 1.5 ns delay, the capture window is thus 3.3 ns / 50 million =
0.07 femtosecond
For the 2.0 ns delay, the capture window is a million times smaller,
and for 2.5 ns it's another million times smaller ...

Light travels 0.3 m in a ns, 0.3 mm in one ps, and 0.3 micron in one
femtosecond.

Peter Alfke, Xilinx Applications

--
Nicholas C. Weaver nweaver@cs.berkeley.edu

 

[Jon Elson]

Brannon King wrote:

The & is used to allow identifiers to begin with an _ or a number.

My problem is more with Protel than Xilinx ISE. Protel's pld software

is so broken
that I don't even know where to start. For instance, I put in a 16-bit
shift register,
and all that comes out in the EDIF file are the Q outputs of the FFs.
No clock,
data in or anything else show up. Fortunately, their basic schematic
code works better,
and the right stuff comes out, but there's extra junk, and some really
inconsistent
stuff.

Make sure
your files are purely structural. EDIF2NGD only supports EDIF 2.0.0. What's
worse: the error messages can be off by thousands of lines either direction.

Yes, but the net names and such pretty quickly bring you to the trouble

spot.

What's worse than that: the memory efficiency of the tool is terrible. As
far as a "conversion tool" is concerned, get the parser from www.edif.org
for the 2.0.0 files. Run your code in and out of there. The pretty printed
version from that should work better.

I had planned on checking this as a base when I got to the point of

making a converter
program, but didn't think of using it as is to clean up the EDIF. Thanks!

I have plenty of EDIF files that will
work with the EDIF2NGD tool Xilinx ships. Here's an example:



Thanks for the example! I think I have the EDIF format that Xilinx

needs pretty well
figured out, now.

Jon

 

[Bob Perlman]

On Mon, 25 Aug 2003 18:25:30 +0000 (UTC),
nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) wrote:

In article <3F4A4A96.18037049@xilinx.com>,
Peter Alfke <peter@xilinx.com> wrote:
Sounds reasonable to me...
Peter Alfke

Just realized. How does a LUT input react to a metastable input (to
do the voting circuit)?

Voting circuits don't work as a metastability cure. Imagine a
2-out-of-3 circuit that's looking at three flip-flops. If one FF is
HIGH, another is LOW, and the third is metastable, what's the output
of the voting circuit?

Back in the early 80's, UCSD professor Leonard Marino wrote a paper in
which he very thoroughly analyzed a number of alleged metastability
cures, one of which was the voting circuit. I can't find my copy of
the paper, but it must have appeared in IEEE Transactions on
Computers.

Bob Perlman
Cambrian Design Works

 

[Anil Khanna]

Hi Martin,

TIG should work, if not, you could always try a MCP (multicycle path
constraint) if you know how many times your data is sampled.

Anil

"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:3f49e539@dnews.tpgi.com.au...

Martin Euredjian wrote:
The constraint guide indicates that the TIG constraint can be used in
HDL
(Verilog in my current design). However, an attempt to use it produces
the
following error:

ERROR:Xst:1582 - The constraint 'tig=' is not supported neither in BEGIN
MODEL/END section in the XCF file, nor in HDL code.

I have not been able to find further information on this error message
or
issue in the Xilinx site. Does anyone know if TIG is truly supported in
HDL? I'd hate to place it in the UCF file, to me it feels much more
approprite to have this constraint move with the HDL source.

The form I'm using is:

// synthesis attribute TIG of <net_name> is "";

As a point of interest, the nets in question are the output of the
registers
of a microprocessor interface. The values are only sampled a few times
per
second by the receiving module. There is not need to have any of these
nets
meet nanosecond level timing constraints as other parts of the design
must.
Is there a better approach than "TIG"?

Hi Martin,

I think this old thread answers your question:

http://groups.google.com/groups?threadm=3dbd0daa%241_1%40lon-news.intensive.

net

Regards,
Allan.