Embedded languages based on early Ada (from "Re: Preferred OS, processor family for running embedded

[Colin Paul Gloster]

"Dmitry A. Kazakov" <[email protected]> posted on Fri, 2 Mar
2007 17:32:26 +0100 :
"[..]

I'm looking for something like Cilk, but even the concurrent loop
(JPR's for I in all 1 .. n loop?) would be a help.

Maybe, just a guess, the functional decomposition rather than statements
could be more appropriate here. The alternatives would access their
arguments by copy-in and resynchronize by copy-out."


From William J. Dally in 1999 on
HTTP://CVA.Stanford.edu/people/dally/ARVLSI99.ppt#299,37,Parallel Software: Design Strategy
:"[..]
- many for loops (over data,not time) can be forall
[..]"
Without reading that presentation thoroughly now, I remark that Dally
seemed to be supportive of Wrigley's finely grained parallelism.

 

[Colin Paul Gloster]

In timestamped Sat, 03 Mar 2007 16:59:52 GMT, "Dr. Adrian Wrigley"
<[email protected]> posted:
"[..]
On Sat, 03 Mar 2007 15:26:35 +0000, Jonathan Bromley wrote:

[..]

For the numerical-algorithms people, I suspect the problem of
inferring opportunities for parallelism is nearer to being solved
than some might imagine. There are tools around that
can convert DSP-type algorithms (such as the FFT that's
already been mentioned) into hardware that's inherently

Again, this is ages old now. But it can't convert
C-type programs reliably and efficiently.

parallel; there are behavioural synthesis tools that allow
you to explore the various possible parallel vs. serial
possibilities for scheduling a computation on heterogeneous
hardware. It's surely a small step from that to distributing
such a computation across multiple threads or CPUs. All
that's needed is the will.

[..]"


I am not aware of tools which automatically generate such parallel
implementations, though they may exist. For many algorithms a precise
implementation would be required, but for many numerical applications
in which absolute adherence is not required, are such tools so
impressive that they will replace Jacobi's method with the
Gauss-Seidel method (or something even better) without guidance?

 

[Dr. Adrian Wrigley]

"Dmitry A. Kazakov" <[email protected]> posted on Fri, 2 Mar
2007 17:32:26 +0100 :
"[..]

I'm looking for something like Cilk, but even the concurrent loop
(JPR's for I in all 1 .. n loop?) would be a help.

Maybe, just a guess, the functional decomposition rather than statements
could be more appropriate here. The alternatives would access their
arguments by copy-in and resynchronize by copy-out."

From William J. Dally in 1999 on
HTTP://CVA.Stanford.edu/people/dally/ARVLSI99.ppt#299,37,Parallel Software: Design Strategy
:"[..]
- many for loops (over data,not time) can be forall
[..]"
Without reading that presentation thoroughly now, I remark that Dally
seemed to be supportive of Wrigley's finely grained parallelism.

I hadn't seen that presentation, but a number of other key points
are made by Dally:
-------------------------------------
# Writing parallel software is easy
* with good mechanisms

# Almost all demanding problems have ample parallelism

# Need to focus on fundamental problems
* extracting parallelism
* load balance
* locality
o load balance and locality can be covered by excess parallelism

Conclusion: We are on the threshold of the explicitly parallel era
* Diminishing returns from sequential processors (ILP)
o no alternative to explicit parallelism
* Enabling technologies have been proven
o interconnection networks, mechanisms, cache coherence
* Fine-grain machines are more efficient than sequential machines

# Fine-grain machines will be constructed from multi-processor/DRAM chips
# Incremental migration to parallel software

 

[Martin Thompson]

Hello again,

Hi!

It seems prudent to highlight that my advice regarding discrepancies
between VHDL simulations and synthesized VHDL was intended for someone
(named Mike Silva) who I suspected would not have been aware of how
common this is, who said in
(which is a different subthread on comp.lang.ada and so does not
appear in References fields on comp.lang.vhdl):

"[..]

Well, I did pick up a VHDL book a while back. Maybe it's a sign.
But first I want to get Ada running on a SBC."

Sorry if this caused confusion. Having said that, I would prefer
simulations to reflect reality (but I appreciate that less accuracy
for higher speed can be acceptable if you know what you are
sacrificing and what you are doing).

Yes, you always have to simulate at an appropriate level of
abstraction (otherwise we'd be doing the whole hting in Spice

In timestamped Fri, 02 Mar 2007 15:55:46
+0000, Martin Thompson <[email protected]> posted:


Well, attributes are all a bit tool specific, I'm not sure this is
important. The sim and the synth will *behave* the same, but the
numbers used to represent states might not be what you expect. Or am
I misunderstanding what you are getting at?"



You seem to have understood it but to not be aware of what I have read
on the matter, which may be just scaremongering, I have never actually
checked whether a simulation tool and a synthesis tool differ on this.

<snip>
OK, so that tool allows you to use attributes to do things that
violate the rules of VHDL.

The interpretation of the ENUM_ENCODING attribute is specific to
Presto VHDL. Other VHDL tools, such as simulators, use the
standard encoding (ordering).

"We changed the way VHDL works". No wonder you get mismatches.

"[..]

'Z' not being treated as high impedance by a synthesis tool;

It will be if the thing you are targetting has tristates. Either as
IOBs or internally."


Maybe Synplify does. Synopsys's pvhdl_5.pdf warns instead:
"5
Inferring Three-State Logic 5
Presto VHDL infers a three-state buffer when you assign the value of
Z to a signal or variable. The Z value represents the high-impedance
state. Presto VHDL infers one three-state buffer per process. You
can assign high-impedance values to single-bit or bused signals (or
variables). [..]

[..]

You cannot use the z value in an expression, except for
concatenation and comparison with z, such as in
if (IN_VAL = .Z.) then y<=0 endif;
This is an example of permissible use of the z value in an
expression, but it always evaluates to false. So it is also a
simulation/
synthesis mismatch.

OK, no synthesis tool will allow a comparison with "Z" as it's not a
real physical value that you can "measure" with a gate.

[..]

Be careful when using expressions that compare with the z value.
Design Compiler always evaluates these expressions to false, and
the pre-synthesis and post-synthesis simulation results might differ.
For this reason, Presto VHDL issues a warning when it synthesizes
such comparisons."

That's fair enough. Real life getting in the way again! At least you
get warned.

In timestamped Fri, 02 Mar 2007 15:55:46

values being ignored for synthesis;

Works in my tools."


In case someone tries to coerce you into using Synopsys: from
pvhdl_c.pdf :

"[..]

subprogram
Default values for parameters are unsupported. [..]

[..]"

I shan't be using that tool then (not for architectures which do
support inititalisation anyway). For ASICs it makes sense, as they
*don't* know how to initialise.

Again, I expect my synth tool to allow me to do things that my chip
can do and warn me (or error!) if I try and do impossible stuff.

"[I am not an async expert but...] You can do async design in VHDL and
with synthesis, but proving correctness by simulation does not work
out as I understand it."


I do not have a clue.

Fair enough

"[..]

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.

Now I've reread that, I don't know what you are saying. The language
has two uses:
1) Testbenches
2) Defining real devices

are you saying the langauge is not useful if it can't *all* be used
for 2)?

