Fwd: [lowrisc-dev] Multiple Rockets and Minions memory hierarchy
by Daniel Follesø
Hi.
Regarding the Nexys Video card I see two possibilities for an improved
debug link. The DPTI/ DSPI link (See section 7 of "https://reference.
digilentinc.com/_media/nexys-video:nexys_video_rm.pdf")
I have run some basic loopback tests over DPTI at speed up to 5 MB/s using
the demo that comes with Digient ADEPT 2. Have also found a an AXI
component of DPTI Written in VHDL :"https://github.com/Digilent/
vivado-library/tree/master/ip/AXI_DPTI_1.0". Drivers for the FT2232H chip
is needed. FTDI makes their closed drivers "D2XX". An open alternative is
"libFTDI".
Here is a "proof of consept" that got me started:
"*http://steckdenis.be/post-2016-06-25-fast-usb-connection-on-the-nexys-video-using-ft2232h.html
<http://steckdenis.be/post-2016-06-25-fast-usb-connection-on-the-nexys-vid...>*
".
In addition i have looked at Ethernet interface with the card. Have found
some resources on git specifically targets the Nexys Video Ethernet module.
These are described using VHDL, so might need some rewriting. I have some
experience working with VHDL and have done some translation from verilog to
VDHL av few years ago.
Just some thoughts on ways to get support for the much more capable Nexys
Video.
--Daniel
2017-05-30 19:14 GMT+02:00 Dr Jonathan Kimmitt <jrrk2(a)cam.ac.uk>:
> The target board for the minion-v0.4 release is Nexys-4DDR. We had to cut
> out some optional features for this board. Unfortunately the next low cost
> board in the same series, the Nexys-Video, lacks flow control on its UART,
> which causes problems for the trace debugger. Our build system in principle
> supports SMP rocket systems that share L2-cache and DDR memory, coherence
> is managed by TileLink. I don't think anybody has built it for FPGA
> recently.
>
> Regards,
> Jonathan Kimmitt
> LowRISC team member
>
> Sent from my iPhone
>
> > On 30 May 2017, at 17:33, Tobias Strauch <tobias(a)cloudx.cc> wrote:
> >
> > Hi guys,
> >
> > may I add a question to the one below:
> >
> > 3) I know it has mentioned a few months ago, but what would be the
> target virtex eval board for the next lowrisc release. maybe Wei mentioned
> it (and the questions below) at the WS, but the sound is terrible.
> >
> > thank you for your answer in adcance, see you in Hebden Bridge, cheers,
> Tobias
> >
> >
> >> Tobias Strauch <tobias(a)cloudx.cc> hat am 17. April 2017 um 12:39
> geschrieben:
> >>
> >>
> >> Hi Rob et al.,
> >>
> >> thank you for sharing an update on your wonderful project at the RISC-V
> WS in Munich.
> >>
> >> I’ve been following the lowRISC project closely and I was wondering, if
> I may ask you two questions.
> >>
> >> 1) Support for (many) MultiCores (except the Minions):
> >>
> >> Are you still planning to go for a solution, that supports multiple
> cores of the same kind (except the Minion Cores Network), so let’s say,
> multiple rockets, multiple BOOMs etc. I’m particular interested in how you
> solve the cache coherence\software\OS software problems that come with it.
> >>
> >> 2) Minions and local memory
> >>
> >> Will you attach local memory to the individual minions, and if so, how
> will your global memory hierarchy look like?
> >>
> >> Thank you so much in advance for your answers.
> >>
> >> Cheers, Tobias
> >>
> >> PS: Can’t wait to work with your next release.
> >>
> >> PPS: I think the survey on the RISC-V cores you mentioned is highly
> appreciated.
> >>
> >
>
>
5 years, 11 months
Multiple Rockets and Minions memory hierarchy
by Tobias Strauch
Hi Rob et al.,
thank you for sharing an update on your wonderful project at the RISC-V WS in Munich.
I’ve been following the lowRISC project closely and I was wondering, if I may ask you two questions.
1) Support for (many) MultiCores (except the Minions):
Are you still planning to go for a solution, that supports multiple cores of the same kind (except the Minion Cores Network), so let’s say, multiple rockets, multiple BOOMs etc. I’m particular interested in how you solve the cache coherence\software\OS software problems that come with it.
2) Minions and local memory
Will you attach local memory to the individual minions, and if so, how will your global memory hierarchy look like?
Thank you so much in advance for your answers.
Cheers, Tobias
PS: Can’t wait to work with your next release.
PPS: I think the survey on the RISC-V cores you mentioned is highly appreciated.
6 years
Re: Weekly Report of Porting musl to RISC-V Project #5
by Alan Pillay
What is the current status of musl on RISC-V?
This was the last time I heard about it, but it has been many months since.
Regards.
> Hello,
>
> Thanks to the folks, I passed the mid-term evaluation. Now it is about
> time to publish the fifth progress report on porting musl on RISC-V.
>
> Last week, the toolchain itself has been built for RISC-V and running
> on Spike, and libc-test [1] can be executed with it now. I posted the
> result of tests on [2]. The REPORT.txt file contains all error
> messages of failed tests, both run-time ones and compile-time ones.
>
> Some failures are expected since musl on x86_64 also does the same
> ones (e.g. errors in src/api/fcntl.c), but there are some unexpected
> errors too. I guess that the "warning: <the name of a header> is
> shorter than expected" warning indicates bugs in arch-dependent part
> of I/O functions or system calls (or kernel?) and it causes syntax
> errors in the same compilation unit.
>
> Moreover, some tests triggers a "signal 11" error (segmentation fault)
> in libc. I added some logs to [2]. They are bugs in the port,
> obviously. I am working on them.
>
> The good news is, anyway, some results are *better than x86_64*,
> especially in math functions :-)
> (probably the cause is the difference in the floating-point precision,
> though. it is usual in float tests...)
>
> It takes long, long time to get but finally I have a (seems-to-be)
> working test suite for the port. I will continue to debug and fix the
> port using the result. Stay tuned!
>
>
> [1]: http://nsz.repo.hu/git/?p=libc-test
> [2]: https://gist.github.com/omasanori/ee828369aea844ac7fdfdc8362953299
>
> --
> Masanori Ogino
6 years
Regarding Release version 0.3
by Daniel Follesø
Hello lowRISC community.
First of I would like to say that this is a really exciting project! Keep
up the great work!
The last few months I have ben getting familiar with the lowRISC project as
part of an electronics/ processor course here in Norway.
So far my main focus have been on getting “Release version 0.3” implemented
on the Nexys4 DDR board. I have also been looking into some possibilities
of updating the Nexys Video board port so that it works with trace debugger
capabilities( I might come back to you in a few weeks regarding this).
During the process I have had several issues (mostly related to Vivado),
and have therefore documented the process of going from a clean system
install to a working DebugConfig.
The last couple of days I have tried to make sure that my guide works every
time (witch it seems to be). I am running "Lubuntu 16.04 LTS", "Vivado
2015.4" and "gcc version 5.4.0" at the moment.
I can share this guide if it is of any use to the project. I am also open
to help updating the documentation on the site to make it more up to date.
One thing I would like some input on is the state of my build of the The
RISC-V GCC/Newlib Toolchain. It seems to work( I can compile and run
programs in spike), but I get quite a few warnings during the build process
that I cannot wrap my head around. I would be very pleased to get some
feedback on this. Is this expected behavior?
Attached is a copy of the terminal dump from one trial of the build process.
BTW: I have never been able to run the demo files on the Nexys4 DDR. Have
always had to generate the bitstream and Busybox from source.
Best regards
Daniel Folleso
6 years
Re: [lowrisc-dev] CTM Debug
by Armia Salib
Great. I will use these hints. I really enjoyed working with LowRISC :).
--------------------------------------------
On Mon, 5/22/17, Philipp Wagner <lists(a)philipp-wagner.com> wrote:
Subject: Re: [lowrisc-dev] CTM Debug
To: "Armia Salib" <armiasalib(a)yahoo.com>, lowrisc-dev(a)lists.lowrisc.org, "Wei Song" <ws327(a)cam.ac.uk>
Date: Monday, May 22, 2017, 4:33 PM
Hi,
good you figured it out.
A couple notes and observations:
- It's expected that the
UART off-chip interface cannot handle all
packets generated by the CTM. In this case,
"dropped packet" markers
should
be inserted into the trace stream. However, it wouldn't
surprise
me if there was a bug lurking in
there somewhere.
- It
currently is a known bug that the opensocdebug software part
is
rather unoptimized regarding throughput
and decoding and writing higher
volumes of
traces requires too much CPU power. As you found out, the
workaround for now is to give the software
more CPU power :-)
-
Virtual machines and USB are not best friends, especially if
combined
with UART to USB dongles. From our
experience, the Nexys 4 DDR board,
however,
is at least not especially bad in this regard (unlike many
higher priced Xilinx eval boards). However,
if possible run on native
hardware with no
USB hubs in between and don't connect to USB 3 ports.
If running VirtualBox, make sure to always
install the VirtualBox
Extension Pack with
the USB drivers.
I'm
currently refactoring the opensocdebug software part to give
better
performance and reliability.
However, this work is still a bit off, so
unfortunately you need to continue using the
workaround you found until
then.
Best,
Philipp
On 05/22/2017 10:31 AM, Armia Salib wrote:
> Hello Philipp and Wei,
>
> Thank you for your
help. I really appreciate that. In normal operation CTM can
work fine for me. However when I tried it to debug the Linux
boot. I faced some troubles. After debugging I realized that
the CTM generates very high packets throughput in this case,
and it seems that the program running on the virtual machine
cannot handle such throughput. To relax this I did the
following:
> 1- Installed Orcale VM
extension.
> 2- Use USB 3.0 instead of
the default 1.1.
> 3- Assign two
processor cores to run the virtual machine.
> 4- Add many stalling cycles on branching,
to reduce the CTM packet rate, and reduces the misses.
>
> After these changes,
I can collect the needed logs that I need in my debugging
process.
>
> For
reference, you may find below the list of commands needed to
create the bitstream and download into the Nexys4DDR.
>
> Best regards,
> Armia
>
>
>
>
>
> # Clone repository.
>
git clone -b debug-v0.3 https://github.com/lowrisc/lowrisc-chip.git
> cd lowrisc-chip
> git
submodule update --init --recursive
>
> # Compile the building tools.
> source set_env.sh
> cd
$TOP/riscv-tools
> ./build.sh
>
> # Building the Linux
GCC
> cd
$TOP/riscv-tools/riscv-gnu-toolchain
> cd
build
> ../configure --prefix=$RISCV
> make -j$(nproc) linux
>
> # Build glip software
> cd $TOP/opensocdebug/glip
> ./autogen.sh
> mkdir
build; cd build
> ../configure
--prefix=$OSD_ROOT --enable-tcp --enable-uart
> make && make install
>
> # Build Open SoC
Debug software
> cd
$TOP/opensocdebug/software
>
./autogen.sh
> mkdir build; cd build
> ../configure --prefix=$OSD_ROOT
--enable-python-bindings
> make
&& make install
>
> # Create the bitstream.
> cd $TOP/fpga/board/nexys4_ddr/
> source
/opt/Xilinx/Vivado/2015.4/settings64.sh
>
make bitstream
> make jump
>
> # Prepare Linux.
> cd $TOP/riscv-tools
>
curl https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.6.2.tar.xz
| tar -xJ
> curl -L http://busybox.net/downloads/busybox-1.21.1.tar.bz2
| tar -xj
> cd linux-4.6.2
> git init
> git remote
add origin https://github.com/lowrisc/riscv-linux.git
> git fetch
> git
checkout -f -t origin/debug-v0.3
> #
lowRISC-specific hack for enabling power pin for SD card
> patch -p1 < spi_sd_power_hack.patch
> cd $TOP/fpga/board/nexys4_ddr
> $TOP/riscv-tools/make_root.sh
>
> # Download the
bitstream and open opensocdebugd.
> sudo
adduser <username> dialout
> vivado
-mode batch -source $TOP/fpga/common/script/program.tcl
-tclargs "xc7a100t_0"
./lowrisc-chip-imp/lowrisc-chip-imp.runs/impl_1/chip_top.new.bit
> opensocdebugd uart device=/dev/ttyUSB1
speed=12000000
>
> #
From another terminal execute.
>
osd-cli
>
> # Execute
the following commands on osd-cli.
>
reset -halt
> terminal 2
> mem loadelf boot.bin 3
> ctm log ctm.log 4
>
start
>
>
>
>
>
>
--------------------------------------------
> On Mon, 5/22/17, Philipp Wagner <lists(a)philipp-wagner.com>
wrote:
>
>
Subject: Re: [lowrisc-dev] CTM Debug
>
To: lowrisc-dev(a)lists.lowrisc.org
> Date: Monday, May 22, 2017, 8:38 AM
>
> Hi,
>
> On
> 05/20/2017 03:08 PM, Armia Salib
wrote:
> >
>
Hello all,
> >
> > I am
>
trying to use CTM to debug the booting of the Linux. I am
> using LowRISC V0.3. I followed the
steps in section
> 'Directly load
Linux to DDR RAM' in
'http://www.lowrisc.org/docs/debug-v0.3/fpga/'.
> I also added the following command
after loadelf
> 'ctm log ctm.log
4' to enable the CTM logs.
>
>
> > However, after the
> 'start' command, the Linux
start to boot for a
> while, then
opensocdebugd program crashes due to
>
segmentation fault. I can see some logs in
> 'ctm.log'
> >
> >
> Is there anyone experience this
behaviour before? Do you
> have any
hints to debug this issue further?
>
>
> > Just a note, I am
> using Ubuntu 14.04.5 LTS virtual
machine. When I used Ubuntu
> 16.04.2
LTS, opensocdebugd always crashes even without any
> CTM and with simple program.
>
> We're
using Ubuntu 16.04 most of the time,
>
and it should work fine
> there. Could
you
> please create a backtrace of the
segfault by running
>
> gdb --args opensocdebugd uart
> .... (add all parameters as you usually
would)
> # ... wait until it crashes
...
> bt
>
> And post
> the
output here.
>
>
Philipp
>
>
>
6 years
Re: [lowrisc-dev] CTM Debug
by Armia Salib
Hello Philipp and Wei,
Thank you for your help. I really appreciate that. In normal operation CTM can work fine for me. However when I tried it to debug the Linux boot. I faced some troubles. After debugging I realized that the CTM generates very high packets throughput in this case, and it seems that the program running on the virtual machine cannot handle such throughput. To relax this I did the following:
1- Installed Orcale VM extension.
2- Use USB 3.0 instead of the default 1.1.
3- Assign two processor cores to run the virtual machine.
4- Add many stalling cycles on branching, to reduce the CTM packet rate, and reduces the misses.
After these changes, I can collect the needed logs that I need in my debugging process.
For reference, you may find below the list of commands needed to create the bitstream and download into the Nexys4DDR.
Best regards,
Armia
# Clone repository.
git clone -b debug-v0.3 https://github.com/lowrisc/lowrisc-chip.git
cd lowrisc-chip
git submodule update --init --recursive
# Compile the building tools.
source set_env.sh
cd $TOP/riscv-tools
./build.sh
# Building the Linux GCC
cd $TOP/riscv-tools/riscv-gnu-toolchain
cd build
../configure --prefix=$RISCV
make -j$(nproc) linux
# Build glip software
cd $TOP/opensocdebug/glip
./autogen.sh
mkdir build; cd build
../configure --prefix=$OSD_ROOT --enable-tcp --enable-uart
make && make install
# Build Open SoC Debug software
cd $TOP/opensocdebug/software
./autogen.sh
mkdir build; cd build
../configure --prefix=$OSD_ROOT --enable-python-bindings
make && make install
# Create the bitstream.
cd $TOP/fpga/board/nexys4_ddr/
source /opt/Xilinx/Vivado/2015.4/settings64.sh
make bitstream
make jump
# Prepare Linux.
cd $TOP/riscv-tools
curl https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.6.2.tar.xz | tar -xJ
curl -L http://busybox.net/downloads/busybox-1.21.1.tar.bz2 | tar -xj
cd linux-4.6.2
git init
git remote add origin https://github.com/lowrisc/riscv-linux.git
git fetch
git checkout -f -t origin/debug-v0.3
# lowRISC-specific hack for enabling power pin for SD card
patch -p1 < spi_sd_power_hack.patch
cd $TOP/fpga/board/nexys4_ddr
$TOP/riscv-tools/make_root.sh
# Download the bitstream and open opensocdebugd.
sudo adduser <username> dialout
vivado -mode batch -source $TOP/fpga/common/script/program.tcl -tclargs "xc7a100t_0" ./lowrisc-chip-imp/lowrisc-chip-imp.runs/impl_1/chip_top.new.bit
opensocdebugd uart device=/dev/ttyUSB1 speed=12000000
# From another terminal execute.
osd-cli
# Execute the following commands on osd-cli.
reset -halt
terminal 2
mem loadelf boot.bin 3
ctm log ctm.log 4
start
--------------------------------------------
On Mon, 5/22/17, Philipp Wagner <lists(a)philipp-wagner.com> wrote:
Subject: Re: [lowrisc-dev] CTM Debug
To: lowrisc-dev(a)lists.lowrisc.org
Date: Monday, May 22, 2017, 8:38 AM
Hi,
On
05/20/2017 03:08 PM, Armia Salib wrote:
>
Hello all,
>
> I am
trying to use CTM to debug the booting of the Linux. I am
using LowRISC V0.3. I followed the steps in section
'Directly load Linux to DDR RAM' in 'http://www.lowrisc.org/docs/debug-v0.3/fpga/'.
I also added the following command after loadelf
'ctm log ctm.log 4' to enable the CTM logs.
>
> However, after the
'start' command, the Linux start to boot for a
while, then opensocdebugd program crashes due to
segmentation fault. I can see some logs in
'ctm.log'
>
>
Is there anyone experience this behaviour before? Do you
have any hints to debug this issue further?
>
> Just a note, I am
using Ubuntu 14.04.5 LTS virtual machine. When I used Ubuntu
16.04.2 LTS, opensocdebugd always crashes even without any
CTM and with simple program.
We're using Ubuntu 16.04 most of the time,
and it should work fine
there. Could you
please create a backtrace of the segfault by running
gdb --args opensocdebugd uart
.... (add all parameters as you usually would)
# ... wait until it crashes ...
bt
And post
the output here.
Philipp
6 years
CTM Debug
by Armia Salib
Hello all,
I am trying to use CTM to debug the booting of the Linux. I am using LowRISC V0.3. I followed the steps in section 'Directly load Linux to DDR RAM' in 'http://www.lowrisc.org/docs/debug-v0.3/fpga/'. I also added the following command after loadelf 'ctm log ctm.log 4' to enable the CTM logs.
However, after the 'start' command, the Linux start to boot for a while, then opensocdebugd program crashes due to segmentation fault. I can see some logs in 'ctm.log'
Is there anyone experience this behaviour before? Do you have any hints to debug this issue further?
Just a note, I am using Ubuntu 14.04.5 LTS virtual machine. When I used Ubuntu 16.04.2 LTS, opensocdebugd always crashes even without any CTM and with simple program.
Best regards,
Armia
6 years
ISA baseline for lowRISC -- will it implement the C extension?
by Manuel A. Fernandez Montecelo
Hi,
There have been discussions in the RISC-V sw-dev mailing list about the
default ABIs, and Krste explained that C would be very much a
recommended default for systems planning to support Unix-like OSs, so
the recommendation would be to support RV64GC.
So just to make sure and in the interest of targetting baseline ABIs
that work for most hardware out there... will lowRISC support that
extension?
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo(a)gmail.com>
6 years
Want to contribute
by Nishant Pani
Hello,
I am Nishant a fresh graduate in Electronics. I have fair amount of Verilog
and FPGA Experience. I would like to contribute to developing open source
IP for the lowRISC project. Any pointers to what are the cores the
community wants to develop and how to start developing these
Regards
Nishant
6 years
