mostly incompatible - part 3 : Hot-air balloon

I've started a little project to see, if everything works out as smoothly as I imagined.

• Short story: It doesn't
• Long story: If you tinker about long enough, you get something working...

The first project only connects a NIOS cpu to an onchip memory and connects a clock.
That really is almost nothing - but you already see what the system will (and won't) be capable of.

• In order to have a more or less easy interface, many of the configuration decisions have to be wrapped and decided "on its own" - so it takes generics away from you...
• The modelling isn't that easy and sometimes, it is better to have a working solution than a good-looking one ... compromises wherever you look.

The project can be checked out at Google Code.

An anonymus access should be possible using

svn checkout http://high-level-fpga-gen.googlecode.com/svn/trunk/ high-level-fpga-gen-read-only

You will have to 

• install a Java JDK
• set the CLASSPATH, so it includes the current directory
• install Quartus and the NIOS IDE
• start the NIOS command shell 
• hop to the directory and call "./call_sopc"

... so if you're willing to give it a shot - good luck.

I will try to let the example grow for a while, so I will see another loadfull of difficulties.

At the moment, I don't see another easy way to find out if it's feasible at all ;0)

mostly incompatible - part 2: Wrapping it up

The problem, stated in the last post, has an answer - an artificial layer above the status quo, where everything is just fine ;-)

What should be acomplished

• You start with a collection of SOPC components, normally described by a _hw.tcl file and VHDL files for their implementation
• You want to connect them in a useful manner, not worrying too much about the little details
• The component should work out the connection details on its own - if possible.
• HW dependencies / specifications should be implemented as transparent as possible.

Starting with the technique and hitting off from there ...

• Every component will get a Java-File that can be included like
  "import fpga_components.component2.*;"
• The Project itself gets another Java-File e.g. mySystem.java that is calling the components' functions in order to make the right connections (sometimes with arguments, referencing data files like the memoryInstance...xml files)
• The Projects can inherit from one another (Java is quite suitable for clean inheritance) and overwrite properties (e.g. bit_width) and methods (when some part is just handled in a completely other way).
• The output of that whole Java-Process would just be some small TCL-Files with the plain calls to the automated SOPC builder...
• In the long run the _hw.tcl files should also be generated by the Java-File (... but that might be a nice second step ...) so the correspondent things can be done for Vivado etc. - but for a first run, the SOPC integration could be done with the already existing _hw.tcl files.
• "service" components like a memory core with multiple ports collect all the requests from the connected components and configurate themselves afterwards accordingly (so - it is dynamically decided, whether a component gets port 3 or 4, whichever is the next unused one...).
• For the normal case, that the memory core isn't written by yourself, its configuration is done with a Java-File nevertheless - the instantiation calls just call something external that is included otherwise.

First traps - right means used?

• A first thought was to use precompiled .jar-Files - that way, you could have started out without knowing, which files are around...
• For a first implementation, the version with "hard linked" files will be more transparent and the upcoming errors easier to find... (You just have to call "javac .." and "java ..." after one another to get it started - so linkage problems will occur already at javac).
• Java is a "clean" language and on all platforms available.
• The alternative might have been C# where the plugins would have been .dll files - do-able but not really easy to read.

Above above

• The components should have a common core - so the base class(es) will also be a part of the fpga_components-directory and they will also be checked-out/copied-into/whatever.

=> Hot air without content

• The real problems and real answers will occur on the battlefield - when the first classes have been written and the smoke clears...
• A good way would be to port some existing code to the new manner and to try to implement a small project that just instantiates two or three of these components and glues them together ...

mostly incompatible - part 1 : VHDL - as if higher languages have never happened

Hacking plain VHDL without further abstractions is quite hard when you want to mantain dozens of different projects:

• they are more or the less the same ...
• ... but differ in the combination or configuration of the sub components that make them up
• the answer was the SOPC builder from Altera, Xilinx has struggled a long time until they came out with Vivado and now Altera have dared to introduce QSys as a slightly incompatible successor.

The actual state

SOPC / QSys

