Simulation of VHDL code for a vending machine

rickman wrote:

>>> That is the common default for bits.
>> ?
>>> The *only* advantage is it covers tristate signals.

>> sure. But I don't have/need tristates.

Neither do I.
My default for I/0 bits is std_ulogic.
But this is not common.
I don't know why.

    -- Mike Treseler

Mike Treseler wrote:
> rickman wrote:
>>>> That is the common default for bits.
>>> ?
>>>> The *only* advantage is it covers tristate signals.
>>> sure. But I don't have/need tristates.
> Neither do I.
> My default for I/0 bits is std_ulogic.
it was too, for me.

I may have found that some parts of my code used
std_logic and others used std_ulogic, but then
why take the risk of not detecting conflicts
with multiple drivers AND simulating slower ?

> But this is not common.
> I don't know why.
I'm puzzled.

However I'll try to implement a small set of libraries
that implement a "common" type for all my bits and
vectors, so it's easier to switch between different types
and subtypes and watch the difference.

>    -- Mike Treseler
yg

-- 
http://ygdes.com / http://yasep.org

whygee wrote:

> I may have found that some parts of my code used
> std_logic and others used std_ulogic, but then
> why take the risk of not detecting conflicts
> with multiple drivers AND simulating slower ?

I expect there is no logical reason.
Just tradition.


        -- Mike Treseler

rickman wrote:

> After struggling with VHDL type casting for some time, I finally
> settled on using signed/unsigned for the majority of the vectors I
> use.  I seldom use integers other than perhaps memory where it
> simulates much faster with a lot less memory.  But nothing is
> absolute.  I just try to be consistent within a given design.

I use integer/natural ranges for small numbers
and signed/unsigned for large.

> I have
> never used bit types, but the discussion here about the advantages of
> ulogic over logic is interesting.  I certainly like to speed up my
> simulations.  But it is such a PITA to get away from std_logic. 

Vectors, require some compromise.
I only use std_logic_vector for non-numeric variables
and for the device pins.

For std_ulogic bits, there is no pain.
However the advantages are not overwhelming either.

Simulators are now very well optimized for standard types,
and I would not expect much run-time speed up.

Detecting multiple drivers at compile time is very useful
for new users using many processes,
but these errors can also be found at elaboration time.



       -- Mike Treseler

Mike Treseler wrote:
> whygee wrote:
> 
>> I may have found that some parts of my code used
>> std_logic and others used std_ulogic, but then
>> why take the risk of not detecting conflicts
>> with multiple drivers AND simulating slower ?
> I expect there is no logical reason. Just tradition.
There is probably a little of that,
but knowing VHDL as I know it,
it is certainly backed by an excellent,
compelling reason. It becomes tradition
when we forget it :-/

Furthermore, my code was primarily meant
for synthesis (and works), so the ulogic vs logic
choice was not an issue, being a one-time,
few seconds of synthesis cost.

OK now I should stop ranting and start coding ;-)


>         -- Mike Treseler
yg

-- 
http://ygdes.com / http://yasep.org

On Jan 19, 1:51=A0pm, Mike Treseler <mtrese...@gmail.com> wrote:
> rickman wrote:
> > After struggling with VHDL type casting for some time, I finally
> > settled on using signed/unsigned for the majority of the vectors I
> > use. =A0I seldom use integers other than perhaps memory where it
> > simulates much faster with a lot less memory. =A0But nothing is
> > absolute. =A0I just try to be consistent within a given design.
>
> I use integer/natural ranges for small numbers
> and signed/unsigned for large.

Can you explain the idea behind that?  Why integers for small numbers
and not large?


> > I have
> > never used bit types, but the discussion here about the advantages of
> > ulogic over logic is interesting. =A0I certainly like to speed up my
> > simulations. =A0But it is such a PITA to get away from std_logic.
>
> Vectors, require some compromise.
> I only use std_logic_vector for non-numeric variables
> and for the device pins.
>
> For std_ulogic bits, there is no pain.
> However the advantages are not overwhelming either.
>
> Simulators are now very well optimized for standard types,
> and I would not expect much run-time speed up.

As optimized as they may be, a signal that does not require resolution
will take longer than one that does.  Detecting multiple drivers is
done at compile time while the resolution is done at simulation time.
I guess if there are no multiple drivers the difference may not be
apparent though.


