I'm working on riscv-sodor and I want to modify the Makefile to generate Verilog. How can I do this task?
Regards,
From the Sodor README (https://github.com/ucb-bar/riscv-sodor):
How can I generate Verilog myself?
You can generate the Verilog code by modifying the Makefile in emulator/common/Makefile.include. In the CHISEL_ARGS variable, change "--backend c" to "--backend v". This will dump a Top.v verilog file of the core and its scratchpad memory (corresponding to the Chisel module named "Top") into the location specified by "--targetDir" in CHISEL_ARGS.
Once you have the Top.v module, you will have to write your own testharness and glue code to talk to Top.v. The main difficulty here is that you need to link the riscv-fesvr to the Sodor core via the HTIF link ("host-target interface"). This allows the fesvr to load a binary into the Sodor core's scratchpad memory, bring the core out of reset, and communicate with the core while it's running to handle any syscalls, error conditions, or test successful/end conditions.
This basically involves porting emulator/*/emulator.cpp to Verilog. I recommend writing a Verilog testharness that interfaces with the existing C++ code (emulator/common/htif_emulator.cc, etc.). emulator/common/htif_main.cc shows an example stub that uses Synopsys's DirectC to interface between a Verilog test-harness and the existing C++ code.
Related
I can read/write an external sdram using fmc in stm32f429. But working with address and read/write functions is not proper for my purpose. I want to introduce external sdram as if internal sram is clearly extended and whenever I define a big variable it is projected to external sdram automatically.
I checked stm32f4 cubemx repository examples (SDRAM+DATAMEMORY) and searched a lot but it seems this is not straightforward.
Following these steps based on what I found, I get hardfault after system_init.
Defining external sdram address and size in the linker (off-chip ram)
Adding some code in startup_stm32f420xx.s
Defining DATA_IN_ExtSDRAM for initializing sdram before main function
Enabling system clock before main function
My external sdram is connected to SDRAM1 in stm32f429.
What is the correct procedure? Is SystemInit_ExtMemCtl() function implemented correctly? Is any modification needed? Is enabling clock before main function and after system_init needed?
Can anyone tell what is the correct code step by step?
Thanks in advance.
What you are asking for is not really possible.
The internal SRAM and external SDRAM are not contiguous; their addresses are a long way apart and variables cannot simply overflow automatically from one to the other.
The correct steps for using the external memory are exactly as given in the example projects, it would be meaningless to repeat them here.
The work you have to do yourself is to decide which variables go in which memory. You can assign a variable to a section using the gcc section attribute or a similar feature of another compiler. There are examples of this in the STM32Cube package.
I am Trying to understand How linux printing
"Uncompressing Linux....... done, booting the kernel"
message even before it uncompressed itself in ARM Versatile Boad.
From this File the function decompress_kernel is writing the message through putstr() function which inturn have putc function which writing to hardware register uart.
putc is implemented in this file, putc writes directly to AMBA_UART_DR registers and these registers are different across architectures and also differs across different chips too.
But in the latest kernel-4.6 this was deprecated .
When i checked putc implemetation for ARM Versatile Boad in latest kernel its been deprecated so
how they implemented in latest kernel-4.6 where as rest of machine-specific code still exist?
How kernel is printing the banner in latest kernel?
Versatile board support code was converted to the multi-platform kernel model (ARCH_MULTIPLATFORM). Just like every other board support code of the same kind, now it takes putc() prototype from arch/arm/include/debug/uncompress.h.
Instead, the actual implementation of putc() is a generic assembly function coded into arch/arm/boot/compressed/debug.S.
Being generic, debug.S makes reference to few macros (addruart, waituart, senduart, busyuart) to get information about the actual UART hardware. These macros are defined in an include file selected by CONFIG_DEBUG_LL_INCLUDE (search arch/arm/Kconfig.debug for it). In case of the Versatile board CONFIG_DEBUG_LL_INCLUDE is defined as arch/arm/include/debug/pl01x.S, where in fact you find those macros.
The typical example workflow for OpenCL programming seems to be focused on source code within strings, passed to the JIT compiler, then finally enqueued (with a specific kernel name); and the compilation results can be cached - but that's left for you the programmer to take care of.
In CUDA, the code is compiled in a non-JIT way to object files (alongside host-side code, but forget about that for a second), and then one just refers to device-side functions in the context of an enqueue or arguments etc.
Now, I'd like to have the second kind of workflow, but with OpenCL sources. That is, suppose I have some C host-side code my_app.c, and some OpenCL kernel code in a separate file, my_kernel.cl (which for the purpose of discussion is self-contained). I would like to be able to run a magic command on my_kernel.cl, get a my_kernel.whatever, link or faux-link that together with my_app.o, and get a binary. Now, in my_app.c I want to be able to somehow to refer to the kernel, even if it's not an extern symbol, as compiled OpenCL program (or program + kernel name) - and not get compilation errors.
Is this supported somehow? With nVIDIA's ICD or with one of the other ICDs? If not, is at least some of this supported, say, the magic kernel compiler + generation of an extra header or source stub to use in compiling my_app.c?
Look into SYCL, it offers single-source C++ OpenCL. However, not yet available on every platform.
https://www.khronos.org/sycl
There is already ongoing effort that enables CUDA-like workflow in TensorFlow, and it uses SYCL 1.2 - it is actively up-streamed.
Similarly to CUDA, SYCL's approach needs the following steps:
device registration via device factory ( device is called SYCL ) - done here: https://github.com/lukeiwanski/tensorflow/tree/master/tensorflow/core/common_runtime/sycl
operation registration for above device. In order to create / port operation you can either:
re-use Eigen's code since Tensor module has SYCL back-end ( look here: https://github.com/lukeiwanski/tensorflow/blob/opencl/adjustcontrastv2/tensorflow/core/kernels/adjust_contrast_op.cc#L416 - we just partially specialize operation for SYCL device and calling the already implemented functor https://github.com/lukeiwanski/tensorflow/blob/opencl/adjustcontrastv2/tensorflow/core/kernels/adjust_contrast_op.h#L91;
write SYCL code - it has been done for FillPhiloxRandom - see https://github.com/lukeiwanski/tensorflow/blob/master/tensorflow/core/kernels/random_op.cc#L685
SYCL kernel uses modern C++
you can use OpenCL interoperability - thanks to which you can write pure OpenCL C kernel code! - I think this bit is most relevant to you
The workflow is a bit different as you do not have to do an explicit instantiation of the functor templates as CUDA does https://github.com/lukeiwanski/tensorflow/blob/master/tensorflow/core/kernels/adjust_contrast_op_gpu.cu.cc or any .cu.cc file ( in fact you do not have to add any new files - avoids mess with the build system )
As well as this thing: https://github.com/lukeiwanski/tensorflow/issues/89;
TL;DR - CUDA can create "persistent" pointers, OpenCL needs to go through Buffers and Accessors.
Codeplay's SYCL compiler ( ComputeCpp ) at the moment requires OpenCL 1.2 with SPIR extension - these are Intel CPU, Intel GPU ( Beignet work in progress ), AMD GPU ( although older drivers ) - additional platforms are coming!
Setup instructions can be found here: https://www.codeplay.com/portal/03-30-17-setting-up-tensorflow-with-opencl-using-sycl
Our effort can be tracked in my fork of TensorFlow: https://github.com/lukeiwanski/tensorflow ( branch dev/eigen_mehdi )
Eigen used is: https://bitbucket.org/mehdi_goli/opencl ( branch default )
We are getting there! Contributions are welcome! :)
Where can I find the source code of some of the system calls? For example, I am looking for the implementation of fstat as described here.
A system call is mostly implemented inside the Linux kernel, with a tiny glue code in the C standard library. But see also vdso(7).
From the user-land point of view, a system call (they are listed in syscalls(2)...) is a single machine instruction (often SYSENTER) with some calling conventions (e.g. defining which machine register hold the syscall number - e.g. __NR_stat from /usr/include/asm/unistd_64.h....-, and which other registers contain the arguments to the system call).
Use strace(1) to understand which system calls are done by a given program or process.
The C standard library has a tiny wrapper function (which invokes the kernel, following the ABI, and deals with error reporting & errno).
For stat(2), the C wrapping function is e.g. in stat/stat.c for musl-libc.
Inside the kernel code, most of the work happens in fs/stat.c (e.g. after line 207).
See also this & that answers
I'm trying to simulate ICE5LP1K FPGA internal oscillator on ModelSim. My design includes the following instance:
SB_HFOSC OSCInst1 (
.CLKHFEN(1'b1),
.CLKHFPU(1'b1),
.CLKHF(CLKLF)
)
I included sb_ice_syn.v file but have a design loading error:
Error: ../testbench/sb_ice_syn.v(26066): Module 'SB_HFOSC_CORE' is not defined
I'm not able to find SB_HFOSC_CORE module in the lattice installation folder.
Where can I find the missed modules?
Doing ModelSim simulation of a Lattice ICE40 family (ICE5LP1K device) design with PLLs requires that a Verilog model of the PLL is included. This is described in Lattice Application Note AN006 (see "c:\lscc\iCEcube2.2015.04\doc\Modelsim_AN006.pdf" for latest iCEcube2 version) on page 9:
If your design contains PLL, add ABIPTBS8.v and ABIWTCZ4.v in $INST_DIR/verilog. For performing Post-Synth simulation for a VHDL design having PLL, you will require a mixed-language simulator, since the PLL model (ABIPTBS8.v) is available only in verilog format.
If the design contains Hardened IP primitives, add the encrypted Verilog simulation library sb_ice_ipenc_modelsim.v available in $INST_DIR/Verilog.
An alternative is if you write a simple simulation model of the SB_HFOSC_CORE PLL core, and then include this in the simulation, since I assume that your focus is on verification of the remaining design, so you probably only need the PLL to give a usable clock.
It is working now.
I found the missing module in the sb_ice_ipenc_modelsim.v