Clock Edge notation

Where do you suggest I give my shift_out line then....Should I give it
outside the process instead?
Yes, writing 'procedure' I was thinking about the process .



when 625 => shift_out <= shift_register(624);
when 624 => shift_out <= shift_register(623);
when 623 => shift_out <= shift_register(622);
Are you insane? Design is all about reuse and avoiding redundancies. All you
need:
shift_out <= shift_register(offset);

.... and do it outside the process. At least outside the clocked loading
block of the process.
 
You can avoid the 'U'|'X'|'W'|'Z'|'-' warnings at time zero by replacing
your "run xx" by:

set StdArithNoWarnings 1
run 0 ns;
set StdArithNoWarnings 0
run xx;

Hans
www.ht-lab.com

"srinukasam" <srinukasam@yahoo.co.in> wrote in message
news:1da19c11ea4dca3b83589e57c1adf77f@localhost.talkaboutprogramming.com...
HI TO ALL
I designed a mux which gives multiple outputs. but at the time of
simulation with model sim iam getting some warning with generate command.
And my testbench is working for my design.the only problem is warning.i
want to get rid of those warnings.pls help me.

Warnings..

# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand,
the result will be 'X'(es).
# Time: 0 ns Iteration: 0 Instance: /mux_ge_tb/mut/ge1__5/mut1
# ** Warning: CONV_INTEGER: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, and it has been converted to 0.
# Time: 0 ns Iteration: 0 Instance: /mux_ge_tb/mut/ge1__5/mut1
# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand,
the result will be 'X'(es).
# Time: 0 ns Iteration: 0 Instance: /mux_ge_tb/mut/ge1__4/mut1
# ** Warning: CONV_INTEGER: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, and it has been converted to 0.
# Time: 0 ns Iteration: 0 Instance: /mux_ge_tb/mut/ge1__4/mut1
# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand,
the result will be 'X'(es).
# Time: 0 ns Iteration: 0 Instance: /mux_ge_tb/mut/ge1__3/mut1
# ** Warning: CONV_INTEGER: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, and it has been converted to 0.
# Time: 0 ns Iteration: 0 Instance: /mux_ge_tb/mut/ge1__3/mut1
# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand,
the result will be 'X'(es).
# Time: 0 ns Iteration: 0 Instance: /mux_ge_tb/mut/ge1__2/mut1
# ** Warning: CONV_INTEGER: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, and it has been converted to 0.
# Time: 0 ns Iteration: 0 Instance: /mux_ge_tb/mut/ge1__2/mut1
# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand,
the result will be 'X'(es).
# Time: 0 ns Iteration: 0 Instance: /mux_ge_tb/mut/ge1__1/mut1
# ** Warning: CONV_INTEGER: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, and it has been converted to 0.
# Time: 0 ns Iteration: 0 Instance: /mux_ge_tb/mut/ge1__1/mut1
# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand,
the result will be 'X'(es).
# Time: 0 ns Iteration: 0 Instance: /mux_ge_tb/mut/ge1__0/mut1
# ** Warning: CONV_INTEGER: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, and it has been converted to 0.
# Time: 0 ns Iteration: 0 Instance: /mux_ge_tb/mut/ge1__0/mut1


DESIGN FOR COMPONENT-----

LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;

entity mux is
generic ( input_w :integer :=16; --input signal width
ictrl_w :integer :=4); -- individual control signal
width

port(input:in std_logic_vector (input_w-1 downto 0);
ctrl: in std_logic_vector (ictrl_w-1 downto 0);
out_mux:eek:ut std_logic);
end entity mux;

architecture mux_beh of mux is
begin
out_mux<=input(conv_integer(ctrl));
end architecture mux_beh;

COMPONENT IS USED IN THIS DESIGN -------

LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_arith.all;


ENTITY mux_ge IS
generic ( input_w :integer :=16; --input signal width
ictrl_w :integer :=4; -- individual control signal
width
tctrl_w : integer :=24; -- total control signal width--mem
out
no_out,no_ctrl :integer :=6); -- no of output
signals(r),no.of control signals (V)

