So that in one read access, the software can read both the status and
the value and can decide if the value is correct.  This avoids race
issues.

Simplify the code and avoid possible glitches.

Olof Kindgren authored 4 years ago and Tristan Gingold committed 4 years ago

The goal is to make sure that files in the common directory don't
depend on things defined elsewhere. With these changes, the only
remaining issue is gc_delay_line that uses generic_dpram from
genrams

Signed-off-by: Olof Kindgren <olof.kindgren@gmail.com>

Marcus Comstedt authored 4 years ago and Tristan Gingold committed 4 years ago

The response should not be EXOKAY unless an atomic access is requested
by the master using the LOCK signals.  This bridge does not even
support atomic accesses (it's an AXI4-Lite slave and does not have the
LOCK signals) so it's required to respond OKAY even if the master
does attempt an atomic access (this is how the master knows that the
slave does not support atomic accesses).  The AXI4-Lite specification
clearly states that the EXOKAY response is not supported in AXI4-Lite.

Marcus Comstedt authored 4 years ago and Tristan Gingold committed 4 years ago

The BVALID signal must be asserted once the write operation is
completed.  The master is not required to assert BREADY before this
happens.  The old code happened to work if the master tied BREADY
high, which is allowed but not required.

Tomasz Wlostowski authored 4 years ago and Tristan Gingold committed 4 years ago

Conflicts:
	modules/wishbone/wb_fine_pulse_gen/xwb_fine_pulse_gen.vhd

Tomasz Wlostowski authored 4 years ago and Tristan Gingold committed 4 years ago

wb_fine_pulse_gen: implement separate serdes/PLL reset and lock indicator (required to maintain correct phase of the output pulses)

Tomasz Wlostowski authored 4 years ago and Tristan Gingold committed 4 years ago

gc_simple_spi_master: keep MOSI at 0 when inactive so that multi-master SPI signals can be just ORed together

Previously, the full flag was asserted at g_size-1 when using g_show_ahead.
The new implementation solves this. However, for backward compatibility,
the default is to still use the previous behaviour. Set g_show_ahead_legacy_mode
to false to switch to the new one.

As a generic module to update xc7 firmware.

The only reason for this is to improve readability and reduce the usage of gc_posedge/gc_negedge, in
case we want to deprecate them in the near future.

Signed-off-by: Dimitris Lampridis <dimitris.lampridis@cern.ch>

Signed-off-by: Dimitris Lampridis <dimitris.lampridis@cern.ch>

The main reason for doing this is so that all our sync modules are based directly on
gc_sync (instead of using it indirectly through gc_sync_ffs).

Another benefit of this is that the feedback loop of the pulse synchroniser will now be two clock
cycles shorter (one input clock cycle + one output clock cycle), since gc_sync_ffs is using one
more flip-flop compared to gc_sync.

This will also reduce the number of warnings in various synthesis and simulation tools, since
gc_pulse_syncrhonizer is also used by the gc_sync_word modules, as well as the async dual clock
FIFOs.

Signed-off-by: Dimitris Lampridis <dimitris.lampridis@cern.ch>

This was recently introduced by T. Gingold and we both agreed that it is not really adding much
value, as it can be easily replaced by the more versatile combination ofgc_sync + gc_edge_detect.

Signed-off-by: Dimitris Lampridis <dimitris.lampridis@cern.ch>

This is necessary in order to properly "emulate" the previous implementation
of the gc_sync_ffs module.

Furthermore, a "new" module has been introduced, the gc_edge_detect, which
combines positive and negative pulse edge detection. gc_negedge and gc_posedge
have been rewritten to use internally the new gc_edge_detect.

Signed-off-by: Dimitris Lampridis <dimitris.lampridis@cern.ch>

This is to avoid any confusion caused by g_SYNC_EDGE and g_EDGE
generics used in gc_sync, gc_sync_ffs and gc_sync_edge modules.

Also use capitals for generics as defined by our coding style.

Signed-off-by: Dimitris Lampridis <dimitris.lampridis@cern.ch>