RISC-V LLVM status update
by Alex Bradbury
As you will have seen from previous postings, I've been working on upstream
LLVM support for the RISC-V instruction set architecture. The initial RFC
<http://lists.llvm.org/pipermail/llvm-dev/2016-August/103748.html>
provides a good overview of my approach. Thanks to funding from a third party,
I've recently been able to return to this effort as my main focus. Now feels
like a good time to give an update on where the RISCV backend is at, and how
you can help.
Note: a version of this message has also been sent to the llvm-dev
mailing list <http://lists.llvm.org/pipermail/llvm-dev/2017-August/116709.html>.
## Current status
* A full, regularly rebased patchset can be found here
<https://github.com/lowRISC/riscv-llvm>.
* 16 of these patches have been put up for review so far. 7 have been
committed, and 8 are awaiting review.
* The vast majority of the GCC torture suite compiles and runs at O0,
targeting RV32I. 1315 out of 1352 compile and run (32 compile-time failures, 5
run-time failures).
* I intend to keep <http://www.lowrisc.org/llvm/status> updated with status,
test results etc.
## Next steps and getting involved
The plan has always been to work from the MC-layer upwards towards reliable
RV32I codegen. This then provides a stable 'core' of the backend where it's
easy for further development work to be parallelised, and for others to make
contributions. I think we're now at that point.
I would really like to avoid setting up a new 'downstream', and to use this
opportunity to pull in new people to upstream LLVM development. However
collaboration is made rather difficult for now due to the large gap between
the patches that have been reviewed and committed upstream vs the complete
patchset. If you would like to help, reviewing the remaining patches
<https://reviews.llvm.org/differential/?authors=asb&order=updated> is an
incredibly valuable way to do so. If you would like to be listed as a reviewer
for future patches, just let me know (and feel free to add yourself for
existing patches). I'll be doing some refactoring of RISCVInstrInfo.td as
discussed here
<http://lists.llvm.org/pipermail/llvm-dev/2017-August/116635.html>, but this
is a straight-forward non-functional change. Other than that, there are no
planned changes to the patches currently up for review.
My current plans look like the below, though of course will accelerate
significantly with more contributors:
* Next 2-3 weeks: resolve remaining torture suite issues, ABI compliance
testing, documentation on MC layer backend implementation
* End of Oct: Clang toolchain driver, initial MAFD MC layer + codegen +
calling conventions, initial benchmarking vs RISC-V GCC and generated code
quality improvements
* End of Dec: finalise MAFD support, improve MAFD compliance testing and
larger-scale codegen testing, further expanded backend docs, generated code
quality improvements
I've mapped out a number of TODO items here
<https://github.com/lowRISC/riscv-llvm/issues>, which I hope can help to
co-ordinate efforts. Where possible, this indicates the current preferred
approach (e.g. we plan to provide RV64 support building upon Krzysztof's
variable-sized register class work). I've submitted a RISC-V BoF session
proposal for the upcoming LLVM Dev Meeting. If accepted, this should provide a
great opportunity to further discuss and co-ordinate work between the multiple
parties who have expressed an interest.
## Credits and support
Thank you to everyone who has contributed review comments, suggestions, or code
to this patchset and related support patches: Chandler Carruth, Chih-Mao Chen,
David Chisnall, Simon Cook, David Craven, Hal Finkel, James Y Knight, David
Majnemer, Ed Maste, Dylan McKay, Krzysztof Parzyszek, Jordy Portman, Philip
Reames, Tim Northover, Eugene Zalenko, Florian Zeitz. Apologies to anybody who
I've missed.
This work has been performed through lowRISC CIC <http://www.lowrisc.org>, a
not-for-profit company. If your company would like to see my work on RISC-V
LLVM to be sustained or to accelerate, contributing sponsorship and/or
development time is the best way to do that. Please contact asb(a)lowrisc.org if
you would like to discuss sponsorship, or have questions about code
contributions that you can't discuss on-list.
5 years, 8 months
Re: [lowRISC/lowrisc-chip] Errors : Add a DMA master device in LowRiSC (#66)
by Dr Jonathan Kimmitt
Dear jawadhy,
The port to a different FPGA is of moderate complexity depending on the
details of peripherals available.
The Kintex series primitives are slightly different to the Artix, which
is different again to Ultrascale,
and memory sizes and dynamic memory interfaces differ between boards.
Xilinx IP versions and supported Vivado versions need to change.
Sadly not every Vivado release is robust and software support is not
available to academic institutions.
You will need a different configuration of DDR controller in most cases,
it is unlikely the video and keyboard peripherals will be compatible,
which will mean a certain amount of rewriting. Also the XCF file also
has to be changed, because signal names and pins change with different
packages and boards.
UART to USB interfaces differ a lot between boards and while it is
relatively easy to emulate a PC interface at 115200 baud, it could be
difficult to get the trace interface working at an effective speed. For
this reason we have not included a port to the KC705 since moving to
debug-v0.3.
Not every board has a SD-card interface, on some boards you may be able
to work with an external adapter.
Work has started on updating the KC705 support for debug-v0.3 on the
kc705_update branch and previous mention of VC707 support has been
discussed on this list. Also the Zedboard port was provided by a third
party.
The Nexys4_video board was purchased of part of a plan to provide more
capacity, but turned out to be disappointing due to a lack of flow
control signals on the UART. Obviously hardware designers have
conflicting demands on them for different features when designing boards
and this results in them dropping features which they consider low
priority. Another issue is the lack of USB support in the FPGA on most
boards. USB endpoints tend to terminate in off-chip IP, whereas what we
would like is to implement the USB in the FPGA (subject to area
constraints).
Looking ahead we would like to support Ethernet but there are many
different PHY chips on the different boards with multiple different
interfaces.
Another annoying problem is that multiple high-speed interfaces can
interfere with each other if used simultaneously, due to noise
considerations, bond wire inductance, and the generosity of decoupling
provided.
The decentralized nature of the git repositories makes it relatively
easy for a third party to contribute a board port.
Regards,
Jonathan
On 24/08/17 02:45, jawadhy wrote:
>
> Thanks both for your answer. How difficult is it to port the
> lowRISCv0.4 to work with bigger FPGA? was it done by other team?
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/lowRISC/lowrisc-chip/issues/66#issuecomment-324509022>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAgF13qH99zdM4NntBaLz08...>.
>
5 years, 9 months
Adding DMA device to lowrisc
by Jawad Haj-Yihia
Hello,
I'm trying to add simple DMA device to the lowrisc (lowRISC 0-4 milestone
release), I'm following the tutorial on the following link:
http://www.lowrisc.org/docs/internship-2016/device-tutorial/
But it seems the code there is not compatible with the latest release and
the compilation fails, could you please help with the syntax or code that
adds DMA device that is working with the latest release?
Regards,
Jawad Haj-Yihia
5 years, 9 months
Re: [lowRISC/lowrisc-chip] Errors : Add a DMA master device in LowRiSC (#66)
by Dr Jonathan Kimmitt
The tutorial mentioned is intended for use with the following example:
git clone -b vga --recursive https://github.com/nbdd0121/lowrisc-chip.git
From that example, you should be able to discover the differences from
the v0.3 release (primarily in LowRISCChip.scala)
This code has not been tested with the v0.4 release, but since the
changes are minor, it should be possible.
However the v0.4 release is heavily packed with logic and it may not
easily be possible to add more functionality to it successfully.
I'm sorry Chisel error messages are not more sanitary but this is
outside of our control. The fragment you give is insufficient to learn
anything.
Regards,
Jonathan
On 23/08/17 09:11, sumancu wrote:
>
> Hello,
> I'm trying to add simple DMA device to the lowrisc (lowRISC 0-4
> milestone release), I'm following the tutorial on the following link:
> http://www.lowrisc.org/docs/internship-2016/device-tutorial/
>
> But it seems the code there is not compatible with the latest release
> and the compilation fails, could you please help with the syntax or
> code that adds DMA device that is working with the latest release?
>
>
> Errors are:.
> .
> .
> .
>
> [error] (lowrisc_chip/compile:run) Nonzero exit code: 1
> [error] Total time: 15 s, completed Aug 23, 2017 1:42:11 PM
> /home/ssau/lowrisc-chip/Makefrag-build:9: recipe for target
> '/home/ssau/lowrisc-chip/vsim/generated-src/Top.DefaultL2Config.sv' failed
> make: ***
> [/home/ssau/lowrisc-chip/vsim/generated-src/Top.DefaultL2Config.sv]
> Error 1
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/lowRISC/lowrisc-chip/issues/66>, or mute the
> thread
> <https://github.com/notifications/unsubscribe-auth/AAgF1zaumUFr-dUvhOmCrqM...>.
>
5 years, 9 months
Re: [lowrisc-dev] KC705 support
by Armia Salib
Thank you, Wei, Stefan and Dr Jonathan for this support. We will share with you our changes to support KC705 once it is done.
--------------------------------------------
On Tue, 8/22/17, Dr Jonathan Kimmitt <jrrk2(a)cam.ac.uk> wrote:
Subject: Re: [lowrisc-dev] KC705 support
To: lowrisc-dev(a)lists.lowrisc.org
Date: Tuesday, August 22, 2017, 11:29 AM
The KC705 .xdc file mentions two
signals
set_property
PACKAGE_PIN M19 [get_ports USB_TX]
set_property IOSTANDARD LVCMOS25 [get_ports
USB_TX]
set_property PACKAGE_PIN K23
[get_ports USB_RTS]
set_property IOSTANDARD
LVCMOS25 [get_ports USB_RTS]
set_property
PACKAGE_PIN K24 [get_ports USB_RX]
set_property IOSTANDARD LVCMOS25 [get_ports
USB_RX]
set_property PACKAGE_PIN L27
[get_ports USB_CTS]
set_property IOSTANDARD
LVCMOS25 [get_ports USB_CTS]
You will note that the sense is the opposite of
what a rational person
would do
(i.e. it refers to the PC side). This may mean
you need to reverse the
sense of
CTS and RTS. Referring to the circuit diagram
from the Xilinx website
might help here.
Also the SD interface needs a
reset. I have tentatively connected this to
set_property PACKAGE_PIN Y21
[get_ports sd_reset]
set_property IOSTANDARD
LVCMOS25 [get_ports sd_reset]
but in the Xilinx .xdc file, this is identified
as SDIO_SDWP
The SD/MMC
card specification history has a long history of changing
names, so this also
needs
careful review.
Getting
these pins to actually work in hardware is another matter as
Stefan points out.
Jonathan
On
22/08/17 11:16, Stefan Wallentowitz wrote:
> On 22.08.2017 12:04, Wei Song wrote:
>> The 'rts' and 'cts'
signals are used for UART hardware flow control
>> which is used to support the high baud
rate.
>> Actually I am not the most
knowledgable person on this matter.
>>
On our mail list, Jonathan and Stefan have already started
to provide
>> information regarding
UART.
>> Stefan is the original author
for this high speed UART interface, which
>> amazed me initially as well.
> Hi Armia,
>
> the UART chip on the KC705 is a joke. As
you correctly observed, it only
>
supports 1MBaud. But beyond that it doesn't have
hardware flow control,
> which the
current implementation needs. Anyhow, for testing and
ramping
> up that should be okay, but for
traces it may become an issue. There is
>
the plan to add XON/XOFF flow control this winter, that will
be helpful
> then.
>
> As I said the only
setup we currently support is the Cypress Superspeed
> (USB 3.0) FMC board. We use it on the
VCU108 in another project but with
> the
same debug interface and it works like a charm. I also have
a FT300
> FMC board here, but again
won't find time before October/November to get
> it running.
>
> If anyone of you would like to work on it
instead, I am happy to assist.
>
> Cheers,
> Stefan
>
5 years, 9 months
Re: [lowrisc-dev] KC705 support
by Wei Song
The 'rts' and 'cts' signals are used for UART hardware flow control
which is used to support the high baud rate.
Actually I am not the most knowledgable person on this matter.
On our mail list, Jonathan and Stefan have already started to provide
information regarding UART.
Stefan is the original author for this high speed UART interface, which
amazed me initially as well.
-Wei
On 22/08/2017 01:14, Armia Salib wrote:
> Hello Wei,
>
> Thank you for your reply. So I am interested in adding this support to V0.3, I can contribut it back when I am done. As I mentioned before, I updated the Makefile. However, I still have minor issues:
>
> - I checked the changes in 'chip_top.sv', and I found two new IOs, 'rts' and 'cts'. I think I need to add them to 'pin_plan.xdc' based on the information in https://www.xilinx.com/support/documentation/boards_and_kits/kc705/ug810_... P46. Did I miss something?
>
> - Also, will KC705 be able to run on 12000000 UART speed? From https://www.silabs.com/documents/public/data-sheets/CP2103.pdf, I see the the UART-USB bridge support up to 1Mbps. What are the changes needed to support lower rate?
>
> Thank you in advance :).
> Armia
>
> --------------------------------------------
> On Mon, 8/21/17, Wei Song <wei.song(a)cl.cam.ac.uk> wrote:
>
> Subject: Re: [lowrisc-dev] KC705 support
> To: "Armia Salib" <armiasalib(a)yahoo.com>, "lowrisc-dev" <lowrisc-dev(a)lists.lowrisc.org>
> Cc: "Dr Jonathan Kimmitt" <jrrk2(a)cam.ac.uk>
> Date: Monday, August 21, 2017, 9:44 PM
>
> Hello Armia,
>
> KC705 is only officially supported for
> untether-v0.2.
> It is not supported for
> v0.3/0.4 only because the limited number of
> users and the limit time available on our
> end.
> There are numerous attempts to port
> lowRISC to KC705/VC707 board in
> recent
> years.
> I believe there must have been
> several successful ports, however, no one
> has contribute back yet.
> The
> port job is actually straight-forward. It is just not urgent
> enough
> for us to actually make it.
>
> Would you please file an issue
> on our GitHub? Therefore we can keep
> track
> it and may be have it done some time in the future.
> Even better, if you would like to port v0.3/0.4
> to KC705 and contribut
> it back, we can
> definitely provide help and guide you for the whole
> process.
>
> To start the port
> for v0.3, the easier way I think is to modify the
> Makefile available for the Nexys4-DDR board
> into one supporting KC705.
> The major
> difference for these two boards is the memory controller.
>
> I cc.ed Jonathan who is now in
> charge of the minion/FPGA work for lowRISC.
>
> Best regards,
> Wei
>
>
> On
> 21/08/2017 21:21, Armia Salib wrote:
> >
> Hello *,
> >
> > We bought
> KC705 board particularly to build a system that is based on
> LowRISC V0.3 project. We tried to execute "make
> bitstream" from
> "lowrisc-chip/fpga/board/kc705", but it gave the
> following errors:
> >
> >
> """
> > ERROR: [Synth
> 8-1031] dii_package is not declared
> [/home/armia/IntensivateRoot/lowrisc-chip/src/main/verilog/chip_top.sv:3]
> > ERROR: [Synth 8-1766] cannot open include
> file consts.vh
> [/home/armia/IntensivateRoot/lowrisc-chip/src/main/verilog/chip_top.sv:5]
> > ERROR: [Synth 8-1766] cannot open include
> file dev_map.vh
> [/home/armia/IntensivateRoot/lowrisc-chip/src/main/verilog/chip_top.sv:6]
> > """"
> >
> > Is KC705 board
> supported for LowRISC V0.3 and V0.4? I can change
> "lowrisc-chip/fpga/board/kc705/Makefile" with the
> msissing files, however, I am not sure if I will face more
> surprises later. What are other changes you may expect to
> support KC705?
> >
> >
> Best regards,
> > Armia
> >
>
>
5 years, 9 months
KC705 support
by Armia Salib
Hello *,
We bought KC705 board particularly to build a system that is based on LowRISC V0.3 project. We tried to execute "make bitstream" from "lowrisc-chip/fpga/board/kc705", but it gave the following errors:
"""
ERROR: [Synth 8-1031] dii_package is not declared [/home/armia/IntensivateRoot/lowrisc-chip/src/main/verilog/chip_top.sv:3]
ERROR: [Synth 8-1766] cannot open include file consts.vh [/home/armia/IntensivateRoot/lowrisc-chip/src/main/verilog/chip_top.sv:5]
ERROR: [Synth 8-1766] cannot open include file dev_map.vh [/home/armia/IntensivateRoot/lowrisc-chip/src/main/verilog/chip_top.sv:6]
""""
Is KC705 board supported for LowRISC V0.3 and V0.4? I can change "lowrisc-chip/fpga/board/kc705/Makefile" with the msissing files, however, I am not sure if I will face more surprises later. What are other changes you may expect to support KC705?
Best regards,
Armia
5 years, 9 months
Ping and Intro
by Alain Toussaint
Hello,
Just a quick ping to see if the list still exist because there was no
mail since the 24th of July.
BTW, I've been on this list to learn since a long time (February 2017
I think) but never commented before. Basically, I'm slowly learning
how to design computer with the help of the Harris & Harris book
Digital Design and Computer Architecture, second edition but
otherwise, have no formal training on anything related to computer (my
formal training is in psychology & neuroscience, see
http://journal.frontiersin.org/article/10.3389/fpsyg.2010.00241/full)
but I do regular build of linux from scratch svn version
(http://linuxfromscratch.org/lfs/) and have been running Linux in its
various form since 1998.
Alain
5 years, 9 months
