Question about 2 bit counter example.

[Skybuck Flying]

Hi,

I am new to electronics and VHDL etc.

I am trying to understand the first 2 bit counter example. In this PDF:

http://tech-www.informatik.uni-hamburg.de/vhdl/doc/cookbook/VHDL-Cookbook.pdf

I think the clock signal goes as follows:
high, low, high, low, high, low.

So that's just the same as:
101010101010101010101

The clock signal is connected to a T_flipflop and goes out port Q0 (and also
ff0 I dont understand what that is... just some internal state thing ? but
ok)

So after the clock signal passess through the T_flipflop the new signal will
look like:
old clock signal:
1010101010101010101010

( t_flipflop is explained at
http://en.wikipedia.org/wiki/Flip_flop#T_flip-flop )

new Q0 signal:
1100110011001100110011

Now the new Q0 signal also goes to another inverter...

So after the inverter the interver signal will look like:

( I think an inverter just inverts it right ? )

Q0 inverter signal:
0011001100110011001100

Now the Q0 inverter signal enters another t_flipflop and it's output is Q1.
(also ff1)

Q1 signal:
001000100010001000100


So now we have three signals:

The original clock signal:
101010101010101010101010

The Q0 flipflop signal:
110011001100110011001100

The Q1 flipflop signal:
001000100010001000100010

Ok I find this a little bit weird.

For a counter I would expect the output to be the following:
Q0 Q1:

00
01
10
11
00
01
10
11

However the output seems to be:

10
10
01
00
10
10
01
00
10
10
01
00
10
10
01
00
10
10
01
00
10
10
01
00

This is totally different than how I would expect it too work...

Have I made a mistake in my reasoning somewhere ?

Is there a part I dont understand ? maybe the inverter works differently ?

Or is the PDF/manual a weird/bogus/wrong example of a 2 bit counter ???

Bye,
Skybuck.

 

[Skybuck Flying]

"Skybuck Flying" <nospam@hotmail.com> wrote in message news:...

Hi,

I am new to electronics and VHDL etc.

I am trying to understand the first 2 bit counter example. In this PDF:


http://tech-www.informatik.uni-hamburg.de/vhdl/doc/cookbook/VHDL-Cookbook.pdf

I think the clock signal goes as follows:
high, low, high, low, high, low.

So that's just the same as:
101010101010101010101

The clock signal is connected to a T_flipflop and goes out port Q0 (and
also
ff0 I dont understand what that is... just some internal state thing ? but
ok)

So after the clock signal passess through the T_flipflop the new signal
will
look like:
old clock signal:
1010101010101010101010

( t_flipflop is explained at
http://en.wikipedia.org/wiki/Flip_flop#T_flip-flop )

new Q0 signal:
1100110011001100110011

Now the new Q0 signal also goes to another inverter...

So after the inverter the interver signal will look like:

( I think an inverter just inverts it right ? )

Q0 inverter signal:
0011001100110011001100

Now the Q0 inverter signal enters another t_flipflop and it's output is
Q1.
(also ff1)

Q1 signal:
001000100010001000100


So now we have three signals:

The original clock signal:
101010101010101010101010

The Q0 flipflop signal:
110011001100110011001100

The Q1 flipflop signal:
001000100010001000100010

Ok I find this a little bit weird.

For a counter I would expect the output to be the following:
Q0 Q1:

00
01
10
11
00
01
10
11

However the output seems to be:

10
10
01
00
10
10
01
00
10
10
01
00
10
10
01
00
10
10
01
00
10
10
01
00

This is totally different than how I would expect it too work...

Have I made a mistake in my reasoning somewhere ?

Is there a part I dont understand ? maybe the inverter works differently ?

Or is the PDF/manual a weird/bogus/wrong example of a 2 bit counter ???

The problem is I don't understand picture/figure 1-2.

If I work out how the bits move through it I don't see the desired result...
?

Can anybody explain figure 1-2 ???

Bye,
Skybuck

 

[Skybuck Flying]

Ok,

Now I understand how these electronics work...

But I do find it very weird indeed

First of all the t flip flop only changes state on a fall from 1 to 0 (some
flip flops might work opposite but ok)

Second of all, apperently the "outputs" of the construction/entity has to be
read at the same rate as the clock rate.

Otherwise it doesn't make much sense.

The first mistake I made was assuming that every 1 bit during the clock rate
would convert the flip flop.

But this is not the case... the flip flop only changes when the 1 change
from 1 to zero or vice versa...

So my first assumption that it worked like this was wrong:

11001100110011001100

Suppose a flip flop was connected to this bit stream.

I thought that each 1 would convert the next flip flop like this:
10001000100010001000

Which is wrong

The flip flop only changes when the input changes from 1 to zero.

So given the input stream:
11001100110011001100

The flip flop output stream would be:
( assuming it changes on a fall from 1 to zero)
00111100001111000011

Etc... truely halving the signal etc.

Now the last tricky part is in reading the outputs...

Let's draw it one more time:

Clock rate: 01010101010101010101
Q1 : 00110011001100110011
Inverter : 11001100110011001100
Q2 : 00001111000011110000

So filtering out Q1 and Q2:

Q1 : 00110011001100110011
Q2 : 00001111000011110000

At first glance this doesn't seem to make any sense at all

The output would be:
00
00
10
10
01
01
11
11
00

The output should look like:
00
01
10
11
00
01
etc

So the funny thing with electronics is that the signal has to be stable for
a while.

So the signal has to be read... and apperently this happens at the same rate
as the clock rate ?

So we need to use the clock rate to figure it out
01 = one clock tick


Clock rate: 01#01#01#01#01#01#01#01#01#01
Q1 : 00#11#00#11#00#11#00#11#00#11
Q2 : 00#00#11#11#00#00#11#11#00#00

Reading Q1 and Q2 during the clock tick gives the following stable result:

Q1 : 0#1#0#1#0#1#0#1#0#1
Q2 : 0#0#1#1#0#0#1#1#0#0

Now putting this next to each other:

Q1, Q2
00
10
01
11
00
10
01
11

This looks a bit better

Maybe we need to switch em around

Q2, Q1
00
01
10
11
00
01
10
11

Ah, now we have our desired result

Electronics are damn tricky !

Bye,
Skybuck =D

 

[Skybuck Flying]

"Skybuck Flying" <nospam@hotmail.com> wrote in message news:...

Ok,

Now I understand how these electronics work...

But I do find it very weird indeed

First of all the t flip flop only changes state on a fall from 1 to 0
(some
flip flops might work opposite but ok)

Second of all, apperently the "outputs" of the construction/entity has to
be
read at the same rate as the clock rate.

Otherwise it doesn't make much sense.

The first mistake I made was assuming that every 1 bit during the clock
rate
would convert the flip flop.

But this is not the case... the flip flop only changes when the 1 change
from 1 to zero or vice versa...

So my first assumption that it worked like this was wrong:

11001100110011001100

Suppose a flip flop was connected to this bit stream.

I thought that each 1 would convert the next flip flop like this:
10001000100010001000

Which is wrong

The flip flop only changes when the input changes from 1 to zero.

So given the input stream:
11001100110011001100

The flip flop output stream would be:
( assuming it changes on a fall from 1 to zero)
00111100001111000011

Etc... truely halving the signal etc.

Now the last tricky part is in reading the outputs...

Let's draw it one more time:

Clock rate: 01010101010101010101
Q1 : 00110011001100110011
Inverter : 11001100110011001100
Q2 : 00001111000011110000

Oops I see I messed up here

Had to take the inverter for Q2

Clock rate: 01010101010101010101
Q1 : 00110011001100110011
Inverter : 11001100110011001100
Q2 : 00111100001111000011

So filtering out Q1 and Q2:

Q1 : 00110011001100110011
Q2 : 00111100001111000011

Clock rate: 01#01#01#01#01#01#01#01#01#01
Q1 : 00#11#00#11#00#11#00#11#00#11
Q2 : 00#11#11#00#00#11#11#00#00#11

Reading Q1 and Q2 during the clock tick gives the following stable result:

Q1 : 0#1#0#1#0#1#0#1#0#1
Q2 : 0#1#1#0#0#1#1#0#0#1

Now putting this next to each other:

Q1, Q2
00
11
01
10
00
11
01
10
00
11
01

Yeah maybe we still need to switch em around

00
11
10
01
00
11
10
01
00
11
10

Ok this looks a bit better

Apprently a countdown counter ?

Or did I mess up again somewhere ?

Tricky, tricky,tricky,tricky

Bye,
Skybuck.

 

[Skybuck Flying]

Hmm the code below figure 1-2 of the vhdl cookbook seems to be an
incrementing counter.

count:=(count + 1) mod 4
Q1 := count_value mod 2
Q2 := count_value / 2

count value: 0,1,2,3,0,1,2,3
Q1 : 0,1,0,1,0,1,0,1
Q2 : 0,0,1,1,0,0,1,1

While my output shows a decrementing counter.

Could it be that the cookbook has a wrong picture ?

Or is there still a flaw somewhere in my reasoning ?

http://tech-www.informatik.uni-hamburg.de/vhdl/doc/cookbook/VHDL-Cookbook.pdf

Bye,
Skybuck

"Skybuck Flying" <nospam@hotmail.com> wrote in message news:...

"Skybuck Flying" <nospam@hotmail.com> wrote in message news:...
Ok,

Now I understand how these electronics work...

But I do find it very weird indeed

First of all the t flip flop only changes state on a fall from 1 to 0
(some
flip flops might work opposite but ok)

Second of all, apperently the "outputs" of the construction/entity has
to
be
read at the same rate as the clock rate.

Otherwise it doesn't make much sense.

The first mistake I made was assuming that every 1 bit during the clock
rate
would convert the flip flop.

But this is not the case... the flip flop only changes when the 1 change
from 1 to zero or vice versa...

So my first assumption that it worked like this was wrong:

11001100110011001100

Suppose a flip flop was connected to this bit stream.

I thought that each 1 would convert the next flip flop like this:
10001000100010001000

Which is wrong

The flip flop only changes when the input changes from 1 to zero.

So given the input stream:
11001100110011001100

The flip flop output stream would be:
( assuming it changes on a fall from 1 to zero)
00111100001111000011

Etc... truely halving the signal etc.

Now the last tricky part is in reading the outputs...

Let's draw it one more time:

Clock rate: 01010101010101010101
Q1 : 00110011001100110011
Inverter : 11001100110011001100
Q2 : 00001111000011110000

Oops I see I messed up here

Had to take the inverter for Q2

Clock rate: 01010101010101010101
Q1 : 00110011001100110011
Inverter : 11001100110011001100
Q2 : 00111100001111000011

So filtering out Q1 and Q2:

Q1 : 00110011001100110011
Q2 : 00111100001111000011

Clock rate: 01#01#01#01#01#01#01#01#01#01
Q1 : 00#11#00#11#00#11#00#11#00#11
Q2 : 00#11#11#00#00#11#11#00#00#11

Reading Q1 and Q2 during the clock tick gives the following stable result:

Q1 : 0#1#0#1#0#1#0#1#0#1
Q2 : 0#1#1#0#0#1#1#0#0#1

Now putting this next to each other:

Q1, Q2
00
11
01
10
00
11
01
10
00
11
01

Yeah maybe we still need to switch em around

00
11
10
01
00
11
10
01
00
11
10

Ok this looks a bit better

Apprently a countdown counter ?

Or did I mess up again somewhere ?

Tricky, tricky,tricky,tricky

Bye,
Skybuck.

 

[Ralf Hildebrandt]

Skybuck Flying wrote:

I am new to electronics and VHDL etc.

I am trying to understand the first 2 bit counter example. In this PDF:

http://tech-www.informatik.uni-hamburg.de/vhdl/doc/cookbook/VHDL-Cookbook.pdf

I would not recommend Ashendens VHDL Cookbook for a beginner, because
there are several traps and pitfalls in it if you aim for synthesizable
VHDL code.
It is good document for somebody, who has basic VHDL knowledge -
especially, if some synthesizable circuits have been already done. Then
this Cookbook is a really good overview over the language and its
capabilities.
Nevertheless Ashendens Cookbook highlights VHDL as a programming
language - not as a modelling language for real-world synthesizable
circuits.


Let me explain one of these traps in this book - fig. 1-2 is described
with the following code:

---
count_up: process (clock)
variable count_value : natural := 0;
begin
if clock = '1' then
-- ... and so on
end if;
end process count_up;
---

This coding style will work in simulations, because everytime if clock
changes, the process is triggered and then because of the if-statement
the code inside the if-clause is executed with the rising_edge(clock).

But much more clear and recommended for synthesizable code ist:

---
count_up: process (clock)
variable count_value : natural := 0;
begin
if rising_edge(clock) then
-- ... and so on
end if;
end process count_up;
---

Furthermore, I guess, that the original code will not result after
synthesis in flipflops as wanted! The synthesis tool will give a
warning, that the sensitivity list is incomplete and will threat it as
latches, wich will result in this example in an infinite loop.

Short: Synthsis and simulation differ!


If the original code would be really recognized as a flipflop
description, most synthesis tools will use D-FFs and therefore fig. 1-2
and the code do not have much in common.
Using modulo in the description does not lead to a code, that can be
understood well. I would suggest for a 2 bit counter:

library IEEE;
use IEEE.std_logic_1164.all,IEEE.numeric_std.all
--...
process (reset, clock)
variable count_value : unsigned(1 downto 0);
begin
if (reset='1') then
count_value:=(others=>'0');
-- type bit does not need a reset, but real-world circuits do
-- unsigned is 'U' (unknown) at simulation start
elsif rising_edge(clock) then
count_value:=count_value + 1; -- automatic overflow
end if;
q0<=count_value(0);
q1<=count_value(1);
end process;


A second pitfall is the type bit or bit_vector, that is used by
Ashenden. Because bit is only '1' or '0', no unknown values can be
represented. Use std_ulogic(_vector), std_logic(_vector), signed or
unsinged instead.



Ralf

 

[Skybuck Flying]

"Ralf Hildebrandt" <Ralf-Hildebrandt@gmx.de> wrote in message
news:3l9u95F11g5ssU1@individual.net...

Skybuck Flying wrote:


I am new to electronics and VHDL etc.

I am trying to understand the first 2 bit counter example. In this PDF:


http://tech-www.informatik.uni-hamburg.de/vhdl/doc/cookbook/VHDL-Cookbook.pdf

I would not recommend Ashendens VHDL Cookbook for a beginner, because
there are several traps and pitfalls in it if you aim for synthesizable
VHDL code.
It is good document for somebody, who has basic VHDL knowledge -
especially, if some synthesizable circuits have been already done. Then
this Cookbook is a really good overview over the language and its
capabilities.
Nevertheless Ashendens Cookbook highlights VHDL as a programming
language - not as a modelling language for real-world synthesizable
circuits.


Let me explain one of these traps in this book - fig. 1-2 is described
with the following code:

---
count_up: process (clock)
variable count_value : natural := 0;
begin
if clock = '1' then
-- ... and so on
end if;
end process count_up;
---

This coding style will work in simulations, because everytime if clock
changes, the process is triggered and then because of the if-statement
the code inside the if-clause is executed with the rising_edge(clock).

I read a PDF about the possibility of computers without a clock.

http://www.sun.com/processors/throughput/SciAm_Reprint.pdf

Since I am not really used to programming with clocks and stuff like that...
an async system might be much easier
to program for an application programmer like me

Anyway my question is: Can VHDL be used to program such a async device ?

The document itself says that most tools are far behind etc... so I wouldn't
be too surprised if VHDL and Verilog don't support it.

Are there any HDL languages that do support these async type of
ideas/devices etc ?

Ok back to the VHDL topic:

But much more clear and recommended for synthesizable code ist:

---
count_up: process (clock)
variable count_value : natural := 0;
begin
if rising_edge(clock) then
-- ... and so on
end if;
end process count_up;
---

Rising_edge is that a predefined function ?

Furthermore, I guess, that the original code will not result after
synthesis in flipflops as wanted! The synthesis tool will give a
warning, that the sensitivity list is incomplete and will threat it as
latches, wich will result in this example in an infinite loop.

Short: Synthsis and simulation differ!

entity count2 is

generic (prop_delay : Time := 10 ns);

port (clock : in bit;

q1, q0 : out bit);

end count2;

architecture behaviour of count2 is

begin

count_up: process (clock)

variable count_value : natural := 0;

begin

if clock = '1' then

count_value := (count_value + 1) mod 4;

q0 <= bit'val(count_value mod 2) after prop_delay;

q1 <= bit'val(count_value / 2) after prop_delay;

end if;

end process count_up;

end behaviour;


architecture structure of count2 is

component t_flipflop

port (ck : in bit; q : out bit);

end component;

component inverter

port (a : in bit; y : out bit);

end component;

signal ff0, ff1, inv_ff0 : bit;

begin

bit_0 : t_flipflop port map (ck => clock, q => ff0);

inv : inverter port map (a => ff0, y => inv_ff0);

bit_1 : t_flipflop port map (ck => inv_ff0, q => ff1);

q0 <= ff0;

q1 <= ff1;

end structure;

If you right that would be bad and nasty.

Since in the original code at first glance there is no loop ?

If the original code would be really recognized as a flipflop
description, most synthesis tools will use D-FFs and therefore fig. 1-2
and the code do not have much in common.
Using modulo in the description does not lead to a code, that can be
understood well. I would suggest for a 2 bit counter:

library IEEE;
use IEEE.std_logic_1164.all,IEEE.numeric_std.all
--...
process (reset, clock)
variable count_value : unsigned(1 downto 0);
begin
if (reset='1') then
count_value:=(others=>'0');
-- type bit does not need a reset, but real-world circuits do
-- unsigned is 'U' (unknown) at simulation start
elsif rising_edge(clock) then
count_value:=count_value + 1; -- automatic overflow
end if;
q0<=count_value(0);
q1<=count_value(1);
end process;


A second pitfall is the type bit or bit_vector, that is used by
Ashenden. Because bit is only '1' or '0', no unknown values can be
represented. Use std_ulogic(_vector), std_logic(_vector), signed or
unsinged instead.

The code example uses "natural" for the count_value.

variable count_value : natural := 0;
begin

if clock = '1' then

count_value := (count_value + 1) mod 4;

q0 <= bit'val(count_value mod 2) after prop_delay;

q1 <= bit'val(count_value / 2) after prop_delay;



Are the mod 4, mod 2 and /2 statements/operations allowed ?

I see you have defined

variable count_value : unsigned(1 downto 0);

Does this mean "natural" is bad for synthesis ?

I do realize the pdf/cookbook is pretty old (from 1990).

So far I have been reading stuff to get a feel for things.

Though writing code costs lot's of time so once I would get to that point...
it would be better to do it as good as possible so that
"synthesis" might be possible without too much problems

Can you recommand any VHDL programmer's references or tutorial which are
good for "synthesis" ?

Bye,
Skybuck.

 

[Ralf Hildebrandt]

Skybuck Flying wrote:

I read a PDF about the possibility of computers without a clock.

http://www.sun.com/processors/throughput/SciAm_Reprint.pdf

Since I am not really used to programming with clocks and stuff like that...
an async system might be much easier
to program for an application programmer like me

No - the opposite is valid: It is quite easy to model a synchronous system.

And let me add: Forget "programming". Hardware has to modelled.
Programming VHDL is o.k. for non-synthesizable testbenches, but for real
hardware VHDL is more a textual CAD software than and programming language.

Anyway my question is: Can VHDL be used to program such a async device ?

AFAIK yes - I've heard about it, but did never such heavy stuff.

The document itself says that most tools are far behind etc... so I wouldn't
be too surprised if VHDL and Verilog don't support it.

It is not the language itself, that makes this difficult but also the
nessecary hardware for totally asynchronous devices.

---
count_up: process (clock)
variable count_value : natural := 0;
begin
if rising_edge(clock) then
-- ... and so on
end if;
end process count_up;
---

Rising_edge is that a predefined function ?

Yes. It is almost the same as

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

but it is recommended to use rising_edge. Furthermore it makes the code
easy to read.


[quoting repaired]

count_up: process (clock)
variable count_value : natural := 0;
begin
if clock = '1' then
count_value := (count_value + 1) mod 4;
q0 <= bit'val(count_value mod 2) after prop_delay;
q1 <= bit'val(count_value / 2) after prop_delay;
end if;
end process count_up;
end behaviour;
....
Since in the original code at first glance there is no loop ?

Yes - for simulation. But a synthesis tool does not find an 'event
attribute and therefore assumes, that this process describes a latch.
(Well .. I guess so. I have no synthesis tool at hand at the moment,
because I am at home.)

A second pitfall is the type bit or bit_vector, that is used by
Ashenden. Because bit is only '1' or '0', no unknown values can be
represented. Use std_ulogic(_vector), std_logic(_vector), signed or
unsinged instead.


The code example uses "natural" for the count_value.

I was talking about Ashendens Cookbook in general. He uses bit(_vector)
in general.

Are the mod 4, mod 2 and /2 statements/operations allowed ?

Yes.

I see you have defined

variable count_value : unsigned(1 downto 0);

Does this mean "natural" is bad for synthesis ?

No - but using an unsigned vector is more handy for this example.
* The range definition makes it clear, how many flipflops will be
inferred. This helps me reading the code and the synthesis tool gets
an easier job.
* Overflow is handled automatically.
- Natural is a subtype of integer beeing 0 or any other positive
value. Usually integer is a 32 bit data type. The unused bits have
to be removed by the synthesis tool.
- To make it clear, that only the range 0 to 3 is desired, you could
declare count_value to be "natural range 0 to 3". But then, if 3 is
reached, adding a 1 would result in a range violation and therefore
you have to add manually a statement like
if (count_value=3) then
count_value:=0;
else count_value:=count_value+1;
end if;
Using the unsigned vector, this extra statement can be saved, wich
makes the code more readable.
* Because q0 and q1 have to be derived from count_value, your could use
the modulo approach like in Ashendens example or you could convert the
natural to unsigned. Both is not well readable. From the unsigned
vector the desired bits can be derived very easy as I have shown in my
example.

Note that everything, that was mentioned are just reasons for nice
readable code. Synthesis results using natural or unsigned will be the
same - except for synthesis time maybe.

I do realize the pdf/cookbook is pretty old (from 1990).

This is not a reason pro or contra this Cookbook. There are only a few
points, that have changed during the years. (e.g. the recommendation for
std_(u)logic_(vector) and for the library IEEE.numeric_std)

Unfortunately Ashendens Cookbook is a really nice example how to
_program_ with VHDL. And as I told you: Forget programming if you aim
for synthesizable code.

Can you recommand any VHDL programmer's references or tutorial which are
good for "synthesis" ?

I've learned VHDL with "HDL chip design" from Douglas J. Smith, Doone
Publications. I teaches both VHDL and Verilog, which makes it great, if
you (unfortunately ;-)) have to learn Verilog later.

And let me add a general hint: There are 3 things in a HDL you need:
combinational logic, flipflops and (if you want) latches. Almost
everything synthesizable can be described with this.


Ralf