¿Cuál es la mejor manera de modelar un controlador de transacción fuera de orden en UVM?

Answer 1

Como mencionó el controlador fuera de orden, asumo que se refiere al modelo de alguna interfaz de protocolo / comunicación donde las respuestas pueden salir fuera de orden con respecto a las solicitudes. Una forma sencilla es usar el par {sequence_id, transaction_id} para que coincida con las respuestas recibidas y hacer lo que quieras hacer.

En el método de ejecución del controlador a medida que recibe solicitudes de la secuencia, siga conduciendo como un hilo paralelo. Cada hilo recopilará la respuesta del DUT, establecerá la secuencia y la identificación de la transacción en la respuesta y la enviará de vuelta a la secuencia

Un pseudo código se vería como el siguiente

En la secuencia, necesitas unir las respuestas y manejarlas.

Para manejar la respuesta en secuencia, use response_handler para hacer lo que quiera hacer con la recepción fuera de orden (o incluso en la respuesta de orden)

Espero que esto ayude

Answer 2

He logrado algunos avances en el desarrollo de un controlador fuera de servicio gracias a este muy buen artículo que he encontrado en Internet “Secuencia, Secuencia en la pared, que es el más justo”. Los autores son de Mentor Graphics.

Ahora volvamos a la pregunta respuesta:

Para modelar un controlador fuera de servicio necesitamos un controlador segmentado donde todos los canales deben ser independientes entre sí. Supongamos que tenemos 3 canales: write_data, write_address, write_resp para dirección, datos y respuesta. Usted escribe la dirección para enviar en un buzón. Luego lees desde el buzón y conduces los datos. A continuación, comprueba la respuesta y coloca la respuesta en un buzón.

Es importante que utilicemos los buzones de correo para este trabajo porque proporcionan tareas de bloqueo para obtener y poner datos que sincronizarán el tiempo de obtención y colocación de nuestro elemento y resolverán el acceso de puntero nulo.

A continuación tenemos que ejecutar los 3 canales en paralelo. Esto se puede hacer en la clase de controlador de UVM en el siguiente método (puede que haya algunos otros métodos, pero he implementado este):

el controlador de clase extiende uvm_driver (fase uvm_phase);
tenedor
write_address (); // hilo para enviar la dirección
write_data (); // hilo para enviar datos
write_resp (); // hilo para enviar resp
join_none
// entonces necesitamos un bucle para siempre para obtener los elementos de secuencia del secuenciador

para siempre comenzar
seq_item_port.get_next_item (trans); // trans es el elemento de transacción
trans_array [trans.tag] = trans;
seq_item_port.item_done ();
address2SendMb.put (trans.tag);
fin
tarea write_address ();
para siempre comenzar
trans trans_ins;
address2SendMb.get (trans_ins.tag);
trans_ins = trans_array [trans_ins.tag];
// Enviar la dirección a la interfaz según protocolo.

// al final cuando las señales de dirección están completamente hechas
data2SendMb.put (trans_ins.tag);
fin
tarea final
tarea write_data ();
para siempre comenzar
trans trans_ins;
data2SendMb.get (trans_ins.tag);
trans_ins = trans_array [trans_ins.tag];
// Enviar los datos a la interfaz según protocolo.

// al final cuando las señales de datos están completamente hechas

fin
tarea final
tarea write_resp ();
para siempre comenzar
trans trans_ins;
// espera el canal de datos resp
trans_ins.resp = resp; // resp es la señal de interfaz desde la cual // muestrearemos resp
resp2checkMb.put (trans_ins.resp);
fin
fin
clase final

Esta es la idea básica de modelado de controladores fuera de orden. Necesitamos verificar la etiqueta de respuesta con la etiqueta que hemos enviado para verificar si la dirección y la respuesta de los datos se enviaron en consecuencia desde el dispositivo esclavo.

Añadiré más si encuentro algo nuevo.
Gracias

Answer 3

Básicamente, hay diferentes formas de modelar un controlador en el que se conectó al secuenciador a través de puertos TLM bidireccionales.

En casos normales en los que no necesita ninguna respuesta del conductor, entonces

seq_item_port.get_next_item (req);

seq_item_port.item_done ();

hará el trabajo por ti.

Pero en caso de que la implementación del controlador fuera de orden es un poco diferente.

Básicamente, consta de dos fases, como la fase de solicitud y la fase de respuesta, y la respuesta que sale del controlador para cada uno de los elementos de la secuencia está fuera de servicio. Al completar la transacción anterior, la dirección de la siguiente transferencia ya se ha capturado en el bus, en palabras cortas canalizadas.

Por lo tanto, para este tipo de controlador necesita una lógica adicional para implementar aparte de las descritas anteriormente:

a) Uso de semáforos para el cuidado de las etapas canalizadas.

b) La serie de llamadas a set_id_info () para rastrear las secuencias significa la respuesta que se alimenta.

c) Uso de get_request y put_response en lugar de get_next_item.

d) llamada get_response (req) en el método de tarea del cuerpo de la secuencia para garantizar que se ha consumido toda la solicitud.

e) El uso de múltiples bifurcaciones se une en el controlador para asegurar el multihilo que cuidará a los descendientes.

Estos son algunos pasos para modelar un conductor sobresaliente o fuera de servicio.

Pero de manera similar, cuando modela este tipo de controlador, los cambios correspondientes deben incorporarse en el cuadro de indicadores ya sea mediante la implementación de un análisis de quince o un comparador fuera de orden para que se mantenga la integridad de los datos.

Answer 4

Lo siento, no puedo responder a esta pregunta, porque realmente no uso el sistema Verilog para verificar mi diseño. Para alternar, uso Simulink como también DSPBuilder para finalizar los algoritmos de procesamiento de imágenes. Espero que mi experiencia pueda ayudarlo.