Simulation of VHDL code for a vending machine

[Mike Treseler]

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

 

[whygee]

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

 

[Mike Treseler]

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

 

[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

 

[whygee]

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

 

[rickman]

On Jan 19, 1:51 pm, 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.  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.

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

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.

       -- 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

 

[Jonathan Bromley]

On Thu, 21 Jan 2010 05:54:10 -0800 (PST), rickman wrote:

[Mike Treseler]

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?

Can't speak for Mike, but my reasoning might be: integers are
convenient because they allow mixing of signed and unsigned
quantities, and all the sign extension and range checking
gets sorted out for me automatically; but VHDL integers
(inexcusably, for any time later than about 1990) don't
support anything wider than 31 bits. Yes, 31, that's not
a typo for 32; you can't reliably get 32-bit signed
behaviour from VHDL integers, and you can't get 32-bit
unsigned behaviour at all. Madness, and one of my top
beefs with VHDL.

Beyond 31 bits, the signed and unsigned types work well
and don't put any insuperable obstacles in my way; but
mixing signed and unsigned is tedious, and it's also
irritating that you can't copy an integer number or
expression directly into a signed or unsigned vector,
because VHDL doesn't allow overloading of the
assignment operator.

My personal choice tends to be driven by whatever looks
neatest in the specific application I have to hand;
any cracks can easily be papered-over by creating some
appropriate VHDL functions.

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.

Right, a simulator can (and should!) optimise away the resolution
function when only one driver exists on a signal. I suspect the
need to support multi-valued logic is a bigger cost of CPU power
than the resolution function, in many cases. No U/X/Z to worry
about in an integer!

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.

And also by synthesis tools. When writing HDL code that
aims to be synthesisable, it's a smart move to synthesise
it early in the debug process - just as soon as you've
got the syntax goofs out of it. Synthesis tools do a lot
of pretty smart static analysis and, obviously, can check
for synthesis design rules that are of no concern to simulators.
Some simulators have a "synthesis rule check" option on their
compilers, but I've never found those to be useful; they miss
far too much.

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.

Sure, but you can easily end up with syntactically legal - and
perfectly meaningful - code that drives a signal from more than
one process, and waste a lot of debug time as a result. In
fairness, that tends to be more of a beginner's problem; the
old hands around here probably get that sort of thing right
first time, more often than not.
--
Jonathan Bromley

 

[Andy]

On Jan 21, 9:17 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Thu, 21 Jan 2010 05:54:10 -0800 (PST), rickman wrote:

[Mike Treseler]

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?

Can't speak for Mike, but my reasoning might be: integers are
convenient because they allow mixing of signed and unsigned
quantities, and all the sign extension and range checking
gets sorted out for me automatically; but VHDL integers
(inexcusably, for any time later than about 1990) don't
support anything wider than 31 bits.  Yes, 31, that's not
a typo for 32; you can't reliably get 32-bit signed
behaviour from VHDL integers, and you can't get 32-bit
unsigned behaviour at all.  Madness, and one of my top
beefs with VHDL.

Beyond 31 bits, the signed and unsigned types work well
and don't put any insuperable obstacles in my way; but
mixing signed and unsigned is tedious, and it's also
irritating that you can't copy an integer number or
expression directly into a signed or unsigned vector,
because VHDL doesn't allow overloading of the
assignment operator.

My personal choice tends to be driven by whatever looks
neatest in the specific application I have to hand;
any cracks can easily be papered-over by creating some
appropriate VHDL functions.

As optimized as they [data types in library ieee] 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.

Right, a simulator can (and should!) optimise away the resolution
function when only one driver exists on a signal.  I suspect the
need to support multi-valued logic is a bigger cost of CPU power
than the resolution function, in many cases.  No U/X/Z to worry
about in an integer!

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.

And also by synthesis tools.  When writing HDL code that
aims to be synthesisable, it's a smart move to synthesise
it early in the debug process - just as soon as you've
got the syntax goofs out of it.  Synthesis tools do a lot
of pretty smart static analysis and, obviously, can check
for synthesis design rules that are of no concern to simulators.
Some simulators have a "synthesis rule check" option on their
compilers, but I've never found those to be useful; they miss
far too much.

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.

Sure, but you can easily end up with syntactically legal - and
perfectly meaningful - code that drives a signal from more than
one process, and waste a lot of debug time as a result.  In
fairness, that tends to be more of a beginner's problem; the
old hands around here probably get that sort of thing right
first time, more often than not.
--
Jonathan Bromley

On Jan 21, 7:54 am, rickman <gnu...@gmail.com> wrote:

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.

As Jonathan alluded, many simulators have a default optimization (can
be turned off) that, assuming all resolution functions are transparent
(meaning that the result of the resolution of a single driver is
always the value of that single driver) omit the resolution function
when only one driver is present. Of course, the resolution function
for std_logic is transparent, but resolution functions are not
required to be that way by the LRM. I have seen such non-transparent
resolution functions used in a library used for modelling performance
of systems with resource contention, etc. As I recall, the arbitration
scheme used a non-transparent resolution function on the record type
that represented a bus. However, for std_logic, there is often no
simulation penalty, but perhaps a small elaboration phase penalty.

Integer arithmetic promotes results to at least 31 bit signed, and
only limits them upon assignment to a smaller subtype's range. Thus
the result of a natural - 1 can be less than zero (just don't try to
store it in a natural!), whereas the result of an unsigned - 1 cannot.
The synthesis tools are smart enough to optimize out the logic from
the intermediate promotion that is not needed.

Integer arithmetic is MUCH faster to simulate than vector based
arithmetic, even when using divide/modulo by powers of 2 to extract
"bit fields" or truncate values. The divide/modulo with powers of 2 is
automatically optimized by synthesis. Integer operations are usually
implemented directly via the corresponding processor instruction,
rather than the complex nature of dealing with individual MLV "bits"
spread across different addresses in memory for a vector.

The new fixed point package borrows some interesting features from
integers, but not all of them. Note that the fixed point types can be
used for integers by simply specifying non-negative index ranges. The
fixed point operators promote the results to a size that is large
enough to handle the largest possible result without overflowing, but
they do not promote u_fixed to s_fixed for subtraction (an unfortunate
oversight for arithmetic completeness, which could also be handled by
the customary resizing). The general idea for using the fixed point
system would be to let the operators promote intermediate values in
expressions to preserve accuracy, then resize the final result to fit
the size of the storage, the same way (conceptually) that is used for
integers.

Andy

 

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

 

[Tim Wescott]

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

 

[Richard Damon]

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 will
initialize themselves to 'False', std_logic to 'U'. Proving that your design
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 = '1' then" or similar conditional statements that do not react appropriately to unknown values.

If you are willing to express all of your RTL logic as assignments from boolean expressions, or include lots of "elsif val = 'X' then" statements, then 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 assert a warning, and return false, if passed an unknown value. With them, I can use statements like "if is1(my_sig) then" and at least be warned about making 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-synthesis 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 include and propagate uknowns appropriately (sometimes too appropriately!). This is where you should test your design's initialization. A quick scan of the synthesis tool's utilization summary for any non-reset register primitives also helps a lot.

Andy