port( input:in std_logic_vector(input_w-1 downto 0);
tctrl: in std_logic_vector(tctrl_w-1 downto 0);
out_fmux:eek:ut std_logic_vector(no_out-1 downto 0));
END ENTITY mux_ge;

--
ARCHITECTURE mux_ge_str OF mux_ge IS

component mux

generic ( input_w :integer :=16; --input signal width
ictrl_w :integer :=4); -- individual control signal
width

port(input:in std_logic_vector(input_w-1 downto 0);
ctrl:in std_logic_vector(ictrl_w-1 downto 0);
out_mux: out std_logic);
end component mux;


BEGIN
ge1:for i in 0 to no_out-1 generate

mut1:mux port map(input,tctrl((i*ictrl_w)+(ictrl_w-1) downto
i*ictrl_w),out_fmux(i));
end generate ge1;


END ARCHITECTURE mux_ge_str;

configuration mux_ge_config of mux_ge is
for mux_ge_str
for all:mux
use entity work.mux(mux_beh);
end for;
end for;
end configuration mux_ge_config;
 
praveen.kantharajapura@gmail.com wrote:

Hi all,

In my design all the modules are in VHDL except one which is in
verilog.I wanted to know if it is possible to call my verilog module in
my VHDL top level.

If possible can any body tell me how to go about it.

Regards,
Praveen



Hi Praveen,
You will have to create a wrapper for the Verilog model as:

Entity <module name> is
End <module name>;

architecture verilog of <name> is
attribute foreign of verilog:architecture is "VERILOG(event)
work.<module name>:modulel";
begin
end;

In case you are using NCSIM, you can directly instantiate the verilog
component in VHDL.
NCSIM allows the instantiation of the Verilog in VHDL either through
direct instantiation, component binding or default bindings.

-Tarun
 
"valentin tihomirov" <spam@abelectron.com> writes:

signal shift_register : std_logic_vector ( (left-1) downto 0 ):= (others
=> '0');

Natural std_logic_vector range is (1 to length). It is up to you, just some
std functions may malfunction on you vectors.
Huh? I've been doing std_logic_vector (msb downto lsb) for years and
never had any problems. I don't think there is any "naturalness"
about doing (1 to something). Or have I misunderstood what you are saying?

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt
 
Elinore wrote:


process(...)
begin
...
You left the most important facts!
Because of the following code:

case S is
when S1 => offset <= "00000001";
S<=S2;
when S2 => address <= address + offset; -- (1)
offset <= offset + '1'; -- (2)
the only possible process is a synchronous process, sensitive to the
edge of a clock - e.g.:

process(reset,clock)
begin
if (reset = '1') then
-- do some reset
elsif rising_edge(clock) then
case S is
-- and so on




Above VHDL description is not working in simulation as I expect. When I
modify the code as following, it is working as I expect, ie, after S2
clock cycle, address is "1" and offset is "1".

------Description 2----------------------------------------------
...
when S2 => address <= address + offset; -- (1)
offset <= offset + '1'; -- (2)

when S3 => if offset = '1' then S <= S3; enf if; -- (4)
---------------------------------------------------------------
Remember that assigning a value to a signal (the "<=" operator) results
in assigning the value in the next delta delay. Therefore such things like

offset <= offset + 1;
if (offset = ...) then

results in testing for the /old/ value of offset.


Ralf
 
& is concatenation; I think it's what you're looking for:

your_signal(31 downto 0) <= bobs_signal(31 downto 24) & "00000000" &
alices_signal(15 downto 8) & that_wire & and_this_one & '1' &
and_so_on(4 downto 0);
 
Andy Peters wrote:

Given a top-level entity that instantiates some lower-level entites, do
you:

a) instantiate the lower-level modules as entities, e.g.,

u_foo : entity work.foo
port map ( signals );

b) instantiate the lower-level modules as components, e.g.,

u_foo : component foo
port map (signals );

The advantage of a) is that you don't have to type the lower-level
entity's port interface declaration in your architecture.
And you only have to keep 2 port lists lined up instead of 3.

