Clock Edge notation

[Jonathan Bromley]

On Wed, 12 Jan 2005 00:31:40 +0100, Jan De Ceuster
<jan.de.ceuster@xs4all.be> wrote:

I have a vector such as:

signal counter : unsigned(7 downto 0);

and want to set it to and integer (say 1). I have lots of cumbersome
ways to do it:
[snip]

What I would really like to do is overload assignment "<=" so I could
just write:

counter <= 1; -- My idea of elegant

but I don't think VHDL allows that

No, there's no overloading of assignment. A fine opportunity for
religious warfare.

It would be nice if VHDL had a "just copy the damn bits" assignment
operator, maybe call it "<-",

You're entitled to your own opinion

Ok, not the most interesting problem in the world, but VHDL type
conversion can be an awful pain at times.

I think it's quite interesting; this kind of thing can make
or break the readability/maintainability of a piece of code.

Don't forget functions and procedures.

procedure Just_Copy_The_Damn_Bits_As_Unsigned_Binary (
signal S: out std_logic_vector;
N: in natural ) is
begin
S <= std_logic_vector ( to_unsigned ( N, S'length ) );
end;
...
JCTDBAUB ( counter , 1 ); -- Maintainable, clear, short

It is left as a trivial exercise for the reader to invent
a better name than JCTDBAUB for that procedure.

If you have a commonly-used subtype, it can be clearer to
use a function...

subtype Machine_Word is std_logic_vector(15 downto 0);
function to_Word ( N: in natural ) is
begin
return std_logic_vector (
to_unsigned ( N, Machine_Word'length ) );
end;
...
counter <= to_Word(1);

All these points are simple and obvious, but easy to
forget in the maelstrom of coding a significant design.
My golden rule is: as soon as I write a fragment of code
for the second time, it's a good moment to write a subprogram.

~~~~~~~~~~ end of sensible advice : start of rant ~~~~~~~~~~~

None of this alters the fact that the lack of assignment
overloading is a sad omission from VHDL. Obviously it's
made more difficult by the existence of two assignment
operators := and <= , but it seems to me that you don't
ever want to change the semantics of signal updating;
therefore, overloading := would be sufficient if you
accept that signal assignment is effectively a variable
assignment, to a hidden temporary variable of the same
subtype as the signal, followed by an update of the
signal using the value held in the hidden variable.

Fixed point arithmetic is an obvious example of a
situation where the lack of assignment overloading
is pretty much disastrous:

variable I: unsigned_fixed(3 downto 0); -- 4-bit integer
variable F: unsigned_fixed(-1 downto -4); -- 4-bit fraction
...
I := F; -- Ha ha, you inadvertently multiplied it by 16
-- and there's nothing the compiler can do to stop you!
--
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.

 

[tom]

Moti wrote:

Thanks Falk and Nicolas,

the NxN array seems like a good idea - I was just looking for some
more
elegant
solution (like a special generate) for the code to be more readable..
But it looks like I have no choise.

You always have a choice. For recursive hardware structures, choose
confluence:

- component pyramid +count +in -out is
- if width in == 0
- out = ''
- else
- out = {pyramid (count + 1) ('msbs' in) $} '++'
- {regs 1 count ('lsb' in) $}
- end
- end

http://www.confluent.org/

-Tom

 

[Moti]

You always have a choice. For recursive hardware structures, choose
confluence:

- component pyramid +count +in -out is
- if width in == 0
- out = ''
- else
- out = {pyramid (count + 1) ('msbs' in) $} '++'
- {regs 1 count ('lsb' in) $}
- end
- end

http://www.confluent.org/

-Tom

It's never too late to learn a new language
Thanks for the tip, but I think that VHDL will have to do (for now)..
Moti.

 

[Göran Bilski]

Moti wrote:

You always have a choice. For recursive hardware structures, choose
confluence:

- component pyramid +count +in -out is
- if width in == 0
- out = ''
- else
- out = {pyramid (count + 1) ('msbs' in) $} '++'
- {regs 1 count ('lsb' in) $}
- end
- end

http://www.confluent.org/

-Tom


It's never too late to learn a new language
Thanks for the tip, but I think that VHDL will have to do (for now)..
Moti.

You can also do recursive hardware in VHDL.
Although it's not as small as confluence.


Göran

 

[tom]

Why not use Confluence to generate your low level components, then
instantiate them into your higher-level designs?

(Note: Confluence 0.9.3 is the latest version with support for VHDL.
0.10.0 is Verilog-only at this point. VHDL will be back on-board with
0.10.1.)

-Tom

 

[7]

Sven Lossman wrote:

Here is a very sweet game for Linux/Windows/Apple.

http://cube.sourceforge.net/

Question from a newbie.

The game I know is excellent providing you have OpenGL working.
But not every liveCD for example boots up with OpenGL working.

The question for those in the know, is why is OpenGL not
integrated into the heart of X?

What I'm really getting at is why is 3D speedy graphics
methods not part of X?

I can imagine it is beneficial for hardware makers
to have some minimal standard to which they can make 3D
cards. To design good 3D cards, you would just need some
good VHDL engineers to make the samples out of FPGA and then
tape out the chips. If you open source the 3D card specs,
the VHDL can also be open sourced (e.g http://www.opencores.org ),
and then you can just download the best VHDL,
and add the extra customisations for making
a great video card at very little development cost.
Just a suggestion.

 

[Mike Treseler]

Clemens wrote:

I have modified the code a little bit so that it is easier readable. It
works fine, but I wonder if there is a nicer, more professional way to solve
this task. Because the way I do it I need an 128 bit latch, to store my
value before I write it to the memory.

It's readable, it's synchronous, it fits and it works.
If the fpga and coprocessor use the same clock,
I don't see much more design work to do.
The 128 bits of register are essential.

The "professional" aspect includes completing
verification and documentation:

Verify Fmax margin in the static timing report.
Upgrade your vhdl testbench to pass/fail.
Check the test coverage and add some corner cases to your testbench.
Cut the operation description from your
posting here and paste it as a comment into your source code.
Check all the vhdl and script sources into an RCS directory
or CVS server to control changes and versions.

-- Mike Treseler

 

[Neo]

Its very rarely used but I think some go for it to avoid declaring
those extra signals reqd otherwise. still its not a good idea as you've
stated.

 

[Jezwold]

I am just interested in how anyone would put a design team under
pressure to do anything,hearding cats while riding a unicycle and
juggling at the same time would be easier I should think.

 

[Paul Uiterlinden]

Winston Smith wrote:

Does anyone else have an objective opinion on BUFFER, especially any
synthesis issues? Besides it being a pain in the ass.

It is not a pain if it is used consistently. Only then it will become a
gain in stead of a pain.

Years ago the design teams I was working in decided to use BUFFER, with
a few simple rules when to use IN, OUT, INOUT or BUFFER. See

http://www.google.nl/groups?hl=nl&lr=&q=uiterlinden+buffer+unidirectional+group%3Acomp.lang.vhdl&btnG=Zoeken

We still use these rules and it works just fine, both for simulation as
well for synthesis.

Another thing is that there seem to be some relaxations underway in the
new VHDL standard with respect to BUFFER and OUT. I don't know the
details though.

Paul.

 

[Dave Higton]

In message <dml0019ifuctbchv6b40fso880id77tqkm@4ax.com>
Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
wrote:

The next rev of VHDL will allow 'out' ports to be read within an
architecture. This makes 'buffer' even less useful.

This looks like a good move. It's always seemed silly to me that VHDL
doesn't allow you to read the value of an output port. Why not? You're
entitled to know, since it was you that set it. But in order to satisfy
VHDL, you have to go through this clumsy procedure of setting an internal
signal, then copying the internal signal to the output port; then you
have to remember to reference the internal signal, not the external one.
Clumsy.

Using buffer instead of output seemed to be good; it looks to me like an
output whose value you can read. Great. I don't know of any other
difference - but I'm ready to learn! However, ModelSim is pedantic, too.
If I create an entity containing a signal of type buffer in a lower
level, and connect it to a signal of type output on a higher level,
ModelSim objects. The signal has to be of type buffer all the way
up the hierarchy, right to the output pin. There's some reason, that I
can't remember right now, why that's inconvenient. (It's a long time
ago that I last tried it.)

Dave

 

[Ralf Hildebrandt]

pflloyd wrote:

process(Reset, DataSentTouCAck, Latch_FMU_Bus)
variable temp : bit;
begin
if Reset = '1' then
temp := '0';
elsif DataSentTouCAck'event and DataSentTouCAck = '1' then
temp := '0';
elsif Latch_FMU_Bus = '1' then
temp := '1';
end if;
DataInLatchToFMUValid <= temp;
end process;

When I compile this I get the following error

Can't infer register for signal "temp" because signal does not hold its
value outside clock edge

This process is just a D-FF with an asynchronous reset.

process(Reset, DataSentTouCAck, Latch_FMU_Bus)
variable temp : bit;
begin
if Reset = '1' then
temp := '0';
elsif Latch_FMU_Bus = '1' then
temp := '1';
elsif DataSentTouCAck'event and DataSentTouCAck = '1' then
temp := '0';
end if;
DataInLatchToFMUValid <= temp;
end process;

Async set / rest is not allowed in an elsif branch after an 'event.

Ralf

 

[Nicolas Matringe]

Ralf Hildebrandt a écrit :

process(Reset, DataSentTouCAck, Latch_FMU_Bus)
variable temp : bit;
begin
if Reset = '1' then
temp := '0';
elsif Latch_FMU_Bus = '1' then
temp := '1';
elsif DataSentTouCAck'event and DataSentTouCAck = '1' then
temp := '0';
end if;
DataInLatchToFMUValid <= temp;
end process;

Async set / rest is not allowed in an elsif branch after an 'event.

Not sure this will compile either, if the EPM doesn't have FFs with both
async set and preset.


--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/

 

[scottypc]

You need to seriously consider taking a VHDL for beginners class. That
code is terrible.

 

[Winston Smith]

"Jezwold" <edad3000@yahoo.co.uk> wrote in news:1107331558.335105.133270
@c13g2000cwb.googlegroups.com:

I am just interested in how anyone would put a design team under
pressure to do anything,hearding cats while riding a unicycle and
juggling at the same time would be easier I should think.

In large corporations there is always a push to standardize and control
everything. That way all initiative can be safely removed and only a mere
set of processes remain.

That is why small start-ups come up with all the great new ideas.

Some significant degree of coordination is needed on a big team, especially
if one were to use BUFFERS. Then there is a a need to coordinate the INs
and OUTs usually there are few INOUTs that are well known.

 

[Jezwold]

The sample code you gave just compiled correctly under modelsim 5.3 and
the only error i got was that Array case expressions must not be in
parentheses.

 

[Jezwold]

Having read some of the comments it apears that you should in fact get
an error because its not a locally static variable,so I susspect
version 5.3 is incorrect and later versions have been modified to more
acuratly follow the lrm

 

Thanks for your answer.

What makes 'sel_sig' type not locally static. Is it because the type
of sel_sig is std_logic_vector, which is defined as an unbounded array,
even though the entity port description bounds the array?

If I use the internally declared 'sel_sig_i' signal for the selector
expression. I get the same warning. In this case, the signal's type
is defined in the file, it is bounded, I am not making a subtype of an
unbounded array. Why isn't this not locally static?

I have tried to understand the LRM's definition, but I find the wording
confusing.



Thanks again
Calvin

 

[Mike Treseler]

Philipp wrote:

_Building and optimizing final netlist ...
_Register outp_0 equivalent to accu1_8 has been removed

Those are synthesis warnings.
Maybe "outp" doesn't affect any entity ports.
Did your simulation work as expected?

-- Mike Treseler

 

[Philipp]

Those are synthesis warnings.
Maybe "outp" doesn't affect any entity ports.
Did your simulation work as expected?

yes simulation works as expected. I get an answer from Paul in the FPGA
Forum and he thinks

outp and accu have many bits which will always have the same value. The
synthesis tool notices this, and thus decides to reusue the accu register to
feed whatever the corresponding bits of the outp register feed.

For example, outp(0) is always accu(0). So is accu1(8). So using accu1(8)
everywhere that outp(0) is used is logically equivalent, and uses fewer
resources.

Now the question is if it is okay to leave it this way and let the
synthesizer do the work