vraag over op de productie gecompenseerd

C

cherjier

Guest
Dit is een voorbeeld code:
module teller (CLOCK, ENABLE, count);
input CLOCK;
input ENABLE;
output [3:0] COUNT;

reg [3:0] COUNT = 3'b000;

altijd @ (posedge CLOCK)
if (ENABLE)
COUNT <= count 1;
anders
COUNT <= 3'b000;
endmodule

de beperkingen:
NET "CLOCK" TNM_NET = "CLOCK";
TIMESPEC "TS_CLOCK" = PERIODE "CLOCK" 5 ns HOGE 50%;

voor behavoural simulatie, de output blokstellen COUNT en registreer COUNT zal schakelen op dezelfde klok die het ideale geval
na PAR en voer de functie PAR simulatie, het register COUNT zal rond 1.5ns vertraging met betrekking tot de huidige klok rand en de output pad zal vertraging 6 ns naar dezelfde klok rand.de output pad is bijna 1 klokcyclus vertraging.

Ik probeer om te experimenteren met de offset beperkingen:
OFFSET = IN 2 ns voor "CLOCK";
OFFSET = OUT 10 ns NA "CLOCK";

maar de PAR geeft me een fout
Olierijke:-1.478ns (eis - (klok aankomst klok pad gegevens pad onzekerheid))
Bron: count_int_0 (FF)
Bestemming: COUNT_OUT <0> (PAD)
Bron Klok: CLOCK_BUFGP stijgt op 0.000ns
Vereiste: 10.000ns
Data path Vertraging: 5.282ns (Niveaus van Logic = 1)
Klok Path Vertraging: 6.196ns (Niveaus van Logic = 2)
Klok Onzekerheid: 0.000ns

Klok Path: CLOCK te count_int_0
Locatie Vertraging type Delay (ns) Fysieke Resource
Logisch Resource (s)
------------------------------------------------- -- ------------------
M17.I Tiopi 0.885 CLOCK
CLOCK
CLOCK_BUFGP / IBUFG
BUFGCTRL_X0Y31.I0 netto (fanout = 1) 0,875 CLOCK_BUFGP / IBUFG
BUFGCTRL_X0Y31.O Tbgcko_O 0.900 CLOCK_BUFGP / BUFG
CLOCK_BUFGP / BUFG
SLICE_X174Y368.CLK netto (fanout = 3) 3,536 CLOCK_BUFGP
------------------------------------------------- -- --------------------------
Totaal 6.196ns (1.785ns logica, 4.411ns route)
(28,8% logica, 71,2% route)

Data Path: count_int_0 te COUNT_OUT <0>
Locatie Vertraging type Delay (ns) Fysieke Resource
Logisch Resource (s)
------------------------------------------------- -- ------------------
SLICE_X174Y368.XQ Tcko 0.360 count_int <0>
count_int_0
G10.O netto (fanout = 6) 1,399 count_int <0>
G10.PAD Tioop 3.523 COUNT_OUT <0>
COUNT_OUT_0_OBUF
COUNT_OUT <0>
------------------------------------------------- -- --------------------------
Totaal 5.282ns (3.883ns logica, 1.399ns route)
(73,5% logica, 26,5% route)

de klok pad vertraging en data path vertraging is groot, maar het model is eenvoudig genoeg.
naast, zodra de offset toegevoegd door verhoging van de compensatie te 12ns, het ontwerp zal falen op post par simulatie.indien zonder compensatie van beperkingen, het ontwerp kan op de post par simulatie, maar met een grote vertraging tussen de FF en de pad.

tenslotte, hoe kan het bepalen van de juiste waarde voor de compensatie van een input / output?
dank je ..

 
Użytkownicy iPhone biją na alarm - po odebraniu wiadomości SMS składającej się z określonych znaków, występujących w alfabecie arabskim, smartfon Apple samoczynnie się zrestartuje. Zdaniem posiadaczy iPhone błąd krytyczny jest obecny nie tylko w iOS 8.3, ale we wcześniejszych wersjach. Jest on na tyle uciążliwy, że powoduje ciągłe restarty urządzen...

