Mantenha a contabilização de transações durante descarte e reset

O cancelamento é um evento explícito do projeto

Reset retorna o controle a um estado conhecido; flush cancela trabalho pendente especificado. Limpar apenas os dados é insuficiente. Se valid permanecer alto, zero pode se tornar uma transação falsa. Bits antigos de dados com valid zero são inofensivos. Limpe o estado adequado que indica a posse de dados: full em um buffer de uma posição, count e ponteiros em uma FIFO, ou estado da FSM e valid do resultado.

Nosso contrato síncrono de clock único exclui aceitação e entrega em uma borda de reset em ambos os extremos e cancela nela todo o trabalho pendente. Reinicializar apenas um extremo enquanto o outro conta o valid antigo como entrega viola esse acordo. Documente o escopo do reset e a política de prontidão. Novas entradas após reset pertencem a um novo intervalo de transações.

Com cancelamento, use accepted-delivered-canceled=outstanding. Cancele cada transação não entregue exatamente uma vez. A fila de referência também deve remover o trabalho cancelado, verificando que nenhum resultado antigo entre no novo intervalo.

Uma solicitação externa de memória pode sobreviver a um descarte interno. Distinga respostas tardias usando um identificador de geração ou espere as solicitações antigas terminarem antes de reiniciar. Reutilizar cedo demais um campo pequeno de geração pode confundir uma resposta antiga com uma atual. Nosso projeto final não tem respostas externas atrasadas e cancela apenas buffers internos.

Um descarte seletivo pode manter trabalho anterior a um desvio e remover operações posteriores do caminho errado. Isso exige regras definidas de ordenação e confirmação. Trabalho inválido não deve atualizar armazenamento nem participar de encaminhamento. Teste reset com o sistema vazio, em pausa, cheio e durante transferências potencialmente simultâneas. Apenas o reset inicial não exercita o cancelamento de trabalho pendente.