«

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-hambu...L-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 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-hambu...L-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

"Ralf Hildebrandt" <Ralf-> wrote in message
news:...
> 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-hambu...L-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/throug...Am_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.

Skybuck Flying wrote:


> I read a PDF about the possibility of computers without a clock.
>
> http://www.sun.com/processors/throug...Am_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