Clock Edge notation

[Ralf Hildebrandt]

Paul wrote:

* finally: VHDL code it better human-readable - IMHO ;-)

I used to think that vhdl would be more readable than verilog, but I've
seen too much vhdl code that looks like this:

x := std_logic_vector(to_unsigned((to_integer(unsigned(z1)) +
to_integer(unsigned(z2))), 9));
....
which I *think* is meant to do the same thing as this nice verilog
code:

x = z1 + z2;

Yes - I agree, this is the point, where VHDL is not well readable, but
remember two things:
* It is well-defined if signed or unsigned arithmetics are used (as long
as you use IEEE.Numeric_std.ALL). For addition you don't care about
this, but for a comparison it is important.
* How many of these constructs do you have in a typical design? O.k. -
quite a lot if you do DSP arithmetics, but normally these things are
rare. (I often try to re-use adders as they have a speed impact and
are area-expensive. Therefore 5 such things in the whole design is a
big number.)



And finally: It is my personal opinion, that it is better readable. ;-)
It started learing VHDL with only little knowledge about the C syntax.
Now, as I have learned C, Verilog is much more readable, but still my
opinion is the same. When I do Verilog I code it like VHDL and it looks
much better than in examples. But again: IMHO!

Ralf

 

[Mike Treseler]

Jim George wrote:

A rough equivalent to your code would be
main: process (clk)
begin
if (rising_edge(clk)) then
a <= b;
end if;
end process;

True, except for the -- everything else part. See:
http://home.comcast.net/~mike_treseler/test_uart.vhd
for a full example of this style of synchronous testbench.

However, the problem is a gets assigned *exactly* at the clock,
which is not what happens in the real world (due to setup time).

But it is what happens in a synchronous simulation
of the real word. Real clock to Q delays become delta delays.
The DUT provides synchronization of all inputs that
need it.

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

Nothing wrong with that.

Synchronized inputs and static timing analysis
are my preference to verify the setup and holds.

This testbench style is not synthesizable like Ralf's.
It just works works like one that is -- but a
little easier for me to read.

-- Mike Treseler

 

[Jim George]

True, except for the -- everything else part. See:
http://home.comcast.net/~mike_treseler/test_uart.vhd
for a full example of this style of synchronous testbench.

OK, that example made it clear what kinda stuff could go into
"--everything else". Thanks!

 

[Martin Thompson]

"Paul" <verilog@sbcglobal.net> writes:

* finally: VHDL code it better human-readable - IMHO ;-)

I used to think that vhdl would be more readable than verilog, but I've
seen too much vhdl code that looks like this:

x := std_logic_vector(to_unsigned((to_integer(unsigned(z1)) +
to_integer(unsigned(z2))), 9));
y := std_logic_vector(to_unsigned((to_integer(unsigned(x(7
DOWNTO 0))) + to_integer(unsigned(x(8
DOWNTO 8)))), 8));

I would argue that's just bad code - x and y should be unsigned in
this case. It's not very often that you actually want to assign the
result of an arithmetic operation to a boggo vector.

One can write unreadble code in any language - and as someone else has
pointed out, at least the operations in numeric_std are well-defined.

Cheers,
Martin


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

 

[Paul Uiterlinden]

IcYdRIP wrote:

I have to reuse the same call many times. so I plan to use a procedure.
I've read the reference manual and some books, But I still don't know
if it's possible to use a clock signal from entity in the procedure. I
mean, if there's a clk signal in the entity, and I define a procedure
in the package, the declaration as follow for example:

procedure dm9000_rd_data(signal clk : in std_logic; reg : in
std_logic_vector(7 downto 0); signal daBus : inout std_logic_vector(7
downto 0); signal cmd, cs, iowait, rd : out std_logic;

and can I use the clk as it's in a entity? such as clk's events and
values. or I can just read the clk value only?

WAIT is supported in procedures. Also attributes such as 'EVENT can be
used. That's why you must declare the formal parameter as signal.

Paul.

 

[Brian Drummond]

On 12 Apr 2005 10:47:26 -0700, "Paul" <verilog@sbcglobal.net> wrote:

* finally: VHDL code it better human-readable - IMHO ;-)

I used to think that vhdl would be more readable than verilog, but I've
seen too much vhdl code that looks like this:

x := std_logic_vector(to_unsigned((to_integer(unsigned(z1)) +
to_integer(unsigned(z2))), 9));
y := std_logic_vector(to_unsigned((to_integer(unsigned(x(7
DOWNTO 0))) + to_integer(unsigned(x(8
DOWNTO 8)))), 8));

which I *think* is meant to do the same thing as this nice verilog
code:

USUALLY that's a warning that you (or the code's writer) hasn't thought
through the design properly.

If he had defined x and y as type unsigned, he could have written
something like