It is possible to write testbenches for VHDL in a language other than
VHDL. I do not argue whether testbenches in VHDL or another language
are better.

Nor do I.

It is possible to synthesize code in a language other than
a dedicated hardware description language, and we interpret which of
synthesizable and unsynthesizable code are a side effect of
practicalities of reality. I am not trying to convince you on this
point, we simply think about it differently.

OK.



"I wish VHDL had *more* non synthesisable features
(like dynamic array sizing for example)."


I am aware of an initiative to add a feature, which may or may not be
synthesizable, to VHDL to aid verification, but I do not believe I had
heard a desire for VHDL to have "*more* non synthesisable features"
before .

I think lots of people would like more support for funkier testbenches!

" I'd like to write my
testbenches in Python "

So why don't you?
HTTP://MyHDL.JanDecaluwe.com/doku.php

Then I'd have to write my FPGA code in Python as well. Which I would
also like to do, but integrating it with other IP is tricky at the
moment. It also only produces Verilog output (although VHDl is on the
way) which would mean a mixed-language license for me :-(

I have done some stuff in MyHDL, and I intend to do more (when I get a
PC upgrade at home... 300MHz Celeron's are not ideal for FPGA
development - even small ones!)

"[..]

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
: "Using 2D-Arrays as I/O signals _may_ be a problem for some synthesis
tools. [..]"

Well, that's a bit weak ("*may* be a problem") - what tools do they
currently not work in?"


Ask the author of (Ralf
Hildebrandt). I am not personally aware of any.

OK, so it's not strong support for the fact that multidimensional
arrays don't work anywhere...

Martin J. Thompson wrote:

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

Yes, in the past it has been a problem. [..]"


By coincidence I was checking something else in the book Luca Fanucci,
"Digital Sistems Design Using VHDL", SEU, 2002 last week and it was
mentioned therein that multidimensional arrays are not
synthesizable. I do not know whether or not they actually were
supported for synthesis at that time.

Still 5 years old! A long time in EDA terms...

Cheers,
Martin

 

[Martin Thompson]

I am unhappy that electronic engineers are very eager to try
to transfer things which are unsuitable for software to hardware for
which they are also unsuitable, e.g. C++ and UML.

That sounds like one for the .sig file!

Cheers,
Martin

 

[KJ]

: "Using 2D-Arrays as I/O signals _may_ be a problem for some synthesis
tools. [..]"

Well, that's a bit weak ("*may* be a problem") - what tools do they
currently not work in?"


Ask the author of (Ralf
Hildebrandt). I am not personally aware of any.

OK, so it's not strong support for the fact that multidimensional
arrays don't work anywhere...

2-D arrays work just fine in Quartus, haven't had the need to try higher
dimensions yet...for what it's worth.

Kevin Jennings

 

[Colin Paul Gloster]

In timestamped Tue, 06 Mar 2007 16:19:12
+0000, Martin Thompson <[email protected]> posted:

"[..]

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.

Now I've reread that, I don't know what you are saying. The language
has two uses:
1) Testbenches
2) Defining real devices

