EDK : FSL macros defined by Xilinx are wrong

Melissa Vetromille wrote:
Hello!

I have a system implemented in hardware and I prototyped it in
VIrtex-II Pro platform with a testbench. I analyzed the signals using
chipscope and it worked the same as in simulation. After this, I
created a project in EDK and substituted the testbench by a
Microblaze processor. The project stopped working. Now, I need to
debug the harwdare in order to find the problem, ut I don't know how
to do this. I'm trying to use ModelSim.
In fact, I generated the simulation files and created the testbench
file to stimulate my system. However, this testbench just generates
the clock and reset, so I need instanciate my software in order to
generate the other stimulus. Is it possible? What do I have to do in
order to incorporate my software in simulation? Does anyone can help
me?

Thank you!

Melissa
Click to expand...

If your tb entity name is Test_sim and if your EDK system instance is
UUT, add this to your testbech :

configuration tb_conf of Test_sim is
for testbench_arch
for UUT: system
use configuration work.system_conf;
end for;
end for;
end tb_conf;


Also, simulate the tb_conf configuration and not just your test bench
entity. (when selecting what to simulate).
EDK will also create a system.do or a .do to load everything needed IIRC.



Sylvain
 
Hi Austin,

So, can I then summarize that EasyPath is basically a standard Virtex
II/4 but with less time on the testbed (only the cells and routing used
by the customer are tested) in order to reduce cost?

There is a basic 1's, 0's, shorts, leakage, etc test done to all parts,
EasyPath or no.
Click to expand...
Of course. The global die specs must be met.

And then, for EasyPath, only those features used by the customer are
tested (with the addition of any LUT pattern for the CLBs they use, and
any IO strength for th IOB standard they use, which allows for the two
most common ECO requests we got after we shipped). The difference in
test time between as close as we can get to 100% testing for any
possible use, and as close as we can get to 100% testing for one use is
SIGNIFICANT.
Click to expand...
Sounds quite reasonable. So, technologically there's nothing holding Altera
back in investing in a few extra ("standard") device testers and, as an
intermediate price-reduction step, doing same under the hereby trademarked
name "Crippledie" (come to think of it, sounds great as the title of an
ultra-violent FPS game taking place in a hospital or a leper colony too -
I'll have a chat with my local EA Games marketing guy).

I can't imagine that only partially testing an ASIC is patentable - but then
again, one-click-shopping is patentable as well according the USPTO so I
wouldn't be surprised.

Then of course there's HardCopy2, which, like EasyPath, only needs to be
tested with the user design _but also_ is a lot smaller in die size.

Thus:

Better Yield+Shorter Time+Smaller Area = Even Lower Cost to Altera, which
means even Lower Prices to customer. No ECO and no last-minute changes
though, I'll give you that.

Am I right?

Best regards,



Ben
 
I've found out how to prevent the delays.. If you run rpcbind with the
-i (insecure..) flag, there is no delay. (Well this is with BaseX but
I don't see why it would be any different for WebPack)

Still trying to figure out why my file dialogs complain about long
paths though..
 
codejk,

What kind of floating-point number is it? IEEE754? Single or double
precision?

Are those the actual dimensions of your matrices?

It looks to me like you have 9 multiplications, 6 additions and 2
divisions to do every 80ns. I work this out to be 212.5MFLOPS.

According to:
http://www.xilinx.com/ipcenter/processor_central/microblaze/microblaze_fpu.htm

The best performance you're going to get from a FPU-enabled microblaze
running on a V4 is 33MFLOPS (clocking at 200MHz). I work out about
22-23 MFLOPS being the most you would get for your particular
instruction mix. Reduce this again for the lower performance of the
Spartan 3, then you're looking at being a long way off from what you
need.

So, FPU-enabled microblaze is a good suggestion, but when you factor in
the 'result every 80 ns constraint' it's unfortunately not viable.

All is not lost though, even with Spartan devices these days you can
get well into the GFLOPS in terms of floating-point performance. To do
it you need to take advantage of the vast real-estate and
data-throughput capabilities of the devices.

What I would suggest are floating-point cores. Pipelined, and with
multiple instantiations. With these you could easily obtain the
performance you need.

You would have to pay for the IP, but once you had it you could very
easily achieve your design with minimum headaches.

Of course, if you don't have the cash to fork out on this, then you'll
have no choice but to look at another way of doing it, fixed point for
example...

Tell us how you get on,

Robin
 
Firstly.. a 16-bit spi peripheral is just done with two spi transactions.

Second.. don't use gated clocks.

Third.. see two (can't repeat this often enough).

Forth.. use a divide by two with a clock enable to generate the SPI clock.
It will clean up all your problems.
including sending on rising edge, receiving on falling edge. The only down
side is it takes twice as long... so you wait 8 'busy_waits' instead of 4 ..
usually it doesn't cause a problem.


Simon


"Marco" <marcotoschi@nospam.it> wrote in message
news:dhu826$vdo$1@news.ngi.it...
"Antti Lukats" <antti@openchip.org> wrote in message
news:dhu2oi$a4c$05$1@news.t-online.com...
"Marco" <marcotoschi@nospam.it> schrieb im Newsbeitrag
news:dhu289$tce$1@news.ngi.it...
Hallo,
I have made a clock divider using a counter connected to master clock
and
a
comparator.

The comparator has a clock enable to avoid "gating-clock".

Now my trouble. I have connected some logic blocks to the new clock,
but
in
this way it has high load and delay.

1) you should connect ALL clk inputs to master clock (not the new clock)
and
use clock enables
2) why do you reinvent the wheel? the opb_spi core is provided by xilinx
for
free!
3) SPI is easier to implement as FSL peripheral :)
4) in most cases the GPIO bitbanged SPI is fastest to implement, and
takes
no resources (except gpio pins) sure takes some sw overhead

