Re: gEDA-user: Design Flow Roadmap starting point
From: al davis [EMAIL PROTECTED] Subject: Re: gEDA-user: Design Flow Roadmap starting point Date: Sun, 18 Mar 2007 01:29:07 -0400 Message-ID: [EMAIL PROTECTED] Al, (Jumping into the discussion mid-waters) I still believe we need an interchange file format, that should be a VHDL derivative. VHDL has most of the capabilities needed, and is an industry standard. If something is missing, we can add it, and propose it back to the standards committee. They might even welcome it. I think that VHDL is a very good boiler-plate. This approach was used for Boundary Scan files. You can strip of many things from VHDL which you will not initially need. What you end up with very quickly is a small subset which brings much of the properties which gedas textual format has. It should be fairly easy to do so. Hierarchial stuff is trivial. Attributes is trivial. From this you can then selectively add things from the VHDL standard at need. What should one cut out or cut down then? Design entities and configurations (Section 1) - all but config (1.3) Subprograms and packages (Section 2) - cut out Types (Section 3) - cut down considerably Declarations (Section 4) - cut down Specifications (Section 5) - most if not all is in Names (Section 6) - most if not all is in Expressions (Section 7) - initially all cut out Sequential statements (Section 8) - initially all cut out Concurrent statements (Section 9) - all but 9.5 and 9.6 which however is cut down This is just a swift walk-through of the VHDL standard (using the VHDL-93 that was lying on my desk anyway). Whatever is needed to support AMS infra- structure (i.e. analog signals), which should not be very much. What we need is: Entity declaration (with generics and ports). Architecture. Instantiation of other entities. Assignment of attributes and generics. Assignment of signals. UREF's could be converted into labels. This is not complex stuff and it should be fairly easy to generate parser and dumper in C or C++, especially if one uses PCCTS/ANTLR. Writing up a VHDL equalent format for the geda netlist format should not be too hard. If you want to go beyond the geda netlist format constrains of today, it is fairly easy to do. The one thing which I am not up to date on is how modern character sets is handled etc. gnetlist really needs to be redone, from the ground up. This VHDL based intermediate format is the way to do it. gnetlist has served us well so far, but we have learned a lot by doing it and using it, and it is time to move on. Indeed. * Similarly, how should gnetlist behave? A use-case list would be useful. Any extraction should preserve hierarchy, in hopes that the target tool also benefits from it. If it doesn't, you need a separate flattener pass, separate from the translation. In a gnetlist rewrite, a flattener could be written and called for those backends that need it. In the other direction, naming conventions may alow for de-flatenations in some cases, so support for that may also be considered. Regardless, the translation must be 100%, lossless, in both directions. Indeed. gschem attributes need to have types. The type is just a string, but important. That way one type can be those passed to a simulator, another can be those passed back from the simulator, etc. Since the type is just a string, new types can be added at any time. An attribute should be able to have multiple types. Your uses of types confuses me here. In a future, it is not necessarilly only strings, but it is a good first assumption. * Finally, how should PCB behave with a hierarchical schematic? Right click on a symbol, select go inside, and another drawing opens up showing what's inside. gschem also should act this way. Indeed. Cheers, Magnus ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
From: al davis [EMAIL PROTECTED] Subject: Re: gEDA-user: Design Flow Roadmap starting point Date: Tue, 3 Apr 2007 19:08:27 -0400 Message-ID: [EMAIL PROTECTED] Al, All that is needed is the basic framework. It is really simple. Most of everything is out, but by picking a standard language there is a pre-determined way to add later if we need it. Certainly. My point with the exercise was to show just how much of VHDL that is not going in. What we need is: Entity declaration (with generics and ports). Architecture. Instantiation of other entities. Assignment of attributes and generics. Assignment of signals. UREF's could be converted into labels. Not even all of that. Maybe not. This was a very quick and coarse subset exercise. What is needed is a somewhat large subset of VHDL than the current gnetlist VHDL backend generates. You can actually take that subset and extend out from that until you have the features you need. I beleive the relevant comments is still there to help guidance through the VHDL LRM. :-) This is not complex stuff and it should be fairly easy to generate parser and dumper in C or C++, especially if one uses PCCTS/ANTLR. I was thinking of using the gnucap CS parser class, and doing it like everything else in gnucap, as a language plugin. I am guessing that VHDL will be about 50 lines of code, Verilog will be about 50 lines of code, Spice will be about 2000 lines of code, pcb about 100 lines, not sure about gschem. Need to look at the gnucap parser class stuff. Otherwise I agree. The idea is a common framework that gets them all. It must be able to both parse it and generate it. Certainly. However, many formast have their quirks and limits, so in the end you will find that many formats will be hard to fully support. gnetlist has served us well so far, but we have learned a lot by doing it and using it, and it is time to move on. Indeed. There is lot of old stuff like that. That is my opinion of Spice, too. It has served us well, time to move on. At least a few of its creators think so too. Certainly. With modern things like VHDL and XML you can take a fresh start, gain a little and loose a little. I've never been a fan of XMLizing things for its own sake thought. gschem attributes need to have types. The type is just a string, but important. That way one type can be those passed to a simulator, another can be those passed back from the simulator, etc. Since the type is just a string, new types can be added at any time. An attribute should be able to have multiple types. Your uses of types confuses me here. The idea here is that if attributes have types it is easy to filter out or select all attributes of a given type. It also is easy to make translators. Certainly, but for a sufficiently complex thing, type filtering isn't helping unless you can construct new types out of the old and name them as you like. Compound types of various sort comes to mind after some time and ka-bang things got a bit complex again. Filtering on attribute names is probably a better appoach most of the times. Cheers, Magnus ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
From: al davis [EMAIL PROTECTED] Subject: Re: gEDA-user: Design Flow Roadmap starting point Date: Tue, 3 Apr 2007 20:22:34 -0400 Message-ID: [EMAIL PROTECTED] On Tuesday 03 April 2007 19:38, Magnus Danielson wrote: From: al davis [EMAIL PROTECTED] I was thinking of using the gnucap CS parser class, and doing it like everything else in gnucap, as a language plugin. I am guessing that VHDL will be about 50 lines of code, Verilog will be about 50 lines of code, Spice will be about 2000 lines of code, pcb about 100 lines, not sure about gschem. Need to look at the gnucap parser class stuff. Otherwise I agree. The line count is a guess. My point is that VHDL and Verilog are about the same. Spice is the worst one of all. Others are between. The fact that VHDL and Verilog are so regular makes the parsers and generators small. The Spice parser and generator is huge because the language is so irregular. It seems every component is different. Index finger to thumb measures are fine. :) The point about irregular languages is indeed a good one. Certainly, but for a sufficiently complex thing, type filtering isn't helping unless you can construct new types out of the old and name them as you like. Compound types of various sort comes to mind after some time and ka-bang things got a bit complex again. Filtering on attribute names is probably a better appoach most of the times. That is way too complicated. The type is just a name, used to group things, so they can be filtered as groups. I was talking about type as in integer, real, string, bit etc. Thus the confusion. Without changing anything, it is possible to just use a naming convention and partial matching to select. I am thinking of groups like simulation parameters, the hidden attributes that make gschem work, layout stuff, data coming back from a simulator. The names cannot be determined in advance. Strings like what we do now for things like spice sources is not the way to go long term. To store it, it would need to be able to be encoded as a single string anyway, so it might make sense to just do that and forget doing anything special. Thus, the only type you initially intend to support is string. However, many named constants/attributes/generics of the type string is in there. I forsee alot of other side-information that follows along. We might need different architectures depending on which simulator is going to handle things. A simulation model for one form may not have the same names as another etc. You would also like attributes to propagate out of devices, so that we can have for a signal the shortest rise and fall times, which is immensly usefull for SI and EMC work, just to name one. If you take a few steps back, there are more of these things. Cheers, Magnus ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: XML file formats .... was: Re: gEDA-user: Some footprints I tried to create
From: Stuart Brorson [EMAIL PROTECTED] Subject: XML file formats was: Re: gEDA-user: Some footprints I tried to create Date: Wed, 14 Mar 2007 16:59:37 -0400 (EDT) Message-ID: [EMAIL PROTECTED] Stuart, Sounds like a job for XML :-) . Really, I don't see the big deal. If you would like am XML format, write a parser that will take the current format and generate XML to and from that. This could be located in the File-Export / File-Import menu (or something like that). Now you get your XML and others can keep what they currently use. I don't want to go into great detail about the argument against XML again. I'll observe that we have this same debate about XML file formats every two or three years. I think it has to do with how long it takes us to lose our institutional memory due to churn on the mailing list. Maybe I'll write an item for the FAQ about why we don't junk the file format in favor of XML. Please do! * The other benefit of XML is that it is more-or-less human readable. I'll grant that this is a valid assertion. Our current file format is not readable by a human who has never read the documentation. However, our current file format *is* ASCII, and is completely documented, so an essential reason for readability -- the ability to write scripts against the file -- is already taken care of. Also, a human can certainly read the file format once he has taken the time to RTFM. Human readability -- without knowing the file format -- is a nice to have which isn't high on my priority list. I agree with all your other points, but would actually like to modulate this one. While an XML format to some degree is more readable upfront, you will still rely on documentation for the higher levels anyway, as they in no way is encoded into the format. The basic format will be a little less cryptic than the gEDA format, but higher level requirements cryptography will remain the same, so you can never walk away from the RTFM factor. Never. So, to some degree this aspect is as much a chimera as with the finished parser, infact for the same reason as these aspects is really application specific and not format specific. Other than that, I agree fully with you. These are just my opinions, of course. Naturally. :) Finally, if you really, really want to play with gschem files in XML, you can grab a pair of .sch - XML utilities I wrote 4 years ago here: http://www.brorson.com/gEDA/gschem/ If you really want XML schematic files, have fun with those little utilities! Having XML capability through such a side utility may very well be a good middle way. If you dress the bride up with DTD and documentation, it could be usefull for those dying to toss their XML tools at the data, or indeed want to interact with the data through XML. Maybe one should consider bringing it into the GAF family. PS. I beleive I was quite early out raising a voice against XML. Cheers, Magnus ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: OT: Opencores CORDIC - bugs?
From: Peter Clifton [EMAIL PROTECTED]
Subject: gEDA-user: OT: Opencores CORDIC - bugs?
Date: Sat, 10 Mar 2007 04:14:19 +
Message-ID: [EMAIL PROTECTED]
Hi,
Peter,
I was just curios if anyone on list has used the open-cores cordic VHDL.
Haven't played with that. Haven't had the need so far.
I'm using it to generate a reference waveform for a PWM generator, and
have been bashing my head against the wall with little oddities and
glitches like different results for +ve and -ve angles (which should
read the same for cosine).
Eventually, I tracked it down to the HDL which divides by a power of two
in the cordic pipeline. Put simply... it doesn't work for -ve numbers.
In twos complement - for the specific implementation used at least -
which sign extends with the original MSB:
-2 1 == -1
-1 1 == -1
(etc..)
Clearly this is different from the behaviour for +ve numbers, hence he
discrepency I noted.
Does anyone per chance know an efficient hardware algorithm which can
produce the same /2 results for +ve and -ve twos complement numbers?
Shift left with sign extention?
half(30 downto 0) = whole(31 downto 1);
half(31) = whole(31);
Should do it. Very efficient.
If you try it on -2 you expect -1:
1110
=
If you try it on 2 you expect 1:
0010
=
0001
-3 will become -1 just as 3 will become 1. Thus, it is symmetric around 0.
This _may_ not be what you are after. You might require rounding such that
-1 / 2 become 0. This is kind of running into the IEEE-754 field, but with
whole numbers. Regardless of which you need, it should be obvious how to
extend this. An adder-chain for the rounding is a good hint I think, but only
if you really need it.
Depending on which stage in the cordic pipeline, the shift may be up to
one less than a whole word length. I've no idea how this ends up being
synthesised in an FPGA.
I would have to take a look in the CORDIC code, but I don't have the time now.
My current work around is to test for negativity, take the -ve if it is
-ve, (giving a +ve), do the shift, then take the -ve again (if the
original was -ve).
Perhaps the best way is for me to keep the cordic operating in the
0-45 degree angle range, rather than the -45-45 I've been using so
far.
Any thoughts?
Cheers,
Magnus
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: vhdl and gschem
From: John Griessen [EMAIL PROTECTED] Subject: Re: gEDA-user: vhdl and gschem Date: Sun, 18 Feb 2007 18:54:46 -0600 Message-ID: [EMAIL PROTECTED] al davis wrote: For manual entry, the Verilog format is clear, compact, and regular. .. far superior to the Spice format. The next real release of gnucap will use Verilog as the default netlist language, and read Spice files through a plug-in. Thanks for that decision Al, I've always liked the now orientedness of verilog/iverilog. It's a natural for text definition of a network -- of wires or busses. It's a language about what's-connected-now. I on the other hand would have preferred VHDL. There is many reasons for it. Cheers, Magnus ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: vhdl and gschem
From: Chitlesh GOORAH [EMAIL PROTECTED] Subject: Re: gEDA-user: vhdl and gschem Date: Fri, 16 Feb 2007 23:36:22 +0100 Message-ID: [EMAIL PROTECTED] Hello there, I successfully created a vhdl file from http://tux.u-strasbg.fr/~chit/cours_vhdl/halfadder.sch http://tux.u-strasbg.fr/~chit/cours_vhdl/output.net. However, since my schematic includes some and2 and or2, the output.net includes the respective components, but if I compile the vhdl file directly, it will fails since it lacks the and2 and or2 entities. Unfortunately for such a simple schematic. Is there a method to tell gnetlist to include appropriate package name for the and2 and or2 components so that one shouldn't right his own and2 and or2 vhdl file but uses the standard vhdl code? No, and it shouldn't really. You should rather include those desciptions from other schematics, given models from libraries or type them yourself. gschem/gnetlist allows you to interconnect things. You could even use it in a hierarchial fashion if you wish. Just include the VHDL files into your compilation and you will be fine. Cheers, Magnus ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: vhdl and gschem
From: Chitlesh GOORAH [EMAIL PROTECTED] Subject: gEDA-user: vhdl and gschem Date: Sun, 11 Feb 2007 20:03:47 +0100 Message-ID: [EMAIL PROTECTED] Hi! Hello thre, I'm trying to make a VHDL file from a mere simple half adder schematic: http://tux.u-strasbg.fr/~chit/half_adder/adder.sch with: gnetlist -g vhdl adder.sch -o output.vhdl http://tux.u-strasbg.fr/~chit/half_adder/output.vhdl However, I don't know how to create an entity with gschem. Can any one point how to make a simple one for my adder.sch ? In my actual output.vhdl, the entity is not found. See comment from Carlos Nieves Ónega. However, in general what you do want to do is to design in input and output You want to go into the VHDL symbol table and use ipad-1, opad-1 and iopad-1 which will map over to VHDL in, out and inout declarations of Std_Logic type. Assign the value of these to the name you want in the entity port declaration. There still isn't vectorization which would be nice in the long run. My second question about the vhdl and geda is how can I simulate that output.vhdl file with ghdl when the generated output.vhdl comes with: component 7408 or 7086 in my case. how can I make ghdl read those particular components as their respective entities and architecture (or, and)? Should I create those entities by myself or is it there something automated ? There is even those pre-rolled for your delight. Check out: http://www.freemodelfoundry.com/ Cheers, Magnus - guilty to the original VHDL backend which fortunatly have been maintained by others ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
