Quais são as melhores práticas para Descrição de Hardware Idiomas (Verilog, VHDL etc.) [fechado]

Question

O que as melhores práticas devem ser observados quando da implementação do código HDL?

Quais são as semelhanças e diferenças quando comparado com campos de desenvolvimento de software mais comum?

Answer 1

O melhor livro sobre este tema é manual Reutilização Metodologia . Abrange tanto VHDL e Verilog.

E, em particular alguns problemas que não têm uma correspondência exata em software:

• No travas
• Cuidado com resets
• Verifique se o seu calendário interno e externo
• Use apenas o código synthesizable
• Registre seus resultados de todos os módulos
• Tenha cuidado com o bloqueio vs. atribuições sem bloqueio
• Tenha cuidado com listas sensíveis para a lógica combinatória (ou uso @ (*) em Verilog)

Alguns que são os mesmos incluem

• Use CM
• código tenham comentários
• Test (simular) o seu código
• reutilização de código quando apropriado
• Você possui uma agenda up-to-date
• ter uma especificação ou casos de uso ou um cliente Agile

Answer 2

Uma espécie de uma discussão antiga, mas queria colocar no meu $ 0,02. Isto não é realmente específico para Verilog / VHDL .. mais em design de hardware em geral ... de design especificamente synthesizable para ASICs personalizados.

Este é o meu PARECER com base em anos de indústria (em oposição ao acadêmico) experiência em design. Eles estão em nenhuma ordem particular

A minha declaração guarda-chuva é projetar para a execução de validação. Em design de hardware, a validação é primordial. Os erros são muito mais caro quando encontrado em silício real. Você não pode simplesmente re-compilação. Portanto, pré-silício é dado muito mais foco.

• Saiba a diferença entre caminhos de controle e caminhos de dados. Isto permite-lhe criar um código muito mais elegante e sustentável. Também permite que você salve portas e minimizar X propagação. Por exemplo, caminhos de dados nunca deve precisar de fracassos repostos, caminhos de controle deve sempre precisa.

• Prove funcionalidade antes da validação. Seja através de uma abordagem formal ou através de formas de onda. Isto tem muitas vantagens, vou explicar 2. Primeiro, você vai economizar cebola tempo perdido descascando através de questões. Ao contrário de muitos de nível de design de aplicações (esp enquanto aprende) e mais trabalho do curso, o tempo de turn-around para alterações de código é muito grande (em qualquer lugar de 10 minutos a dias, dependendo da complexidade). Cada vez que você alterar o código, você precisa passar por elaboração, verificação de fiapos, compilar, de forma de onda de simulação trazer-up, e, finalmente, real .. que se pode levar horas. Em segundo lugar, você é muito menos propensos a ter dificuldade para bater casos de canto. Note que isto é em relação ao pré-silício validação. Estes certamente vai bater no pós-silício custando-lhe lotes de $$$. Confie em mim, o up front custo de provar funcionalidade minimiza muito o risco e vale bem a pena o esforço. Isso às vezes é difícil convencer os graduados recentes da faculdade.

• ter "pedaços de frango". frango bits são bits em MMIO configurado através do driver para desativar um recurso em silício. É destinado a Reverter alterações feitas na qual a confiança não é alto (confiança é diretamente proporcional ao esforço de validação). É quase impossível para acertar todos os estados possíveis em pré-silício. Confiança em seu design não pode realmente ser cumpridas até que seja comprovada em pós-silício. Mesmo se houver apenas 1 estado que é atingido 0,000005% do tempo que expõe o erro, ele vai bater no pós-silício, mas não necessariamente em pré-silício.