antti



I have tried using a BUFG, and I think it could be a work around.

I would know if there are other solution when load is high.

Marco
Click to expand...
 
have you ever listened to the radio and heard those magic words "and coming
up after 8am....."

Simon


"Antti Lukats" <antti@openchip.org> wrote in message
news:dhua46$3eh$00$1@news.t-online.com...
"Ed McGettigan" <ed.mcgettigan@xilinx.com> schrieb im Newsbeitrag
news:4342A6AA.6020500@xilinx.com...
Antti Lukats wrote:
"Ed McGettigan" <ed.mcgettigan@xilinx.com> schrieb im Newsbeitrag

We have improved the VGA quality on the upcoming ML405 and ML410
boards
that will be released early next year.

Ed


Hi Ed,

your comment about 405 "to be released early next year" (2006) sounds
like
firm indication that Xilinx has serious problems with 4FX? The ML405
was
announced no later than jan 2005 (maybe earlier), now you are saying
that it
is coming sometime in 2006 ? Why announce products that are 'maybe'
coming
more than a year later? I would have expect ML405 to be available by
now.
Well if there is really an issue with 4FX that would explain why no FX
boards are available from Xilinx online shop. Just wondering.


Right now almost all of the FX20 silicon is being shipped to customers
on a priority basis. We do have fully functional ML405 and ML410 boards
in house that we are now making available to our processor specialist
FAEs and available on a limited loaner basis to customers and this will
increase over coming months.

It takes 3-4 months from this point before we can complete all of the
rest of the material in order to turn it from early access board that
requires a knowledgeable and trained person to use it into a general
availability product with full manufacturing tests, documentation,
reference designs and packaging. Also, our internal processes has
certain requirements that must be met before we place boards in the
Xilinx
Online Store, this should happen 1-2 months after the boards are
available from our distributors.

We haven't formally announced the ML405 and ML410, but we have shown
them at trade shows and forums such as this as an upcoming development
vehicle for Virtex-4. We do this so that our customers and partners can
understand what our plans our for support collateral so that they can
develop their own product development and test roadmaps.

Ed

Ok that explains it a bit. I expected that Xilinx internally should have
ml405 boards. So the deal is that the boards are there, but are just not
going to be made available until someday in 2006.

I still dont see a point to have the ml405 being mentioned in Xilinx
publications in JAN 2005, and then ship sometime in 2006

