Infer RS FlipFlop

S

Scott Gravenhorst

Guest
I'm just curious, I occasionally use RS flipflops in my Verilog FPGA
designs, but I've never found a way to infer them.

Is there a way to infer an RS flipflop as opposed to instantiating a
primitve for a D flipflop with asynchrous preset and asynchronous
clear?

Thanks.
 
On Dec 10, 9:57 am, no.s...@gte.net (Scott Gravenhorst) wrote:
I'm just curious, I occasionally use RS flipflops in my Verilog FPGA
designs, but I've never found a way to infer them.

Is there a way to infer an RS flipflop as opposed to instantiating a
primitive for a D flipflop with asynchronous preset and asynchronous
clear?

Thanks.
Click to expand...
Most people try NOT to infer latches! :)

always @ (set,clear)
if (set)
r = 1'b1;
else if (clear)
r = 1'b0;

AL
 
On Wed, 10 Dec 2008 09:29:55 -0800 (PST)
LittleAlex <alex.louie@email.com> wrote:

Is there a way to infer an RS flipflop as opposed to instantiating a
primitive for a D flipflop with asynchronous preset and asynchronous
clear?

Thanks.

Most people try NOT to infer latches! :)
Click to expand...
I second that. Does the FPGA that you are targeting actually has RS FF
in its macro library? If it doesn't, then you shouldn't be using RS FF.
If it does, then you should always use the macro directly.

I have seen examples of designs where the designer ASSUMES RSFF is
supported by the library when in fact it doesn't. In the end, a bad
latch design is created that sometimes cause race conditions.

--
I used to work in a fire hydrant factory. You couldn't park anywhere
near the place.
-- Steven Wright
 
On Dec 10, 12:51 pm, Jason Zheng <Xin.Zh...@jpl.nasa.gov> wrote:
On Wed, 10 Dec 2008 09:29:55 -0800 (PST)

LittleAlex <alex.lo...@email.com> wrote:
Is there a way to infer an RS flipflop as opposed to instantiating a
primitive for a D flipflop with asynchronous preset and asynchronous
clear?

Thanks.  

Most people try NOT to infer latches!  :)

I second that. Does the FPGA that you are targeting actually has RS FF
in its macro library? If it doesn't, then you shouldn't be using RS FF.
If it does, then you should always use the macro directly.

I have seen examples of designs where the designer ASSUMES RSFF is
supported by the library when in fact it doesn't. In the end, a bad
latch design is created that sometimes cause race conditions.

--
I used to work in a fire hydrant factory.  You couldn't park anywhere
near the place.
                -- Steven Wright
Click to expand...
The RS latch is the easy case. What the OP wants is a D flip-flop,
i.e. clocked device with separate async set and reset like a 7474.

I'm pretty sure you can model this, but not without at least two
always blocks, so I don't think a typical synthesis tool will accept
the model code to infer the flip-flop.

I you have the Xilinx tools there should be source for a model in
the $Xilinx$\verilog\src\unisims folder. The flop you want is
FDCP (D flip-flop with async clear and preset).

The model has one always block for reset / preset. another for
clocked operation. I'm pretty sure it won't get through
synthesis.

Regards,
Gabor
 
On Wed, 10 Dec 2008 12:07:39 -0800 (PST)
gabor <gabor@alacron.com> wrote:

The RS latch is the easy case. What the OP wants is a D flip-flop,
i.e. clocked device with separate async set and reset like a 7474.
Click to expand...
You need to read OP again. He does NOT want DFF with async set and
reset.

