Clock Edge notation

[fpgawizz]

Brian
Looks like your code is meant for simulation purposes. And you have 2
concurrent signal assignment statements on "z" which is z <= '1' follwed
by z <= '0'. thats why you are getting the multisource error.
Doing something like z <= not z after 50 ns woulg give you a toggling
signal "z". Make sure you initialize "z" to '0'. After clauses are for sim
purposes only. I am assuming you are just doing a simulation here.

 

[m]

On Sat, 09 Apr 2005 15:33:53 GMT, David Bishop <dbishop@vhdl.org>
wrote:

Herb T wrote:

Folks,
I was talking to some electronics buffs on a chat channel, and they
were telling me that only Universities and DOD uses VHDL. I thought it
was hogwash, but wanted to find out if many commercial companies are
using the language earnestly. The resident HDL expert was saying
verilog is the language of choice these days. Is that true? I
personally prefer VHDL because the I already have too many reference
materials on how to use it.

This is a myth prepuated by some people and companies that typically
have a vested interest in Verilog or system Verilog.

I have real data from Dataquest that says VHDL is about 50/50 with
Verilog. Verilog has the advantage in ASIC space, and VHDL in FPGA
space. Note that there are MANY more FPGAs being designed than ASICs,
however ASICs are worth much more to the EDA companies than FPGAs are.

I have another piece of real data. If you go to dice and search for
VHDL and Verilog keywords across US and In Bay Area/Silicon Valley
Metro areas, you get almost even numbers in whole US and twice as many
Verilog related jobs in the Bay Area.Monster gives similar results
(320/304 for Verilog/VHDL) if you do a generic search and (140/80 in
Northern California). This seems to correlate with your Dataquest data
as Bay Area is heavily into ASICs and the distribution of FPGAs would
be more even across US.

 

[fpgawizz]

You have to use a clock to do your toggling. You can have two states in a
state machine where in state 1, you set z to 0, and in state 2 z is set
to 1 and this state machine is clocked by your 50 ns clock. z would then
be a toggling signal.

 

[Ralf Hildebrandt]

bhiggins@umr.edu wrote:

ERROR:Xst:528 - Multi-source in Unit <waittime> on signal <z

You are driving a value to one signal from more than one process. (Note
that every concurrent statement ist also considered as a process.)

use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

Just a note: It is not recommended to used these libraries, as their
implementation dependts on the simulator / synthesizer. Use
IEEE.Numeric_std.ALL instead.

begin
z <= '1' after 500000000 ns;

z <= '0' after 500000000 ns;

end Behavioral;

Two concurrent statements driving z.

process -- no sensitivity list - triggered at simulation start
begin
z <= '1' after 500000000 ns;
z <= '0' after 500000000 ns;
wait; -- uncomment to execute the process again after end
end process;


Note: This is only for simulation. the after-clause is NOT synthesizable.

Whats your intention for this piece of code? Is it a clock or just a
signal, that should be high and go to low later.
If it is a clock - take an internal clock generator from you FPGA or use
the clock via a FPGA input pin.
I it is a signal - you need a clock with a period suitable for you
desired "delays". Test e.g. for the rising_edge(clock).

Ralf

 

[Mike Treseler]

IcYdRIP wrote:

I connect iet9000 with a xilinx fpga board.
and how can I operaton on dm9000? I mean, the dm9000 has already been
drived in IET9000 or I have to write a driver in VHDL

No.

or I can
directly operate on dm9000 according to the read/write timing through
the processor interface of dm9000?

That's it.
http://www.invector.nu/iet9000.asp


--Mike Treseler

 

[Mike Treseler]

"This is the conventional wisdom. I disagree. I prefer to use signal
(non-blocking) assignments _only_ for the purpose of transferring a
variable (register) value to a port or to another process."

This works fine.
I have provided you an example design and testbench
that is very easy to read
if you want to test the technique on your tools.

On the contrary:

"Try looking at a complex always block which uses a mixture of
blocking and non-blocking and it can be a real challange to decipher
what is intended even with a good understanding of the language."

As long as signal assignments are used only
as wiring, no confusion will result.

I'm sure there are many opinions out there, and I'm interested to see
what people think.

Consider trying some examples on your simulator
and judge for yourself.

-- Mike Treseler

 

[Jonathan Bromley]

On 10 Apr 2005 21:21:41 -0700, "Taras_96" <taras.di@gmail.com> wrote:

I've heard a number of theories about when to use signal assignments or
variable assignments for RTL code, and when to use concurrent or
sequential VHDL. Does anyone have an opinion on the following 'rules
of thumb'?

