C
Colin Paul Gloster
Ladies (if any actually read comp.lang.vhdl
or comp.arch.fpga) and gentlemen,
You may have been wondering why I have not
been posting much to Usenet and SystemC.org
since September 2007.
In January 2006 I became a Ph.D. student in
the largest University of Pisa but I quit
in September 2007 (details follow). I have
unsuccessfully tried to apply for a number
of Ph.D. scholarships and jobs to replace my
sabotaged attempt at a Ph.D. in Pisa, and I
do not have much money remaining so now I
announce my woe here in the hope that one
of you might help me.
I had the misfortune to unintentionally but
quite clearly empirically disprove a published
theory of my main tutor's. I was discouraged to
submit a paper for publication which would highlight
points similar to those below, and I was too afraid to
continue with writing the paper in my spare time
before I quit lest that could still be used as a
sufficient excuse to expell me. I was also warned
that if I would not quit, then my empty refereed
publication record would be used as a reason to
fail me in the second annual review. I quit in
September 2007.
In addition to the problems below,
Prof. Luca Fanucci forbade me from pointing out
in my presentations that high-level SystemC(R)
modeling did not prove to be competitive with
Verilog.
Please feel free to discuss these points on
Usenet for yourselves, but if you have
anything to say to me (hopefully an offer,
but even advice would be welcome) please
reply to me directly by writing to
Colin Paul Gloster,
Via Tosco Romagnola 2461,
Titignano,
56023 Cascina (PI),
Italy
or by emailing to (e-mail address removed)
but please bear in mind that my Internet
access is currently chiefly restricted to
approximately three gratis hours in a local
library.
Yours faithfully,
Colin Paul Gloster
Table of Contents
Introduction to C++ Issues in Pisa
An example of where similar, unrelated objects should be refactored into a single
hierarchy on Sourceforge
Lack of effective inheritance on Sourceforge
Unnecessary case branches on Sourceforge
A number of bad practices on Sourceforge
Miscellaneous C++ Issues in Pisa
VHDL Issues in Pisa
Bibliography
Introduction to C++ Issues in Pisa
A non disclosure agreement between myself; my former tutor, Prof. Luca Fanucci,
and his partner, STMicroelectronics, prevents me from mentioning a number of items
for a number of years. Fortunately, I am legally at liberty to highlight many
problems which I detected in published source code which was written by
STMicroelectronics and is available for gratis on the Internet. My project in Pisa
involved using this source code. I had offered to help with that source code, but
despite the large list of flaws which I uncovered, my offer was ignored. It is
trivial to check my list (below) in which I give exact file names and line
numbers. I was not permitted to write a paper concerning these issues. What I
accidentally uncovered irrefutably contradicted published papers by my tutor of
the time (the [Fanucci] entry in the bibliography) and published papers by his
partner, STMicroelectronics (the [OCCN2] entry in the bibliography). This tragic
incident is another case highlighting that the IEEE allows untrue papers. It is
not a sin to not be the best programmer in the World, but they incorrectly claimed
in papers that they are highly competent at writing source code in C++.
An example of where similar, unrelated objects should be refactored into a single
hierarchy on Sourceforge
The reader may wish to download the file occn_lib_2.0.1.beta.tar.gz from
https://sourceforge.net/project/showfiles.php?group_id=74058
and to consult the files occn_lib_2.0.1.beta/include/utils/CQueueObject.n and
occn_lib_2.0.1.beta/include/utils/CQueuePtrObjectEv.n therein for what is
discussed here.
A constructor for a derived class (which e.g. CQueuePtrObjectEv could become in a
new version) must call a constructor for the base class (which e.g. CQueueObject
could become in a new version). Three of the four lines from a constructor of
CQueueObject are lexically copied in a constructor of CQueuePtrObjectEv, and the
counterpart to the remaining line from CQueueObject differs by simply having an
array of type T* instead of of type T (but as templates are used everywhere, a
pointer to a type is actually a type so perhaps CQueuePtrObjectEv should be
replaced by a future class which we could call "CQueueObjectEv" or even better
"CQueueEv"). Somewhat similarly, the bodies of the destructors are lexically
identical; the remove() methods contain identical semantics but differing
quantities of braces, but even worse they return an element without expelling it
from the agenda; the method add() of CQueuePtrObjectEv performs identical,
lexically copied steps as in the method add() of CQueueObject and after those
steps has some additional steps which would be more maintainably added as in "When
a base-class member function is overridden in a derived class, it is common to
have the derived-class version call the base-class version and do some additional
work" as written in a C++ book (the entry [Deitel and Deitel] in the
bibliography); the get_length() methods are lexically identical and each of them
contains two off by one errors; the methods is_not_empty() are lexically
identical; and the methods is_not_full() are lexically identical.
diff include/utils/CQueueObject.n include/utils/CQueuePtrObjectEv.n
32,33c32,33
< // File: CQueueObject.n
< // Created: Fri Jun 14 09:36:43 2002
---
< data (new (T) [size]) ,
---
< tail(0)
< {}
---
< {
73c77
< }
---75c79,85
< data[tail]=item;
---
< {
90d98
< }
97c105,106
< N_uint tmp_head=head+1;
< if (tmp_head==size)
< {
< tmp_head=0;
< }
< return data[tmp_head];
---
< return (tail!=head);
---
< const N_uint tmp= tail+1;
< return (tmp==size) ? (0!=head) : (tmp!=head);
<
---
Lack of effective inheritance on Sourceforge
In occn_lib_2.0.1.beta/include/channels/BusBaseChannel.n from STMicroelectronics,
both MasterIf<class,class> and SlaveIf<class,class> are subclasses of
Msgbox<class,class> and their respective set_index() methods are almost identical
but were clearly implemented using lexical copying. This is in contrast to the
claim in [OCCN1]: "The On-Chip Communication Network (OCCN) proposes an efficient,
open-source research and development framework for the specification, modeling and
simulation of on-chip communication architectures. OCCN increases the productivity
of developing new models for on-chip communication architectures through the
definition of a universal Application Programming Interface (API) and an object-
oriented C++ library built on top of SystemC. [..]
This environment provides several important on-chip network modeling features.
* Object-oriented design concepts, fully exploiting advantages of this software
development paradigm.
[..]" The following claim in [OCCN2] is similarly nonsensical: "OCCN focuses on
NoC modeling by providing a flexible, state-of-the-art, C++-based framework
consisting of an open-source, GNU GPL library, built on top of SystemC. OCCN
design methodology offers unique features, such as
* object-oriented design concepts," and is reminiscent of a comparison in Embedded
Systems Conference, 1990 to teenage sex and object oriented programming similar to
"The state of the art of Software Architecture is like teenage sex: it's on every-
body's mind all the time, everyone talks about it all the time (but they don't
really know what they are talking about), everyone thinks everyone else is doing
it, the few that are doing it: 1) are doing it poorly, 2) think it will be better
next time, and 3) are not practising it safely" reproduced in e.g. [Crocker].
Conceited delusions of grandeur such as those expressed in [OCCN1,OCCN2] might be
attributed to electronic engineers having a basis for arrogance more than a decade
behind realtime embedded programmers' and justifiably not knowing enough about
software development, but one of the coauthors of [OCCN1] and [OCCN2] owns a
company which allegedly[ISD1]: "Integrated Systems Development S.A. (ISD) is a
company established in 1998, active in the domain of Integrated Systems
(IS) of Guaranteed Quality and Performance. It is an R&D organization [..]"
and allegedly[ISD2}:"The ISD software group is dedicated to efficient and retance_id < 1000000)
168 sprintf(tmp_str, "f%u_favg_", instance_id);
169 else if (instance_id >= 1000000) {
170 fprintf(stderr, "way too many filenames \n");
171 OCCN_error_exit("error in stats");
172 }
173 strcat(string_gen_tbl[BaseStat::F_FREQ_STAT_AVG], tmp_str);
174
175 ptr = string_gen_tbl[BaseStat::F_FREQ_STAT_AVG];
176 break;
177
178 case BaseStat::FREQ_STAT_CURR:
179 string_gen_tbl[BaseStat::F_FREQ_STAT_CURR] = new
char[max_string_size];
180 if (string_gen_tbl == NULL)
181 {
182 fprintf(stderr, "Statistics Error: new string_gen_tbl (in
BaseStat::activate_stats) failed: retry with smaller max_string_size\n");
183 OCCN_error_exit("error in stats");
184 }
185 strcpy(string_gen_tbl[BaseStat::F_FREQ_STAT_CURR],
"./stat/");
186 //strcpy(string_gen_tbl[BaseStat::F_FREQ_STAT_CURR]+7,
"fn_fcur_");
187 if (instance_id < 10)
188 sprintf(tmp_str, "f00000%u_fcur_", instance_id);
189 else if (instance_id < 100)
190 sprintf(tmp_str, "f0000%u_fcur_", instance_id);
191 else if (instance_id < 1000)
192 sprintf(tmp_str, "f000%u_fcur_", instance_id);
193 else if (instance_id < 10000)
194 sprintf(tmp_str, "f00%u_fcur_", instance_id);
195 else if (instance_id < 100000)
196 sprintf(tmp_str, "f0%u_fcur_", instance_id);
197 else if (instance_id < 1000000)
198 sprintf(tmp_str, "f%u_fcur_", instance_id);
199 else if (instance_id >= 1000000) {
200 fprintf(stderr, "way too many filenames \n");
201 OCCN_error_exit("error in stats");
202 }
203 strcat(string_gen_tbl[BaseStat::F_FREQ_STAT_CURR], tmp_str);
204
205 ptr = string_gen_tbl[BaseStat::F_FREQ_STAT_CURR];
206 break;
A number of bad practices on Sourceforge
From occn_lib_2.0.1.beta/include/interfaces/Pdu.n:
137 template <typename H, typename BU, int size>
138 int Pdu<H,BU,size>:
perator==(const Pdu<H,BU,size>& right) const
139 // {{{
140
141 {
142 e_last_addr<slave_first_addr)
143 {
144 OCCN_error_exit("Address ranges isn't correct (end address <
start address");
145 }
146 return true;
147 }
148
149 // }}}
In occn_lib_2.0.1.beta.tar.gz from
HTTPS://SourceForge.net/project/showfiles.php?group_id=74058, in the file
include/interfaces/Port.n, the following is inexcusable:
template<class WPdu, class RPdu>
RPdu* SlavePort<WPdu,RPdu>::receive(sc_time& time_out, bool& received)
// {{{
{
if ( (*this)->wait_read_authorization(time_out)==1 )
{
received = true;
}
else
{
received = false;
(*this)->cancel_receiving();
}
return (RPdu*)((*this)->get_read_pdu_ptr());
// maybe not valid but need to send back something !
}
// }}}
VHDL Issues in Pisa
I had applied to Pisa in September 2005 when I was living in Ireland, having just
returned from my Swedish internship in the Netherlands. I was in contact by
telephone and email with Prof. Luca Fanucci who was in Italy. At home, in a
different country from university, I had a subscription to the ACM Digital
Library, but instead Prof. Fanucci's publications tend to be on IEEEXplore for
which I did not have a subscription. He did email me a publication and I was able
to download an abstract of his from an old MAPLD conference. We established that
VHDL would be something I would want to be seriously involved in if I was to
secure a scholarship in Pisa. After I secured the scholarship and moved to Italy,
he mentioned C++ to me for the first time and he revealed his agenda against VHDL.
However, in time it became clear that he was very good at neither VHDL nor C++.
For example in his book of lecture notes entitled "Digital Sistems Design Using
VHDL" (he blamed the misspelling of Systems on the publisher) published by
Servizio Editoriale Universitario di Pisa,
Via Curtatone e Montanara 6,
56126 Pisa,
Italy,
telephone/fax +39 050 540120
dated May 2002, he went against best practice which was standardised in the 1990's
by using a clock edge synchronization coding style which is well-known by experts
to result in mismatches between simulation and synthesis. He did this on Slides
3.19; 4.12; 4.24 and 4.27. You can check with
http://groups.google.com
that I already knew how to do this in a less error-prone manner before I moved to
Italy. He has mistakes on Slides 2.14; 4.5; 4.16 and 4.20 (and also misspellings
on other slides).
I do not know everything concerning VHDL. I have entirely through my own fault
unintentionally overlooked things. I admit that. I am not perfect. One prominent
example is that though I had looked at the relevant part of the VHDL standards
concerning implicit initializations, I had not noticed this feature of VHDL so
when I discovered that one of our VHDL tools performs implicit initializations I
was very displeased with it and I deplored this feature to Prof. Luca Fanucci. He
ignored me, as usual, so I eventually proposed as part of the VHDL standardization
process to have implicit initializations illegal. Someone unaffiliated with the largest
University of Pisa explained the legality and rationale to me on the newsgroup
and I retracted my proposal. I felt like a fool and it became
clear that no one in the University of Pisa except for myself was interested
enough in VHDL (our most important language (we never even had a C++ compiler and
almost everyone else in the group in Pisa used only VHDL for the project)) to
monitor the standardization process and that no one in the University of Pisa was
an expert of VHDL and that no one in the University of Pisa cared enough about me
to support me. This inaction of Prof. Luca Fanucci's was extremely inappropiate.
Please see my proposal and its retraction on
https://bugzilla.mentor.com/show_bug.cgi?id=120
Luca Fanucci is fit to be a professor of none of VHDL; C++; C; and SystemC(R)
intellectual properties.
Also, when I was applying to Pisa, Luca Fanucci showed me a public webpage of
STMicroelectronics's concerning the project which he initially assigned me to.
After I arrived in Italy and saw the true algorithm, I learnt that the webpage was
misleading.
Bibliography
[Crocker] Will Tracz, Quote of the Day attributed to Ron Crocker, International
Conference on Software Engineering 1995 "Window On the World", Volume 1, Number 1
[Deitel and Deitel] Deitel and Deitel; "C++: How to Program", third edition,
Prentice Hall, 2001, Section 9.6 Overriding Base-Class Members in a Derived Class
and 9.9 Using Constructors and Destructors in Derived Classes
[Fanucci] Armaroli; Coppola; Diaz Nava; Fanucci, "High Level Modeling and
Simulation of a VDSL Modem in SystemC 2.0 - IPsim", "Proceedings of The 3rd IEEE
International Workshop on System-on-Chip for Real-Time Applications", 2003
[Grammatikakis] WWW.CS.TEICrete.Gr/english/showdetails.asp?id=12
[ISD1] WWW.ISD.Gr/index.htm#top11
[ISD2] WWW.ISD.Gr/index.htm#top23
[OCCN1] Grammatikakis, HTTP://OCCN.Sourceforge.net/coverpg.html, February 2005
[OCCN2] Marcello Coppola, Stephane Curaba, Miltos D. Grammatikakis, Giuseppe
Maruccia and Francesco Papariello, "OCCN: A Network-On-Chip Modeling and
Simulation Framework", Design for Automation and Test in Europe 2004 conference
[structured programming] Leonard H. Weiner, "The Roots of Structured Programming",
"ACM SIGCSE Bulletin", February 1978
or comp.arch.fpga) and gentlemen,
You may have been wondering why I have not
been posting much to Usenet and SystemC.org
since September 2007.
In January 2006 I became a Ph.D. student in
the largest University of Pisa but I quit
in September 2007 (details follow). I have
unsuccessfully tried to apply for a number
of Ph.D. scholarships and jobs to replace my
sabotaged attempt at a Ph.D. in Pisa, and I
do not have much money remaining so now I
announce my woe here in the hope that one
of you might help me.
I had the misfortune to unintentionally but
quite clearly empirically disprove a published
theory of my main tutor's. I was discouraged to
submit a paper for publication which would highlight
points similar to those below, and I was too afraid to
continue with writing the paper in my spare time
before I quit lest that could still be used as a
sufficient excuse to expell me. I was also warned
that if I would not quit, then my empty refereed
publication record would be used as a reason to
fail me in the second annual review. I quit in
September 2007.
In addition to the problems below,
Prof. Luca Fanucci forbade me from pointing out
in my presentations that high-level SystemC(R)
modeling did not prove to be competitive with
Verilog.
Please feel free to discuss these points on
Usenet for yourselves, but if you have
anything to say to me (hopefully an offer,
but even advice would be welcome) please
reply to me directly by writing to
Colin Paul Gloster,
Via Tosco Romagnola 2461,
Titignano,
56023 Cascina (PI),
Italy
or by emailing to (e-mail address removed)
but please bear in mind that my Internet
access is currently chiefly restricted to
approximately three gratis hours in a local
library.
Yours faithfully,
Colin Paul Gloster
Table of Contents
Introduction to C++ Issues in Pisa
An example of where similar, unrelated objects should be refactored into a single
hierarchy on Sourceforge
Lack of effective inheritance on Sourceforge
Unnecessary case branches on Sourceforge
A number of bad practices on Sourceforge
Miscellaneous C++ Issues in Pisa
VHDL Issues in Pisa
Bibliography
Introduction to C++ Issues in Pisa
A non disclosure agreement between myself; my former tutor, Prof. Luca Fanucci,
and his partner, STMicroelectronics, prevents me from mentioning a number of items
for a number of years. Fortunately, I am legally at liberty to highlight many
problems which I detected in published source code which was written by
STMicroelectronics and is available for gratis on the Internet. My project in Pisa
involved using this source code. I had offered to help with that source code, but
despite the large list of flaws which I uncovered, my offer was ignored. It is
trivial to check my list (below) in which I give exact file names and line
numbers. I was not permitted to write a paper concerning these issues. What I
accidentally uncovered irrefutably contradicted published papers by my tutor of
the time (the [Fanucci] entry in the bibliography) and published papers by his
partner, STMicroelectronics (the [OCCN2] entry in the bibliography). This tragic
incident is another case highlighting that the IEEE allows untrue papers. It is
not a sin to not be the best programmer in the World, but they incorrectly claimed
in papers that they are highly competent at writing source code in C++.
An example of where similar, unrelated objects should be refactored into a single
hierarchy on Sourceforge
The reader may wish to download the file occn_lib_2.0.1.beta.tar.gz from
https://sourceforge.net/project/showfiles.php?group_id=74058
and to consult the files occn_lib_2.0.1.beta/include/utils/CQueueObject.n and
occn_lib_2.0.1.beta/include/utils/CQueuePtrObjectEv.n therein for what is
discussed here.
A constructor for a derived class (which e.g. CQueuePtrObjectEv could become in a
new version) must call a constructor for the base class (which e.g. CQueueObject
could become in a new version). Three of the four lines from a constructor of
CQueueObject are lexically copied in a constructor of CQueuePtrObjectEv, and the
counterpart to the remaining line from CQueueObject differs by simply having an
array of type T* instead of of type T (but as templates are used everywhere, a
pointer to a type is actually a type so perhaps CQueuePtrObjectEv should be
replaced by a future class which we could call "CQueueObjectEv" or even better
"CQueueEv"). Somewhat similarly, the bodies of the destructors are lexically
identical; the remove() methods contain identical semantics but differing
quantities of braces, but even worse they return an element without expelling it
from the agenda; the method add() of CQueuePtrObjectEv performs identical,
lexically copied steps as in the method add() of CQueueObject and after those
steps has some additional steps which would be more maintainably added as in "When
a base-class member function is overridden in a derived class, it is common to
have the derived-class version call the base-class version and do some additional
work" as written in a C++ book (the entry [Deitel and Deitel] in the
bibliography); the get_length() methods are lexically identical and each of them
contains two off by one errors; the methods is_not_empty() are lexically
identical; and the methods is_not_full() are lexically identical.
diff include/utils/CQueueObject.n include/utils/CQueuePtrObjectEv.n
32,33c32,33
< // File: CQueueObject.n
< // Created: Fri Jun 14 09:36:43 2002
---
44c44
48c48
< data (new (T) [size]) ,
---
50,51c50,56
< tail(0)
< {}
---
56c61
66c71
71d75
< {
73c77
< }
---75c79,85
< data[tail]=item;
---
81c91
88d97
< {
90d98
< }
97c105,106
101,106c110
< N_uint tmp_head=head+1;
< if (tmp_head==size)
< {
< tmp_head=0;
< }
< return data[tmp_head];
---
113c117
117c121
124c128
128c132,134
< return (tail!=head);
---
135c141
139,141c145,156
< const N_uint tmp= tail+1;
< return (tmp==size) ? (0!=head) : (tmp!=head);
<
---
Lack of effective inheritance on Sourceforge
In occn_lib_2.0.1.beta/include/channels/BusBaseChannel.n from STMicroelectronics,
both MasterIf<class,class> and SlaveIf<class,class> are subclasses of
Msgbox<class,class> and their respective set_index() methods are almost identical
but were clearly implemented using lexical copying. This is in contrast to the
claim in [OCCN1]: "The On-Chip Communication Network (OCCN) proposes an efficient,
open-source research and development framework for the specification, modeling and
simulation of on-chip communication architectures. OCCN increases the productivity
of developing new models for on-chip communication architectures through the
definition of a universal Application Programming Interface (API) and an object-
oriented C++ library built on top of SystemC. [..]
This environment provides several important on-chip network modeling features.
* Object-oriented design concepts, fully exploiting advantages of this software
development paradigm.
[..]" The following claim in [OCCN2] is similarly nonsensical: "OCCN focuses on
NoC modeling by providing a flexible, state-of-the-art, C++-based framework
consisting of an open-source, GNU GPL library, built on top of SystemC. OCCN
design methodology offers unique features, such as
* object-oriented design concepts," and is reminiscent of a comparison in Embedded
Systems Conference, 1990 to teenage sex and object oriented programming similar to
"The state of the art of Software Architecture is like teenage sex: it's on every-
body's mind all the time, everyone talks about it all the time (but they don't
really know what they are talking about), everyone thinks everyone else is doing
it, the few that are doing it: 1) are doing it poorly, 2) think it will be better
next time, and 3) are not practising it safely" reproduced in e.g. [Crocker].
Conceited delusions of grandeur such as those expressed in [OCCN1,OCCN2] might be
attributed to electronic engineers having a basis for arrogance more than a decade
behind realtime embedded programmers' and justifiably not knowing enough about
software development, but one of the coauthors of [OCCN1] and [OCCN2] owns a
company which allegedly[ISD1]: "Integrated Systems Development S.A. (ISD) is a
company established in 1998, active in the domain of Integrated Systems
(IS) of Guaranteed Quality and Performance. It is an R&D organization [..]"
and allegedly[ISD2}:"The ISD software group is dedicated to efficient and retance_id < 1000000)
168 sprintf(tmp_str, "f%u_favg_", instance_id);
169 else if (instance_id >= 1000000) {
170 fprintf(stderr, "way too many filenames \n");
171 OCCN_error_exit("error in stats");
172 }
173 strcat(string_gen_tbl[BaseStat::F_FREQ_STAT_AVG], tmp_str);
174
175 ptr = string_gen_tbl[BaseStat::F_FREQ_STAT_AVG];
176 break;
177
178 case BaseStat::FREQ_STAT_CURR:
179 string_gen_tbl[BaseStat::F_FREQ_STAT_CURR] = new
char[max_string_size];
180 if (string_gen_tbl == NULL)
181 {
182 fprintf(stderr, "Statistics Error: new string_gen_tbl (in
BaseStat::activate_stats) failed: retry with smaller max_string_size\n");
183 OCCN_error_exit("error in stats");
184 }
185 strcpy(string_gen_tbl[BaseStat::F_FREQ_STAT_CURR],
"./stat/");
186 //strcpy(string_gen_tbl[BaseStat::F_FREQ_STAT_CURR]+7,
"fn_fcur_");
187 if (instance_id < 10)
188 sprintf(tmp_str, "f00000%u_fcur_", instance_id);
189 else if (instance_id < 100)
190 sprintf(tmp_str, "f0000%u_fcur_", instance_id);
191 else if (instance_id < 1000)
192 sprintf(tmp_str, "f000%u_fcur_", instance_id);
193 else if (instance_id < 10000)
194 sprintf(tmp_str, "f00%u_fcur_", instance_id);
195 else if (instance_id < 100000)
196 sprintf(tmp_str, "f0%u_fcur_", instance_id);
197 else if (instance_id < 1000000)
198 sprintf(tmp_str, "f%u_fcur_", instance_id);
199 else if (instance_id >= 1000000) {
200 fprintf(stderr, "way too many filenames \n");
201 OCCN_error_exit("error in stats");
202 }
203 strcat(string_gen_tbl[BaseStat::F_FREQ_STAT_CURR], tmp_str);
204
205 ptr = string_gen_tbl[BaseStat::F_FREQ_STAT_CURR];
206 break;
A number of bad practices on Sourceforge
From occn_lib_2.0.1.beta/include/interfaces/Pdu.n:
137 template <typename H, typename BU, int size>
138 int Pdu<H,BU,size>:
perator==(const Pdu<H,BU,size>& right) const139 // {{{
140
141 {
142 e_last_addr<slave_first_addr)
143 {
144 OCCN_error_exit("Address ranges isn't correct (end address <
start address");
145 }
146 return true;
147 }
148
149 // }}}
In occn_lib_2.0.1.beta.tar.gz from
HTTPS://SourceForge.net/project/showfiles.php?group_id=74058, in the file
include/interfaces/Port.n, the following is inexcusable:
template<class WPdu, class RPdu>
RPdu* SlavePort<WPdu,RPdu>::receive(sc_time& time_out, bool& received)
// {{{
{
if ( (*this)->wait_read_authorization(time_out)==1 )
{
received = true;
}
else
{
received = false;
(*this)->cancel_receiving();
}
return (RPdu*)((*this)->get_read_pdu_ptr());
// maybe not valid but need to send back something !
}
// }}}
VHDL Issues in Pisa
I had applied to Pisa in September 2005 when I was living in Ireland, having just
returned from my Swedish internship in the Netherlands. I was in contact by
telephone and email with Prof. Luca Fanucci who was in Italy. At home, in a
different country from university, I had a subscription to the ACM Digital
Library, but instead Prof. Fanucci's publications tend to be on IEEEXplore for
which I did not have a subscription. He did email me a publication and I was able
to download an abstract of his from an old MAPLD conference. We established that
VHDL would be something I would want to be seriously involved in if I was to
secure a scholarship in Pisa. After I secured the scholarship and moved to Italy,
he mentioned C++ to me for the first time and he revealed his agenda against VHDL.
However, in time it became clear that he was very good at neither VHDL nor C++.
For example in his book of lecture notes entitled "Digital Sistems Design Using
VHDL" (he blamed the misspelling of Systems on the publisher) published by
Servizio Editoriale Universitario di Pisa,
Via Curtatone e Montanara 6,
56126 Pisa,
Italy,
telephone/fax +39 050 540120
dated May 2002, he went against best practice which was standardised in the 1990's
by using a clock edge synchronization coding style which is well-known by experts
to result in mismatches between simulation and synthesis. He did this on Slides
3.19; 4.12; 4.24 and 4.27. You can check with
http://groups.google.com
that I already knew how to do this in a less error-prone manner before I moved to
Italy. He has mistakes on Slides 2.14; 4.5; 4.16 and 4.20 (and also misspellings
on other slides).
I do not know everything concerning VHDL. I have entirely through my own fault
unintentionally overlooked things. I admit that. I am not perfect. One prominent
example is that though I had looked at the relevant part of the VHDL standards
concerning implicit initializations, I had not noticed this feature of VHDL so
when I discovered that one of our VHDL tools performs implicit initializations I
was very displeased with it and I deplored this feature to Prof. Luca Fanucci. He
ignored me, as usual, so I eventually proposed as part of the VHDL standardization
process to have implicit initializations illegal. Someone unaffiliated with the largest
University of Pisa explained the legality and rationale to me on the newsgroup
and I retracted my proposal. I felt like a fool and it became
clear that no one in the University of Pisa except for myself was interested
enough in VHDL (our most important language (we never even had a C++ compiler and
almost everyone else in the group in Pisa used only VHDL for the project)) to
monitor the standardization process and that no one in the University of Pisa was
an expert of VHDL and that no one in the University of Pisa cared enough about me
to support me. This inaction of Prof. Luca Fanucci's was extremely inappropiate.
Please see my proposal and its retraction on
https://bugzilla.mentor.com/show_bug.cgi?id=120
Luca Fanucci is fit to be a professor of none of VHDL; C++; C; and SystemC(R)
intellectual properties.
Also, when I was applying to Pisa, Luca Fanucci showed me a public webpage of
STMicroelectronics's concerning the project which he initially assigned me to.
After I arrived in Italy and saw the true algorithm, I learnt that the webpage was
misleading.
Bibliography
[Crocker] Will Tracz, Quote of the Day attributed to Ron Crocker, International
Conference on Software Engineering 1995 "Window On the World", Volume 1, Number 1
[Deitel and Deitel] Deitel and Deitel; "C++: How to Program", third edition,
Prentice Hall, 2001, Section 9.6 Overriding Base-Class Members in a Derived Class
and 9.9 Using Constructors and Destructors in Derived Classes
[Fanucci] Armaroli; Coppola; Diaz Nava; Fanucci, "High Level Modeling and
Simulation of a VDSL Modem in SystemC 2.0 - IPsim", "Proceedings of The 3rd IEEE
International Workshop on System-on-Chip for Real-Time Applications", 2003
[Grammatikakis] WWW.CS.TEICrete.Gr/english/showdetails.asp?id=12
[ISD1] WWW.ISD.Gr/index.htm#top11
[ISD2] WWW.ISD.Gr/index.htm#top23
[OCCN1] Grammatikakis, HTTP://OCCN.Sourceforge.net/coverpg.html, February 2005
[OCCN2] Marcello Coppola, Stephane Curaba, Miltos D. Grammatikakis, Giuseppe
Maruccia and Francesco Papariello, "OCCN: A Network-On-Chip Modeling and
Simulation Framework", Design for Automation and Test in Europe 2004 conference
[structured programming] Leonard H. Weiner, "The Roots of Structured Programming",
"ACM SIGCSE Bulletin", February 1978