Denne gang er det en opgave som er nem at beskrive. Som med mange af vores brainere er det også en type løsning som er oplagt og nem når man kender svaret.
I et Xilinx FPGA design ønsker du at udnytte de registre som sidder tæt på benene på dit device for at opnå lavt delay fra clock til output. Som mange af jer ved ligger der i input/output blokkene registre som er velegnede til formålet. Så du vælger at sætte en constraint som beder dit tool om at udnytte disse registre: IOB=TRUE.
Efter PAR (place-and-route) og timing analyse af resultatet noterer du dig at til trods for at du har IOB=TRUE på dine data IO pins får du ringere clock-to-output delays end beskrevet i datasheet for det pågældende device. Hvorfor?
Tip: På nogle andre outputs viser timing analysen delays præcis som ventet.
Først med rigtig svar i kommentarerne vinder hele hæderen… Tror kun der er et muligt svar, som også er realistisk i praksis – men vi får se
Der kan være flere årsager, men den mest åbenlyse er at PAR ikke skelner mellem input og output siden af registrene. Medmindre man specifikt vælger at “packe” registre for outputs only (mener jeg det hedder).
Hej Casper. Du har fat i noget af det rigtige. Du har ret – man kan sagtens have en forskel på input og output register mht. placering. Men lad os bare udvide konceptet med at IOB=TRUE på både de data registre som modtager input og de registre som indeholder data output værdierne. Braineren går mest på hvilke gode ideer du og andre har til at output timing nu ikke blev helt som databladet lovede trods det faktum at der er blevet bedt om “packing”.
Henning kommer med følgende på mailen:
Tak for et altid interessant og tankevækkende nyhedsbrev.
Linken fra ”Brainer” virker ikke I min setup. Giver fejl 404.
Det skal nu ikke afholde mig fra at komme med et bud:
1. IOB er alligevel ikke blevet placeret i periferien. Placering er blevet ”overrulet” på grund af en timing constraint af signalet der går mellem IOB og core. IOB er blevet ”suget ind i” core for at møde constraint der. Lidt a la pest/kolera problematikken.
2. Den sidste ting jeg kunne forestille mig ville være at drive strength / load er sat forkert således at signalet bliver forsinket pga. stige fald-tiden er for stor – vel kun hvis det er et FPGA output.
—
Tak for det – 404 fejlen blev hurtigt rettet. Og dine ideer er godtaget, men det er heller ikke rigtig løsningen… der må tænkes vidre
Afhængig af om man bruger DLL i sit clock setup, kan man i det mindste forbedre output to clock ved at fjerne delay blokken. (NODELAY) Har også tidligere haft “success” ved at ændre slew rate og drive strength for en hel gruppe IOB. Men ellers er min erfaring at det meste magi sker i mapningen, ikke i place and route, specielt lineært med mængden af brugt logik. Xilinxs map options er gode at kunne imho.
Godt feedback. Der gemmer sig en lille detalje endnu som trods FF placering i IOB og passende drive strength giver “sløvt” clock-to-output.
Er det andre der har et bud?
Nu er det mindst 1+ år siden jeg har haft fat i en Xilinx FPGA og kan intet huske om deres clock struktur, derfor forsøgte jeg ikke at svare i første omgang. I en altera FPGA vil dette, så vidt jeg kan se, kun være muligt såfremt man har sat en regional eller IO constrain på clock nettet, således at det anvendte clock net kun kan føde en del af FPGA’en og nogle IO blokke direkte. Dvs at de pins som er i IO blokke uden dette clock net får deres clock routet via yderligere nets eller via et global net med større forsinkelse end det regionale net.
Nb 1+ år skulle have været mindst 10 år siden
Jeg ville mene at en output_delay timing constraint på relevante IO ville mappe FF ud i IO pads. Constraint formatet afhænger lidt af hvilket værktøj man benytter, der er eks. forskel på hvordan de specificeres i SDC(Synplify/Altera) og i Xilinx UCF/XCF. Eksempelvis ville en SDC constraint se nogenlunde således ud: “set_output_delay my_pin -clock my_io_clock -min 0.9*io_clock_period -max 0.9*io_clock_period”. Denne constraint modellerer et virtuelt eksternt register som clockes med my_io_clock og har et(eksternt) delay til D pinen på 90% af clock perioden, således at FPGA clock to out delay inklusive I/O pad delay skal møde de resterende 10%. Det ville være meget mere ligetil at forklare dette med en figur :O)
Venlige hilsener
Det er et par år siden jeg lavede FPGA designs, så bær over med mig
I den nævnte situation ville et hurtigt kig på timingsnedbrydningen sikkert hurtigt kunne fortælle, hvad der er galt.
En ting, der ikke er nævnt er forsinkelse af clocken ud til FF’en evt. pga. fysisk delay (skew) eller pga. ekstra clock buffere.
Denne brainer råber på en afslutning. Xilinx har i deres IO blokke et programmerbart IODELAY element som kan forsinke input fra – eller output til chip pin’en. Dette kan bruges til delay matching af IO’s. Men hvorfor dette delay skulle være aktiveret på nogle og ikke andre pin’s, vel og mærke uden at designer udtrykkeligt har bedt om det, ved jeg ikke. Men disse delay enheder ville altså kunne forsinke clock til output som beskrevet i quizen.
vh henning
Hej alle.
Tak for tilbagemeldingerne – og tak for deltagelse på timing analyse kurset i går til dem er jer som deltog. I kender nu svaret på braineren.
Desværre har jeg ikke set nogle pletskud fra jer, så jeg åbner for en del af løsningen.
Indrømmet – Jeg har givet jer en svær opgave, eftersom I ikke selv har haft mulighed for at snuse rundt i designet.
Det som afslører sig er:
- At clock distributionen er fin og har dermed ikke voldsomt skew/insertion delay.
- Output registeret sidder som ønsket og specificeret pr. UCF filen i IOB
Det som giver den øgede clock-to-output forsinkelse på IO er at output tri-state bufferens enable signal IKKE er placeret i registeret i IOB’en sammen med selv output registeret.
Ergo – clock signalet ankommer til et register som ligger et stykke vej fra den pågældende IOB og interconnect delay til IOBens tri-state buffer er kilden til problemet.
En lille tillægsbrainer kan således være følgende 2 spørgsmål:
a) Når jeg nu har sat IOB=TRUE på både output-registeret og output-enable registeret – Hvorfor bliver de så ikke begge to placeret i IOB’en?
b) Hvordan kunne jeg sikre mig, at jeg havde fået at vide med det samme at output-enable registeret ikke blev placeret i IOB’en?
God weendend.
(Det tæller ikke at svare på spørgsmål a) hvis du var med på kurset i går)
- Anders Enggaard
I et registreret design vil der altid være et output register per bit. En 16-bit databus vil således have 16 output registre.
Output Enable signalet derimod er et fælles signal for flere bits, er kun 1 bit bred og har derfor kun et register. Det ene regsiter kan naturligvis ikke placeres i alle IO celler på een gang.
For at få OE-registeret ud i hver IO-celle, må man derfor generere et et separat OE-signal per output register. I tilfældet med 16 output registre, skal der være 16 OE signaler – et til hvert output register.
Nu skulle PAR gerne kunne placere et separat OE register ude ved hvert output register i IO cellen. Dog skal man lige sørge for, at synteseværktøjet ikke optimerer OE signalet tilbage til en enkelt bit igen;-)