I'm writing my first bit of mildly nontrivial Verilog. It's a controller for a sort of combination boxcar and lock-in, with a few bells and whistles. (The lock-in runs for exactly N cycles, with nonoverlapping switch waveforms with enough dead zone for the amps to settle, and then holds the final value.)
To make the control inputs well-behaved, I'd like to make them ones-catching, i.e. clock 1 into a register when they arrive, and reset it when a state machine gets to the right point.
Den fredag den 11. april 2014 21.45.26 UTC+2 skrev Phil Hobbs:
VHDL wouldn't help you
it's hard to tell exactly what you want to do but;
you should generally register your inputs through a FFs or two before you use them to avoid(reduce) the risk of meta-stabilty sending your state machine to lala-land
you should think about what hardware you have, a ff with clk and rst it can't be sensitive to the edges of more than two signals
can your "Go" signal be less that a clk cycle wide?
The whole register it with FF thing helps with metastability: you basically clock the input through a short shift register; if the input is at half-mast when the clock happens, then by the time it gets through a couple of flip flops (so the theory goes) it has resolved into a firm zero or one, and you don't end up with a bunch of bits that are hanging in the middle somewhere.
Xilix et all deny the possibility that metastability could be a problem with their parts. Nearly everyone that I know who does FPGA design uses the chain-o-ff trick. Pick your poison.
I've used that in the past, both in MSI and in the DOS Orcad PLD tools. It's really that I'm just learning Verilog, and don't know the syntax quirks very well yet. Xilinx's cryptic error messages aren't much help.
Sounds analogous to the syntax differences between VHDL's combinatorial _architecture_ block, and the _process_ block that can go within. You can do the same things with the same signals, but the latter is written as a procedural conditional (which makes edge triggered logic possible, or at least, easier).
Something else that would be tempting might be a dual-clocked FF (like PC3 in the... HC4046 or 7046??), which could be described as:
process (clk1, clk2) begin if (clk1'event and clk1='1') then q = '1'; elsif (clk2'event and clk2='1') then q = '0'; end if; end process;
But most (all?) tools will not synthesize this due to the dual edge dependency.
You have to work around such situations by describing the combinatorial logic yourself (two D's and an RS, for example). Which will of course be much slower than a single cell synthesis (assuming they provided dual clocked FFs in the standard cells).
Afraid I only have experience in VHDL, so if this was helpful at all, I don't know. :p
afaiu the Xilinx point is that the FFs are so fast that it is extremely rare a FF will take longer to resolve metastability than any realistic clock
So the output of FF will have resolved to a firm 0/1 long before the next clock edge, so FFs after that first FF will "never" see anything but a firm 0/1 with plenty of setup time
It is not metastability that is the problem. It is the possibility of a signal changing at some random time relative to your clock. In a state machine, an external signal can decide whether you go to state 21 or 22 when in some particular state. If that input were to change such that some of the state registers got the new value and some the old because the change was within the setup time for those FFs, you could end up being thrown into some random state. If a one-hot state machine, you could end up with multiple bits set. On a binary coded state machine, you could just end up in an odd state.
The timing tools will guarantee that anything clocked internally will satisfy setup and hold times on every FF on the chip, so when some signal changes, it guarantees that ALL FFs that need that signal will get the same value. But, when an un-synchronized input comes in, the tools can't handle that.
Now, if you can demonstrate your logic fails with a SINGLE rank FF on the inputs, but runs reliably with DUAL rank FFs, then it sounds like metastability. But, NO FFs on inputs going into anything clocked is pure trouble.
much better, once you skip all the async edge triggered stuff and run everything on a single clock it is much easier to prove that it works
yeh, sometimes the resemblance to C can trick people to think that it is a programming language like C. It is not, it is a hardware description language and if you want it to be synthesisable you need to describe something that is realizable in the available hardware
Those two chunks of code aren't equivalent though, if any of varx are vectors rather than single bits.
if (var) ...
is a boolean test, equivalent to the C boolean tests: if all bits of the the argument (var) are zeros, it's false, otherwise true.
The "bar" operator | is a bit-by-bit or. It returns a vector of bits, with length equal the maximum length of its arguments. Each bit of the result is equal to the or of the corresponding bits of the inputs. (If any of the inputs is short, it is zero extended on the left.) If you then assign this to a single bit variable, it will throw away all but the least significant bit of the result. (This happens silently, and can cause hard to find bugs.)
The || operator is a boolean or. If either argument is true (i.e. contains any 1 bits) it will return true (a single 1).
I suggest you read up on the differences between:
~ (bitwise not) and ! (boolean not) & (bitwise and) and && (boolean and) | (bitwise or) and || (boolean or)
Whist I don't think this has anything to do with the tool "puke" problem, it is something that is important to understand when starting with Verilog.
I would be very surprised if XST couldn't handle that statement. I suspect that there's more going on in your source code that can be determined from your post.
Also, XST is a family of compilers. Different parsers are used depending on the target device and the ISE version.
So...
Are you able to post a larger chunk of source code?
What is the exact error message?
Could you identify the target device?
What is the ISE version?
What do tools other than XST say about the code? I always simulate in Modelsim before letting the (relatively braindead) Xilinx tools see the code. In general synthesisers (e.g. XST) interpret the language reference manual rather loosely, and simulators (particularly the "big
Differences between e.g. C lang and Verilog statements. there are no clean rules broken with that style ... as long as you know exactly what you are doing.
It has a state machine already, for something else. I solved it by moving the goal posts--the asynchronous signals have to be valid long enough to include a rising clock edge, rather than using ones-catching inputs. Then they go into a 3-stage shift register,
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.