RS LATCH VHDL STRUCTURAL MODEL

[Pavel-Ioan Duta]

Hello,

I'm new to this group and VHDL too. I'm trying to simulate an RS latch using structural model but with no luck. My code is the following:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ENTITY RSLATCH IS

PORT(R,S : IN BIT; Q,NQ : BUFFER BIT);

END RSLATCH;

ARCHITECTURE NETLIST OF RSLATCH IS

COMPONENT NOR2

PORT(a,b : IN BIT; c : OUT BIT);

END COMPONENT;

BEGIN

U1 : NOR2

PORT MAP(R,NQ,Q);

U2 : NOR2

PORT MAP(Q,S,NQ);

END NETLIST;

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I had compiled the code with success, but when im forcing the R or the S signal, my outputs (Q, NQ) aren't changing. Could somebody help me in this matter, please? Thank you in advance!

[Rob Gaddi]

Is the NOR2 something that you have a definition for somewhere?

Also, no one would write that code that way any time in the last 20
years. BIT is deeply out of fashion, and structural definitions of
basic logic blocks are a grossly overcomplicated approach. Even
defining an RS latch is a pretty low-level thing (though I've needed it
myself), but if you were going to do it you'd do it like:

library ieee;
use ieee.std_logic_1164.all;

entity RSLATCH is
port (
R, S : in std_logic;
Q, NQ : out std_logic
);
end entity RSLATCH;

architecture Behavioral of RSLATCH is
begin

LATCH: process(R, S)
variable state : std_logic;
begin
if (R = '1') then
state := '0';
elsif (S = '1') then
state := '1';
end if;
Q <= state;
NQ <= not state;
end process LATCH;

end architecture Behavioral;

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com

Email address domain is currently out of order. See above to fix.

[rickman]

I don't see anything wrong with your code off the top of my head. The
use of "buffer" is unusual, in fact, I didn't know buffer existed until
now. But it should work, certainly in simulation.... except that you
are connecting it to an output of the NOR2 component. I read that if
buffer is used, it must be used at all levels of the hierarchy.

If you can enable VHDL-2008 in your tools, you can do the same thing
with OUT that you are doing with BUFFER without the complications. What
simulator are you using?

--

Rick C

[Pavel-Ioan Duta]

Thank you so much for your help! So it's seems that my VHDL book source is "a little bit" outdated. Could you please provide me an updated VHDL source for a beginner like me?

[Pavel-Ioan Duta]

I am using ModelSim. I'we managed to make the code works. I had to define the entity of NOR2 and it's architecture. Here is the final code that works:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ENTITY NOR2 IS

PORT(a,b : IN BIT; c : OUT BIT);

END ENTITY NOR2;

ARCHITECTURE NETLIST_NOR OF NOR2 IS
BEGIN

c<=a nor b;

END ARCHITECTURE NETLIST_NOR;

ENTITY RSLATCH IS

PORT(R,S : IN BIT; Q,NQ : BUFFER BIT);

END ENTITY RSLATCH;

ARCHITECTURE NETLIST OF RSLATCH IS

COMPONENT NOR2

PORT(a,b : IN BIT; c : OUT BIT);

END COMPONENT;

BEGIN

U1 : NOR2

PORT MAP(R,NQ,Q);

U2 : NOR2

PORT MAP(Q,S,NQ);

END ARCHITECTURE NETLIST;

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I know there are many ways of doing this latch and i'm a novice on VHDL but even the smallest progress is still a prgress :)

[rickman]

This was not so much an exercise in making a latch... as you will find
them seldom used. It is more an exercise in using structural VHDL
(components).

The other way to produce logic is called "inference" which is what Rob
wrote for you. The functionality of the logic is described by the code
and the tools turn the source into actual gates and registers or
whatever functional elements your target chip contains.

Both methods are used with the structural part usually being used to
connect modules that you have written or provided by the tool (memory
for example). In fact, that is what you have done. You use inference
to define the functionality of the NOR2 gate, then you connect these
gates structurally to create the latch.

When I read your original example it didn't occur to me the entity for
the NOR2 gate had not been defined elsewhere. They can be defined in
another file of similar source code and combined by your tool or in a
package which you refer to with a "use" statement, similar to a C
language include statement if you are familiar with that.

--

Rick C

[KJ]

On Tuesday, July 12, 2016 at 1:44:33 PM UTC-4, Pavel-Ioan Duta wrote:
>
> I know there are many ways of doing this latch and i'm a novice on VHDL but even the smallest progress is still a prgress :)

Then here is a little tidbit, don't bother with the component declaration. Instead you directly instantiate. Where you currently have a component and you instantiate like this...

> COMPONENT NOR2 PORT(a,b : IN BIT; c : OUT BIT); END COMPONENT;

> U1 : NOR2 PORT MAP(R,NQ,Q);
> U2 : NOR2 PORT MAP(Q,S,NQ);

Instead you can skip the component declaration and instead write it like this...
> U1 : entity work.NOR2 PORT MAP(R,NQ,Q);
> U2 : entity work.NOR2 PORT MAP(Q,S,NQ);

As you've probably already noticed, the entity declaration for NOR2 and the component declaration for NOR2 are nearly identical. Problem occurs when those two declarations are not identical usually due to some change in one place that is not reflected in the other. The errors you get from the simulator are often not terribly clear when you have this problem.

By using direct entity instantiation (i.e. putting 'entity work.' in front of the NOR2 entity name), you no longer need to have the component declaration. Since now there is only the entity defining the interface, you don't have to worry about changing the interface in one place and not the other. Also less code to write.

This has nothing to do with modelling an RS flip flop, just a tip on how to write things better to avoid future problems.

Kevin Jennings

[KJ]

On Tuesday, July 12, 2016 at 1:28:33 PM UTC-4, rickman wrote:
> The
> use of "buffer" is unusual, in fact, I didn't know buffer existed until
> now. But it should work, certainly in simulation.... except that you
> are connecting it to an output of the NOR2 component. I read that if
> buffer is used, it must be used at all levels of the hierarchy.
>

As far as I know, 'buffer' is generally supported today and has been for some time, I've used it for a while. The 'must be used at all levels of the hierarchy' thing I'm pretty sure were all compiler bugs that eventually were fixed. There used to be a time when one might want to avoid 'buffer' due to limitations of the tool that you were using, but I think those days are off in the past.

> If you can enable VHDL-2008 in your tools, you can do the same thing
> with OUT that you are doing with BUFFER without the complications.

Yes, the use of 'out' and 2008 makes 'buffer' now a secondary way of doing things. So now that you're aware of 'buffer', you can safely forget about it. The one use case left would be situations where 2008 is not allowed for whatever reason.

Kevin Jennings