2017-05-16 4 views
1

Consultez le code exemple suivant:SystemVerilog: Variable d'interface référencée dans la tâche d'une autre interface

interface I(); 
    logic x; 
    modport slave(input x); 
endinterface 

interface J(I.slave i); 
    logic y; 
    task process; 
     if (i.x) begin 
      // ... 
     end 
     if (y) begin 
      // ... 
     end 
    endtask 
endinterface 

module test(input wire logic clock); 
    I iXXX(); 
    J jXXX(.i(iXXX), .*); 

    always @(posedge clock) begin 
     jXXX.process(); 
    end 
endmodule 

Ce code fonctionne en utilisant Vivado 2017,1 Simulator et ne pas travail en utilisant Vivado 2017,1 Synthèse qui échoue avec l'erreur

[Synth 8-146] cannot resolve hierarchical name ... 

Si vous modifiez le if (i.x)-if (jXXX.i.x), il ne synthétisent. Cela me semble complètement étrange. Peut-être que quelqu'un peut faire la lumière sur ce que ce comportement est attendu et ce que la norme en dit.

Référencer jXXX.i.x aurait du sens si le code de tâche est collé dans lequel l'process() appel se produit, à l'exception spéciale que les variables non comme l'interface y (qui sont contenus dans l'interface) ont le nom de l'instance d'interface préfixé. Pour l'instant, je voterais juste pour "bug du compilateur". La solution de contournement que j'utilise à l'heure actuelle est d'ajouter wire logic HACK_i_x = i.x; à l'interface et de référencer ce fil local comme if (HACK_i_x) qui simule et synthétise.

Répondre

0

Cela ressemble à un bug d'outil de synthèse pour moi. D'autres simulateurs gèrent également le code que vous avez écrit. Le chemin hiérarchique jXXX. de l'intérieur J est une référence hiérarchique ascendante vers lui-même. Alambiqué, mais toujours légal.