Qestion about the ability of synthesis

Maybe the "ability" is not correct or accurate. After synthesis, the simulation should reflect the reality of FPGA. But, the initial value of counter is "0000". After the first clock rising edge, its content is "00X0". It seems the simulation does not know the correct value even it did know the first value is "0000".

Thanks.

fl wrote:

The simulation (or the simulator) does exactly what you you tell it to do. You need to know why your design doesn't calculate the first count correctly and fix it.

I mean, I don't care about the absolute initial value of the counter. I think it indeed there are such cases in reality (although it is only a redundant activity to reset the counter to some value). I want to understand the capability of synthesis software a little more here. I have to program adhere to its requirement. I increase the step of the counter from 1 to 2, it is correct. But, it seems reset is necessary to obtain a correct counter. For shift register, some Xilinx chips have a structure which is very efficient but without a reset function I remember. Thank you.

The second one is incorrect because it does not be explicitly reset and you are getting 'lucky' in the behavioural sim because the simulator is initializing the value of count to 0 for you whereas in 'the real world' you generally don't get this behaviour (unless the device explicitly guarantees you some 'powerup default' value. Had you used 'unsigned (3 downto 0) instead of 'integer' for the signal count, the initial value assigned by the simulator would be 'U' (undefined) and it might have been clearer about why the reset is necessary.

Having said that though, I am at a bit of a loss to explain why the post-synthesis sim got the initial value of '0000' correct (I would've expected it to be 'UUUU' but in any case you do need a reset.

Another oddity is the counting by 2 and init to 0 which implies that the counter will never reach a value of that will cause it to get reset to 0 properly in your behavioural sim....did you test this? When the count tries to go from 14 to 16 you should get a fatal sim error because count goes out of it's defined range of 0 to 15.

Although integer and their subtypes are in many cases a more 'natural' expression of what you're trying to accomplish, you do have to be a bit more diligent about making sure that things that get feedback (like counters) get explicitly reset or you'll run into cases exactly like this where the pre-route simulation works but does not match post-route.

Until you master this, you might consider using the 'numeric_std' package to do your arithmetic operations. With that package, when you don't explicitly reset things they will be undefined (i.e. 'U') and it will be easier to see that you got the design correct.

KJ

Hi,

fl schrieb:

I consider a design without a reset as bad for myself, but using Xilinx Fpga without a reset should be no problem. A 00X0 after the first rising edge with 0000 before the first rising edge indicates often a timing problem. Check timing analyses if your design achievs the applied clock frequency. Else check, where your X is comming from.

bye Thomas

fl wrote:

Hei,

i checked your design with the ISE 8.2 and simulated both versions. I did not get any undefined values but with a post-synthesis simulation you should not get an undefined value since the flip-flops are all initialized. This one can see in the netlist created by netgen. If you see an X then it could be a timing problem since. Also KJ was right that you'll run into error during simulation if you try to compile the design directly in Modelsim or another simulator. Your design will never reach the 15 and 16 is out of range. The post-synthesis model works cause the synthesizer is smart enough to limit your counter to 4 bit (3 bit since the last bit is stuck to 0) and what happens is that you'll get a wrap-around. So 16 will be "10000" and since your counter has only 4 bit you'll get a "0000". This result you can also see in the RTL viewer of the ISE software. There are a few pitfalls in doing VHDL design and one is not to initialize counters or FSMs. So there should always be a reset. Some devices have the ability to "wake-up" with a default value which can normally be specified by generics or attributes. This you'll have to look up in the documentation of the target device. Another thing is that i would try to avoid to compare values with "greater " or "lower" than a value. This can increase your logic since the synthesizer has to synthesize all this cases. In your case i would just compare my value to "14" and then do the wrap-around. There is no need to compare values larger than 14 since the result of the counter should always be well defined. If you'll get a number greater than 14 than something in your design is very fishy...

Good luck! Torsten

Torsten Alt schrieb:

I disagree. Using '=' for counters may decrease your logic but may also increase your logic[1]. But it will always be a pitfall, if your counter value gets over (for inc-counter, else under)) the value your looking for, due to any reason. I just had to remove a bug from a co-designer basing on this pitfall.

