Subject: |
Re: Ascii file formats and the use of EDIF |
From: |
[email protected] |
Date: |
Fri, 08 Apr 94 15:01:47 -0500 |
I don't want to get into circles on this topic. Last month we
had a 1 hour talk about file conversions at the LANL meeting. The
issues and current answers are:
Q) Will we continue supporting DCT.
A) No, Phase it out. Let gdct replace it.
Q) Will we support the use of EDIF based design tools.
A) Yes
Q) How will we support these EDIF based design tools.
A) Use conversion programs between EDIF and our database format.
Q) How should we convert between EDIF and loadable binary.
---> I opened my big mouth asked...
Q) Can't we loose the binary format and just load an ascii file(s)?
A) If it does not take more than 25% longer than the binary to load.
(Earlier this week, some timing tests showed this to be the case
when using the currect gdct ascii format. Loading straight EDIF
could fail this speed requirement since it is much more verbose.)
Q) Could the ascii format be EDIF?
A) Yes if we could convert gdct to use EDIF. We would also have to
make sure it loads at a reasonable speed.
Q) What would it take to convert gdct to EDIF?
A) 1) Convert the current ascii data to EDIF format.
2) Add the graphic line plotting data.
3) Insert the proper references to the component/symbol dictionary
for the record instances.
Q) Is it possible to convert gdct to EDIF?
A) I am now finding out that it looks OK except for the graphic
info. Probably not in a bidirectional way unless the loss of the
graphic info is acceptable (I assume not.)
Q) Should we convert dctsdr from binary to ascii (to go along
with the rest of the ascii stuff)? And what format should we use?
A) Ascii would be better for the same reasons as for the record
descriptions. EDIF should be possible. I am looking into it now.
Q) Would such an EDIF version of dctsdr be useful to capfast users?
A) Unknown. Looking into it. Need comments.
Q) Is it possible for something like capfast to load and edit an EDIF
file that has no graphic information in it.
A) I thought that Chip Watson said the answer is no, but would try it
to see what would happen. *I* am supposed to look into the EDIF
specs to find out what is specified about this situation, and have
not done so yet.
=======================================================
Time passed, I did the gdct ascii load test and it looked OK. I talked
with Jim Kowalkowski about GDCT and using EDIF for the files. He said
it looks OK, except for the graphic stuff since it is part of the
graphics library and is not too close to EDIF. It would take a fair
amount of work to do and would require imposing on the paradigm (my one
for the day) used by the interviews package to save its graphic info.
=======================================================
Here are the current questions going thru my head and my gut feelings
about the answers:
Q) If GDCT can't share databases with capfast, is using EDIF
as the gdct file format reasonable?
--> I don't think so. It would only waste time to rewrite the code and
for no gain. Capfast's database files would still be editable by
gdct (since a converter would need to be written), but not vice
versa.
Q) If EDIF is slower than the current ascii format is it worth loading
on the IOC?
--> Maybe. I have always hated keeping two copies of data in sync with
eachother. And was 1/2 the reason to get rid of the binary
databases. (The other 1/2 was to eliminate the required internal
representation of the binary data and structure field alignment crud
that goes on in makesdr.) So for that reason I would like to say
yes. But if noone wants to use it, the point is mute.
Q) If EDIF is too slow, should we continue to think about using it for
dctsdr?
--> Only if it is some use to the EDIF users. If they still have to
generate some kind of graphic library and insert the descriptor info
into that somehow, then who cares? It would be better to use a more
effecient format for loading and the flat file lovers. This awaits
comments from the capfast klan and some reading of the EDIF manuals.
Q) If EDIF is too ugly for the oracle report generator users, what
format should be supported, since a conversion would have to be
written for them?
--> Why create more formats. The current gdct format seems pretty
reasonable, and loads fast enough. Any other sugestions?
Q) Will the EDIF schematic tools be able to edit anything that
originates from our non-EDIF based tools?
--> I don't think so, unless they are happy with the lack of graphic
info. Because that info is currently not part of the gdct format,
and never will be present in the oracle-generated databases. This
awaits info from the EDIF specs and some tests by the users.
Anyone want to try to load up that file from Matt Needs into capfast
as is and see what happens?
===================================================================
What am I leaving out? Am I lieing about anything? Has anyone ever
taken a DCT database and (somehow) imported it into a usable EDIF file
for capfast editing?
--John
- Navigate by Date:
- Prev:
EPICS drivers for CAN and RS232 / TCP/IP Matthias Clausen DESY -MKV2/KRYK-
- Next:
Re: Ascii file formats and the use of EDIF watson
- Index:
<1994>
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Ascii file formats and the use of EDIF winans
- Next:
Re: Ascii file formats and the use of EDIF watson
- Index:
<1994>
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|