Commit Graph

14 Commits (edbd9f7b8f5fd1f2da3a25170f31a14aa4b5acae)

Author SHA1 Message Date
Istvan Csomortani 32eeedb660 makefile: Update makefiles 2020-05-07 08:41:49 +01:00
Istvan Csomortani aa5fdf903e Makefile: Update makefiles 2019-08-26 16:58:01 +03:00
Istvan Csomortani 42b14f341a axi_spi_engine: Generate false paths only on ASYNC_CLK mode 2019-06-28 11:18:29 +03:00
Istvan Csomortani 40fbb37d6f spi_engine: Add additional synchronization FIFO's to axi_spi_engine
Add additional synchronization FIFOs to several interfaces of the
axi_spi_engine module, to prevent metastability and timing issues in
case when the system clock and the SPI clock are asynchronous.
2019-06-28 11:18:29 +03:00
Lars-Peter Clausen 2b914d33c1 Move Altera IP core dependency tracking to library Makefiles
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>
2018-04-11 15:09:54 +03:00
Lars-Peter Clausen 35a39ba2e6 Regenerate library Makefiles using the new shared Makefile include
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>
2018-04-11 15:09:54 +03:00
Istvan Csomortani a740b6012f Make: Use $(MAKE) for recursive make commands
This commit should resolve the issue #64.

Recursive make commands should always use the variable MAKE, not the explicit
command name ‘make’.
2018-03-07 07:40:19 +00:00
Lars-Peter Clausen 01aea161fa Create CDC helper library
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>
2017-05-23 11:16:07 +02:00
Adrian Costina 8ebc8fe4e2 updated makefiles 2016-12-09 23:06:41 +02:00
Adrian Costina d60bce654c Makefiles: Updated Makefiles so they run correctly with gnuwin32 tools 2016-08-05 15:16:04 +03:00
Rejeesh Kutty e42b4ea378 hdlmake- updates 2016-08-04 13:28:25 -04:00
Istvan Csomortani 74c220d79e make: Update Make files 2016-07-20 14:17:04 +03:00
Rejeesh Kutty c293c04634 hdl make updates 2016-06-01 13:53:09 -04:00
Lars-Peter Clausen e6b58e8a20 Add SPI Engine framework
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>
2015-05-21 17:21:35 +02:00