x = z1 + z2;

x := z1 + z2;
-- clear enough?

;

// Was the length mismatch deliberate or is it cover for an obscure bug?
// How do unequal-length operands get handled?
// Did it sign extend or zero fill the shorter one?
// If it extends the shorter operand, can I trust it to flag length
// mismatches between the expression and the assignment variable?

y := x(7 downto 0) + "0000000"&x(8);
-- Clear and precise.
-- Yes there are better ways to extend the shorter operand.
-- Doesn't necessarily do the same as the Verilog code because
-- there are a lot of assumptions in the translation...

The VHDL version has the advantage over the Verilog code that the
operand length mismatch was obviously deliberate and handled in a
defined manner, and not an obscure bug waiting to happen.

Now there are reasons for reverting to std_logic_vector at the physical
ports of a chip, but the ":=" form of assignment tells me x and y are
variables inside a process, so that can't matter here!

Of course the above assumes he is using "numeric_std" and not the
non-standard "std_logic_arith" library, whouch would IMO be another
warning of a poorly thought out design.

Some vhdl proponents believe that readability is synonymous with
verbosity.

And some don't. But this VHDL proponent believes that the precision is
worth _some_ excessive verbosity, to ensure that the code actually does
what it says it does.

- Brian

 

[Bert Cuzeau]

Salman wrote:

I have a vhdl value that I must test whether it increments by one. The
input signal is a 32-bits count value (std logic vector). My module
would receive this value as an input to check whether it increments and
that would affect the state machine.

How would I code something like this as efficiently as possible?


Salman

Unclear spec.
If it' a counter with Enable (that can only be incremented by one
or remain stable. Load ??), then a simple xor gate on LSB does it !

Otherwise, an incrementor and equality comparator ?

 

[Pete Fraser]

"Weng Tianxiang" <wtx@umem.com> wrote in message
news:1113405753.475611.67850@l41g2000cwc.googlegroups.com...

All of them treats 'Modified Booth Algorithm' as a given thing and none
of them gives why. The paper has 24 pages in length. That is the reason
I am trying to find a copy of it and read its original paper.

Thank you for your response.

I did a quick Google search, and found thar the paper was re-printed in
Swartzlander Vol 1.

Swartzlander, E. E., Jr. 1990. Computer Arithmetic. Los Alamitos, CA:

IEEE Computer Society Press, vols. 1 and 2. ISBN 0818689315 (vol. 1).

QA76.6.C633. Volume 1 is a reprint (originally published: Stroudsberg,

PA: Dowden, Hutchinson & Ross). Volume 2 is a sequel.

Contains reprints of many of the early (1960-1970) journal articles on

adder and multiplier architectures.



Worth checking?

 

[Engineering Guy]

Salman wrote:

I have a vhdl value that I must test whether it increments by one. The
input signal is a 32-bits count value (std logic vector). My module
would receive this value as an input to check whether it increments and
that would affect the state machine.

How would I code something like this as efficiently as possible?


Salman

Should it check if the previous value is (current-1)?

Is it unsigned or signed?
Need more spec...

EG

 

[Engineering Guy]

khansa wrote:

Please mention a tool that can accepts VHDL code and converts it into
a circuit schematic(preferably at the register transfer level or gate
level). Does ORCAD have such an option?

Aldec's Active-HDL has a Code2Graphics converter that works quite well
with VHDL and Verilog. It generates either block diagrams for structure
and finite state machine bubble diagrams for certain code templates.
It can convert to a block diagram virtually anything since it allows for
behavioral (concurrent assignments and processes) blocks in the document...

EG

 

[Mike Treseler]

Brian Drummond wrote:

If he had defined x and y as type unsigned, he could have written
something like
x := z1 + z2;
y := x(7 downto 0) + "0000000"&x(8);

Now there are reasons for reverting to std_logic_vector at the physical
ports of a chip, but the ":=" form of assignment tells me x and y are
variables inside a process, so that can't matter here!

Well said.
Thanks for the posting.

Conversion between
std_logic_vector and unsigned
is a simple cast on the
edge assignments.

Most designs have 10 times
more process register bits
than pins on the device.

-- Mike Treseler

 

[Tim Hubberstey]

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

Unfortunately, any language feature can be abused. I also come from a
hardware background so I understand what you mean. However, a lot of the
pre-processor complexity you see in C code often comes from people
writing code that will work on many different platforms and operating
systems.

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.

That's fine, as long as you're the only person dealing with the code. I
try to write code that is, as much as possible, reusable and
parameterizable. This often results in situations where you want to vary
the port list to include/exclude control signals. There are ways you can
do this that stay within the existing VHDL definition, but these methods
often result in compiler and/or synthesis warnings that add confusion to
the log files. Using a pre-processor, IMO, produces much cleaner results
for the *user* of an IP block even though the code inside the block may
be a little harder to understand.

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.

