simprim X_FF component

C

Chao

Guest
Hello, dear all

when I did my timing simulation, I got the warning message:
# ** Warning: /X_FF SETUP Low VIOLATION ON I WITH RESPECT TO CLK;
# Expected := 0.67 ns; Observed := 0.258 ns; At : 1.9 ns

Can someone tell me more about the X_FF component from the simprim
library? Or is there any link for the explanation. I failed to find
out any in the past 60 minutes. Thanks for your help.

Chao.
 
when I did my timing simulation, I got the warning message:
# ** Warning: /X_FF SETUP Low VIOLATION ON I WITH RESPECT TO CLK;
# Expected := 0.67 ns; Observed := 0.258 ns; At : 1.9 ns

Can someone tell me more about the X_FF component from the simprim
library? Or is there any link for the explanation. I failed to find
out any in the past 60 minutes. Thanks for your help.

This looks like a setup & hold type violation.
Is the signal into the flip-flop asynchronous to its clock? most likely.
So pass the signal thru several stages of FFs to reduce meta stability.
You'll still get the above message though. The massage can be turned off
but it's probably better to leave it on & check that each one really is a
meta stability issue.

(Unless of course you have an incredibly fast clock, like GHz range).

Anyway, that's what I think, others are wlecome to correct me or re-enforce!
 
Hi, Niv

thank you for your answer. yes, I knew that was caused by the setup
time requirement. It is a good idea to avoid the meta-stability for
sampling the input data. Can you give me some explanation to the X_FF
component? because it is appeard very often in the timing_sim.vhd
(i.e. tool-generated timing simulation file). Thanks

Chao.


"Niv" <niv.nospam.goaway@ntlworld.com> wrote in message news:<JpRDc.20$444.0@newsfe4-gui>...
when I did my timing simulation, I got the warning message:
# ** Warning: /X_FF SETUP Low VIOLATION ON I WITH RESPECT TO CLK;
# Expected := 0.67 ns; Observed := 0.258 ns; At : 1.9 ns

Can someone tell me more about the X_FF component from the simprim
library? Or is there any link for the explanation. I failed to find
out any in the past 60 minutes. Thanks for your help.

This looks like a setup & hold type violation.
Is the signal into the flip-flop asynchronous to its clock? most likely.
So pass the signal thru several stages of FFs to reduce meta stability.
You'll still get the above message though. The massage can be turned off
but it's probably better to leave it on & check that each one really is a
meta stability issue.

(Unless of course you have an incredibly fast clock, like GHz range).

Anyway, that's what I think, others are wlecome to correct me or re-enforce!
 
c.chen@gmx.de (Chao) writes:

thank you for your answer. yes, I knew that was caused by the setup
time requirement. It is a good idea to avoid the meta-stability for
sampling the input data. Can you give me some explanation to the X_FF
component? because it is appeard very often in the timing_sim.vhd
(i.e. tool-generated timing simulation file). Thanks
X_FF is just the simulation model of a Flip-Flop. As far as I remember
the sources of the model are delivered with your copy of ISE. Search
the Xilinx directory for the simlation sources. Normally you compile
these sources to build your simulation library.

If you don't like the original simulation model, just write your own one :)

But if your problem is asynchronous inputs that cause many 'X' in simulation,
then I'd suggest searching the group on how to switch of x-propagation of your
simulator.

BR
 
For ModelSim, you add this option to your vsim command:
-GXon=FALSE

"Gary Michels" <i_ll_reply_to_the_group@hotmail.com> wrote in message
news:1xjywcpw.fsf@inter.net...
c.chen@gmx.de (Chao) writes:

thank you for your answer. yes, I knew that was caused by the setup
time requirement. It is a good idea to avoid the meta-stability for
sampling the input data. Can you give me some explanation to the X_FF
component? because it is appeard very often in the timing_sim.vhd
(i.e. tool-generated timing simulation file). Thanks

X_FF is just the simulation model of a Flip-Flop. As far as I remember
the sources of the model are delivered with your copy of ISE. Search
the Xilinx directory for the simlation sources. Normally you compile
these sources to build your simulation library.

If you don't like the original simulation model, just write your own one
:)

But if your problem is asynchronous inputs that cause many 'X' in
simulation,
then I'd suggest searching the group on how to switch of x-propagation of
your
simulator.

BR
 
Let me start by saying, do not write your own X_FF model and do not use
the -GXon switch. Neither is good advice in my opinion and both of
these can get you into far more trouble than help in almost any
situation. Let me first address the initial question: "Can someone tell
me more about the X_FF component from the simprim library? Or is there
any link for the explanation."

