VHDL: números inteiros para síntese?


17

Estou um pouco confuso sobre se devo usar números inteiros em VHDL para sinais e portas de síntese, etc.

Eu uso std_logic nas portas de nível superior, mas internamente eu estava usando números inteiros variados em todo o lugar. No entanto, deparei-me com algumas referências a pessoas dizendo que você só deve usar assinados / não assinados para código direcionado à síntese.

Voltei e reformulei meu projeto atual para usar assinaturas ... e, bem, é visivelmente mais feio.

É uma prática ruim usar números inteiros? Qual é o problema? Existe alguma incerteza sobre qual largura a ferramenta mapeará números inteiros?


Boa pergunta. Eu estive me perguntando isso. Comecei com o uso de números inteiros, positivos e outros em todo o lugar, mas acabou sendo muito cabeludo para ser sintetizado adequadamente. Espero que alguém possa explicar por que todo mundo acaba usando std_logic em uma linguagem altamente tipada.
Trygve Laugstøl 21/03/11

1
Sim. Isso não é louco? Altamente digitado na prática atual tende a resultar em muitos DATA_I <= TO_UNSIGNED (32010, DATA_I'LENGTH); tipo coisas ... que não incomoda ninguém? :) Com certeza parece muita bagagem desnecessária. (Especialmente ao adicionar STD_LOGIC_VECTOR () a isso) Declarei meu tipo e tamanho, esse deve ser DATA_I <= 32010; Isso deve estar implícito. Ir entre assinado / não assinado, etc, pode e deve ser explícito ... mas uma atribuição ou operação direta e inequívoca em números inteiros deve estar implícita.
22411 darron

Respostas:


15

Inteiros são bons em síntese, eu os uso o tempo todo.

Eu uso std_logic nas portas de nível superior, mas internamente eu estava usando números inteiros variados em todo o lugar

Isso é bom!

Estar ciente:

  • Você está simulando primeiro, não está :) - Os tipos inteiros não "rolam" automaticamente na simulação - é um erro sair do intervalo especificado para eles. Se você deseja um comportamento de substituição, é necessário codificá-lo explicitamente.
  • -(231-1)+231-1-231unsignedsigned
  • Se você não os restringir, às vezes poderá acabar com contadores de 32 bits, onde menos seriam necessários (se o sintetizador e as ferramentas subseqüentes não puderem "ver" que eles poderiam otimizar os bits de distância).

No lado positivo:

  • Eles são muito mais rápidos para simular do que vetores não assinados / assinados
  • Eles não passam automaticamente pela simulação (sim, está nas duas listas :). Isso é útil - por exemplo, você recebe um aviso antecipado de que seu contador é muito pequeno.

Quando você usa tipos de vetores, você está usando ieee.numeric_std, nãoieee.std_logic_arith é?

Eu uso integers onde posso, mas se eu quiser explicitamente "contadores de n bits de rolagem", eu costumo usá-lo unsigned.


Sim, eu uso numeric_std. Acho que estou principalmente preocupado com as ferramentas Xilinx ... elas ainda geram std_logic_vector para tudo e "UNSIGNED" não está no realce da sintaxe.
21411 darron

1
@ Darron Não se preocupe com o destaque da sintaxe. O editor e seu marcador de sintaxe são um software completamente diferente da ferramenta de síntese. Além disso, não assinado é "apenas" um tipo de dados. Faz parte de uma biblioteca padrão, não da própria linguagem.
Philippe

O limite inferior não é -2 ^ 32 + 1? Se fosse -2 ^ 31 - 1, seria necessário apenas mais um bit para representar apenas um único número - muito estranho.
Bregalad

@Bregalad - boa captura - isso está errado há um bom tempo!
Martin Thompson

@ MartinThompson Ou talvez você possa escrever como - (2 ^ 32-1) se preferir manter o sinal de menos.
Bregalad


6

Não há nada errado em usar números inteiros para RTL em si , mas há razões para que alguns a evitem. Esta é realmente uma pergunta sobre as "melhores práticas" subjetivas e, eventualmente, você precisará descobrir o que prefere. Como ajuda, compartilharei minha experiência e pensamentos sobre isso.

Principalmente , sou a favor do uso de números inteiros (restritos), também ao escrever para síntese. Às vezes faço isso, mas, na prática , geralmente me ater a signede unsigned. Vou elaborar o porquê.

Você será forçado a usar tipos de dados vetorizados em parte do seu design de qualquer maneira:

  • Dificilmente qualquer IP de fornecedor ou IP de terceiros usará o integertipo para portas

  • Por exemplo, ao enviar dados através do BlockRam, mesmo que você os deduza e, portanto, nunca precise fazer interface com nenhum IP / macro / primitivo, você provavelmente precisará converter para o tipo vetorizado de qualquer maneira

  • Mesmo que nenhuma das opções acima se aplique, você precisará fazer a interface com outra coisa em algum momento (uma porta de nível superior, se nada mais)

Como você não pode usar integero design completo, você pode ignorar tudo isso porque:

  • Em alguns momentos, você precisará fazer as conversões de qualquer maneira, e isso tira parte do ponto de usar integer em primeiro lugar

  • Além disso, para simulação, essas conversões normalmente são chamadas com vetores de 'U'ou'X' , antes reset, ou em outras vezes, e cada tal chamada de função irá gerar mensagens de aviso da função pacote, bagunçando seus avisos de simulação / prompt de

Desvantagens do uso integer :

  • Ao contrário dos tipos vetorizados, números inteiros não têm 'U' e 'X'; Acho isso muito útil em simulações. Você vê como os sinais não inicializados se propagam pelo design e provavelmente reagirá se vir muitos sinais não inicializados após a redefinição. Este não será o caso se estiver usando números inteiros.

  • Com números inteiros, há um risco maior de incompatibilidade de simulação / síntese ao adicionar ou subtrair resultando em sub / transbordamento. (Como já apontado por outra pessoa.)

Casos típicos em que considero integerrealmente uma boa opção:

  • Para sinais / contadores de depuração que você monitora através do chipScope / signalTap etc.

  • Representação totalmente interna de contadores, que nunca entra ou sai do seu próprio código. Sim, existem tais casos, por exemplo, se você estiver escrevendo um FIFO e você são escritas cálculo de posição / lê para formar os sinais full, empty, almostFulletc. (no entanto aritmética sobre os ponteiros é uma maneira melhor do cálculo de posição neste caso. ..)

Minhas próprias conclusões: uso números inteiros algumas vezes, mas com moderação e principalmente nos casos descritos acima. Não vejo muita sobrecarga no uso unsignede, em signedvez de número inteiro, e, portanto, geralmente os atendo.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.