This is, mostly, a style issue so I won't disagree with your choice.
However, there are some pragmas that *must* be inside the code because
the tool the pragma is for doesn't have any back-end files. Some code
coverage and formal verification tools come to mind here.

Even if you don't choose to intentionally use pragmas in your code, it
can still happen by accident. For instance, I once wasted an entire
day's synthesis run because I reformatted a comment block and
inadvertently ended up with a comment line that started out:
-- Synopsys ...
This caused the synthesis of the block to fail which, since it was a
block instantiated by many other blocks, caused the entire 18-hour
synthesis run to fail.

Even worse is the case where you accidentally generate a valid pragma
that causes some subtle error in your result. My point is that, whether
you choose to use them or not, pragmas have no business looking like
comments.
--
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]

cristian wrote:

The signals declared in the procedure declaration are local to the
procedure. So, you can have a clock signal for using within the
procedure.

A procedure can use a signal passed to it,
or a signal in the scope of the calling process,
but if I try to *declare* a signal inside a procedure
declaration, I will see something like this:

** Error: Signal declaration 'bozo' not allowed in this region.

Signals can be "local" to an architecture, block or package.

-- Mike Treseler

 

[Tim Hubberstey]

Ralf Hildebrandt 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?

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.

Possibly not for pre-processing, as long as the pragma issue is
addressed somehow.

However, I would still like to see a macro capability. Generates are
powerful and can do many things, but sometimes they either just aren't
enough (lack of an "else" clause is a big failing), or are way too complex.
--
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:

However, there are some pragmas that *must* be inside the code because
the tool the pragma is for doesn't have any back-end files. Some code
coverage and formal verification tools come to mind here.

Thanks for the tip. I will remind myself
not to bother evaluating such tools.
Modelsim seems to do ok on
code coverage without resorting to such hacks.

-- Synopsys ...
This caused the synthesis of the block to fail which, since it was a
block instantiated by many other blocks, caused the entire 18-hour
synthesis run to fail.

Serious bummer. I'll resolve to keep vendor names
and keywords like "translate" out of my comments.

My point is that, whether
you choose to use them or not, pragmas have no business looking like
comments.

I agree that comments ought to be ignored by all tools.
Some of the vendors use vhdl attributes to do this sort of thing.
At least that eliminates the possible side effects of putting
vendor settings in source code.


-- Mike Treseler

 

[Tim Hubberstey]

Paul wrote:

* finally: VHDL code it better human-readable - IMHO ;-)


I used to think that vhdl would be more readable than verilog, but I've
seen too much vhdl code that looks like this:

x := std_logic_vector(to_unsigned((to_integer(unsigned(z1)) +
to_integer(unsigned(z2))), 9));
y := std_logic_vector(to_unsigned((to_integer(unsigned(x(7
DOWNTO 0))) + to_integer(unsigned(x(8
DOWNTO 8)))), 8));

This really an issue with the standard packages and not the language
itself (a hairline distinction). Many people create their own packages
that crunch this kind of thing down to something reasonable. For
instance, I use a function, AddSLV(vec_1, vec_2, mode), that takes 2
standard_logic_vectors and "adds" them. The "add" function can be signed
or unsigned 2's complement, Gray, etc. as defined by the mode value.

which I *think* is meant to do the same thing as this nice verilog
code:

x = z1 + z2;
y = x[7:0] + x[8];

You could write the exact equivalent in VHDL by using the unsigned
package instead of the numeric_bit package:

x <= z1 + z2;
y <= x(7 downto 0) + x(8);
^-- not sure about this since I don't use the
unsigned package. Might need to re-size it.

(Now try to imagine the above vhdl code with really long identifiers
instead of the short identifiers that I used.)

Some vhdl proponents believe that readability is synonymous with
verbosity.

No argument there. I much prefer the [x:y] notation to (x downto y).
It's also a safe bet that something that basic is never going to change.

However, your example isn't really about readability -- it's about
strong (VHDL) vs weak (Verilog) typing. Some people like a
strongly-typed language because of the implicit error checking, others
hate it because the typing "keeps me from doing what I want". It's a
philosophical difference that goes much deeper than just syntax and is
probably just as religious as Mac vs PC or Linux vs Windows.
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com

 

[Jim Lewis]

Tim Hubberstey wrote:

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.

I think for future revisions of VHDL all user requests
need to be on the table. To get a good solution, we
need to get many perspectives. One of the challenges
is to translate from a request that suggests an
implementation to the underlying requirement - because
there may be a better way of addressing the requirement
that is already being proposed.

The original language designers have blessed us with a
clean, consistent language. As we move forward, those of
us who decide to answer the call and step into this role,
need to work hard to keep the language clean and consistent.