Antti
Click to expand...
 
I tried Project > Cleanup Project Files, and that didn't seem to help. Are
there any other implementation files that I should delete which isn't taken
care of by that?

Thanks,

-- Matt

"Adarsh Kumar Jain" <adarsh.jain@cern.ch> wrote in message
news:dhqt4u$gcb$1@sunnews.cern.ch...
you can try to delete the project implementation files and retry. I also
had this portability error but with a different message but it went off
once i deleted the project implementation files.
Cheers,
Adarsh
"Matthew Plante" <maplante@iol.unh.edu> wrote in message
news:dhjtlc$80c$1@tabloid.unh.edu...
Has anyone else received this error with ISE 7.1i? I added a peripheral
to my embedded system, and when I re-synthesize it it XST, I get:

ERROR:portability:3 - This Xilinx application has run out of memory or
has encountered a memory conflict. Current memory usage is 798040 kb.
Memory problems may require a simple increase in available system memory,
or possibly a fix to the software or a special workaround. To
troubleshoot or remedy the problem, first: Try increasing your system's
RAM. Alternatively, you may try increasing your system's virtual memory
or swap space. If this does not fix the problem, please try the
following: Search the Answers Database at support.xilinx.com to locate
information on this error message. If neither of the above resources
produces an available solution, please use Web Support to open a case
with Xilinx technical Support off of support.xilinx.com. As it is likely
that this may be an unforeseen problem, please be prepared to submit
relevant design files if necessary.

Any ideas?


Thanks,
-- Matt


+--
|Matthew Plante
| University of New Hampshire
| InterOperability Lab
| Research & Development
| SMTP: maplante@iol.unh.edu
| Phone: +1-603-862-0203
+-
Click to expand...
 
I use similar structures in Synplify all the time. I don't see why XST
would do a poor implementation of the same thing as long as it knows that
useA and useB are wires and not to integrate the combinatorial equations for
useA and useB into the adder. I modified the diagram to illustrate how the
representation fits your need.

"Sylvain Munaut" <com.246tNt@tnt> wrote in message
news:4342f488$0$28231$ba620e4c@news.skynet.be...
John_H wrote:
snip
q <= (useA ? A : 0) + (useB ? B : 0); // 1 level

Actually, I don't see how to fit your representation (useA useB) into a
single level ...

What I wanted the tool to do is : (pt_n is not passthru)
Click to expand...
Following diagram modified for useA and useB above:

. cout
. _|_
. ,--/___\ CYMUX
. | | |
. ______ | | |
. a(b) ---------| | | | | ____ XORCY
. b(n) ------x--| LUT4 |-x----------\\ \_____
. useB ---x--|--| | | x----//___/
. useA ---|--|--|______| | |
. | | / |
. | | __ / |
. | '------| \ _/ cin
. '---------|__/
. MULT_AND


Sylvain
Click to expand...
 
John_H wrote:
I use similar structures in Synplify all the time. I don't see why XST
would do a poor implementation of the same thing as long as it knows that
useA and useB are wires and not to integrate the combinatorial equations for
useA and useB into the adder. I modified the diagram to illustrate how the
representation fits your need.
Click to expand...
Yeah, I confused the two choices of CYMUX ... My bad. The two
representation works just fine.

But XST doesn't understand yours either ... it also uses two level with
useA and useB ...


Sylvain


"Sylvain Munaut" <com.246tNt@tnt> wrote in message
news:4342f488$0$28231$ba620e4c@news.skynet.be...

John_H wrote:

snip

q <= (useA ? A : 0) + (useB ? B : 0); // 1 level

Actually, I don't see how to fit your representation (useA useB) into a
single level ...

What I wanted the tool to do is : (pt_n is not passthru)


Following diagram modified for useA and useB above:


. cout
. _|_
. ,--/___\ CYMUX
. | | |
. ______ | | |
. a(b) ---------| | | | | ____ XORCY
. b(n) ------x--| LUT4 |-x----------\\ \_____
. useB ---x--|--| | | x----//___/
. useA ---|--|--|______| | |
. | | / |
. | | __ / |
. | '------| \ _/ cin
. '---------|__/
. MULT_AND
Click to expand...
 
