i'm working on designing a mips processor using verilog in modelsim student version and we developed a c++ tool that converts assembly operations to machine code and save the result in .txt file so is there a way to make modelsim runs this tool when simulation starts ?
You can use $system("foo"); to run any system call from system verilog, including invoking your external C++ program, like ("echo hi"); or :
$system("path/to/my/cpp_binary.exe arg1 arg2 arg3");
If you wrap it in an initial block, you can run it at the beginning of simulation. See this answer.
I think you meant you want to simulate an application running on your processor. To do that, you need to have a testbench that models memory with all the necessary connections to your processor. Then get your .txt file in a form that can be read by the $readmemh() system task. Then you load the contents of file into your memory.
Related
I am trying to run multi-thread programs/benchmark in a rocket-chip SoC I generated from chipyard.
I generated the TutorialConfig SoC given in https://fires.im/isca22-slides-pdf/03_building_custom_socs.pdf, which consists of a Rocket core and a BOOM core.
To check whether I can run a multi-threaded program in this configuration, I compiled the mt-matmul benchmark in riscv-tests after changing the number of cores in crt.S file.
I ran it using the following command:
make CONFIG=TutorialStarterConfig run-binary BINARY=riscv-tests/benchmarks/mt-matmul.riscv
In the output trace, I can only see 'C0' at the beginning of each line, I am assuming I should see 'C1' if the program was executed in a second core.
Is this the correct way to run multi-threaded programs with RocketChip SoCs?
Do I need to change anything else in the programs or in the SoC?
I've written and compiled a RISC-V Linux application.
I want to dump all the instructions that get executed at run-time (which cannot be achieved by static analysis).
Is it possible to get a dynamic assembly instruction execution historgram from QEMU (or other tools)?
For instruction tracing, I go with -singlestep -d nochain,cpu, combined with some awk. This can become painfully slow and large depending on the code you run.
Regarding the statistics you'd like to obtain, delegate it to R/numpy/pandas/whatever after extracting the program counter.
The presentation or video of user "yvr18" on that topic, might cover some aspects of QEMU tracing at various levels (as well as some interesting heatmap visualization).
QEMU doesn't currently support that sort of trace of all instructions executed.
The closest we have today is that there are various bits of debug logging under the -d switch, and you can combine the tracing of "instructions translated from guest to native" with the "blocks of translated code executed" translation to work out what was executed, but this is pretty awkward.
Alternatively you could try scripting the gdbstub interface to do something like "disassemble instruction at PC; singlestep" which will (slowly!) give you all the instructions executed.
Note: There ongoing work to improve QEMU's ability to introspect guest execution so that you can write a simple 'plugin' with functions that are called back on events like guest instruction execution; with that it would be fairly easy to write a dump of guest instructions executed (or do more interesting processing), but this is still work-in-progress, so not available yet.
It seems you can do something similar with rv8 (https://github.com/rv8-io/rv8), using the command:
rv-jit -l
The "spike" RISC-V emulator allows tracing instructions executed, new values stored into registers, or just simply a histogram of PC values (from which you can extract what instruction was at each PC location).
It's not as fast as qemu, but runs at 100 to 200 MIPS on current x86 hardware (at least without tracing enabled)
I'm trying to create a Linux software in C++ which need to run code in a protected environment on x86 and x86-64 processor.
My problem is to find a way to run code in protected environment, first, only on x86-64 (it's a technical part of processors way of working), I have see Local Descriptors Table, but I found it no more works on x86-64. I also heard about the Intel VT technology, but documents seems very complicated.
Have you any idea of ways to run code in a protected environment on linux and x86-64 inside a process?
My goal is to create something like an OS inside a linux process.
Like Windows or Linux does, I want the program runned inside my protected environment no to access part of my software, and make systemcall if needed. I believe I have found a way to do so, I esxplain it below.
I have found a way to do what I want:
Each time my program will switch from main part to the program inside, it will use mprotect (a function of Glibc on Linux) to change the right to access to lot of part of the memory of the process.
Each time the program inside will make a systemcall to my program, it will change back the right to access to the memory.
You may thinks it stays security issues, because the program inside can run any kind of code and access to system call to linux and so can access to not allowed things. But I believe I can use a tricky which would prohibit the code inside to start any kind of opcodes.
I'm midway through a VHDL class and have been able to play relatively nice with the ISE and Digilent toolchain in Linux... until trying to reflash a PicoBlaze program. For details, I am currently running and targeting,
Fedora 21 64-bit (3.19.3-200.fc21.x86_64)
Nexys2 development board from Digilent (with a Spartan3)
Xilinx ISE 14.7
Adept 2.16.1 Runtime
Adept 2.2.1 Utilities
I've been able to run ISE and program the Nexys2 bit files with iMPACT just fine so far in Linux, but this current project is to write an assembly program for the PicoBlaze soft core processor, compile and update the memory of the running vector without having to resynthesize any VHDL.
Using the steps from Kris Chaplin's post, I can compile a PSM to HEX and then convert that HEX file to an SVF in dosbox. From here I can use Digilent's Adept tool in Windows to program a top_level.bit file which has the PicoBlaze already synthesized, I could also do this in ISE's iMPACT in Linux. After the design is running, I can use Adept to program the SVF file into the running memory of the design and everything is peachy. However, trying to load the SVF into iMPACT in Linux throws an exception,
EXCEPTION:iMPACT:SVFYacc.c:208:1.10 - Data mismatch.
The only issue I've found online with that error shows that there should be an '#' symbol that needs to be removed, but I haven't seen any '#'s anywhere in the SVF.
I also tried to convert the SVF to XSVF. iMPACT doesn't throw an error loading the XSVF, but programming/executing the XSVF freezes the design instead of running the new program.
Adept doesn't have a comparable GUI in Linux that I've seen, just a cmd line tool 'djtgcfg'. Just like iMPACT, I've been able to program the toplevel.bit file fine with
$ djtgcfg prog -d Nexys2 -i 0 -f ../../toplevel.bit
but attempting to program the svf file with the same call doesn't seem to affect anything. It says it should take a few minutes and immediately reports "Programming succeeded" but I don't see any change on the device.
I'd really like to keep my environment all in Linux if I can, I don't have quite enough room on my laptop to juggle between two VMs.
Is it possible to use use iMPACT to write an SVF file to the Nexus2? Or can/should I be using the Adept utility differently?
Has anyone gotten this to work? Thanks a ton!
There are many better ways to reconfigure the PicoBlaze InstructionROM without resynthesizing:
use Xilinx's data2mem tool
This toll is shipped with ISE and can patch BlockRAM contents in bit-files
=> requires FPGA reprogramming
use PicoBlaze's embedded JTAGLoader6
Enable the embedded JTAGLoader6 design in the template file. Use JTAG_Loader_RH_64 binary or JTAG_Loader_Win7_64.exe to upload a hex-file via JTAG into the PicoBlaze ROM.
=> reconfigure ROM at runtime, no FPGA reprogramming needed
The manual from Ken Chapman offers several pages on how to use JTAG_Loader. Additionally, have a look into the PicoBlaze discussions at forums.xilinx.com. There are some discussions regarding bugs and issues around JTAG_Loader and how to solve them.
Also have a look into opbasm from Kevin Thibedeau as an alternative and improved PicoBlaze assembler. It is also shipped with an ROM patch tool.
I know it's a little bit late for the original poster, but I suspect I am taking the same class and I believe I have found a solution to upload picoblaze code on linux.
Download the KCPSM3 zip file from Xilinx IP Download, extract the contents and move the executables from the JTAG_loader folder to your working directory.
In dosbox run hex2svfsetup.exe for the nexys2 board select menu options 4 - 0 - 1 - 8
Use the assembler to create the .hex file
In dosbox run hex2svf.exe to create the svf file
Then run svf2xsvf.exe -d -i < input.svf > -o < output.xsvf >
The contrary to the JTAG_Loader_quick_guide.pdf in the initial zip file use impact and open the xsvf file and program using the xsvf file.
I need to compile by simulink inside BB hardware a block that returns an .avi video signal like the 'From a Multimedia File' simulink block.
I tried to compile a simulink model with 'From a Multimedia File' block but building fails since, i think, it can not transfer "block + file" into BB.
How can i make it to out a video file signal as stand-alone application ?
Does the BB have any file I/O? Otherwise, it doesn't make sense at all to generate code for the block... The doc for the DSP block says:
This block supports code generation for the host computer that has
file I/O available. You cannot use this block with Real-Time Windows
Target™ software because that product does not support file I/O.
It also says that the "generated code for this block relies on prebuilt library files" and recommends using PackNGo to make sure all the dependencies are included in the generated code. If you haven't look at the documentation for the block yet, I strongly recommend that you do so.
Also, there is another block with the same name from the Computer Vision System Toolbox, which one are you referring to? Again, look at the doc, it has the same comments about requiring prebuilt library files.
I'm not sure whether the code generation will work with the BB target (note that the doc only mentions "host" computer as opposed to target), but the fact remains that the target does require file I/O otherwise it's a pointless exercise.