01-07-2018 09:40 AM
Using Vivado 2016.4 for Win64, I'm trying to do a very simple thing: use a printf inside a tiny C routine linked via DPI to a trivial systemverilog testbench, which looks like this:
import "DPI-C" function int myTest();
int rc = 0;
#500 $display("Before myTest");
#50 rc = myTest();
#50 $display("After myTest, rc = %d\n", rc);
The C routine, in file myTest.c located in my project directory, is simply this:
I process the file giving this command in the tcl console:
(where I have already cd'd to the project directory), producing dpi.a in the xsim.dir\xsc subdirectory as expected.
When run, this is the output:
# run 1000ns
After myTest, rc = 551
INFO: [USF-XSim-96] XSim completed. Design snapshot 'Test_dpi_tb_behav' loaded.
INFO: [USF-XSim-97] XSim simulation ran for 1000ns
In the output it may be noticed that the C function must have been called, since rc displays as expected as 551, but no printf() output occurs between the "before" and "after" $display outputs. The delays of 500 and 50 ns are not significant; the same thing happens when these are not used.
Other info: in sim. settings/Elaboration/More Options, besides -sv_root set to xsim.dir\xsc below the project dir., I also specify -sv_lib dpi.a, as one would expect given that linking of the C routine obviously succeeds.
I think it's reasonable to expect that a printf should output to the same console as does $display. Is this a bug, perhaps fixed in a later Vivado edition, or is something wrong with my test? An example at http://testbench.in/DP_07_DATA_TYPES.html suggests that this printf should be usable in a DPI-linked function.
I've done other tests to establish that fprintf works in conjunction with fopen/fclose, so the problem evidently concerns the value of stdout.
If anyone would care to look at this, the source files are attached. Thanks in advance.
01-07-2018 10:25 PM
I tried to simulate the files that you have shared with the below commands in the vivado TCL console using Vivado 2016.4.
xelab -svlog Test_dpi_tb.sv -sv_lib dpi -R
I did get the exact output as shown below
Thanks & Regards,
01-08-2018 02:07 PM
@shameera Thanks for your prompt reply.
At first I thought, maybe it's because ive been running xelab in project mode, and you used pure tcl. So I made a fresh directory Retest_DPI, placed both source files into it, started vivado 2016.4 and, without opening any project, gave this sequence of commands in the Tcl console:
cd .... (into the Retest_DPI directory)
exec xsc myTest.c
exec xelab -svlog Test_DPI_tb.sv -sv_lib dpi -R
Nojoy - still no printf output.
The submission system won't allow me to use the word transcrypt (spelled properly) in this message body. I don't know why - I see no mention of this in the Community rules. I suppose its for one's own protection. I've redacted the private information in the actual two of "those things" I've attached.
The first session contains the above xsc and xelab commands, starting with a directory containing no files other than the 2 source files. In that session (#0), xelab complains about an invalid --mode switch, but still produces output, which runs.
The second session (#1) is from the same xelab command repeated, but after the subdirectories had already been created by the first run. No complaint occurs in that case.
Unfortunately xsc.exe doesn't have a --version switch. xelab --version displays as "Vivado Simulator 2016". The transcrypt shows xelab build info. Since it would involve Xilinx IP, I cannot not attach the relevant .exe's & bat files, but can send them if you (representing Xilinx) would like to contact me privately. The 3 DLLs in the Microsoft.VC110,CRT subdirectory are all version 11.00.51106.1.
Sure seems like, if I have the same exe's as you, I should be getting identical results. Could there possibly be a software version difference?
Thanks again for your help.
01-08-2018 09:11 PM
The exact output that I did got in my earlier post was done in Linux machine. As, you are using Windows machine I did cross check in the windows machine and I was able to reproduce the issue i.e., the printf statement was not displayed in the console. This issue is also reproducible in Vivado 2017.3 too.
So, I did check internally and found that there was an CR#968603 filed regarding this issue and it is to be fixed in the later Vivado versions. Please note that this issue is seen only on the windows machine.
Thanks & Regards,
09-11-2019 12:39 PM
Any update on this? printf through DPI still doesn't work in 2018.3, and I can't check on 2019.1 for the moment.