Hi Bill,

On Tue, 4 Oct 2005 12:16:04 +0200, "Bill" <billbill@telia.se> wrote:
Is the following a good way to avoid meta stability problems? The signal 'd'
is synchronous to a 1.8 MHz clock?
Click to expand...
And from your code I assume that the synchronizing clock is
24 MHz.


The answer to yor question is that your solution is NOT a good
way to "avoid" metastability.

First, you can't avoid it, you can only make its effect lower
probability. The way to make it lower probability is to have
additional settling time within the synchronizer.

Second, while your circuit is clever, it boils down to
a two stage synchronizer, with logic (your median circuit)
between the first and second stage. This logic subtracts
from the resolving time available between the first stage
and the second stage of your synchronizer. As is often the
case with proposed circuits to help mitigate metastability
in clock domain crossing circuits, what you have done is
made the analysis of the behavior harder, but the result is
not as good as just two flipflops.

Peter's response to you is dead wrong in this part:
There are more important things to worry about, forget metastability...
Click to expand...
in this part:
If you run a 1.8 MHz clock (even with a similar asynchronous data
rate), your chance of having a 3 ns extra metastable delay is once per
billion years (at 24 MHz it would be only 5 million years).
Click to expand...
the assumption of 3 ns slack is unsupported, and if you are using
Xilinx's crappy FPGA router (you don't say which product you are
targetting) then there may be no slack regardless of what the cycle
time is, although as clock rates drop the likelyhood of there
being no slack diminishes. This is because the router stops trying
to improve the route as soon as the timing specification is met.
At this point there is no slack.

This issue can be helped by adding specific timing constraints to
the synchronizer circuit that force additional resolving time by
specifying path requirements that are more demanding than the
clock cycle time implies.

in this part:
For every additional ns of acceptable settling time, the
mean-time-between-failure increases at least a million times. (see
XAPP094 on the Xilinx website)
Click to expand...
this rule of thumb depends on what product you are using. The 1E6
is for the latest devices. You may be using something else.
Older technology may have numbers as low as 1E2.

In summary, you will be better served with a simple two stage
synchronizer, with as tight a timing constraint as you can use
to maximize the slack time between the first and second flip flops.

You can read FAR more on the subject at this URL:

http://www.fpga-faq.org/FAQ_Pages/0017_Tell_me_about_metastables.htm


... your VHDL ...
Click to expand...


Philip Freidin



===================
Philip Freidin
philip.freidin@fpga-faq.org
Host for WWW.FPGA-FAQ.ORG
 
Peter Alfke wrote:
The rule still is: If you have reason to worry about metastability,
give the flip-flop in question maximum slack to settle, and have it
drive only one near-by synchronizing flip-flop. Without that
precaution, you might get into trouble...
Click to expand...
Peter, rookie question: given the following synchronizer:

module test(input clk, input in_sig, output reg out_sig);
reg [1:0] ss;

always @(posedge clk)
begin
out_sig <= ss[1];
ss <= { ss[0], in_sig };
end
endmodule


How, specifically, do I tell XST to locate ss[1] as close as possible
to ss[0]?


Regards,
Paul.
 
Melissawrote:
In fact, I had already put this configuration statments in the end of
Click to expand...
my testbench, but I didn't see the software working. My system just
writes the value '1' in a register(slv_reg0) and '2' in
another(slv_reg1), but when I simulate the system in ModelSim the
registers continue with the value '0'. Shouldn't it change the value
of my registers?
Thank you!

Sylvain Munautwrote:
Melissa Vetromille wrote:
Hello!

I have a system implemented in hardware and I prototyped it in
VIrtex-II Pro platform with a testbench. I analyzed the signals
using
chipscope and it worked the same as in simulation. After this, I
created a project in EDK and substituted the testbench by a
Microblaze processor. The project stopped working. Now, I need to
debug the harwdare in order to find the problem, ut I don't know
how
to do this. I'm trying to use ModelSim.
In fact, I generated the simulation files and created the testbench
file to stimulate my system. However, this testbench just generates
the clock and reset, so I need instanciate my software in order to
generate the other stimulus. Is it possible? What do I have to do
in
order to incorporate my software in simulation? Does anyone can
help
me?

