Duas Perguntas:
Tamanho do Grupo?
Podemos fazer o opcional em uma linguagem mais amigável? (e.g. Ruby, Python ou etc.. )
Obrigado
Hugo, quando dou o make no exemplo que vc deixou, aparece isso:
ghdl -r verificador_test
test/verificador_test.vhdl:65:10:@1ns
assertion error): Verificador disse que '0''0''0''0''0''0''0''0' com check '0''0' devolve d0 '0'.
test/verificador_test.vhdl:73:9:@1nsassertion error): Verificador mandou mais ou menos de um sinal de desconto.
test/verificador_test.vhdl:67:10:@2nsassertion error): Verificador disse que '0''0''0''0''0''0''0''0' com check '0''0' devolve d5 '0'.
test/verificador_test.vhdl:73:9:@2nsassertion error): Verificador mandou mais ou menos de um sinal de desconto.
test/verificador_test.vhdl:69:10:@3nsassertion error): Verificador disse que '0''0''0''0''0''0''0''0' com check '0''0' devolve d10 '0'.
test/verificador_test.vhdl:73:9:@3nsassertion error): Verificador mandou mais ou menos de um sinal de desconto.
test/verificador_test.vhdl:71:9:@4nsassertion error): Verificador disse que '0''0''0''0''0''0''0''0' com check '0''0' devolve d20 '0'.
test/verificador_test.vhdl:73:9:@4nsassertion error): Verificador mandou mais ou menos de um sinal de desconto.
Isso deveria acontecer?
ghdl -r verificador_test
test/verificador_test.vhdl:65:10:@1ns
test/verificador_test.vhdl:73:9:@1ns
test/verificador_test.vhdl:67:10:@2ns
test/verificador_test.vhdl:73:9:@2ns
test/verificador_test.vhdl:69:10:@3ns
test/verificador_test.vhdl:73:9:@3ns
test/verificador_test.vhdl:71:9:@4ns
test/verificador_test.vhdl:73:9:@4ns
Isso deveria acontecer?
Sim!
Se você olhar o código, ele sempre responde com '0', '0', '0', '0'.
Os testes que estão lá esperam uma resposta '1','0','0','0' ou '0','1','0','0' ou '0','0','1','0' ou '0','0','0','1'. Foi só para vocês terem um exemplo de cada falha que pode acontecer.
O trabalho de vocês é justamente sumir com tudo isso (sem apagar os testes) e me dar mais alguns casos.
Se você olhar o código, ele sempre responde com '0', '0', '0', '0'.
Os testes que estão lá esperam uma resposta '1','0','0','0' ou '0','1','0','0' ou '0','0','1','0' ou '0','0','0','1'. Foi só para vocês terem um exemplo de cada falha que pode acontecer.
O trabalho de vocês é justamente sumir com tudo isso (sem apagar os testes) e me dar mais alguns casos.
Tamanho do grupo: 2
Como está no exemplo.
Hmmm, acho que não. Eu prefiro MESMO em C. A idéia é que vocês precisem manipular bits como no EP e isso não existe nessas linguagens mais amigáveis.
No melhor dos casos, nelas, vocês manipulam um objeto que simula um bit que não é bem a idéia.
O mais legal do VHDL é que, com o que vocês gerarem, vocês podem mandar para uma empresa de construção de circuitos (o .vhdl) que eles implementam numa placa pra você (diz o Alfredo).
Isso dará para vocês um comparativo das diferenças que podem existir entre duas linguagens de baixo nível.
Como está no exemplo.
Hmmm, acho que não. Eu prefiro MESMO em C. A idéia é que vocês precisem manipular bits como no EP e isso não existe nessas linguagens mais amigáveis.
No melhor dos casos, nelas, vocês manipulam um objeto que simula um bit que não é bem a idéia.
O mais legal do VHDL é que, com o que vocês gerarem, vocês podem mandar para uma empresa de construção de circuitos (o .vhdl) que eles implementam numa placa pra você (diz o Alfredo).
Isso dará para vocês um comparativo das diferenças que podem existir entre duas linguagens de baixo nível.
Não é possível fazer o ep em grupo de três pessoas???
[]s
[]s
Não!
Já tá fácil o suficiente com 2 pessoas
Já tá fácil o suficiente com 2 pessoas
alguma alternativa pra fazer esse ep em windows?
Alias, só pra complementar: o GHDL ta no repositório do Debian e do Gentoo.
Mais algumas duvidas:
Nao seria melhor usar como entrada um array de bit?
Precisamos seguir a mesma proporcao entre identificacao e verificacao que a mostrada no exemplo? (eu tava planejando usar uma verificacao bem maior, ate porque nao devem ter 216 alunos e se temos apenas 24 possibilidades de verificacao, usando numeros aleatorios ate da pra conseguir passar com algumas tentativas...)
A saida deve ser como no exemplo?
Nao seria melhor usar como entrada um array de bit?
Precisamos seguir a mesma proporcao entre identificacao e verificacao que a mostrada no exemplo? (eu tava planejando usar uma verificacao bem maior, ate porque nao devem ter 216 alunos e se temos apenas 24 possibilidades de verificacao, usando numeros aleatorios ate da pra conseguir passar com algumas tentativas...)
A saida deve ser como no exemplo?
Sem array de bits.
Placas lógicas não tem arrays
Quer dizer, tem, mas são um monte de "cabos" de um bit um ao lado do outro (eu acho). De toda forma, vocês têm que tratar os bits 1 a 1.
Quanto ao exemplo, é um exemplo
Vocês estão livres para usar os bits como quiserem. Mas precisa ter um certo número de bits de verificação suficiente para ela ser útil.
A saída deve ser d0, d5, d10 ou d20 sim.
Respondi?
Placas lógicas não tem arrays
Quer dizer, tem, mas são um monte de "cabos" de um bit um ao lado do outro (eu acho). De toda forma, vocês têm que tratar os bits 1 a 1.
Quanto ao exemplo, é um exemplo
Vocês estão livres para usar os bits como quiserem. Mas precisa ter um certo número de bits de verificação suficiente para ela ser útil.
A saída deve ser d0, d5, d10 ou d20 sim.
Respondi?
alguém sabe se jah tem GHDL instalado na rede linux???
vlww
vlww
Alguem saberia responder?
Eu suponho que os admins da rede Linux que estão cursando a matéria poderiam responder.
Eu posso ajudar aqueles que tiverem problemas em suas máquinas mas é só isso.
Eu posso ajudar aqueles que tiverem problemas em suas máquinas mas é só isso.
Quando vc fala em fazer o EP em C , isso quer dizer que eu não preciso usar o vhdl?.
Então eu poderia entender os bits como um vetor de "bits".
Eu nunca mexi em VHDL e não vou ter tempo de aprender em tempo.
Então eu poderia entender os bits como um vetor de "bits".
Eu nunca mexi em VHDL e não vou ter tempo de aprender em tempo.
Eu nunca falei em fazer o EP em C.
Eu falei em fazer o item extra do EP em C. Isso está lá no enunciado.
O EP é para ser feito em VHDL para que vocês vejam um pouco de VHDL. Acho que ninguém aqui sabe VHDL (eu também não sabia). É bem fácil de aprender e o trabalho é bem simples também. E em VHDL, vocês vão receber vários bits sim e não um vetor de bits.
Eu falei em fazer o item extra do EP em C. Isso está lá no enunciado.
O EP é para ser feito em VHDL para que vocês vejam um pouco de VHDL. Acho que ninguém aqui sabe VHDL (eu também não sabia). É bem fácil de aprender e o trabalho é bem simples também. E em VHDL, vocês vão receber vários bits sim e não um vetor de bits.
Tbm não entendemos qual a função dos arquivos verificador e verificador_teste
Alguem sabe explicar?
vlw
Alguem sabe explicar?
vlw
São apenas exemplos para vocês. Tentei facilitar a vida de todos montando o projeto e só deixando para vocês implementarem a lógica. E o relatório é claro
O ghdl está instalado na rede linux, sim
Hugo, não entendi como funciona direito esses d0, d5, d10 e d20. Eu sei que são os descontos que vc vai dar ao aluno.
No seu arquivo teste, tá algo parecido com isso: d5 = pattern(i).d5 ...
o primeiro d5 é o resultado da minha decisão de eu dar esse desconto?
Uma outra dúvida, por exemplo, fiz a manipulação dos bits e decidi dar um desconto de 10 ... então eu seto d10 <= 1, certo?! E o resto dos d's, seto eles como zero ou não preciso colocar nada?
E uma última pergunta por enquanto, para eu adicionar mais casos, eu coloco mais linha no pattern lá né? E aquele sum faz a verificação d0 > d5 > d10 > d20? Ou será que eu estou viajando? ^^"
Isso.
O primeiro d5 é o resultado que eu obtive da execução do seu programa.
Na verdade, d10 <= 1 manda um sinal 1 para o canal d10 (se você pensar em circuito). Então se você não "setar" os outros, eles não recebem sinal e ficam 0. Mas pode enviar 0 para deixar mais claro se você preferir.
Sim. Basta adicionar mais uma linha no pattern para adicionar um teste.
O sum faz (ou deveria fazer) a verificação de que não há mais de um desconto atribuído.
O primeiro d5 é o resultado que eu obtive da execução do seu programa.
Na verdade, d10 <= 1 manda um sinal 1 para o canal d10 (se você pensar em circuito). Então se você não "setar" os outros, eles não recebem sinal e ficam 0. Mas pode enviar 0 para deixar mais claro se você preferir.
Sim. Basta adicionar mais uma linha no pattern para adicionar um teste.
O sum faz (ou deveria fazer) a verificação de que não há mais de um desconto atribuído.
Hugo, só posso usar os operadores lógicos no arquivo verificador.vhdl ou posso usar If tb?
A idéia era ficar nos bits mesmo. Para que o código de vocês pudesse ser transformado num circuito. A realidade é que um if pode ser feito com operadores lógicos.
Digamos que pode usar if mas eu acho melhor se forem só os operadores lógicos. Ou seja, considero o EP e dou nota com if mas ela é um pouco menor do que a sem if Se você estiver mirando no 10, não use if. Se você estiver atolado de trabalho, vai com if mesmo.
Digamos que pode usar if mas eu acho melhor se forem só os operadores lógicos. Ou seja, considero o EP e dou nota com if mas ela é um pouco menor do que a sem if
Hugo,
no enuciado vc fala q o verificador_teste deve enviar um sinal com o desconto do aluno,(isso seria imprimir o desconto do msm na tela?). Já no paragrafo seguinte fala que o verificador_teste não deve imprimir nada.Não entendi como isso funciona.
Também não entendi o que cada verificador deve fazer ( verificador e verificador_teste)
Valeu!
no enuciado vc fala q o verificador_teste deve enviar um sinal com o desconto do aluno,(isso seria imprimir o desconto do msm na tela?). Já no paragrafo seguinte fala que o verificador_teste não deve imprimir nada.Não entendi como isso funciona.
Também não entendi o que cada verificador deve fazer ( verificador e verificador_teste)
Valeu!
O verificador deve enviar um sinal com o desconto.
Isso não é imprimir na tela não. É enviar um sinal mesmo.
O verificador_teste recebe esse sinal. Pensa nisso como se fosse um return.
O verificador_teste é um teste automatizado. Ele vai imprimir erros se detectar alguma coisa anormal ou incorreta. Logo, se o EP de vocês estiver funcionando, o verificador_teste não deveria imprimir nada. Fez sentido?
Pensem no verificador como um sistema lógico mesmo. Não tem impressão. São sinais elétricos que entram e sinais elétricos que saem. Só isso.
O verificador_teste é um programinha que verifica que dados sinais de entradas, os sinais de saída estão corretos.
Melhorou?
Isso não é imprimir na tela não. É enviar um sinal mesmo.
O verificador_teste recebe esse sinal. Pensa nisso como se fosse um return.
O verificador_teste é um teste automatizado. Ele vai imprimir erros se detectar alguma coisa anormal ou incorreta. Logo, se o EP de vocês estiver funcionando, o verificador_teste não deveria imprimir nada. Fez sentido?
Pensem no verificador como um sistema lógico mesmo. Não tem impressão. São sinais elétricos que entram e sinais elétricos que saem. Só isso.
O verificador_teste é um programinha que verifica que dados sinais de entradas, os sinais de saída estão corretos.
Melhorou?
melhorou bastante
então no verificador_test somente devemos acrescentar mais testes, certo?!
valeu!
então no verificador_test somente devemos acrescentar mais testes, certo?!
valeu!
E talvez tirar os que já existem pois eles provavelmente não fazem sentido
Vocês até podem mudar mais comportamentos mas acho que não é necessário. O importante é que esse arquivo verifique que seu programa funciona corretamente. A idéia é que, se eu tirar ou mudar uma linha de código qualquer da implementação, o verificador_teste vai imprimir algum erro.
Vocês até podem mudar mais comportamentos mas acho que não é necessário. O importante é que esse arquivo verifique que seu programa funciona corretamente. A idéia é que, se eu tirar ou mudar uma linha de código qualquer da implementação, o verificador_teste vai imprimir algum erro.
Não entendi bem o que são os algoritmos mais alto nível... meu circuito por exemplo foi feito meio na raça...isso é um problema?
os algoritmos deveriam ser do tipo, pega os 18 primeiros bits ve o número que eles representam por exemplo n, ve n mod 4, e compara com os 2 bits finais que seriam de verificação.... algo desse tipo? ou estou viajando?
Grato,
Fábio.
os algoritmos deveriam ser do tipo, pega os 18 primeiros bits ve o número que eles representam por exemplo n, ve n mod 4, e compara com os 2 bits finais que seriam de verificação.... algo desse tipo? ou estou viajando?
Grato,
Fábio.
No relatório seria legal uma explicação assim. Para ter idéia do que vocês estavam pensando quando implementaram o algoritmo.
O código mesmo vai ficar bem baixo nível por outro lado porque é para usar bits e portas lógicas essencialmente.
O código mesmo vai ficar bem baixo nível por outro lado porque é para usar bits e portas lógicas essencialmente.
possibilidade de entrega atrasada? até qdo? qto de desconto?
Dessa vez acho que não vai dar para entregar atrasado porque eu vou ter 1 dia para corrigir. Tenho que entregar as notas todas pro Alfredo dia 16 se me lembro bem.
Quão diferentes tem que ser os dois algoritmos alternativos?
Pensamos em um jeito de aumentar/diminuir as probabilidades sem mudar quase nada do nosso código.. Temos que pensar em uma idéia diferente??
Além disso, devemos aumentar/diminuir o número de cartões válidos/inválidos ou o número de cartões com descontos altos (ou ambos)?
Pensamos em um jeito de aumentar/diminuir as probabilidades sem mudar quase nada do nosso código.. Temos que pensar em uma idéia diferente??
Além disso, devemos aumentar/diminuir o número de cartões válidos/inválidos ou o número de cartões com descontos altos (ou ambos)?
hmm.. eu tb tenho uma duvida com relação a isso..
estamo lidando com 20 bits, o q me parece bem pouco.
a grosso modo, por melhor q seja a função de distribuição, se gerarmos um número, aleatoriamente, entre 0 e 2^16 (tirando os 4 dochecksum), teremos uma grande chance desse número estar dentro de algum dos descontos não é?
estou colocando aqui algo mais ou menos assim (porcentagem do total de possíveis identificadores):
d20 : 7.5%
d10 : 15%
d05 : 30%
d0 : 47.5%
dessa forma, se o cara chutar uma sequencia de bits ele tem 52,5% por cento de chances de acertar (desde q ele acerte o checksum tb)!
as distribuições estão corretas ou é necessário diminuí-las?
é isso mesmo ou entendi errado?
estamo lidando com 20 bits, o q me parece bem pouco.
a grosso modo, por melhor q seja a função de distribuição, se gerarmos um número, aleatoriamente, entre 0 e 2^16 (tirando os 4 dochecksum), teremos uma grande chance desse número estar dentro de algum dos descontos não é?
estou colocando aqui algo mais ou menos assim (porcentagem do total de possíveis identificadores):
d20 : 7.5%
d10 : 15%
d05 : 30%
d0 : 47.5%
dessa forma, se o cara chutar uma sequencia de bits ele tem 52,5% por cento de chances de acertar (desde q ele acerte o checksum tb)!
as distribuições estão corretas ou é necessário diminuí-las?
é isso mesmo ou entendi errado?
Ok, mas pra ele acertar no desconto, ele tem que acertar o checksum tb.
Então dentre 2^20 cartões possíveis, ele só vai possuir 52,5% de 2^16 que batem com o cheksum respectivo, o que nas minhas contas dá 3% do total de cartões!!!
Então dentre 2^20 cartões possíveis, ele só vai possuir 52,5% de 2^16 que batem com o cheksum respectivo, o que nas minhas contas dá 3% do total de cartões!!!
Vocês não são obrigados a usar 4 bits de checksum como o Cadu já postou (eu tinha dito anteriormente que o exemplo era meramente um exemplo).
A grande dificuldade deveria estar em acertar o checksum. Sim, dentre todas as possibilidades, para que exista uma certa quantidade válida, se o cara chutar um número válido, ele vai se dar bem. Então se de todos os números válidos, 50% estiverem sendo usados para cartões válidos, a probabilidade de se ganhar um desconto chutando um número é 50%. Mas 2^20 = 1024*1024. É cartão pra dedéu! Vocês precisam de 500.000 cartões válidos? Pensem bem nisso.
As distribuições dependem do algoritmo que vocês resolverem implementar. Podem existir algoritmos que distribuem os descontos quase igualmente, outros que mudam essa probabilidade. Para mim tanto faz desde que vocês tenham controle sobre isso e me mostrem isso no relatório.
A grande dificuldade deveria estar em acertar o checksum. Sim, dentre todas as possibilidades, para que exista uma certa quantidade válida, se o cara chutar um número válido, ele vai se dar bem. Então se de todos os números válidos, 50% estiverem sendo usados para cartões válidos, a probabilidade de se ganhar um desconto chutando um número é 50%. Mas 2^20 = 1024*1024. É cartão pra dedéu! Vocês precisam de 500.000 cartões válidos? Pensem bem nisso.
As distribuições dependem do algoritmo que vocês resolverem implementar. Podem existir algoritmos que distribuem os descontos quase igualmente, outros que mudam essa probabilidade. Para mim tanto faz desde que vocês tenham controle sobre isso e me mostrem isso no relatório.
Não precisa ser muito diferentes. Só precisa ter mais estudantes com descontos em um deles e menos no outro.
Não precisa de outra idéia não.
Aumentar/Diminuir o número de cartões com desconto (de 5, 10 e 20).
Não precisa de outra idéia não.
Aumentar/Diminuir o número de cartões com desconto (de 5, 10 e 20).
Quanto ao gerador em C, como deve ser a impressao?
devemos imprimir os 20 bits ( + os 4 que determinam o desconto )da forma :
"( 'x' , .... 'y' , '0, '0', '0', '1') ,"
(por exemplo, para um caso de 20% de desconto, (sem as aspas) )
ou basta :
x ... y
?
devemos imprimir os 20 bits ( + os 4 que determinam o desconto )da forma :
"( 'x' , .... 'y' , '0, '0', '0', '1') ,"
(por exemplo, para um caso de 20% de desconto, (sem as aspas) )
ou basta :
x ... y
?
Quero os 20 bits que eu preciso para cadastrar um novo aluno. Inclusive os do checksum. Só imprimam isso de forma legível qualquer