Read more...
 
Ik heb niet onderzocht uw timing verslagen, maar hier
is een andere aanpak voor het oplossen van het probleem.De beste manier om de flop-to-pad timing is om uw output Flops in de IOBs,
in plaats van in de logica weefsel.Verwijzen naar de "IOB" beperking in uw ISE Constraint Gids.

U kunt echter niet op een snelle counter in de IOBs omdat IOBs niet de leuke feedback en snelle uitvoering keten zoals in de logica weefsel.Integendeel, je zou kunnen verlaten de teller in de logica weefsel, en voeg een output register aan uw ontwerp.Dat register kunnen gaan in de IOBs.Nu heb je een snelle counter en snel flop-op-pad timing, vermeerderd met een cyclus van latentie.

 
Ik had bewerkt de code:
output [3:0] COUNT_OUT;
reg [3:0] COUNT_OUT;

altijd @ (posedge CLOCK)
COUNT_OUT <= count;

en voeg ik deze lijn op UCF dossier:
INST "COUNT_OUT [0]" IOB = true;
INST "COUNT_OUT [1]" IOB = true;
INST "COUNT_OUT [2]" IOB = true;
INST "COUNT_OUT [3]" IOB = true;

de FF te PAD timing deed verbeteren, maar pas vanaf 12 tot 10 ns ns, en de FF te PAD vertraging nog steeds groot voor me.
doet dit normaal of heb ik niet het register in IOB?

 
10ns is zeker te lang voor een IOB flop.Uw HDL ziet er goed uit, maar een of andere manier de IOB beperkingen niet werken.
Check het in kaart brengen / routing logbestanden voor berichten waarschuwing in verband met de IOB beperkingen.

Toen ik synthetiseren logica willen dat ISE selecteert IOB Flops automatisch, dus ik gewoonlijk niet hoeft te vermelden IOB beperking.Maar ik moet ergens.

Controleer ook uw "Pad Samenvatting" verslag.De "IO Registreren" kolom moet zeggen "ja" indien de IOB flop wordt gebruikt.
U kunt ook de IOB configuraties en algemene routing in FPGA-editor.

 
Ik controleer de kaart verslag,
dat ik niet kon vinden waarschuwing betreffende IOB, maar ik heb alleen deze waarschuwing:
WAARSCHUWING: LIT: 243 - Logische netwerk N11 heeft geen last.
waarvan ik weet niet waarom ....

Ik heb de PAD syntheseverslag en de IO-register heeft laten zien "ja".

zodat de output Ffr heeft gelegen op IOB ..

enig idee over weten?

 
Dat
is goed nieuws uw PAD samenvatting zegt IO Registreren is "ja".

OFFSET = OUT 10 ns NA "CLOCK";

Oh wacht even!Die beperking wordt de tijd vanaf de CLOCK input pad naar de uitgang COUNT_OUT pad.Dat
is helemaal door de FPGA, niet alleen uit het IOB flop op de uitgang pad.Dat lange pad konden meer dan 10ns op sommige FPGA's,
met name oudere types.

Welk type FPGA gebruikt u?

 
echt?Ik dacht dat deze beperkingen heeft de tijd van de IOB op de uitgang pad na de specifieke klok rand.

alleen voor informatie, normaal heb je gebruik maken van de compensatie van beperkingen?eigenlijk, hoe heb je figuur uit de offset waarde?

Ik gebruikte Virtex 4, moet het een beetje snel .. Ik denk dat ...

 
Xilinx beperkingen zijn soms verwarrend, zelfs na zorgvuldige lezing van de documentatie.

