Ana Rita Diniz da Cruz Trajano

Plataforma Web de suporte à aprendizagem de

Design de Hardware em SystemVerilog

Campina Grande, Paraíba

Junho de 2023
 Ana Rita Diniz da Cruz Trajano

Plataforma Web de suporte à aprendizagem de Design de

Hardware em SystemVerilog

Trabalho de Conclusão de Curso de Bachare-

lado submetido à Coordenadoria de Gradua-
ção em Engenharia Elétrica da Universidade
Federal de Campina Grande como parte dos
requisitos necessários para a obtenção do grau
de Bacharel em Ciências no Domínio da En-
genharia Elétrica

Universidade Federal de Campina Grande Ű UFCG

Centro de Engenharia Elétrica e Informática Ű CEEI
Departamento de Engenharia Elétrica Ű DEE

Orientador: Gutemberg Gonçalves dos Santos Júnior, Dr.

Campina Grande, Paraíba

Junho de 2023
 Ana Rita Diniz da Cruz Trajano

Plataforma Web de suporte à aprendizagem de Design de

Hardware em SystemVerilog

Trabalho de Conclusão de Curso de Bachare-

lado submetido à Coordenadoria de Gradua-
ção em Engenharia Elétrica da Universidade
Federal de Campina Grande como parte dos
requisitos necessários para a obtenção do grau
de Bacharel em Ciências no Domínio da En-
genharia Elétrica

Trabalho aprovado. Campina Grande, Paraíba, 27 de junho de 2023:

Gutemberg Gonçalves dos Santos

Júnior, Dr.
Orientador

Marcos Ricardo Alcântara de Morais,

Dr.
Avaliador

Campina Grande, Paraíba

Junho de 2023
Soli Deo Gloria
 Agradecimentos

Agradeço a Deus pelo dom da vida, da salvação, do sustento e do Propósito. Aos

meus pais, Zé Ivan e Cida, que nunca mediram esforços para garantir minha educação e
apoiaram a menina que iniciou esta graduação. Ao meu irmão Júnior, por todo apoio e
amizade.
Agradeço ao meu esposo, Léo, pelo companheirismo, pela compreensão, pelas doses
de motivação, por vezes tão necessárias, e por tornar esta etapa da caminhada muito mais
fácil de ser vivida e superada. A conquista, de fato, não é só minha, é dele também.
Agradeço aos tantos amigos que pude fazer nesta jornada. Às amigas Rebeca
Thaiana, Margareth Mee, Duda e Yasmin, que tornaram os dias em Campina Grande
muito melhores. Aos colegas do período 2018.1 Gabrielle, Letícia, João Pedro, Pedro
Henrique, Rodrigo, Heriberto, Gabriel, Breno, Vilar, Ezequiel, Helder, Petrúcio e Alan,
por dividirem tantas matérias, trabalhos e desaĄos. E aos demais, no curso e do grupo
Missão Federal, que cruzaram o meu caminho e dividiram dias comigo na UFCG.
Agradeço aos diversos professores que pude conhecer e admirar ao longo do curso.
Para tanto, cito meu orientador Gutemberg Junior, por tanta excelência proĄssional e
interpessoal demostrada em sua atuação acadêmica, e o professor Marcos Morais, com o
qual tive o privilégio de aprender tanto em projetos de capacitação pelo XMEN. Que a
motivação para o ensino nunca lhes falte.
Por Ąm, agradeço à menininha em meu ventre Áster, por ser minha companheira
inseparável nesta fase Ąnal e por torná-la um tanto mais desaĄadora. Ainda não te conheço,
minha Ąlha, mas te amo muito.
ŞHá pessoas que desejam saber só por saber, e isso é curiosidade; outras, para alcançarem
fama, e isso é vaidade; outras, para enriquecerem com a sua ciência, e isso é um negócio
torpe; outras, para serem ediĄcadas, e isso é prudência; outras, para ediĄcarem os outros,
e isso é caridade
(Agostinho de Hipona)
 Resumo
Neste trabalho propõe-se a construção do protótipo de uma plataforma web que auxilie
os estudantes no processo de aprendizagem da Linguagem de Descrição de Hardware
SystemVerilog, proporcionando uma diminuição de barreiras ferramentais e um enfoque
prático ao ensino, a partir de um ambiente simples para execução dos códigos e a partir
da validação imediata de cumprimento dos objetivos das atividades.

Palavras-chave: SystemVerilog. Sistema de gerenciamento de aprendizagem. Simulação.

VeriĄcação Automática.
 Abstract
This work proposes the construction of a prototype of a web platform that helps students
in the process of learning the SystemVerilog Hardware Description Language, providing
a reduction in tool barriers and a practical approach to teaching, based on a simple
environment for execution of the codes and from the immediate validation of fulĄllment of
the activity objectives.

Keywords: SystemVerilog. Learning Management System. Simulation. Automated Check-

ing.
 Lista de ilustrações

Figura 1 Ű Jornadas de Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Figura 2 Ű Arquitetura em Camadas . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figura 3 Ű Interface do Fliplot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figura 4 Ű Diagrama Entidade Relacionamento . . . . . . . . . . . . . . . . . . . 28
Figura 5 Ű Tela de Login da aplicação . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figura 6 Ű Tela de Consulta das Atividades . . . . . . . . . . . . . . . . . . . . . . 29
Figura 7 Ű Tela de Detalhamento de uma Atividade . . . . . . . . . . . . . . . . . 30
Figura 8 Ű Tela de Inclusão de Atividade - Parte 1 . . . . . . . . . . . . . . . . . . 30
Figura 9 Ű Tela de Inclusão de Atividade - Parte 2 . . . . . . . . . . . . . . . . . . 31
Figura 10 Ű Tela de Inclusão de Atividade - Parte 3 . . . . . . . . . . . . . . . . . . 31
Figura 11 Ű Tela de Inclusão de Atividade - Parte 4 . . . . . . . . . . . . . . . . . . 32
Figura 12 Ű Tela de Detalhamento de uma Turma . . . . . . . . . . . . . . . . . . . 32
Figura 13 Ű Tela de Detalhamento de Submissões por Atividade . . . . . . . . . . . 33
Figura 14 Ű Tela de Vínculo de Novas Atividades a uma Turma . . . . . . . . . . . 33
Figura 15 Ű Tela de Consulta das Atividades e Submissões do Aluno . . . . . . . . 34
Figura 16 Ű Tela de Submissão Pós-Simulação . . . . . . . . . . . . . . . . . . . . . 34
Figura 17 Ű Arquitetura Geral do Sistema . . . . . . . . . . . . . . . . . . . . . . . 35
 Lista de tabelas

