[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
gEDA-user: An example for other uses of gEDA: visual programming
Hi everybody!
Some of you might remember have read this thread back in December:
http://archives.seul.org/geda/user/Dec-2008/msg00065.html
Back then I had some issues with gnetlist and hierarchy handling.
Unfortunately, when asked for more details, I couldn't give furhter
explanations due to a lack of time (since there is no quick way to
explain this).
Peter Clifton asked me to send the details, since at least the geda
developers might be curious seeing how I use the software. Back then, I
had a tight deadline to observe, but now I'd be glad to fill you in on
some details.
(N.B.: I originally intended posting this to gEDA-dev, in order not to
annoy less experienced/interested users, but the developer mailinglist
has gone invitation only, so it's probably best to do this here on
geda-user. If you're not interested just don't read it.)
abstract
--------
The work I did is a diploma thesis at the Technical University of Munich
(Technische Universität München), chair of computer architecture,
entitled "design techniques for dataflow oriented processor architechtures".
The basic idea is to enhance an EDA tool in order that it can be used
for visual programming of a dataflow array processor.
The PACT Technologies XPP-III (eXtreme Programming Platform) is a
processor architecture that contains, among other nice stuff, a dataflow
array made up by configurable processing array elements (PAEs).
(You can get more information on this topic here:
http://www.pactxpp.com/main/index.php?id=publications_whitepapers, for
further details and some very explanatory diagrams please have a look at
the "XPP-III processor overview" whitepaper.)
PAEs can be configured to perform some primitive operation such as ADD,
SUB, MUL, XOR, etc., and the data routing connections between them can
be configured as well.
The configuration of the dataflow array is done via the "Native Mapping
Language" (NML), PACT's proprietary language for that purpose. PACT
defines the effort as "comparable to assembler programming, but much
simpler than HDL [..] since no timing issues arise". Still, its quite a
time-consuming work.
The goal of the diploma thesis was to enhance gEDA so that it can be
used for programming, i.e. configuring, the XPP-III dataflow array
graphically and obtaining NML code out of this graphical configuration.
Basicaly, two means were necessary to achieve this goal:
- a set of PACT XPP-III specific symbols for gschem
- an NML backend for gnetlist that understands these symbols and
generates the NML code out of the schematic
Each symbol represents a different PAE configuration such as ADD, SUB,
MUL, MERGE, DEMUX, etc. (and the wiring of these symbols in gschem
configures the data port interconnection configuration of the array).
The netlister backend is then fed the schematic, producing the according
NML code.
I've put together a brief illustrated explanation here:
http://home.in.tum.de/~florian/geda/thesis/index.php
(The text I intended to send turned out way too long, and I found it
hard to judge if it was too confused to understand for anyone but me ;).
So, if it turns out anyone is interested in the topic and wants some
more details, feel free to ask.)
the problem
-----------
So far it was all quite straight forward. The real problems arose when
dealing with NML's module structure and schematic hierarchy.
I will send some more details on that if requested.
To make a long story very short, I have a hierarchycal structure with
one subsheet corresponding to one module in the NML code.
And I had to get a hierarchical view of this inside the netlister
backend, for several reasons:
- There are module instance specific attributes (= sub sheet
instantiation wide attributes), so I virtually _had_ to get the sub
sheet symbol
- Modules can be instantiated multiple times, and I have to detect
those multiple instances (can't be done that easy with hierarchy
traversal enabled)
- I have to detect the module signature (=i/o ports from subsheet to
higher level sheet), even with unconnected subsheet pins
In the end, I solved my problem the (presumably) only satisfying way: by
disabling hierarchy traversal and then calling gnetlist (with my own
backend of course) recursively from within my backend's scheme code,
producing temporary module files and reading in and appending those
files the way back up returning from the recursion when the recursion
terminates.
This way I would process all components and yet I could process and
analyze the subsheet symbols (and the attributes they hold).
contributions
-------------
In the course of this thesis I did some work that the community might
benefit from as well.
In my opinion it'd be better if I opened a separate thread for the
discussion on those contributions, since and mixing up the two
discussions produces a mess,
I think you'll agree.
Regards,
Oliver
P.S.: Many thanks to Ales Hvezda, Steve Meier and Peter Clifton for
their help efforts.
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user