EDK : FSL macros defined by Xilinx are wrong

[Gabor]

In the Xilinx timing reports, paths that have exceptions to the period
constraint show up as unconstrained. If you have the patience to
follow through the chain of net names you may find that this path
has either been assigned "TIG" (timing ignore) via some group, or
that it doesn't meet the normal definition of a path from clocked
flip-flop output to data input, such as a gated clock or reset signal.

In your case the path does look like the timing constraint would apply
unless there is a TIG or multipath exception for the signal or module.

johnp wrote:

I'm using a Xilinx V2Pro part with the 6.2.03i s/w release and I'm
seeing the
following unconstrained path in the timing report:

================================================================================
Timing constraint: Unconstrained period analysis for net "clk_conv"

Delay: 3.073ns (data path - clock path skew +
uncertainty)
Source: u0clk_trig_if/trig_conv0 (FF)
Destination: u0clk_trig_if/trig_conv1 (FF)
Data Path Delay: 3.073ns (Levels of Logic = 0)
Clock Path Skew: 0.000ns
Source Clock: clk_conv rising at 0.000ns
Destination Clock: clk_conv rising at 2.450ns
Clock Uncertainty: 0.000ns

Data Path: u0clk_trig_if/trig_conv0 to u0clk_trig_if/trig_conv1
Location Delay type Delay(ns) Physical
Resource
Logical
Resource(s)
-------------------------------------------------
-------------------
SLICE_X32Y0.YQ Tcko 0.419
u0clk_trig_if/trig_conv0

u0clk_trig_if/trig_conv0
SLICE_X25Y9.BY net (fanout=2) 2.428
u0clk_trig_if/trig_conv0
SLICE_X25Y9.CLK Tdick 0.226
u0clk_trig_if/trig_conv1

u0clk_trig_if/trig_conv1
-------------------------------------------------
---------------------------
Total 3.073ns (0.645ns logic,
2.428ns route)
(21.0% logic,
79.0% route)



In my .ucf file, I have set the period on clk_conv, so I don't see why
I'm getting this unconstrained path. In fact, in another section of the
timing
report, I see:

================================================================================
Timing constraint: TS_clk_conv = PERIOD TIMEGRP "clk_conv" 2.450 nS
HIGH 50.000000 % ;

4 items analyzed, 0 timing errors detected. (0 setup errors, 0 hold
errors)


Thus, I believe the constraint on clk_conv is entered correctly, but
for some reason
the tools appear to ignore the constraint on some of the registers
driven by the
clock.

My Verilog code has the registers trig_conv1 and trig_conv0 in the same
always
block with the proper clock edge. The code seems straight forward, so
I don't
see how the coding style could cause this.



Any ideas?

Thanks

John Providenza

 

[Symon]

"Philip Freidin" <philip@fliptronics.com> wrote in message
news:ji6mo15amnurn107gkp4s0a4uof39pkrbp@4ax.com...

I think it is best to distribute the signal on your PCB.

...but be aware of the load you're placing on the signal. The FPGA's pins

have considerable capacitance. If you wire the signal to 8 pins, you could
have 100pF loading the end of your line. This gives you a rise time of the
order of 5ns if driven from 50 ohms. The timing might be skewed as the
signal rises through the thresholds of the inputs.
Cheers, Syms.
p.s. I'm wondering if you could use some spare unbonded IOBs for this? Take
the signal in. Distribute it with low skew (easy to say!) to the outputs of
4 or 8 unbonded IOBs. Use the input delay thingies? The same as previously
suggested, but without using up real IOBs?

 

[Symon]

"Philip Freidin" <philip@fliptronics.com> wrote in message
news:ji6mo15amnurn107gkp4s0a4uof39pkrbp@4ax.com...

I think it is best to distribute the signal on your PCB.

...but be aware of the load you're placing on the signal. The FPGA's pins