De ISE 9.2i Constraints Gids's beschrijving van de OFFSET beperking begint met de volgende paragraaf.Merk op hoe zij verwijst naar de externe klok en I / O-pinnen, en sluit interne punten:OFFSET is een fundamentele timing beperking.
Zij bepaalt de timing relatie tussen een externe klok en de bijbehorende data-of data-out pin.
OFFSET is alleen gebruikt voor pads-gerelateerde signalen, en kan niet worden gebruikt voor de uitbreiding van de aankomsttijd specificatie methode om de interne signalen in een ontwerp.
Een klok die komt uit een intern signaal is een opgewekt uit een synch-element, zoals een FF.
Een klok die afkomstig is van een pad en gaat door een DLL, DCM, klok buffer, of combinatorische logica wordt ondersteund.Een paar bladzijden later is "Voorbeeld Drie: OFFSET NA".De commentaar zegt de beperking bepaalt de tijd van de klok input pad naar de data-uitgang pad.

Ik
heb nooit gebruikt OFFSET beperkingen in mijn projecten.Misschien
zal ik het ooit nodig, maar tot nu toe
heb ik gewoon gebruikt IOB input / output-Flops en vervolgens een beroep op de I / O-timing schakelen kenmerken in de data sheet.

De Virtex-4 doet een hoop dingen echt snel, maar het kan nog steeds aanzienlijke vertraging tussen de klok input-en data-uitgang.Er zijn nogal wat interne stappen tussen die twee kussentjes.Ik probeerde je bijvoorbeeld design in een xc4vfx12-10-ff668, en de klok te COUNT_OUT vertraging was ongeveer 9.2ns in de Trace verslag en post-route simulatie.Dat
is vergelijkbaar met de resultaten.

Code:

module top (CLOCK, ENABLE, COUNT_OUT);

input CLOCK, ENABLE;

reg [3:0] COUNT = 0;

output reg [3:0] COUNT_OUT;altijd @ (posedge CLOCK) beginnen

COUNT <= ENABLE?
COUNT 1: 0;

COUNT_OUT <= count;

eindigen

endmodule
 
hum ... ik denk dat
ik een beetje duidelijk voor nu.
de offset out is een verwijzing naar de input klok op de uitgang blokstellen timing.

Olierijke:-1.478ns (eis - (klok aankomst klok pad gegevens pad onzekerheid))
Bron: count_int_0 (FF)
Bestemming: COUNT_OUT <0> (PAD)
Bron Klok: CLOCK_BUFGP stijgt op 0.000ns
Vereiste: 10.000ns
Data path Vertraging: 5.282ns (Niveaus van Logic = 1)
Klok Path Vertraging: 6.196ns (Niveaus van Logic = 2)
Klok Onzekerheid: 0.000ns

vanaf hier zien we dat de klok komen over de inbreng blokstellen tijd was 0ns maar de klok aan de FF had een grote vertraging van 6ns en de Ffr tot uitgang pad had een 5ns gegevens vertraging die
de y was een grote productie vertraging.Ik denk dat de reden was de klok pad vertraging.
eens?

Trouwens, voor de periode na par simulatie, nadat ik in de beperkingen compenseren met een grote gecompenseerd uit beperkingen, de simulatie zal mislukken.maar als de offset beperkingen was verwijder de simulatie werd passeren, maar met een grote productie vertraging.heb je gezicht hetzelfde probleem?

 
De acht lijnen u opgenomen uit de timing verslag moet worden gevolgd door bijkomende nuttige info, maar het kan moeilijk te interpreteren.Hier
is de volledige doorsnede van mijn Trace verslag:
Code:

Olierijke: 0.846ns (eis - (klok aankomst klok pad gegevens pad onzekerheid))

Bron: COUNT_OUT_0 (FF)

Bestemming: COUNT_OUT <0> (PAD)

Bron Klok: CLOCK_BUFGP stijgt op 0.000ns

Vereiste: 10.000ns

Data path Vertraging: 4.146ns (Niveaus van Logic = 1)

Klok Path Vertraging: 5.008ns (Niveaus van Logic = 2)

Klok Onzekerheid: 0.000nsMaximale Klok Path: CLOCK te COUNT_OUT_0

Locatie Vertraging type Delay (ns) Fysieke Resource

Logisch Resource (s)

------------------------------------------------- -- ------------------

AD12.I Tiopi 0.944 CLOCK

CLOCK

