VHDL: Nomenclatura e interpretação da arquitetura


14

Nota: Estou usando o ISE da Xilinx e tenho uma placa FPGA para trabalhar (com interruptores, luzes e assim por diante), e hackeei alguns projetos simples até agora. Ao mesmo tempo, estou lendo vários tutoriais para criar uma base para o que estou fazendo.

Eu já vi várias entidades e suas arquiteturas mencionadas nos materiais de referência que eu já passei, mas os nomes geralmente são confusos. Muitas vezes, em vez de "arquitetura rtl de .." ou "arquitetura estrutural de ...", verei "arquitetura foo de ..." ou até mesmo "arquitetura arco de ..."

Percebo (tardiamente) que o nome da arquitetura é tão arbitrário quanto o nome da entidade, embora existam guias de estilo que sugerem que convenções de nome mais consistentes possam ser usadas para evitar esse problema. Isso me leva a algumas perguntas:

  • Olhando para uma entidade, como determinar o modelo de arquitetura real sendo usado sem dicas do nome da arquitetura? RTL, comportamental, estrutural ... eles parecem bastante parecidos com os dos meus alunos (assumindo que os exemplos que eu vi foram realmente nomeados corretamente). Um exemplo simples, mas óbvio, seria útil aqui (ou um ponteiro para um).

  • Se especificar várias arquiteturas para uma única entidade (o que eu entendo ser possível), você simplesmente atribui nomes diferentes às arquiteturas no mesmo arquivo ou ...?

  • Os nomes da arquitetura estão confinados a uma determinada entidade (ou seja, há algum problema com "namespaces" usando o mesmo nome da arquitetura em várias entidades)?

Edit: e mais um:

  • Parece que há uma distinção entre RTL e comportamental, mas, como mencionado acima, não estou realmente vendo nos exemplos que vi (muitas vezes vejo apenas uma arquitetura sendo definida). Uma arquitetura é mais comum que as outras?

O que eu estava procurando é um projeto abrangente e simples de vários componentes (pequenos componentes), escrito usando as práticas recomendadas (nomeação adequada, nem todas amontoadas em um arquivo etc.), mas ainda não encontrei um. Considero exemplos de projetos criados adequadamente muito úteis para esclarecer princípios básicos e práticas recomendadas. Se você souber de um projeto de exemplo, ficaria grato por um ponteiro para isso também. (Se nada mais, talvez depois de descobrir isso, eu possa compartilhar um dos meus ...)

Respostas:


6

Olhando para uma entidade, como determinar o modelo de arquitetura real sendo usado sem dicas do nome da arquitetura?

Você não pode - quando é instanciada ou configurada, a arquitetura pode ser especificada (se houver mais de uma para escolher) ou um padrão será escolhido para você.

Se especificar várias arquiteturas para uma única entidade (o que eu entendo ser possível), você simplesmente atribui nomes diferentes às arquiteturas no mesmo arquivo ou ...?

Você lhes dá nomes diferentes. Ele não precisa estar no mesmo arquivo (na verdade, o VHDL se importa muito menos do que você imagina no que está em qual arquivo)

Os nomes da arquitetura estão confinados a uma determinada entidade (ou seja, há algum problema com "namespaces" usando o mesmo nome da arquitetura em várias entidades)?

Eles são "anexados" a uma entidade e podem ser reutilizados.

Costumo usar a1como arquitetura para tudo que pode ser sintetizado como

  • rtl implica nível mais baixo (para muitos leitores) do que eu escrevo.
  • behavioural geralmente implica não sintetizável (para alguns leitores)
  • synth é usado pelo sintetizador para seu modelo (caso contrário, eu teria usado isso)

a1 até agora não teve conflitos e não causa confusão;)

Se eu realmente tenho mais de uma arquitetura, tenho a tendência de nomeá-las verbalmente (por exemplo, hard_multiplierse lut_multiplierspara um filtro que instancia - ou não - os blocos MUL18).

Muitas vezes você tem apenas uma arquitetura, por isso não importa. Bons nomes de entidades são muito mais importantes.

Parece que há uma distinção entre RTL e comportamental, mas, como mencionado acima, não estou realmente vendo nos exemplos que vi (muitas vezes vejo apenas uma arquitetura sendo definida). Uma arquitetura é mais comum que as outras?

É histórico - você não costumava sintetizar código "comportamental" (que a certa altura incluía coisas como adicionar!) - então você criou uma versão RTL que instanciava adicionadores e coisas do gênero. (É o que eu entendo - eu escrevo códigos comportamentais (e ainda assim sintetizáveis) desde que comecei o VHDLing em 1999!)


Agradeço a resposta ponto a ponto!
28713 MartyMacGyver

Faço o mesmo: cito todas as minhas arquiteturas arche, em vez disso, concentro-me em dar às entidades nomes razoáveis. Para o raramente caso em que tenho mais de uma arquitetura para uma entidade, apenas dou a eles outros nomes. No entanto, para mim, behaviouralrealmente implica código que não é possível ou não pretende ser sintetizado. Além disso, sempre tive a ideia de que rtlé o nome adequado para todos os HDL destinados à síntese, independentemente do nível de abstração. (I pode, como sempre, estar errado em qualquer um desses pontos embora, mas essa foi a minha compreensão do uso dessas palavras.)
Carl

