Here's a link to one of the best accounts of a complex project
which has a large software component. (I or someone else on the
design team always tried to do these after completing tape out
for an IC, but seldom achieved this level of Shiro Kawai's
insight.)
http://www.lava.net/~shiro/Private/essay/gdc2002.html
and an account at an earlier point in the project:
http://www.shiro.dreamhost.com/scheme/docs/jlugm2000.html
With knowledge of IC design flow in mind, I came away with some great
points:
1. big projects use off the shelf and custom software
2. some (maybe most?) big software projects don't produce
software as a deliverable , but produce software to create
another product
3. lots of languages are necessary, particularly for point
tools: perl, lisp, VBasic, SQL, Java, scheme, (add verilog, M,
spice, tool scripts, and C for an IC design)
4. workflow and its eveolution are key
5. the people who begin with the project aren't the same ones
who finish it
6. lisp (allegro lisp, anyway) can behave and play nicely on
unix with other languages and off the shelf software ( I have
not seen this in IC design, though.)
7. on a big project, programmers will create enough custom
tools to allow users to exceed the hardware capacity which
seemed reasonable at the beginning of the project.( true in IC
design, too.)
Enjoy!
Chris
Chris Beggy <······@kippona.com> writes:
> 6. lisp (allegro lisp, anyway) can behave and play nicely on
> unix with other languages and off the shelf software ( I have
> not seen this in IC design, though.)
What about Cadence Design?
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> Chris Beggy <······@kippona.com> writes:
>
>> 6. lisp (allegro lisp, anyway) can behave and play nicely on
>> unix with other languages and off the shelf software ( I have
>> not seen this in IC design, though.)
>
> What about Cadence Design?
You're right.
If the design flow uses Design Planner, the engine or object
management part under the hood is lisp. Likewise, scripting for
layout/schematic capture is in lispy SKILL. For some of the
Avanti tools the scripting language is schemey, too.
In Shiro's project, though, they used more than just lisp
binaries or lisp for scripting, I think. They used it to write a
mini-language to allow *other* off the shelf software, perl
scripts presumably using DBD::xxsql modules, java, and
visualbasic, to query the sophisticated database.
The point I'm trying to make is this: faced with a similar
problem in an IC design flow, in my experience, folks would
choose perl, C or maybe python, and wouldn't even consider lisp.
This article proves that *can* and maybe *should* consider lisp
to patch, extend, and enhance a design flow put together with off
the shelf and homegrown point tools.
Chris
Chris Beggy <······@kippona.com> wrote in message news:<··············@lackawana.kippona.com>...
In Shiro's project, though, they used more than just lisp
> binaries or lisp for scripting, I think. They used it to write a
> mini-language to allow *other* off the shelf software, perl
> scripts presumably using DBD::xxsql modules, java, and
> visualbasic, to query the sophisticated database.
Actually, we didn't get perl DBI interface work
on our database, although we thought of implementing it.
We used our proprietary interface. Also we wanted to make
it work with ODBC but we couldn't do so in time. These
could've been done if we have had targetted at such a system
from the beginning (The system we got was the outcome of
our crooked path).
However, Chris makes the point. If the function modules
can be clearly separated and the interface is cleary defined,
as in the database server and clients, people don't care
much what language the other module is written in.
And if the other side is written in "popular" languages,
such as perl, python or even VB, people start using the
lisp core without knowing so, and even like the flexiblity
of the lisp side (as far as you have enough people who can
maintain the lisp side).
--
Shiro Kawai
http://www.shiro.dreamhost.com/scheme/
# The most important things are the hardest things to say --- Stephen King
·····@acm.org (Shiro Kawai) wrote:
> However, Chris makes the point. If the function modules
> can be clearly separated and the interface is clearly defined,
> as in the database server and clients, people don't care
> much what language the other module is written in.
It is very well said. If I may, I'd like to corroborate Chris' and
Shiro's point with an additional example.
Metcast [1] decouples applications along two planes. The first plane
of separation is the database. A (web application) server doesn't care
how its back-end database is populated. The server and the decoders of
data do not communicate directly; they are not even directly aware of
each other's existence. They work on their own timescale, in separate
processes, on behalf of different users (and even sometimes on
different computers). Needless to say decoders and the server can be
written in different languages (although they are all implemented in
Scheme).
The second plane of decoupling is between clients of data and the
application server. The clients and the server communicate via HTTP,
which is a remote procedure call protocol [2]. An HTTP transaction
payload may be a multi-part entity. This makes it possible for an HTTP
RPC call to accept and _return_ multiple values. We found the latter
to be highly useful.
Metcast clients request products in a _declarative_ S-expression-based
language [3]. The language was designed in 1997, before the whole XML
hype broke loose. Architecturally, the Metcast looks a lot like web
services (although it was running before such word emerged). We do
have a bona fide web services gateway btw, developed by an independent
person. This proves that Metcast isn't that complex to
program. Speaking of Web services, I'm constantly fending off
persistent attacks to uglify the request language and turn it into
XML. Making MBL XML is trivial -- but it brings nothing but ugliness,
along with the buzzword compliance.
Since Metcast clients are cleanly separated from the Metcast server,
the clients can be written in any language that supports string
processing. I know of Metcast clients written in C++, Java, Perl,
Python, Scheme, JavaScript and even VB (the latter wasn't my
idea). Because we use httperf for benchmarking, I guess I should add C
language to the above list. You can even write a Metcast client in
Fortran (no one has made that choice, AFAIK).
The Metcast server is written in Scheme. Thanks to Mario, it runs as a
FastCGI process connected to the Apache (or IIS, if needed to be) web
server. This combination gives us load-balancing, process/connection
pool maintenance, and SSL processing for free. BTW, you can write a
FastCGI server in R5RS Scheme. With inetd, you only need to read and
write on the standard input and output ports. The superdaemon does not
impose much overhead: it comes into play only when the pool of fastcgi
processes expands.
[1] http://pobox.com/~oleg/ftp/papers/Scheme-Metcast-paper.ps.gz
http://pobox.com/~oleg/ftp/papers/Scheme-Metcast-talk.ps.gz
http://zowie.metnet.navy.mil/~spawar/JMV-TNG/
[2] http://www.usenix.org/publications/login/2000-4/features/speaking.html
[3] http://pobox.com/~oleg/ftp/Scheme/Request-Language.html
http://zowie.metnet.navy.mil/~spawar/JMV-TNG/Request-Lang.html
(the latter two documents are not the same)