Existem bibliotecas de código aberto para VHDL da mesma forma que para C ++ ou python?


11

Quando estou abordando um problema em C ++ ou python, existem muitas bibliotecas que fazem o trabalho pesado do meu código. Estou pensando em GNU GSL , BOOST ou FFTW para C ++ e NumPy ou SciPy para python. De muitas maneiras, o fato de esses recursos existirem vale a pena a codificação nessas respectivas linguagens, pois as bibliotecas impedem que você tenha que reescrever todas as coisas de baixo nível do zero.

As bibliotecas padrão do IEEE parecem cobrir apenas o básico, como tipos de dados (meio que parecido com as bibliotecas padrão C).

Parece que em VHDL, você pode comprar / encontrar alguns "Núcleos IP" que resolverão um problema, em vez de usar uma biblioteca de código aberto. Em python, se eu quero falar com um dispositivo serial, eu simplesmente import serialacabei. Em VHDL, eu ficaria preso escrevendo um protocolo serial do zero ou teria que pesquisar nos vários repositórios até encontrar alguém que tivesse produzido algo que funcionasse. Eu estaria então corrigindo bits de código no meu projeto, em vez de apenas incluir algo e chamar isso. De maneira semelhante, se eu quiser executar uma FFT, posso encontrar exemplos de FFTs em VHDL via google, mas não há algo simples como FFTW que eu possa encontrar.

Existem bibliotecas de código aberto abrangentes disponíveis que eu possa importar para meus projetos? Por que todos parecem lançar seu próprio código para tantas das mesmas coisas?


2
Você pesquisou opencores.org?
Marku

3
Para bibliotecas de verificação VHDL, consulte osvvm.org
Jim Lewis

Na área externa, você também pode comprar bibliotecas de várias fontes. Você passará algum tempo com a maioria dos núcleos de opencores, pois a maioria não está bem documentada.
Voltage Spike

Respostas:


14

Sou desenvolvedor e mantenedor da ' The PoC Library '. Tentamos fornecer uma biblioteca composta por pacotes (coleção de novos tipos e funções) e módulos. Ele vem com quinos comuns, aritmética, componentes de relógio cruzado, componentes de E / S de baixa velocidade e uma pilha Ethernet / IP / UDP (próxima versão).

Como o @crgrace descreveu, é bastante complicado projetar módulos, que:

  • trabalhar em muitas plataformas
  • suporta a maioria das cadeias de ferramentas de fornecedores
  • adicione nenhuma / menos sobrecarga

Nossa biblioteca possui um mecanismo de configuração interno (PoC.config) para distinguir fornecedores, dispositivos e até subfamílias de dispositivos para escolher o código certo ou uma implementação otimizada. Também distingue entre código de síntese e simulação em alguns pontos.

Por exemplo, PoC.fifo_cc_gotum FIFO com uma interface de 'relógio comum' (cc) e sinais de entrada / saída para controlar o fifo. O fifo é configurável em larguras, profundidades, bits de estado de preenchimento e tipo de implementação. É possível escolher um tipo de implementação de RAM baseada em LUT ou On-Chip-RAM (ocram). Se este fifo é sintetizado com a opção ocram para Altera, ele usa altsyncram; se o Xilinx for escolhido, ele usará uma descrição genérica do BlockRAM e implementará a aritmética do ponteiro por instanciação explícita da cadeia de transporte (o Xilinx XST não encontra a solução ideal, por isso é feito manualmente).

Existem outros 2 tipos de fifo com interface 'clock dependente' (dc) e clock independente (ic). Portanto, se for necessário alternar de um fifo normal para um fifo de relógio cruzado (PoC.fifo_ic_got), altere o nome da entidade, adicione um relógio e redefina o domínio do segundo relógio, isso é tudo.

Acho que isso prova que é possível escrever módulos comuns, que funcionam em várias plataformas e compilam em diferentes ferramentas (Spartan-> Virtex, Cyclone -> Stratix; ISE, Vivado, Quartus).

Além do PoC, existem outras bibliotecas de código aberto:


Os projetos "Descubra silício livre e de código aberto" ( FOSSi ) no GitHub oferecem um banco de dados navegável de todos os projetos do GitHub que usam principalmente , , ou qualquer outra linguagem importante de descrição de hardware ( ).