Thank you!

Melissa
Click to expand...
If your tb entity name is Test_sim and if your EDK system instance is
UUT, add this to your testbech :

configuration tb_conf of Test_sim is
for testbench_arch
for UUT: system
use configuration work.system_conf;
end for;
end for;
end tb_conf;


Also, simulate the tb_conf configuration and not just your test bench
entity. (when selecting what to simulate).
EDK will also create a system.do or a .do to load everything needed
IIRC.



Sylvain[/QUOTE]
 
Melissawrote:
I had already tryied to debug using chipscope, but it showed an
Click to expand...
error. The place and route report showed that I have 1 BSCAN and
with chipscope I have to use another. So, I'm trying to use 2 BSCANs
and it overmaps the FPGA. What do I have to do in order to use
chipscope? I inserted a chipscope_icon and a chipscope_opb_iba. Do I
have to insert something else?
Thank you!

Zarawrote:
On Tue, 04 Oct 2005 19:16:46 -0500,
mvetromille@gmail-dot-com.no-spam.invalid (Melissa Vetromille)
wrote:

Hello!

I have a system implemented in hardware and I prototyped it in
VIrtex-II Pro platform with a testbench. I analyzed the signals
using
chipscope and it worked the same as in simulation. After this, I
created a project in EDK and substituted the testbench by a
Microblaze processor. The project stopped working. Now, I need to
debug the harwdare in order to find the problem, ut I don't know
how
to do this. I'm trying to use ModelSim.
In fact, I generated the simulation files and created the testbench
file to stimulate my system. However, this testbench just generates
the clock and reset, so I need instanciate my software in order to
generate the other stimulus. Is it possible? What do I have to do
in
order to incorporate my software in simulation? Does anyone can
help
me?

Thank you!

Melissa

For me, the best way to debug hardware with a microblaze inside is to
Click to expand...
instantiate a ChipSocpe icon and ila inside the design, connected to
the secondary bscan port of an opb_mdm connected to the microblaze.
This way, you may debug hardware or software (not simultaneously)
easily.[/QUOTE]
 
On 5 Oct 2005 15:33:44 -0700, "Paul Marciano" <pm940@yahoo.com> wrote:

Peter Alfke wrote:
The rule still is: If you have reason to worry about metastability,
give the flip-flop in question maximum slack to settle, and have it
drive only one near-by synchronizing flip-flop. Without that
precaution, you might get into trouble...

Peter, rookie question: given the following synchronizer:
Click to expand...
I'm not Peter, but you could put the following two lines in your UCF:

INST "ss_1" LOC = "CLB_R1C1.S0" ;
INST "ss_0" LOC = "CLB_R1C1.S0" ;

If you don't like the upper left corner, change both lines to
different rows and columns to move it. Or if you want the tools to
automatically place both FFs, put the following two lines in your UCF:

INST "ss_1" RLOC = "R0C0.S0" ;
INST "ss_0" RLOC = "R0C0.S0" ;

It would be more complex if one FF was in an IOB, or was an output
from BlockRAM. It could be done with attributes in the source. This
can get well beyond a rookie question!

Also, should make sure the routing agrees: Add something like the
following to the UCF:

INST "ss_1" TNM = "SYNC_FF";
INST "ss_0" TNM = "SYNC_FF";
TIMESPEC "TS_SYNCS" = FROM "SYNC_FF" TO "SYNC_FF" 2.5 ns;

The time value needs to be adjusted based on the family, speed grade,
and other variables.


--
Phil Hays to reply solve: phil_hays at not(coldmail) dot com
If not cold then hot
 
