Platform-independent core collection issueshttps://ohwr.org/project/general-cores/issues2024-01-30T14:00:23Zhttps://ohwr.org/project/general-cores/issues/54Support Verilog output with gen_sourceid tool2024-01-30T14:00:23ZDimitris LampridisSupport Verilog output with gen_sourceid toolDimitris LampridisDimitris Lampridishttps://ohwr.org/project/general-cores/issues/53Linux driver for wb simple uart2024-01-24T13:17:26ZPiotr KlasaLinux driver for wb simple uartadd a driver for "wb simple uart", which will support physical uart.https://ohwr.org/project/general-cores/issues/51inferred_async_fifo_dual_reset : spurious pulse on almost_full_int after reset2024-01-22T12:56:55ZAlexis Marquetinferred_async_fifo_dual_reset : spurious pulse on almost_full_int after resetmy instanciation if anybody wants to reproduce:
```vhdl
fifo : ENTITY work.generic_async_fifo_dual_rst
GENERIC MAP(
g_data_width => 74,
g_size => g_size,
g_show_ahead => TRUE,
g_with_rd_empty => true,
g_with_rd_full => false,
g_with_rd_almost_empty => false,
g_with_rd_almost_full => true,
g_with_rd_count => true,
g_with_wr_empty => false,
g_with_wr_full => true,
g_with_wr_almost_empty => false,
g_with_wr_almost_full => false,
g_with_wr_count => false,
g_almost_empty_threshold => 0,
g_almost_full_threshold => g_size - 2,
g_memory_implementation_hint => "auto"
)
```
almost_full_int (and so wr_almost_full_o & rd_almost_full_o) will pulse out of reset because wr_count reg is undef for the first clock cycle out of reset in sim:
![Screenshot_from_2024-01-22_13-48-04](/uploads/54922fe4970da9178ff857ab0d92ac81/Screenshot_from_2024-01-22_13-48-04.png)
and adding a reset statement for wr_count fixes it when added here:
https://ohwr.org/project/general-cores/blob/master/modules/genrams/common/inferred_async_fifo_dual_rst.vhd#L284
![Screenshot_from_2024-01-22_13-49-38](/uploads/1201bed7fb286b200f77b13a832ff05e/Screenshot_from_2024-01-22_13-49-38.png)
vivado 2022.2.2, xsim
will do a PR laterhttps://ohwr.org/project/general-cores/issues/50add rx/tx interrupt enable in wb_uart2024-01-15T15:33:02ZKonstantinos Blantosadd rx/tx interrupt enable in wb_uartThe purpose of this issue is to add RX and TX interrupt enable registers, a modification which will be used in ProFIPKonstantinos BlantosKonstantinos Blantoshttps://ohwr.org/project/general-cores/issues/49add a fifo with mixed width2023-12-21T12:49:47ZTristan Gingoldadd a fifo with mixed widthTristan GingoldTristan Gingoldhttps://ohwr.org/project/general-cores/issues/47revert version of wb_uart2023-12-15T10:29:46ZKonstantinos Blantosrevert version of wb_uartThe purpose of this issue is to revert to a previous working version of wb_uart which is used for ProFip.
In parallel, debug the newer version to see why it is not working for Profip.Konstantinos BlantosKonstantinos Blantoshttps://ohwr.org/project/general-cores/issues/46demo_vunit_ghdl_testbench2023-12-12T14:07:05ZKonstantinos Blantosdemo_vunit_ghdl_testbenchThe purpose of this issue is to demonstrate a simple demo of a testbench using VUnit with GHDL.Konstantinos BlantosKonstantinos Blantoshttps://ohwr.org/project/general-cores/issues/43generate_cdc_constraints.tcl creates faulty constraints with path segmentation2023-09-27T15:04:03ZAdrian Byszukgenerate_cdc_constraints.tcl creates faulty constraints with path segmentationIn some scenarios the `tools/generate_cdc_constraints.tcl` script creates constraints that will trigger critical implementation warnings in Vivado:
```
[Constraints 18-515] set_max_delay: Path segmentation by forcing 'some_starting_regs/O' to be timing startpoint. [/path/to/gencores_constraints.xdc:1]
Resolution: Use valid startpoint to avoid path segmentation such as the clock pin of a register.
```
This is a legitimate warning and such constraints will ignore the source clock skew and insertion delays, while still taking into account the destination clock skew.
![image](/uploads/70f142078ee951bdf0ce4896ceda8d40/image.png)
The proper startpoint is always a `C`/`CLK` clock input of a sequential element.
More info about the path segmentation can be found in Xilinx documentation, specifically UG903 "Vivado Design Suite User Guide: Using Constraints" -> Ch.5 Timing Exceptions -> Path Segmentation
It's true that generated constraints contain `-datapath_only` switch that should ignore src/dst clock skew, but it's not clear how path segmentation interacts with that switch. Moreover, having N critical warning after implementation is always bad and may obfuscate other issues for anyone analyzing their design.
CC: @andreda @twlostow @marquetaTomasz WlostowskiTomasz Wlostowskihttps://ohwr.org/project/general-cores/issues/32Consider to contribute to Linux kernel2022-08-18T13:58:55ZFederico VagaConsider to contribute to Linux kernelThe I2C and the SPI drivers are for opencores ip-cores. The I2C driver is already part of the kernel, but the SPI one is not. We should push our change to the I2C to the mainline, and try to push the full SPI driver as wellhttps://ohwr.org/project/general-cores/issues/28Genram g_show_ahead_legacy_mode does not work for virtex62020-11-03T12:51:02ZLucas Maziero RussoGenram g_show_ahead_legacy_mode does not work for virtex6It seems the new generic `g_show_ahead_legacy_mode` will not work for virtex6, as `modules/genrams/xilinx/virtex6/generic_sync_fifo.vhd` module does not include the `g_show_ahead_legacy_mode`, but the component declaration at `modules/genrams/genram_pkg.vhd` does.https://ohwr.org/project/general-cores/issues/27AXI4-lite to wishbone bride: wlast and rlast signals should be not present2020-10-16T09:14:59ZGregoire HagmannAXI4-lite to wishbone bride: wlast and rlast signals should be not presentThe AX4I-lite does not have the wlast and rlast signals (ug1037).
the records t_axi4_lite_slave_in_32 and t_axi4_lite_slave_out_32 have both rlast& wlast signals. They should be removed
the xwb_axi4lite_bridge:
wlast is ignored but still present in the interface.
rlast signal driven but could be ignored?
Cheby is generating ARPROT and AWPROT signal. Should they be included in the records?https://ohwr.org/project/general-cores/issues/26xwb_slave_adapter hangs on ACK asserted state in PIPELINE to CLASSIC mode2020-10-13T12:07:39ZPiotr Miedzikxwb_slave_adapter hangs on ACK asserted state in PIPELINE to CLASSIC modexwb_slave_adapter hangs on ACK asserted state in PIPELINE to CLASSIC mode
> PERMISSION 3.35
> Under certain circumstances SLAVE interfaces MAY be designed to hold [ACK_O] in the
> asserted state. This situation occurs on point-to-point interfaces where there is a single
> SLAVE on the interface, and that SLAVE always operates without wait states.https://ohwr.org/project/general-cores/issues/25t_wishbone_byte_select definition2020-09-02T23:16:32ZPiotr Miedzikt_wishbone_byte_select definitionshouldn't t_wishbone_byte_select be defined as
```vhdl
subtype t_wishbone_byte_select is
std_logic_vector((c_wishbone_data_width/8)-1 downto 0);
```
instead of
```vhdl
subtype t_wishbone_byte_select is
std_logic_vector((c_wishbone_address_width/8)-1 downto 0);
```
https://ohwr.org/project/general-cores/blob/master/modules/wishbone/wishbone_pkg.vhd#L41https://ohwr.org/project/general-cores/issues/21xwb_crossbar range verification2020-01-21T13:14:32ZMarek GumiĆskixwb_crossbar range verificationxwb_crossbar asserts when 1 or 2-bit address space is configured. It is due to the following if: https://ohwr.org/project/general-cores/blob/master/modules/wishbone/wb_crossbar/xwb_crossbar.vhd#L109
This assert makes sense if the bus uses byte granularity, but afaik WB supports word granularity as well (that I'm using).
Moreover setting c_wishbone_data_width to 8 will cause constant "align" to have a range (-1 downto 0)
https://ohwr.org/project/general-cores/blob/master/modules/wishbone/wb_crossbar/xwb_crossbar.vhd#L83https://ohwr.org/project/general-cores/issues/5wb_spi support for SDIO2019-08-06T09:12:35ZPiotr Miedzikwb_spi support for SDIOIt's not possible to implement abaco (4dsp) FMC116/FMC112 SPI
communication using wb\_spi because it does not support SDIO
signaling.
wb\_spi supports only MISO/MOSI signaling.Dimitris LampridisDimitris Lampridishttps://ohwr.org/project/general-cores/issues/6xwb_axi4lite_bridge transaction loss2019-08-26T21:09:46ZPiotr Miedzikxwb_axi4lite_bridge transaction lossxwb\_axi4lite\_bridge as a AXI slave need to act as an arbiter on each
channel.
A current design in proposed master may loss "some" transactions in case
of heavy/long transfers.
You may check our WishboneAXI bridge library:
https://github.com/qermit/WishboneAXI
**Axi4Lite to Wishbone**
core:
https://github.com/qermit/WishboneAXI/blob/master/cores/Wishbone2AXI/hdl/WishboneAXI_v0_1_S_AXI4_LITE.vhdTomasz WlostowskiTomasz Wlostowskihttps://ohwr.org/project/general-cores/issues/11xwb_crossbar: cannot place sdb at 0x000000002019-08-06T09:12:41ZPiotr Miedzikxwb_crossbar: cannot place sdb at 0x00000000xwb\_crossbar: cannot place sdb at 0x00000000 if using
f\_sdb\_auto\_layout/f\_sdb\_auto\_sdb and some slaves are smaller than
sdb rom itselfDimitris LampridisDimitris Lampridishttps://ohwr.org/project/general-cores/issues/12wb_spi: loosing first bit during first transfer2019-08-06T09:12:57ZPiotr Miedzikwb_spi: loosing first bit during first transferwb\_spi: loosing first bit during first transfer when tx\_negate=1 and
rx\_negate=0 (CPOL=0,CPHA=0)
Steps to reproduce bug:
write 0x00000004 to 0x00000014 (divider)
write 0x00000001 to 0x00000018 (slave select)
write 0x000000FF to 0x00000000 (data0)
write 0x00000508 to 0x00000010 (ctrl)
Wait for end of transfer
write 0x000000FF to 0x00000000 (data0)
write 0x00000508 to 0x00000010 (ctrl)
### Files
* [tx_neg_0xFF.PNG](/uploads/20069c4c3fc7618d317f8499249f6889/tx_neg_0xFF.PNG)
* [tx_neg_0xFF.PNG](/uploads/1add99f1b422bc31ada9fb9028751784/tx_neg_0xFF.PNG)
* [tb_wb_spi.vhd](/uploads/935b390b80c70867bc764d8ce5ed9e1e/tb_wb_spi.vhd)Dimitris LampridisDimitris Lampridis