Tabela 1 Ű Requisitos do Sistema para área do Professor na linguagem Gherkin . . 18

Tabela 2 Ű Requisitos do Sistema para área do Aluno na linguagem Gherkin . . . 20
 Lista de abreviaturas e siglas

HDL Hardware Description Language

HTML HyperText Markup Language

CSS Cascading Style Sheets

SQL Structured Query Language

API Application Programming Interface

REST Representational State Transfer

Java EE Java Platform Enterprise Edition

CORS Cross-Origin Resource Sharing

IDE Integrated Development Environment

HTTP HyperText Transfer Protocol

JPA Java Persistence API

BDD Behavior Driven Development

 Sumário

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 REVISÃO DA LITERATURA . . . . . . . . . . . . . . . . . . . . . . 14

3 REQUISITOS E ESPECIFICAÇÕES . . . . . . . . . . . . . . . . . . 17
3.1 Fluxos de Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Princípios Arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 TECNOLOGIAS UTILIZADAS . . . . . . . . . . . . . . . . . . . . . 23
4.1 Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Java e Spring Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3 ApiREST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.5 SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.6 Icarus Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.7 Fliplot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.8 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 PROJETO E IMPLEMENTAÇÃO . . . . . . . . . . . . . . . . . . . 27
5.1 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3 Telas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3.1 Área do Professor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3.2 Área do Aluno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.4 Arquitetura Geral do Sistema . . . . . . . . . . . . . . . . . . . . . . . 35

6 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
 12

1 Introdução

As Linguagens de Descrição de Hardware são ferramentas que, como subentende

a própria terminologia, descrevem a estrutura e o comportamento do hardware. Elas
distinguem-se das linguagens de software, que por sua vez, são comumente orientadas a
uma sequência de passos executáveis que deĄnem um algoritmo usual. Tal característica,
quando comparada as linguagens de software, podem tornar as HDLs potencialmente
difíceis para a assimilação no processo de aprendizagem. Concomitantemente, a maioria
das ferramentas ligadas a elas apresentam uma característica de voltada à indústria, sendo
assim, ferramentas fechadas e de complexa conĄguração.
Devido aos fatores apresentados, propõe-se neste trabalho a construção de uma
plataforma web que auxilie os estudantes no processo de aprendizagem da Linguagem
de Descrição de Hardware SystemVerilog denominada SV Checking. Pretende-se assim,
proporcionar uma diminuição de barreiras ferramentais e um enfoque prático, por meio da
proposta de atividades prontamente validadas.

1.1 Objetivos
1.1.1 Objetivo Geral

• Propor e desenvolver o protótipo de uma plataforma Web para apoiar a aprendizagem

de SystemVerilog, levando em consideração a relação professor-aluno.

1.1.2 Objetivos Específicos

• DeĄnir funcionalidades e requisitos da plataforma;

• Desenvolver o projeto backend do sistema, de maneira que permita a simulação de

designs em SystemVerilog;

• Desenvolver o projeto frontend da aplicação.

1.2 Metodologia
A princípio, foi implementado um protótipo, na linguagem Java e utilizando o
framework Spring Boot, que constituiu, de forma simples, a funcionalidade principal
objetivada para a plataforma. Esse protótipo apresentou a característica de iniciar a
simulação de um design escrito em SystemVerilog partindo de informações e de comandos
Capítulo 1. Introdução 13

de uma página Web, a qual foi feita utilizando o framework Angular, HTML, CSS e
TypeScript.
Com o suporte obtido a partir da construção do protótipo da funcionalidade
principal, foi deĄnido o fluxo de interação da aplicação com o usuário - incluindo funções
e requisitos secundários, o fluxo de arquitetura e o da estrutura do sistema de Banco de
Dados.
Em posse da proposta da plataforma, especiĄcada tecnicamente, foram previstas e
construídas as telas que compõem a interface gráĄca da plataforma e o projeto backend
necessário, utilizando as mesmas linguagens e tecnologias usadas inicialmente para o
protótipo, ajustou-se a comunicação entre eles de forma que se obteve uma aplicação
integrada, a qual interage com o usuário satisfatoriamente.
Em seguida, foram implementados o sistema de banco de dados e toda sua comuni-
cação com o backend, considerando ações e consultas desse último sobre o banco, para
garantir a persistência de dados da aplicação.
Por Ąm, foram feitos eventuais ajustes no código-fonte, além da escrita e da revisão
do trabalho.

1.3 Organização do Trabalho

O trabalho está estruturado em 6 capítulos, incluindo este introdutório, conforme
a seguir.
O Capítulo 2 apresenta uma Revisão da Literatura relacionada ao objetivo deste
trabalho.
No Capítulo 3 estão detalhados Requisitos e EspeciĄcações objetivados com a
implementação.
O Capítulo 4 descreve as Tecnologias Utilizadas no desenvolvimento da aplicação.
No Capítulo 5 são apresentados os aspectos de Projeto e Implementação utilizados.
Por Ąm, no Capítulo 6, têm-se as considerações Ąnais e os pontos de continuidade
do trabalho.
 14

2 Revisão da Literatura

Neste capítulo, será apresentada uma revisão da literatura no que se refere a