I'm pretty sure you can model this, but not without at least two
always blocks, so I don't think a typical synthesis tool will accept
the model code to infer the flip-flop.
Click to expand...
The problem isn't so much with the modeling. If you write something in
RTL that models RS latches, and the target platform does not support
it (most FPGA don't), synthesis tools somethings tries to map to the
closest thing they can get, which could indeed be wrong. The worst
thing that a synthesis tool can do is to do this without warning the
user, or that the user forget to check the synthesis warnings.

--
I used to work in a fire hydrant factory. You couldn't park anywhere
near the place.
-- Steven Wright
 
On Wed, 10 Dec 2008 12:07:39 -0800 (PST)
gabor <gabor@alacron.com> wrote:

I'm pretty sure you can model this, but not without at least two
always blocks, so I don't think a typical synthesis tool will accept
the model code to infer the flip-flop.
Click to expand...
On second thought, you can't model this with two always blocks without
getting undeterministic results. Think about the case where set and
reset occuring simultaneously.

--
I used to work in a fire hydrant factory. You couldn't park anywhere
near the place.
-- Steven Wright
 
On Wed, 10 Dec 2008 12:07:39 -0800 (PST), gabor <gabor@alacron.com>
wrote:

On Dec 10, 12:51 pm, Jason Zheng <Xin.Zh...@jpl.nasa.gov> wrote:
On Wed, 10 Dec 2008 09:29:55 -0800 (PST)

LittleAlex <alex.lo...@email.com> wrote:
Is there a way to infer an RS flipflop as opposed to instantiating a
primitive for a D flipflop with asynchronous preset and asynchronous
clear?

Thanks.  

Most people try NOT to infer latches!  :)

I second that. Does the FPGA that you are targeting actually has RS FF
in its macro library? If it doesn't, then you shouldn't be using RS FF.
If it does, then you should always use the macro directly.

I have seen examples of designs where the designer ASSUMES RSFF is
supported by the library when in fact it doesn't. In the end, a bad
latch design is created that sometimes cause race conditions.

--
I used to work in a fire hydrant factory.  You couldn't park anywhere
near the place.
                -- Steven Wright

The RS latch is the easy case. What the OP wants is a D flip-flop,
i.e. clocked device with separate async set and reset like a 7474.
Click to expand...
That's what the Xilinx Spartan family FDCPE primitive is. That is the
primitive that I use for this purpose. I just ground the clock, data
and clock enable inputs. I was really just looking for a more
universal way to express the logic, to infer it. The WebPACK ISE
(10.1) language template shows code to infer a D FF with either an
asynch clear or an asynch preset, but not both.

I'm pretty sure you can model this, but not without at least two
always blocks, so I don't think a typical synthesis tool will accept
the model code to infer the flip-flop.

I you have the Xilinx tools there should be source for a model in
the $Xilinx$\verilog\src\unisims folder. The flop you want is
FDCP (D flip-flop with async clear and preset).

The model has one always block for reset / preset. another for
clocked operation. I'm pretty sure it won't get through
synthesis.

Regards,
Gabor
Click to expand...
 
On Dec 10, 3:29 pm, Jason Zheng <Xin.Zh...@jpl.nasa.gov> wrote:
On Wed, 10 Dec 2008 12:07:39 -0800 (PST)

gabor <ga...@alacron.com> wrote:
I'm pretty sure you can model this, but not without at least two
always blocks, so I don't think a typical synthesis tool will accept
the model code to infer the flip-flop.

On second thought, you can't model this with two always blocks without
getting undeterministic results. Think about the case where set and
reset occuring simultaneously.

--
I used to work in a fire hydrant factory.  You couldn't park anywhere
near the place.
                -- Steven Wright
Click to expand...
Actually set and reset are in the same block, it's the clock that
goes in the other block. In any case, set and reset have a
predetermined priority to match the hardware. Releasing set and
reset simultaneously may be bad, but so is a clock edge too soon
after release of reset or set. The hardware has obvious setup and
hold requirements to meet in a real design, and these can be modeled
as well. The problem with inference in this case is that synthesis
wants to find all assignments in a single always block or it gets
a "multi-source" error. You can do it in one block in VHDL, but
not in Verilog.
 
Jason Zheng wrote:

On Wed, 10 Dec 2008 09:29:55 -0800 (PST)
LittleAlex <alex.louie@email.com> wrote:
Click to expand...
(previously snipped, but Scott wrote)

