simprim X_FF component

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.

Reply to
Chao
Loading thread data ...

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!

Reply to
Niv

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.

Reply to
Chao

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

Reply to
Gary Michels

:-)

simulation,

your

Reply to
Barry Brown

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:

formatting link
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
formatting link

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:

Reply to
Brian Philofsky

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.

Reply to
Tim

Tim wrote:

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

formatting link
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

Reply to
Brian Philofsky

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.
Reply to
Hal Murray

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.