Jeg vil vælge at følge dit råd til Finn.Finn,</p>
<p>Lad være med at spilde for meget tid på Carsten, han lever i sin egen verden hvor han har sine egne naturlove og en af dem er at alle andre ved mindre end han gør.
Jo det er et problem at dit design er afhængig af et givent routing delay, når du ikke har gjort dig umage med at fortælle værktøjet hvad dette delay skal være. Når du ikke har gjort dig umage med dette havner du i situationer hvor du ender med at skrive:Det er ikke et givent routing delay, der er problemet, men forskelle i routing delay, som opstår ud fra den tilfældige routing.
Når du skriver dette, samt det uoverskuelige i at constraine et asynkront design, kommer du altså til at fremstå som om du ikke rigtig har forstået problematikkerne og løsningerne på samme. Det er muligt det ikke er tilfældet men nu ved du hvilken følelse dine læsere sidder tilbage med.Jeg har fra mit eget virke flere eksempler på, at kredsløb kan virke i én version, men fejle i næste version ved få rettelser et helt andet sted, fordi kredsen så routes lidt forskelligt - og det på trods af, at jeg er meget opmærksom på problemerne.
Ja? Hvis dit design er afhængig af et givent routing delay kan det vel dårligt komme som en overraskelse? Med mindre selvfølgelig det du skriver er at værktøjet ikke overholder de constraints du har sat op, men sådan læser jeg det ikke.Jeg har fra mit eget virke flere eksempler på, at kredsløb kan virke i én version, men fejle i næste version ved få rettelser et helt andet sted, fordi kredsen så routes lidt forskelligt - og det på trods af, at jeg er meget opmærksom på problemerne
Bortset fra det ligner resten af dit indlæg noget der skulle have noget med det jeg skrev at gøre, men jeg kan ikke rigtig se en sammenhæng.
Carsten, vi snakker om at "garantere" robusthed. Her har hvad man får ud af at se på et billede, eller hvor godt man tror man læser kildekode ingen relevans. Jeg tror ikke vi behøver bruge mere tid på den kode dit værktøj autogenerer i forhold til det her emne.Ja, i højeste grad, for robusthed handler først og fremmest om overblik. Hvis jeg lister den VHDL kode, der autogenereres ud fra min grafik, vil jeg garantere for, at der ikke findes én eneste programmør i hele verden, der ville kunne skabe sig nok overblik til sikkert at kunne rette nogen steder.
Jeg ved ikke hvorfor du går og bilder dig selv ind at du er unik i forhold til at tage sådan nogle parametre, eller for den sags skyld temperatur udsving, i betragtning. Det er muligt du er unik i din måde at løse det på men det er så også det. Så ud over dig vil jeg antage at det er alle andre der tænker på disse ting.Komponenterne i en IC kan jo i modsætning til diskrete komponenter ikke testes individuelt for en lang række parametre, så man ved reelt set ikke, hvor tæt man er på fejlgrænsen; men med en dual-phase clock, kan man acceptere særdeles store parameterændringer. Vis mig lige det VHDL eller Verilog system, som kan syntetisere countere og flip-flop's baseret på en sådan teknologi - eller for den sags skyld den FPGA designer (bortset fra mig), der tænker på disse ting!
Mener du virkelig at du garanterer robusthed ved at vise et billede? Jeg er med på at et fint billede kan vise et bedre overblik over hvordan funktionaliteter hænger sammen, men robusthed vil jeg mene demonstreres på helt andre måder"Én tegning kan forklare mere end 1000 ord." Ikke ti vilde heste skal få mig over på tekstbaseret VHDL, Verilog eller hardware-C, selvom det er det, "man gør", for så ville jeg aldrig nogensinde kunne garantere robusthed i de ting, jeg laver (bl.a. med dual-phase clock overalt), og med asynkrone netværk med over 5000 gates ville jeg have mistet overblikket for længst.
Henning. Jeg kan langt hen af vejen godt være enig med dig. Mit problem er at hvis vi selv bestemmer "lidt" er det op til dig at bestemme hvad "lidt" er. Det har jeg det slet ikke godt med.
Tak Martin jo den kom igennem :-)
Skulle man være heldig at kunne lokke en invitation ud af en eller anden? Larsopoulsen(@)gmail.com
Lars Opstrup Poulsen