Does anyone know why there are no EDIF CL libraries available?
EDIF=Electronic Design Interchange Format. It is very obviously
designed by LISP users in the early 80s. I'm having to write
some CL programs to mangle the EDIF s-expressions and it seems
like to me that whoever standardized the format probably had
lots of function libraries to do things to it.
Anyone know anything about it?
-jim
"Jimka" <·····@rdrop.com> writes:
> Does anyone know why there are no EDIF CL libraries available?
I would guess because you don't need any :-)
A EDIF parser can be written as "(read inputstream)". If you have
enough memory to handle this you can then just write some code to walk
the tree and extract the data and attributes you need.
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Yes, I agree that it seems very simple until you actually
try to do something with it. What ends up happening
again is that we write functions ourselves to handle this type
of walking... state machines, and regular pattern search
and replace. It just seems to me there would be functions already
that perform common operations on EDIF data.
By the say, parsing EDIF is more than just calling read.
There is the problem of case to consider. The keywords
of EDIF itself are apparently case independent, but the
design data it is trying to represent is very case sensitive.
Any type of walker of the data must remember to match
keywords in a case fold manner, but to respect case
of other data.
Another problem is that each keyword can only appear
in certain contexts defined by some state machine. The
state machine is explained in a 500 page EDIF manual
but there is no program available to do operations on the
data structure with correctness maintained.
-jim
Jimka <·····@rdrop.com> wrote:
+---------------
| By the say, parsing EDIF is more than just calling read.
| There is the problem of case to consider. The keywords
| of EDIF itself are apparently case independent, but the
| design data it is trying to represent is very case sensitive.
| Any type of walker of the data must remember to match
| keywords in a case fold manner, but to respect case
| of other data.
+---------------
In the small amount of EDIF post-processing I've done recently,
I've found that (setf (readtable-case *readtable*) :invert) helps
a lot with the design data, without screwing up the rest of my
environment.
If you're only dealing with EDIFs from one design tool, then the case
of the keywords tends to be constant -- camelcased, with the tools I've
been dealing with [e.g. "edifVersion", "viewRef", "cellRef"]:
(edif MyDesignName
(edifVersion 2 0 0)
(edifLevel 0)
(keywordMap (keywordLevel 0))
(status
(written
(timeStamp 2005 05 23 23 05 04)
(program "CAPTURE.EXE" (Version "10.3.0.p001"))
(comment "Original data from OrCAD/CAPTURE schematic"))
(comment "")
(comment "Wednesday, March 02, 2005")
...))
But if you're mixing various EDIF-generating tools [i.e., dealing
with EDIFs from various tools], then I suspect you're correct that
you need to do case-independent matching on the keywords.
+---------------
| Another problem is that each keyword can only appear
| in certain contexts defined by some state machine. The
| state machine is explained in a 500 page EDIF manual
| but there is no program available to do operations on the
| data structure with correctness maintained.
+---------------
My needs so far have been minimal; I've been able to extract
the data I needed with very simple CL tree-walking functions.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
"Jimka" <·····@rdrop.com> writes:
> Yes, I agree that it seems very simple until you actually
> try to do something with it. What ends up happening
I agree if you're writing a commercial tool to accept EDIF from several
vendors. However, for simple in-house work I've managed fine with read.
Recently I made a small program to extract the different ball
locations on a FPGA from an EDIF file which was exported from a PCB
system. One problem was that the FPGA was not a single instance, but
consisted of several symbols (for each IO bank) and there was no
information in the EDIF file which indicated which of these symbols
made up the physical part. This information is somewhere in the PCB
physical layout system, but was not present in the EDIF file. I ended
up making a list of all the symbols that made up the FPGA and
extracted the ball locations and convert that into the constraint
format for my FPGA tool.
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?