Well, Philip and I are good friends since 25 years back, that's why I
let him call me "dead wrong".
And we have a long-standing controversy about the dangers of
metastability.
My error was making the tacit assumption that a 24 MHz design would
always have 3 ns slack. I should have suggested to force the router to
assume 33 Mhz, which would then absolutely guarantee an extra 8 ns of
slack. The design in question was descibed as dead slow....
Then the question of device generation: 8 years ago, in XC4008-8
devices, I measured 4 decimal orders of magnitude increase in MTBF fo
every extra ns. (But that device was very slow even then)
XC4005-3 was faster, and increased MTBF by 8 orders of magnitude per
ns.
And Virtex2Pro increased by 9 orders of magnitude, and has a much
shorter basic delay.
It's all documented in XAPP094.
So you really have to go to the museum to get parts with slow recovery
from metastability.
Like 74S74 and 74H74 dual flip-flops, the arch-villains of bad
metastable behavior in the 'sixties and 'seventies. But who cares about
them today?

In many cases, designers just make the fundamentally unforgivable
mistake of synchronizing an asynchronous input in two parallel paths,
always expecting the identical result. Fat chance.

Philip wants to make sure that we all stay alert against the evil force
of metastabilty, while I want to make people aware that the problem
often is elsewhere. We are not that far apart.
Peter Alfke, from home.
 
Oops,

Looks like I read the 'english', and not the code.