Veja também:


+1 por mostrar o que você fez e também o que os outros fizeram. Boa lista longa.
Mister Mystère

3

Bibliotecas de código aberto como você descreve não seriam tão úteis para VHDL ou Verilog quanto para uma linguagem de programação de uso geral. Isso ocorre porque COMO você implementa uma determinada função pode depender muito do que você está tentando fazer. Código que é bom e FPGA provavelmente não é tão bom para um ASIC e vice-versa.

Além disso, como estamos descrevendo o hardware, uma função que executa uma FFT exigiria detalhes específicos como largura da palavra e relógio e estratégia de redefinição que amarraria suas mãos e restringiria todo o seu design. Se você tornasse a função muito flexível, ela teria uma sobrecarga enorme.

Por fim, observe o tamanho do seu executável quando você inclui muitas bibliotecas em C, por exemplo. Há uma tonelada de inchaço lá. Isso não importa para o desenvolvimento de software (na maioria das vezes), mas importa muito para o FPGA e, especialmente, o desenvolvimento do ASIC. Não faz sentido sintetizar um monte de sobrecarga que você não precisa.

Portanto, a conclusão é que não existem bibliotecas e sua abordagem atual é sólida.


Os geradores de núcleos alternativos (IP) também oferecem os riscos do Scylla e Chabydris de travamento do fornecedor e inchaço resultante. As capacidades de FPGA e ASIC cresceram o suficiente para suportar inchaço, o problema então custa e teste, ajudado pela padronização de inchaço (por exemplo, AMBA AXI4). A troca do Time To Market versus "despesas gerais desnecessárias" já é feita por indústrias inteiras. Projeto de sistema usando blocos de construção em vez de design de hardware, este último o suporte do VHDL.
User8352

Seu terceiro parágrafo é bastante ignorante de como os compiladores e as ferramentas de síntese funcionam - as ferramentas devem descartar as coisas que não são necessárias e os resultados não utilizados, provavelmente até mais em uma configuração de lógica digital do que em uma biblioteca de idiomas de alto nível, onde pode haver alguma informação local. variáveis ​​e alocações de memória que são sobrecarga da abstração da biblioteca, especialmente se ele estiver vinculado dinamicamente.
Chris Stratton

2

VHDL e Verilog são linguagens descritivas e descrevem blocos de hardware. Um driver serial em C ++ pode ser convertido em um IP serial em VHDL / Verilog.

O opencores.org é o maior banco de dados de código aberto até o momento.

Para facilitar o processo de pesquisa, download e navegação de código (via Github), você pode usar esta interface moderna:

http://freerangefactory.org/cores.html

Se, por exemplo, você procurar por serial, poderá terminar aqui:

http://freerangefactory.org/cores/communication_controller/serial_uart_2/index.html

e pule diretamente para o código no GitHub. Lá você verá que é fácil instanciar o módulo serial, conectar seu próprio circuito a ele e começar a enviar e receber dados. Isso é tão simples quanto as bibliotecas seriais em C ++.

Eu espero que isso ajude.


0

O primeiro site que vou para esse tipo de coisa (como o @MarkU mencionou) é opencores.org.

Por exemplo, há um mecanismo FFT parametrizado , escrito em VHDL, lançado sob a licença BSD. O status é "beta".


não é isso que o OP pede. Ele ou ela conhece o opencores.org Um mecanismo FFT parametrizado está muito longe de importar uma biblioteca matemática padrão no Python e usá-la. Não existe "middleware" no hardware por causa da sobrecarga.
Crcrace

0

Para verificação, existe a metodologia de verificação de código aberto VHDL (OSVVM).
O OSVVM é uma metodologia abrangente e avançada de verificação de VHDL que simplifica a implementação de cobertura funcional, aleatória restrita e Randomização Inteligente de Cobertura (uma metodologia inteligente de bancada de testes). Também facilita a implementação de arquivos de transcrição compartilhados, relatórios de erros, logs (impressão condicional) e modelagem de memória.

O site e o blog da OSVVM estão em http://osvvm.org . Os pacotes também estão disponíveis no github em: https://github.com/JimLewis/OSVVM

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.