FDE vs latch?

It's usually harder to meet Static Timing Analysis with latches. They are as troublesome as a very troublesome thing. If you think you need to use one, think again.

--------------------------------------- Posted through

"RCIngham" wrote in message news:kt-dnRe2Lb2cTi7SnZ2dnUVZ snipped-for-privacy@giganews.com...

In this particular case, it's grabbing a rather large 100 ns tick count, to inject into a message as a timestamp later. Timing isn't an issue. The only concern was relative space efficiency. There seems no difference between a latch and FDE, eating up a slice every 2 bits.

I "solved" the other problem of serializing the multi-word timestamps by sending 8-bit counts after the first full timestamp. The question remains, though, how to efficiently byte-serialize the large data word. I hate to hand write a state machine to do this, for every word size I might encounter. Shifting the latched value seems unnecessarily painful.

Rotating a single hot bit in a surrogate shadow word, one bit representing a data byte, seems so far the best solution, but I can't dream up a way to generate the required statements to go with it. Rotating the surrogate mask effectively makes for a cheap, easy one-hot FSM, but I don't have the language skill to generate the corresponding:

with vmask select dout

WRT latches: With FDE, all timing paths start and/or end at the FDE. With a latch, they don't (e.g. when the latch is transparent). This makes for many more false paths, etc that cause STA to be very conservative, to the point that you often cannot meet timing unless you use a lot of false path constraints. The problem with those is that they (the constraints) are inherently very difficult to verify (that they are correctly stated and applied) except by inspection and manual analysis.

Also some (most) FPGA architectures do not have a latch primitive, but use a macro built from one or more LUTs. These circuits are notoriously glitchy in the presence of two or more inputs changing simultaneously, especially likely since upstream logic is often merged into the same LUT. Unless very carefully designed around, this can cause latches to unlatch even though the enable did not change.

Short version: it hurts when you do that.

WRT your function. If the i argument is known at synthesis time (this includes the index of a for-loop), then no hardware is synthesized at all, just wires. Otherwise, it will just be multiplexers, with no adder or multiplier (multiply/divide by power of two is just a shift, and the addition of 7 to a number that is already known to have zeroes in the least three bits does not take an adder, just a lut that always outputs 1, which may be shared with others, and some more wires).

I do not understand your last question.

Andy

Doh! A for loop does seem the obvious answer. Does that synthesize in a clocked process?

Thanks.

It does if it's synthesizable.

More specifically, if the loop can be unrolled into some mess of combinational logic, then that logic can be placed in front of a register, and the for loop can be synthesized. If there is no combinational logic that would generate that function (or if there is, but it's enormous, e.g. a divider) then you can't synthesize it.

A counter and an array of bytes, rather than a shift mask and whatever, was the trick. It synthesized to a counter and a big mux. Thanks for the help.

do_vcount : process (clk) ...

v_out