• exceções evitar no caminho de controle a todo custo. Cada nova exceção você tem dobra seus esforços de validação. Este é difícil de explicar. Vamos dizer que há um bloco DMA que vai salvar a dados para a memória que outro bloco vai usar. Vamos dizer que a estrutura de dados salvos fora é dependente de alguma função que está sendo feito. Se você decidiu projetar tal que a estrutura de dados salvos foi diferente entre diferentes funções, basta multiplicar seus esforços de validação pelo número de funções DMA. Se esta regra for seguida, a estrutura de dados salvos fora seria um super-conjunto de todos os dados disponíveis para cada função, onde os locais de conteúdo são codificados. Uma vez que o DMA salvar lógica é validado para uma função de seu validados para todas as funções.

• Minimizar as interfaces (ler minimizar caminhos de controle). Isto está relacionado com a minimização exceções. Primeiro, cada nova interface requer validação. Isso inclui novas damas / trackers, afirmações, pontos de cobertura e modelos funcionais de ônibus em seu testbench. Em segundo lugar, ele pode aumentar seus esforços de validação exponencialmente! Vamos dizer que você tem uma interface para leitura de dados em caches. Agora vamos dizer que (por alguma estranha razão) você decidir que quer uma outra interface para leitura de memória principal. Você só quadruplicou seus esforços de validação. agora você precisa para validar estas combinações a qualquer momento n :

  • não cache de leitura, nenhuma memória de leitura
  • não cache de leitura, leitura de memória
  • cache de leitura, nenhuma memória de leitura
  • cache de leitura, leitura de memória

• Compreender e comunicar suposições. Faltando esta é a principal razão para o bloco para questões de comunicação bloco. Você poderia ter um bloco perfeito totalmente validado .. no entanto, sem compreender todas as suposições, o bloco irá falhar quando seu conectado.

• Minimizar estados potenciais. Os estados menos (intencionais ou não) um projeto tem, menos esforço necessário para validar. É uma boa prática de grupo como funções em 1 função de nível superior (como seqüenciadores e árbitros). É muito difícil identificar e definir esta função de alto nível tal que engloba tantas funções menores como possível, mas ao fazê-lo muito eliminar Estado e no potencial turno para bugs.

• Sempre fornecer um sinal forte de deixar seu bloco. A maior parte da flopping vez é a solução. Você não tem idéia do que o bloco (s) ponto final vai fazer com ele. Você pode executar em problemas de tempo que podem ter um impacto directo sobre a sua implementação perfeito.

• Evite FSMs tipo mealy menos que o desempenho está impactado negativamente. FSMs Mealy são mais propensos a problemas de produção de tempo ao longo Moore

• .. e, finalmente, o que eu mais não gosta: "se não está quebrado, não conserte" Por causa do risco envolvido e o alto custo de erros, muitas vezes hackers é uma mais prático solução para resolução de problemas. Outros têm escapado a esta mencionando utilização de componentes existentes.

Como para comparar contra mais tradicional design de software:

• programação de eventos discretos orientada é um paradigma completamente diferente. As pessoas vêem sintaxe verilog e pensar "oh, é apenas como C" ... no entanto, isso não pode estar mais longe da verdade. Embora a sintaxe é semelhante, deve-se pensar de forma diferente. Por exemplo, um depurador tradicional é praticamente insignificante no RTL sintetizável (desenho Testbench é diferente). Formas de onda em papel são a melhor ferramenta disponível. No entanto, dito isto, FSM projeto pode, por vezes, programação procedural imitar. Pessoas com um fundo de software tendem a ficar louco com FSMs (Eu sei que fiz no início).

• Sistema Verilog tem muitos e muitos (e muito) de testbench características específicas. É completamente objeto orientado. Tanto quanto testbench design vai, é muito semelhante ao design de software tradicional. No entanto, ele tem mais 1 dimensão associada a ele, que de tempo. condições de corrida e atrasos de protocolo deve ser contabilizado

• Como para validação, também é diferente (e os mesmos). Existem 3 principais abordagens;

  • verificação propagativo Formal (FPV): Você provar através da lógica que sempre funciona
  • testes aleatórios Directed. Aleatoriamente definido atrasos, os valores de entrada, e que permitam recurso, tal como definido por uma semente. dirigido significa que o peso coloca sementes em caminhos que têm menos confiança. Esta abordagem utiliza pontos de cobertura para indicar a saúde
  teste
  • Focus. Isto é semelhante ao teste de software tradicional

