Signalübergabe bei zwei PLL Takten

Tim Gast #4343772
Lesenswert?
• ▲
▼ 
Vielleicht ist die Frage trivial, aber so richtig bin ich aus anderen 
Beiträgen nicht schlau geworden.

Ich habe eine PLL/DCM die mir beispielsweise einen 50 und 100 MHz Takt 
liefert. Nun möchte ich ein Signal auf die schnellere Taktdomäne senden.

Kann ich es einfach rüberreichen? wenn sig50 startet, kommt dann sig100a 
oder sig100b heraus? oder kann man es nicht sagen? Wichtig ist für 
taktgenau zu sagen, wann das Signal gesampelt wurde.


1
clk_50  |^^^^^|_____|^^^^^|_____|^^^^^|_____|^^^^^|_____

2
sig50   ____________|^^^^^^^^^^^|_______________________

3


4
clk_100 |^^|__|^^|__|^^|__|^^|__|^^|__|^^|__|^^|__|^^|__

5


6
sig100a _____________|^^^^^^^^^^^|______________________

7
sig100b __________________|^^^^^^^^^^^|_________________

1
process(clk_100)

2
begin

3
 if rising_edge(clk_100) then

4
   sig100 <= sig50;

5
 end if;

6
end process;


  





  

    Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
  








      

      



  

    

      Lothar M.
      

    

      Moderator

      (Firma: Titel)

    Persönliche Seite

    
    #4343833
  




  

  Lesenswert?
  

  •
  
  ▲  
  

  ▼  
  		
  

  


  

      
Es kommt sigB heraus, weil (bzw. wenn) das sig50 als Reaktion auf clk_50 
ja so gar nicht existiert. Das Bild müsste so aussehen:
1
         _____       _____       _____       _____       

2
clk_50  |     |_____|     |_____|     |_____|     |_____

3
                      ___________

4
sig50   _____________|           |_______________________

5


6
         __    __    __    __    __    __    __    __    

7
clk_100 |  |__|  |__|  |__|  |__|  |__|  |__|  |__|  |__

8


9
                            ___________

10
sig100b ___________________|           |_________________


  





  

    Antwort Zitieren Bearbeiten Löschen Beitrag melden
  








      

      



  

    

      Tim

    

      Gast


    

    
    #4343876
  




  

  Lesenswert?
  

  •
  
  ▲  
  

  ▼  
  		
  

  


  

      
Folge ich damit richtig, dass man davon ausgehen kann, dass clk_100 auch 
keinen unbekannten skew durch das Routing bekommt?
Es wird also sicher gestellt, dass clk_100 sich nicht verzögert und 
damit auch nicht eine Flanke vorher das Datum übernimmt?

  





  

    Antwort Zitieren Bearbeiten Löschen Beitrag melden
  








      

      



  

    

      Lothar M.
      

    

      Moderator

      (Firma: Titel)

    Persönliche Seite

    
    #4343886
  




  

  Lesenswert?
  

  •
  
  ▲  
  

  ▼  
  		
  

  


  

      
Tim schrieb:
> Es wird also sicher gestellt, dass clk_100 sich nicht verzögert und
> damit auch nicht eine Flanke vorher das Datum übernimmt?
Wenn du das der Toolchain mit der passenden Verdrahtung und 
entsprechenden Constraints mitteils, dann ja.

> dass clk_100 auch keinen unbekannten skew durch das Routing bekommt? Es
> wird also sicher gestellt, dass clk_100 sich nicht verzögert
Das sind die Grundlagen eines synchronen Designs...

  





  

    Antwort Zitieren Bearbeiten Löschen Beitrag melden
  








      

      



  

    

      Duke Scarring

    

      Gast


    

    
    #4343941
  




  

  Lesenswert?
  

  •
  
  ▲  
  

  ▼  
  		
  

  


  

      