• The SOPC builder (and QSys) is a good and plainly implemented idea ...
• ... you just have to make the connection where they are possible by filling out a binary matrix
• ... but for every component interface you add, you either add a column or row - making the matrix extreeeemly big (20x60 for a normal system - just activate the right nodes ... of the 1200)
• ... and the GUI is doing a poor job with that huge number of possible connections ...

Vivado

• might be better than I think - since I don't develop with Xilinx chips and have only watched the presentation above (link)
• it uses a schematic view and nice boxes with structured connections (so you don't have to see every signal)
• since that is still too much trouble they added some heuristical automatisms like Auto-Connect for a few components it knows and a verify to find the wrongly connected dots faster ...
• overall it seems a bit ... basic ...

Scripting as a first solution ...

In order to have a programmatic solution - without much clicking - you can use TCL scripts to automate the GUIs (Vivado, SOPC builder and QSys). They naturally use different syntax etc. but do more or less the same...

• TCL isn't a language that is structured per se and the way Altera uses it doesn't help much either.
• So - you can automate it, you can structure your different projects and model your systems in any way you want but ...
• ... it isn't portable anymore
• ... it is quite unreadable ...

... another layer above as the second

It would therefore be nice to define the system a bit more general.

The breaking-down to the actual implementation would be done in a secondary step, where the gory details can be locked away in funny code - once - and then you can forget about them.

mostly botch 2: Problemchen bei den Traum-Maßen

Auf der anderen Seite unseres Häuschens haben wir noch nach einer Sitzmöglichkeit gesucht und mit wenig Platz sowie dem passenden Untergrund gekämpft.
Die Lösung kam wieder von Christine Reess, die uns vorschlug, die Bank auf das Lüftungsgitter unserer Luft-Wasser-Wärme-Pumpe zu stellen:

• dort ist sie überdacht und wenn man drauf sitzt hat man die Wand im Rücken (Feng Shui freut sich)
• der Platz ist dort eh noch frei und etwas massives, das die Luftzufuhr verhindert darf nicht drauf.
• ... perfekt

Nach ein bisschen Amazon-Recherche hatten wir unseren Favorit gefunden.

• Keine Wartung (alle Jahre neu anpinseln) notwendig
• von der Farbe her wollten wir auch im Bereich weiss/grau/schwarz bleiben.
• genau die richtigen Maße - Die Bank ist mit 126x81x57cm angegeben und unser Gitter ist 55cm breit, wobei 1-2cm hinten noch Luft sind...

Denkste

Das Päckchen kam an und war innerhalb von 10 Minuten aufgebaut - wirklich nett.

Leider stellte sich raus, dass mit 57cm Tiefe der Abstand der Füße gemeint war - weiter oben ist das Rückenteil etwas ausladender ...

Ein bisschen hatten wir so etwas schon befürchtet und auf die Fuß-Bohrungen gehofft.

Also auf in den Baumarkt und Bastelmaterial besorgt...

Die schwebende Bank

wie man sieht konnte man ein einfaches Alu-Profil 

• für 6 Euro erstehen
• mit einer kleinen Metallsäge kürzen
• drunter legen und die Löcher anzeichnen => Vorsicht - Fussabstände waren bei uns links und rechts 15mm unterschiedlich - also nicht nach dem ersten Anzeichnen kopieren ;-)
• mit einem 5er Bohrer ein Loch durch und mit 5mm x 20mm -Schrauben fest machen