The
disadvantages of a) is that you don't see that entity's interfaces in
your architecture,
Tolerable with a good editor.

and you have to ensure that you compile the
lower-level entities before the higher-level ones.
That is tolerable using make.
The advantage of b) is that it's clear what signals the lower-level
entity needs. The disadvantage is that if you change the interface to
the lower-level entity (in its source file), you have to make sure that
you change the component declaration in your higher-level module's
architecture. Keeping these in sync could be a problem.
I find this too tedious. I vote for A.

-- Mike Treseler
 
Calvin wrote:
I am aware of three main styles for state machine coding: Medvedev,
Moore and Mealy. Recently, one of my coworkers introduced a "hybrid"
one as follows:

p_reg: process(rst, clk)
begin
if rst = '0' then
current_state <= st_idle;
current_output <= cmb_idle;
elsif rising_edge(clk) then
current_state <= next_state;
current_output <= next_output;
end if;
end process p_reg;
-> A state machine with buffered outputs


He said this is the best approach for state machine coding.
I truly appreciate any comments as well as pros/cons for this approach.
Somebody here in the newsgroup once stated: "Forget Mealy-, Moore- and
other types of state machines." I agree with this and suggest: Use any
type of output generation, that is suitable for your special purpose.

* If you need buffered (hazard-free) outputs, use flipflops.
* If you don't need hazard-free outputs, you don't need buffers and
therefore the outputs may be generated from pure combinational logic.
* If your output depends on the value of an input - use it. If you need
input buffers to make the input hazard-free - use them.

In general: A FSM and their output signals are nothing more than a bunch
of combinational logic and some flipflops. For every flipflop you have
to ensure, that setup- and hold-times are not violated and for every
output you have to decide, if it must be hazard-free or not.

Ralf
 
Brandon wrote:

From reading old posts, I see it is not possible to have an array of
generic-width std_logic_vector in an entity. I've seen some of the work
arounds, including using the type std_logic_matrix, but I'm not
entirely happy with them (none of them are straightforward).