are you saying the langauge is not useful if it can't *all* be used
for 2)?"


I really did say 2), but that would be as a hardware language. Writing
testbenches is not useless, and writing testbenches in a (part of a) language
which can not define real devices does not make that (part of a)
language useless for testbenches, but it does make that (part of a)
language useless for defining real devices which is what I expect to
be able to do with a hardware description language.


"[..]

"I wish VHDL had *more* non synthesisable features
(like dynamic array sizing for example)."


I am aware of an initiative to add a feature, which may or may not be
synthesizable, to VHDL to aid verification, but I do not believe I had
heard a desire for VHDL to have "*more* non synthesisable features"
before .

I think lots of people would like more support for funkier testbenches!

[..]"


In which case the goal to have "funkier testbenches", but you do not
need to go out of your way to make these unsynthesisable. They may be
unsynthesisable, but that would just be a side effect and not the
goal. Of course, as you do not want to synthesize such features, you
will not waste effort trying to make them synthesisable, but that is
not the same thing as deliberately obstructing any chance to
synthesize them.



"OK, so it's not strong support for the fact that multidimensional
arrays don't work anywhere...

[..]"

Apparently they work with many tools. Most tools are not necessarily
all tools, though it is true that we do not have a definite claim that
even one tool still in use does not support them, merely a hint.

Cheers,
Colin Paul

 

[Martin Thompson]

In timestamped Tue, 06 Mar 2007 16:19:12
+0000, Martin Thompson <[email protected]> posted:

"[..]

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.

Now I've reread that, I don't know what you are saying. The language
has two uses:
1) Testbenches
2) Defining real devices

are you saying the langauge is not useful if it can't *all* be used
for 2)?"


I really did say 2), but that would be as a hardware language. Writing
testbenches is not useless, and writing testbenches in a (part of a) language
which can not define real devices does not make that (part of a)
language useless for testbenches, but it does make that (part of a)
language useless for defining real devices which is what I expect to
be able to do with a hardware description language.

So you'd rather use a different language for testbenches? Or throw
away the non-synth bits.

<aside>Historically, VHDL was for *describing* hardware, and only
intended for synthesis. People then made synthesisers later. So it's

"[..]