Die Bank steht somit auf der Alu-Schiene und diese liegt auf dem Beton-Rand sowie den Gitter-Stäben auf. Alu ist zwar kein besonders harter Werkstoff aber genau deswegen kann man ihn als Laie bearbeiten und bei der Anwendung reichts hoffentlich (Scher-Winkel, Material unter Zug etc. - man kann sich's auf jeden Fall schön reden)

=> Zumindest wackelt es nicht, ist bequem und wir sind vorerst mal glücklich und hoffen dass es langfristig hält ...

mostly botch : Ein Kamin-Rankgitter für unseren Hopfen

Um die Terrasse auch an der Fensterfront ein wenig zu begrünen haben wir uns entschlossen, einen Hopfen den Kamin hochwachsen zu lassen.

Leider fanden wir keine fertigen Lösungen oder Tips dazu und mussten daher selbst kreativ werden.
Dieser Beitrag passt zu unserem Kamin - wahrscheinlich nicht zu Deinem - nimm ihn einfach als ersten Denkanstoss und den Beweis, dass selbst handwerklich unbegabte Leute was halbwegs passables hinbekommen, wenn sie nur darauf achten, faul zu bleiben ...

Hopfen

• hinterlässt keine Spuren der Saugnäpfe, wie bei wildem Wein oder Efeu
• verdorrt zum Winter hin komplett, sodass man zwischendurch auch wieder ran kann (Terrasse neu ölen etc.)
• ist ein flotter Kletterer, sodass er über einen Sommer hinweg auch schnell wieder oben ist...

Ran an den Kamin

• Eine erste Version verwendete Schrauben, die auch den Kamin gehalten hätten - also gschwind aufschrauben, Blech noch durchfitzeln und schnell wieder zuschrauben.
• Das haben wir uns dann doch nicht getraut - keine Ahnung, was so ein Kamin sagt, wenn man ihn mal zwischendurch losschraubt ;-)
• Es gab jedoch in den Langlöchern noch einen geschickten Platz, wo man eine weitere Schraube befestigen konnte...
• Somit wird das Rankgitter oben befestigt und hängt dann einigermassen lose bis in den Kübel runter

Ausgangspunkt

• fertige Bohnen-Gitter von 1.8m aus verzinktem Metall, die eine viel zu enge Biegung hatten
• ein einfaches Alu-Blech mit 1m Länge
• Drahtseilklemmen
• einige M8er-Schrauben und Muttern sowie passende Unterlegscheiben

Das Blech kann man in Breite und Dicke variieren, je nachdem wie viel Stabilität man sich erhofft und wieviel Stress man sich geben möchte.

Alu wurde verwendet, da es nicht rostet, für Hobby-Bastler noch bearbeitbar ist und kein chemischer Quatsch mit dem Rest passiert.

Vorarbeiten

• Uns reichte die Höhe von 1.8m und somit wollten wir nur die Breite der Gitter vergrößern - wir haben daher zwei davon etwas auseinandergebogen (ging super) und mit der Hälfte überlappend übereinander gelegt.
• Danach wurden die beiden Gitter an allen Steg-Kreuzungen mit normalem verzinkten Gartendraht aneinander gebunden (verdrillen und mit einer Zange festzurren und abzwicken)
• Die Breite des entstandenen Rankgitters wurde ausgemessen und in der Mitte des Alu-Blechs in diesem Abstand Bohrlöcher für die Drahtseilklemmen angezeichnet.

Bohren und Schrauben

Eine billige Bohrmaschine, Metallbohrer vom Tchibo und ein bisschen Geduld reichen, um Alu zu Leibe zu rücken.

Mit einem 4er-Bohrer wurden die Löcher für die zwei Klemmen gebohrt.

Danach wurde das Alu-Blech auf die gleiche gewünschte Rundung gebracht - geht gut ohne Schraubstock und Werkzeug - einfach in die Hand nehmen und biegen (am Ingenieurs-Bauch oder so).

Danach am besten Rank-Gitter und Alu-Blech unter leichtem Fluchen (weil's nur pi*Daumen passt) zusammenschrauben. An den Kamin ran halten und schauen, ob man noch etwas kürzen muss - weil's viel zu weit weg ist... Danach mit einem 8.5er-Bohrer links und rechts die Löcher für die Kamin-Installation bohren.

Abstand halten

Bei uns gab es noch eine Schraube weiter vorne, für die man eine Biegung hätte machen müssen ....

Statt dessen wurde eine längere Schraube verwendet und eine Mutter extra als Abstandshalter verwendet.

Zwischen den Lagen gabs jeweils noch ne Unterlegscheibe - weil das kleinste Päckchen 100 Stück enthielt ...

Im Winter wird die äusserste Schraube entfernt und das Rankgitter kann somit komplett abgenommen werden - weil bei uns im Januar der Kaminfeger ja auch überall ran will...

Ergebnis

wir finden's schön und hoffen, dass die abenteuerliche Konstruktion auch ne Weile hält.