entity myentity is
generic (
depth: integer;
width: integer
port (
x : in arrayofstdlv_t(depth-1 downto 0)(width-1 downto 0);
...
);
end entity myentity;
Remember, that some old synthesis tools are not capable of synthesizing
2D-arrays!

Every x-dimensional array can be broken down into a (x-1)-dimensional
array until you have reached the 1D-array.
Example: The 2D-array

1,2,3,4
5,6,7,8
a,b,c,d

can also be written as the 1D-array

1,2,3,4,5,6,7,8,a,b,c,d

Therefore it is always possible to break arrays in entities down to
1D-arrays (vectors).


Ralf
 
Ralf Hildebrandt wrote:


Somebody here in the newsgroup once stated: "Forget Mealy-, Moore- and
other types of state machines." I agree with this and suggest: Use any
type of output generation, that is suitable for your special purpose.
Indeed. Synthesis has been done.
Spend your time describing and simulating your design.

-- Mike Treseler
 
Keyvan Jamaleddin wrote:
Hi everyone,
I got some errors while i was compiling the standard moore model for
and i don't know what it means.

Library ieee;
Use ieee.std_logic_1164.all;
Entity ali is
Port (clk,reset,x :IN STD_LOGIC;
Z :OUT STD_LOGIC);
End ali;

Architecture behavior of ali is
Type statetype is (s1,s2,s3,s4,s5,s6,s7,s8,s9,s10,s11,s12,
s13,s14,s15,s16,s17,s18,s19,s20,s21,
s22,s23,s24,s25,s26,s27);
signal state : statetype;
Begin
something is missing here.

"process (clk, reset)
begin"

might help?

IF reset = '1' then
State<=state'LEFT;
ELSIF (clk'event and clk = '1')then
Case state is
 
Colin Marquardt wrote:

I document testcases as comments with a special prefix. These are
then filtered out and processed with LaTeX, giving a nice PDF
file. One could also embed diagrams in description languages like
pstricks, metapost, dot, pic etc. and handle them in the same way.
If somebody has already done this, I'd love to hear about it.
I stick to plain text with block diagrams like this

--[foo]---[bar]---[bas]--

and timing diagrams like this
--foo ___--__-_-__----
--bar ___-____-_-_-___

I like to print out code and lay down
and mark it up, so I limit my lines to 78 characters and
use the vhdl-print-two-column setting in vhdl-mode.

To the original poster: take a look at emacs' vhdl-mode and its
integration into speedbar for a hierarchy parser.
Yes, that meets the OP's public domain / open source spec,
and there is no better way to navigate a complex design.

-- Mike Treseler
 
"Hubble" <reiner@huober.de> writes:

<snip>

If you want to disable/enable logic, use boolean generics and if
statements:

GENERIC in_synthesis: boolean:= true;
..

If not in_synthesis then
... (some logic here)
end If;
I do this in a package:

CONSTANT in_simulation : BOOLEAN := false
--synthesis translate_off
OR true
--synthesis translate_on
;
CONSTANT in_synthesis : BOOLEAN := NOT in_simulation;

Then I don't have to worry about remembering to change the constant
when I synthesize. And there's only one set of pragmas in the whole
design to worry about.

Cheers,
Martin


--
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt
 
skatoulas@hotmail.com wrote:

I've got the following problem. I've got a generic integer input to an
entity that defines the number of S-R flip flops to be created.
Consider a higher level description of your logic.

The problem here is that there have to be ceiling(log2(num_of_nodes-1))
http://groups-beta.google.com/groups?q=round+ceil_log2

-- Mike Treseler
 
Hi Suman,

Verific DOES allow nesting of translate_off pragma's.
The Verific parsers are used in some 35 EDA tools, including
synthesis and verification tools.
For example, Altera's Quartus II synthesis uses the Verific's parsers,
and thus it will support translate_off nesting.

Sometimes nesting happens legally in the standard VHDL packages, albeit
under different 'vendor' translate_on/off pragma's.
Verific needs to be complient with many different tools, and thus needs to
be sensitive to many tool vendor pragma's. Thus support for nesting was needed.

The problem with pragma's is that there is no written spec on how they should work.
So if you can, try to avoid them.

Rob

<suman.nandan@gmail.com> wrote in message news:1121403963.905016.111000@z14g2000cwz.googlegroups.com...
Hi all,
Can anyone tell me what should be the ideal behaviour for a
synthesis tool regarding the pragmas translate_off/on and
synthesis_off/on ?
My question is, can we nest the pragmas one inside the other ?
like say ..

-- pragma translate_off
-- pragma synthesis_off
... (some logic here)
-- pragma synthesis_on
-- pragma translate_on

or

-- pragma tranlate_off
-- pragma synthesis_off
...(some logic here)
-- pragma tranlate_on
-- pragma synthesis_on

I have heard that DC ignores such nesting and take the outermost
into account. Can you tell me what is the behaviour of other tools ?

Thanks.
 
Giving the value of:

shift_out <= shift_register(left-1); within the same process(clk) is
also working fine.....
At first, assigning at clk edge will change funcinonality inferring an FF.
Secondly, shift_out is the entity-wide signal, there is no need to hide it
in the process scope.
 
Huh? I've been doing std_logic_vector (msb downto lsb) for years and
never had any problems. I don't think there is any "naturalness"
about doing (1 to something). Or have I misunderstood what you are
saying?

What do you think will be result of

key := ((BS(0) and x"01") sll 6) or ((BS(1)srl 2) and x"3F");

where
subtype BYTE is std_logic_vector (7 downto 0);
type TBYTE_STR is array (0 to 6) of BYTE;
variable BS: TBYTE_STR;
key: BYTE;

Check the "and" and "sll" functions in the std_logic_1164 package, they both
return
VARIABLE result : std_logic_vector ( 1 TO l'LENGTH );

Getting once into trouble, I had to overwrite the standard functions to
return vector having the same range as the first argument.
 
hello Hans
i didnt understood what is your replacement for my problem( modelsim
error).
could you please send me some detailed reply.
thank you
bye
 

Welcome to EDABoard.com

Sponsor

Back
Top