definir todas as portas de saída em VHDL como "buffer" tipo

[shaiko]

Olá pessoas. Você pode listar qualquer boa razão para não usar o "tampão" do tipo para todas as saídas da entidade? Ao descrever um bloco complexo de lógica, eu gosto de poder voltar a ler uma porta de saída sem ter que usar um sinal auxiliar. Eu sei que todas as portas de saída em HDL Verilog são automaticamente buffers. Então ... por que não em VHDL? Quais são os contras de declarar todas as saídas como tampões?

 

[std_match]

É uma boa idéia na teoria, mas provavelmente você vai entrar em apuros. Você deve usar o "tampão" em todos os níveis do design. O problema é que se você criar uma entidade com o tipo de porta "buffer", você não pode conectá-lo ao tipo de porta "para fora". Poderia funcionar se você fizer um desenho completo por si mesmo, ou se o projeto tem uma regra estrita que vai usar apenas "tampão". Eu sugiro que você use o atributo "driving_value" em vez. Que permite ler o que o processo está a tentar conduzir (que pode ser diferente a partir do valor real). A razão para este comportamento é que um processo não pode saber o valor de sua saída do! Pelo menos não para "std_logic", "sem sinal" e "assinado". A saída pode ser ligado a uma outra saída, fora do processo.

 

[shaiko]

Você pode explicar como usar o "driving_value" atributo?

 

[TrickyDicky]

condução valor é um atributo de um sinal que dá o seu valor, tal como definido no processo actual. Ele funciona da mesma como a atribuição de uma variável temporária. por exemplo:

 iniciar um processo de

 

[shaiko]

Então, se a entidade porta "a" é defiend como "fora std_logic" e eu quero lê-lo de volta - eu posso evitar redefinindo-a como "tampão" e, em vez escrever: internal_sig

 

[TrickyDicky]

sim, mas você só pode fazer isso a partir do mesmo processo que um é conduzido dentro assim, se uma é definida fora de um processo como: a

 

[shaiko]

O que eu quero é dirigir 'a' diretamente e ser capaz de lê-lo de volta (sem ter que usar um sinal de "auxiliar"). O 'atributo driving_value dá apenas uma solução parcial, então ... ele não pode ser usado sempre. Isso nos deixa novamente com a necessidade de usar sinais auxiliares que por sua vez faz com que a lista de sinais longo de nosso projeto complexo ainda mais! "99% dos engenheiros não se preocupam com o tampão, e alguma empresa de codificação diretrizes proíbem o uso de tampão" Eu vejo que a única boa razão para não usar o tipo de buffer é por causa da compatibilidade com outros projetos. Mas isso é como evitar o uso de carros elétricos porque não é maneira demais estações de gás em torno de ...

 

[FvM]

std-jogo inicialmente mencionou o fato, que alguns compiladores de design, que são referentes a uma versão VHDL de idade, permitem que as portas de buffer para ser apenas ligado ao tipo de buffer na hierarquia superior. Isso não é no entanto exigido por ferramentas recentes, tanto quanto eu estou ciente de, por exemplo Altera Quartus não requer que desde sempre, também ModelSim não. Eles até mesmo tolerar, que a propriedade de buffer está escondido em uma definição de componente em uma entidade superior, renomeando um tampão para fora. Funcionalmente, não há diferença entre o buffer e um sinal de uso temporário para portas de saída, presumindo-se a atribuição de sinal temporária de sinal de saída é feito em código concorrente. Eu também não ouvi, que em Verilog, onde cada reg saída ou fio podem ser lidas sem pré-requisitos especiais, alguém fez uma coisa dele.

 

[TrickyDicky]

Isso nos deixa novamente com a necessidade de usar sinais auxiliares que por sua vez faz com que a lista de sinais longo de nosso projeto complexo ainda mais!

Que tal escopo seus sinais? Você pode decalre sinais dentro regiões gerar (assumindo que eles são usados ​​apenas no interior da geração) Além disso, use variáveis ​​dentro de processos de estágio do pipeline para substituir sinais. Apenas lembre-se sobre as regras de atribuição de variável.

 

[shaiko]

TrickyDicky, Não importa se é um sinal ou variável ... Meu ponto é, que a declaração de um sinal / variável que é essencialmente um fio, cujo único propósito é servir como um mediador entre a lógica ea porta de saída - torna o código desnecessariamente prolixo. Com todos os 'out' portas definidas como amortecedores, facilmente evitar que o texto desnecessário e tornar o código mais limpo.

 

[FvM]

Definindo todas as portas de saída como buffers cria um olhar estranho do porto e é potencialmente confuso, gostaria de restringi-la às saídas realmente ler novamente, então o tipo de buffer ajuda a identificar esses sinais.

 

[shaiko]

FVM, Isso é uma boa idéia. E eu acho que esta era a intenção originial da língua ... No entanto, por alguma razão, como mencionado TrickyDicky 99% dos engenheiros não se incomode com buffers.

 

[FvM]

No entanto, por alguma razão, como mencionado TrickyDicky 99% dos engenheiros não se incomode com buffers.

Sim, mas eu não sei exatamente por quê. Eu não vou usar tampões para os sinais que são primariamente interna a uma entidade, apenas copiado para o mundo exterior para fins informativos. Simplesmente porque ele confunde propósito do sinal. Sinais que são primariamente sinais de saída da entidade, mas precisava de adicional internamente são candidatos tampão típicas.

 

[TrickyDicky]

Como com muitas coisas em VHDL (as bibliotecas std_logic_unsigned / aritmética e instanciações de componentes, blocos, registram sinais), existem algumas coisas que foram assumidas ou descartadas ao longo dos anos devido à sua falta de suporte dos fornecedores de síntese. E então hábitos formaram usando (ou não) essas coisas que são suportados na língua. Im tampão adivinhação é uma daquelas coisas. O problema com tampão agora, é que ele é mencionado em outros lugares (buffers IO em FPGAs) e também poderia levar algumas pessoas a pensar que, porque ele é especial, ele é automaticamente registrado (que não é), ou causar alguma confusão com inout. Estes podem ser um pouco remota, mas tenho certeza que eles aconteceram.

 

[FvM]

Como uma observação adicional, as restrições para os portos fora foram removidos em VHDL 2008. Alguns autores ainda ver buffer relacionada com tamponamento sinal de hardware. Eu não tenho certeza, se um tratamento diferente pode ser esperada com ferramentas de síntese ASIC, mas não pode com compiladores de design habituais FPGA tanto quanto eu estou ciente.