Thank you, your comments are very enriching.
The goal was to make a program that uses inputs from stdin to directly
change the values of any entries of an entity that would simulate and
display it on the screen automatically without entering the cycle: Change ".
vhd" -> Compile -> Run -> Analyse GtkWave.
I made a program, is the end of this email (Using a litle of Perl + VHDL).
For example if you have this flip flop to test:
library ieee;
use ieee.std_logic_1164.all;
entity dffx is
port( d, clk, rst: in std_logic;
q: out std_logic);
end dffx;
architecture behaviour of dffx is
begin
process(rst,clk)
begin
if(rst='1') then
q <= '0';
elsif(clk'event and clk='1') then
q <= d;
end if;
end process;
end behaviour;
Doing this would be enough:
$ ghdl -a Dff.vhdl
$ ./testchio dffx d,clk,rst q > testchio.vhdl
$ ghdl -a testchio.vhdl
$ ghdl -e testchio_tb
$ ghdl -r testchio_tb
(testchio is the end of this email)
The first argument of "testchio" is the name of the entity you want to
test, the second is a list of inputs separated by commas, and the third is
a list of outputs separated by commas.
When running it will appear on the screen:
d,clk,rst,q=1110
This means that d = 1, CLK = 1, RST = 1, q = 0
Then you can provide new inputs, and in that case are possible up to 3
entries.
Example:
d,clk,rst,q=1110
000 -------------------------------> (1)
000
d,clk,rst,q=0000
100 -----------------------------------> (2)
100
d,clk,rst,q=1000
110 -----------------------------------> (3)
110
d,clk,rst,q=1101
001 -----------------------------------> (4)
001
d,clk,rst,q=0010
_____________
Explaining:
(1) ---> d=0 , clk=0 , rst=0
(2) ---> d=1 , clk=0 , rst=0
(3) ---> d=1 , clk=1 , rst=0
(4) ---> d=0 , clk=0 , rst=1
The set of bits in the input that goes, are the new values to the inputs of
the entity that you want to analyze. Therefore in this case, is 3.
For now this works only with std_logic, is very limited.
A teacher told me that I could use "assert" / "report", I'll search it later
.
The program Testchio is below:
#!/usr/bin/perl
my @ins1 = split(',', $ARGV[1]);
my @ins2 = split(',', $ARGV[2]);
my $subst1 = '';
foreach my $val (@ins1) {
$subst1 = $subst1."$val: in std_logic;";
}
my $subst2 = '';
foreach my $val (@ins2) {
$subst2 = $subst2."$val: out std_logic;";
}
$subst2 = substr $subst2, 0, length($subst2)-1;
my $subst3 = '';
foreach my $val (@ins1) {
$subst3 = $subst3."signal $val: std_logic :='1';";
}
my $subst4 = '';
foreach my $val (@ins2) {
$subst4 = $subst4."signal $val: std_logic;";
}
my $subst5 = '';
foreach my $val (@ins1) {
$subst5 = $subst5."
if($val='1') then
write(dados, string'(\"1\"));
else
write(dados, string'(\"0\"));
end if;
";
}
my $subst6 = '';
foreach my $val (@ins2) {
$subst6 = $subst6."
if($val='1') then
write(dados, string'(\"1\"));
else
write(dados, string'(\"0\"));
end if;
";
}
my $subst7 = '';
my $jk=0;
foreach my $val (@ins1) {
$subst7 = $subst7."
elsif(j=$jk)
then
$val <= '0';
";
$jk = $jk+1;
}
my $subst8 = '';
my $jk=0;
foreach my $val (@ins1) {
$subst8 = $subst8."
elsif(j=$jk)
then
$val <= '1';
";
$jk = $jk+1;
}
my $subst9 = '';
foreach my $val (@ins1) {
$subst9 = $subst9."$val,";
}
foreach my $val (@ins2) {
$subst9 = $subst9."$val,";
}
$subst9 = substr $subst9, 0, length($subst9)-1;
print 'library ieee;
use ieee.std_logic_1164.all;
use std.textio.all;
entity testchio_tb is
end entity testchio_tb;
architecture behaviour of testchio_tb is
component '.$ARGV[0].'
port ( '.$subst1.$subst2.'
);
end component;
'.$subst3.$subst4.'
begin
UQ1:
dffx port map ('.$ARGV[1].','.$ARGV[2].'
);
-- Stimulus:
main: -- main
process -- Requires ghdl -r <model>
--stop-time=<number>ns
variable dados: line;
variable erro: line;
variable j : integer ;
begin -- to stop model execution.
wait for 50 ns;
writeline(output, dados);
write(dados, string\'("'.$subst9.'="));
'.$subst5.$subst6.'
writeline(output, dados);
readline(input, dados);
j := 0;
for i in dados\'range loop
case(dados(i)) is
when \'0\' =>
if(j=-1) then
'.$subst7.'
else
end if;
j := j +1;
when \'1\' =>
if(j=-1) then
'.$subst8.'
else
end if;
j := j+1;
when others => NULL;
end case;
end loop;
end process main;
end behaviour;';
On Sat, Aug 10, 2013 at 9:50 PM, David Koontz <[email protected]> wrote:
>
> On 10 Aug 2013, at 4:47 PM, Christiano <[email protected]> wrote:
>
> In added a
> wait for 50 ns;
> Early in the process that everything worked correctly, simulators need to
> put a wait, and wait is not real, if I put 5000000 us he will not stand 5
> seconds, is all virtual.
>
>
> The model is virtual hardware, all it knows is simulation time. Real time
> reflects how time efficient the entire model execution process is, which
> can be because of real time delays (waiting on input) as well as system
> time execution.
>
> Note that ghdl executes single threaded and nothing runs (simulation or
> system time) waiting for readline input.
>
> For any platform there's likely a threshold below which it's more
> efficient to use direct stimulus stored or generated in the model (test
> bench) versus gotten from external sources (file I/O). A single flipflop
> simulation is likely below that threshold for any platform. Crossing above
> that is dependent on how much vector/response data you're dealing with.
>
> There are categories of stimulus where the expected results are provided
> such as adherence to standards for say a crypto algorithm.
>
> In general it's likely safe to say you spend more time on design
> validation and implementation verification than actual model design and
> implementation. Besides using formatted file I/O you can write programs to
> generate stimulus elements of your test bench in VHDL.
>
> Don't get me wrong. I found your approach exhibiting innovative thinking,
> just not easily understandable without understanding the interaction
> between readline input and your model. It exceeds the requirements for
> testing a simple flip flop. There's also an apparent problem with it that
> can be fixed (the only change to your original code is shown):
>
>
> readline(input, dados);
>
> j := 0;
> for i in dados'range loop
> case(dados(i)) is
> when '0' =>
> if(j=0) then
> d <= '0';
> elsif(j=1) then
> clk <= '0';
> else
>
> write(erro, string'("test"));
> writeline(output, erro);
> rst <= '0';
> end if;
> j := j +1;
> when '1' =>
> if(j=0) then
> d <= '1';
> elsif(j=1) then
> clk <='1';
> else
> rst <= '1';
> end if;
> j := j+1;
> when 'E' =>
> wait; -- ends simulation with --wave=dff_tb.ghw or
> --vcd=dff_tb.vcd
> -- and no --stop-time specified.
> when others => NULL;
>
> end case;
> wait for 10 ns; -- Added delay element for waveform
> generation.
> end loop;
>
>
> Without a delay associated with the case statement choices (shown added
> above - each bit in dados takes 10 ns) means signal assignments (which
> only occur here) can overwrite a signal's single scheduled update value
> for remaining values of dados(i). You can inspect or inject sequence in
> a process's sequential statements as you do here. Without simulation time
> advancing you can only schedule one update.
>
> An un-timed model (no wait or after statements) doesn't reflect hardware
> it reflects sequence, where the simulation cycle is guaranteed to emulate
> concurrency for signal assignment but not the passage of time. Hardware
> in clocked systems is operated by the passage of discrete time.
>
> When we talk about waveforms in VHDL it's more than just about providing
> output to waveform viewers it's about the future value of signals
> reflecting the passage of simulation time. We guarantee the passage of
> simulation time by sensitivity to signal events reflecting the passage of
> simulation time or by using wait for *time*_expression or after *time*
> _expression.
>
> You rules in the if then else statements still don't represent how I would
> test the flip flop. But at least you can't lose scheduled signal updates
> by playing loose with the input vector length.
>
> ghdl -r dff_tb --wave=dff_tb.ghw
>
> 0010
> 1000
> test
> test
> 1000
> 1000
> 1100
> test
> test
> 1100
> 1101
> 1010
> test
> 1010
> 1000
> 1110
> test
> 1110
> 1100
> 1011
> 1011
> 1010
> E
> david_koontz@Macbook:
>
> The rest seems to be how easily confused on can become over the rules
> found in the if then else statements:
>
>
>
> In general it's not up to the rest of the world to learn how you want do
> things. You could have documented this with state translation diagrams or
> tables.
>
> With the wait changes shown above the testbench appears to operate
> properly. Understanding the rules requires effort. There is input you can
> provide manually that doesn't meet your expectations (the lack of a "test"
> output described in your first post). From the waveforms I don't see the
> model doing anything wrong.
>
> Your rules aren't all inclusive. One noteworthy thing to know is the
> first input bit has to be a '1' to get the flip flop out of reset.
>
> Personally I'd write the rules separately for purposes of assertion
> testing and deal with applying stimulus (input) directly.
>
>
>
>
>
>
>
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
