SR latches in Xilinx devices?

Generally speaking you're asking for trouble when you try to make asynchronous sequential circuits using LUTs. You just can't force the tools to make the coverage terms for state transition. In most Xilinx parts you can use actual flip-flops to get SR's (see FDCP in the libraries guide).

Luckily, not an issue here - the standard cross-coupled NAND is already hazard-free (unless the mapper decides to reimplement it, which seems unlikely).

My main concern is trce - do you know if the timing analyser will trace through the the S/R ports on an FDCP? I can't see anything obvious in the documentation. Presumably it won't be able to handle explicit cross-coupled gates, though.

Rick

Hazard-free as long as the set and reset pulses are well formed and far enough apart in time. It's not difficult to make an oscillation burst otherwise.

-- Mike Treseler

Gabor's comment referred to, presumably, single-variable static hazards, and the cross-coupled NAND is already covered for this.

Oscillation isn't relevant here, because you can't noramlly solve for multi-variable dynamic hazards by adding terms. It's not difficult to make almost any async circuit oscillate by changing more than one input 'simultaneously'. That's why they're normally designed to allow only one input to change at a time, and why F/Fs have setup and hold requirements, for example. An SR latch has similar timing requirements on its 2 inputs.

Rick

"Mike Treseler" schrieb im Newsbeitrag news: snipped-for-privacy@individual.net...

After all, what is a RS-FF good for nowadays??

Regards Falk

The same things that it has always been good for. For a cost of 2 gates, it gives you a memory. It doesn't need a clock. It remembers an event until you have time to deal with it. It's ideal for handshaking, and for communicating between different clock domains. Can you name any other digital circuit which is so versatile, at such a small cost? Even if you ignore the 'cost', as you might do in an FPGA implementation?

Rick

"Richard Thompson" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

Uhhh? COST??? C'mon. In a FPGA, a handfull of Flipflops is always free. So why asking for trouble and doing stone age handshakes when there are proven solutions using standard methods (here, D-FlipFlops)? I wouldnt waste a nanosecond thinking of RS-FlipFlops made of gates.

Regards Falk

an

handshaking,

cost?

free. So

proven

Speaking of cost, is a LUT less costly than a flip-flop? In Xilinx Virtex parts, a LUT can be 16 flip-flops sometimes. Besides if you want both gate outputs from your cross-coupled NAND gates you need

Another thing to wonder about, is whether changing a single LUT input creates the same output transition as with the implemented gates. For example if the output is the same for both states of the switched input, a gate will never glitch, but will the LUT glitch? This may depend on the implementation of the output multiplexer.

Although this is not directly related to the current SR latches discussion, let me expose a problem that forced me to define a VHDL equivalent of the good old 7474 flip-flop made with NAND gates and a set of KEEP attributes on the signals.

Although it may be questionable to do so, once you try to synthetize a flip-flop with such an expression as "If Rising_Edge(Signal_In) Then ...", where Signal_In is not supposed to be a general clock at all, the synthesis tool generally reserves a global clock chain and buffer for just that purpose.

This may be a real problem if the number of times you want to do that (because for instance you need to have a very quick reaction on the rising edge of a signal) gets significant vs the number of available GCLK nets and buffers.

Pardon me if I am presently missing a very simple way to tell the tool "Please do not use one of your GCLK resources", but I am not a very frequent user of VHDL and had no chance to go to any advanced seminar of any kind.

A solution to that problem ?

Please answer if you are aware of some.

tool

Take a look at CLOCK_BUFFER in the constraints guide. You can set the attribute CLOCK_BUFFER to "none" for a signal to prevent automatic insertion of global resources.

Consider a synchronous design. That uses just one GCLK net and provides quick delivery to every flop in the design.

-- Mike Treseler

An interesting point, which has come up on various occasions over the years; I recall Peter Alfke posting on this occasionally. The answer (at least pre-Virtex, I don't know if it has changed recently) is that you dont get a glitch when changing one input on a LUT (or so Xilinx claims). The mux is a break-before-make, but the circuit ensures that you only switch between two flops, and the stray capacitance holds the old value.

This thread has (from my point of view, anyway) degenerated somewhat. My concern was getting trce to report an asynchronous path through a latch, of unspecified, or any, design. I pointed out what an RS F/F was, simply because it doesn't seem to be general knowledge any more. Its simplest representation is two cross-coupled gates, but most of us know that you can implement it in several other ways. The VHDL/Verilog code that I use synthesises to a flop, as you suggested, and as would be expected; no synth is going to produce cross-coupled gates. My post led to an irrelevant series of other posts (not from yourself) suggesting that R/S latches are of no use and obsolete and, by implication, that I don't know what I'm doing.

On the issue of cost, perhaps those who think that that an R/S is obsolete should try designing a two-way handshake between two clock domains, and then report back on the relative cost of the two approaches, taking into account total resource usage, and design and verification time.

Rick

"Richard Thompson" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

;-)) Trying to reinvent the wheel? I hope you have a VERY good idea whow to make it rounder. I guess the problem is, that many engineers think the could build clever handshake cicuits for asynchronous interfaces by having a flashy idea and lots of homebrew circuits from the good old TTL era in the head. This approach fail often enough, I guess. Dont get me wrong, I dont say you cant design such a circuit (I dont know, maybe maybe not), but Iam afraid there are lots of asynchronous wanna-bees. So again, why reinventing the wheel? In a FPGA, you have the same amount of FF as LUTs. No gain in using RS-FFs made by cross coupled NANDs. This is even more true for CPLDs, I guess it takes two macrocells to make a RS-FF out of logic (and works maybe only be using WYSIWYG switch ON). Again, no saving. And there are proven, small circuit for such handshaking using standard, supported design methods. Again, what do you gain, except the outlaw-feeling ?? ;-)

Regards Falk

I'm not quite sure what point you're making, or what you think it is I actually wrote. But, since you're so smart, can you tell me whether a D F/F is a synchronous or an asynchronous device?

Rick

Since I was quoted: Yes, the old explanation still holds true: If you change one LUT input, and the output before and after that change is the same, then there will be no glich (ever). More generally, even when you change more than one input, but the output for all permutations of these inputs is the same, there can be no glitch. That's guaranteed by the way the multiplexers in the LUT are designed. Peter Alfke, Xilinx Applications

"Richard Thompson" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

I got your statement the way, that there are still a need and use for RS-Flipflops made of NANDS in FPGAs. I dont think so. And I gave explainations.

;-) Asynchronous, but well defined. But this doest mean that you should created more asynchronous stuff.

Regards Falk

(snip)

I would say it isn't the device, but how you use it.

You can make ripple counters or synchronous counters our of DFFs, and with a two-phase clock, synchronous logic our of RS flip-flops. Does anyone remember when two phase clocks were popular any more? (I believe the TMS9900 even has a four phase clock.)

-- glen

If you are using synplify, you can use the syn_noclockbuf constraint.

Jeremy