8

Aqui estão os tipos de arquitetura:

Comportamental:

Notas gerais:

  • Tradicionalmente, não há hierarquia (apenas um arquivo, nenhum componente é instanciado), embora isso varie entre as ferramentas.
  • Muito rápido para simular.
  • Os comportamentos dos sinais são definidos.
  • Quando comportamental é usado apenas para simulação, ele pode conter código não sintetizável. O comportamento pretendido para a síntese deve naturalmente ser sintetizado.

Notas específicas do Xilinx

  • Geralmente, os modelos de geradores principais são arquivos .vhd de pré-síntese

Estrutural:

Definição geral

  • Instancia apenas componentes e os une (hierárquico).
  • Mais lento para simular do que comportamental.
  • Nenhuma definição real de comportamento do sinal no nível superior.
  • Somente código sintetizável.

Notas específicas do Xilinx

  • Os modelos de geradores principais não levam em consideração o tempo.
  • Geralmente, os modelos de gerador de núcleo instanciam listas de redes pós-síntese

Os itens acima são basicamente os dois principais animais tradicionais da arquitetura. Muito comumente, é usada uma definição "mista", que contém propriedades de ambos.

RTL:

RTL o que é realmente colocado no FPGA no final do dia. Portanto, este é um código sintetizável que define o comportamento do sistema e é composto de uma hierarquia de códigos:
As camadas inferiores serão comportamentais sintetizáveis, onde o âmago da questão do comportamento do sinal é definido e os níveis superiores serão estruturais, onde componentes comportamentais são interligados para criar um grande "diagrama de blocos" de nível superior, se você desejar.

Em várias arquiteturas:

As arquiteturas podem ser todas em um arquivo ou em vários arquivos. A única coisa importante é que a entidade seja compilada primeiro e que a arquitetura a ser usada seja especificada.

Este livro é muito útil e detalha esse tipo de coisa muito bem.

Não existe uma regra rígida e rápida sobre como as coisas devem ser feitas em termos de modelos comportamentais e estruturais distintos ou apenas de mistura deles. Geralmente, em grandes projetos de firmware (ou em grandes empresas, onde o código é compartilhado e reutilizado), é útil distinguir entre os dois para simplificar as questões, no entanto, no final do dia, tudo se resume ao que funciona melhor para você.


Obrigado pela resposta e pela dica do livro (embora evidentemente seja um item difícil de adquirir).
MartyMacGyver 28/02

@MartyMacGyver: sim, eu só costumo ler a versão do Google Docs: P
stanri

Eu mas é deliberadamente faltando páginas ...
MartyMacGyver

1

Antes de tudo, os projetos de arquitetura do mundo real não podem ser estritamente categorizados dessa maneira. Por que se limitar? Você pode instanciar outras entidades e conectá-las "estruturalmente", mas adicione um processo ou atribuição simultânea aqui e ali para adicionar alguma lógica "rtl" e talvez use alguns padrões de codificação "comportamentais" para que o sintetizador descubra algumas das detalhes com os quais você não se importa (como adicionar sem instanciar especificamente um adicionador com parâmetros de área / pipelining / desempenho), tudo na mesma arquitetura.

Mais importante, você deve entender o que é sintetizável nas atuais tecnologias asic / fpga e o que não é, e isso independentemente do modelo de arquitetura.

Uma entidade pode ser implementada de várias maneiras, mesmo permitindo comportamentos ligeiramente diferentes; portanto, você pode ter várias arquiteturas para a mesma entidade. Além disso, você pode ter uma arquitetura apenas para simulação (geralmente não sintetizável) que pode simular mais rapidamente que a versão "real", o que pode ser útil ao testar projetos grandes como um todo. Você daria nomes a essas arquiteturas que o ajudarão a lembrar o que as torna diferentes das outras, e simplesmente bhv / str / rtl geralmente não é suficiente ou preciso, dada a natureza híbrida dos projetos do mundo real.

Em relação às suas perguntas específicas, a declaração de arquitetura está vinculada a um nome de entidade, portanto, não há problemas de espaço para nome com arquiteturas de mesmo nome para diferentes entidades. Basta usar nomes diferentes para arquiteturas para a mesma entidade.

As arquiteturas podem residir em arquivos diferentes, você só precisa garantir que a declaração da entidade seja compilada primeiro.

Você pode selecionar qual arquitetura usar ao instanciar a entidade ou usar instruções de configuração. Caso contrário, o padrão é 'geralmente' a última arquitetura que o compilador viu para uma determinada declaração de entidade.


1
Obrigado pela sua resposta! O tema comum parece ser que os projetos geralmente não se encaixam perfeitamente nos buracos da arquitetura que eu tenho lido. Espero encontrar um exemplo canônico para satisfazer minha curiosidade (bastante pedante) sobre o assunto ... Se eu vou divergir de um "ideal", gostaria de pelo menos saber como é a aparência ideal.
28713 MartyMacGyver
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.