propostas de plataformas que buscam melhoria da aprendizagem e ensino de HDLs.
Para tal revisão, foi utilizada a base do IEEE e o seu recurso de pesquisa avançada,
a Ąm de serem Ąltrados documentos de interesse. A busca foi feita por documentos com as
seguintes características: que possuíssem em seu resumo os vocábulos HDL, SystemVerilog,
Verilog ou VHDL, combinados com a presença das palavras ŞassessmentŤ, ŞlearningŤ ou
ŞteachingŤ, e, ainda, pelo menos um dentre os termos ŞtoolŤ, ŞplatformŤ, ŞsoftwareŤ ou
ŞappŤ; foi aplicado um Ąltro quanto aos anos de publicação, restringindo-os aos últimos 10
anos (2013-2023), e outro quanto aos tipos de documentos, no qual documentos que se
referissem a livros foram retirados dos resultados.
Em termos práticos, além dos Ąltros de ano de publicação e tipo de documento cita-
dos, esta foi a busca utilizada: (((Abstract:SystemVerilog) OR (Abstract:Verilog) OR (Abs-
tract:VHDL) OR (Abstract:HDL)) AND ((Abstract:assessment) OR (Abstract:learning) OR
(Abstract:teaching)) AND ((Abstract:tool) OR (Abstract:platform) OR (Abstract:software)
OR (Abstract:app))).
A pesquisa mencionada na base de dados IEEE Xplore retornou 127 resultados, os
quais, após uma análise de título e resumo, foram reduzidos a 10. Tal redução ocorreu
porque diversas publicações não apresentavam propostas conforme o objetivo desta revisão,
ou seja, a maioria não se referia a propostas que objetivavam melhorar o ensino/aprendizado,
propriamente dito, de Linguagens de Descrição de Hardware, apesar de estarem relacionadas
a elas de alguma forma, ou propunham metodologias, cursos, mudanças nos assuntos
abordados em salas de aula, e não ferramentas, para a Ąnalidade em questão.
Primeiramente, Becker (2014) propõe uma ferramenta de aprendizagem online
baseada em PSHDL (Plain Simple Hardware Description Language). Para tal, utiliza-se de
argumentos quanto às ferramentas complexas que acompanham linguagens como Verilog e
VHDL e, apesar de citar o paradigma de programação diferenciado dessas linguagens, que
não são sequenciais, a nova linguagem de programação citada mantém a característica de
paralelismo, apresentando, no entanto, um Şfluxo de trabalho melhoradoŤ em relação às
convencionais.
Morgan et al. (2018), por sua vez, tem como proposta a plataforma ViciLogic 2.0,
a qual é deĄnida como escalável e distribuída. Os objetivos apresentados para ela são de
aprendizado online, prototipagem de hardware a partir de projetos com origem VHDL
ou Verilog criados, simulados e sintetizados no Vivado, apresentação de um aplicativo
cliente e de uma plataforma criadora de cursos para sistemas digitais. Essa plataforma
Capítulo 2. Revisão da Literatura 15

inclui aulas guiadas, monitoramento para progressão automática do curso, veriĄcações de

conhecimento e sandbox do usuário.
Haase (2018) e Haase (2022) trata-se de publicações que descrevem a mesma
ferramenta, chamada LogicCircuits. Ela é interativa e tem um enfoque voltado à interface
de diagramas de blocos. Uma função que fazem tais documentos pertinentes de serem
citados na presente revisão é a de exportação dos circuitos modelados na linguagem VHDL.
Os artigos de Ayodele, Inyang e Kehinde (2015), Canesche et al. (2021) e Luković et
al. (2017) abordam, em seus conteúdos, laboratórios feitos em ambiente educacional com
objetivos diversos de aprendizado no que se refere às linguagens de descrição de hardware.
Ayodele, Inyang e Kehinde (2015) busca que os alunos implementem máquinas de estado
Ąnito em VHDL, por meio de um laboratório remoto proposto denominado Advanced
Digital Lab; Canesche et al. (2021) propõe extensões a serem utilizadas para o Google
Colab, com o intuito de ensinar arquiteturas de design de circuitos lógicos, linguagem
Verilog, processador e GPU; e Luković et al. (2017) objetiva a projeção de circuitos digitais
no software Xilinx ISE Design Suite, propondo a realização de um experimento e o fluxo
para ele.
Duas propostas concentram-se na linguagem VHDL: Mosbeck, Hauer e Jantsch
(2018) apresenta o sistema VELS, o qual possui avaliação automática de designs e fun-
cionalidades de interesse no fluxo professor-aluno, sendo relatada também a experiência
de utilização dessa plataforma com cerca de 1000 alunos; e o Kumar, Panicker e Kassim
(2013) que, ao apresentar o quanto os ambientes de desenvolvimento direcionados às HDLs
são voltados ao ambiente proĄssional e não adequados para a introdução educacional,
justiĄca sua proposição de um aplicativo que apresenta um ambiente leve, que roda em
diversas plataformas e que gera feedback aos programas dos alunos, por meio de correção
funcional. Esse último também está em experimentação relatada em artigo, sendo ela por
dois semestres na National University of Singapore.
Com o foco em SystemVerilog, Kohútka e Stopjaková (2018) construiu um software
denominado ChipDE, o qual pode ser deĄnido como uma IDE voltada para a linguagem
em questão. A IDE possui recursos como edição de texto, navegador de arquivos/projetos,
realce de sintaxe, preenchimento automático de código, desenho de diagrama de blocos,
geração de código SystemVerilog a partir de diagramas de blocos e vice-versa. Essa
plataforma também se apresenta motivada pela característica das ferramentas atuais
utilizadas, as quais são bem menos eĄcientes e menos soĄsticadas que as utilizadas no
contexto de software para desenvolvimento.
A partir da revisão feita, Ąca evidente a existência da problemática motivadora
deste trabalho, que aponta para as grandes barreiras ferramentais existentes no contexto
das linguagens de descrição de hardware. Kohútka e Stopjaková (2018) apresentou-a em
contexto de desenvolvimento, mas este trabalho dedica-se ao contexto inicial de aprendizado
Capítulo 2. Revisão da Literatura 16

e leva em consideração a relação professor-aluno, assim como Mosbeck, Hauer e Jantsch

(2018) e Kumar, Panicker e Kassim (2013), entretanto, para a linguagem SystemVerilog.
Nascimento e Sibuya (2021) é uma produção em português, a qual não consta na base
de dados objeto da revisão, mas que também foi referência metodológica para a presente
produção.
 17

3 Requisitos e EspeciĄcações

Nesta seção serão apresentadas as jornadas de usuário, os requisitos e a arquitetura

adotada para o sistema.

3.1 Fluxos de Usuário

Com o intuito de obter maior assertividade na estruturação dos requisitos, foram
mapeados fluxos de ações simples necessários para cada tipo de usuário, aluno e professor,
em interação com a plataforma, conforme resume a Figura 1.

Figura 1 Ű Jornadas de Usuário

Fonte: Autoria Própria

Em um primeiro momento, o professor deve criar uma atividade, a partir da

inserção de descrição, de informações e de arquivo necessários para o entendimento do
aluno quanto à atividade e para o teste da submissão do aluno. Após isso, o professor
deve criar uma turma e cadastrar alunos associando-os a ela. Em seguida, associar a
atividade já cadastrada na plataforma à turma, estabelecendo uma data limite de entrega,
possibilitando que uma mesma atividade possa estar relacionada a turmas diferentes com
datas limites diferentes.
Com o término da etapa anterior, os alunos têm a possibilidade de consultar
as atividades requisitadas à turma em que eles estão incluídos, podem acessar uma
atividade, consultar as instruções e elaborar um código. Ao concluir o código, o aluno
tem a possibilidade de testar sua implementação com os arquivos gerados pelas ações do
Capítulo 3. Requisitos e EspeciĄcações 18