have considerable capacitance. If you wire the signal to 8 pins, you could
have 100pF loading the end of your line. This gives you a rise time of the
order of 5ns if driven from 50 ohms. The timing might be skewed as the
signal rises through the thresholds of the inputs.
Cheers, Syms.
p.s. I'm wondering if you could use some spare unbonded IOBs for this? Take
the signal in. Distribute it with low skew (easy to say!) to the outputs of
4 or 8 unbonded IOBs. Use the input delay thingies? The same as previously
suggested, but without using up real IOBs?

 

[Andy Peters]

damir wrote:

I need to implement slow FIFO (16-bit wide, max. 10 MHz) using external
single-port SRAM connected to the FPGA (Spartan II/III).

Does anyone have similar FIFO controller (sync/async) implemented using
VHDL?

A FIFO in a single-port RAM? Neat trick, although I suppose the slow
speed makes it do-able.

-a

 

[Peter Alfke]

After some thinking:
1.
You can divide the input load by using "zero-delay buffer chips" with
up to 8 outputs and very little skew betrween them. And you can even
compensate for the (assumed constant) skew between the outputs.(see
below)
2.
You can drive all IDELAYs from the fabric, using internal fan-out.
Again, you an compensate away the routing delay differences.

The compensation is done by setting all IDELAY values be to the same,
and then observing the parallel captured word. It should always be
either all zeros or all ones. If it's different, change the responsible
IDELAY accordingly.

Obviously, this compensation deos not cover drift with temperature and
Vcc.

Peter Alfke, Xilinx Applications

 

[Ray Andraka]

Andy Peters wrote:

A FIFO in a single-port RAM? Neat trick, although I suppose the slow
speed makes it do-able.

-a

Andy,

Sure, I've done that many times, as well as virtual multi-port memory.
The key is to time multiplex the ports into the single port using a
faster memory clock than the access rate you need on any one port.

Damir,
It isn't really a hard problem, you basically have two address counters
muxed into the single address of the RAM. An additional up/down counter
will give you the population count needed for a synchronous FIFO, and a
little bit of extra logic to decode the flags from the population count
is all that it takes. An async FIFO can only be approximated by a
single ported memory, because by definition all accesses to the memory
happen on the same clock domain. For an 'async' fifo you will need to
implement a syncrhonous fifo in the memory with a small on-chip async
fifo cascaded to the input or output to take care of the clock domain
crossing.

 

[Ray Andraka]

Phil Hays wrote:

Ray Andraka <ray@andraka.com> wrote:


This is not safe as presented, as you can't guarantee all the flip-flops
in the counter will be released from reset on the same clock cycle.


Then please show how it fails.

If bit 0, the LSB, is released last, then it works. None of the
other bits can go high until bit 0 goes high. Agree?

If bit 1, the next bit, is released last, then the bit 0 goes high
first, reset is released, then it works. Agree?

Even if two clocks could come into the LSB FF before the release of
reset to the next bit, then the count sequence would be:

0000
0001
0000
0001
0010
0011
etc

And it works.

Same thing for each bit up to the MSB.



In Xilinx
FPGAs, it is easier and more compact to use the SRL16 as a shift
register to delay the reset, and it avoids the reset signal time of
arrival issue inside the reset circuit.


I disagree. SRL16's are wonderful for logic, but have horrible
metastable charactistics. This really is a metastable problem, so
SRL16's are a bad idea. Use slice FFs to make a shift register. Or
use a SRL16, and follow it with FFs.


The problem is that if the reset is released right at the clock edge at

any one flip-flop, that flip-flop can go metastable, and can result in
it landing in the '1' state instead of the '0' state. I saw this exact
failure on an SDRAM controller provided as part of the infrastructure IP
on one of the high-end 3rd Party FPGA boards two years ago. The fix,
BTW, was to add a synchronizing flip-flop to make removal of the reset
to the whole counter synchronous with the counter's clock.

For the SRL16, yes, you are correct, the metastable performance sucks.
I should have been more exact by stating the SRL16 should be preceded by
a flip-flop. The SRL16 is essentially being used as a counter to delay
the reset. You want the FF before the SRL16, as that is where the clock
domain crossing is. You will also want a FF after the SRL16, but that
one is for timing closure, not metastability reasons.

 

