I am working with Vivado simulator.
I would like to know if it is possible to suppress the time messages in the Tcl console. They are printed with the note entry:
report "LED1 is turned on" severity note;
results int:
Note: LED1 is turned on
Time: 4477500 ps Iteration: 6 Process: /testbench/\GEN(1)/line__280 File: H:/Image/Image.srcs/sim_1/new/tb.vhd
Can I get rid of this time entry?
Thank you so for this post it really helped me.
It is not straight forward though.
You need to mark them as a string unfortunately. So in vivado the following will work
use STD.TextIO.all;
procedure test is
variable LineBuffer : LINE;
begin
write(LineBuffer, string'("test message"));
writeline(output, LineBuffer);
end procedure;
Please note its not in brackets its with an apostrophe.
No, the report and assert format is fixed.
But, you can write to STDOUT from VHDL. These messages are displayed without time information in the simulator console (between other messages).
Example for writing to STDOUT:
use STD.TextIO.all;
procedure test is
variable LineBuffer : LINE;
begin
write(LineBuffer, "test message");
writeline(output, LineBuffer);
end procedure;
Source: https://github.com/VLSI-EDA/PoC/blob/master/src/sim/sim_protected.v08.vhdl#L150-L226
Screenshot from iSim:
The output from Vivado Simulator should be similar.
Related
I'm running a constant loop of ReadLn to get command input. But when it comes to multithreading, I get an issue:
var command: string;
function ThreadTest(p: pointer) : ptrint;
begin
Delay(500);
WriteLn('THREAD TEST');
end;
{...}
BeginThread(#ThreadTest);
ReadLn(command);
'THREAD TEST' is written in the input field.
Is there any way to prevent this? I don't want to wait for the thread to finish to call ReadLn. Do I have to rewrite ReadLn using ReadKey? I'm using FreePascal with Crt and Windows.
EDIT: I need to write 'THREAD TEST' as a new line and move the ReadLn down 1 tcrtcoord, so 'THREAD TEST' is displayed properly. WriteLn works perfectly and as intended, unless called while ReadLn is in process.
I am working on reading a text file in vhdl. There are many examples on this, but I am curious why this minimal showcase example doesn't work in GHDL. It works in ModelSim (by Mentor).
Is this because of missing features in GHDL? (I did not find anything in docs/ github issues)
Is this because of wrong standard that I am using without knowing?
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use STD.textio.all;
entity test is
end test;
architecture behavioral of test is
file input : text;
begin
process
variable line_in : line;
begin
file_open(input, "input.txt");
while not endfile(input) loop
readline(input, line_in);
end loop;
wait for 100 ns;
end process;
end behavioral;
The output I get is:
./test:error: cannot open file "input.txt"
This means, there is no file/cannot be opened, but the file exists with correct access rights (proven in Modelsim). I tried this with full file name, too.
I'm using GHDL 0.37 on Linux with these flags:
--ieee=synopsys --std=08
If
file input : text;
is replaced with
file input : text open read_mode is "input.txt";
and
file_open(input, "input.txt");
is removed it works in GHDL.
However, I still don't know why the previous version did not work.
The example code is expected to fail. Note the lack of a procedure file_close call.
After the execution of the wait for 100 ns; wait statement the execution of the process statement will resume in a future simulation cycle. The statements in a process are executed in order and after the last statement (the wait statement) the first statement
file_open(input, "input.txt");
will be executed again.
Without an intervening file_close call a subsequent file_open call will fail.
IEEE Std 1076-2008
10.2 Wait statement
The timeout clause specifies the maximum amount of time the process will remain suspended at this wait statement. If no timeout clause appears, the timeout clause for (STD.STANDARD.TIME'HIGH – STD.STANDARD.NOW) is assumed. It is an error if the time expression in the timeout clause evaluates to a negative value.
11.3 Process statement
The execution of a process statement consists of the repetitive execution of its sequence of statements. After the last statement in the sequence of statements of a process statement is executed, execution will immediately continue with the first statement in the sequence of statements.
5.5.2 File operations:
In the second form of FILE_OPEN, the value returned through the Status parameter indicates the results of the procedure call:
— A value of OPEN_OK indicates that the call to FILE_OPEN was successful. If the call to FILE_OPEN specifies an external file that does not exist at the beginning of the call, and if the access mode of the file object passed to the call is write-only, then the external file is created.
— A value of STATUS_ERROR indicates that the file object already has an external file associated with it.
— A value of NAME_ERROR indicates that the external file does not exist (in the case of an attempt to read from the external file) or the external file cannot be created (in the case of an attempt to write or append to an external file that does not exist). This value is also returned if the external file cannot be associated with the file object for any reason.
— A value of MODE_ERROR indicates that the external file cannot be opened with the requested Open_Kind.
The first form of FILE_OPEN causes an error to occur if the second form of FILE_OPEN, when called under identical conditions, would return a Status value other than OPEN_OK.
The question use of the file_open procedure call is of the first form. The second form would fail returning a Status parameter value of STATUS_ERROR, already associating an external file with the file object input.
The fix for that would be to transform the wait statement to prevent the process from continuing to execute:
wait; -- wait for 100 ns;
end process;
or provide an explicit file_close call so a subsequent file_open call would succeed. (This would cause a lot of host activity for no useful purpose.)
The modified code could look like:
-- library IEEE;
-- use IEEE.STD_LOGIC_1164.all; -- NOT USED
use STD.textio.all;
entity test is
end test;
architecture behavioral of test is
file input : text;
begin
process
variable line_in : line;
begin
file_open(input, "input.txt");
while not endfile(input) loop
readline(input, line_in);
write (OUTPUT, line_in.all & LF);
end loop;
wait; -- wait for 100 ns; -- EXECUTE ONCE
end process;
end behavioral;
Yields:
%% ghdl -a --ieee=synopsys --std=08 test.vhdl
%% ghdl -e --ieee=synopsys --std=08 test
%% ghdl -r --std=08 test
some text
more text
yet some more text
getting boring
%%
Where a write to the file OUTPUT (the console) echos the contents of each line found in input.txt. Note that the end of line is removed by the readline procedure call and reintroduced to the string being written to OUTPUT.
So why does the different file declaration succeed?
architecture file_declaration of test is
-- file input : text;
file input: text open read_mode is "input.txt";
begin
process
variable line_in: line;
begin
-- file_open(input, "input.txt");
while not endfile(input) loop
readline(input, line_in);
write (OUTPUT, line_in.all & LF);
end loop;
wait for 100 ns;
end process;
end architecture file_declaration;
There's only one call to file_open, an implicit call during elaboration of the file declaration (6.4.2.5 File declarations). The file remains open yet there are no remaining lines to read, determined by the endfile call. Here the endfile call would occur every 100 ns, which would likely result in your CPU utilization to increase as test executes until TIME'HIGH is reached. Performing the endfile call would result in host file operations resulting in suspension and resumption of the ghdl model execution. An effective test of only making endfile procedure calls.
A wait statement (10.2) without a timeout clause (for 100 ns) will wait until TIME'HIGH effective ending the simulation without any intervening signal events or other process suspensions and resumptions or making TIME'HIGH/100 ns - 1 endfile procedure calls, each involving suspension and resumption of the shown process statement.
You could also specify a simulation stop time on ghdl's command line, matching the usage in Modelsim most likely:
%% ghdl -a --ieee=synopsys --std=08 test.vhdl
%% ghdl -e --ieee=synopsys --std=08 test
%% ghdl -r --std=08 test --stop-time=300ns
some text
more text
yet some more text
getting boring
./test:info: simulation stopped by --stop-time #300ns
%%
Host file operations can incur a significant execution time penalty. If you were to assign the read values to a signal or variable of a composite (array or record) type object they can be reused without waiting on host file operations.
I have a VHDL testbench where I would like to write 32-bit binary words to a file for testing. Below is a minimal, complete, verifiable example.
When executed with GHDL (commands below) an overflow is generated at the indicated line. If the line is commented out execution completes successfully and writes the file. The overflow occurs anytime the high bit is set.
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use std.textio.all;
use std.env.stop;
entity u32_file_write is
end entity;
architecture rtl of u32_file_write is
type intFileType is file of natural;
file fh : intFileType;
begin
run: process
variable no_high_bit : std_logic_vector(31 downto 0) := x"7FFFFFFF";
variable with_high_bit : std_logic_vector(31 downto 0) := x"FFFFFFFF";
begin
file_open(fh, "out.bin", write_mode);
write(fh, to_integer(unsigned(no_high_bit)));
write(fh, to_integer(unsigned(with_high_bit))); -- Overflow here.
file_close(fh);
stop;
end process;
end architecture;
I run the following GHDL commands to run the VHDL code (save as u32_file_write.vhd):
ghdl -a -fexplicit --std=08 --ieee=synopsys u32_file_write.vhd
ghdl -e -fexplicit --std=08 --ieee=synopsys u32_file_write
ghdl -r -fexplicit --std=08 --ieee=synopsys u32_file_write
With the line commented out, the corrected results are written to the file:
% od -tx4 out.bin
0000000 7fffffff
If the line is uncommented, an overflow is generated:
ghdl:error: overflow detected
from: ieee.numeric_std.to_integer at numeric_std-body.vhdl:3040
ghdl:error: simulation failed
As noted above, the write will work with any value in the first 31-bits. The write will overflow with any value where the 32-bit is set.
The underlying problem is integer'high is 2^31-1. See:
How to represent Integer greater than integer'high
The accepted answer here states to use an intermediate 'text' format a text processing language. Another answer shows a solution for reading using 'pos but that doesn't help me write.
How can I read binary data in VHDL/modelsim whithout using special binary formats
Is there a simple rework/workaround that will allow me to write all 32-bits of data to a binary file?
Change your file type to character. Convert 8 bits at a time to character and write all four characters to the file,
With 8 bit writes you're responsible for getting the endian order correct.
You can do that with a write procedure tailored to write 32 bit unsigned values to the character file:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use std.textio.all;
use std.env.stop;
entity u32_file_write is
end entity;
architecture foo of u32_file_write is
-- type intFileType is file of natural;
type intFileType is file of character; -- CHANGED type mark
file fh : intFileType;
procedure write (file cf: intFileType; val: unsigned (31 downto 0)) is
begin
write (cf, character'val(to_integer(val( 7 downto 0))));
write (cf, character'val(to_integer(val(15 downto 8))));
write (cf, character'val(to_integer(val(23 downto 16))));
write (cf, character'val(to_integer(val(31 downto 24))));
end procedure;
begin
run: process
variable no_high_bit : std_logic_vector(31 downto 0) := x"7FFFFFFF";
variable with_high_bit : std_logic_vector(31 downto 0) := x"FFFFFFFF";
begin
file_open(fh, "out.bin", write_mode);
-- write(fh, to_integer(unsigned(no_high_bit)));
-- write(fh, to_integer(unsigned(with_high_bit))); -- Overflow here.
write (fh, unsigned(no_high_bit));
write (fh, unsigned(with_high_bit));
file_close(fh);
stop;
end process;
end architecture;
ghdl -a -fexplicit --std=08 --ieee=synopsys u32_file_write.vhdl
ghdl -e -fexplicit --std=08 --ieee=synopsys u32_file_write
ghdl -r -fexplicit --std=08 --ieee=synopsys u32_file_write
Note that the only command line argument besides the command (-a, -e, -r) required here is --std-08 because of stop. There are no Synopsys package dependencies nor a requirement for -fexplicit (which isn't depended on either).
od -tx4 out.bin
0000000 7fffffff ffffffff
0000010
A host's file system contains files that consist of an array of 8 bit characters. It's convention (format) that superimposes the idea of something bigger.
VHDL superimposes type on file transactions, unfortunately there's no way to declare a natural range value greater than 2 ** 31 -1, if your integers were bigger they wouldn't be portable.
The above method treats files as character files allowing superimposition of size of elements of the contents by conventions (here in the host system, if you want to read 32 bit unsigned you'd want to read 4 characters and assemble a 32 bit value in the correct endian order).
An unsigned_int here is a 32 bit unsigned value. Note that the ascending or descending order isn't required to match in a subprogram call because of implicit subtype conversion (formals and actuals elements are associated in left to right order here).
The author of the original post encountered a problem reported in a comment:
The write() above generates an error during analysis:
u32_file_write.vhd:23:14:error: cannot resolve overloading for
subprogram call.
The error repeats four times, once for each write().
I've not found a way to get GHDL to write raw bytes other than an
integer.
Line 23 in the comment appears to correspond to the 18th line above where character 14 is the parameter list of the first write procedure call write[file IntFileType, character] which suggests the declaration for type IntFileType's type definition's type mark hasn't been changed to type character. The signature of the procedure calls would not match those of the implicitly declared write for file type IntFileType, also noting the line numbers don't match.
The code has been provided complete in this answer to allow copying in it's entirety from the question, which was done along with naming the design file with a .vhdl suffix and using the command lines above.
The version of ghdl used is a recent build (GHDL 0.36-dev (v0.35-259-g4b16ef4)) built with an AdaCore 2015 GPL gnat (GPL 2015 (20150428-49)) and tested with both the llvm backend code generator (clang+llvm-3.8.0) and mcode code generator both on MacOS (10.11.6, gnat-gpl-2015-x86_64-darwin-bin and clang+llvm-3.8.0-x86_64-apple-darwin, using Xcode 8.2.1).
(The endian order of the character writes from val in the new write procedure has been reversed to match the OP's od -xt out.bin result byte order )
If you don't absolutely need the output to be binary you could use the VHDL2008 standard procedures to directly write your vectors, without conversion:
$ ghdl --version
GHDL 0.36-dev (v0.35-259-g4b16ef4c-dirty) [Dunoon edition]
Compiled with GNAT Version: GPL 2017 (20170515-63)
llvm code generator
Written by Tristan Gingold.
Copyright (C) 2003 - 2015 Tristan Gingold.
GHDL is free software, covered by the GNU General Public License. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat u32_file_write.vhd
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use std.textio.all;
use std.env.stop;
entity u32_file_write is
end entity;
architecture rtl of u32_file_write is
begin
run: process
variable no_high_bit : std_logic_vector(31 downto 0) := x"7FFFFFFF";
variable with_high_bit : std_logic_vector(31 downto 0) := x"FFFFFFFF";
variable l: line;
file fh: text open write_mode is "out.txt";
begin
hwrite(l, no_high_bit);
writeline(fh, l);
hwrite(l, with_high_bit);
writeline(fh, l);
file_close(fh);
stop;
end process;
end architecture;
$ ghdl -a -fexplicit --std=08 u32_file_write.vhd
$ ghdl -e -fexplicit --std=08 u32_file_write
$ ghdl -r -fexplicit --std=08 u32_file_write
simulation stopped #0ms
$ cat out.txt
7FFFFFFF
FFFFFFFF
I'm using the (probably incorrect!) command
yosys -f verilog -p "prep; show stretch count.dot" count.v
for the following simple example
module count(input clk,output [7:0] LEDS);
reg [26:0] count;
assign LEDS = count[26:19];
always #(posedge clk) begin
count <= count + 1;
end
endmodule
Its not working as I'd expect giving no output to a file name I don't want...
3. Generating Graphviz representation of design.
Writing dot description to `/home/chris/.yosys_show.dot'.
ERROR: Nothing there to show.
Whats the correct way to do this?
The command line your are apparently looking for is:
yosys -p "prep; show -stretch -prefix count -format dot" count.v
Complete beginner to Ada here.
I am trying to compile and run a simple Ada program, from here: http://www.dwheeler.com/lovelace/s1sf.htm
Here is the code:
-- Demonstrate a trivial procedure, with another nested inside.
with Ada.Text_IO, Ada.Integer_Text_IO;
use Ada.Text_IO, Ada.Integer_Text_IO;
procedure Compute is
procedure Double(Item : in out Integer) is
begin -- procedure Double.
Item := Item * 2;
end Double;
X : Integer := 1; -- Local variable X of type Integer.
begin -- procedure Compute
loop
Put(X);
New_Line;
Double(X);
end loop;
end Compute;
I'm on Linux, using gnat so I do:
gnatmake -c compute.adb
gnatmake compute
Which gives me the executable. Running the executable gives a list of zeros, as it seems to initialize X to 0, even though it says to initialize it to 1, so I should get a list 1,2,4,...
Can anyone explain either where my code or my thinking is wrong? Oh and using gnat is there a way to compile and create the executable in a single command?
I can only guess that when you added "-gnato", gnatmake simply replied gnatmake: "compute" up to date. leaving you with the same executable.
brian#Gannet:~/Ada/Play$ gnatmake -gnato compute.adb
brian#Gannet:~/Ada/Play$ ./compute
1
2
...
536870912
1073741824
raised CONSTRAINT_ERROR : compute.adb:9 overflow check failed
Then without -gnato (I had to touch the source or I got the "up to date" message)
brian#Gannet:~/Ada/Play$ gnatmake compute.adb
brian#Gannet:~/Ada/Play$ ./compute
1
2
...
536870912
1073741824
-2147483648
0
0
0
0
which subsequently appears as a string of zeroes. Adding your extra "if" statement touched the file, forcing recompilation : the "if" itself is not strictly necessary (though testing and preventing constraint error is a Good Thing!)
The moral : without -gnato, or rather, without at least the flags -gnataoE -fstack_check, Gnat is not an Ada compiler.
As you double the integer value each time without any delay in the loop, it will overflow quickly. In GNAT, overflow checking is off by default, you can enable it with the -gnato switch. So when the integer value overflows, it finally gets 0 and that's what you're seeing (the output is too fast to see the initial numbers).
Compiling with -gnato should give you a constraint error on execution. You can also produce the executable with one line by executing
gnatmake -gnato compute.adb