I have a useful opinion on rules of thumb in general: If you use
only your thumb to design things, they are quite helpful. Once you
graduate to using all ten fingers, the rules of thumb tend to get
consigned to the scrapheap of "things I learned along the way".

1) Model combinational logic within a process with a full sensitivity
list ...

In VHDL you have no choice - despite what you say about "concurrent
logic" (see below).

... using variable assignments

Assign to variables whenever it aids the noble cause of readability
and clarity of expression.

Coming from a Verilog background, I was told to model combinational
logic, using an always@(/*AUTOSENSE*/) ...

Yuck. What is (/*AUTOSENSE*/)? (I can guess.) Today,
Verilog-2001 always@* is fully supported by all serious tools.

... procedural block with blocking assignments.

Yes, that's entirely appropriate.

The VHDL equivalent of this is using a process with a
full sensitivty list, and using variable assignments.

No it isn't. VHDL variables are invisible outside the process
that defines them, but this is not true for Verilog regs.

However, the
variables are only visible from within the process, and thus it is
difficult to get the results out to a sequential block (clocked
process) bit of code.

So, you need a signal. You have no choice. It is appropriate.

Once way of getting around this is by assigning the variable to a
signal once all combinational logic has finished

An excellent idea.

however, this breaks
the general rule of not mixing blocking and non-blocking (in Verilog),
or signal and variable (in VHDL) assignments

Please cite a reference to this "general rule". It is neither a
rule, nor general. It is a misunderstanding of the rule imposed
by almost every Verilog synthesis tool: "never mix blocking and
nonblocking assignment TO THE SAME VARIABLE". In VHDL such a "rule"
would be meaningless, because you can make variable assignment only
to variables, and signal assignment only to signals. Variable
assignment to a variable, and signal assignment to a signal, may
be freely mixed in a single process, of course.

[ mixing var:= and sig<= ]

also seems cumbersome.

Why?

"In general:

sequential blocks use non-blocking <=
combinational blocks use blocking ="
http://groups-beta.google.com/group/comp.lang.verilog/browse_frm/thread/6c57aee8293cd934/32fd131568d5e217

In Verilog, that's a reasonable starting point.
In VHDL it makes no sense.

"Use non blocking assignments within sequential (clocked) blocks:"
http://groups-beta.google.com/group/comp.lang.verilog/browse_frm/thread/d4db6011c11acbf7/

In several messages on comp.lang.verilog I have explained at some
length why this is pernicious nonsense. Others have responded with
entirely valid reasons why they personally choose to follow that
guideline even though they know it is not mandatory.

Please try to limit the quantity of Verilog baggage you bring
to VHDL. VHDL has enough baggage of its own, without adding
spurious stuff.

Another solution is to migrate all combinational code into the
concurrent section of VHDL

AARGH - As I said in an earlier response to you, there is NO
SUCH THING as "the concurrent section of VHDL" in the sense
you are using here. The body of an architecture contains
a collection of processes. These processes execute independently
and concurrently. However, sometimes processes appear in
disguise...

* a concurrent assignment is in fact a process, sensitive to
all signals that appear in the expression that it calculates,
containing an assignment to the target signal and nothing else
* a component instance is a rather complicated process made up
of the collection of processes in the architecture body of the
instantiated component
.... and so on.

- but why then, in Verilog, would you write
combinational code in procedural blocks rather than using assign
statements?

So that you can say more complicated things clearly.

Is there any other disadvantages in writing combinational code in
concurrent VHDL - perhaps code clarity? The disadvantage mentioned
above is not really relevant in RTL.

As pointed out above, "concurrent" VHDL is simply a shorthand
way of writing a particularly simple kind of process.

[...]

So in summary:
If you are to write combinational logic
[...]
but this seems to go against conventional wisdom.

Conventional wisdom is often deluded, but far worse, it often is
transformed (by time and the passage of newsgroup postings) into
half-truth and urban myth. Trust it at your peril.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Ralf Hildebrandt]

stoyan.shopov@gmail.com wrote:

I am new to VHDL and have just started tackling the VHDL simulation. I
have read that in signal assignments of the type:

a <= b after 10 ns;

the 'after' clause is ignored in synthesis. Ok, but when should I use
such clauses in the simulation? They are very useful in the
testbenches, but when and why should I use such clauses in the VHDL
sources that will be later synthesized?

Then let me ask you one thing: What is the difference between a
testbench and a VHDL source?

I can't see one, as the testbench is also VHDL.