[Michael Dreschmann]

Hello Peter,

I found your appnote about async fifos:
http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=pa_fifo
Very interesting and helpful, but one thing is not quite clear to me.
You write:
"FULL is of interest only to the write logic, where it must stop
further writes. FULL goes active as a result of the last write
operation, which makes the rising edge of FULL a synchronous signal,
[...] Therefore, we only need to synchronize the falling edge of
FULL..."
Then you describe how to make the falling edge synchronous to the
write clock. But why is this necessary?
If I connect the writing system to this async falling edge signal
directly what would be the problem? An "again availabe fifo" possible
would be detected one clock earlier but this shouldn't be a problem,
because the effect (falling edge of FULL) is still behind the cause
(read pointer was increased). Where is my error?

Thanks,
Michael

 

[Athena]

Hi all,

At present I am using EDK7.1 to do projects. By EDK I get a file "download.bit". If i use the "impact" of ISE7.1, i can download this file to the Virtex-ii Pro50 fpga board(produced by memec insight), but the file is in ram, so I have to download it every time when the power is on. However, I want to download the file in prom or flash once, and make the the system run every time when the power is on. According to EDK document "Chapter12 Programming flash memory", I think it is possible. However i couldn't find the prom on the fpga board when using the impact to check the device. Or maybe I can use flash or system ACE, but my flash is the one I said at the beginning, It is not OK according to the edk document. I will do some tests with system ACE.

Cheers. Thank you!

Athena

 

[Peter Alfke]