professor na criação da atividade, recebendo o resultado da execução pela plataforma,

como também baixar a forma de onda para visualização em uma ferramenta externa.
Após isso, tanto professor quanto aluno podem consultar informações resultados
das submissões que se relacionam a eles.
Tais fluxos de usuário permitiram compreender as ações na plataforma cronologica-
mente e a necessidade das funcionalidades na aplicação. Com essa análise, foram possíveis
as deĄnições de requisitos para que a plataforma supra as necessidades elencadas.

3.2 Requisitos
Baseado nos fluxos propostos, foram mapeadas as funcionalidades que o sistema
deve apresentar para os dois tipos de usuário e escritas como requisitos na linguagem
Gherkin. Esse tipo de linguagem é utilizado na abordagem de desenvolvimento caracterizada
como BDD (Behavior Driven Development), a qual se caracteriza como uma técnica de
desenvolvimento ágil com o intuito de diminuir diĄculdades de comunicação, permitindo
que todos os membros de uma equipe utilizem uma mesma linguagem para realizar o
trabalho: o cliente, a área de negócio, a área de testes e os desenvolvedores.
A linguagem Gherkin caracteriza-se pela descrição de características de interesse
por meio de cenários simples, usando palavras-chave como ŞDadoŤ, ŞQuandoŤ e ŞEntãoŤ, a
Ąm de evitar ambiguidades (PAPADOPOULOS et al., 2017). As Tabelas 1 e 2 condensam
os requisitos, a partir dos aspectos da linguagem como colunas. Esta linguagem é utilizada

Tabela 1 Ű Requisitos do Sistema para área do Professor

na linguagem Gherkin
Dado
Um professor cadastrado
acessando a tela
de ŚLoginŠ da aplicação
Um professor logado
acessando a tela
de ŚHomeŠ da aplicação
Quando Então
Insere as informações
O sistema valida as informações
corretas de ŚUsuárioŠ,
e direciona para a tela ŚHomeŠ
ŚSenhaŠ, escolhe o tipo
do Professor com as opções
de usuário ŚProfessorŠ e
ŚTurmasŠ e ŚAtividadesŠ
pressiona o botão ŚEntrarŠ
O sistema lista as atividades
vinculadas ao professor
Pressiona a opção
com nome e a opção de
ŚAtividadesŠ
deletar, além de um botão
ŚNova AtividadeŠ
Capítulo 3. Requisitos e EspeciĄcações
Um professor logado
acessando a tela
que lista suas atividades
Um professor logado
acessando a tela
que lista suas atividades
Um professor logado
acessando a tela
de conĄrmação Ąnal
da criação da atividade
Um professor logado
acessando a tela
de ŚHomeŠ da aplicação
Um professor logado
acessando a tela
que lista suas turmas
19
O sistema lista nome, descrição,
entradas e saídas da atividade,
Pressiona o link
além de opções para baixar
do nome de uma das
arquivos gerados para testar
atividades listadas
a submissão do aluno para
aquela atividade
O sistema direciona a uma
sequência de telas em que o
professor entrará com as infor-
mações de nome, descrição
e tipo da atividade, quantidades,
Pressiona o botão nomes e tamanhos de entradas
ŚNova AtividadeŠ e saídas, o Golden Design e
o arquivo de especiĄcação
das entradas a serem testadas
nas submissões dos alunos,
além de uma conĄrmação Ąnal
para a criação da atividade
O sistema salva a
Pressiona o botão atividade criada e volta
ŚCriar AtividadeŠ à tela que lista as ativi-
dades ligadas ao professor
O sistema lista as turmas
vinculadas ao professor
Pressiona a opção
com nome e a opção de
ŚTurmasŠ
deletar, além de um botão
ŚNova TurmaŠ
O sistema lista os alunos
ligados à turma, com nome,
username, e-mail e a opção
deletar; e lista as atividades
Pressiona o link
ligadas à turma, com nome,
do nome de uma das
data limite, opção de ŚVer
turmas listadas
SubmissõesŠ e opção de
delatar; além dos botões
ŚNovo AlunoŠ e ŚVincular
outras atividades à TurmaŠ
Capítulo 3. Requisitos e EspeciĄcações
Um professor logado
acessando a tela
que detalha uma turma
Um professor logado
acessando a tela
que detalha uma turma
Um professor logado
acessando a tela
que detalha uma turma
Tabela 2 Ű Requisitos do Sistema para área do Aluno na
linguagem Gherkin
Dado
Um aluno cadastrado
acessando a tela
de ŚLoginŠ da aplicação
20
O sistema direciona à
tela de ŚRegistro de
Pressiona o botão
AlunoŠ, com os campos
ŚNovo AlunoŠ
nome, username, e-mail
e botão ŚRegistrarŠ
O sistema direciona à
tela de ŚVincular Novas
AtividadesŠ, a qual lista
Pressiona o botão atividades cadastradas que
ŚVincular outras atividades não estão vinculadas àquela
à TurmaŠ turma, com opção de seleção,
nome, descrição, campo para
entrada de data limite e
botão ŚVincular AtividadesŠ
O sistema lista o nome dos
alunos da turma com status
da última submissão salva
Pressiona o botão
por ele àquela atividade,
ŚVer SubmissõesŠ
além de opções para baixar
em uma atividade
arquivo VCD e de Design
dos alunos que já submeteram
àquela atividade
Fonte: Autoria Própria
Quando Então
Insere as informações
O sistema valida as informações
corretas de ŚUsuárioŠ,
e direciona para a tela ŚHomeŠ
ŚSenhaŠ, escolhe o tipo
do Aluno com a opção
de usuário ŚAlunoŠ e
ŚAtividadesŠ
pressiona o botão ŚEntrarŠ
Capítulo 3. Requisitos e EspeciĄcações 21

O sistema lista as atividades

