Wieder einmal ein Xilinx V5 Design auf V6 umgestellt und dabei alles, aber auch alles neu bauen müssen, weil die Cores nicht fehlerfrei upgraden, bzw auf V6 umzustellen sind und obendrein noch 2 Toolversionen hinzukamen: Mitsamt der Umstellung von 12.4 auf 14.4 habe ich das design nunr 1,5mal gebaut zu dem damals bereits bestehenden. Die Firma hat also einen Migrationsaufwand zu höheren Chips (die den Toolsrpung leider zwanghaft erfordern) von 150%, statt vielleicht 20%, wenn es alles automatisch ginge, wie Xilinx das ja gerne behauptet. Frage 1 an die FPGA-Mannen: Kann/Darf man angesichts solcher Aufwände überhaupt noch mit X arbeiten? - WWie sieht das bei Vivado aus, wer kann da etwas zu sagen? Ich überlege, zu empfehlen, die komplette Platform zu wechseln und auf einen anderen Chip-Hersteller zu gehen, mitsamt seiner tools versteht sich. Frage2: Ist das bei Lattice etwas Entspannter, oder gebe ich mich da falschen Hoffnungen hin? Bitte keine Hinweise darauf, dass bei X angeblich die Cips besser sind. Sollte das der FAll sein, was ich bezweifle, käme Migration natürlich nur dort in Frage, wo es technisch ginge. Es wäre aber schon eine enorme Hilfe, wenn man Designs (und wir haben hier an die 100 zum pflegen1!!!) auf Dauer mit weniger Aufwand und Kosten auf neue Plattformen integrieren könnte.
Weltbester FPGA Pongo schrieb im Beitrag #3102540: > - WWie sieht das bei Vivado aus, wer kann da etwas zu sagen? Nenne mir einen Grund, warum es einfacher oder besser werden sollte, als es jetzt mit ISE ist? > Ich > überlege, zu empfehlen, die komplette Platform zu wechseln und auf einen > anderen Chip-Hersteller zu gehen, mitsamt seiner tools versteht sich. Ich würde erstmal mit anderen Herstellern Erfahrung sammeln wollen, bevor ich so eine Empfehlung abgebe... > Frage2: Ist das bei Lattice etwas Entspannter, oder gebe ich mich da > falschen Hoffnungen hin? Alle Hesteller kochen mit Was^W Silizium & Software. Sicher mag das eine oder andere Detail besser gelöst sein, aber 100% Fehlerfrei?! Das wird es nirgendwo geben. > Es wäre aber schon eine enorme Hilfe, wenn man Designs (und wir haben > hier an die 100 zum pflegen1!!!) auf Dauer mit weniger Aufwand und > Kosten auf neue Plattformen integrieren könnte. Verwendet weniger bis keine IP-Cores und keinen Microblaze. Allgemeiner VHDL-Code läßt sich wesentlich leichter portieren. Auch zwischen verschiedenen Herstellern. Wenn Ihr um die 100 Designs habt, hätte ich mir schon lange mal die Töchter der anderen Mütter angeschaut... Duke
Moin, ich fahre gerade zweigleisig mit Spartan6(Xilinx) und ECP3(Lattice), auf letzeren habe ich den Code im Zuge portiert. Muss sagen, dass ich vor der Migration viel mehr Schiss hatte als nötig. Im Endeffekt lief es sehr "smooth", allerdings auch, weil ich mich zur architekturunabhängigen modularen Entwicklung gezwungen hatte. Ich fasse mal kurz ein paar Knackpunkte lose zusammen: - ECP3: JTAG ist nicht ausreichend dokumentiert, teils scheint der Lattice-eigene Code fehlerhaft (nicht ganz konform zur Norm). Beim Spartan6 deutlich besser gelöst. - Spartan6 hat DDR-Core, ECP3 nur als $$-SoftIP - Toolchain bis Sp6-LX75 kostenlos, ECP3 benötigt Lizenz - Timingkontrolle bei Xilinx etwas 'logischer' bzw. offensichtlicher - generisch programmierte 2-clock-Domain-FIFOs liefen auf Lattice nicht sauber, IPExpress-Core nötig. - Tools unter Diamond 2.0 routen manche asynchrone Signale etwas merkwürdig, denken z.B., es sei ein globaler Reset. Muss man explizit definieren. - Support: Zwischen X und L schenkt sich da nix. Scheint alles outgesourct und nur auf FAQ gebucht.. Im grossen Ganzen bin ich mit der Lattice-Toolchain sehr zufrieden, läuft unter Linux deutlich besser als ISE. Allerdings verbrät sowohl ISE als auch Diamond sinnlos Rechenzeit für die Anzeige "Ich arbeite gerade". Macht also Sinn, die Tools per "Make" aufzurufen. Was allerdings eher mühsam zu verwenden ist, ist der mico32. Es wird zwar eine 64-Bit-Toolchain für Linux angeboten, die hat allerdings derart viele 32-bit-Abhängigkeiten, dass sie 'from the box' kaum zu verwenden ist. Flog erst mal in die Ecke. Die Wartung im offiziellen gcc-Tree scheint dürftig, einen aktuellen GCC für dem lm-32-Target zu compilieren, schlägt fürchterlich fehl (Compiler Bug). Im Endeffekt kommst Du um einen Test-Run mit einem Evalboard nicht rum, gerade wenn du von der Virtex-Klasse umsteigst. Soweit ich das sehe, gibt es bei den Boliden am oberen Ende nichts vergleichbares beim grossen L. Sicher ein grosser Knackpunkt ist, ob Du mit VHDL, Verilog, oder gar vermischt arbeitest. Bei X scheint mir der VHDL-Support spezifischer Black-Box-Entities für externe Simulatoren etwas besser. Nu, soweit meine 50 Cent an Senf, frohe Ostern, - Strubi
Also IP Cores von einer Architektur zu einer anderen rüberretten ohne neu anzulegen ging bei Xilinx noch nie. Wo steht denn dass das gehen soll? Da ist zuviel spezifisches drin. Ansonsten hab ich eigentich seit der Umstellung auf die XML Projekt-Files keine größeren Abstürze mehr erlebt, die ein Neu-Aufbauen des Projektes erfordert hätten. Von einem großen Mehraufwand kann ich nicht berichten. Sorgenkind ist bei mir lediglich iMPACT, das hat in jeder Version wieder neue lustige Bugs, aber durch xc3sprog o.ä. kann man da mittlerweile viel umgehen.
Ja das ist alles ein Krankheit und jeder macht ein Zauberei drum. Die Skripte im Hintergrund blähen sich auf und alte Funktion gehen einfach nicht mehr. Alles in einer Entwicklungssoftware für Hightech Produkte. Lattice hatte ich mal und da lief die Lizenz nach einem Jahr aus. Weiss nicht ob die Lizenzen noch zeitlich beschränkt sind,es war lästig. Auch wenn du mal ein Praktikanten hast, braucht der auch eine Lizenz und es wird auch schon wieder kompliziert. Du musst lernen mit mehr VHDL generic Code und nicht den IP Core zu benutzen. Ich habe bis hin zum Softcore alles in VHDL und bin so flexibeler und auch ohne Schmerzen. Auch für die Simulation nehme ich GHDL und so bin hier aus dem Herstellerzwängen.
Lattice und Xilinx decken nicht das gleiche Markt Segment ab. Insbesondere für den Virtex gibt es bei Lattice z.Z. keine Alternative. Umgekehrt gibt es für MachXO2 und ICE40 bei Xilinx keine Alternative. Portierung von Cores auf eine andere Familie geht auch bei Lattice ohne Neugenerierung auch nicht so ohne weiteres, z.B. unterscheidet sich die PLL zwischen MachXO2 und ECP3 erheblich. Für Upgrade vom z.B. ECP2M auf ECP3 gibt es für den ECP3 extra rückwärts kompatible Primitiven, wie gut das funktioniert weiss ich aber nicht. Strubi schrieb: > > - ECP3: JTAG ist nicht ausreichend dokumentiert, teils scheint der > Lattice-eigene Code fehlerhaft (nicht ganz konform zur Norm). Beim > Spartan6 deutlich besser gelöst. Da interresiert mich, in welcher Beziehung meinst du das, Programming, Boundary Scan oder Benutzung von JTAG in der eigenen Logik? > - Spartan6 hat DDR-Core, ECP3 nur als $$-SoftIP Stimmt. Wobei SoftIP auch Vorteile hat, man kann Bugts fixen, bzw gefixt bekommen. Lattice $$-Cores haben ein Eval Feature das erlaubt dass das Design mindestens 4 Stunden läüft, meiner Erfahrung sogaer 8-10 Stunden. > - Toolchain bis Sp6-LX75 kostenlos, ECP3 benötigt Lizenz Lizenz Politik ist halt eine andere. Es gibt gute Argumente für beide Varianten. > - Timingkontrolle bei Xilinx etwas 'logischer' bzw. offensichtlicher Ist das nicht Gewohnheitsfrage? > - Tools unter Diamond 2.0 routen manche asynchrone Signale etwas > merkwürdig, denken z.B., es sei ein globaler Reset. Muss man explizit > definieren. Was auch lästig ist, ist das unmotivierte und inkonsistente Umtaufen von Clocksignalen durch Synplify Pro. > - Support: Zwischen X und L schenkt sich da nix. Scheint alles > outgesourct und nur auf FAQ gebucht.. Xilinx hat ein aktives Forum, das Forum bei Lattice ist arg verwaist, und wird in 4 Wochen auch eingestellt.
Lattice User schrieb: > Strubi schrieb: >> >> - ECP3: JTAG ist nicht ausreichend dokumentiert, teils scheint der >> Lattice-eigene Code fehlerhaft (nicht ganz konform zur Norm). Beim >> Spartan6 deutlich besser gelöst. > > Da interresiert mich, in welcher Beziehung meinst du das, Programming, > Boundary Scan oder Benutzung von JTAG in der eigenen Logik? Irgendwo habe ich hier mal dazu was gepostet. Geht insbesondere um die Anbindung von eigener Logik per User-Instructions. Nach etwas Chip-Scoping die Erkenntnis: -- Attention: It was assumed that itdi is identical with the TDI pin -- of the JTAGE primitive (i.e. routed directly from the package tdi -- pin to jtdi). This does not appear to be the case. See: -- * tdi.png: Data valid on falling edge (TDI output from FTDI) -- * jtdi.png: Data valid on rising edge (jtdi routed to output via itdi) -- Conclusion: TDI is sampled on the rising edge to the jtdi output. Ähnlich mit dem internen TDO-Signal. Somit ist ein selbst implementiertes Register in der internen Scan-Chain (DR) u.U. in der Detektion genau ein Bit grösser, oder ein Bit geht beim Schieben verschütt, wenn man es 'blind' nach Doku implementiert. So wie die Debugregister z.B. beim mico32 angebunden sind, funktioniert das so implementierte Schieberegister nicht richtig, d.h. beim Durchschieben der Bits nach JTAG-Standard wird eins verschluckt. Heisst, man kann einen mico32 nicht in der Kette zusammen mit einem zweiten Chip (also echtem Silicon, nicht interner Core) sauber betreiben/debuggen. Habe sowohl im mico32-Code wie auch Orcastra-Backend keine korrekte Lösung gefunden (aber vielleicht war ich auch einfach nur selber doof). Man kann es allerdings richtig implementieren, aber nur mit extra-Klimmzügen, die ansich unsinnig wären (Bei Spartan6 haben sie ENDLICH mal was nachgedacht und so ein paar alte Schönheitsfehler behoben). Leider alles nicht dokumentiert und dem Tech-Support von Lattice scheint das Problem nicht bewusst. In den meisten Fällen wird man nicht mehrere Chips in der Chain hängen haben, somit tritt das Problem nicht auf. Ansonsten ist am JTAG-Port nichts auszusetzen, ist wie gesagt nur das kleine blöde Implementationsdetail bei der standardkonformen Anbindung von eigenen Schieberegistern. Grüsse, - Strubi
Hi René, René D. schrieb: > > Du musst lernen mit mehr VHDL generic Code und nicht den IP Core zu > benutzen. Ich habe bis hin zum Softcore alles in VHDL und bin so > flexibeler und auch ohne Schmerzen. > > Auch für die Simulation nehme ich GHDL und so bin hier aus dem > Herstellerzwängen. Noch ein guter Punkt: Mit GHDL kann man teils die Xilinx-Primitiven simulieren, bei den Lattice Blackbox-Entities geht da gar nix (encrypted Verilog). Noch zum Thema IP: Einige handgestrickte fiese asynchronen Geschichten (wie 2-clockdomain-FIFOs) laufen bei Xilinx tadellos, während sie bei Lattice nur zu 99.999% tun. Sehr sehr böse, und ich habe den Knackpunkt bei der Synthese dazu noch nicht eruiert. Fazit: Ohne IP-Cores gings in der Beziehung nicht. Hat mich ne Woche gekostet...:-(
Strubi schrieb: > Lattice User schrieb: >> Strubi schrieb: >>> >>> - ECP3: JTAG ist nicht ausreichend dokumentiert, teils scheint der >>> Lattice-eigene Code fehlerhaft (nicht ganz konform zur Norm). Beim >>> Spartan6 deutlich besser gelöst. >> >> Da interresiert mich, in welcher Beziehung meinst du das, Programming, >> Boundary Scan oder Benutzung von JTAG in der eigenen Logik? > > Irgendwo habe ich hier mal dazu was gepostet. Geht insbesondere um die > Anbindung von eigener Logik per User-Instructions. Nach etwas > Chip-Scoping die Erkenntnis: > Ah, also um die jtagconn16 Komponente. Ja, das lässt zu wünschen übrig. > Noch ein guter Punkt: Mit GHDL kann man teils die Xilinx-Primitiven > simulieren, bei den Lattice Blackbox-Entities geht da gar nix (encrypted > Verilog). In "C:\lscc\diamond\2.1\cae_library\simulation\vhdl\ecp3\src" ist nichts encrypted.
Strubi schrieb: > Noch ein guter Punkt: Mit GHDL kann man teils die Xilinx-Primitiven > simulieren, bei den Lattice Blackbox-Entities geht da gar nix (encrypted > Verilog). Auf den Stuss sind sie aber beim X auch umgestiegen. Ohne Encrypted Verilog geht bei MGT, PCIe usw. auch gar nix mehr. Da braucht man gleich mal wieder die teure ModelSim Variante wenn man den ISim Schrott nicht nehmen will.
Duke Scarring schrieb: > Nenne mir einen Grund, warum es einfacher oder besser werden sollte, als > es jetzt mit ISE ist? Die Firma Xilinx könnte entschieden haben, mehr Qualität in ihre Produkte zu bringen. Oder Vivado wird von einer neuen Programmierertruppe gemacht, bzw einer anderen, als die, die ISE machen. Duke Scarring schrieb: > Wenn Ihr um die 100 Designs habt, hätte ich mir schon lange mal die > Töchter der anderen Mütter angeschaut... Ich bin nicht von Anfang an dabei gewesen und die, die es zu entscheiden hatten, haben über die Jahre alle gewechselt. Problem: Der Schritt zu einem anderen Hersteller wird mit steigender Zahl der Designs immer grösser. Also frisst man das, was man immer gefressen hat, wobei wir durchaus auch Altera-Designs haben, nämlich die, die von anderen Gruppen mal mit Altera entwickelt wurden und die man der Abteilung aufs Auge gedrückt hat. Diesbezüglich gibt es im Übrigen immer mal wieder Versuche, alles auf einen Hersteller umzustellen, aber die Migrationsaufwandsabschätzungen führen immer wieder zu einem Doppel-Nein! :-) Duke Scarring schrieb: > Ich würde erstmal mit anderen Herstellern Erfahrung sammeln wollen, > bevor ich so eine Empfehlung abgebe... Deshalb frage ich ja. Ich möchte aber nur Dinge versuchen, die Aussicht auf Erfolg haben. Nachdem, was ich hier lese, ist der Versuch, mal in Lattice zu machen nicht so erfolgversprechend. Christian R. schrieb: > Also IP Cores von einer Architektur zu einer anderen rüberretten ohne > neu anzulegen ging bei Xilinx noch nie. Nun, viele IP Cores unterscheiden sich im Script kaum und es ist ja das script allein, dass die SYN steuert. Die eine Steueranweisung in die andere zu übersetzen, sollte machbar sein - manuell geht es ja auch! Zudem darf man wenigstens erwarten, dass man nicht alles neu bauen muss, nur weil ich die ISE hochgehe, und der Chip derselbe bleibt. Das ist das Grösste Ärgernis! >encrypted VHDL Genau das ist der Punkt, so langsam die Weichen zu stellen. Ich brauche möglichst viel natives VHDL. Beim X wird immer mehr spezifisches produziert.
Weltbester FPGA Pongo schrieb im Beitrag #3103786: > Zudem darf man wenigstens erwarten, dass man nicht alles neu bauen muss, > nur weil ich die ISE hochgehe, und der Chip derselbe bleibt. Das ist das > Grösste Ärgernis! Das hat bei mir bisher problemlos geklappt. Manche Cores darf man halt nicht updaten, das sagt der CoreGen aber vorher an. So wird z.B. der FIR Compiler ohne AXI nicht mehr weiter entwickelt. Aber sonst geht das schon. Bei den encrypted VHDL gehts eher um die Modelle für die aufwenigen IP Cores wie MGT und PCIe, da wollen die ja auch nicht allzu viel offenlegen, das kann ich nachvollziehen, aber gibts sowas nicht für VHDL auch? Modelsim ist gleich um einiges teurer mit dual language. Vivado oder ISE macht keinen Unterschied. Vivado kennt nur die 7er Serie und arbeitet im Hintergrund doch mit den selben Tools. Die IDE ist auch nicht entscheidend besser, die verweigern sich weiterhin komplett jeglicher Versionskontrolle und einen gescheiten Editor gibts auch im Vivado nicht. Von Autovervollständigung haben die offenbar noch nie was gehört. Scheint Teulfelszeug zu sein. Und immer einen externen Editor nehmen, nervt auf Dauer auch, gerade wenn man das Design erst mal lokal aufsetzt und noch viel am Projekt selbst ändert. Ich hab mal Eclipse + Veditor getestet, aber das ist auch sehr buggy, der Typ der das hauptsächlich macht, hat aber für VHDL auch wenig übrig. Notepad++ geht sowerit ganz gut, aber eine native Integration in ISE wäre ja wirklich nicht zuviel verlangt, andere können das auch.
Christian R. schrieb: > Modelsim ist gleich um einiges teurer mit dual language. > Das ist natürlich ein Punkt für Lattice. Die in Diamond enthaltene Version von ActiveHDL (Aldec) hat mixed language support freiscgeschaltet. AcitiveHDL gibts aber leider nur für Windows.
Naja, Isim kann das auch, aber dafür z.B. keine Analog-Darstellung.
Christian R. schrieb: > Naja, Isim kann das auch, aber dafür z.B. keine Analog-Darstellung. Die Lattice Version von ActiveHDL kann das. Jedem fehlt etwas: ModelSim: Kein mixed language support Isim: Keine Analogdarstellung ActiveHDL: Kein Linux support Es sind lauter kleine Details, und as was fehlt ist natürlich immer das Ausschlusskriterium wenns um den Umstieg geht.
Lattice User schrieb: > ModelSim: Kein mixed language support Du meinst, nicht, ohne Extra Lizenz, oder? ModelSIM kann das durchaus, mit gewrapptem Verilog sogar ganz easy.
Weltbester FPGA Pongo schrieb im Beitrag #3104078: > Lattice User schrieb: >> ModelSim: Kein mixed language support > Du meinst, nicht, ohne Extra Lizenz, oder? > Ja das meine ich.
Lattice User schrieb: > Jedem fehlt etwas: > ModelSim: Kein mixed language support > Isim: Keine Analogdarstellung > ActiveHDL: Kein Linux support XSim (Vivado-Ersatz für ISIM) hat Analogdarstellung
Hier noch ein bisschen Senf von meiner Seite dazu. Letzte Arbeit war mit Xilinx, jetzt mache ich Designs für die Industrie mit Lattice. Externer Editor ist bei allen nötig, auch die Editoren in Active-HDL und Synplify sind nicht das, was man länger benutzen möchte. Für VHDL, und nur darüber kann ich urteilen, kann ich jedem Emacs empfehlen. Emacs braucht seine Eingewöhnung aber der VHDL Modus ist das Wert. (Hat hier jemand Erfahrung mit Emacs und Sigasi? Vergleich?) Der Vergleich mit der Lizenz Lattice/Xilinx hinkt aus der Logik von Lattice: Die Lizenz wird benötigt für Bausteine mit SERDES (z. B. ECP3), der 6-LX bringt keine SERDES mit... Ja, die Lattice Lizenzen laufen nach einem Jahr ab, das nervt mich auch. Mündliche Aussage eines FAEs vom Distributor: "Wenn sie die Lattice Tools lizenzieren und Linux einsetzen möchten, dann können wir ihnen einfach den Riviera geben". Bei Arbeit gibts leider kein Linux, konnte seine Aussage also noch nicht in die Waagschale werfen. Wer möchte es ausprobieren? :-) Aus meiner Sicht ein Vorteil ist, dass ich mit Synplify und Active-HDL arbeiten kann, anstatt diesen selbstgemachten Tools, man merkt einfach das die Leute diese Software verkaufen und entsprechend den Kunden auch etwas bieten müssen. -> Beide Tools unterstützen vorbehaltlos VHDL2008, hilft natürlich auch beim Generisch halten. Aber ein Umstieg auf Xilinx geht dann nicht mehr. Das Xilinx Forum ist voll von Leuten die gerne VHDL2008 hätten... Leider scheint sich da nicht viel zu tun. Gerade Xilinx mit ihren dicken Eisen täte gut daran den Designer zu unterstützen grosse Designs handhabbar zu machen, da gehört VHDL2008 dazu... Der Support von Lattice ist brauchbar. Das Forum kann man vergessen, typischen Beispiel von "wir haben jetzt auch" ohne das sich jemand drum kümmert. Für mich nur schlechte PR. Der Lattice Techsupport per E-Mail funktioniert gut. Manchmal muss ich das denen zwei mal erklären aber sie antworten schnell und bleiben dran. Die FAEs kann ich noch nicht beurteilen. Wie schon sehr richtig geschrieben wurde, Lattice und Xilinx haben andere Zielkunden. Für meine jetzige Firma ist Lattice genau richtig, da wären die grossen A oder X Chips fehlplaziert. Ist aber ein sehr wichtiger Punkt zu beachten, bei der Hersteller und Tool auswahl. Sieht man auch sehr schön, Lattice hat den ECP4 wieder zurückgezogen. "Vermutlich mangels Interesse von Kunden" hat mir ein Verkäufter gesagt. Dafür gibts dann so lustige Sachen wie den 4 mm x 4 mm kleinen MachXO2 mit 1200 4-LUTs, passt perfekt zum neuen Kinetis Cortex-M0 mit 3 mm x 3 mm Gehäuse. Sowas passt auch in ein Hörgerät (Als Gedankenexperiment, Stromverbrauch ist ja auch ein Thema). Die Vorteile von Xilinx sind natürlich dass die Firma viel grösser ist, mit den Process Nodes immer viel tiefer ist und du viel mehr Leute findest die schon mit Xilinx Erfahrung gesammelt haben (Ich habe mich sehr schnell eingewöhnt, denke ein umstieg auf A wäre auch nur eine kurze Sache).
Christoph schrieb: > Der Vergleich mit der Lizenz Lattice/Xilinx hinkt aus der Logik von > Lattice: > Die Lizenz wird benötigt für Bausteine mit SERDES (z. B. ECP3), der 6-LX > bringt keine SERDES mit... Die kleinen Spartaner (T am Ende) mit den Serdes laufen aber auch alle mit dem ISE Webpack soweit ich weiss (noch nicht probiert).
Christoph schrieb: >Beide Tools unterstützen vorbehaltlos VHDL2008, hilft natürlich auch >beim Generisch halten Ja schon, aber Reveal unterstützt es nicht ;-)
Christoph schrieb: > Mündliche Aussage eines FAEs vom Distributor: "Wenn sie die Lattice > Tools lizenzieren und Linux einsetzen möchten, dann können wir ihnen > einfach den Riviera geben". > Bei Arbeit gibts leider kein Linux, konnte seine Aussage also noch nicht > in die Waagschale werfen. Wer möchte es ausprobieren? :-) > > > > Der Support von Lattice ist brauchbar. Das Forum kann man vergessen, > typischen Beispiel von "wir haben jetzt auch" ohne das sich jemand drum > kümmert. Für mich nur schlechte PR. Das Forum war ja eher ein schlechter Ersatz für eine Knowledgebase und eine KnowIssue Liste. Ansonsten tote Hose. Wird jetzt auch am 1. Mai geschlossen. > > Dafür gibts dann so lustige Sachen wie den 4 mm x 4 mm kleinen MachXO2 > mit 1200 4-LUTs Must du nochmal hingucken, der hat 2.5 x 2.5 mm (25 Balls, 0.4 mm Abstand) :-)
Auch wenn Lizenzkosten im Profesionellen Umfeld kein Hauptentscheidungsgrund sein sollte... Lattice hat gerade wieder einen Promoaktion: 99€ für so ziemlich alles.. IP's, IP Suites und Diamond Vollversion. Was kostet die Vivadio z.Z. ? Cheers
Achso: ChipScope kostet doch immernoch extra, oder? Reveal (Lattice) ist for free.
SuperWilly schrieb: > Christoph schrieb: >>Beide Tools unterstützen vorbehaltlos VHDL2008, hilft natürlich auch >>beim Generisch halten > > Ja schon, aber Reveal unterstützt es nicht ;-) Die anderen Lattice Tools vermutlich auch nicht. Ich habe gestern mal SystemVerilog ausprobiert, Designflow als solcher klappt wunderbar, aber z.B. der SimulationWizard mag es nicht. Reveal habe ich schon seit längeren nicht mehr nötig gehabt, das wäre als kein Hinderungsgrund für mich.
Christoph schrieb: > Ja, die Lattice Lizenzen laufen nach einem Jahr ab, das nervt mich auch. Geht das tool dann gar nicht mehr? Bei Xilinx läuft ja das tool ab und ChipScope fällt aus, weiterbauen kann man schon.
AFAIK kann man nur keine neuen Projekte mehr anfangen. ISt mir aber noch nicht passiert, im Gegenteil, meine letzten Diamond-Lizenzen sind beim Kauf von IP Cores einfach so mitverlängert worden ;-) , waum auch immer... Gruß
>Reveal habe ich schon seit längeren nicht mehr nötig gehabt, das wäre >als kein Hinderungsgrund für mich. Verwendest Du beim Debugging die Methode des scharfen Hinsehens? :-)
Lattice User schrieb: > SuperWilly schrieb: >> Christoph schrieb: >>>Beide Tools unterstützen vorbehaltlos VHDL2008, hilft natürlich auch >>>beim Generisch halten >> >> Ja schon, aber Reveal unterstützt es nicht ;-) > > Die anderen Lattice Tools vermutlich auch nicht. Ich habe gestern mal > SystemVerilog ausprobiert, Designflow als solcher klappt wunderbar, aber > z.B. der SimulationWizard mag es nicht. > > Reveal habe ich schon seit längeren nicht mehr nötig gehabt, das wäre > als kein Hinderungsgrund für mich. Ja, das ist so. Die Hirarchieanzeige etc. im Diamond kann mit VHDL2008 nicht umgehen. Ist mir egal, der ganze Designflow klappt. Habe Lattice auch schon mal darauf angesprochen und der Supporter sagt, die Software Leute arbeiten daran. Mal sehen ob das wirklich mal kommt. Lattice User schrieb: >> Dafür gibts dann so lustige Sachen wie den 4 mm x 4 mm kleinen MachXO2 >> mit 1200 4-LUTs > Must du nochmal hingucken, der hat 2.5 x 2.5 mm (25 Balls, 0.4 mm > Abstand) :-) Habe ich aus dem Kopf heraus geschrieben :-) Ich finds vorallem erstaunlich, dass dieser winzling immer noch 1280 4-LUTs und 64 kbit Blockram hat. Der Mikrocontroller ist auch etwas kleiner: Kinetis KL02 chip-scale package (CSP) 1.9 mm x 2.0 mm (20 Balls) Auf meinen Daumennagel würde ich so 4 MCUs und 4 FPGAs unterbringen :-)
> Ich brauche möglichst viel natives VHDL. Beim X wird immer mehr > spezifisches produziert. Das ist in der Tat ein Problem. Eigentlich waren Verilog und VHDL ja dazu gedacht, herstellerunabhängige Hardwarestrukturen und Funktionen zu beschreiben, doch der Wind hat sich gdreht: Die Hersteller sind offenbar immer mehr bemüht, ihren Code gezielt zu "entuniversalisieren", um die Kundenbindung voranzutreiben und die Portierung zu verhindern. Den dicksten Hund, der mir in diesem Zusammenhang begegnet ist, ist das Verhalten des System Generators aus MATLAB Simulink heraus: Anstatt bei einer einfachen Signalverarbeitungskette einfach mittels numeric.std längst implementierte Grundfunktionen wie "+", "-", und "*" zu verwenden oder wenigstens standard Vektoroperationen zu generieren, werden ausdrückliche virtuelle Xilinx-Addierer und Xilinx-Multiplier erzeugt und mittels Component und Map im Design angeschlossen und zwar welche, die es real gar nicht gibt! So wird z.b. eine 8+8 Addierer oder ein 5x5 Multiplier gebaut, ohne Rücksicht auf die reale Grösse der DSP-Elemente, was überhaupt der einzige Nutzen einer expliziten Instaziierung wäre. Diese Geschichte ist dann nicht nur schlechter lesbar und verhindert die Portierung sondern erzeugt auch noch Pflegebedarf sowie Datenmüll, denn bei einer Änderung der Bitbreite von Eingangsvektoren, welche bei einem inferierten Multiplier oder Addierer, der mit einfachem + / * beschrieben wurde, wird nicht etwa das Ergebnis automatisch mitkaliert, sondern ein anderer Addierer eingesetzt, während der alte als Müll auf der Platte bleibt. Hat man sich den Luxus gegönnt, die Signalkette gar mittels Xilinx blockset grafisch einzugeben, darf man Konstantenvergleiche manuell in der Bitbreite anpassen, wärend ein rudimentäres "if (unsigned(vectorname) = 19)" immer noch arbeiten würde, egal, wie breit der Vektor nun ist. Das Arbeiten mit generics und implizieter Skalierung wird dadurch effektiv verhindert und das Designen ausgebremst!!!!! Das Design ist dann komplett herstellergebunden und schon jetzt bestehen js oft 50% des Designs schon aus Cores und was weiss ich noch, die herstellerabhängig sind. Christoph schrieb: > du viel mehr Leute > findest die schon mit Xilinx Erfahrung gesammelt Das is richtig, wobei nicht wenige von denen ihre "Erfahrungen" dazu nutzen, um einen anderen Chip anzudenken :-)
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.