Looks like it is registered once, and then sent to another FF. Both
FF's are clocked on the rising edge, so it is not a metastability
"filter" (which would clock the second FF on the falling edge) to reduce
the probability of a metastable event (they can not be prevented, but
the statistics can be improved to where you just don't care).

That is a standard looking shift register.

No issue with that.

The FPGA fabric is always slower than a global clock (except in some
rare cases where things are really poorly placed due to other issues
with poor or confusing or conflicting constraints), so there is no
problem (like there could be in an ASIC) that the data might get to some
FF's before the clock would (and an event is missed altogether).

The tools should make a reasonably good placement to prevent problems.

I have seen where folks used location constraints to be sure that the
clock arrived at the MSB or last stage first, and then went against the
flow of data towards the LSB or first stage to ensure that the clock
would always get to the FF BEFORE the data coming to the FF could
possibly change in ASIC standard cell flows. Not really needed in an
FPGA: the fabric and clocks are supposed to be "correct by
construction" so the engineer doesn't have to worry.

This whole thing also has nothing to do with metastability.

Austin

Austin Lesea wrote:

Paul,

Unless Peter has hidde talents I am unaware of, let me try to answer this.

Apply minimum time constraint to the routing of the signals in question.

This may be difficult to do, as if you overconstrain, the tools give up,
without necessarily finding the best they can do (why work hard on
something that can't be done?).

An alternative is to look at the placed and routed design in FPGA Editor
so you can find the actual delays on the nets in question. If the
delays are not acceptable, you can reroute by hand.

This is obviously tiresome, and difficult, which is the reason why you
should not be doing this at all: one should register the signal in
question ONCE, and then route it to where it is needed or used.

It is poor design to sample any signal more than one time, and expect to
get the same result if timing is not guaranteed (ie synchronous with the
proper setup and hold times being always observed).

Austin



Paul Marciano wrote:

Peter Alfke wrote:

The rule still is: If you have reason to worry about metastability,
give the flip-flop in question maximum slack to settle, and have it
drive only one near-by synchronizing flip-flop. Without that
precaution, you might get into trouble...



Peter, rookie question: given the following synchronizer:

module test(input clk, input in_sig, output reg out_sig);
reg [1:0] ss;

always @(posedge clk)
begin
out_sig <= ss[1];
ss <= { ss[0], in_sig };
end
endmodule


How, specifically, do I tell XST to locate ss[1] as close as possible
to ss[0]?


Regards,
Paul.
Click to expand...
 
Philip,

I always enjoy reading patents that claim to eliminate metastability.

Seems that the patent office has never figured this one out: they did
make it a law that perpetual motion machines are not patentable, but
there is no such restriction for metastability "eliminators" (all of
which don't work!).

Many of these clever circuits perform worse than the standard solutions
found in any good textbook on the subject, as you point out.

Austin

Philip Freidin wrote:

Hi Bill,

On Tue, 4 Oct 2005 12:16:04 +0200, "Bill" <billbill@telia.se> wrote:

Is the following a good way to avoid meta stability problems? The signal 'd'
is synchronous to a 1.8 MHz clock?


And from your code I assume that the synchronizing clock is
24 MHz.


The answer to yor question is that your solution is NOT a good
way to "avoid" metastability.

First, you can't avoid it, you can only make its effect lower
probability. The way to make it lower probability is to have
additional settling time within the synchronizer.

Second, while your circuit is clever, it boils down to
a two stage synchronizer, with logic (your median circuit)
between the first and second stage. This logic subtracts
from the resolving time available between the first stage
and the second stage of your synchronizer. As is often the
case with proposed circuits to help mitigate metastability
in clock domain crossing circuits, what you have done is
made the analysis of the behavior harder, but the result is
not as good as just two flipflops.

Peter's response to you is dead wrong in this part:

There are more important things to worry about, forget metastability...


in this part:

If you run a 1.8 MHz clock (even with a similar asynchronous data
rate), your chance of having a 3 ns extra metastable delay is once per
billion years (at 24 MHz it would be only 5 million years).


the assumption of 3 ns slack is unsupported, and if you are using
Xilinx's crappy FPGA router (you don't say which product you are
targetting) then there may be no slack regardless of what the cycle
time is, although as clock rates drop the likelyhood of there
being no slack diminishes. This is because the router stops trying
to improve the route as soon as the timing specification is met.
At this point there is no slack.

This issue can be helped by adding specific timing constraints to
the synchronizer circuit that force additional resolving time by
specifying path requirements that are more demanding than the
clock cycle time implies.

in this part:

For every additional ns of acceptable settling time, the
mean-time-between-failure increases at least a million times. (see
XAPP094 on the Xilinx website)


this rule of thumb depends on what product you are using. The 1E6
is for the latest devices. You may be using something else.
Older technology may have numbers as low as 1E2.

In summary, you will be better served with a simple two stage
synchronizer, with as tight a timing constraint as you can use
to maximize the slack time between the first and second flip flops.

You can read FAR more on the subject at this URL:

http://www.fpga-faq.org/FAQ_Pages/0017_Tell_me_about_metastables.htm



... your VHDL ...




Philip Freidin



===================
Philip Freidin
philip.freidin@fpga-faq.org
Host for WWW.FPGA-FAQ.ORG
Click to expand...
 
Hi Ben,
Thank you for your advices.

Now I'll try to use coregen IPs in ISE 6.1.
I cannot use the latest release of ISE (7.1.03, I mean)
because it seems like it has some bugs.
(I'm not sure about that. Maybe my circuit has some bugs, too.)

And.. My application related to 2D graphics.
Exactly it's about the self configuration of image sensor using several
images but
now I have too much obstacles :)
Thank you so much.
 
You are most likely right ... but as you say.. many designers confuse the
two but the effect is the same (missing samples) .. so is the cure :)

Simon



"Peter Alfke" <alfke@sbcglobal.net> wrote in message
news:1128523047.354410.304960@g44g2000cwa.googlegroups.com...
Simon, your problem was not metastability. Since many designers do not
really understand the metastable mechanism, it gets blamed for all
mystery problems. In many cases the problem is caused by synchronizing
an asynchronous input in more than one flip-flop in parallel. This will
inevitably fail, because the two flip-flops have different capture
times. But that has nothing whatsoever to do with metastabilty...
Peter Alfke
Click to expand...
 
yes and no.

Xilinx and Altera both have 'standard' libraries. They are VHDL, Verilog,
schematic ..... you can guarantee them to be different as the underlying
structure is different.

Mostly they have their built-in's (pin definitions, LUTs block rams etc)
but you can often find 74 series gates too.
Xilinx has a rather nice core gen to build more complex functions.. some are
free some cost. Mostly it depends on what you want from your library

Simon

"Simon Heinzle" <sheinzle@student.ethz.ch> wrote in message
news:4344d45b@news1.ethz.ch...
Hi everybody,

With ASICs, there are standard cell libraries in .lib file format for the
target process -- is there a comparable .lib file for the Xilinx FPGAs?

Best regards,
Simon
Click to expand...
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top