Considere el siguiente código:
wire unpacked_wire[3:0];
wire [3:0] packed_wire;
assign unpacked_wire = packed_wire; // Error: Cannot assign packed type to unpacked type
assign {>>{unpacked_wire}} = packed_wire; // No errors
Mi primera declaración de asignación falla. Sin embargo, el segundo no. Sin embargo, de acuerdo con IEEE Std 1800-2017, sec 11.4.14:
Cuando se utiliza en el lado izquierdo, los operadores de transmisión realizan la operación inversa, es decir, descomprimen un flujo de bits en una o más variables.
Entonces, ¿no es redundante el operador de transmisión en LHS ya que está convirtiendo un tipo desempaquetado... a un tipo desempaquetado? Entonces, ¿no debería seguir siendo ilegal esta segunda asignación? Para mí, este código se lee como si el operador de transmisión en realidad estuviera empaquetando los datos.
Solución del problema
Es desempaquetar en el sentido de que toma un único valor empaquetado integral y lo divide en los elementos individuales de una matriz desempaquetada. Cuando se trata del operador de transmisión, si está empacando o desempaquetando no es tan relevante, está reorganizando el diseño de los bits. También podrías escribir esto como
assign unpacked_wire = {>>{packed_wire}};
Cuando solo hay un objeto a cada lado de la asignación, no importa de qué lado coloque el operador de transmisión.
El LRM considera los tipos desempaquetados como un tipo fuerte. Solo puede realizar asignaciones de/a tipos equivalentes. Los tipos empaquetados, por otro lado, son débiles. Puede realizar asignaciones entre tipos empaquetados de diferentes tamaños y trunca o rellena los datos de forma silenciosa. El operador de transmisión se parece más a un reparto explícito que facilita las asignaciones entre tipos desempaquetados y otros empaquetados o desempaquetados.
No hay comentarios.:
Publicar un comentario