Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > SR Flip Flop

Reply
Thread Tools

SR Flip Flop

 
 
Nirav
Guest
Posts: n/a
 
      09-09-2007
Hello Everybody,

I'm the student of Electronics and Communication Engineering and
finding a problem in implementing SR Flip flop on VHDL Platform, using
Quartus 7.1 tool. Please help me out.

I've made a few programs for that but in all those I'm finding same or
other Problem or not perfect output, Can you please let me know where
I'm making this mistake ??

1st Program :

library IEEE;
use IEEE.STD_LOGIC_1164.all;

entity RSFF_NRK is
port(s,r,clk : in BIT ; q,qbar : buffer BIT);
end RSFF_NRK;

architecture RSFF_NRK_ARC of RSFF_NRK is
begin

process(clk)
begin

if (clk'event and clk = '1') then

if( r = '1' and s = '0' ) then

q <= r nor qsbar;
qs <= r nor qsbar;

qbar <= s nor qs;
qsbar <= s nor qs;

elsif(s= '1' and r = '0') then

qbar <= s nor qs;
qsbar <= s nor qs;

q <= r nor qsbar;
qs <= r nor qsbar;


elsif(s = '1' and r = '1') then

q <= '1';
qbar <= '1';

end if;

end if;

end process;

end RSFF_NRK_ARC;

Here the program runs well but its RTL schematic shows a very large
circuit instead of having only 2 gates.

2nd Program :

library IEEE;
use IEEE.STD_LOGIC_1164.all;

entity RSFF_NRK is
port(ip : in std_logic_vector (1 downto 0); clk : in BIT ; q,qbar :
out BIT);
signal qs,qsbar : BIT;
signal sel : INTEGER;
end RSFF_NRK;

architecture RSFF_NRK_ARC of RSFF_NRK is
begin

process(clk,ip)
begin

if (clk'event and clk = '1') then


case ip is

when "00" => sel <= 0;
when "01" => sel <= 1;
when "10" => sel <= 2;
when "11" => sel <= 3;

end case;

if(sel = 1) then

q <= ip[0] nor qsbar;
qs <=ip[0] nor qsbar;

qbar <=ip[1] nor qs;
qsbar <=ip[1] nor qs;

elsif(sel=2) then

qbar <=ip[1] nor qs;
qsbar <=ip[1] nor qs;

q <=ip[0] nor qsbar;
qs <=ip[0] nor qsbar;

elsif(sel=3) then

q <= ip[1] ;
qbar <= ip[0] ;

end if;


end if;

end process;

end RSFF_NRK_ARC;

Here, I've made the program but ip[_] is not being supported, always
at this point I'm given an error report.

3rd Program :


library IEEE;
use IEEE.STD_LOGIC_1164.all;

entity RSFF_NRK is
port(s,r,clk : in BIT ; q,qbar : out BIT);
end RSFF_NRK;

architecture RSFF_NRK_ARC of RSFF_NRK is
begin

process(clk)
begin

if (clk'event and clk = '1') then

if( r = '1' and s = '0' ) then
q <= s;
qbar <= r;
elsif(s= '1' and r = '0') then
qbar <= r;
q <= s;
elsif(s = '1' and r = '1') then

q <= s;
qbar <= r;

end if;

end if;

end process;

end RSFF_NRK_ARC;

Here program works well but circuit becomes much a complex.

Please point out my error or let me have an alternate solution.

Nirav

 
Reply With Quote
 
 
 
 
beckjer
Guest
Posts: n/a
 
      09-10-2007
In program 1, (common problem in all 3 programs) add an 'else'
statement to complete all the transistions. Leaving off the else
clause can make for some large and messy circuits. A simple fix is:
if your_happy = '1' AND youknowit = '1' then
clapYourHands; -- proc call
else
null;
end if;

Null is a wonderful statement. It's great for creating sections you
want to go back to (an inherant comment - of I'm not done yet) or
closing if then else groups.

In program 2 I see that you are combining std_logic_vector with bit
for operations. Try defining all the entity names with std_logic
instead of bit. That or you will need to convert the bit (or
std_logic_vector) for the nor operation to work properly.


In program 3 it looks like you always have:
q <= s; qbar <= r;

I would change the structure to
if r = '1' or s = '1' then
q <= s;
qbar <= r;
else --you are missing the final 'else' keyword. This can make for
rather large circuits.
null;
end if;



 
Reply With Quote
 
 
 
 
jens
Guest
Posts: n/a
 
      09-11-2007
> Null is a wonderful statement. It's great for creating sections you
> want to go back to (an inherant comment - of I'm not done yet) or
> closing if then else groups.


I guess I fail to see the point of adding two lines of code to every
if statement to tell it to do nothing, it'll do nothing just fine on
it its own. The suggestion of converting everything to std_logic is a
good one.

To answer the original question...

Every signal assigned in a clocked process will create a flip-flip, so
the first two examples will create 4 flip-flops, one each for q, qs,
qbar and qsbar. Also, the outputs of some of those flip-flops will
feed into the inputs of other flip-flops, which will delay signals in
a way you didn't intend. Using variables instead of signals could
have change the behavior, but would still be needlessly complex. The
third one is better with only two flip-flops (q and qbar). The key to
create one SR flip-flop is to create only one flip-flop for q and
derive qbar from q. Also, the logic is more complex than it needs to
be, as it handles the illegal case separately and also assign outputs
to input values rather than constants. As is usually the case, look
for a simpler answer rather than a more complicated answer. Try
something like this:

process( clk )
begin
if ( r = '1' ) then -- R wins in the illegal case of RS=11
q <= '0';
elsif ( s = '1' ) then
q <= '1';
end if;
end process;

qbar <= not q;

 
Reply With Quote
 
jens
Guest
Posts: n/a
 
      09-11-2007
> Null is a wonderful statement. It's great for creating sections you
> want to go back to (an inherant comment - of I'm not done yet) or
> closing if then else groups.


I guess I fail to see the point of adding two lines of code to every
if statement to tell it to do nothing, it'll do nothing just fine on
it its own. The suggestion of converting everything to std_logic is a
good one.

To answer the original question...

Every signal assigned in a clocked process will create a flip-flip, so
the first two examples will create 4 flip-flops, one each for q, qs,
qbar and qsbar. Also, the outputs of some of those flip-flops will
feed into the inputs of other flip-flops, which will delay signals in
a way you didn't intend. Using variables instead of signals could
have changed the behavior, but would still be needlessly complex. The
third one is better with only two flip-flops (q and qbar). The key to
create one SR flip-flop is to create only one flip-flop for q and
derive qbar from q. Also, the logic is more complex than it needs to
be, as it handles the illegal case separately and also assign outputs
to input values rather than constants. As is usually the case, look
for a simpler answer rather than a more complicated answer. Try
something like this:

process( clk )
begin

if ( r = '1' ) then -- R wins in the illegal case of RS=11
q <= '0';
elsif ( s = '1' ) then
q <= '1';
end if;
end process;

qbar <= not q;

 
Reply With Quote
 
jens
Guest
Posts: n/a
 
      09-11-2007
> Null is a wonderful statement. It's great for creating sections you
> want to go back to (an inherant comment - of I'm not done yet) or
> closing if then else groups.


I guess I fail to see the point of adding two lines of code to every
if statement to tell it to do nothing, it'll do nothing just fine on
it its own. The suggestion of converting everything to std_logic is a
good one.

To answer the original question...

Every signal assigned in a clocked process will create a flip-flip, so
the first two examples will create 4 flip-flops, one each for q, qs,
qbar and qsbar. Also, the outputs of some of those flip-flops will
feed into the inputs of other flip-flops, which will delay signals in
a way you didn't intend. Using variables instead of signals could
have changed the behavior, but would still be needlessly complex. The
third one is better with only two flip-flops (q and qbar). The key to
create one SR flip-flop is to create only one flip-flop for q and
derive qbar from q. Also, the logic is more complex than it needs to
be, as it handles the illegal case separately and also assign outputs
to input values rather than constants. As is usually the case, look
for a simpler answer rather than a more complicated answer. Try
something like this:

process(clk)
begin
if rising_edge(clk) then
if r = '1' then -- R wins in the illegal case of RS=11
q <= '0';
elsif s = '1' then
q <= '1';
end if;
end if;
end process;

qbar <= not q;

 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      09-12-2007
> Null is a wonderful statement. It's great for creating sections you
> want to go back to (an inherant comment - of I'm not done yet) or
> closing if then else groups.


Your comments about NULL completing an if-else statement got my
attention.

Are you trying to avoid latches, by any chance?

In clocked processes, if-then statements (without else) can result in
clock enables, but not latches.

Latches are caused by combinatorial processes that execute, but, under
some circumstances do not assign a signal that is assigned under
other circumstances. When the signal is not assigned, it is forced to
"remember" its previous state, and a latch is inferred to do that. The
common (and I believe outdated) admonition to always have an 'else'
with every 'if-(elsif)-then' statement to avoid latches in
combinatorial processes is not a reliable way to avoid latches.

There are many more effective approaches to avoiding latches. First,
avoid combinatorial processes, and you won't have any latches.

If you have to use a combinatorial process (you probably really don't
but if you think you have to), then provide default assignments to
every signal driven by the process, right up front in the process,
before any if/case/loop/etc. statements. By assigning everything a
default value in one place, it makes it easier to review/audit the
code, and verify that no latches will be produced. Then you don't have
to worry about whether every if has an else (and contains all the
assignments in needs), etc.

For example, rather than write:

if condition = '1' then
a <= b;
else
a <= '0';
end if;

you could re-write it as:

a <= '0'; -- default
if condition = '1' then
a <= b;
end if;

Of course, the advantages become more clear as the number of signals
and conditions grows.

Andy

 
Reply With Quote
 
beckjer
Guest
Posts: n/a
 
      09-12-2007
On Sep 11, 4:39 pm, jens <(E-Mail Removed)> wrote:
> > Null is a wonderful statement. It's great for creating sections you
> > want to go back to (an inherant comment - of I'm not done yet) or
> > closing if then else groups.

>
> I guess I fail to see the point of adding two lines of code to every
> if statement to tell it to do nothing, it'll do nothing just fine on
> it its own. The suggestion of converting everything to std_logic is a
> good one.
>

I meant closing case statements, not if statements (which would make
it a useless comment). Not enough coffee the other day I guess.

 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      09-12-2007
On Sep 12, 12:47 pm, beckjer <(E-Mail Removed)> wrote:
> On Sep 11, 4:39 pm, jens <(E-Mail Removed)> wrote:> > Null is a wonderful statement. It's great for creating sections you
> > > want to go back to (an inherant comment - of I'm not done yet) or
> > > closing if then else groups.

>
> > I guess I fail to see the point of adding two lines of code to every
> > if statement to tell it to do nothing, it'll do nothing just fine on
> > it its own. The suggestion of converting everything to std_logic is a
> > good one.

>
> I meant closing case statements, not if statements (which would make
> it a useless comment). Not enough coffee the other day I guess.


Oh,... nevermind.
Disregard my comments regarding latch avoidance.

Andy

 
Reply With Quote
 
Paul Uiterlinden
Guest
Posts: n/a
 
      09-13-2007
beckjer wrote:

> On Sep 11, 4:39 pm, jens <(E-Mail Removed)> wrote:
>> > Null is a wonderful statement. It's great for creating sections you
>> > want to go back to (an inherant comment - of I'm not done yet) or
>> > closing if then else groups.

>>
>> I guess I fail to see the point of adding two lines of code to every
>> if statement to tell it to do nothing, it'll do nothing just fine on
>> it its own. The suggestion of converting everything to std_logic is a
>> good one.
>>

> I meant closing case statements, not if statements (which would make
> it a useless comment). Not enough coffee the other day I guess.


Also there NULL makes no sense, in my opinion. A choice is allowed to be
empty. Something along these lines is valid VHDL:

case my_enum is
when => e_plus
a := b + c;
when => e_min
a := b - c;
when others =>
-- Do nothing (no NULL needed here)
end case;

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.
 
Reply With Quote
 
Jonathan Bromley
Guest
Posts: n/a
 
      09-14-2007
On Thu, 13 Sep 2007 23:08:46 +0200, Paul
Uiterlinden <(E-Mail Removed)> wrote:

> Something along these lines is valid VHDL:
>
> case my_enum is
> when e_plus => -- JB fixed minor syntax error
> a := b + c;
> when e_min =>
> a := b - c;
> when others =>
> -- Do nothing (no NULL needed here)
> end case;


Agreed, but... when I write control structures
I typically write the WHOLE control structure
and then start filling in the bodies. This
prevents me from making silly nesting errors.
So I might write:

case my_enum is
when e_plus =>
when e_min =>
when others =>
end case;

and then start adding code to each branch.

A completely empty branch is a good clue that I
forgot to do something. Consequently, I generally
prefer to put an explicit "null;" in branches that
I *intended* to be empty, to distinguish them from
branches that I didn't get around to completing yet.

Users of the kind of highly automated text editor
that makes my brain explode will doubtless tell me
there's a better way to write code...
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
http://www.velocityreviews.com/forums/(E-Mail Removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Tristate Flip Flop Jim VHDL 12 11-18-2004 12:45 PM
IC area of flip-flop and SRAM? Weng Tianxiang VHDL 1 05-23-2004 04:05 PM
Best book on a flip flop circuit Weng Tianxiang VHDL 1 05-20-2004 06:51 PM
4 bit divisor with flip-flop ? eric VHDL 15 02-05-2004 03:31 AM
Flip Flop Synchronization John VHDL 3 01-05-2004 05:58 PM



Advertisments