Um aluno logado
acessando a tela
de ŚHomeŠ da aplicação
Um aluno logado
acessando a tela
que lista suas atividades
Um aluno logado
acessando a tela
de ŚSubmissõesŠ
Um aluno logado
acessando a tela
de ŚSubmissõesŠ
apresentando a opção
ŚSubmeterŠ
vinculadas à turma do aluno
com nome, data limite, status
Pressiona a opção e opção ŚAcessarŠ, além de
ŚAtividadesŠ opções para baixar arquivo
VCD e Design de atividades
que já tiveram submissões
feitas
O sistema direciona para a tela
de ŚSubmissãoŠ que lista nome,
Pressiona a opção
descrição, entradas e saídas
ŚAcessarŠ em uma das
da atividade, com um campo
atividades listadas
de texto para entrada do
Design e o botão ŚSimularŠ
O sistema apresenta na tela
a saída do simulador para
a co-simulação do design
submetido com o testbench
Preenche o campo de
da atividade, o status da
texto do Design e
submissão, um botão para
pressiona ŚSimularŠ
baixar o arquivo VCD, um
botão para abrir o visualiza-
dor de formas de onda
externo e um para ŚSubmeterŠ
O sistema salva a submissão
Pressiona o botão feita pelo aluno para aquela
ŚSubmeterŠ atividade e retorna à tela
que lista suas atividades.
Fonte: Autoria Própria

A escrita dos requisitos foi fundamental para deĄnir a criação dos componentes no
contexto de frontend, as requisições que devem estar previstas tanto em diferentes rotas
na API e quanto em comunicação ao banco de dados, além de demais métodos necessários,
no que tange ao backend e quais entidades devem existir em Banco para persistência
conveniente dos dados da aplicação.
Capítulo 3. Requisitos e EspeciĄcações 22

3.3 Princípios Arquiteturais

A arquitetura utilizada foi a arquitetura em camadas, a qual é a mais comum de ser
utilizada em aplicativos Java EE e se caracteriza pela organização em camadas horizontais,
cada uma desempenhando um papel especíĄco na aplicação. As camadas padrões são:
camada de apresentação, camada de negócios, camada de persistência e camada de banco
de dados. Essa separação funcional dos componentes em camadas propicia a construção
dos modelos de responsabilidade na arquitetura, facilitando o desenvolvimento, o teste, a
governança e a manutenção de aplicativos (RICHARDS, 2015).

Figura 2 Ű Arquitetura em Camadas

Fonte: (RICHARDS, 2015)

Na plataforma objeto deste trabalho, haviam requisições do usuário que não

precisavam de persistência em banco de dados, apenas realização de serviços, como criação
de arquivos e co-simulação de arquivos como o testbench da atividade e o design submetido
pelo aluno, não havendo necessidade de persistência de dados e salvamento em banco,
por hora. Dessa forma, utilizou-se uma camada de serviços entre a de negócio e a de
persistência, sendo uma camada aberta, ou seja, é possível que ela não esteja incluída em
alguns fluxos de requisições, e Ąm da requisição, em algumas ocasiões.
 23

4 Tecnologias Utilizadas

Neste Capítulo, serão detalhadas as principais tecnologias utilizadas no desenvolvi-

mento da aplicação.

4.1 Angular
O Angular (ŚAngular2Š ou ŚAngular2+Š) foi lançado em setembro de 2016 e se trata
de uma versão revolucionária do AngularJS, framework lançado em 2009 e que, devido
aos seus benefícios, foi posteriormente patrocinado pela Google. Desde sua versão anterior,
ele utiliza uma matriz de controladores e serviços com o intuito de criar aplicativos de
Śpágina únicaŠ, melhorando a experiência do usuário (SULTAN, 2017).
Tal framework possui diretivas de atributos, estruturais e até personalizadas que
aprimoram a capacidade dos elementos HTML, anexando comportamentos personalizados
à construção da tela. Além disso, o funcionamento de suas unidades-base (componentes)
combinam o elemento ŚViewŠ (arquivos estáticos referentes a construção da tela) e o
elemento ŚControllerŠ (código em linguagem de programação para que as ações resultantes
da interação em tela ocorram) em um só conteiner que lida com ambas as funcionalidades.
Ademais, o Angular, em relação a sua versão anterior, admite a utilização de
TypeScript, linguagem transpilada em JavaScript que possui o diferencial sobre essa última
de suportar ŚtipagensŠ de variáveis e classes (SULTAN, 2017).
No contexto da plataforma a qual se trata o presente trabalho, o Angular foi
utilizado para a implementação da interface gráĄca e de uma primeira camada de controle.
Foram criados componentes angular conforme as jornadas de usuário da Figura 1; foram
utilizadas as diretivas citadas, principalmente as estruturais, na construção das telas; e,
ainda, o suporte às classes do TypeScript permitiu que objetos trafegassem pelo frontend,
sendo utilizados para requisições à API, com atributos semelhantes aos objetos do backend.

4.2 Java e Spring Boot

A linguagem Java é orientada a objetos e possui como diferencial a sua compilação
para um bytecode, o qual é executado por uma máquina virtual. Essa característica garante
independência de plataforma em que o código está rodando (SINGER, 2003).
De acordo com Jovanović et al. (2017), o framework Spring, por sua vez, é a
estrutura Java mais popular e seus recursos permitem eĄciência no desenvolvimento de
aplicativos Web. São esses recursos:
Capítulo 4. Tecnologias Utilizadas 24

• Inversão de Controle, que se caracteriza por um controle de fluxo invertido no qual

as demandas de fontes externas assumem o controle do programa;

• Injeção de Dependências, que é um padrão da inversão de controle que diminui o

nível de acoplamento entre os componentes do programa, já que os módulos injetados
são objetos abstratos com implementação concreta;

• Aspecto de Orientação a objetos;

• JPA, que se trata de uma interface de mapeamento do estado do objeto para as

colunas do Banco de Dados.

Por sua vez, o Spring Boot foi projetado para simpliĄcação da utilização do Spring,
possuindo conĄguração automática, iniciador de dependências, possibilidade de controle
do aplicativo pelo console, etc (JOVANOVIĆ et al., 2017).
Neste projeto, foram utilizadas as facilitações citadas do Spring Boot sob um
projeto Maven. A injeção de dependência foi feita entre os componentes que constituem
diferentes camadas da arquitetura, as quais serão melhor explicadas no tópico que trata
do Projeto e Implementação do Backend, a orientação a objetos foi utilizada, de forma
que classes com nomes e atributos semelhantes às entidades de Banco foram criadas, a Ąm
de utilizar facilidades dos métodos JPA na camada de mapeamento.

