[SOLVED] Programmable down counter

Pavithra89 · Mar 18, 2013

Hi
Im new to electronics and this forum as well. I have been given to design a programmable down counter using CPLD. I wrote the code in vhdl and i simulated using test bench. But what I really wanted to know what output should i check in oscilloscope and show it to my teacher. He asked to me show output frequency change when preset input value is changed Im not able to figure out what s he trying to say :} m exactly dumb to his questions.. Please help me asap :I

barry · Mar 18, 2013

I presume you've got a counter that reloads itself every time it reaches zero, correct? If so, you should be able to look at your LOAD signal whose frequency will change depending on the load value.

Pavithra89 · Mar 19, 2013

thank you for ur reply yes u presumed right. but what is load signal in my code. This s my code please find time to help me in this

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
 
entity enter1 is
    Port ( reset : in  STD_LOGIC;
           clock : in  STD_LOGIC;
           input : in  STD_LOGIC_VECTOR (7 downto 0);
           output : out  STD_LOGIC_VECTOR (7 downto 0);
           pulse : out  STD_LOGIC;
           clk_out : out  STD_LOGIC);
end enter1;
 
architecture Behavioral of enter1 is
signal pre_count:std_logic_vector(7 downto 0);
signal count:std_logic:='0';
signal div_clk:std_logic:='1';
begin
    process(clock,reset,input)
    begin
        if reset = '1' then
        pre_count<=input;
            elsif clock'event and clock='1' then
                       div_clk<=not div_clk;
               pre_count<=pre_count-1;
                if pre_count=input then
                                   pre_count<="00000000";
                    count<='1';
                else
                    count<='0';
                end if;
        end if;
    end process;
clk_out<=div_clk;
pulse<=count;
output<=pre_count;      
end Behavioral;

Waiting for your suggestions
Regards

barry · Mar 19, 2013

You've got that signal "count", which goes high for one clock-cycle when your counter is reloaded. This signal goes to your output, "pulse". So....
If you do a simulation of this it should be obvious to you.

Just as a point of style, there's no reason to have a signal called "count" which then gets connected to an output with a totally different name, "pulse". That makes things a LOT harder to follow; you could have just assigned "pulse" inside your process. On the occasions where you need to read the value of an output(and, thus have to use a signal, for instance your clk_out/div_clk thing) what I usually do is give the signal a name similar to the output, for example port name=clk_out; signal name=clk_out_s. Otherwise you can spend a lot of time tracking down signals if they keep changing name along the path.

K-J · Mar 19, 2013

barry said:
On the occasions where you need to read the value of an output(and, thus have to use a signal, for instance your clk_out/div_clk thing) what I usually do is give the signal a name similar to the output, for example port name=clk_out; signal name=clk_out_s.

Or simply change the output signal from 'out' to 'buffer' (will work with all versions of VHDL), or compile using VHDL-2008 (assuming the tool supports 2008).

Kevin

std_match · Mar 19, 2013

K-J said:
Or simply change the output signal from 'out' to 'buffer' (will work with all versions of VHDL), or compile using VHDL-2008 (assuming the tool supports 2008).

Kevin

Don't use buffer if you design a sub-block that will be used by other people.
When you instantiate a block with "buffer" outputs, they can't be connected to "out" outputs, which is a pain in the a**.
This is the case with VHDL 87 and 93, not sure about VHDL-2003.
My suggestion is to never use "buffer".
I have sometimes tried to use the attribute "driving_value" instead, but some tool didn't accept it.
The safe way for all versions of VHDL is to use an intermediate signal, preferably with a name very similar to the "out" output.

K-J · Mar 20, 2013

std_match said:
Don't use buffer if you design a sub-block that will be used by other people.
When you instantiate a block with "buffer" outputs, they can't be connected to "out" outputs, which is a pain in the a**. This is the case with VHDL 87 and 93, not sure about VHDL-2003.

This behavior was changed with VHDL-2002. That specification is now 10+ years old. Limiting yourself to only using language definitions that are 20+ years old is a choice you can make but is probably not very useful.

My suggestion is to never use "buffer".

While your suggestion is not 'wrong', it is based on ancient behavior that has long since been changed.

I have sometimes tried to use the attribute "driving_value" instead, but some tool didn't accept it.
The safe way for all versions of VHDL is to use an intermediate signal, preferably with a name very similar to the "out" output.

The need to have source code that is compliant with tools that only support VHDL '87 and VHDL '93 is likely next to non-existent. If your tool doesn't support a 10 year old specification then you should really take a look at using other tools.

Kevin Jennings

Pavithra89 · Mar 20, 2013

barry said:
You've got that signal "count", which goes high for one clock-cycle when your counter is reloaded. This signal goes to your output, "pulse". So....
If you do a simulation of this it should be obvious to you.

Just as a point of style, there's no reason to have a signal called "count" which then gets connected to an output with a totally different name, "pulse". That makes things a LOT harder to follow; you could have just assigned "pulse" inside your process. On the occasions where you need to read the value of an output(and, thus have to use a signal, for instance your clk_out/div_clk thing) what I usually do is give the signal a name similar to the output, for example port name=clk_out; signal name=clk_out_s. Otherwise you can spend a lot of time tracking down signals if they keep changing name along the path.

owwww thank u very much .. it worked :}

- - - Updated - - -

It just worked... Thank u all

TrickyDicky · Mar 20, 2013

K-J said:
This behavior was changed with VHDL-2002. That specification is now 10+ years old. Limiting yourself to only using language definitions that are 20+ years old is a choice you can make but is probably not very useful.

The problem is, tools like quartus only support '93. They seem to have skipped 2002 and picked a few choice bits from 2008, but usually without all the support that was in 2002 like the above.
I would think it safer to stick with the '93 version while raising a support request with altera to get their act together.

K-J · Mar 20, 2013

TrickyDicky said:
The problem is, tools like quartus only support '93. They seem to have skipped 2002 and picked a few choice bits from 2008, but usually without all the support that was in 2002 like the above.

They do support 2002 in the case being discussed (i.e. connecting 'buffer' to an 'out')

I would think it safer to stick with the '93 version while raising a support request with altera to get their act together.

Or just try it out and find that the tool supports it just fine.

Kevin Jennings

[SOLVED] Programmable down counter

Pavithra89

Member level 2

barry

Advanced Member level 7

Pavithra89

Pavithra89

Member level 2

barry

Advanced Member level 7

K-J

Advanced Member level 2

std_match

Advanced Member level 4

K-J

Advanced Member level 2

Pavithra89

Member level 2

TrickyDicky

Advanced Member level 7

K-J

Advanced Member level 2

Similar threads

[SOLVED] Programmable down counter

Member level 2

Advanced Member level 7

Member level 2

Advanced Member level 7

Advanced Member level 2

Advanced Member level 4

Advanced Member level 2

Member level 2

Advanced Member level 7

Advanced Member level 2

Similar threads

Privacy & Transparency

Privacy & Transparency