[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