"I wish VHDL had *more* non synthesisable features
(like dynamic array sizing for example)."


I am aware of an initiative to add a feature, which may or may not be
synthesizable, to VHDL to aid verification, but I do not believe I had
heard a desire for VHDL to have "*more* non synthesisable features"
before .

I think lots of people would like more support for funkier testbenches!

[..]"


In which case the goal to have "funkier testbenches", but you do not
need to go out of your way to make these unsynthesisable. They may be
unsynthesisable, but that would just be a side effect and not the
goal.

Is that not the case with current features? No-one is going out of
their way to make them unsynthesisable. I think we just differ on our
point of view here - you would like all of an HDL to be synthesisable,
I'd *like* that, but I'll happily use a subset for synth and more of
it for sims.

Of course, as you do not want to synthesize such features, you
will not waste effort trying to make them synthesisable, but that is
not the same thing as deliberately obstructing any chance to
synthesize them.

Again, no-one is going out of their way.

"OK, so it's not strong support for the fact that multidimensional
arrays don't work anywhere...

[..]"

Apparently they work with many tools. Most tools are not necessarily
all tools, though it is true that we do not have a definite claim that
even one tool still in use does not support them, merely a hint.

Fine, we'll leave it at that then

Cheers,
Martin

 

[Colin Paul Gloster]

In timestamped Tue, 06 Mar 2007 16:20:27
+0000, Martin Thompson <[email protected]> posted:

I am unhappy that electronic engineers are very eager to try
to transfer things which are unsuitable for software to hardware for
which they are also unsuitable, e.g. C++ and UML.

That sounds like one for the .sig file!"


Thank you, I aim to please!

Prof. Giovanni De Micheli said on April 2nd, 2007 while lecturing: "I
invented HardwareC a few years ago" and after he presented two slides
after that clause he said: "Java is a great language, I like it. It's
cleaner than C/C++, but that's life." He said that C has an advantage
over VHDL because code might initially be targeted to a processor but
be migrated to hardware elsewhere in the system if the attempt on the
processor does not perform well enough.

In contrast to what is quoted above which he used his voice to say, he
showed in writing more than one slide of his promoting the SystemC(R)
approach as being good. E.g. "Processes run concurrently". I asked
whether he had tried to convey that SystemC(R) code genuinely,
literally runs concurrently. He answered that he did mean that
literally, but he admitted that in practice SystemC(R) implementations
do not run concurrently. He clarified that he was convinced that the
SystemC(R) standard was written in terms of concurrency. During a
lunch break I challenged this again (this time by email: see below): I
did not receive a response from him yet but an organizer of the
lecture sent the response below.

Regards,
Colin Paul Gloster


"Dear Colin Paul,

please try to address questions to Prof. De Micheli personally just
after the
lecture or during the break. This will avoid any form of
misunderstanding
without bothering Prof. De Micheli via email. Could you imagine if all
the
students would start sending questions to Prof. De Micheli via email
?

The presence of Prof. De Micheli is a great opportunity for all the
students
attending the course so please try to avoid asking too many questions
during the lecture in order for Professor De Micheli to have the
possibility to
address all the topics he originally planned for the course.

Thanks a lot for your understanding.

Best Regards, [..]


----- Original Message ----- From: "Colin Paul Gloster"
<[email protected]>
To: <giovanni.demicheli[..]>
Cc: [.. some of the students who had been exposed to propaganda by the
lecturer, and also a carbon copy to the organizer]
Sent: Monday, April 02, 2007 2:05 PM
Subject: SystemC(R) concurrency, or lack thereof

Dear Professor Giovanni De Micheli,

You said on a number of occassions during one of the lectures today that
SystemC(R) multiprogramming is concurrent. I asked you whether you meant that
literally, to which you replied that you did literally mean that but that
implementations might use interleaved serial code instead of parallel code but
that you believed that the SystemC(R) definition is concurrent.

I completely reject your claim that the SystemC(R) library is defined to be
concurrent. Please explain to me how I have misinterpreted the definition of
the scheduling policy of the SystemC(R) standard's as described in 4.2.1 The
scheduling algorithm of the standard:
"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."

Thanks,
Colin Paul Gloster

P.S. Other parts of the lecture were interesting."