Is there a way to infer an RS flipflop as opposed to instantiating a
primitive for a D flipflop with asynchronous preset and asynchronous
clear?

I second that. Does the FPGA that you are targeting actually has RS FF
in its macro library? If it doesn't, then you shouldn't be using RS FF.
If it does, then you should always use the macro directly.

I have seen examples of designs where the designer ASSUMES RSFF is
supported by the library when in fact it doesn't. In the end, a bad
latch design is created that sometimes cause race conditions.
Click to expand...
As far as I know, you just need NAND or NOR gates to make
an RS flip-flop, so using CLB logic should work just fine.

You can't easily build an edge triggered FF with CLB logic,
which may be one reason FPGAs like to supply them.

Getting the timing right will require some work, and routing
delay will likely limit the speed.

-- glen
 
On Thu, 11 Dec 2008 09:04:43 -0700
Glen Herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

As far as I know, you just need NAND or NOR gates to make
an RS flip-flop, so using CLB logic should work just fine.
Click to expand...
Which requires you to use macros and write structural HDL as I
suggested. Unless I am mistaken, I don't think you can you construct RS
FF using RTL without the synthesis tool complaining about combinational
logic loops.


--
A possum must be himself, and being himself he is honest.
-- Walt Kelly
 
On Wed, 10 Dec 2008 12:25:49 -0800, Jason Zheng
<Xin.Zheng@jpl.nasa.gov> wrote:

On Wed, 10 Dec 2008 12:07:39 -0800 (PST)
gabor <gabor@alacron.com> wrote:

The RS latch is the easy case. What the OP wants is a D flip-flop,
i.e. clocked device with separate async set and reset like a 7474.


You need to read OP again. He does NOT want DFF with async set and
reset.
Click to expand...
Actually, that works fine - I really don't care what primitive ISE
infers, as long as it acts like an RS flip-flop. That's why I've been
using the FDCPE primitive, but I've been instantiating it directly.
In fact, I've tried creating an RS flipflop with 2 cross coupled NOR
gates using gate level synthesis and that works, but it seems there
should be an easier way to infer the functionality of an RS flip-flop.

I'm pretty sure you can model this, but not without at least two
always blocks, so I don't think a typical synthesis tool will accept
the model code to infer the flip-flop.