> Detecting multiple drivers at compile time is very useful
> for new users using many processes,
> but these errors can also be found at elaboration time.
>
> =A0 =A0 =A0 =A0-- Mike Treseler

Yeah, I can't say I have many issues with multiple drivers.  I'm
pretty sure the tools I've been using give adequate warnings when I do
make a mistake and reuse a signal name.

Rick

On Tuesday, December 1, 2009 9:53:18 PM UTC+5, glallenjr wrote:
> Currently I am studying the "Circuit Design with VHDL" by Volnei A.
> Pedroni. On page 207 the run a simulation but do not provide the test
> bench. I would like to run the same simulation but I am not familiar with
> how to write a testbench. If possible please provide a testbench to mimic
> the simulation shown on page 207. If you are unfamiliar with this book or
> the simulation run, I would also appreciate ANY KIND of testbench which
> could simulate it's funcionality. Also if there are any errors with the
> code, please let me know! Your help is much appreciated! thank you!
> 
> Here is the code we are trying to implement:
> 
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> 
> entity vending_machine is
>     Port ( clk, rst : IN  STD_LOGIC;
>            nickel_in, dime_in, quarter_in : IN  BOOLEAN;
>            candy_out, nickel_out, dime_out, quarter_out: OUT STD_LOGIC);
> end vending_machine;
> 
> architecture fsm of vending_machine IS
> 	TYPE state IS (st0, st5, st10, st15, st20, st25, st30, st35, st40, st45);
> 	SIGNAL present_state, next_state: STATE;
> 	
> begin
> 	PROCESS(rst, clk)
> 	BEGIN
> 		IF(rst='1') THEN
> 			present_state <=st0;
> 		ELSIF(clk' EVENT AND clk ='1') THEN
> 			present_state <= next_state;
> 		END IF;
> 	END PROCESS;
> 	
> 	PROCESS(present_state, nickel_in, dime_in, quarter_in)
> 	BEGIN
> 		CASE present_state IS
> 			WHEN st0 =>
> 				candy_out <= '0';
> 				nickel_out <='0';
> 				dime_out <= '0';
> 				IF (nickel_in) THEN next_state <= st5;
> 				ELSIF (dime_in) THEN next_state <= st10;
> 				ELSIF (quarter_in) THEN next_state <= st25;
> 				ELSE next_state <=st0;
> 				END IF;
> 			WHEN st5 =>
> 				candy_out <= '0';
> 				nickel_out <='0';
> 				dime_out <= '0';
> 				IF (nickel_in) THEN next_state <= st10;
> 				ELSIF (dime_in) THEN next_state <= st15;
> 				ELSIF (quarter_in) THEN next_state <= st30;
> 				ELSE next_state <=st5;
> 				END IF;
> 			WHEN st10 =>
> 				candy_out <= '0';
> 				nickel_out <='0';
> 				dime_out <= '0';
> 				IF (nickel_in) THEN next_state <= st15;
> 				ELSIF (dime_in) THEN next_state <= st20;
> 				ELSIF (quarter_in) THEN next_state <= st35;
> 				ELSE next_state <=st10;
> 				END IF;
> 			WHEN st15 =>
> 				candy_out <= '0';
> 				nickel_out <='0';
> 				dime_out <= '0';
> 				IF (nickel_in) THEN next_state <= st20;
> 				ELSIF (dime_in) THEN next_state <= st25;
> 				ELSIF (quarter_in) THEN next_state <= st40;
> 				ELSE next_state <=st15;
> 				END IF;
> 			WHEN st20 =>
> 				candy_out <= '0';
> 				nickel_out <='0';
> 				dime_out <= '0';
> 				IF (nickel_in) THEN next_state <= st25;
> 				ELSIF (dime_in) THEN next_state <= st30;
> 				ELSIF (quarter_in) THEN next_state <= st45;
> 				ELSE next_state <=st20;
> 				END IF;
> 			WHEN st25 =>
> 				candy_out <= '1';
> 				nickel_out <='0';
> 				dime_out <= '0';
> 				next_state <= st0;
> 			WHEN st30 =>
> 				candy_out <= '1';
> 				nickel_out <='1';
> 				dime_out <= '0';
> 				next_state <= st0;
> 			WHEN st35 =>
> 				candy_out <= '1';
> 				nickel_out <='0';
> 				dime_out <= '1';
> 				next_state <= st35;
> 			WHEN st45 =>
> 				candy_out <= '0';
> 				nickel_out <='0';
> 				dime_out <= '1';
> 				next_state <= st35;
> 		END CASE;
> 		END PROCESS;
> 		
> 		END fsm;
> 
> 
> 	   
> 					
> ---------------------------------------		
> This message was sent using the comp.arch.fpga web interface on
> http://www.FPGARelated.com

hello,
I have done with this code but if a user inserts 2 nickel or 1 dime and he decided not to take a candy and he want his money back. How could i return his inserted coins without giving him candy. please Reply ASAP
thanks

On Sat, 02 Nov 2013 06:03:56 -0700, fahmeed.zaheer47 wrote:

> On Tuesday, December 1, 2009 9:53:18 PM UTC+5, glallenjr wrote:
>> Currently I am studying the "Circuit Design with VHDL" by Volnei A.
>> Pedroni. On page 207 the run a simulation but do not provide the test
>> bench. I would like to run the same simulation but I am not familiar
>> with how to write a testbench. If possible please provide a testbench
>> to mimic the simulation shown on page 207. If you are unfamiliar with
>> this book or the simulation run, I would also appreciate ANY KIND of
>> testbench which could simulate it's funcionality. Also if there are any
>> errors with the code, please let me know! Your help is much
>> appreciated! thank you!
>> 
> 
> hello,
> I have done with this code but if a user inserts 2 nickel or 1 dime and
> he decided not to take a candy and he want his money back. How could i
> return his inserted coins without giving him candy. please Reply ASAP
> thanks

I doubt that anyone is here to do your work.  Most of us, if we're 
interested in helping you at all, are here to help you to do your work.

Here's what I suggest:

* Study the code until you understand it.
* Figure out how to add logic to do what you want
* Do it
* Test it

Buckle down, get to work, make it happen.

-- 
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

On 11/2/13, 9:03 AM, fahmeed.zaheer47@gmail.com wrote:

> hello,
> I have done with this code but if a user inserts 2 nickel or 1 dime and he decided not to take a candy and he want his money back. How could i return his inserted coins without giving him candy. please Reply ASAP
> thanks
> 

How is the user to ask for his money back? This is an additional
requirement, which will need a change to your Interface Control
Document, most likely requiring some additional inputs (to ask for their
money back), and maybe some additional states or outputs to avoid abuses.

A few big questions that comes up are things like do we want to give him
back his OWN coins, to avoid being a slug laundering machine, or become
a coin changer.

Of course, problems like this are really just homework level tasks, a
real machine would need a few more I/Os to handle real world issues like
not having change available and select which product.

On Sunday, January 17, 2010 6:49:48 PM UTC-6, KJ wrote:
> In the end, the main advantage of std_logic is with unknowns. Booleans wi=
ll
> initialize themselves to 'False', std_logic to 'U'. Proving that your des=
ign
> does not depend on a lucky initialization value happens when you use
> std_logic not booleans.

That advantage is reduced considerably when your RTL is full of "if val =3D=
 '1' then" or similar conditional statements that do not react appropriatel=
y to unknown values.=20

If you are willing to express all of your RTL logic as assignments from boo=
lean expressions, or include lots of "elsif val =3D 'X' then" statements, t=
hen  you can realize (in RTL simulation) the benefit of unknown-handling in=
 std_ulogic-based types. I'd rather have understandable code.

I have often used custom is1() or is0() functions (return boolean) that ass=
ert a warning, and return false, if passed an unknown value. With them, I c=
an use statements like "if is1(my_sig) then" and at least be warned about m=
aking a decision based on an uknown value.

However, your point about unknown representation and finding initialization=
 problems is extremely valuable during gate level simulation (post-synthesi=
s or post-P&R). Whether you used booleans and integers or not in your RTL, =
the gate level model is built around std_ulogic and its aggregates that inc=
lude and propagate uknowns appropriately (sometimes too appropriately!). Th=
is is where you should test your design's initialization. A quick scan of t=
he synthesis tool's utilization summary for any non-reset register primitiv=
es also helps a lot.

Andy