A few question about vhdl(clk,signal,etc..)

Guest
hi,
i want to know two things about vhdl signal...
why to use signal count: STD_LOGIC_VECTOR(3 downto 0);
when i use a clock and do counting+1 in the state machine?
and for what to configure it 3 downto 0...
in addtion for what i use signal at all?
thank's
nati
 
On 6/2/2013 3:57 AM, natiben27@gmail.com wrote:
hi,
i want to know two things about vhdl signal...
why to use signal count: STD_LOGIC_VECTOR(3 downto 0);
when i use a clock and do counting+1 in the state machine?
and for what to configure it 3 downto 0...
in addtion for what i use signal at all?
thank's
nati

It sounds like you could use some quality time with a VHDL
textbook.

Basically you must use a signal if you need to use the value
of count outside the process with your state machine. If you
don't need to use its value outside this process, you could
use a variable instead of a signal, but then you need to
understand the difference in the way variables are updated.

There's no real reason to use standard_logic_vector for a
counter unless you're also placing this on a port of the entity,
where you generally avoid other problems by sticking with
standard logic / vectors. Otherwise you'd normally use
a ranged natural or integer.

--
Gabor
 
Am Sonntag, 2. Juni 2013 09:57:57 UTC+2 schrieb nati...@gmail.com:
why to use signal count: STD_LOGIC_VECTOR(3 downto 0);

when i use a clock and do counting+1 in the state machine?

and for what to configure it 3 downto 0...
a vector(3 downto 0) means you have 4 bit width. This is easy to adopt on your hardware needs. YOu could for instance use integer instead and have the problem, that you could end up with a 32 bit width counter while needing only 4 bit. If you detect later that you need not 4 bit width but 400 bit width, it is easy to change in vector, but impossible in integer. Plus the issue that integer is quite special in VHDL concerning covered range (see lrm, or google for details).

bye Thomas
 
Gabor,

I would say "top level" entity. Lower level entities (whose ports are not those of the FPGA) are fine for other data types.

The top level is special, because the gate level model produced after synthesis and/or place & route will always use std_logic and std_logic_vector for the ports, regardless of what types the RTL used. If you want to use both RTL and post-S/P&R models in the same testbench (without constructing a wrapper for the latter), then only use std_logic and std_logic_vector data types for the ports on the top level entity.

Andy
 

Welcome to EDABoard.com

Sponsor

Back
Top