Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   VHDL (http://www.velocityreviews.com/forums/f18-vhdl.html)
-   -   problem with a shift register (http://www.velocityreviews.com/forums/t374678-problem-with-a-shift-register.html)

dauzat.lilian@gmail.com 10-16-2006 01:45 PM

problem with a shift register
 
Hello,

I want to describe in VHDL a 8 bits shift register with synchronous
load but I want it to shift every two rising edge of the master clock
'clk' so I defined the signal clk05 which is supposed to be clk divided
by 2.
Here is my vhdl :

entity man_encoder is
port(
din : in std_logic_vector(7 downto 0); -- parallel 8 bits input
clk, wr, rst : in std_logic; -- wr:load din in input buffer,
rst:asynchronous reset
mdo, ready : out std_logic -- mdo:encoder output
);
end man_encoder;

architecture Behavioral of man_encoder is
signal clk05 : std_logic;
signal wr1 : std_logic;
signal dserial : std_logic;
signal din_sig : std_logic_vector(7 downto 0);
signal buff : std_logic_vector(7 downto 0);

begin
din_sig <= din;
mdo <= buff(7);

-- wr positive edge detector
process(clk, rst, wr)
begin
if (rst='1') then
wr1 <= '1';
elsif (clk'event and clk='1') then
wr1 <= wr;
end if;
end process;

-- clock divider (/2)
process(clk, rst)
begin
if (rst='1') then
clk05 <= '0';
elsif (clk'event and clk='1') then
clk05 <= not(clk05);
end if;
end process;

-- shift register
process(din_sig, wr, wr1, clk)
begin
if (rst='1') then
buff <= (others=>'0');
elsif (clk'event and clk='1') then
if (clk05='1') then
if (wr='1' and wr1='0') then
buff <= din_sig;
else
buff <= buff(6 downto 0) & '0';
end if;
end if;
end if;
end process;
dserial <= buff(7);

end Behavioral;

My problem is the following : the register "buff" is shift on falling
edge of clk05 and I want it on the rising edge of clk05.

Could anyone help me ?

Thanks a lot
Lilian


patrick.melet@dmradiocom.fr 10-16-2006 03:36 PM

Re: problem with a shift register
 
Try this :
process(clk,rst)
begin
if (rst='1') then
buff <= (others=>'0');
clk05_1 <= '0';
elsif (clk'event and clk='1') then
clk_05_1 <= clk_05;
if (clk05='1' and clk05_1='0') then
if (wr='1' and wr1='0') then
buff <= din_sig;
else
buff <= buff(6 downto 0) & '0';
end if;
end if;
end if;
end process;


TigerJade 10-16-2006 04:55 PM

Re: problem with a shift register
 
What happens if you simply change
if (clk05='1') then
to
if (clk05='0') then ?

dauzat.lilian@gmail.com wrote:
> Hello,
>
> I want to describe in VHDL a 8 bits shift register with synchronous
> load but I want it to shift every two rising edge of the master clock
> 'clk' so I defined the signal clk05 which is supposed to be clk divided
> by 2.
> Here is my vhdl :
>
> entity man_encoder is
> port(
> din : in std_logic_vector(7 downto 0); -- parallel 8 bits input
> clk, wr, rst : in std_logic; -- wr:load din in input buffer,
> rst:asynchronous reset
> mdo, ready : out std_logic -- mdo:encoder output
> );
> end man_encoder;
>
> architecture Behavioral of man_encoder is
> signal clk05 : std_logic;
> signal wr1 : std_logic;
> signal dserial : std_logic;
> signal din_sig : std_logic_vector(7 downto 0);
> signal buff : std_logic_vector(7 downto 0);
>
> begin
> din_sig <= din;
> mdo <= buff(7);
>
> -- wr positive edge detector
> process(clk, rst, wr)
> begin
> if (rst='1') then
> wr1 <= '1';
> elsif (clk'event and clk='1') then
> wr1 <= wr;
> end if;
> end process;
>
> -- clock divider (/2)
> process(clk, rst)
> begin
> if (rst='1') then
> clk05 <= '0';
> elsif (clk'event and clk='1') then
> clk05 <= not(clk05);
> end if;
> end process;
>
> -- shift register
> process(din_sig, wr, wr1, clk)
> begin
> if (rst='1') then
> buff <= (others=>'0');
> elsif (clk'event and clk='1') then
> if (clk05='1') then
> if (wr='1' and wr1='0') then
> buff <= din_sig;
> else
> buff <= buff(6 downto 0) & '0';
> end if;
> end if;
> end if;
> end process;
> dserial <= buff(7);
>
> end Behavioral;
>
> My problem is the following : the register "buff" is shift on falling
> edge of clk05 and I want it on the rising edge of clk05.
>
> Could anyone help me ?
>
> Thanks a lot
> Lilian



dauzat.lilian@gmail.com 10-16-2006 06:27 PM

Re: problem with a shift register
 
Thanks for your answer but I still have the same problem.... :-(

patrick.melet@dmradiocom.fr wrote:
> Try this :
> process(clk,rst)
> begin
> if (rst='1') then
> buff <= (others=>'0');
> clk05_1 <= '0';
> elsif (clk'event and clk='1') then
> clk_05_1 <= clk_05;
> if (clk05='1' and clk05_1='0') then
> if (wr='1' and wr1='0') then
> buff <= din_sig;
> else
> buff <= buff(6 downto 0) & '0';
> end if;
> end if;
> end if;
> end process;



dauzat.lilian@gmail.com 10-16-2006 06:29 PM

Re: problem with a shift register
 
In this case my the register is completly out of order :-(

Thanks

TigerJade wrote:
> What happens if you simply change
> if (clk05='1') then
> to
> if (clk05='0') then ?
>
> dauzat.lilian@gmail.com wrote:
> > Hello,
> >
> > I want to describe in VHDL a 8 bits shift register with synchronous
> > load but I want it to shift every two rising edge of the master clock
> > 'clk' so I defined the signal clk05 which is supposed to be clk divided
> > by 2.
> > Here is my vhdl :
> >
> > entity man_encoder is
> > port(
> > din : in std_logic_vector(7 downto 0); -- parallel 8 bits input
> > clk, wr, rst : in std_logic; -- wr:load din in input buffer,
> > rst:asynchronous reset
> > mdo, ready : out std_logic -- mdo:encoder output
> > );
> > end man_encoder;
> >
> > architecture Behavioral of man_encoder is
> > signal clk05 : std_logic;
> > signal wr1 : std_logic;
> > signal dserial : std_logic;
> > signal din_sig : std_logic_vector(7 downto 0);
> > signal buff : std_logic_vector(7 downto 0);
> >
> > begin
> > din_sig <= din;
> > mdo <= buff(7);
> >
> > -- wr positive edge detector
> > process(clk, rst, wr)
> > begin
> > if (rst='1') then
> > wr1 <= '1';
> > elsif (clk'event and clk='1') then
> > wr1 <= wr;
> > end if;
> > end process;
> >
> > -- clock divider (/2)
> > process(clk, rst)
> > begin
> > if (rst='1') then
> > clk05 <= '0';
> > elsif (clk'event and clk='1') then
> > clk05 <= not(clk05);
> > end if;
> > end process;
> >
> > -- shift register
> > process(din_sig, wr, wr1, clk)
> > begin
> > if (rst='1') then
> > buff <= (others=>'0');
> > elsif (clk'event and clk='1') then
> > if (clk05='1') then
> > if (wr='1' and wr1='0') then
> > buff <= din_sig;
> > else
> > buff <= buff(6 downto 0) & '0';
> > end if;
> > end if;
> > end if;
> > end process;
> > dserial <= buff(7);
> >
> > end Behavioral;
> >
> > My problem is the following : the register "buff" is shift on falling
> > edge of clk05 and I want it on the rising edge of clk05.
> >
> > Could anyone help me ?
> >
> > Thanks a lot
> > Lilian



Al 10-18-2006 06:43 PM

Re: problem with a shift register
 
dauzat.lilian@gmail.com wrote:

> -- shift register
> process(din_sig, wr, wr1, clk)
> begin
> if (rst='1') then
> buff <= (others=>'0');
> elsif (clk'event and clk='1') then
> if (clk05='1') then
> if (wr='1' and wr1='0') then
> buff <= din_sig;
> else
> buff <= buff(6 downto 0) & '0';
> end if;
> end if;
> end if;
> end process;
> dserial <= buff(7);
>
> end Behavioral;
>
> My problem is the following : the register "buff" is shift on falling
> edge of clk05 and I want it on the rising edge of clk05.
>
> Could anyone help me ?
>
> Thanks a lot
> Lilian
>


I would do it in this way, so that you load it with one clock-cycle of
wr and you will shift it out when clk05 is 0, that means that the value
will be updated on the next rising_edge (clk) when the clk05 will be 1
again.
Try and let us know.

process(din_sig, wr, wr1, clk)
begin
if (rst = '1') then
buff <= (others => '0');
elsif (clk'event and clk = '1') then
if (wr = '1' and wr1 = '0') then
buff <= din_sig;
elsif clk05 = '0' then
buff <= buff(6 downto 0) & '0';
end if;
end if;
end process;
dserial <= buff(7);


--
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Jim Lewis 10-18-2006 10:33 PM

Re: problem with a shift register
 
Lilian,
I think your design is correct. Let me explain.
In RTL sim, Clk05 does not have any propagation delay.
As a result, it looks like it rises at the same time as
Clk. In a real design, Clk05 has a propagation delay
relative to Clk. Since Clk05 is only half the frequency
of Clk, it looks like you are shifting on the falling
edge of Clk05, however, this is the earliest time at
which you will see Clk rising and Clk05 a 1.

For simulation visualization purposes, you might change:
clk05 <= not(clk05);

to:
clk05 <= not(clk05) after tperiod_Clk/2 ; -- where tperiod_Clk = period of Clk.

However, in general I recommend against using after.

Cheers,
Jim

> Hello,
>
> I want to describe in VHDL a 8 bits shift register with synchronous
> load but I want it to shift every two rising edge of the master clock
> 'clk' so I defined the signal clk05 which is supposed to be clk divided
> by 2.
> Here is my vhdl :
>
> entity man_encoder is
> port(
> din : in std_logic_vector(7 downto 0); -- parallel 8 bits input
> clk, wr, rst : in std_logic; -- wr:load din in input buffer,
> rst:asynchronous reset
> mdo, ready : out std_logic -- mdo:encoder output
> );
> end man_encoder;
>
> architecture Behavioral of man_encoder is
> signal clk05 : std_logic;
> signal wr1 : std_logic;
> signal dserial : std_logic;
> signal din_sig : std_logic_vector(7 downto 0);
> signal buff : std_logic_vector(7 downto 0);
>
> begin
> din_sig <= din;
> mdo <= buff(7);
>
> -- wr positive edge detector
> process(clk, rst, wr)
> begin
> if (rst='1') then
> wr1 <= '1';
> elsif (clk'event and clk='1') then
> wr1 <= wr;
> end if;
> end process;
>
> -- clock divider (/2)
> process(clk, rst)
> begin
> if (rst='1') then
> clk05 <= '0';
> elsif (clk'event and clk='1') then
> clk05 <= not(clk05);
> end if;
> end process;
>
> -- shift register
> process(din_sig, wr, wr1, clk)
> begin
> if (rst='1') then
> buff <= (others=>'0');
> elsif (clk'event and clk='1') then
> if (clk05='1') then
> if (wr='1' and wr1='0') then
> buff <= din_sig;
> else
> buff <= buff(6 downto 0) & '0';
> end if;
> end if;
> end if;
> end process;
> dserial <= buff(7);
>
> end Behavioral;
>
> My problem is the following : the register "buff" is shift on falling
> edge of clk05 and I want it on the rising edge of clk05.
>
> Could anyone help me ?
>
> Thanks a lot
> Lilian
>



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~

Al 10-19-2006 08:17 AM

Re: problem with a shift register
 


Jim Lewis wrote:
> Lilian,
> I think your design is correct. Let me explain.
> In RTL sim, Clk05 does not have any propagation delay.
> As a result, it looks like it rises at the same time as
> Clk. In a real design, Clk05 has a propagation delay
> relative to Clk. Since Clk05 is only half the frequency
> of Clk, it looks like you are shifting on the falling
> edge of Clk05, however, this is the earliest time at
> which you will see Clk rising and Clk05 a 1.
>

I'm sorry but the design is not correct. It should be taken into account
even at the functional level (even if this cannot be verified with a
simulation) that a signal which changes on the event of a clock will
have a delay.
So what's the point of functional verification if it will not check your
functionalities but some other's stuff functionalities?

> For simulation visualization purposes, you might change:
> clk05 <= not(clk05);
>
> to:
> clk05 <= not(clk05) after tperiod_Clk/2 ; -- where tperiod_Clk = period
> of Clk.


I think this assumption is really misleading and would get you to the
point that your functional code would be rather different from the
synthesized code. And as you said:

> in general I recommend against using after.


I would raccomand to use post-synthesis and post-fitting simulation to
really have an idea of what's going on.
Functional verification might be useful to check some combinatorial
logic, but do you think is needed when you need to check sequential
logic if it doesn't take into account the way sequential logic works?
I might be (as almost always...) wrong, but still (even if I already
discussed this in another thread -see Libero 7.2 on comp.arch.fpga) I
doubt that functional simulation can help that much.

Al

--
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Jim Lewis 10-19-2006 03:05 PM

Re: problem with a shift register
 
Al
>> I think your design is correct. Let me explain.
>> In RTL sim, Clk05 does not have any propagation delay.
>> As a result, it looks like it rises at the same time as
>> Clk. In a real design, Clk05 has a propagation delay
>> relative to Clk. Since Clk05 is only half the frequency
>> of Clk, it looks like you are shifting on the falling
>> edge of Clk05, however, this is the earliest time at
>> which you will see Clk rising and Clk05 a 1.
>>

> I'm sorry but the design is not correct. It should be taken into account
> even at the functional level (even if this cannot be verified with a
> simulation) that a signal which changes on the event of a clock will
> have a delay.


The signal has a delta cycle delay with respect to clock.
This in some ways represents a unit propagation delay.
Unfortunately you can't see it in the wave window of most
simulators. You can see it in the list window.

As a designer you have to understand that all outputs that are
clocked are going to show up exactly this way. As a result,
if you create a single clock wide enable signal, it is as if it
has a very long setup and a very short hold and it is going to
look like you are seeing it when it falls. This is the nature
of an enable signal that comes out of a register. It is not
a clock. You are not looking for a rising edge. Instead you
are looking for a level when clock rises.

When drawing them by hand, some people used to draw them
this way on paper too - however then they would confuse
themselves and others as to which cycle they were designing
the signal to occur on. As a result, I would always draw
them with a propagation delay. This is always clear about
the cycle at which they are intended to be sampled.

This is why I suggested injecting the delay - solely
for visualization. It is safe to put a single delay
like this on any register output. I would probably be more
likely to use tperiod_Clk/10 as long as it does not round to 0.
Note that I don't do this in my design practice as once you
understand the nature of enable signals, it is easy to follow
what is happening in simulation and I am too lazy to do
all that typing.


>> For simulation visualization purposes, you might change:
>> clk05 <= not(clk05);
>>
>> to:
>> clk05 <= not(clk05) after tperiod_Clk/2 ; -- where tperiod_Clk =
>> period of Clk.

>
> I think this assumption is really misleading and would get you to the
> point that your functional code would be rather different from the
> synthesized code.


As long as you only do one delay per register output you are safe.

>
>> in general I recommend against using after.

>
> I would raccomand to use post-synthesis and post-fitting simulation to
> really have an idea of what's going on.

Only the timing that comes out after place and route is done is
relevant. Any timing from a separate synthesis tool is just an
estimate.

> Functional verification might be useful to check some combinatorial
> logic, but do you think is needed when you need to check sequential
> logic if it doesn't take into account the way sequential logic works?
> I might be (as almost always...) wrong, but still (even if I already
> discussed this in another thread -see Libero 7.2 on comp.arch.fpga) I
> doubt that functional simulation can help that much.


Functional simulation + safe coding styles + static timing analysis =
design done

Gate and timing simulations are insurance that you did not mess up in one
of the above. I always do gate with at least nominal timing. I don't
put alot of faith in full timing simulations as it is difficult to
exercise a critical path in a critical way.

I read your referenced article. Mike stated,
"A post-layout sim is not always needed for a synchronous design."
I would bet that he is doing functional sim and not post-synthesis sim.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~

Al 10-20-2006 07:12 AM

Re: problem with a shift register
 


Jim Lewis wrote:
>
> When drawing them by hand, some people used to draw them
> this way on paper too - however then they would confuse
> themselves and others as to which cycle they were designing
> the signal to occur on. As a result, I would always draw
> them with a propagation delay. This is always clear about
> the cycle at which they are intended to be sampled.


Indeed that's how you should think about a registered signal and that is
the point that Lilian missed in the very first place.

>> I would raccomand to use post-synthesis and post-fitting simulation to
>> really have an idea of what's going on.

>
> Only the timing that comes out after place and route is done is
> relevant. Any timing from a separate synthesis tool is just an
> estimate.


is an estimation which takes into account clock-to-output delay, as the
functional sim doesn't. Am I wrong?
>
> Functional simulation + safe coding styles + static timing analysis =
> design done
>


Are you saying that the static timing analysis is easier to handle than
running a post-layout sim? If you already have a testbench, which you do
because you have already done a functional sim, isn't just easier to run
the post-layout sim, instead of checking all the critical paths?
I'm sorry but I don't see clearly the point.

> I read your referenced article. Mike stated,
> "A post-layout sim is not always needed for a synchronous design."
> I would bet that he is doing functional sim and not post-synthesis sim.


I really hope to gain that ability one day, now I'm too far behind! :-)
And surely this ng will help a lot.


--
Alessandro Basili
CERN, PH/UGC
Hardware Designer


All times are GMT. The time now is 08:05 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.