Currently the individual IP core dependencies are tracked inside the
library Makefile for Xilinx IPs and the project Makefiles only reference
the IP cores.
For Altera on the other hand the individual dependencies are tracked inside
the project Makefile. This leads to a lot of duplicated lists and also
means that the project Makefiles need to be regenerated when one of the IP
cores changes their files.
Change the Altera projects to a similar scheme than the Xilinx projects.
The projects themselves only reference the library as a whole as their
dependency while the library Makefile references the individual source
dependencies.
Since on Altera there is no target that has to be generated create a dummy
target called ".timestamp_altera" who's only purpose is to have a timestamp
that is greater or equal to the timestamp of all of the IP core files. This
means the project Makefile can have a dependency on this file and make sure
that the project will be rebuild if any of the files in the library
changes.
This patch contains quite a bit of churn, but hopefully it reduces the
amount of churn in the future when modifying Altera IP cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
This reduces the amount of boilerplate code that is present in these
Makefiles by a lot.
It also makes it possible to update the Makefile rules in future without
having to re-generate all the Makefiles.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The external s_axi_{awaddr,araddr} signals that are connect to the core
have their width set according to the specified size of the register map.
If the s_axi_{awaddr,araddr} signal of the core is wider (as it currently
is for many cores) the MSBs of those signals are left unconnected, which
generates a warning.
To avoid this make sure that the signal width matches the declared register
map size.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Move the CDC helper modules to a dedicated helper modules. This makes it
possible to reference them without having to use file paths that go outside
of the referencing project's directory.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
All the hdl (verilog and vhdl) source files were updated. If a file did not
have any license, it was added into it. Files, which were generated by
a tool (like Matlab) or were took over from other source (like opencores.org),
were unchanged.
New license looks as follows:
Copyright 2014 - 2017 (c) Analog Devices, Inc. All rights reserved.
Each core or library found in this collection may have its own licensing terms.
The user should keep this in in mind while exploring these cores.
Redistribution and use in source and binary forms,
with or without modification of this file, are permitted under the terms of either
(at the option of the user):
1. The GNU General Public License version 2 as published by the
Free Software Foundation, which can be found in the top level directory, or at:
https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
OR
2. An ADI specific BSD license as noted in the top level directory, or on-line at:
https://github.com/analogdevicesinc/hdl/blob/dev/LICENSE
There are devices which have a asynchronous data ready signal. (asynchronous
with the spi clock) The CDC stages can be enabled by setting up
the ASYNC_TRIG parameter.
By changing the parameter called SDI_DATA_WIDTH the spi framework can support multiple SDI lines.
The supported number of SDI lines are: 1, 2, 3 and 4.
Add .gitattributes file which sets up the eol encoding handling. This will
make sure that we get a uniform eol encoding across different operating
systems.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
SPI Engine is a highly flexible and powerful SPI controller framework. It
consist out of multiple sub-modules which communicate over well defined
interfaces. This allows a high degree of flexibility and re-usability while
at the same time staying highly customizable and easily extensible.
Currently included are four components:
* SPI Engine execution module: The excution module is responsible for
handling the low-level physical interface SPI logic.
* SPI Engine AXI interface module: The AXI interface module allows
memory mapped acccess to a SPI bus control stream and can be used to
implement a software driver that controls the SPI bus.
* SPI Engine offload module: The offload module allows to store a
predefined SPI Engine command and data stream which will be send out
when a external trigger signal is asserted.
* SPI Engine interconnect module: The interconnect module allows to
combine multiple control streams into a single stream giving multiple
control modules access to a execution module.
For more information see: http://wiki.analog.com/resources/fpga/peripherals/spi_engine
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Lars-Peter Clausen
Istvan Csomortani
AndreiGrozav
Adrian Costina
Rejeesh Kutty