Simulation is covered in the Synthesis and Verification Design Guide.
The current version is located at:
http://toolbox.xilinx.com/docsan/xilinx6/books/docs/sim/sim.pdf
If you go to chapter 6 and go to the section "Debugging Timing Problems"
(page 265) it will explain the timing message and how to understand what
it is telling you, how to debug the issue and hopefully solve the
problem. This is also explained in less detail in Answer Record #5255
SIMPRIM, Timing Simulation - What are "$setup" and "$hold" violations,
and how do I fix them? (VHDL, Verilog) (at www.xilinx.com/techdocs/5255.htm)

If the input is truly an asynchronous input, then you need to design
your circuit to avoid the side-effects of missing timing such as
metastability and once you are satisfied, you can put an ASYNC_REG
attribute on that register. This has the advantage of disabling
X-propogation on that register only so if you have a timing violation
elsewhere, it will still behave appropriately. The global disabling of
X-propogation adds the danger of missing a timing violation in a
synchronous path which can cause a very unpredictable circuit. This too
is covered in more detail in the documents referenced above. Look at
the "Disabling 'X' Propagation" section in the Synth & Verification
Guide which is also referenced from the above section on debugging
timing problems and the link in the Answer record.

I highly suggest you browse through the chapters of this book as it may
explain other things you are seeing in functional and timing simulation
and give more elegant solutions that you may have thought otherwise.
Also the on-line answer records cover many of these topics. Finding the
right answer record is not always easy as there is a lot of information
available there but if you type in the right key words, it generally
comes out in the top few and should not be too hard to find. You should
not need anything near 60 minutes to find this information and if that
is the case, then something is wrong. If you have suggestions on
improving how this data is presented, let me know and I can be sure to
pass that on to the appropriate people.


-- Brian


Barry Brown wrote:
For ModelSim, you add this option to your vsim command:
-GXon=FALSE

"Gary Michels" <i_ll_reply_to_the_group@hotmail.com> wrote in message
news:1xjywcpw.fsf@inter.net...

c.chen@gmx.de (Chao) writes:


thank you for your answer. yes, I knew that was caused by the setup
time requirement. It is a good idea to avoid the meta-stability for
sampling the input data. Can you give me some explanation to the X_FF
component? because it is appeard very often in the timing_sim.vhd
(i.e. tool-generated timing simulation file). Thanks

X_FF is just the simulation model of a Flip-Flop. As far as I remember
the sources of the model are delivered with your copy of ISE. Search
the Xilinx directory for the simlation sources. Normally you compile
these sources to build your simulation library.

If you don't like the original simulation model, just write your own one

:)

But if your problem is asynchronous inputs that cause many 'X' in

simulation,

then I'd suggest searching the group on how to switch of x-propagation of

your

simulator.

BR
 
Brian Philofsky wrote:
Finding the right answer record is not always easy as there
is a lot of information available there but if you type in
the right key words, it generally comes out in the top few
and should not be too hard to find.
But nowhere near as easily as if you had a Google-style search
interface. Searching answers at X is absurdly difficult unless
you are in the priesthood.
 
Tim wrote:
Brian Philofsky wrote:

Finding the right answer record is not always easy as there
is a lot of information available there but if you type in
the right key words, it generally comes out in the top few
and should not be too hard to find.


But nowhere near as easily as if you had a Google-style search
interface. Searching answers at X is absurdly difficult unless
you are in the priesthood.
For me, it is generally not too difficult to find what I want there but
I generally have a good idea what to type to get it. In other words, I
have enough knowledge about what I am searching for to type in the
correct keywords and the practice using the system and understanding the
search tips (http://www.xilinx.com/support/tips.htm) to get the right
items to show up to the top (and I didn't even realize I have joined the
priesthood). I realize that I may not be the typical user of this
resource though so it is always good to hear from others. It is my
understanding that people within Xilinx are actively looking at the
search engine for improvements but what would help is a little more
information on how people are using it. If you are searching for
something and do not find it, spend a few moments to notify Xilinx about
this and give the specifics about how you were attempting to get that
information. Sending this feedback can be as easy as clicking on the
first Answer record that pops up, select the Feedback link and let them
know what you typed, what you are looking for, the fact you could not
easily find it and that this was the first answer record displayed but
unrelated to what you were trying to find. It is this specific
information that will likely best help in improving the search engine
more-so that just telling us it is difficult to find information. This
really should not take much time to do and hopefully that feedback will
improve the search in the future and end up giving back that time and
then some by better displaying the appropriate information more quickly.


-- Brian
 
But nowhere near as easily as if you had a Google-style search
interface. Searching answers at X is absurdly difficult unless
you are in the priesthood.
Doesn't real google work?

An amazing number of sites think their slow/dumb search kludge
is useful. I didn't think Xilinx had made that bluder. I know
I find lots of things on their site via google, but I'm not sure
about the answers section.

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

Welcome to EDABoard.com

Sponsor

Back
Top