4.3 ApiREST
APIRest trata-se de uma interface de programação de aplicações que utiliza o estilo
arquitetônico REST, o qual se trata de um estilo cliente-servidor sem estado que utiliza
restrições adicionais para conectar os componentes Web fornecendo uma interface uniforme.
Ele é caracterizado pelo uso de verbos HTTP (HTTP GET, POST, PUT, DELETE),
códigos de status autodescritivos para resposta e hipermídia como o mecanismo do estado
do aplicativo (DHALLA, 2021).
Para a API da aplicação em questão, foram utilizados os quatro verbos HTTP cita-
dos, os quais refletem alterações nos registros do Banco de Dados ao Ąm do processamento
dessas requisições de entrada, que chegam à API a partir do controle feito pelo frontend
após interações do usuário com a interface gráĄca.

4.4 MySQL
O MySQL trata-se de um servidor e gerenciador de Banco de Dados do tipo relaci-
onal, que possui licença de uso gratuita (MILANI, 2007). O tipo relacional é caracterizado
Capítulo 4. Tecnologias Utilizadas 25

pela representação dos dados em tabelas, nas quais cada linha é um registro que possui
uma chave única e as colunas são atributos quem compõem dados.

4.5 SystemVerilog
A linguagem de descrição de hardware SystemVerilog uniĄca design, especiĄcação e
veriĄcação de hardware e foi proposta para coexistir e aprimorar a HDL Verilog, buscando
aumento de produtividade. SystemVerilog permite veriĄcação em testbenchs com base em
metodologias manuais ou automáticas (IEEE. . . , 2018).
Devido ao fato da SystemVerilog derivar-se da Verilog, ensinada na graduação em
Engenharia Elétrica da UFCG, e ter a característica de suporte a testbenchs, constitui-se
como a HDL proposta e utilizada no contexto desta plataforma.

4.6 Icarus Verilog

O Icarus Verilog (WILLIAMS, 2020) apresenta-se como uma ferramenta de código
aberto que objetiva simular toda a linguagem de descrição de hardware Verilog do padrão
IEEE-1364 (IEEE. . . , 2006). Trata-se de um simulador com um bom suporte também
para SystemVerilog e, devido as suas características de licença e facilidade de instalação,
foi o simulador utilizado no escopo desta aplicação.

4.7 Fliplot
Fliplot é um projeto de código aberto (RACKS, 2021), disponível na Web, desen-
volvido utilizando Javascript e HTML com um backend em Python. Ele possui suporte a
arquivos VCD e uma interface gráĄca que permite análise de formas de onda ao longo do
tempo.
Considerando a possibilidade obter o arquivo VCD, com as formas de onda, ge-
rados pelo testbench em SystemVerilog, o projeto fliplot foi utilizado na aplicação como
visualizador externo para esses tipos de arquivo, havendo um botão para abrí-lo em uma
nova aba, após o arquivo VCD estar disponível para download pelo usuário.

4.8 Git
O sistema de armazenamento, organização, controle e versionamento utilizado no
contexto da implementação objeto deste trabalho foi o Git, ligado ao utilitário Github. O
Git apresenta licença de software livre e foi inicialmente idealizado por Linus Tovalds em
2005 para coordenação do desenvolvimento do Kernel do Linux (SPINELLIS, 2012).
Capítulo 4. Tecnologias Utilizadas 26

Figura 3 Ű Interface do Fliplot

Fonte: (RACKS, 2021)

 27

5 Projeto e Implementação

Neste Capítulo serão abordados tópicos referentes à construção da aplicação.

5.1 Backend
O Backend foi construído levando em consideração a arquitetura apresentada e,
dessa forma, o projeto foi dividido em três pastas principais:

• Controller: Pasta que se refere aos componentes de código referente às rotas da API,
deĄnindo a lógica de negócio do que estará disponível para consumo da API em
cada rota;

• Service: Pasta que se refere aos componentes de código intermediários, entre os

controllers e os repositories, os quais apresentam funções como criar de arquivos,
rodar comandos em terminal, etc;

• Repository: Pasta que se refere aos componentes de código que se comunicam com o
Banco de Dados, a partir da utilização das tecnologias JPA e Hybernate (Camada
de Persistência).

Além das pastas principais, foram adicionadas as seguintes estruturas:

• Model: Pasta que se refere aos componentes de código que são as classes dos objetos
que trafegam na aplicação;

• ConĄg: Pasta que se refere ao componente de código para conĄguração de CORS

Policy, garantindo que o projeto Frontend possa acessar a API.

5.2 Banco de Dados

Com base nas necessidades de negócio do projeto, foi criada a estrutura do banco
de dados mostrada na Figura 4, sendo ela executada em Banco de Dados Relacional do
tipo MySQL.
Vale salientar a necessidade da tabela intermediária Atividade_Turma, pois, dife-
rente das outras relações, que são Śum para muitosŠ - um professor para muitas turmas, uma
turma para muitos alunos, um aluno para muitas submissões, uma atividade para muitas
submissões, um aluno para muitas submissões, uma atividade para muitas portas -, para
ser possível ao professor reutilizar atividades cadastradas para diversas turmas, tornou-se
Capítulo 5. Projeto e Implementação 28

necessária uma relação Śmuitos para muitosŠ - muitas turmas para muitas atividades. Dessa
forma, tal tabela têm os registro dos vínculos entre as duas tabelas, por meio das chaves
estrangeiras, e, ainda, o atributo de Śdata limiteŠ adicionado a essa vinculação, podendo
vincular prazos diferentes a turmas diferentes, mesmo sendo uma mesma atividade.

Figura 4 Ű Diagrama Entidade Relacionamento

Fonte: Autoria própria.

5.3 Telas
A interface foi dividida em duas visões: a do aluno e a do professor. Em um primeiro
momento, no entanto, independente do usuário, apresenta-se a tela de login (Figura 5), na
qual é possível entrar com dados válidos de usuário e senha, sendo direcionado, após isso,
para a área do aluno ou do professor.
Existe a opção, ainda, na tela de login de cadastrar-se na aplicação como professor.
O formulário de registro de novo professor gera uma requisição de adição de um professor
ao Banco de Dados com as características informadas.

5.3.1 Área do Professor

A visão do professor cumpre os requisitos listados na Tabela 1, estando a tela que
lista as atividades apresentada na Figura 6, a que detalha uma atividade na Figura 7 e o
fluxo de telas para inclusão de uma nova atividade apresentadas na sequência das Figuras
8, 9, 10 e 11.
É importante salientar que a requisição de adição das portas e de uma atividade ao
Banco de Dados ocorre apenas na conĄrmação Ąnal presente na Figura 11. O formulário
da tela apresentada na Figura 9 gera, entretanto, requisição ao backend de forma que o
ŚGolden DesignŠ trafega por um objeto da classe Arquivo, a Ąm de ser criado um arquivo
Capítulo 5. Projeto e Implementação 29