Don't get discouraged because something was rejected in the
past, however, do keep in mind the rule about standards:

With standards you don't necessarily get what you want,
but you usually will get something you can live with.


Just so you understand the process we are currently are
using (and may become the model for future revisions):
things that are high value and someone is interested
in working on will get worked on. Keep in mind that they
will have to be traded off between other potential candidate
solutions. So far this seems to have been working well.

If you don't have alot of time, working on just one proposal
that has high value to you is great. If you don't feel
up to working on language proposals, even being aware of
what we are doing and telling your vendors which proposals
are of high value to you will ensure that your vendors take
note and start consider how they are going to implement
the features.

Beyond language proposals, if you look at the big differences
between the capability of "C" and VHDL, you will note that it
is not in the langauge capability, but the fact that C has
an extensive number of libraries. VHDL has some ground to
cover with respect to implementing packages.

Again, if you don't feel up to writing these sort of things,
we will need people who try them out. Make sure the use
model is ok. Test them and find bugs.

There is plenty to do. As we finish the fast track phase and
move to the next phase, we are going to need to do more planning.
Once that planning is complete, we will be able to be more
specific about what needs to be done.

Beyond this, while most WG activities are done on a voluntary
basis, LRM editing is a paid position and we need between
$100K and $150K to finish fast track edits. If you know of
an organization who is willing to help us reach our goal,
please let myself or Steve Bailey (VASG Chair) know. Please
note that neither IEEE dues nor IEEE-SA dues nor donations
to IEEE-SA go to fund IEEE standards working groups. Only
donated directly to the working group funding organization
goes to the working group.


Best Regards,
Jim Lewis
VASG Vice Chair
VHDL-200X Fast Track Co-Team lead
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Jim Lewis]

Ralf Hildebrandt 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?

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

On a similar note, is there another answer for paramterizing
entity interfaces such as introducing some type of interface
abstraction.

---

BTW, the way I currently handle entities is to define all of
the signals. For designs that don't need some of the IO, I
tie off the inputs to constants and leave outputs open.
For FPGA tools this seems to be enough.

For ASIC tools, I instantiate the block inside of another block
with the only the IO I need and then during synthesis, remove
the level of hierarchy for the re-usable component. The result
is a single component without any unused IO. A few more tool
steps but it gets the job done.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Jim Lewis]

Tim,

Possibly not for pre-processing, as long as the pragma issue is
addressed somehow.
Very few of the synthesis tool pragmas made it into 1076.6

(the VHDL RTL Synthesis Standard). Instead 1076.6 mostly
uses attributes.

Unfortunately, there is nothing a standards organization can
do to prevent tool vendors from doing their own things that
are outside of the language. So I think WRT pragmas, we are
stuck. Perhaps what you need is a switch or configuration for
your synthesis tool that says don't do pragmas or only do IEEE
standard pragmas. With this said, you would have to convince
your tool vendor that it is worthy for them to spend the money
to implement this feature.

If you want more standard attributes in standard IEEE 1076.6,
talk to your tool vendors and tell them the importantance
of standards and ask them to join the 1076.6 working group
(and get them to kick off the next revision of the standard).

However, I would still like to see a macro capability. Generates are
powerful and can do many things, but sometimes they either just aren't
enough (lack of an "else" clause is a big failing), or are way too complex.

We considered this for VHDL-200X fast track, but decided
it is more complex than we wanted to tackle in that revision.
The problem is that every branch through a if/else
generate or case generate would need to create an
independently named block (that can be referenced in
a configuration). Going further should each branch also
have a separate declarative region? There is no reason
that this cannot be worked on in the next phase of
VHDL-200X. The only thing we need is for someone to step
forward who wants to work on it.

I have a number of things I personally want to spend time
on in the next revision. This one unfortunately does not
make my list. Not because it is not worthy - but instead
because there are other things that have higher value to me
(and I am selfish).

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Kai Harrekilde-Petersen]

"Weng Tianxiang" <wtx@umem.com> writes:

Hi,
I would like to ask for your opinions on one design issue.

Our PCI-Express design has 3 clocks: one from local clock source on our
board to generate DDR signals;
Another two clocks are from transition line and receiving clock is
extracted from transition 8B/10B signals.

There are two methods we are considering:
Our most VHDL control code is based the receiving clock extracted
from 8B/10B signals and the handling is synchonous with receiving data.


Another design uses its local clock to handle the received data.

If there is any problem with the first method?

Just make sure that you are using a PLL to extract and stabilizing the
receive clock. Also, make sure that in case the 8B/10B input ceases,
that you are able to switch over to an internally generated clock for
the PLL.

If you do this, I don't see any problems in using the receiving clock.


Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>