Fix#1514.
Precisions made to the LICENSE were not legal modifications to the License, just some moral precisions since things don't seemed clear for everyone.
(Won't elaborate on this, but were some reasons add these precisions).
These precisions are just willing to protect the work of the community/developers and allow the project to continue being developed with a
BSD 2-Clause License: ie share almost everything that is developed, without even thinking about potential business opportunities.
Since moral aspects seems to be modifying the license, these are just integrated in the README.md and are still a condition to:
- Expect the community to be welcoming.
- Expect free or even paid support (moral/integrity is more important than $$$ for us).
- Expect the contributions to be accepted/integrated.
So if you don't want to respect the moral precisions, up to you to use the project, but please
be coherent with yourself and don't use our time/energy; just improve/implement things by yourself :)
Move to the latest Ubuntu LTS for updated tooling. This requires us to
drop the zlibc package which no longer exists, and doesn't appear to be
required. Also update to the master branch of the GHDL action as this
contains 22.04 support.
Signed-off-by: Joel Stanley <joel@jms.id.au>
For designs willing to put the reset address of the CPU in a region not directly handled by LiteX,
self.cpu.disable_reset_address_check() can be used in the SoC to disable CPU reset address check.
Right now, when multiple masters want to access the bus,
access is granted to one of them, and is not revoked until
selected master has finished all of its transactions (cyc goes low).
This state causes master starvation if access is granted to high
bandwidth master, like cpu in busy loop.
This commit makes it so access to bus is revoked when pending transaction
is finished (ack and cyc are high) or when selected master is idle.
Signed-off-by: Maciej Dudek <mdudek@antmicro.com>
This commit fixes a bug where, retry after timeout would send another
request, but wouldn't discard a response that arrived after the timeout.
Retries worked, but only for dropped packets. If a response arrived, but
`socker.recvfrom` timed out, response would still be put in receive
queue. Later after sending another request, client would try to read
from the socket and would find a response. But this response would be
for the old request.
This way request/response pairs would get misaligned and stop working
properly.
This commit adds read numbering (writes do not have responses).
Numbering is achieved by utilizing the fact that responses to Etherbone
reads are actually writes to an address specified in a request.
This way, we don't need to extend Etherbone protocol, in fact we use it
as it is intended.
This numbering is then used to discard responses that don't match
current request.
I also cleaned setting of the timeout, as it was being set in multiple
places, sometimes to values so small that retry was bound to happen.
Signed-off-by: Michal Sieron <msieron@antmicro.com>
Now that LiteX can convert from VHDL to Verilog using GHDL, and the
required dependencies are installed in the CI environment, start testing
Microwatt.
Signed-off-by: Joel Stanley <joel@jms.id.au>
GHDL provides a github action that adds a nightly build to the CI
environment:
https://github.com/ghdl/setup-ghdl-ci
Signed-off-by: Joel Stanley <joel@jms.id.au>
By default verilator will be built with -j with no arguments, spawning
many processors. This causes large designs to failure in CI (probably
due to exhausting the memory of the build box):
Error: Process completed with exit code 143.
Set the number of jobs to the number of CPUs in the system. This allows
designs such as Microwatt to build in CI.
Signed-off-by: Joel Stanley <joel@jms.id.au>
This patch allows the AXICrossbar to absorb non-default datawidths
when the crossbar is built.
e.g. in the case of a 64-bit AXICrossbar, without this patch the
crossbar was only connecting the bottom 32 bits.
When finding the longest 1 window when write leveling, if the last tap
is 1, it won't be correctly handle because the end condition force to
judge it as 0.
Add one more iteration and force 0 in that one to handle the last 1.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
The delay finding code is based on integers, and when divided by the
count, rounding error will be quite easy to happen.
Scale up all delay value by 256x to reduce rounding error.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
On some boards, the working delay range found may be not so consecutive.
Considering this to be some inference, we should only count the biggest
consecutive delay range instead of just skip ahead for a fixed offset.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Florent Kermarrec
Joel Stanley
Maciej Dudek
Michal Sieron
bunnie
Christian Klarhorst
Icenowy Zheng
Mateusz Karlic