problem with a shift register

[dauzat.lilian]

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]

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]

What happens if you simply change
if (clk05='1') then
to
if (clk05='0') then ?

 

[dauzat.lilian]

Thanks for your answer but I still have the same problem.... :-(

 

[dauzat.lilian]

In this case my the register is completly out of order :-(

Thanks

 

[Al]

-- 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);

 

[Jim Lewis]

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:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

 

[Al]

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

 

[Jim Lewis]

Al

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.

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.

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:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

 

[Al]

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.

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.

 

[KJ]

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.

'Easier' or 'harder' is not point. A post route simulation does not in any
way replace the need to perform static timing analysis. All a post-route
simulation lets you do is run with all max, or all min or all typical times
for all modelled delays. It doesn't let you do any combination of min/max
times let alone all possible combinations of these times. That's what
static timing analysis addresses.

If you do not perform static timing analysis then you're just rolling the
dice hoping that the timing actually works out. You're not performing the
analysis that would tell you whether your timing will work out under all
conditions (so you can fix it now if there is a problem).

Assuming that you do perform static timing analysis then there is generally
no value to performing post-route simulation. The reason is simply that if
you performed the timing analysis correctly then you know that your design
will work correctly for any combination of delays; the post-route simulation
is simply selecting one particular combination of delays.

If you run a post-route simulation and it runs across an error it either
means
- You didn't perform the timing analysis and there is a timing problem.
- You did not perform timing analysis correctly and there is a timing
problem.
- Your simulation model that surrounds the design being tested is not
accurately modelling input delays in to the design.
- Your simulation model that surrounds the design being tested is not
waiting for the appropriate delays before sampling the outputs.
- You have multiple clocks in your design and you're simply seeing the
result of clock domain crossing...which by itself is not necessarily an
error....depends on whether you've properly done the timing analysis.

The other reason for running post-route simulation is to give management the
warm fuzzies that you performed timing analysis correctly. As should be
clear by now, successful post-route sim does not imply that the timing will
work, but failing a post-route sim in many cases says that you haven't done
the timing analysis correctly and there may be a design problem.

For the experienced designer, the post-route sim is mainly a check off item
that gets done in the background at the end of the design cycle. For the
less experienced it can give some valuable feedback on why performing static
timing analysis is an important step.

KJ

 

[Al]

'Easier' or 'harder' is not point. A post route simulation does not in any
way replace the need to perform static timing analysis. All a post-route
simulation lets you do is run with all max, or all min or all typical times
for all modelled delays. It doesn't let you do any combination of min/max
times let alone all possible combinations of these times. That's what
static timing analysis addresses.

If you do not perform static timing analysis then you're just rolling the
dice hoping that the timing actually works out. You're not performing the
analysis that would tell you whether your timing will work out under all
conditions (so you can fix it now if there is a problem).

Assuming that you do perform static timing analysis then there is generally
no value to performing post-route simulation. The reason is simply that if
you performed the timing analysis correctly then you know that your design
will work correctly for any combination of delays; the post-route simulation
is simply selecting one particular combination of delays.

If you run a post-route simulation and it runs across an error it either
means
- You didn't perform the timing analysis and there is a timing problem.
- You did not perform timing analysis correctly and there is a timing
problem.
- Your simulation model that surrounds the design being tested is not
accurately modelling input delays in to the design.
- Your simulation model that surrounds the design being tested is not
waiting for the appropriate delays before sampling the outputs.
- You have multiple clocks in your design and you're simply seeing the
result of clock domain crossing...which by itself is not necessarily an
error....depends on whether you've properly done the timing analysis.

The other reason for running post-route simulation is to give management the
warm fuzzies that you performed timing analysis correctly. As should be
clear by now, successful post-route sim does not imply that the timing will
work, but failing a post-route sim in many cases says that you haven't done
the timing analysis correctly and there may be a design problem.

For the experienced designer, the post-route sim is mainly a check off item
that gets done in the background at the end of the design cycle. For the
less experienced it can give some valuable feedback on why performing static
timing analysis is an important step.

KJ

Unfortunately all I know about logic is what I learned on the
applications and never had the time to go that much into details, mainly
because I'm developing a non time-critical application in which is not a
matter of timing, as it is of reliability.
Maybe I lack too much and I'd better study how to do static timing
analysis. Anyway I appreciated the explanation and thanks to this ng I'm
learning quicker.

I'd like to excuse me with Jim because of that post, I simply didn't get
your point because of my limited knowledge.

Cheers

Al

 

[Jim Lewis]

is an estimation which takes into account clock-to-output delay, as the
functional sim doesn't. Am I wrong?

As long as your static timing analysis shows that each
register has less than one clock period delay, then
your functional simulation is accurate.

Gate sims tend to be much slower than RTL sims, so
I try to limit myself to after place and route sim.
However, if your design is small and its after synthesis
sims run fast, there is no reason not to run them if
they help you or your teammates understand what is
going on better.

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

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

 

[Mike Treseler]

... I'm developing a non time-critical application in which is not a
matter of timing, as it is of reliability.
Maybe I lack too much and I'd better study how to do static timing
analysis.

I expect that you are already running static timing
with every place and route. Check the timing report.
For quartus and ise, even if I don't set a single
constraint, the tools will still find my clock,
calculate Fmax, and show me my slowest nodes.

Failing static timing is a design problem.
Maybe I have to reduce the clock frequency
or pipeline an offending path to use
two ticks instead of one. Somehow I have
to change the *design* and the problem
is clearly defined.

Failing a post-route netlist sim after
passing the functional sim is a
*process* problem, so it is an emergency.
It should be a rare event, but if it ever happens,
the reason must be found as a top priority.

Such an error means that I either
messed up a timing constraint *or*
or i need to improve my design rule
checking, *or* I need to add or delete
a design rule.

Design rules include my code and script templates
(Jim's "safe coding styles") and the
make, model and revision level of
all tools involved in the production
of the fpga download image.

-- Mike Treseler

 

[Jim Lewis]

Unfortunately all I know about logic is what I learned on the
applications and never had the time to go that much into details, mainly
because I'm developing a non time-critical application in which is not a
matter of timing, as it is of reliability.
Maybe I lack too much and I'd better study how to do static timing
analysis. Anyway I appreciated the explanation and thanks to this ng I'm
learning quicker.

I'd like to excuse me with Jim because of that post, I simply didn't get
your point because of my limited knowledge.

It is an easy and common thing to miss.

This is how I learned about the value of verification
vectors in a timing simulation.
I did an ASIC for space. We were required to test
on the ASIC test platform (fabrication test) the 6 slowest
and one fastest path to/from each IO pin and internal to
the design. We identified the paths with static timing analysis.
_None_ of our normal verification vectors exercised
the worst case paths. We had to tediously research the
paths to figure out how to exercise them as we had to show
pass and failure when they moved the timing checker on the
test platform. After writing a couple we realized that this
was a very timing consuming effort.

Unfortunately we did not understand the impact of the
requirement at the beginning of the program. Due to the
time it was taking to write vectors, for some interfaces,
we decided it would be faster to go back and redesign to
register as much IO as possible at the chip interface.
While this cost some time, it cost less time that writing
the test vectors.

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

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

 

[Al]

I expect that you are already running static timing
with every place and route. Check the timing report.
For quartus and ise, even if I don't set a single
constraint, the tools will still find my clock,
calculate Fmax, and show me my slowest nodes.

Actually I use Designer, but it had never showed me problem about any
timing. I've run through it sometimes, more because of curiosity than
just a need.

Such an error means that I either
messed up a timing constraint *or*
or i need to improve my design rule
checking, *or* I need to add or delete
a design rule.

So it is not just a "time constraint" issue, but most probably even a
logic issue (as you said "reduce the clock frequency or pipeline an
offending path to use two ticks instead of one").

And most probably, as Jim said:

would be faster to go back and redesign

instead of adding timing constraints which may turn out in some others
critical paths. Is that correct?
I think could be worthwhile to add some time constraints, but how do you
get to the point when you realize that something must be changed in the
logic? Is it experience?

Anyway I learnt a lot from this chat and I thank you all guys (Jim, KJ
and Mike). But it'll take time, so I would bother you again! ;-)
Cheers

Al

 

[Mike Treseler]

Actually I use Designer, but it had never showed me problem about any
timing. I've run through it sometimes, more because of curiosity than
just a need.

Designer is a entry tool.
Some other application is doing place and route.

So it is not just a "time constraint" issue, but most probably even a
logic issue (as you said "reduce the clock frequency or pipeline an
offending path to use two ticks instead of one").

The two cases I discussed and should have numbered are:

1. Failing static timing
2. Failing a post-route netlist sim after
passing passing static timing and a functional sim

These don't overlap and neither do the causes.

Anyway I learnt a lot from this chat

Me too. Good luck.


-- Mike Treseler