Hi! Ich wollte mal fragen, ob es eigentlich schon irgendwelche Aktivitäten gibt, mit den Erfahrungen der letzten Jahre mit VHDL, Verilog etc. eine neue Hardwarebeschreibungssprache zu entwickeln. So weit ich weiß wurde VHDL ja nicht unter dem Gesichtspunkt entwickelt, eine systhesefähige Beschreibungssprache zu sein. Vieles ließe sich vermutlich im Nachhinein besser gestalten. Es tauchen ja zum Beispiel in der Softwarewelt regelmäßig neue Programmiersprachen auf, mit neuen oder überarbeiteten Konzepten. Was tut sich denn neues in der Hardware-Sprachenwelt?
verilog wurde zur verification von logik entwickelt vhdl wurde extra zur hardwarebeschreibung entwickelt und wird auch weiterentwickelt z.B. VHDL-2008
Klaus schrieb: > Es tauchen ja zum Beispiel in der Softwarewelt regelmäßig neue > Programmiersprachen auf, mit neuen oder überarbeiteten Konzepten. Was > tut sich denn neues in der Hardware-Sprachenwelt? Die Hardwarebeschreibung selbst ist so ziemlich ausgereizt. Viel interessanter ist die Verifikation und in dem Bereich hat sich viel getan. Mit SystemVerilog wurde eine auf Verilog aufbauende Sprache geschaffen, die entsprechende Konstrukte beinhaltet: - Assertions als echte Sprachkomponente - Functional Coverage - Objektorientierung - Erzeugung von Zufallswerten (f. Objekte und Variablen) mithilfe eines Constraint Solvers - Methodiken, um die Wiederverwendung zu verbessern VHDL hat leider nicht den selben Rückhalt durch die Anwender und entwickelt sich daher langsamer. Gruß Marcus
> VHDL hat leider nicht den selben Rückhalt durch die Anwender VHDL ist akademischer Quatsch. Das überwiegend in Europa gelehrte VHDL ist der Grund, warum Europa bei der Chipentwicklung im Hintertreffen ist. Denn mit dem in den USA mehr genutzten VERILOG lässt sich besser sagen, was der Chip tun soll. Ist wie ALGOL68 vs. C, das eine ist eine akademische Sprache, die andere praktisch verwendbar. Alleine die typischen Missverständnisse beim Lehren von VHDL sind legendär. Ja, es ist Zeit für eine neue Hardwarebeschreibungssprache die für den Zweck geschaffen wurde und einfach und simpel ist, und damit übersichtlichlich und leicht beherrschbar. Nur kann die, im Gegensatz zu einer Programmiersprache, nicht einfach so ein Studi im Hinterzimmer bis zu der Serienreife bringen, mit der ein Chip entsteht. Je länger es sich hinauszögert, um so mehr IP entsteht in "falschen" Sprachen.
MaWin schrieb: > VHDL ist akademischer Quatsch. > > Das überwiegend in Europa gelehrte VHDL ist der Grund, warum Europa bei > der Chipentwicklung im Hintertreffen ist. selten so einen Quatsch gelesen Kest
MaWin schrieb: > VHDL ist akademischer Quatsch. Naja, da würde ich aber handfestere Argumente hören wollen... Es ist einfach so, dass Verilog mehr kann als die Synthesetools können, und VHDL sehr viel mehr kann, als je auf Hardware abgebildet werden könnte. > Denn mit dem in den USA mehr genutzten VERILOG lässt sich besser sagen, > was der Chip tun soll. Da würde ich aber bestenfalls einen Gleichstand erwarten. Nur ist VHDL ein wenig geschwätziger, dafür aber zum Glück sehr viel strenger bei der Typverwaltung. > Denn mit dem in den USA mehr genutzten VERILOG lässt sich besser sagen, > was der Chip tun soll. Könnte das nicht eher so sein, dass Verilog einfach nur einen leichteren Einstieg bietet, und daher die Hemmschwelle für die Amerikaner niedriger liegt? > Das überwiegend in Europa gelehrte VHDL ist der Grund, warum Europa bei > der Chipentwicklung im Hintertreffen ist. Ich möchte mal behaupten, dass auch aus den USA die letzte Zeit keine bahnbrechenden neuen Entwicklungen mehr gekommen sind...
MaWin schrieb: > Ist wie ALGOL68 vs. C, > das eine ist eine akademische Sprache, > die andere praktisch verwendbar. Wenn überhaupt ist das wie Ada und C.
> Wenn überhaupt ist das wie Ada und C. Wollte ich auch zuerst als Beispiel hernehmen, weil es syntaxmässig erst so erscheint aber ADA ist militärisch und damit gar nicht vergleichbar mit VHDL, ALGO68 passt besser zur akademischen Entstehungsgeschichte. > und VHDL sehr viel mehr kann, als je auf Hardware abgebildet werden > könnte. Ähnlich Algol68: Die Sprache hat man formuliert, einen Compiler für die ganze Sprache konnte man nicht bauen. > Nur ist VHDL ein wenig geschwätziger, dafür aber > zum Glück sehr viel strenger bei der Typverwaltung. VHDL erzwingt haufenweise inhaltlich eigentlich überflüssiger Statements, und verschleiert damit was eigentlich geleistet werden soll und macht es schwierig es zu erlernen. Künstlich aufgeblasen ohne Sinn und Verstand nur in Selbstverliebtheit. Akademisch heisst praktisch nicht verwendbar. > Könnte das nicht eher so sein, dass Verilog einfach nur > einen leichteren Einstieg bietet, und daher die Hemmschwelle > für die Amerikaner niedriger liegt? Sicher. Und ? > Ich möchte mal behaupten, dass auch aus den USA die letzte > Zeit keine bahnbrechenden neuen Entwicklungen mehr gekommen > sind Das meiste kommt inzwischen wohl aus Asien, auch mit VERILOG, nicht unbedingt bahnbrechend, aber die Leute kloppen ruck-zuck die Chips zusammen die man so braucht um günstig Massenartikel produzieren zu können, z.B. DSL-Router wo der Chip eine ganzes Linux-System integriert. Ich glaube aber, daß viele Grundlagen dazu aus den USA kommen, beispielsweise so was wie STBx25xx Digital Set-Top Box Integrated Controller. Und womit entstehen die wöchentlich neuen AVRs/PICs ?
Es wird wirklich langsam Zeit, das endlich natürlichsprachiges Deutsch als Hardwarebeschreibungssprache eingeführt wird! ;-) Warum? 1.) chip in Nullkraftfassung stecken 2.) Eingeben:
1 | "ich brauche ne anständige Abhöranlage |
2 | für Herrn Rieger, die selbstjustierend ist und den CCC |
3 | in allen Datenkanälen transparent macht" |
3.) Das Kompillat in den Chip brennen 4.) Freuen. Das ist Innovation! So macht FPGA Spass! die Troll-hanna.
Hallo *, vielleicht kommen wir nochmal zur Ausgangsfrage zurück. Ich zitiere: ... ob es eigentlich schon irgendwelche Aktivitäten gibt, mit den Erfahrungen der letzten Jahre mit VHDL, Verilog etc. eine neue Hardwarebeschreibungssprache zu entwickeln ... ... regelmäßig neue Programmiersprachen auf, mit neuen oder überarbeiteten Konzepten. Was tut sich denn neues in der Hardware-Sprachenwelt? Fakt ist, dass die beiden verbliebenen Sprachen zur Modellierung von Hardware nebeneinander her bestehen und auch weiter entwickelt werden. Ich persönlich finde das gut so. So hat meines Erachtens Verilog-2001 sehr von VHDL profitiert. Allein die Existenz der beiden Sprachen verhindert Stillstand. Stellt euch vor, es gäbe nur Xilinx. Oder nur Pepsi. Im übrigen schlage ich mich auf die Seite von Marcus: Die Hardwarebeschreibung selbst ist so ziemlich ausgereizt. Der Zauber liegt in der Erstellung/Benutzung fertiger Komponenten und in der Verifikation. Das hat mit der Sprache nichts zu tun, eher mit Entwurfsmethodik. Um die scheint es mit allerdings recht schlecht bestellt zu sein in der breiten Masse der FPGA-Desgner. Ich schätze den Anteil der FPGA-Designs, für die eine einigermaßen vollständige und selbstestende Testbench vorliegt, auf unter 25%. Ein Jammer! So wäre denn meine Antwort auf die Ausgangsfrage: Die existierenden Sprachen werden in gewissem Maß weiter entwickelt, ein komplett neuer Ansatz ist mir nicht bekannt, und ich persönlich halte ich auch nicht für nötig. Grüße, Harald
MaWin schrieb: > ADA ist militärisch und damit gar nicht > vergleichbar mit VHDL VHDL ist ein "militärisches" Produkt. Es wurde im Rahmen des VHSIC-Programms, gefördert durch das DoD entwickelt und basiert in der Tat auf Ada. MaWin schrieb: >> Könnte das nicht eher so sein, dass Verilog einfach nur >> einen leichteren Einstieg bietet, und daher die Hemmschwelle >> für die Amerikaner niedriger liegt? > > Sicher. Und ? Falsch. Zumindest historisch. Hinter Verilog standed schon immer Firmen. Der Entwickler von Verilog wurde dann von Cadence gekauft. Und die haben es dann mit Ihrer Marktmacht durchgedrückt. Das sieht man auch heute noch: die Cadence Tools unterstützen VHDL eher stiefmütterlich :-(
MaWin schrieb: >> Nur ist VHDL ein wenig geschwätziger, dafür aber >> zum Glück sehr viel strenger bei der Typverwaltung. > > VHDL erzwingt haufenweise inhaltlich eigentlich überflüssiger > Statements, und verschleiert damit was eigentlich geleistet > werden soll und macht es schwierig es zu erlernen. Künstlich > aufgeblasen ohne Sinn und Verstand nur in Selbstverliebtheit. Ach ja. Der Grund dafür liegt in der Anforderung für die Entwicklung von VHDL. Der Benutzer sollte gezwungen werden vernünftig lesbaren Code zu schreiben.
> Der Benutzer sollte gezwungen werden vernünftig lesbaren Code zu > schreiben. Tja ja, die Arroganz der überheblichen Akademiker eben. Die müssen ja nicht selbst damit produktiv sein, dafür hat man "Fussvolk". Die Akademiker glauben aber, dem dem Rest der Welt vorschreiben zu können, daß Baubeschreibungen in bester deutscher Lyrik in Versform, abzuliefern sind. So viel Arroganz geht halt in die Hose, hat man bei Algol68 (und Ada, falls jemand will) schon gesehen.
MaWin schrieb: >> Der Benutzer sollte gezwungen werden vernünftig lesbaren Code zu >> schreiben. > > Tja ja, die Arroganz der überheblichen Akademiker eben. > > Die müssen ja nicht selbst damit produktiv sein, > dafür hat man "Fussvolk". > > Die Akademiker glauben aber, dem dem Rest der Welt vorschreiben > zu können, > daß Baubeschreibungen in bester deutscher Lyrik in Versform, > abzuliefern sind. > > So viel Arroganz geht halt in die Hose, > hat man bei Algol68 (und Ada, falls jemand will) schon gesehen. Naja, an Arroganz kann man sich bei Dir auch ein Beispiel nehmen. Wieviel hast Du schon von der FPGA Welt gesehen, dass Du Dir so pauschale und unsinnige Urteile erlauben kannst?
Mathi schrieb: > Das sieht man auch heute noch: die Cadence Tools unterstützen VHDL eher > stiefmütterlich :-( Ich behaupte, dass die meisten Toolhersteller VHDL (im Vergleich zu Verilog) eher stiefmütterlich unterstützen. Ein ganz verständlicher, opportunistischer Ansatz, der sich in der Nachfrage begründet. Viele IP Blöcke werden heutzutage nur noch in Verilog angeboten. Ich sehe die Teilung in beide Welten übrigens heute nicht mehr vorranging in der Geografie. Vielmehr scheint sich die Trennlinie zwischen FPGA und ASIC zu befinden, wobei in letzterem Bereich hauptsächlich (System)Verilog eingesetzt wird. -- Marcus
Marcus Harnisch schrieb: > Ich behaupte, dass die meisten Toolhersteller VHDL (im Vergleich zu > Verilog) eher stiefmütterlich unterstützen. Ein ganz verständlicher, > opportunistischer Ansatz, der sich in der Nachfrage begründet. Viele IP > Blöcke werden heutzutage nur noch in Verilog angeboten. > > Ich sehe die Teilung in beide Welten übrigens heute nicht mehr > vorranging in der Geografie. Vielmehr scheint sich die Trennlinie > zwischen FPGA und ASIC zu befinden, wobei in letzterem Bereich > hauptsächlich (System)Verilog eingesetzt wird. hmmm, jetzt mal Stand von vor ca. 7 Jahren: Witzig, dass sowohl IBM als auch Intel einen auf VHDL machen... (IBM im Grossrechnerbereich, Intel im I/O-Chip Bereich, eigene Erfahrung...)
> Ich möchte mal behaupten, dass auch aus den USA die letzte Zeit keine > bahnbrechenden neuen Entwicklungen mehr gekommen sind... Da drängt sich doch die Frage auf, was verwenden den die Chinesen? Haben die bereits ihre "eigene VHDL" oder was?
Alfredo schrieb: > ihre "eigene VHDL" Das hieße dann nur HDL = Hardware Description Language. Verilog ist eine HDL, und VHDL ist ebenfalls eine HDL.
Moin, mir scheint, dass gerade in China noch ziemlich "low level" gearbeitet wird, meine Vermutung geht in Richtung VHDL. Ist halt ein Unterschied, wenn 10 gutdotierte VHDL-Programmierer fuer den Lohn eines Deutschen arbeiten. Zudem wird wohl viel an IP-Cores eingekauft oder einfach bei OpenCores gemopst und aufgebohrt, in punkto GPL nehmen es viele grosse Firmen ja nicht so genau. Die Diskussion Verilog vs VHDL ist IMHO relativ aehnlich sinnlos wie "Ist die Assemblersprache des PowerPC besser als i86?" Wer sich komplexere Sachen backen will und sich an der Geschwaetzigkeit von VHDL aufreibt, muss halt hingehen, und sich seine Synthese-Scripte selber entwickeln, oder sie einkaufen. Gibt schliesslich genug Nischenloesungen am Markt. Gerade bei Hardwaresprachen begruesse ich es eigentlich, dass sich die Low-Level-Sprache ueber die Jahre nicht allzu sehr aendert - auch wenn sie sich so 'besch....' liest wie Pascal (dafür gibt's bestimmt wieder Schelte). Gruesse, - Strubi
Der Streit erinnert mich an etwas da mach ich mal einen >Guttenberg< aus der Wikipedia zu: Big-Endian und Little-Endian - Etymologie: >Die Bezeichnungen gehen auf den satirischen Roman Gullivers Reisen von >Jonathan Swift zurück, in dem die Bewohner des Landes Liliput in zwei >verfeindeten Gruppen leben: Die einen schlagen ihre Eier am dicken, >„großen“, englisch „big“, Ende auf und werden deshalb als Big Ender >bezeichnet, während die Little Ender die Eier am spitzen, „kleinen“, >englisch „little“ Ende öffnen
für testbenches wird systemc gerne genutzt, zur beschreibung eines DUT während der mixed signal verifikation vermehrt vhdl-ams.. macht spaß beides :)
Kleiner Nachtrag (aus dem Blog eines EDA Herstallers): http://blogs.mentor.com/verificationhorizons/blog/2011/05/13/part-8-the-2010-wilson-research-group-functional-verification-study/ -- Marcus
http://myhdl.org Kurzfassung: Setzt Python-Code in vhdl oder verilog um, ob es taugt, k.A. Bin nur gerade drauf gestoßen und habe dann diesen Thread hier gelesen.
Ich versteh den Hype um myhdl nicht. Mal davon abgesehen, dass die API alles andere als stabil ist, ist das ganze eine ziemliche Python-Vergewaltigung. Die eine Hälfte des Codes wird wild "rumgecastet", damit Signale und die neuen Typen irgendwie in Python funktionieren. Dagegen sind die VHDL-Issues mit signed/integer/etc harmlos. Die andere Hälfte ist die Emulation der üblichen Simulationsmethoden (Erzeugung von "unterbrechbaren" Objekten und Aufruf der Objekte). No Sir, I don't like it...
It is true that MyHDL is an evolving language. What is wrong with that? Do you prefer the VHDL status quo? Anyway, calling it "anything but stable" is just not true. Backwards compatiblity is treated quite seriously. What is wrong with creating objects that work "somewhere in Python"? That's how Python is used, right? The question is whether such objects make sense. And I strongly believe MyHDL's intbv makes much more sense than VHDL's unsigned/signed. Finally, it is true that Python features are used to emulate typical hardware simulation semantics. Again, what is wrong with that? It means that MyHDL is pure Python package that works together with any other Python library. What HDL gives you such power? It's up to you what you like or don't like, but I don't find your arguments very impressive. Jan Decaluwe
My arguments are not supposed to impress anybody, they simply reflect my impressions about MyHDL. I don't think that it tackles the HW/model abstraction at the right point, but YMMV.
Ok. So after an alledged unstable API (wrong), critique on the use of Python objects (meaningless) and on the use of Python features to emulate hardware simulation (doubtful), now you come with one more "argument". It really seems you are shooting in the wild. MyHDL doesn't handle the gate level, but it handles the RTL and beyond very well. This is similar to VHDL and SystemVerilog, with the obvious difference that you have access to the power of a super high level general purpose language, and all of that for free.
Yep, I'm talking bullshit on purpose and MyHDL is the best thing that happened to mankind since sliced bread. OMG.
Georg A. schrieb: > Yep, I'm talking bullshit Correct. > on purpose I hope not. My guess is that it was just some cheap talk behind a perceived language barrier. > MyHDL is the best thing that > happened to mankind since sliced bread. Certainly not: it has several deficiencies (like anything man-made). But apparently you don't have a clue about where they really are. Until you do, please stop spreading FUD.
I'm a user of vhdl and python. The concept behind python is clear to me and the concept of vhdl is clear to me (after a steep learning curve). I like both languages. I take a look at myhdl a while ago, but I didn't see the concept. I got no approach to it... Duke
Klaus schrieb: > Jan Decaluwe schrieb: >> Until you >> do, please stop spreading FUD. > > Are you the invetor of myHDL? Yes.
Duke Scarring schrieb: > I'm a user of vhdl and python. The concept behind python is clear to me > and the concept of vhdl is clear to me (after a steep learning curve). > I like both languages. > > I take a look at myhdl a while ago, but I didn't see the concept. I got > no approach to it... That is fine. If you are happy with your design environment as it is, no need to worry about changing it. For the record: I am a big fan of VHDL. I have co-founded a VHDL design services company in 1991, and I am currently involved in a VHDL IDE startup (Sigasi). I owe a lot to VHDL professionally. My main problem with HDLs is not the languages, but the (low-level) way they are used. I see Verilog and its confusing foundations as the main culprit here. In that sense, MyHDL is an attempt to design an HDL which is "easy" to use like Verilog, but with strong foundations like VHDL. For example, MyHDL has delta-cycles, and a separate Signal concept.
Jan Decaluwe schrieb: > My main problem with HDLs is not the languages, but the (low-level) way > they are used. Ok. I use VHDL with records, functions and arrays for a high abstraction level. In my opinion, a higher abstraction level is possible with a kind of IP blocks with handshakes (for timing) and variable ports (for flexible data structures [that's what I use records for]). In a normal language there is no real timing behaviour on variables. But in hardware this is essential. Data signals can be used in parallel or sequential. And also some hardware units can be used in a mix of them (think on digital filters which work with much lower frequency than the system clock). > For example, MyHDL has delta-cycles, and a separate Signal concept. I honour your efforts, but it's necessary to put all these considerations above in a language/concept/whatever that is easy enough to understand so that it is employable. Duke
Duke Scarring schrieb: > Jan Decaluwe schrieb: >> My main problem with HDLs is not the languages, but the (low-level) way >> they are used. > Ok. I use VHDL with records, functions and arrays for a high abstraction > level. Excellent. However, in my experience designers like you are a small minority, which means that HDL design is not living up to its potential. Let me give you an example. The most important IP company is probably ARM. They use Verilog exclusively and they have a set of recommendations. One of these (take a seat) is that you shouldn't use 'if' statements in RTL code. http://infocenter.arm.com/help/topic/com.arm.doc.arp0009a/Verilog_X_Bugs.pdf Those are the kind of stupid ideas which are common in the HDL design world and that I'm fighting against in the first place.
Jan Decaluwe schrieb: > The most important IP company is probably ARM. They use Verilog > exclusively and they have a set of recommendations. One of these > (take a seat) is that you shouldn't use 'if' statements in RTL code. I don't know where you got this from. X-propagation (or rather the lack thereof) is a real issue. The guidelines merely suggest appropriate workarounds in different cases. There is no statement saying you shouldn't use if-statements at all. Since you are participating already, would you care sharing how MyHDL addresses this issue? In any case, the main obstacle preventing large scale deployment is that MyHDL has no backing by EDA vendors. As discussed earlier, even VHDL has a difficult stand. I am afraid that the entire argument in this thread about the quality of MyHDL (which I haven't looked into) is moot, since MyHDL will very likely be limited to a rather small niche for the forseeable future. It doesn't help, of course, that MyHDL is a one-man-show. Cheers Marcus
Marcus Harnisch schrieb: > Jan Decaluwe schrieb: >> The most important IP company is probably ARM. They use Verilog >> exclusively and they have a set of recommendations. One of these >> (take a seat) is that you shouldn't use 'if' statements in RTL code. > > I don't know where you got this from. X-propagation (or rather the > lack thereof) is a real issue. The guidelines merely suggest > appropriate workarounds in different cases. There is no statement > saying you shouldn't use if-statements at all. There sure is. It's recommendation 9. From the paper: """ Recommendation 9: Avoid using if statements, as they optimistically interpret X’s. Instead use ternary (i.e. conditional ?) operators or priority-encoded case statements """ I hope I don't need to convince you that the workarounds with ternary operators or case statements are completely inappropriate for well-written RTL at a decent level of abstraction. > Since you are participating already, would you care sharing how MyHDL > addresses this issue? My pleasure. X is essentially a gate-level abstraction. Even at that level, its value is rather doubtful. No one has ever observed it in real hardware. As minimum, there should have been a notX value that is the logical opposite of X. At the RTL level and higher (MyHDL's playground), X simply has no value and no place. That is what the authors of the ARM paper should have concluded instead of their absurd recommendation. It is also what VHDL desigers that are using boolean, integer and enumeration types in their RTL code understand very well. MyHDL is doing just fine without X.
Marcus Harnisch schrieb: > > In any case, the main obstacle preventing large scale deployment is > that MyHDL has no backing by EDA vendors. MyHDL is an open-source project. Most of its code is devoted to play well with existing standard flows (by conversion). Why would big EDA ever be interested? (i.e. what would they charge for?) More importantly, why would we need them? Big EDA is mainly talking to an ever decreasing number of ASIC designers (with lots of money to spend, that is true). That doesn't sound like "large scale deployment" to me. My vision for digital hardware design is agile design techniques on programmable platforms. Large scale deployment to me means FPGA designers today and more general embedded software designers in the future. If that doesn't happen, I'm not really interested. But if it does happen, I believe solutions like MyHDL are in a sense unavoidable. Large scale deployment will come from users that like the features and the price. Of course, if it happens, it will not be overnight. But I believe time and Gordon Moore are on our side. > I am afraid that the entire argument in this thread about the quality > of MyHDL (which I haven't looked into) is moot, For the record: regarding MyHDL I am very proud on the concept, reasonably satisfied with the interface, but not necessarily that proud on the current implementation. > since MyHDL will very > likely be limited to a rather small niche for the forseeable > future. It doesn't help, of course, that MyHDL is a one-man-show. That perception has come up a few times already and I used to be concerned about it. But thinking about it, is it really a problem? It seems to me that successful projects are often linked to one person, even when there are obviously a lot of others making significant contributions (like in the MyHDL project, thank you all!) Somehow it seems to give projects an identity.
Jan Decaluwe schrieb: > Marcus Harnisch schrieb: >> There is no statement saying you shouldn't use if-statements at >> all. > > There sure is. It's recommendation 9. From the paper: > > """ > Recommendation 9: Avoid using if statements, as they optimistically > interpret X’s. Instead use ternary (i.e. conditional ?) operators or > priority-encoded case statements > """ Which is just a condensed form of this more elaborate rationale
1 | 1. For if statements: |
2 | a) Never use if statements in combinatorial logic (use case or ternary ? instead) |
3 | b) Only use if statements for sequential elements (e.g. flip-flop with asynchronous reset) |
4 | c) Add X-checking assertions to a clock-gating enables in sequential |
5 | logic, e.g. if (enable) |
And other statements scattered across the document. > MyHDL is doing just fine without X. So you will end up with essentially a 2-state simulation? Sorry for my ignorance, but I have no time ATM to check out MyHDL. That is easy enough to get with VHDL, and more recently (only six years) with SystemVerilog. Some commercial simulators, such as VCS, provide switches to perform 2-state simulation. Not sure if this is always better, though. Easier, yes. Jan Decaluwe schrieb: > Why would big EDA ever be interested [in MyHDL]? That's my point. They wouldn't. > For the record: regarding MyHDL I am very proud on the concept, > reasonably satisfied with the interface, but not necessarily that > proud on the current implementation. I am sure there is a lot in it to to be proud of. And I had no intention to rain into your parade. Kindly Marcus
Marcus Harnisch schrieb: > Jan Decaluwe schrieb: >> Marcus Harnisch schrieb: >>> There is no statement saying you shouldn't use if-statements at >>> all. >> >> There sure is. It's recommendation 9. From the paper: >> >> """ >> Recommendation 9: Avoid using if statements, as they optimistically >> interpret X’s. Instead use ternary (i.e. conditional ?) operators or >> priority-encoded case statements >> """ > > Which is just a condensed form of this more elaborate rationale1. For if statements: > a) Never use if statements in combinatorial logic (use case or ternary ? instead) > b) Only use if statements for sequential elements (e.g. flip-flop with asynchronous reset) > c) Add X-checking assertions to a clock-gating enables in sequential > logic, e.g. if (enable) And that really means: don't use if statements to describe logic (either within a combinatorial or a sequential process.) I invite all VHDL designers, expecially those concerned with higher abstraction levels, to consider what such a rule would mean for their code. Morever, I repeat that if one takes this seriously, the logical consequence would be to ban types that don't model an initialized state, such as booleans, state enums and integers. Obviously such types interprete an initialized state (at the gate level after synthesis) optimistically! >> MyHDL is doing just fine without X. > > So you will end up with essentially a 2-state simulation? Sorry for my > ignorance, but I have no time ATM to check out MyHDL. As MyHDL is really not targetting the gate level, I never think about it like that. Objects have a number of states (finite for synthesizable logic) but not one that models the 'uninitialized' state. However, there is an object that reuses Python's 'None' value to model tristates.
Jan Decaluwe schrieb: > Morever, I repeat that if one takes this seriously, the logical > consequence > would be to ban types that don't model an initialized state, such as > booleans, state enums and integers. Obviously such types interprete > an initialized state (at the gate level after synthesis) optimistically! I meant "uninitialized state" here (2x), sorry for posting too fast.
Marcus Harnisch schrieb: > Jan Decaluwe schrieb: >> Why would big EDA ever be interested [in MyHDL]? > > That's my point. They wouldn't. Sorry, but your point was that the lack of backing by big EDA would be the main obstacle to large scale deployment. My point is that that will not matter. A good role model is matlab. It may be one of most popular "EDA" tools, yet that happened completely outside the scope of "big EDA". They started from a true general purpose tool (with an appropriate business model and price), and gradually add more domain-specific tools, e.g. for hardware design. Likewise, Python is a general purpose language that many companies may be using anyway. At some point, some (probably young and naive) hardware designer that likes Python may wonder why she can't stay in the Python environment for her design work. That is my target public. (I know that there are "big EDA" tools now that claim matlab support. But my point stays valid: that has certainly not been a factor for matlab's large scale adoption.)
I gave me a few days to think about a correct response to Jan's postings... > But apparently you don't have a clue about where they really are. Maybe. After 18 years FPGA-fiddling, 16 years of VHDL and some 10k units of my FPGA designs in the consumer market it really looks like I'm unable to grasp what the intentions and (dis)advantages of MyHDL are. > Until you do, please stop spreading FUD. Before your arrogant posting, I simply ignored MyHDL based on my experiences (and they were in my first posting, I struggled with a changed API while working on some 3rd-party MyHDL-code, and wondered about the integer and simulation handling). But I guess it's now time to start some real FUD. I will begin in the next weeks, ~200 students are waiting to hear something about HDLs. EOD for me.
Georg A. schrieb: > I gave me a few days to think about a correct response to Jan's > postings... > >> But apparently you don't have a clue about where they really are. > > Maybe. After 18 years FPGA-fiddling, 16 years of VHDL and some 10k units > of my FPGA designs in the consumer market it really looks like I'm > unable to grasp what the intentions and (dis)advantages of MyHDL are. That is possible, but I certainly have not said that or meant to say it. I have merely complained about the lack of arguments and facts (I still do), and suggested to try a little harder before making judgements. >> Until you do, please stop spreading FUD. > > Before your arrogant posting, I simply ignored MyHDL based on my > experiences (and they were in my first posting, I struggled with a > changed API while working on some 3rd-party MyHDL-code, and wondered > about the integer and simulation handling). Next time, consider asking help on the MyHDL newsgroup. Some initial struggling is natural with anything worth learning. You didn't learn VHDL overnight either. > But I guess it's now time to start some real FUD. I will begin in the > next weeks, ~200 students are waiting to hear something about HDLs. So you are going to use your position as an educator to spread FUD among your students. That's definitely an interesting interpretation of a "correct response". Thanks, but I'll stick to my own standards: back up strong claims with arguments or facts, don't use argumentation from authority, and reveal my full identity. > EOD for me. According to my standards, there never was a discussion in the first place.
Georg A. schrieb: > Before your arrogant posting, I simply ignored MyHDL based on my > experiences (and they were in my first posting, I struggled with a > changed API while working on some 3rd-party MyHDL-code, and wondered > about the integer and simulation handling). Coming back to the subject of changed APIs, I would like to dispute the fact that they are inherently bad, as is being suggested here. Within reason, an API change may be a good sign, indicating that the language designers are willing to improve things or fix problems. The problem then is with the people are not willing to stay current. Let me give an extreme example from the VHDL world. Some 20 years ago, a vendor committed a crime against VHDL by compiling its proprietary std_logic_arith package into the IEEE library, creating the illusion of a standard package. Of course, due to vendor games, incompatible versions of that package popped up, creating an enormous confusion. Finally, in 1995, the problem was fixed when the IEEE standardized numeric_std, a package with the different interface. Obviously, the change was for the better, even absolutely necessary, and everyone should have adopted it immediately. However, to this day, 16 (sixteen!) years later, many VHDL teachers still use the old package in their courses and course material. They are either too lazy to make the change, or too incompetent to understand why it is necessary. And we, practicing VHDL engineers, continually have to clean up the mess behind them. http://stackoverflow.com/questions/6155675/when-should-i-use-std-logic-vector-and-when-should-i-use-other-data-types Jan
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.