... Para completar, eu preciso também discutir as melhores práticas de design teste-banco ... mas isso é para outro dia

Desculpem o comprimento .. Eu estava em "The Zone":)

Answer 3

HDL como Verilog e VHDL realmente parecem incentivar código espaguete. A maioria dos módulos consistem de vários 'sempre' (Verilog) ou 'processo' (VHDL) blocos que podem estar em qualquer ordem. O algoritmo geral ou função do módulo é muitas vezes totalmente obscurecido. Descobrir como o código funciona (se você não escrevê-lo) é um processo doloroso.

Alguns anos atrás me deparei com este papel que descreve um método mais estruturado para projeto VHDL. A idéia básica é que cada módulo tem apenas 2 quarteirões do processo. Uma para código combinatória, e outro para síncronos (os registros). É ótimo para a produção de código legível e de fácil manutenção.

Answer 4

• no HDL, algumas partes do código pode trabalhar ao mesmo tempo, por exemplo duas linhas de código "pode ??funcionar", ao mesmo tempo, esta é uma vantagem, para usar com sabedoria. isso é algo que um programador que está acostumado a linha por linguagens de linha podem achar difícil de entender no início:

  • Long e específico para suas necessidades dutos pode ser criado.
  • Você pode fazer suas grandes módulos funcionam ao mesmo tempo.
  • em vez de uma unidade para fazer uma ação repetida em dados diferentes, você pode criar várias unidades, e fazer o trabalho em paralelo.

• Especial atenção deve ser dada para o processo de inicialização -. Uma vez que seu chip é funcional, você fez uma maneira enorme

depuração no hardware é geralmente muito mais difícil do que a depuração de software assim:

• é o preferido de código simples, por vezes, há outras maneiras para velocidades acima de seu código, após ele já está a executar, por exemplo, utilizando um chip de velocidade mais elevada, etc'.

• Evite "inteligentes" protocolos entre componentes.

• Um código de trabalho em HDL é mais preciosa do que em outros softwares, como hardware é tão difícil de depuração, de modo a reutilização, e também considerar o uso de "bibliotecas" de módulos que alguns são gratuitos e outros vendidos.

• projeto deve considerar não só bugs no código HDL, mas também falhas no chip que você está programando, e em outros dispositivos de hardware que fazem interface com o chip, assim que se deve realmente pensar sobre um projeto que é fácil de Verifica.

Algumas dicas de depuração:

• Se um design inclui vários blocos de construção, seria provavelmente deseja criar linhas das interfaces entre os blocos para testar pontos fora do chip.

• Você vai querer salvar linhas suficientes em seu projeto para desviar dados interessantes a serem inspecionados com dispositivos externos. Também é possível usar estas linhas, e seu código como uma maneira de dizer-lhe o estado actual da execução - por exemplo, se você receber dados em algum ponto, você escrever algum valor para as linhas, numa fase posterior da execução você escreve um outro valor, etc'

  Se o seu chip é reconfigurável isso vai se tornar ainda mais acessível, como você pode testes específicos sob medida, e reprogramar as saídas para cada teste que você vá (isso parece muito bem com leds :). )

Editar:

Por protocolos inteligentes, eu quis dizer que deveria duas das suas unidades físicas ligar, eles devem se comunicar com o simples protocolo de comunicação disponível. isto é, não use quaisquer protocolos caseiros sofisticados, entre eles.

A razão, é esta - Fidning bugs "dentro" de um FPGA / ASIC é reletivly fácil como você tem simuladores. Então, se você tem certeza de que os dados vem como você deseja que ele, e sai como o programa envia, você alcançou utopia Hardware - ser capaz de trabalhar a nível software :) (com o simulador). Mas se seus dados não chegar até você, do jeito que você quer, e você tem que descobrir por que ... você vai ter que ligar para as linhas, e isso não é assim tão fácil.