Tim schrieb:
> Folge ich damit richtig, dass man davon ausgehen kann, dass clk_100 auch
> keinen unbekannten skew durch das Routing bekommt?
Da Du den DCM erwähnt hast, gehe ich davon aus, das die Xilinx-Tools zum 
Einsatz kommen. Dort erzeugt das Tool automatisch abgeleitete 
Constraints.
Daher kenn das Tool auch den Skew und die zulässigen Setup- und 
Hold-Zeiten.

Duke

  





  

    Antwort Zitieren Bearbeiten Löschen Beitrag melden
  








      

      



  

    

      Tim

    

      Gast


    

    
    #4343968
  




  

  Lesenswert?
  

  •
  
  ▲  
  

  ▼  
  		
  

  


  

      
Lothar M. schrieb:
> Das sind die Grundlagen eines synchronen Designs...

leider haben mich andere Meinungen verunsichert.

Natürlich sind zwei Punkte wichtig:
* ob die Simulation/Modell dies unterstützt
* ob der Synthes/P&R Flow dies unterstützt

Bei Ersteren scheint man wohl manchmal über die Delta-Delays zu 
stolpern. Wie z.b. hier 
http://www.fpgarelated.com/showthread/comp.arch.fpga/80535-1.php

laut link:
wenn das Modell unterschiedliche Delta-Zeiten liefert, kann ein 
"shoot-through" wie bei sig100a entstehen.

Ein Test der DCM in Vivado2015.2 zeigt jedoch bei mir einsauberes 
Verhalten.

Demnach sind beide Punkte in Ordnung.

Vielen Dank für die Hilfe.

  





  

    Antwort Zitieren Bearbeiten Löschen Beitrag melden
  








      

      



  

    

      FPGA-Ingenieur

    

      Gast


    

    
    #4344093
  




  

  Lesenswert?
  

  •
  
  ▲  
  

  ▼  
  		
  

  


  

      
Die Simulation ist hier mit Vorsicht zu genießen, weil sie den Jitter 
nicht nachstellt. Da gibt es immer mehrere Kombinationen. Ich würde den 
100er um 90 Grad verstellen, damit die Taktflanken nicht beieinander 
sind. Dann hast Du engere, aber saubere Verhältnisse. Signalübergabe mit 
Synchronizer.

  





  

    Antwort Zitieren Bearbeiten Löschen Beitrag melden
  








      

      



  

    

      Tim

    

      Gast


    

    
    #4344325
  




  

  Lesenswert?
  

  •
  
  ▲  
  

  ▼  
  		
  

  


  

      
FPGA-Ingenieur schrieb im Beitrag #4344093:
> Die Simulation ist hier mit Vorsicht zu genießen, weil sie den
> Jitter
> nicht nachstellt. Da gibt es immer mehrere Kombinationen. Ich würde den
> 100er um 90 Grad verstellen, damit die Taktflanken nicht beieinander
> sind. Dann hast Du engere, aber saubere Verhältnisse. Signalübergabe mit
> Synchronizer.

Das beißt sich wieder mit der oberen Aussage, dass man sich bei der 
phasengleichen Anordnung darauf verlassen kann.

Die Verhaltensimulation stellt ja auch keine FF und Gatterdelays dar.

Ich wäre jetzt davon ausgegangen, dass der Jitter in der 
clock_uncertainty mit berücksichtigt wird und das Routing 
gegebenenfalls, das Datum oder den Clock verzögert. So kenne ich es 
zumindest bei einer einzelnen Taktdomän.

Das wären jetzt doch zwei verschiedene Herangehensweisen.

  





  

    Antwort Zitieren Bearbeiten Löschen Beitrag melden
  









    

    

       Thread beobachten


    

        


Antwort schreiben




  
Bitte melde dich an, um einen Beitrag zu schreiben.

  

  
Bestehender Account



  

    

      

        
        
      

      

        
        
      

    


    

      
      
    




  
oder

  Mit Google-Account einloggen





  
Noch kein Account?

  
Die Registrierung ist kostenlos und dauert nur eine Minute.

  Jetzt registrieren