Clock Edge notation

[Al]

Mike Treseler wrote:

Al wrote:


In old archives I found this thread, started from ALuPin.
I think I have the same problem when trying to "add wave" internal
signals with ModelSim.
Any suggestions?


Maybe you didn't try this.
add wave -r /*

-- Mike Treseler

Ok, so the recursive option will include all the opjects starting from
the / point. Still there should be a way to search for an internal
signal (unless it is pruned away from the synthesizer), whether if it is
a vector of signals or a single one.
With your suggestion I managed to make a better search and I realized
that all the vectors will be add as they are only if there are no
optimization at the netlist level (of course), in that case it's needed
to specify directly the name of the vector index like this:

add wave {sim: /tb/dut/\data_reg[12]\/q}

So which is the meaning of -internal option? It didn't change anything
even on source simulation.

--
Alessandro Basili
CERN, PH/UGC
Hardware Designer

 

[Mike Treseler]

Al wrote:

Still there should be a way to search for an internal
signal (unless it is pruned away from the synthesizer), whether if it is
a vector of signals or a single one.

I use find nets

let's see

63 Sat Nov 11 /evtfs/home/tres/vhdl/ref_design> vsim -c test_uart
Reading /flip/usr1/modeltech/tcl/vsim/pref.tcl
VSIM 1> find nets write_stb_s
# /test_uart/write_stb_s

There's also a gui find that works with waveforms.

So which is the meaning of -internal option? It didn't change anything
even on source simulation.

Don't know. Check the docs.

-- Mike Treseler

 

[Al]

Mike Treseler wrote:

Al wrote:


Still there should be a way to search for an internal
signal (unless it is pruned away from the synthesizer), whether if it is
a vector of signals or a single one.


I use find nets

let's see

63 Sat Nov 11 /evtfs/home/tres/vhdl/ref_design> vsim -c test_uart
Reading /flip/usr1/modeltech/tcl/vsim/pref.tcl
VSIM 1> find nets write_stb_s
# /test_uart/write_stb_s

There's also a gui find that works with waveforms.

That helped a lot! Thanks.

So which is the meaning of -internal option? It didn't change anything
even on source simulation.


Don't know. Check the docs.

Here is what the docs say:

ModelSim Command Reference

add wave
.
.
-internal
For use with wildcard searches. Specifies that the scope of the search is to include
internal objects (non-port objects) if they match the object_name specification. Optional.

But apparently it doesn't do what is expected to do. Apparently the -r
option is much more efficient.



--
Alessandro Basili
CERN, PH/UGC
Hardware Designer

 

[Thomas Stanka]

On 26 Jan., 07:37, "Shenli" <zhushe...@gmail.com> wrote:

Hi all,

I am reading "Coding Guidelines for Datapath Synthesis" from Synopsys.

It says "The most important technique to improve the performance of a
datapath is to avoid expensive carry-propagations and to make use of
redundant representations instead (like carry-save or partial-product)
wherever possible."

1. Is there any article talk about what's "carry-propagation" and how
to avoid use it?

When adding two words, you might get a carry at a bit position
affecting all "higher" bits of the result.
The task of spreading this carry to all other bits is the propagation.
Start with the following site:
http://en.wikipedia.org/wiki/Adder_%28electronics%29
It yould be good to use google to answer questions the article may
left.

2. What's "redundant representations" mean?

Redundant in this case means you double your logic to calculate one
block with carry = 0 and one with carry = 1 and select the result
depending on the real carry. This is useful, if you use blocks of 4 to
8 bits for adding two 64 bit integer as the longest path reduces from
64 full adder to eg. 8 bit full adder plus something like 8 mux to
select the correct result.

If you use an FPGA, you wil detect, that you have fast carry chains
that outperfom most other adder solutions, so this guide is wrong for a
lot of designs.

bye Thomas

 

[Weng Tianxiang]

On Jan 29, 2:10 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On 28 Jan 2007 15:39:20 -0800, "Weng Tianxiang"

wtx...@gmail.com> wrote:
I want a global error signal to indicate the situation and I am not
interested in complex design and all FIFO will be called using one
simple module.

The global error signal applies not only to FIFOs, but also to any
module if there is an error situation happening and it will indicate:
Hi, it is error here in this clock !!! Using this signal will greatly
reduce error debugging time also.Weng,

If this is for simulation only, then you can use global signals.

We have, in the past, suggested using an array of global
signals, one for each instance that you are debugging. You can
then attach a generic to each instance, and use it to determine
which signal is driven by that instance:

package DEBUG_SUPPORT is
signal s: std_logic_vector(1 to 100);
end package DEBUG_SUPPORT;

use work.DEBUG_SUPPORT;
entity DEBUG_ME is
generic (DEBUG_ID: natural := 0);
port (....);
end;
architecture TRACEABLE of DEBUG_ME is
-- Internal signal that reflects the error condition
signal HIGH_WHEN_ERROR: std_logic;
begin
...
... all your other stuff
...
DEBUG_TRACING: if DEBUG_ID > 0 generate
DEBUG_SUPPORT.s(DEBUG_ID) <=
'1' when HIGH_WHEN_ERROR = '1'
else '0';
end generate;
end;

However, that's a little messy because you must now use a
complicated hierarchical configuration to assign the right
generic value to each instance. An alternative possibility
is to use a resolved signal for just one global debug signal.
I don't have time to sketch that out now, but if the generics
method doesn't work for you, reply to this and I'll try to post
an example in the next day or two.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

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

Hi Jonathan,
Thank you for your help.

I have used one of your post on how to generate random number such
that I know your name very well.

Actually I would like to suggest to add a VHDL language element to
resolve the similar problem: how to set or reset a global signal
without consideration of their assertion or deassertion time.

Why VHDL requires that programmers be allowed to assert or deassert a
signal only in one process is to keep their clock relationships
without ambiguity: on which conditions it must first be asserted or
deasserted and on what other conditions it must be deasserted or
asserted and so on.

But in reality, there are times, for example, in global error
reporting mechanism, the timing to assert or deassert don't matters.
It will be very convenient for VHDL to have a global signal type a
signal of which can be asserted or deasserted in any processes many
times and without consideration of their timing relations.

There are two global types of signals: assert first and deassert 2nd.

If above mechanism exists, my design problem can be easily resolved:
1. In a package, declare a signal of that type(global type with
assertion first and deassertion 2nd);
2. In any process, code can be written to assert the signal or
deassert the signal with adding of package;
3. Compiler is responsible to collect all assert conditions and all
deassertion conditions, then generate equations that first assert the
signal and then deasser the signal. The final equation is as follows:
if(all assertion conditions are ORed here) then
the-first-assert-2nd-deassert-global-signal <= '1';
elsif(all deassertion conditions are ORed here) then
the-first-assert-2nd-deassert-global-signal <= '0';
end if;

This type of definitions will not add any harms to VHDL, but simplify
programming in some situations dramatically.

I don't know if the similar definition exists in current VHDL.

Thank you.

Weng

 

[Neo]

Weng Tianxiang wrote:

On Jan 29, 2:10 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com
wrote:
On 28 Jan 2007 15:39:20 -0800, "Weng Tianxiang"

wtx...@gmail.com> wrote:
I want a global error signal to indicate the situation and I am not
interested in complex design and all FIFO will be called using one
simple module.

The global error signal applies not only to FIFOs, but also to any
module if there is an error situation happening and it will indicate:
Hi, it is error here in this clock !!! Using this signal will greatly
reduce error debugging time also.Weng,

If this is for simulation only, then you can use global signals.

We have, in the past, suggested using an array of global
signals, one for each instance that you are debugging. You can
then attach a generic to each instance, and use it to determine
which signal is driven by that instance:

package DEBUG_SUPPORT is
signal s: std_logic_vector(1 to 100);
end package DEBUG_SUPPORT;

use work.DEBUG_SUPPORT;
entity DEBUG_ME is
generic (DEBUG_ID: natural := 0);
port (....);
end;
architecture TRACEABLE of DEBUG_ME is
-- Internal signal that reflects the error condition
signal HIGH_WHEN_ERROR: std_logic;
begin
...
... all your other stuff
...
DEBUG_TRACING: if DEBUG_ID > 0 generate
DEBUG_SUPPORT.s(DEBUG_ID) <=
'1' when HIGH_WHEN_ERROR = '1'
else '0';
end generate;
end;

However, that's a little messy because you must now use a
complicated hierarchical configuration to assign the right
generic value to each instance. An alternative possibility
is to use a resolved signal for just one global debug signal.
I don't have time to sketch that out now, but if the generics
method doesn't work for you, reply to this and I'll try to post
an example in the next day or two.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

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

Hi Jonathan,
Thank you for your help.

I have used one of your post on how to generate random number such
that I know your name very well.

Actually I would like to suggest to add a VHDL language element to
resolve the similar problem: how to set or reset a global signal
without consideration of their assertion or deassertion time.

Why VHDL requires that programmers be allowed to assert or deassert a
signal only in one process is to keep their clock relationships
without ambiguity: on which conditions it must first be asserted or
deasserted and on what other conditions it must be deasserted or
asserted and so on.

But in reality, there are times, for example, in global error
reporting mechanism, the timing to assert or deassert don't matters.
It will be very convenient for VHDL to have a global signal type a
signal of which can be asserted or deasserted in any processes many
times and without consideration of their timing relations.

There are two global types of signals: assert first and deassert 2nd.

If above mechanism exists, my design problem can be easily resolved:
1. In a package, declare a signal of that type(global type with
assertion first and deassertion 2nd);
2. In any process, code can be written to assert the signal or
deassert the signal with adding of package;
3. Compiler is responsible to collect all assert conditions and all
deassertion conditions, then generate equations that first assert the
signal and then deasser the signal. The final equation is as follows:
if(all assertion conditions are ORed here) then
the-first-assert-2nd-deassert-global-signal <= '1';
elsif(all deassertion conditions are ORed here) then
the-first-assert-2nd-deassert-global-signal <= '0';
end if;

This type of definitions will not add any harms to VHDL, but simplify
programming in some situations dramatically.

I don't know if the similar definition exists in current VHDL.

Thank you.

Weng

Hi,
The thing which you are talking about is already there in the language
since its inception. The signals in the larger scope can be assigned
in multiple processes, you just have to use the appropriate library
which has the resolved signal types.

Thanks
neo

 

[Jonathan Bromley]

On 29 Jan 2007 15:49:03 -0800, "Weng Tianxiang"
<wtxwtx@gmail.com> wrote:

But in reality, there are times, for example, in global error
reporting mechanism, the timing to assert or deassert don't matters.
It will be very convenient for VHDL to have a global signal type a
signal of which can be asserted or deasserted in any processes many
times and without consideration of their timing relations.

Personally I think that you are trying to imagine a mechanism
that is too much like hardware. This kind of idea makes sense
only for simulation, and in simulation there are other ways to
do it.

One interesting possibility is to use a shared variable, and
shared procedures, in a package. Note that this needs to
be compiled using VHDL-93; if your compiler supports
VHDL-2002 it will expect you to use protected types, which
is more complicated (but still possible).

package DEBUG_TOOLS is
variable debug_flag: boolean := FALSE;
procedure set_debug_flag(new_value: boolean; ID: integer);
end;
package body DEBUG_TOOLS is
procedure set_debug_flag(new_value: boolean; ID: integer) is
variable L: line;
begin
report "Debug flag was " & boolean'image(debug_flag) &
", set to " & boolean'image(new_value) &
" by ID=" & integer'image(ID);
debug_flag := new_value;
end;
end;

Now I can "use work.DEBUG_TOOLS.all;" in any design,
and simply by calling the procedure I can do whatever
special action I want on reporting an error. I have used
similar techniques to implement coverage data collection
in VHDL without using vendor-specific signal probing tools.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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

 

[Ashu]

With external serdes it is possible to clock data close to 8 GBPS.

 

[Ashu]

On Jan 31, 11:22 am, "Ashu" <ashish.shringarp...@gmail.com> wrote:

With external serdes it is possible to clock data close to 8 GBPS.

There and various Highspeed (>1GBPS) products available in the market,
its ultimately the GBPS/no. of line that really counts for the speed.
Mostly 10GBPS is a parallel implementation.

I worked on 4G/8G serial implementation, using FPGA and external
serdes. But there are tooo many challenges working at that speed from
FPGA, serdes and board pointof view.

You can get any throughput by multiplying no of lines...(PCIe way!!!)

I am not aware abt any >8GBPS achieved on serial bus.
If yes, letme know....

 

[Colin Paul Gloster]

I post from news:comp.lang.ada to news:comp.lang.vhdl .

Stephen A. Leake wrote in news:news:u649rx29a.fsf@stephe-leake.org on
news:comp.lang.ada for the benefit of Mike Silva:

"[..]

[..] FPGA development relies heavily on simulation,
which does not require real hardware."


A warning to Mike Silva: supposed simulators for languages chiefly
used for FPGAs often behave differently to how source code will
actually behave when synthesized (implemented) on a field programmable
gate array. This is true of cheap and expensive tools promoted as
simulators.


Stephen A. Leake wrote in news:news:u649rx29a.fsf@stephe-leake.org on
news:comp.lang.ada :

"[..]

Someone who can do both Ada and VHDL would be a very valuable person!"


A very euphemistic approach to stating that someone who could not do
one of Ada and VHDL after a few days with literature and tools, is
probably not good at the other of VHDL and Ada.


In newsan.2007.02.24.22.11.44.430179@linuxchip.demon.co.uk.uk.uk
timestamped Sat, 24 Feb 2007 22:10:22 GMT, "Dr. Adrian Wrigley"
<amtw@linuxchip.demon.co.uk.uk.uk> posted:
"On Sat, 24 Feb 2007 07:27:01 -0500, Jeffrey Creem wrote:

Stephen Leake wrote:

Someone who can do both Ada and VHDL would be a very valuable person!

I'm always surprised that VHDL engineers are not more open to Ada given
how close the syntax is. The standard joke where I work is that VHDL is
just like Ada except the capslock is always stuck on and comments are
apparently forbidden "

Just as one can find expert C++ programmers who lament what C++ code
from typical C++ programmers and typical C++ education are like, one
can find expert VHDL interlocutors who are not fond of typical VHDL
users. Such people who are so incompetent with VHDL are incompetent
with it because they are forced to use VHDL and they can get away with
not being good at it, so they are not likely to really want to use Ada either.


"I came to Ada from VHDL. When I first encountered VHDL, my first though
was "Wow! You can say what you mean clearly". Features like user
defined types (ranges, enumerations, modular types,"


VHDL does not have Ada 2005's and Ada 95's mod types (
WWW.AdaIC.com/standards/05rm/html/RM-3-5-4.html
), unless I am mistaken.


" multi-dimensional
arrays) gave a feeling of clarity and integrity absent from software
development languages."


Apparently for many years, VHDL subset tools (the only kind of VHDL
tools which exist, so even if the language was excellent one would
need to restrict one's code to what was supported) used to not support
multi-dimensional arrays.


"So when I found that you could get the same benefits of integrity
in software development from a freely available compiler, it didn't
take long to realize what I'd been missing! Ada is without doubt
the language at the pinnacle of software engineering, and infinitely
preferable to Pascal, C++ or Modula 3 as a first language in teaching."


Ada is good in the relative sense that it is less bad than something
which is worse than Ada, which is in no way similar to an absolute
statement that Ada is not bad. Unfortunately Ada (including VHDL)
allows

procedure Ada_Is_As_Unsafe_As_VHDL_And_GNAT_Will_Not_Even_Warn is
value,Y:Integer;
begin
if False then
Value:=0;
end if;
Y:=Value;
end Ada_Is_As_Unsafe_As_VHDL_And_GNAT_Will_Not_Even_Warn;
--GNAT is an abbreviation of "the GNU Ada Translator".

I do not know Modula-3 and Oberon. Do they allow such a trivially
detectable accident?


Dr. Adrian Wrigley wrote:

"But I have ever since wondered why the VHDL and Ada communities
are so far apart."


Sometimes they are not as ignorant of each other as they might
typically be. E.g. Ada 95's and the latest VHDL's permissiveness of
reading things of mode out may be just a coincidence, unlike the
syntax for protected types in IEEE Std 1076-2002 which is copied from
ISO/IEC 8652:1995 (however the semantics are not fully copied,
e.g. mutual exclusion is ridiculously stipulated in VHDL for pure
functions on a common protected object). It is true that the
communities are not always close, e.g. shared variables were
introduced in IEEE Std 1076-1993 and were very bad (but at least even
IEEE Std 1076-1993 contained an explicit warning against them). In my
experience, a person who has specialized in VHDL has heard of Ada but
has not been interested to read anything about Ada except in a brief
history of how VHDL had been started.


" It seems like such a natural partnership for
hardware/software codevelopment."


A thing which may be perceived to be obvious to one might not be perceived to
be such by another. For example, from Jamal Guennouni, "Using Ada as a
Language for a CAD Tool Development: Lessons and Experiences",
Proceedings of the fifth Washington Ada symposium on Ada WADAS 1988:

"[..]

[..] On the other hand, our approach for hardware
description is also different from the one taken by Shahdad.
Indeed, we have stuck to the Ada language whereas Shahdad
[20] has developed a new language based on Ada called
VHDL (a part of the VHSIC program) dedicated to
hardware description and simulation. Moreover, we have
used the same language (i.e., Ada) for hardware and
software simulations whereas the VHDL language is used
for hardware descriptions only. This has several drawbacks
since it sets up a border between a software designer and a
circuit designer. It cannot benefit from the advantages connected
with the use of a single language during the whole
design process (e.g., use of the existing development and
debugging support tools).

[..]"

Don't get excited, Jamal Guennouni was writing about Ada for hardware
much as VHDL had been originally intended for hardware - that is: not
for automatic generation of a netlist. However, work on subsets for
synthesizable Ada has been expended. Now you may become excited, if
you are willing to allow yourself the risk of becoming disappointed,
after all if work was published on this in the 1980s then why did
WWW-users.CS.York.ac.UK/~mward/compiler/
get a publication in 2001 without citing nor even mentioning any of
the earlier relevant works of synthesizable Ada projects?


Dr. Adrian Wrigley wrote:

" And there is significant scope
for convergence of language features - fixing the niggling and
unnecessary differences too."


That would be nice. However complete uniformity shall not happen if
things which are currently compatible are to maintain
compatibility. Does it really make sense to replace one
incompatibility with compatibility and at the same time replace a
different compatibility with an incompatibility? E.g. VHDL differs
from Ada in not allowing to specify an array's dimensions as
follows: array (address_type'range) if address_type is an INTEGER
(sub)type (making array(address_type) legal) but if address_type is a
(sub)type of IEEE.numeric_std.(un)signed it is legal to have
array(address_type'range) but it means something different because
VHDL (un)signed is an array type (making array(address_type) illegal).

Should Ada's attribute 'First refer to the lower bound of the index of
a type based on IEEE.numeric_std.(un)signed or to the lower bound of
the numbers which can be interpreted as being represented by such an
array? It is impossible to choose one or the other without a resulting
incompatibility.

In Ada 2005 and Ada 95, a mod type which represents a whole
number is treated not as an array type when applying attributes,
but in VHDL, IEEE.numeric_std.unsigned and IEEE.numeric_std.unsigned
are treated as array types when applying attributes, even though they
may be treated as whole numbers in other contexts. Mod types and
IEEE.numeric_std.(un)signed are used for logical either true or false
operators.

Even in Ada, an array of Ada Booleans is not identical to an Ada mod
type, and even in VHDL, IEEE.numeric_std.unsigned and INTEGER are not
identical, so why should a huge amount of effort be spent to integrate
similar or other aspects of Ada and VHDL?


" Physical types,"


Why bother?


" reverse ranges,"


Stephen A. Leake responded in news:u7iu68eba.fsf@stephe-leake.org :

"[..] reverse ranges make things ambiguous, especially for slices of
unconstrainded arrays. So I don't want to see those in Ada."


Maybe. From the VHDL standard:
"[..]
[..] the following two block configurations are equivalent:
for Adders(31 downto 0) ... end for;
for Adders(0 to 31) ... end for;
[..]
Examples:
variable REAL_NUMBER : BIT_VECTOR (0 to 31);
[..]
alias MANTISSA : BIT_VECTOR (23 downto 0) is REAL_NUMBER (8 to 31);
-- MANTISSA is a 24b value whose range is 23 downto 0.
-- Note that the ranges of MANTISSA and REAL_NUMBER (8 to 31)
-- have opposite directions. A reference to MANTISSA (23 downto 18)
-- is equivalent to a reference to REAL_NUMBER (8 to 13).
[..]"

It is true that an illegal description can result by mixing up
directions, but could you please give a concrete example of how
directions can be ambiguous? The VHDL attribute 'RANGE returns
"The range A'LEFT(N) to A'RIGHT(N) if the Nth index range
of A is ascending, or the range A'LEFT(N) downto
A'RIGHT(N) if the Nth index range of A is descending", and similarly
'REVERSE_RANGE returns "The range A'RIGHT(N) downto A'LEFT(N) if the
Nth index range of A is ascending, or the range A'RIGHT(N) to
A'LEFT(N) if the Nth index range of A is descending." Similarly:
"NOTES
1 - The relationship between the values of the LEFT, RIGHT, LOW, and
HIGH attributes is expressed as follows:


Ascending range Descending range
T'LEFT = T'LOW T'HIGH
T'RIGHT = T'HIGH T'LOW"


Dr. Adrian Wrigley wrote:

"configurations, architectures,"


It is true that we miss these in dialects of Ada not called VHDL, but
we can cope. An interesting recent post on how to not bother with the
binding of a component instance to a design entity of an architecture by
a configuration specification without sacrificing the intended benefit
of configurations and architectures is
news:54gnriF20p8onU1@mid.individual.net


Dr. Adrian Wrigley wrote:

" defered constants"


Ada 2005 does allow deferred constants, so I am unsure as to what
improvement Dr. Wrigley wants for this area. Perhaps he would like to
be able to assign the value with := in the package body like in VHDL,
which is not allowed in Ada 2005. Perhaps Ada vendors would be willing to
make Ada less like C++ by removing exposed implementation details from
a package_declaration, but you would have been better off proposing
this before Ada 2005 was finalized.


Dr. Adrian Wrigley wrote:

" and ultra-light
concurrency come to mind from VHDL."


In what way is copying concurrency from VHDL where it is not already
present in Ada desirable?


Dr. Adrian Wrigley wrote:

" And general generics, private types,
tagged types, controlled types from Ada (does the latest VHDL have these?)"


No mainstream version of VHDL has these. Interfaces and tagged types might be
added in a future version:
WWW.SIGDA.org/Archives/NewsGroupArchives/comp.lang.vhdl/2006/Jun/comp.lang.vhdl.57450.txt


Stephen A. Leake responded:

"I haven't actually studied the additions in VHDL 2003, but I don't
think most of these Ada features make sense for VHDL. At least, if you
are using VHDL to program FPGAs.

[..]"

Why?

The latest IEEE VHDL standard, does not have these, but the IEEE VHDL
draft standard Draft IEEE P1076/D3.2, December 10, 2006 contains the
addition of subprogram and package generics but VHDL never had (and even
in the draft still does not have) generic instantiations in which the
parameter is a type (Ada83 had all of these kinds of generics). These
could be nice for FPGAs.


Dr. Adrian Wrigley wrote:

"Perhaps a common denominator language can be devised which has the
key features of both, with none of the obsolescent features,"


Perhaps. But people could continue with what they are using. From
Dr. SY Wong, "Hardware/Software Co-Design Language
Compatible with VHDL", WESCON, 1998:

"Introduction.
This Hardware/Software (hw/sw) Co-
Design Language (CDL) (ref.2) is a
small subset of ANSI/ISO Ada. It has
existed since 1980 when VHDL was
initiated and is contained in IEEE 1076
VHDL-1993 with only minor differences.
[..]"


Dr. Adrian Wrigley wrote:

" and
can be translated into either automatically?"

Stephe Leake responded:

"Why would you want to translate them into each other? The semantics
of
VHDL are _significantly_ different from Ada. A VHDL process is _not_
an Ada task.

[..]"


Perhaps for the same reasons people generate Verilog files from VHDL
files, and vice versa.


Dr. Adrian Wrigley wrote:

" Something like this
might allow a "rebranding" of Ada (i.e. a new name, with full buzzword
compliance), and would be ideal to address the "new" paradigm of
multicore/multithreaded processor software, using the lightweight
threading and parallelism absent from Ada as we know it. For those who
know Occam, something like the 'PAR' and "SEQ" constructs are missing in
Ada."


I really fail to see the relevance of multiple processors to
lightweight threading.

Apparently Verilog is used more than VHDL. Verilog apparently has very
little thought given to safe parallelism. (E.g. Jonathan Bromley on
2005 May 20th on news:comp.lang.vhdl :
"[..]

[..] Verilog's cavalier attitude to
process synchronisation (in summary: who cares?!) is a
major problem for anyone who has ever stopped to think about
concurrent programming for more than about five minutes.

[..]")
Papers on multicore topics in the near term are more likely to contain
SystemC(R) or SystemVerilog boasts. Some people do not reason. I was
recently involved in one of the European Commission's major multicore
research projects in which SystemC(R) development was supposedly
going to provide great temporal improvements, but it did not do so
(somehow, I was not allowed to highlight this). Is this a surprise?
From 4.2.1 The scheduling algorithm of "IEEE Standard SystemC(R) Language
TM
Reference Manual", IEEE Std 1666 -2005, "Approved 28 March 2006 American
National Standards Institute", "Approved 6 December 2005 IEEE-SA Standards
Board", supposedly "Published 31 March 2006" even though the Adobe
timestamp indicates 2006 March 29th, ISBN 0-7381-4870-9 SS95505:

"The semantics of the scheduling algorithm are defined in the
following subclauses.
[..]
An implementation may substitute an alternative scheme, provided the
scheduling
semantics given here are retained.
[..]
4.2.1.2 Evaluation phase
From the set of runnable processes, select a process instance and
trigger or resume
its execution. Run the process instance immediately and without
interruption up to
the point where it either returns or calls the function wait.
Since process instances execute without interruption, only a single
process instance
can be running at any one time, and no other process instance can
execute until the
currently executing process instance has yielded control to the
kernel. A process shall
not pre-empt or interrupt the execution of another process. This is
known as co-routine
semantics or co-operative multitasking.
[..]
A process may call the member function request update of a primitive
channel,
which will cause the member function update of that same primitive
channel to be
called back during the very next update phase.
Repeat this step until the set of runnable processes is empty, then go
on to the
update phase.
NOTE 1.The scheduler is not pre-emptive. An application can assume
that a
method process will execute in its entirety without interruption, and
a thread or clocked
thread process will execute the code between two consecutive calls to
function wait
without interruption.
[..]
NOTE 3.An implementation running on a machine that provides hardware
support
for concurrent processes may permit two or more processes to run
concurrently,
provided that the behavior appears identical to the co-routine
semantics defined in
this subclause. In other words, the implementation would be obliged to
analyze any
dependencies between processes and constrain their execution to match
the co-routine
semantics."

Anyone stupid enough to choose C++ deserves all the inevitable
woes. Especially as many of the involved parties did not even know C++
so allowable compilers were required to be restricted to a set of
compilers which are not conformant to the C++ standard as much of the
code was not written in genuine C++. This is not a surprise as the
Open SystemC Initiative's SystemC(R) reference implementation of the
time was written in an illegal distortion of C++.


Dr. Adrian Wrigley wrote:

"While the obscenities of C-like languages thrive with new additions
seemingly every month, the Pascal family has withered. Where is
Wirth when you need him?

(don't take it that I dislike C."


I dislike C.

" Or assembler. Both have their
legitimate place as low-level languages to get the machine code
you want. Great for hardware hacking. Lousy for big teams, complex code)

One can dream..."

C is not great for hardware hacking.

 

[Jean-Pierre Rosen]

Colin Paul Gloster a écrit :

procedure Ada_Is_As_Unsafe_As_VHDL_And_GNAT_Will_Not_Even_Warn is
value,Y:Integer;
begin
if False then
Value:=0;
end if;
Y:=Value;
end Ada_Is_As_Unsafe_As_VHDL_And_GNAT_Will_Not_Even_Warn;
--GNAT is an abbreviation of "the GNU Ada Translator".

I do not know Modula-3 and Oberon. Do they allow such a trivially
detectable accident?

Here is what AdaControl says about it:
Error: IMPROPER_INITIALIZATION: use of uninitialized variable: Value
Error: IMPROPER_INITIALIZATION: variable "value" used before
initialisation>

NB: I think this kind of analysis is for external tools, not for
compilers. Nice when compilers can provide extra warnings, but that's
not their primary job.
--
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

 

[Dr. Adrian Wrigley]

On Wed, 28 Feb 2007 17:20:37 +0000, Colin Paul Gloster wrote:
....

Dr. Adrian Wrigley wrote:

" Something like this
might allow a "rebranding" of Ada (i.e. a new name, with full buzzword
compliance), and would be ideal to address the "new" paradigm of
multicore/multithreaded processor software, using the lightweight
threading and parallelism absent from Ada as we know it. For those who
know Occam, something like the 'PAR' and "SEQ" constructs are missing in
Ada."

I really fail to see the relevance of multiple processors to
lightweight threading.

????

If you don't have multiple processors, lightweight threading is
less attractive than if you do? Inmos/Occam/Transputer was founded
on the basis that lightweight threading was highly relevant to multiple
processors.

Ada has no means of saying "Do these bits concurrently, if you like,
because I don't care what the order of execution is". And a compiler
can't work it out from the source. If your CPU has loads of threads,
compiling code with "PAR" style language concurrency is rather useful
and easy.
--
Adrian

 

[claude.simon@equipement.g]

On 1 mar, 12:22, "Dr. Adrian Wrigley"
<a...@linuxchip.demon.co.uk.uk.uk> wrote:

On Wed, 28 Feb 2007 17:20:37 +0000, Colin Paul Gloster wrote:

...

Dr. Adrian Wrigley wrote:

" Something like this
might allow a "rebranding" of Ada (i.e. a new name, with full buzzword
compliance), and would be ideal to address the "new" paradigm of
multicore/multithreaded processor software, using the lightweight
threading and parallelism absent from Ada as we know it. For those who
know Occam, something like the 'PAR' and "SEQ" constructs are missing in
Ada."

I really fail to see the relevance of multiple processors to
lightweight threading.

????

If you don't have multiple processors, lightweight threading is
less attractive than if you do? Inmos/Occam/Transputer was founded
on the basis that lightweight threading was highly relevant to multiple
processors.

Ada has no means of saying "Do these bits concurrently, if you like,
because I don't care what the order of execution is". And a compiler
can't work it out from the source. If your CPU has loads of threads,
compiling code with "PAR" style language concurrency is rather useful
and easy.
--
Adrian

If my memory is ok Jean Pierre Rosen had a proposal :

for I in all 1 .. n loop
....
end loop;

 

[Georg Bauhaus]

On Thu, 2007-03-01 at 10:18 +0100, Jean-Pierre Rosen wrote:

Colin Paul Gloster a ĂŠcrit :
procedure Ada_Is_As_Unsafe_As_VHDL_And_GNAT_Will_Not_Even_Warn is
value,Y:Integer;
begin
if False then
Value:=0;
end if;
Y:=Value;
end Ada_Is_As_Unsafe_As_VHDL_And_GNAT_Will_Not_Even_Warn;
--GNAT is an abbreviation of "the GNU Ada Translator".

I do not know Modula-3 and Oberon. Do they allow such a trivially
detectable accident?

In fact, Ada compilers do detect this:
Ada_Is_As_Unsafe_As_VHDL_And_GNAT_Will_Not_Even_Warn.ada:7: warning:
‘Value’ is used uninitialized in this function

You'd have to study the compiler docs, though. The warning is from the
backend and needs some switches to be turned on.

Here is what AdaControl says about it:
Error: IMPROPER_INITIALIZATION: use of uninitialized variable: Value
Error: IMPROPER_INITIALIZATION: variable "value" used before
initialisation

 

[Georg Bauhaus]

On Thu, 2007-03-01 at 10:18 +0100, Jean-Pierre Rosen wrote:

Colin Paul Gloster a ĂŠcrit :
procedure Ada_Is_As_Unsafe_As_VHDL_And_GNAT_Will_Not_Even_Warn is
value,Y:Integer;
begin
if False then
Value:=0;
end if;
Y:=Value;
end Ada_Is_As_Unsafe_As_VHDL_And_GNAT_Will_Not_Even_Warn;
--GNAT is an abbreviation of "the GNU Ada Translator".

I do not know Modula-3 and Oberon. Do they allow such a trivially
detectable accident?

In fact, Ada compilers do detect this:
Ada_Is_As_Unsafe_As_VHDL_And_GNAT_Will_Not_Even_Warn.ada:7: warning:
‘Value’ is used uninitialized in this function

You'd have to study the compiler docs, though. The warning is from the
backend and needs some switches to be turned on.

Here is what AdaControl says about it:
Error: IMPROPER_INITIALIZATION: use of uninitialized variable: Value
Error: IMPROPER_INITIALIZATION: variable "value" used before
initialisation

 

[Martin Thompson]

Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> writes:

I post from news:comp.lang.ada to news:comp.lang.vhdl .

I'll leap in then

Stephen A. Leake wrote in news:news:u649rx29a.fsf@stephe-leake.org on
news:comp.lang.ada for the benefit of Mike Silva:

"[..]

[..] FPGA development relies heavily on simulation,
which does not require real hardware."


A warning to Mike Silva: supposed simulators for languages chiefly
used for FPGAs often behave differently to how source code will
actually behave when synthesized (implemented) on a field programmable
gate array. This is true of cheap and expensive tools promoted as
simulators.

What do you mean by this? The VHDL I simulate behaves the same as the
FPGA, unless I do something bad like doing asynchronous design, or
miss a timing constraint. These are both design problems, not
simulation or language problems.

<snip>

" multi-dimensional
arrays) gave a feeling of clarity and integrity absent from software
development languages."


Apparently for many years, VHDL subset tools (the only kind of VHDL
tools which exist, so even if the language was excellent one would
need to restrict one's code to what was supported) used to not support
multi-dimensional arrays.

What's this about "only VHDL subset" tools existing? Modelsim supports
all of VHDL... It is true that synthesis tools only support a subset of
VHDL, but a lot of that is down to the fact that turning (say) an
access type into hardware is a bit tricky.

Multi dimensional arrays have worked (even in synthesis) for years in
my experience.

<snip>

(Followup-to trimmed to comp.ang.vhdl)

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

 

[Dmitry A. Kazakov]

On Thu, 01 Mar 2007 11:22:32 GMT, Dr. Adrian Wrigley wrote:

If you don't have multiple processors, lightweight threading is
less attractive than if you do? Inmos/Occam/Transputer was founded
on the basis that lightweight threading was highly relevant to multiple
processors.

Ada has no means of saying "Do these bits concurrently, if you like,
because I don't care what the order of execution is". And a compiler
can't work it out from the source. If your CPU has loads of threads,
compiling code with "PAR" style language concurrency is rather useful
and easy.

But par is quite low-level. What would be the semantics of:

declare
Thing : X;
begin
par
Foo Thing);
and
Bar Thing);
and
Baz Thing);
end par;
end;

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

 

[Colin Paul Gloster]

In news:1172754472.5352.11.camel@localhost.localdomain timestamped
Thu, 01 Mar 2007 14:07:52 +0100, Georg Bauhaus <bauhaus@futureapps.de>
posted:
"On Thu, 2007-03-01 at 10:18 +0100, Jean-Pierre Rosen wrote:

Colin Paul Gloster a =C3=A9crit :
procedure Ada_Is_As_Unsafe_As_VHDL_And_GNAT_Will_Not_Even_Warn is
value,Y:Integer;
begin
if False then
Value:=3D0;
end if;
Y:=3DValue;
end Ada_Is_As_Unsafe_As_VHDL_And_GNAT_Will_Not_Even_Warn;
--GNAT is an abbreviation of "the GNU Ada Translator".
[..]

In fact, Ada compilers do detect this:
Ada_Is_As_Unsafe_As_VHDL_And_GNAT_Will_Not_Even_Warn.ada:7: warning:
=E2=80=98Value=E2=80=99 is used uninitialized in this function

You'd have to study the compiler docs, though. The warning is from the
backend and needs some switches to be turned on.

[..]"


I admit that I was completely unaware of this. I tried all of these
switches of GNAT's together on that example without getting an
appropiate warning for the problem: -gnatf ("Full errors. Verbose
details, all undefined references" according to gnatmake if invoked
with no arguments) -gnatv ("Verbose mode. Full error output with
source lines to stdout"); -gnatVa ("turn on all validity checking
options"); -gnatwh ("turn on warnings for hiding variable"); and
-gnatwa ("turn on all optional warnings (except d,h,l)", thereby not
enabling warnings for "turn on warnings for implicit dereference" and
"turn on warnings for missing elaboration pragma").

 

[Colin Paul Gloster]

In news:ups7txflv.fsf@trw.com timestamped Thu, 01 Mar 2007 13:23:08
+0000, Martin Thompson <martin.j.thompson@trw.com> posted:
"Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> writes:

I post from news:comp.lang.ada to news:comp.lang.vhdl .

I'll leap in then "

Welcome!


"> Stephen A. Leake wrote in news:news:u649rx29a.fsf@stephe-leake.org on

news:comp.lang.ada for the benefit of Mike Silva:

"[..]

[..] FPGA development relies heavily on simulation,
which does not require real hardware."


A warning to Mike Silva: supposed simulators for languages chiefly
used for FPGAs often behave differently to how source code will
actually behave when synthesized (implemented) on a field programmable
gate array. This is true of cheap and expensive tools promoted as
simulators.

What do you mean by this? The VHDL I simulate behaves the same as the
FPGA, unless I do something bad like doing asynchronous design, or
miss a timing constraint."

Or if you use the enumeration encoding attribute and it is not supported
by both the simulation tool and the synthesis tool; or if you use a
simulation tool which honors the semantics of mode BUFFER but use a
synthesis tool which simply and incorrectly replaces BUFFER with OUT
even if you are supposedly using an earlier version of VHDL in which
BUFFER and OUT are not very similar; a global name might not be
reevaluated if the global value changes even if a function depends on
it (hey, I am not saying it is a good idea, but Synopsys does mention
it as an example of something which can cause a simulation mismatch);
'Z' not being treated as high impedance by a synthesis tool; default
values being ignored for synthesis; TRANSPORT and AFTER being ignored
for synthesis (that TRANSPORT is not amenable to being implemented by
technologies typically targetted by HDLs is not a valid excuse: in
such cases, a tool should report that it is unsupported instead of
ignoring it); sensitivity lists being ignored for synthesis; or other
discrepancies.

" These are both design problems, not
simulation or language problems."

It is true that asynchronous designs or missed timing constraints may
be design problems, but I would prefer that if the synthesized
behavior is bad, that the simulation (which is supposed to indicate
what will happen in reality) would not run well, or that the
simulation would be bad in the same way that the synthesized behavior
is. This may be too much to expect for timing constraints, but I -- perhaps
naively -- do not see why an asynchronous design should be so dismissable.
How hard could it be to replace tools' warnings that a referenced signal
needs to be added to a sensitivity list with a rule in the language standard
which makes the omission from the sensitivity list illegal?

"<snip>

" multi-dimensional
arrays) gave a feeling of clarity and integrity absent from software
development languages."


Apparently for many years, VHDL subset tools (the only kind of VHDL
tools which exist, so even if the language was excellent one would
need to restrict one's code to what was supported) used to not support
multi-dimensional arrays.

What's this about "only VHDL subset" tools existing? Modelsim supports
all of VHDL..."

You may rightly deem that claim of mine to be unwarranted, but outside
of testbenches, I do not see what use the language is if it is not
transferrable to actual hardware.

" It is true that synthesis tools only support a subset of
VHDL, but a lot of that is down to the fact that turning (say) an
access type into hardware is a bit tricky."

That is true, and even if not tricky, it may be pointless. However, I
think that people have become accustomed to this as an excuse even
when it is not valid, e.g. from Synopsys's documentation:
"[..]
Array ranges and indexes other than integers are unsupported.
[..]"

Martin J. Thompson wrote:

"Multi dimensional arrays have worked (even in synthesis) for years in
my experience.

[..]"

Not always, and not with all tools. E.g. last month, someone
mentioned in
news:548d3iF1vbcf6U1@mid.individual.net
: "Using 2D-Arrays as I/O signals _may_ be a problem for some synthesis
tools. [..]"

I admit my next example is historical, but Table 7.1-1 Supported and
Unsupported Synthesis Constructs of Ben Cohen's second (1998) edition of
"VHDL Answers to Frequently Asked Questions" contains:
"[..]
[..] multidimensional arrays are not allowed
[..]"

Cheers,
C. P. G.

 

[Colin Paul Gloster]

In newsan.2007.03.01.11.23.01.229462@linuxchip.demon.co.uk.uk.uk
timestamped Thu, 01 Mar 2007 11:22:32 GMT, "Dr. Adrian Wrigley"
<amtw@linuxchip.demon.co.uk.uk.uk> posted:
"On Wed, 28 Feb 2007 17:20:37 +0000, Colin Paul Gloster wrote:
....

Dr. Adrian Wrigley wrote:

" Something like this
might allow a "rebranding" of Ada (i.e. a new name, with full buzzword
compliance), and would be ideal to address the "new" paradigm of
multicore/multithreaded processor software, using the lightweight
threading and parallelism absent from Ada as we know it. For those who
know Occam, something like the 'PAR' and "SEQ" constructs are missing in
Ada."

I really fail to see the relevance of multiple processors to
lightweight threading.

????

If you don't have multiple processors, lightweight threading is
less attractive than if you do?"

I was thinking that heavyweight processes -- whatever that term might mean,
maybe involving many processes, each of which is working on processing
intensive work without threads' unrestricted access to shared memory --
would be suitable for multiple processors.

" Inmos/Occam/Transputer was founded
on the basis that lightweight threading was highly relevant to multiple
processors."

I reread a little of occam2 and transputers for this post. I do not
know much about them. I do not know.

"Ada has no means of saying "Do these bits concurrently, if you like,
because I don't care what the order of execution is"."

How do you interpret part 11 of Section 9: Tasks and Synchronization
of Ada 2005? (On
WWW.ADAIC.com/standards/05rm/html/RM-9.html#I3506
: "[..]

NOTES
11 1 Concurrent task execution may be implemented on multicomputers,
multiprocessors, or with interleaved execution on a single physical
processor. On the other hand, whenever an implementation can determine
that the required semantic effects can be achieved when parts of the
execution of a given task are performed by different physical
processors acting in parallel, it may choose to perform them in this way.

[..]")

Dr. Adrian Wrigley wrote:

" And a compiler
can't work it out from the source. If your CPU has loads of threads,
compiling code with "PAR" style language concurrency is rather useful
and easy.
--
Adrian"

Maybe I will read more about this some time.