Figura 5 Ű Tela de Login da aplicação

Fonte: Autoria própria.

Figura 6 Ű Tela de Consulta das Atividades

Fonte: Autoria própria.

temporário e fazer sua simulação por um Service no Backend, para análise de sintaxe e
validação do conteúdo.
O arquivo que deve ser adicionado no formulário da tela da Figura 10 serve para
especiĄcar as entradas que devem ser aplicadas ao ŚGolden DesignŠ, o qual se trata de
um módulo em SystemVerilog que possui o comportamento que satisfaz o que o professor
espera na atividade, e ao design a ser submetido pelo aluno. Com as mesmas excitações,
os blocos poderão ter suas saídas comparadas, obtendo, assim, o status da submissão do
Capítulo 5. Projeto e Implementação 30

Figura 7 Ű Tela de Detalhamento de uma Atividade

Fonte: Autoria própria.

Figura 8 Ű Tela de Inclusão de Atividade - Parte 1

Fonte: Autoria própria.

aluno. Dessa forma, o conteúdo desse arquivo de texto servirá para a elaboração de um
arquivo testbench em SystemVerilog que faz tais comparações em momentos desejados.
O arquivo em questão deve ter formato de texto e ter a característica de a cada
linha listar valores em decimal ou a palavra ŚrandŠ, caso se queira excitar a entrada naquele
caso com um valor aleatório, para as entradas especiĄcadas na primeira tela de adição
de atividade, em ordem, separados por Ś_Š. Tratando-se de uma atividade que requer um
Capítulo 5. Projeto e Implementação 31

Figura 9 Ű Tela de Inclusão de Atividade - Parte 2

Fonte: Autoria própria.

Figura 10 Ű Tela de Inclusão de Atividade - Parte 3

Fonte: Autoria própria.

bloco sequencial, além de um valor para cada entrada, deve haver o símbolo Ś#Š, ao Ąm
da linha, seguido da quantidade de clocks que devem passar para que a comparação das
saídas seja feita. O testbench gerado pode ser conferido pelo usuário na tela de conĄrmação
de criação da atividade.
A outra opção na área do professor, conforme detalhado na Tabela 1, é a de listar
as turmas relacionadas a ele, existindo a opção de detalhar uma turma em especíĄco, com
a lista de alunos a de atividades que se referem a ela (Figura 12), de adicionar turma e de
excluir uma existente.
Capítulo 5. Projeto e Implementação 32

Figura 11 Ű Tela de Inclusão de Atividade - Parte 4

Fonte: Autoria própria.

Figura 12 Ű Tela de Detalhamento de uma Turma

Fonte: Autoria própria.

Para uma turma em especíĄco, é possível adicionar alunos relacionados a ela, por
meio de uma tela de cadastro de ŚNovo AlunoŠ e de ŚVincular outras Atividades à TurmaŠ,
por meio de uma tela em que atividades não pertencentes àquela turma são listadas para
seleção, havendo adição de uma data limite para submissão dos alunos (Figura 13).
Existe, ainda, a opção de visualização das submissões dos alunos daquela turma a
cada atividade a ela associada, conforme é observado na Figura 14.
Capítulo 5. Projeto e Implementação 33

Figura 13 Ű Tela de Detalhamento de Submissões por Atividade

Fonte: Autoria própria.

Figura 14 Ű Tela de Vínculo de Novas Atividades a uma Turma

Fonte: Autoria própria.

5.3.2 Área do Aluno

A visão do aluno restringe-se à visualização de uma lista de atividades requeridas
à turma a qual ele está relacionado (Figura 15) e, ao acessar uma dessas atividades, uma
tela de detalhamento com editor para proceder com a simulação e submissão (Figura 16).
Ao simular um preenchimento de design, é gerada uma requisição à API e seu
conteúdo trafega pelo backend como objeto da classe Arquivo. A camada de serviço criará
um arquivo temporário para ele e fará co-simulação dele com otestbench da atividade,
Capítulo 5. Projeto e Implementação 34

Figura 15 Ű Tela de Consulta das Atividades e Submissões do Aluno

Fonte: Autoria própria.

Figura 16 Ű Tela de Submissão Pós-Simulação

Fonte: Autoria própria.

salvo em diretório especíĄco com o nome conforme em Banco de Dados, gerando o arquivo
de formas de onda de extensão VCD e o status da submissão do aluno, os quais serão
disponibilizados em tela conforme Figura 16, com a saída do simulador, caso tenha, e
o botão para abrir em outra aba a aplicação Fliplot para visualizar as formas de onda
geradas.
Apenas após o usuário apertar o botão ŚSubmeterŠ, a submissão em questão será
salva em Banco de Dados e o arquivo em diretório apropriado, com a denominação também
Capítulo 5. Projeto e Implementação 35

salva em coluna de Banco.

5.4 Arquitetura Geral do Sistema

Tendo em vista o que foi apresentado, criou-se um diagrama da arquitetura geral do
sistema (Figura 17), de forma que o controller Ąca imediatamente antes da API, controlando
seus endpoints, entre ŚserviçosŠ e ŚinterfaceŠ; e que o repository Ąca imediatamente após o
Banco de Dados, entre ŚdadosŠ e ŚserviçosŠ, especiĄcando os métodos de acesso ao Banco.
A camada de Frontend está no escopo do que foi implementado no Angular.

Figura 17 Ű Arquitetura Geral do Sistema

Fonte: Autoria própria.

 36

6 Conclusão

Neste trabalho de conclusão de curso, implementou-se o protótipo de uma plata-

forma web que considera a relação professor-aluno e possui suporte para co-simular designs
em SystemVerilog com testbenchs, também gerados pelo sistema, com características de
entradas especiĄcadas. Dessa forma, os requisitos estabelecidos foram alcançados.
Pode-se salientar a característica híbrida da plataforma, de forma que ela pode ser
utilizada tanto pelo professor para proposição de problemas após o ensino de determinadas
competências e habilidades, sendo uma solução que segue a linha do problem-based-learning
(PBL), quanto para a requisição de exercícios com o intuito de que o aluno tenha seu
primeiro contato com determinados assuntos, seguindo assim a linha do learning-by-doing
(LBD).
A partir das evoluções obtidas neste trabalho, trabalhos futuros devem ser con-
siderados visando melhorias na plataforma, em áreas como: integração do visualizador
de formas de onda, validação dos formulários, implementação de mensageiria, gestão dos
arquivos gerados, segurança da aplicação, conteinerização dos recursos para obtenção de
facilidades de deploy e de ajustes para disponibilização da plataforma em servidor.
Além disso, pode-se considerar a adição de funcionalidades, como: possibilidade
do aluno adicionar feedbacks e dúvidas quanto às atividades, aquisição automática pelo
professor de métricas quanto à submissão do aluno, melhorias nas críticas das soluções,
a partir do uso de veriĄcadores estáticos e de uma forma de avaliação de qualidade de
síntese no que foi submetido, dentre outras.
Durante o desenvolvimento deste trabalho de conclusão de curso, foram utilizados
conhecimentos de disciplinas da graduação, como Introdução à Programação, Técnicas de
Programação e Circuitos Lógicos. Como também, a elaboração deste trabalho permitiu a
aprendizagem de conhecimentos complementares à formação curricular, como conhecimen-
tos do sistema de versionamento Git, da linguagem de programação Java, dos frameworks
SpringBoot e Angular e de Banco de Dados Relacional.
 37