All parts of your project, that are going to be synthesized have to
avoid the after-clause. All others may use it.
This includes using the after clause in a subcomponent during the design
process if you are doing top-down design modelling and the subcomponent
will be modelled in a synthesizable way later.



But ... well ... I use the after-clause very seldom and avoid it even if
I do top-down modelling. Even big parts of my testbenches are
synthesizable. ;-)
I don't like to model a component in a non-synthesizable way if I have
to model it later in a synthesizable way, because the conversion often
leads to unforseen problems.

Ralf

 

[Mike Treseler]

stoyan.shopov@gmail.com wrote:

Hi everybody,
I am new to VHDL and have just started tackling the VHDL simulation. I
have read that in signal assignments of the type:

a <= b after 10 ns;

the 'after' clause is ignored in synthesis. Ok, but when should I use
such clauses in the simulation?

I use them very rarely as it makes testbench
synchronization very difficult. I prefer
a main testbench process as shown below.

-- Mike Treseler

---------------------------------------------
main : process is
---------------------------------------------
procedure tic is
begin
wait until rising_edge(clk_s);
end procedure tic;
---------------------------------------------
begin
a <= b;
tic;
-- everything else;
wait;
end process main;
---------------------------------------------

 

[Mike Treseler]

IcYdRIP wrote:

thank you, Mike

You are welcome.

since iet9000 has a 16-bit address/data bus. if the dm9000 wokrs on
8-bit mode, can I seclect 8 bit of iet9000 as address bus, and another
8 bits as databus?
and if dm9000 works on 16-bit, can I define two port: data port and
address port using the same 16-bit bus of iet9000 in my vhdl entity?

These are decisions that only
the designer can make.
Read all the data.
Try something and see what happens.

-- Mike Treseler

 

[Ralf Hildebrandt]

Taras_96 wrote:

1) Model combinational logic within a process with a full sensitivity
list using variable assignments

This is because, you would get different simulation results before and
after synthesis. A process needs to know, when it should be triggered.

The VHDL equivalent of this is using a process with a
full sensitivty list, and using variable assignments. However, the
variables are only visible from within the process, and thus it is
difficult to get the results out to a sequential block (clocked
process) bit of code.

Variables cannot be in sensitivity lists, as they reside /inside/ the
process. The sensitivity list lists stuff from outside. This is, where
Verilog blocking signal assignments differ from VHDL variables. They are
similar (at first sight), but not equal.

process(...)
variable sum;
begin
sum := a + b; //how to get this to a process that is clocked?!
end process;

process(clock)
variable sum;
begin
if rising_edge(clock) then
sum := a + b;
end if;
-- do something with sum - assign it to a signal
end process;

In Verilog you have the edge-condition in the sensitivity list. In VHDL
you have a normal sensitivitiy list and the edge-condition inside the
process.

Note: For the example it would be useful to copy sum to a signal, as sum
is a variable and only readable inside this process.

Once way of getting around this is by assigning the variable to a
signal once all combinational logic has finished, however, this breaks
the general rule of not mixing blocking and non-blocking (in Verilog),
or signal and variable (in VHDL) assignments, and also seems
cumbersome.

First: Mixing blocking and non-blocking assignments holds only for one
variable in a always-satement.
Second: Don't think about this rule in VHDL. This is Verilog stuff.

Let me give you an example:

always @(a,b,sum,flag)
begin
sum = a+b;
if (sum[0] == 1'b1) begin
flag_out <= flag;
end else begin
flag_out <= 1'b0;
end //if
end //always

I mixed blocking and non-blocking assignments in general, but this was
nessecary to code it this way. For every signal I used only one
assignment type.

In VHDL the code could look like:

process(a,b,flag)
variable sum_var : unsigned(15 downto 0);
begin
sum_var := a+b;
if (sum_var[0] = '1') then
flag_out <= flag;
else
flag_out <= '0';
end if;
sum <= sum_var;
end process;


Ralf

 

[Tim Hubberstey]

Jim Lewis wrote:

If you have a language issue that you think needs to be
addressed, you can submit an enhancement request against
it at:
http://www.eda.org/vasg/bugrep.htm

If you have trouble remembering this, there is a link to
it at:
http://www.eda.org/vhdl-200x/

-- Warning! Rant_Mode <= true

The problem with this method is that there are some issues that the
language controllers are simply not willing to address.

Foremost among these, IMO, is the issue of a built-in pre-processor.
Nearly every person I have encountered who is just learning VHDL, but
has experience with another language, asks: Why is there no
pre-processor/macro capability?

From the very beginning (VHDL'87), it has been stated that the
designers don't want a pre-processor but that if you really feel the
need for one, there are many options available as stand-alone tools.
While this is indeed true, use of a 3rd party pre-processor results in
*non-standard* and *non-portable* code.

There are also those who say that you don't need a pre-processor because
there are other methods built into the language that do the same thing.
This is true in many cases but use of these methods almost always
results in far more complex (hard to maintain) code and/or an explosion
in the number of lines of total code.

Then there are the issues that, I believe (perhaps incorrectly), can't
(or shouldn't) be addressed by any solution other than a pre-processor.
One of the most common issues is having optional ports in an entity
declaration.

Finally, there is the whole issue of compiler directives. This has been
"solved" by defining special "comments" that operate as directives. The
logical place for these directives, IMO, is as pre-processor directives.
Instead, we have what can only be described as a "hack"; these special
comments. I wonder how many other people have had problems with
inadvertent invocation of a directive because of an unfortunately-worded
comment?

The existence of a number of custom-designed pre-processors for VHDL is,
to me, a clear indication that this is a feature that is really a
language requirement.
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com

 

[Mike Treseler]

Tim Hubberstey wrote:

Foremost among these, IMO, is the issue of a built-in pre-processor.
Nearly every person I have encountered who is just learning VHDL, but
has experience with another language, asks: Why is there no
pre-processor/macro capability?

Hi Tim,

I came from a hardware background and found
it odd when first maintaining a C program that I had to
wade through a nest of #ifndefs and hack
some #defines to get the options right.
Maintaining the *almost* C-like macros
can also be challenging for a bit bouncer.

Then there are the issues that, I believe (perhaps incorrectly), can't
(or shouldn't) be addressed by any solution other than a pre-processor.
One of the most common issues is having optional ports in an entity
declaration.

If it's my code, I am inclined to just edit in the change
and use version control to dig it up if I ever have to.
If it's an untouchable entity, I can make a wrapper
in about a minute.

Finally, there is the whole issue of compiler directives.

I prefer to keep my code free of directives and
make those settings in the back-end files.

-- Mike Treseler

 

[Paul Uiterlinden]

Praveen wrote:

I have been using the following procedure to detect the edge of an
signal in a clock synchronous process. I might have made some minor
mistakes in the code below..but the concept is to use a temporary
signal to detect the edge..

Signal FlagTmp : std_logic;
..
..
process(Reset,Clock)
begin
if (Reset = '0') then
FlagTmp <= '1' ;
elsif (Rising_edge (Clock)) then
if(Mysignal = '1' and FlagTmp <= '1') then
Output <= '1' ;
FlagTmp <= '0' ;
elsif (Mysignal = '0') then
FlagTmp <= '1' ;
Output <= '0' ;
else
Output <= '0' ;
end if;
end if;
end process;

I am not sure if this is a "grand" way of doing it. Could anyone
suggest a better approach?

Much simpler would be to think in hardware. It's just a flip-flop to get
the previous value and a gate to detect prev_value = '0' and
current_value = '1':

signal my_sig_1d: std_logic;
process
begin
wait until clock = '1';
my_sig_1d <= my_sig;
end process
output <= my_sig and not my_sig_1d;

Depending whether you put the signal assignment of output inside or
outside the process you add and extra flip-flop (so an extra clock
delay) or not.

I've removed your asynchronous reset. You did not reset output anyway.

Paul.

 

[Bert Cuzeau]

Praveen wrote:

I have been using the following procedure to detect the edge of an
signal in a clock synchronous process. I might have made some minor
mistakes in the code below..but the concept is to use a temporary
signal to detect the edge..

Signal FlagTmp : std_logic;
..
..
process(Reset,Clock)
begin
if (Reset = '0') then
FlagTmp <= '1' ;
elsif (Rising_edge (Clock)) then
if(Mysignal = '1' and FlagTmp <= '1') then
Output <= '1' ;
FlagTmp <= '0' ;
elsif (Mysignal = '0') then
FlagTmp <= '1' ;
Output <= '0' ;
else
Output <= '0' ;
end if;
end if;
end process;

I am not sure if this is a "grand" way of doing it. Could anyone
suggest a better approach?

Thanks.

Not very far but...

- Missing set/reset
- missing resynchronization flip flop.

Also: you didn't say "rising" but "edge".
If it's any edge (<=> signal change) then use an xor.

signal rDin, rrDin : std_logic;

-- Synchronous edge detection
process (Clk,Reset)
begin
if (Reset = '1') then
rDIn <= '0';
rrDin <= '0';
Dout <= '0';
elsif rising_edge(Clk) then
rDIN <= Din;
rrDin <= rDin;
Dout <= rDin xor rrDin; -- any edge
--Dout <= rDIn and not rrDin; -- rising etc...
end if;
end process;

Beware of the possible spurrious detection at powerup if your signal
is always '1'. (in which case you could preset instead of reset)

Bert Cuzeau

 

[Paul Uiterlinden]

xiibweb@hotmail.com wrote:

HDLParsers:164 - "C:/Projects/knm/2bit.vhd" Line 11. parse error,
unexpected INTEGER_LITERAL, expecting IDENTIFIER

entity 2bit is

Names of identifiers should not start with a digit. Choose two_bit, or
something similar instead.

Paul.

 

[Brian Drummond]

On Mon, 11 Apr 2005 16:50:17 -0700, Mike Treseler
<mike_treseler@comcast.net> wrote:

Tim Hubberstey wrote:

Foremost among these, IMO, is the issue of a built-in pre-processor.
Nearly every person I have encountered who is just learning VHDL, but
has experience with another language, asks: Why is there no
pre-processor/macro capability?

Hi Tim,

I came from a hardware background and found
it odd when first maintaining a C program that I had to
wade through a nest of #ifndefs and hack
some #defines to get the options right.
Maintaining the *almost* C-like macros
can also be challenging for a bit bouncer.

I came to C from a more formal software background (ALGOL-W, then
Modula-2 and a very clean OO language), and found much the same thing,
plus the non-referentially-transparent nature of C style pre-processing
makes it virtually unusable except for trivial hacks.

Even then it leads to pretty unstable systems. Part of the problem is
that it's untestable, or at least untested by any compiler system I
know; only the processed code undergoes syntax checking (does anyone
know of a pre-compiler that traverses every branch and reports on errors
in the currently unreachable ones?), and that has several interesting
ways of generating (or at the very least) obscuring errors.

Some of its common uses are to overcome problems in C that shouldn't be
there in the first place, and VHDL doesn't have anyway. Such as the lack
of a proper import mechanism (package/library/use in VHDL;
FROM ... IMPORT in Modula-2).

I for one would be very unhappy about adding ways of introducing so many
bugs into VHDL, and the only way to avoid it would be a much more
rigorous and heavyweight approach than the C pre-processor.

- Brian

 

[Jim George]

Mike Treseler wrote:

stoyan.shopov@gmail.com wrote:

Hi everybody,
I am new to VHDL and have just started tackling the VHDL simulation. I
have read that in signal assignments of the type:

a <= b after 10 ns;

the 'after' clause is ignored in synthesis. Ok, but when should I use
such clauses in the simulation?


I use them very rarely as it makes testbench
synchronization very difficult. I prefer
a main testbench process as shown below.

-- Mike Treseler

---------------------------------------------
main : process is
---------------------------------------------
procedure tic is
begin
wait until rising_edge(clk_s);
end procedure tic;
---------------------------------------------
begin
a <= b;
tic;
-- everything else;
wait;
end process main;
---------------------------------------------

Mike,
A rough equivalent to your code would be

main: process (clk)
begin
if (rising_edge(clk)) then
a <= b;
end if;
end process;

However, the problem is a gets assigned *exactly* at the clock, which
is not what happens in the real world (due to setup time). Here, an
"after" clause on the assignment would help simulate that. For example,
one of my designs interfaces with a QL5064 chip, whose datasheet says
that the chip's control bus signals have a 4 ns setup time. So in my
test bench, I use "data <= data_int after 4 ns;"
-Jim

 

[Ralf Hildebrandt]

Tim Hubberstey wrote:

Foremost among these, IMO, is the issue of a built-in pre-processor.
Nearly every person I have encountered who is just learning VHDL, but
has experience with another language, asks: Why is there no
pre-processor/macro capability?

From the very beginning (VHDL'87), it has been stated that the
designers don't want a pre-processor ...

Do we need a preprocessor, if something like the generate statements
would be extended to the signal declaration and to the entity? Such a
solution would offer configuration using one idea - not two like the
parameter and defines in Verilog.


Ralf

 

[Ralf Hildebrandt]

Weng Tianxiang wrote:

I appreciate if you can help me get the copy of the following
paper:

If your local library cannot provide this paper, ask yourself if you
really need it. If you only want to understand something like a
Booth/MacSorley Multiplier, try to find some papers or tutorials about
it. Even if you don't find a step-by-step tutorial it is possible to
reengineer the idea from a paper, that touches this topic.

Ralf