Encontrar um bug nas linhas, é duro como você tem que ligar para as linhas com equipamentos especiais, que registram os estados das linhas, em momentos diferentes, e você tem que ter certeza de suas linhas agem de acordo com o protocolo.

Se você precisa conectar dois de suas unidades físicas fazer o "protocolo" tão simples quanto possível, até o ponto que não será chamado um protocolo :) Por exemplo, se as unidades compartilham um relógio, adicionar linhas x de dados entre eles, e fazer uma gravação unidade daqueles ea outra unidade de leitura, passando, assim, uma "palavra" que tem x bits entre eles em cada queda relógio, por exemplo. Se você tem FPGA de, caso a taxa de clock original seja muito rápido para dados paralelos - você pode controlar a velocidade deste, de acordo com suas experiências, por exemplo tornando a estadia dados sobre linhas de ciclos, pelo menos, 't' relógio etc'. Presumo transferência de dados paralela é mais simples, como você pode trabalhar com a menor taxa de relógios e obter os mesmos desempenhos, sem a necessidade de dividir as suas palavras em uma unidade, e remontar no outro. (Espera-se que não há atraso entre a 'relógio' cada unidade recebe). Mesmo esta é provavelmente demasiado complexo:)

Em relação SPI, I2C etc' Eu não implementado qualquer um deles, Eu posso dizer que eu tenho ligado pernas de dois FPGA está sendo executado a partir do mesmo relógio, (não me lembro a formação exata de resistores no meio), a taxas muito mais elevadas, então eu realmente não posso pensar em uma boa razão para usar aqueles, como a principal forma de passar dados entre seu próprio FPGA de, a menos que os do FPGA estão localizados muito longe um do outro, que é uma razão para usar uma série ao invés de um barramento paralelo.

JTAG é usado por algumas empresas FPGA, para test / programar seus produtos, mas não tenho certeza se for usado como forma de transportar dados em altas velocidades, e é um protocolo de ... (ainda um que pode ter algum built-in com o apoio chip).

Se você tem que implementar qualquer protocolo conhecido, considere o uso de um código HDL pré-fabricados para isso -. Que pode ser encontrado ou compra

Answer 5

Esta é a pergunta que exige 10 mandamentos de JBDAVID para o projeto de hardware.

1. Use Controle de Revisão / Versão, assim como em Software. SVN e Hg são livres.
2. Exigir o código para passar verificação de sintaxe antes do check-in. Uma ferramenta LINT é melhor.
3. Use um Hardware-força total Verificação Idioma para o projeto de Verificação. System-Verilog é quase uma escolha segura.
4. Bugs trilha. Bugzilla e mosquitos são ferramentas livres. FogBugz requer um pouco de $.
5. Use afirmações em questões de captura com uma utilização incorrecta.
6. A Tríade Cobertura faz para um projeto estável:. Medir a cobertura de código, cobertura funcional e cobertura de declaração na ferramentas tanto de simulação e formais
7. O poder é King:. Uso CPF ou UPF para captura, fiscalizar e verificar o seu Power-Intenção
8. o projeto real é muitas vezes sinal misto, usar uma linguagem Mixed-Signal para verificar o analógico com o digital. Verilog-AMS é de uma tal solução. Mas não exagere. modelagem número real pode realizar a maioria dos aspectos funcionais do comportamento de sinal misto.
9. Use a aceleração de hardware para validar o software que tem de trabalhar com o silício!
10. Sintaxe editores de texto Consciente para a sua HDL / HVL são um requisito mínimo para desenvolvedor IDE.

Answer 6

Para FPGAs, Xilinx tem desta página . Quase todos se aplicaria a outros fornecedores FPGA ou possa ter regras equivalentes. Uma grande parte é aplicável a projetos ASIC.

A Intel tem HDL Coding Estilos recomendados e recomendações de projeto (PDF) debaixo desta página .