CLOCK_BUFGP / IBUFG

BUFGCTRL_X0Y13.I0 netto (fanout = 1) 0,835 CLOCK_BUFGP / IBUFG

BUFGCTRL_X0Y13.O Tbgcko_O 0.900 CLOCK_BUFGP / BUFG

CLOCK_BUFGP / BUFG

OLOGIC_X1Y41.CLK netto (fanout = 6) 2,329 CLOCK_BUFGP

------------------------------------------------- -- --------------------------

Totaal 5.008ns (1.844ns logica, 3.164ns route)

(36,8% logica, 63,2% route)Maximale data path: COUNT_OUT_0 te COUNT_OUT <0>

Locatie Vertraging type Delay (ns) Fysieke Resource

Logisch Resource (s)

------------------------------------------------- -- ------------------

OLOGIC_X1Y41.OQ Tockq 0.584 COUNT_OUT_0

COUNT_OUT_0

AB13.O netto (fanout = 1) 0,002 COUNT_OUT_0

AB13.PAD Tioop 3.560 COUNT_OUT <0>

COUNT_OUT_0_OBUF

COUNT_OUT <0>

------------------------------------------------- -- --------------------------

Totaal 4.146ns (4.144ns logica, 0.002ns route)

(100,0% logica, 0,0% route)

 
hum ... Ik kan u zeggen wat maar enigszins i dunno dit grote bedrag van vertraging aanvaardbaar omdat zij slechts een eenvoudig ontwerp.

Ik heb ook nooit gebruikt voor en alleen vertrouwen op de IOB schakelen timing alleen.
de offset beperkingen lijken belangrijk, maar nog steeds niet het idee krijgen hoe het goed gebruikt ...

<img src="http://www.edaboard.com/images/smiles/icon_sad.gif" alt="Triest" border="0" />Trouwens, ik heb een andere vraag en ik hoop wat feedback kan krijgen ..
Dit is een voorbeeld code:
Code:

module multi_cyc_test (

CLK,

RST_N,ENA,

IN_DATA,

OUT_DATA

);parameter IDLE = 2'b00;

parameter Load = 2'b01;

parameter COUNT = 2'b10;

parameter WINKEL = 2'b11;CLK-ingang;

input RST_N;

input ENA;

input [3:0] IN_DATA;output [3:0] OUT_DATA;reg [1:0] counter;

reg [3:0] reg_a;

reg [3:0] reg_b;reg [1:0] current_state;

reg [1:0] next_state;reg count_start;

reg reg_a_en;

reg reg_b_en;draad count_done;toewijzen count_done = &counter;

toewijzen OUT_DATA = reg_b;altijd @ (posedge CLK of negedge RST_N)

if (! RST_N)

counter <= 2'b00;

anders als (count_start)

counter <= counter 1;altijd @ (posedge CLK of negedge RST_N)

if (! RST_N)

reg_a <= 4'h0;

anders als (reg_a_en)

reg_a <= IN_DATA;altijd @ (posedge CLK of negedge RST_N)

if (! RST_N)

reg_b <= 4'h0;

anders als (reg_b_en)

reg_b <= ~ reg_a; / / vanaf reg_a te reg_b, tussentijdse wellicht meer combinatievormen logicaaltijd @ (posedge CLK of negedge RST_N)

if (! RST_N)

current_state <= stationair;

anders

current_state <= next_state;altijd @ (current_state of ENA of count_done) beginnencount_start = 1'b0;

reg_a_en = 1'b0;

reg_b_en = 1'b0;zaak (current_state)

IDLE: beginnen

if (ENA) next_state = belasting;

eindigenLOAD: beginnen

next_state = count;

reg_a_en = 1'b1;

eindigenCOUNT: beginnen

next_state = count;

if (count_done) next_state = WINKEL;

count_start = 1'b1;

eindigenWINKEL: beginnen

next_state = stationair;

reg_b_en = 1'b1;

eindigenstandaard: beginnen

next_state = stationair;

eindigen

ENDCASE

eindigenendmodule
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top