Referências

AYODELE, K. P.; INYANG, I. A.; KEHINDE, L. O. An ilab for teaching advanced logic
concepts with hardware descriptive languages. IEEE Transactions on Education, v. 58,
n. 4, p. 262Ű268, 2015. Citado na página 15.

BECKER, K. A web based tool for teaching hardware design based on the plain simple
hardware description language. In: 2014 IEEE Global Engineering Education Conference
(EDUCON). [S.l.: s.n.], 2014. p. 88Ű93. Citado na página 14.

CANESCHE, M. et al. Google colab cad4u: Hands-on cloud laboratories for digital design.
In: 2021 IEEE International Symposium on Circuits and Systems (ISCAS). [S.l.: s.n.],
2021. p. 1Ű5. Citado na página 15.

DHALLA, H. K. A performance comparison of restful applications implemented in spring

boot java and ms. net core. In: IOP PUBLISHING. Journal of Physics: Conference Series.
[S.l.], 2021. v. 1933, n. 1, p. 012041. Citado na página 24.

HAASE, J. An html5-based interactive simulation tool for teaching and self-study of

electronic circuits. In: 2018 12th European Workshop on Microelectronics Education
(EWME). [S.l.: s.n.], 2018. p. 41Ű44. Citado na página 15.

HAASE, J. Flipped classroom with digital circuits: An html5-based interactive simulation

tool. In: 2022 IEEE Global Engineering Education Conference (EDUCON). [S.l.: s.n.],
2022. p. 307Ű312. Citado na página 15.

IEEE Standard for SystemVerilogŰUniĄed Hardware Design, SpeciĄcation, and VeriĄcation

Language. IEEE Std 1800-2017 (Revision of IEEE Std 1800-2012), p. 1Ű1315, 2018.
Citado na página 25.

IEEE Standard for Verilog Hardware Description Language. IEEE Std 1364-2005
(Revision of IEEE Std 1364-2001), p. 1Ű590, 2006. Citado na página 25.

JOVANOVIĆ, Ž. et al. Java spring boot rest web service integration with java artiĄcial
intelligence weka framework. In: International ScientiĄc Conference ŞUNITECH 2017.
[S.l.: s.n.], 2017. p. 323Ű327. Citado 2 vezes nas páginas 23 e 24.

KOHúTKA, L.; STOPJAKOVá, V. Chipde - a development environment for system

verilog-based digital ic design. In: 2018 16th International Conference on Emerging
eLearning Technologies and Applications (ICETA). [S.l.: s.n.], 2018. p. 273Ű278. Citado
na página 15.

KUMAR, A.; PANICKER, R. C.; KASSIM, A. Enhancing vhdl learning through a

light-weight integrated environment for development and automated checking. In:
Proceedings of 2013 IEEE International Conference on Teaching, Assessment and Learning
for Engineering (TALE). [S.l.: s.n.], 2013. p. 570Ű575. Citado 2 vezes nas páginas 15 e 16.

LUKOVIć, V. et al. The remote lab Şnexys 2 fpga platformŤ aimed for learning design of
digital circuits. In: 2017 4th Experiment@International Conference (exp.atŠ17). [S.l.: s.n.],
2017. p. 101Ű102. Citado na página 15.
Referências 38

MILANI, A. MySQL-guia do programador. [S.l.]: Novatec Editora, 2007. Citado na

página 24.

MORGAN, F. et al. Vicilogic 2.0: Online learning and prototyping of digital systems
using pynq-z1/-z2 soc. In: 2018 International Symposium on Rapid System Prototyping
(RSP). [S.l.: s.n.], 2018. p. 76Ű82. Citado na página 14.

MOSBECK, M.; HAUER, D.; JANTSCH, A. Vels: Vhdl e-learning system for automatic
generation and evaluation of per-student randomized assignments. In: 2018 IEEE Nordic
Circuits and Systems Conference (NORCAS): NORCHIP and International Symposium of
System-on-Chip (SoC). [S.l.: s.n.], 2018. p. 1Ű7. Citado 2 vezes nas páginas 15 e 16.

NASCIMENTO, B. M.; SIBUYA, F. H. T. Sistema de Suporte ao Desenvolvimento de

Projetos VHDL. 2021. Citado na página 16.

PAPADOPOULOS, I. et al. Enhancing the studentŠs logical thinking with gherkin

language. In: IEEE. 2017 IEEE Global Engineering Education Conference (EDUCON).
[S.l.], 2017. p. 1543Ű1547. Citado na página 18.

RACKS, B. Fliplot. 2021. Disponível em: <https://github.com/raczben/fliplot>. Citado

2 vezes nas páginas 25 e 26.

RICHARDS, M. Software architecture patterns. [S.l.]: OŠReilly Media, Incorporated 1005

Gravenstein Highway North, Sebastopol, CA . . . , 2015. v. 4. Citado na página 22.

SINGER, J. Jvm versus clr: a comparative study. In: CITESEER. Proceedings of the 2nd
international conference on Principles and practice of programming in Java. [S.l.], 2003. p.
167Ű169. Citado na página 23.

SPINELLIS, D. Git. IEEE software, IEEE, v. 29, n. 3, p. 100Ű101, 2012. Citado na

página 25.

SULTAN, M. Angular and the trending frameworks of mobile and web-based platform
technologies: A comparative analysis. In: Proc. Future Technologies Conference. [S.l.: s.n.],
2017. p. 928Ű936. Citado na página 23.

WILLIAMS, S. Icarus Verilog. 2020. Disponível em: <https://github.com/steveicarus/

iverilog>. Citado na página 25.