For a simple counter there are only external reasons like SEU that will lead to this pitfall, in complex designs, there might be a erroneous written if-then-else path leading to the situation were your counter waits forever.

bye Thomas

[1] A 8 bit '=' needs 15 XOR2. A 8 bit '> 127' is free in terms of gates.

Having seen almost every error one can make with counters, I prefer free-running counters with reload logic. This implies that the counter can never get "stuck". If, for some reason, the counter manages to enter an illegal state, it will self-correct. This usually implies that at least a small period will be garbage, but the system won't fail.

Also, while it sometimes it does make sense to make a counter 1 bit wider than the actual count, and use the MSB as a reload signal, you have to be careful. If you exceed the maximum length of a carry chain, the P&R tools will break the counter up, and you may lose more performance than if you had made the counter the exact width.

Of course, with most of my designs the reload value is never a power of

2, or the counter is under software control, so I typically write them the "normal" way anyway.

Thomas Stanka schrieb:

Hei,

a 8 bit "=" needs at maximum 7 AND2 and 7 INV not 15 XOR2. And of course is a compare larger 2^n-1 always for free since you only have to check the n-bit. But this is a special case. In most cases your logic will increase. On can calculate it theoretically by dividing a n-bit comparator into m n/m-bit comparators + the glue logic. So for a 16-bit comparator one can split it into 2x8-bit or 4x4-bit or 8x2-bit. The size of the splitting can be adapted to the width of the LUTs in case of an FPGA.

SEU are a different story but if this can happen in your environment then the counter is your smallest problem.

The point with complex designs and if-else paths are that i would simply not use nested and long if-else paths cause you leave the implementation of your design to the synthesis tools. They are pretty good if it comes to standard design elements like comparators, counters, registers etc. But they are pretty bad if it comes to synthesize VHDL code which is written like C. Also your design will be prone to latches if you don't take care about the path coverage.

The method of radarman is a nice one. Compare equal to a value and take a MSB as a security check to reinitialize the counter in case something went wrong.

Bye, Torsten

You've got to make a pretty big counter before synthesis breaks it up.

The MSB to reload trick actually works quite well, even for non-power-of-2 and programmable counters. The trick is to load the counter with the complement of the count (or load it with the count and decrement). It is nice because it provides a direct decode of the terminal count and can be accomplished in one layer of logic if the load value is computed correctly.

Hi,

Torsten Alt schrieb:

Your right, I was a bit fast in writing and slow in thinking ;).

But definitiv not all. Even a 4 bit > 9 uses less logic as 4 bit = 9 for most technologies. The logic may increase and may decrease. In most cases you don't even bother thinking about the size of your logic. And I guess you won't find 5 designers reading this news, with designs were you really had to squeeze each single gate (anyone else here with 100% resource usage? :).

:) Actually not. If you have to consider SEU, you usually have easy technologies to prevent Errors. But blocking counter and FSM are even worse in case of SEU, because you have to consider every possible value for each FF in case of multiple Upsets. Nevertheless, blocking counter and FSM are also thread to designs without considering SEU.

There are steps between C-Style code and simple designs using only straight forward code. For most of my designs I think afterwards I should have used more abstract possibilities of describing my code, instead of using relative low description levels.

bye Thomas

This threw me for a bit, then I realized you're comparing

8 bits with a constant value, not two 8 bit registers.

-Dave

--
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

Actually wouldn't you need 7 AND2 and 8 INV if you're comparing to 0?

-Dave

--
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

If you are comparing your 8-bit count value to a constant, it can be handled in two levels of logic. Remember, you don't use up an input when you are comparing with a constant, the constant becomes part of the truth table, so you use all four inputs for the counter input. This is why it is preferable to (pre)load an up/down counter, and compare against a constant to reload/stop generate a terminal count signal.

There are times when you have to compare the counter with a register, but they are fairly rare in my experience. Typically, you can avoid the vast majority of these cases with careful design.