The problem isn't so much with the modeling. If you write something in
RTL that models RS latches, and the target platform does not support
it (most FPGA don't), synthesis tools somethings tries to map to the
closest thing they can get, which could indeed be wrong. The worst
thing that a synthesis tool can do is to do this without warning the
user, or that the user forget to check the synthesis warnings.
Click to expand...
Ah. In other words, I should simply instantiate it as I've been doing
to avoid any synthesis confusion. The only problem I have with
instantiations of primitives is that much of what I do is "open" and
instantiated primitives won't port directly to mfrs of FPGAs other
than the one(s) I use. I always comment my code, so these instances
of FDCPE have clear comments indicating that I am using the FDCPE as
an RS.
 
On Dec 11, 11:46 am, Jason Zheng <Xin.Zh...@jpl.nasa.gov> wrote:
On Thu, 11 Dec 2008 09:04:43 -0700

Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
As far as I know, you just need NAND or NOR gates to make
an RS flip-flop, so using CLB logic should work just fine.

Which requires you to use macros and write structural HDL as I
suggested. Unless I am mistaken, I don't think you can you construct RS
FF using RTL without the synthesis tool complaining about combinational
logic loops.

--
A possum must be himself, and being himself he is honest.
                -- Walt Kelly
Click to expand...
Actually using CLB logic, i.e. LUT's is not a good idea
for building asynchronous sequential logic. The OP's idea
was to infer an available RS flip-flop structure, not to
build one out of "gates". One problem with building sequential
logic from gates in an FPGA is that it is not always obvious
that your LUT will have the hold terms after optimization.
 
On Thu, 11 Dec 2008 18:44:14 GMT
no.spam@gte.net (Scott Gravenhorst) wrote:

On Wed, 10 Dec 2008 12:25:49 -0800, Jason Zheng
Xin.Zheng@jpl.nasa.gov> wrote:

On Wed, 10 Dec 2008 12:07:39 -0800 (PST)
gabor <gabor@alacron.com> wrote:

The RS latch is the easy case. What the OP wants is a D flip-flop,
i.e. clocked device with separate async set and reset like a 7474.


You need to read OP again. He does NOT want DFF with async set and
reset.

Actually, that works fine - I really don't care what primitive ISE
infers, as long as it acts like an RS flip-flop. That's why I've been
using the FDCPE primitive, but I've been instantiating it directly.
In fact, I've tried creating an RS flipflop with 2 cross coupled NOR
gates using gate level synthesis and that works, but it seems there
should be an easier way to infer the functionality of an RS flip-flop.
Click to expand...
/*shakes head*/ You should ALWAYS care about what primitives ISE (or any
other synth. tool) infers from your HDL code. The nastiest bugs are the
ones that work 99% of the time, but fail 1% of the time that you don't
anticipate. Take the following code for example:

always @ (set or rst)
if (set & !rst) Q <= 1;
else if (rst & !set) Q <= 0;

A possible way to implement this is an RS-FF (although some may point
out that this is not the best way to implement it). But it could also
be synthesized to a gated latch represented by the following HDL:

wire g = set ^ rst;
wire d = set & ~rst;

always @ (g or d)
if (g) Q <= d;

RTL simulation will show that the two are equal. But which one do you
really want? Only you would know. The only sure way to guarantee that's
what you will get is through macro instantiation. Sure you'll lose
portability, but that's the price to pay when your design involves
something that not all platforms support.
 
On Thu, 11 Dec 2008 10:47:52 -0800 (PST)
gabor <gabor@alacron.com> wrote:

One problem with building sequential
logic from gates in an FPGA is that it is not always obvious
that your LUT will have the hold terms after optimization.
Click to expand...
Macro instantiations (and further with syn_keep attribute) will hold
through synthesis and cell mapping. But your point about building RS-FF
out of LUT is valid. I wouldn't do it unless a true RS latch marco is
provided by Xilinx.
 
On Thu, 11 Dec 2008 18:44:14 GMT, no.spam@gte.net (Scott Gravenhorst)
wrote:

On Wed, 10 Dec 2008 12:25:49 -0800, Jason Zheng
Xin.Zheng@jpl.nasa.gov> wrote:

On Wed, 10 Dec 2008 12:07:39 -0800 (PST)
gabor <gabor@alacron.com> wrote:

The RS latch is the easy case. What the OP wants is a D flip-flop,
i.e. clocked device with separate async set and reset like a 7474.


You need to read OP again. He does NOT want DFF with async set and
reset.

Actually, that works fine - I really don't care what primitive ISE
infers, as long as it acts like an RS flip-flop. That's why I've been
using the FDCPE primitive, but I've been instantiating it directly.
In fact, I've tried creating an RS flipflop with 2 cross coupled NOR
gates using gate level synthesis and that works, but it seems there
should be an easier way to infer the functionality of an RS flip-flop.
Click to expand...
Have you tried that obvious, ie :

reg srff;

always @(set, rst)
begin
if (set)
srff <= 1;
else if (rst)
srff <= 0;
end

If you don't like the set priority, you can reverse the conditional
assignment order to get rst priority (and make sure that it is
equivalent to the SR latch you have in your library if there is one if
you want any hope of mapping to it). Of course this won't get mapped
into a DFF with async R/S inputs but a most probably a combinational
loop. One thing you have to pay attention to is that if the library
has a transparent latch as a cell and if that gets inferrred you might
get into hold timing because of a race so you have to declare the gate
input of the latch cell as a clock to check timing.

Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services
http://www.dspia.com
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top