Michael,
FULL is a control signal for the writing (and EMPTYis a control signal
for the reading).
As I said, the leading edges are naturally derived from the appropriate
clock, and are thus synchronous.
The falling edges are caused by the "wrong" clock, and can thushave any
weird phase relationship with the important clock.
You do not want the FULL flag go away in an asynchronous way, since
that might "confuse" the write logic, whether it can or cannot write at
this moment.
And the trailing edge of EMPTY should clearly communicate with the read
logic, in an unambiguous way. These flags must be interpreted
correctly for many millions of times, any ambiguity will bite you,
sooner or later. Usually in the worst way (Murphy's Law).
Peter Alfke

 

[Bob Perlman]

Hi -

First off, I've got to commend you for asking this question. Lots of
first-time managers don't realize they need to build a skill set until
after their first project. Good for you.

I can't answer all your questions, but here are a few comments about
maintaining schedules.

Maybe it's been improved, but after my last experience with Microsoft
Project in the mid-nineties, I vowed never to use it again. Granted,
I winge and whine about all MS tools, but Project has got to be the
least intuitive, most time-consuming tool I've ever encountered (and
I'm including CAE tools in the mix). You want to spend time refining
the schedule, not learning the peculiarities of the scheduling tool.

Try to use a simpler approach, if you can. Joel Spolsky recommends
using Excel; the following article may give you some ideas:

http://www.joelonsoftware.com/articles/fog0000000245.html

After my experience with Project, I went on the lookout for simple
scheduling tools that weren't sophisticated enough to keep trying to
"help" me. One that I've used successfully is Kidasa Milestones
(www.kidasa.com), which costs $60 and, to its credit, does very little
compared to Project.

Finally, one engineer I worked with a while back made what I'd
consider a key insight: the most important items on the schedule are
the transfer points, i.e., dates on which you transfer work to someone
else, or someone else transfers work to you. You can tell they're
important by observing how much effort people put into trying to avoid
filling them out on the schedule.

Bob Perlman
Cambrian Design Works



On 29 Nov 2005 07:53:39 -0800, gretzteam@hotmail.com wrote:

Hi,
I just got chosen as 'project manager' for our next project. It seems
like most people feel 'sorry' for me around here... We are designing a
moderately large mostly digital asic and the team consists of about 6
people. I've never managed anything before and most of the people in
the team are more senior designer than me. Right now, things are
decided from hallway conversations, and nothing is really written down
in terms of schedule and who-does-what...

I wonder what tools if any that people use to manage a project. Is
something like MS-Project any good? I understand that the schedule we
would put in place will never hold, but I figure it's better to have
something than nothing. Also, what do people use to track down bugs and
issues. The chip is divided in 6-7 blocks, each will be assigned to
one-two person. Where should I gather the information coming out of the
weekly meeting - schedule slip, bugs to be fixed etc...email?
ms-project? hallway?

Thanks a lot,

Dave

 

[Hal Murray]

No matter what, if you track the actual schedule against your original
estimate you can at least have an estimate of when you'll actually be
done. Not only can you use this estimate to motivate the troops, but
you can use it to warn your boss that things aren't going as fast as
expected.

How well does that work?

I'd expect it would give horrible results in two common cases.
(Maybe just looking at the same thing two different ways.)

One is the one-last-bug problem. All the module tests go great
but then it doesn't work when you put it together.

The other is that halfway through a project, the nature of the
work changes. You shift from writing code to integrating/checking.
Knowledge of how well things worked during the first mode doesn't
tell you anything about how good your estimates for the second mode
will be.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[Phil Hays]

Ray Andraka <ray@andraka.com> wrote:

The problem is that if the reset is released right at the clock edge at
any one flip-flop, that flip-flop can go metastable, and can result in
it landing in the '1' state instead of the '0' state. I saw this exact
failure on an SDRAM controller provided as part of the infrastructure IP
on one of the high-end 3rd Party FPGA boards two years ago. The fix,
BTW, was to add a synchronizing flip-flop to make removal of the reset
to the whole counter synchronous with the counter's clock.

Yes, this can happen, and it is OK. If the FF has an asynchronous
clear, the D input is one, and the clear is released just before the
clock edge, the FF can go metastable, and might resolve to one or
zero.

If the FF has an asynchronous clear and the D input is zero, there is
no chance of a metastable result.

So the only FF that can go metastable on the first clock edge after
reset is the LSB. That may well mess up a SDRAM controller, but will
not cause this circuit to do anything other than have the extra delay
of the metastable resolution time if that slips past the next clock
edge. Which is acceptable, as all we are hoping for is a clear
release from reset for the rest of the design.

For the SRL16, yes, you are correct, the metastable performance sucks.
I should have been more exact by stating the SRL16 should be preceded by
a flip-flop. The SRL16 is essentially being used as a counter to delay
the reset. You want the FF before the SRL16, as that is where the clock
domain crossing is. You will also want a FF after the SRL16, but that
one is for timing closure, not metastability reasons.

Good explanation.


--
Phil Hays to reply solve: phil_hays at not(coldmail) dot com
If not cold then hot

 

[Hal Murray]

If I connect the writing system to this async falling edge signal
directly what would be the problem? An "again availabe fifo" possible
would be detected one clock earlier but this shouldn't be a problem,
because the effect (falling edge of FULL) is still behind the cause
(read pointer was increased). Where is my error?

It's an asynchronous signal going into your state machine.
All the classic things can go wrong. The complicated one is
metastability. The simple one is that it meets setup for
some parts of your FSM but not for others.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[Simon Peacock]

Depends what side of the coin you come from when you consider how "powerful"
the tools are...
Sure you can't use OP in Hardware... but software is getting to be
bloatware... that's easy in software as the average PC has a ton of ram to
play with.. in real hardware .. as in not RAMS (which are symmetrical and
enjoy one transistor, one capacitor per element) there is a real cost per
transistor.. and .. although its a stone axe... it hits very often, very
fast and always on target

Simon


<fjh-mailbox-38@galois.com> wrote in message
news:1133267892.868934.258910@f14g2000cwb.googlegroups.com...

Bob Perlman wrote:
Fergus Henderson wrote:
Mike Treseler writes:
Problem 1.
There are ten times as many software designers
as digital hardware designers.
Solution 1:
Develop high-level languages for hardware design. Make these similar
enough to existing software development practices that developers only
need a general understanding of hardware optimization techniques (e.g.
pipelining, resource sharing, etc.), available hardware resources (e.g.
LUTs
and BlockRAMs), and how high-level language constructs map onto those
hardware resources. Then one hardware engineer can easily train up 10
software engineers to the level of hardware knowledge that they need in
order
to be able to productively develop efficient hardware using a
high-level language.

Would it be possible to do just the opposite, and create a high-level
language that lets a digital designer write efficient,
high-performance software the same way he'd design hardware? Because
I'd like to become an expert programmer without expending much effort.

I'm not suggesting that becoming an expert hardware designer isn't
going to take effort. But currently popular hardware design tools are
in the stone age in comparison to software design tools. The amount of
effort required to implement even very simple functionality in
synthesizable VHDL/Verilog is huge -- much higher than the effort
required to implement the same functionality in software.

Becoming an expert warrior certainly takes effort, regardless of
whether your weapon of choice is a sharpened stone axe or an AK47. But
that's not a good reason to stick with stone axes.

--
Fergus J. Henderson "I have always known that the pursuit
Galois Connections, Inc. of excellence is a lethal habit"
Phone: +1 503 626 6616 -- the last words of T. S. Garp.

 

Watch out for "feature creep" also, i.e. requirements / specifications
changing
as you're going along.

How you handle that will probably be make or break for your project.
It's a
very difficult tightrope between frustrating the people who are waiting
on your
chip (regardless of whether it's customer specific or mass market) by
playing
hardball with a formal change request procedure, or frustrating your
team
by agreeing to spec' changes without agreeing schedule impacts arising
from
those changes.

Doing project management can be very challenging, keeping all those
plates spinning in the air at the same time, but it's very rewarding
when
you hand over the development at the end.

Don't take it personally if the development gets canned, it happens a
lot in our industry. I've never seen a bad project manager be the root
cause of a cancellation, it's usually external like missing a market
opportunity or whatever. In which case you can pin it on your product
marketing people (or your top-management, or your end customers) for
being too far behind the crest of the wave.

Last word, but in my personal experience I think women make better
project managers, as they're naturally gifted multi-taskers, and
usually
have better sift skills than typical male engineers. Not always, but on
average.

Alan

 

[PeteS]

Hal Murray wrote:

No matter what, if you track the actual schedule against your original
estimate you can at least have an estimate of when you'll actually be
done. Not only can you use this estimate to motivate the troops, but
you can use it to warn your boss that things aren't going as fast as
expected.

How well does that work?

I'd expect it would give horrible results in two common cases.
(Maybe just looking at the same thing two different ways.)

One is the one-last-bug problem. All the module tests go great
but then it doesn't work when you put it together.

This is a common issue to all of us, and due to poor specifications.
Engineers (and management) hate the time to put down a thorough
specification 'because we could be actually implementing something',
but when modules don't work together because they did *not* do a
thorough spec, it takes longer and is far more frustrating, to say
nothing of being hazardous to your current employment position.
One of my cardinal rules of project management is --Have a thorough
specification of the task--.
Thorough spec: Any three of your engineers can read it and **will all
get the same result**.
If three different engineers read that spec and do not agree on what it
means, it is not a properly written spec.

The other is that halfway through a project, the nature of the
work changes. You shift from writing code to integrating/checking.
Knowledge of how well things worked during the first mode doesn't
tell you anything about how good your estimates for the second mode
will be.

True enough. I usually allow a fair amount of time (depending on who,

what etc) for 'mode changes'
Product definition
Spec writing
module implementation
Integration
testing

Each of those is a major section and should have some time between them
for the team to 'change focus'.

Your projects may have more stages for good reasons. I have found this
is the minimum for my projects, so far.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

Cheers

PeteS

 

[al99999]

Peter Alfke wrote:

After some thinking:
1.
You can divide the input load by using "zero-delay buffer chips" with
up to 8 outputs and very little skew betrween them. And you can even
compensate for the (assumed constant) skew between the outputs.(see
below)
2.
You can drive all IDELAYs from the fabric, using internal fan-out.
Again, you an compensate away the routing delay differences.

The compensation is done by setting all IDELAY values be to the same,
and then observing the parallel captured word. It should always be
either all zeros or all ones. If it's different, change the responsible
IDELAY accordingly.

Obviously, this compensation deos not cover drift with temperature and
Vcc.

Peter Alfke, Xilinx Applications

Hi,

Is this two different approaches or two steps of one process? For 2)
above, I connected the input pin to 16 IDELAY blocks but got this
error:

FATAL_ERRORackktv4iob.c:737:1.24.2.1 - Input buffer CH1_IBUF drives
multiple
DELAYCHAIN symbols. The implementation tools can not pack the
design.
Process will terminate. To resolve this error, please consult the
Answers
Database and other online resources at http://support.xilinx.com. If
you need
further assistance, please open a Webcase by clicking on the
"WebCase" link
at http://support.xilinx.com

How can I fan out the one input without getting this!!

Thanks

Al

 

[Antti Lukats]

"al99999" <alastairlynch@gmail.com> schrieb im Newsbeitrag
news:1133348095.999307.101310@o13g2000cwo.googlegroups.com...

Peter Alfke wrote:
After some thinking:
1.
You can divide the input load by using "zero-delay buffer chips" with
up to 8 outputs and very little skew betrween them. And you can even
compensate for the (assumed constant) skew between the outputs.(see
below)
2.
You can drive all IDELAYs from the fabric, using internal fan-out.
Again, you an compensate away the routing delay differences.

The compensation is done by setting all IDELAY values be to the same,
and then observing the parallel captured word. It should always be
either all zeros or all ones. If it's different, change the responsible
IDELAY accordingly.

Obviously, this compensation deos not cover drift with temperature and
Vcc.

Peter Alfke, Xilinx Applications

Hi,

Is this two different approaches or two steps of one process? For 2)
above, I connected the input pin to 16 IDELAY blocks but got this
error:

FATAL_ERRORackktv4iob.c:737:1.24.2.1 - Input buffer CH1_IBUF drives
multiple
DELAYCHAIN symbols. The implementation tools can not pack the
design.
Process will terminate. To resolve this error, please consult the
Answers
Database and other online resources at http://support.xilinx.com. If
you need
further assistance, please open a Webcase by clicking on the
"WebCase" link
at http://support.xilinx.com

How can I fan out the one input without getting this!!

Thanks

Al

Hi Al,

I think Peter did suggest the impossible, there is no connections in the
FPGA that would allow single signal to be routed to multiply IDELAY
elements. The only possibility would be to use unbonded IOBs as route
through, but I have not found an option that allows the use of unbonded IOBs
in user design

Antti

 

[PeteS]

Simon Peacock wrote:

Depends what side of the coin you come from when you consider how "powerful"
the tools are...
Sure you can't use OP in Hardware... but software is getting to be
bloatware... that's easy in software as the average PC has a ton of ram to
play with.. in real hardware .. as in not RAMS (which are symmetrical and
enjoy one transistor, one capacitor per element) there is a real cost per
transistor.. and .. although its a stone axe... it hits very often, very
fast and always on target

Simon

Software as bloat [well, non-optimised] (which covers a lot of ground
nowadays) has in fact been justified by people such as Eric Raymond
with the rationale that processor cycles and memory is cheap and
getting cheaper.

The issue in hardware (well, reasonably fast hardware) is bloat, by
definition, is a bad thing[tm].

Taking a fairly standard for instance, let's implement a simple memory
interface, but with a wrinkle; the bus has a *minimum* speed (such as
DDR). Now you can't just run it a little slower - the memory devices
*won't work*. For such an application, a thorough knowledge of the
interface (and the chips on the other side of the design) is a
pre-requisite. It's no good saying do this, then that.

Earlier in the thread, I noticed some compilers automatically register
everything. The problem there is now we get resource utilisation
problems and we *can't route* and meet our timing criteria.

So, before we get to the 'advanced type of tools such as software has',
we must first make them efficient and non-bloating.

Just my $0.02

Cheers

Petes