White Rabbit core collection issueshttps://ohwr.org/project/wr-cores/issues2022-05-16T08:07:25Zhttps://ohwr.org/project/wr-cores/issues/96Possible bug in streamers2022-05-16T08:07:25ZMaciej LipinskiPossible bug in streamersFrom this code, it seems that the fixed latency value should be always configured in units of 8ns
https://ohwr.org/project/wr-cores/blob/proposed_master/modules/wr_streamers/fixed_latency_ts_match.vhd#L152
while it seems that it might depend on the system clock (16ns for 62.5MHz, 8ns for 125MHz). This is what we observed with John in the wr2rf board. TO BE INVESTIGATEDwrpc-v5.0https://ohwr.org/project/wr-cores/issues/88add WB register for setting MAC address from the driver2020-10-02T07:59:44ZGrzegorz Danilukadd WB register for setting MAC address from the driverAdd it to the Syscon WB peripheral. Then the scanning order should be:
1. WB register
2. SDBFS file in eeprom/flash
3. Fallback to default MAC.wrpc-v5.0Grzegorz DanilukGrzegorz Danilukhttps://ohwr.org/project/wr-cores/issues/87reduce address space exposed over Wishbone2020-10-02T07:06:00ZGrzegorz Danilukreduce address space exposed over WishboneCurrently WR PTP Core exposes directly its full internal address space over external Wishbone interface. This requires a huge memory window being allocated from the designs that instantiate it. In vast majority of cases these applications using WR PTP Core are interested only in reading diagnostics registers.
TODO: add Wishbone address translation module that would "hide" the whole LM32 memory space from external WB interface. Provide registers in Syscon WB peripheral for accessing LM32 memory indirectly so that updating LM32 binary is still possible over Wishbone.wrpc-v5.0Grzegorz DanilukGrzegorz Danilukhttps://ohwr.org/project/wr-cores/issues/81select/ready signals for communication with SFP/1Wire2019-04-03T09:24:46ZMaciej Lipinskiselect/ready signals for communication with SFP/1WireIn the VFC-HD board, the access to SFP eeprom, as well 1-wire is multiplexed with application-specific user-defined code. Currently, we have a hack in place that reads SFP data, stores it in register and then fakes I2C slave that is read by WRPC.
The proposal is to have two signals: "select" and "ready". Before reading SFP (and potentially other peripherals), WRPC SW would first request access and then check whether it is granted. In most boards, "select" would be looped back to "ready". In VFC-HD (and any other where needed), the signals would be actually used.
This requires small changes in HDL and SWhttps://ohwr.org/project/wr-cores/issues/1re-measure/calculate alpha parameter2019-02-12T09:43:49ZMaciej Lipinskire-measure/calculate alpha parametersee:
https://www.ohwr.org/project/wr-switch-sw/work_packages/1860/activityhttps://ohwr.org/project/wr-cores/issues/4Use gc_serial_dac from general-cores instead of spec_serial_dac2019-11-01T15:00:38ZGrzegorz DanilukUse gc_serial_dac from general-cores instead of spec_serial_dacThe modules are almost identical, this code duplication should be
removed.Grzegorz DanilukGrzegorz Danilukhttps://ohwr.org/project/wr-cores/issues/5Add support for CuteWR-DP board.2019-11-01T15:00:38ZGrzegorz DanilukAdd support for CuteWR-DP board.Review, fix & merge board support module for CuteWR-DP by Tsinghua
University.Grzegorz DanilukGrzegorz Danilukhttps://ohwr.org/project/wr-cores/issues/7UTC leap second registers2019-02-12T09:43:54ZGrzegorz DanilukUTC leap second registersGSI timing system uses UTC time, therefore they request adding registers
to the WR PTP Core where the UTC offset and upcoming leap second flags
could be read by the HDL modules.
As soon as leap second support is merged into PPSi master, we could
expand pps\_gen registers to export the current UTC offset and 2 flags
(leap59 and leap61).Grzegorz DanilukGrzegorz Danilukhttps://ohwr.org/project/wr-cores/issues/8Add a table of supported extensions of basic WRPC MIB2020-05-12T14:28:50ZMaciej LipinskiAdd a table of supported extensions of basic WRPC MIBIn the basic WRPC MIB add a table with implemented/supported
application-specific MIB extensions
<table>
<tbody>
<tr class="odd">
<td>diag ID</td>
<td>diag Ver</td>
<td>name</td>
<td>OID pointer</td>
</tr>
</tbody>
</table>Adam WujekAdam Wujekhttps://ohwr.org/project/wr-cores/issues/16Extension of WR Streamers testbenches to test 0xCAFE2019-02-12T09:43:58ZMaciej LipinskiExtension of WR Streamers testbenches to test 0xCAFETransmission of the sequence 0xCAFE in data should be tested, i.e. all
different combinations that might cause problems, such as:
\- data with only 0xcafe
\- data with 0xcafe at the end
\- data with 0xcafe and 0x0000 (this is how the escape code is
expanded)
\- etcMaciej LipinskiMaciej Lipinskihttps://ohwr.org/project/wr-cores/issues/36WR streamers: Maximum number of words per frame2019-02-12T09:44:09ZDenia Bouhired-FerragWR streamers: Maximum number of words per frameThe tx streamer has a generic `g_max_word_per_frame` that is described
as (as the name states) the maximum number of words allowed in a frame.
It also consequently means it is the maximum number of words allowed per
block, since a block cannot be split across multiple frames.
However, there is no mechanism to enforce this maximum value, and since
block splitting is not supported, the tx\_streamer will allow blocks of
any length to be input for transmission until a block finishes ( by
asserting a `tx_last_p1_i` pulse), at which point this maximum value is
checked. If `g_max_word_per_frame` has been exceeded, the frame is sent
out.
The generic is more acting as a means of limiting the length of frames
(by finishing one ethernet frame and sending it out) when:
- The user does not "manually" decide to flush the transmitter
(through `tx_flush_p1_i`) or
- No timeout period has been observed or
- The user does not respect the maximum number of words per frame (but
still asserts a `tx_last_p1_i` to signal the end of one block -What
happens though if words keep coming without ever signalling the end
of one blocck and reaching the Ethernet frame payload limit?)
This means that the description (and name) of the generic are not
appropriately describing its function. Alternatively the specification
for this function needs to be clarified and a better implementation
proposed in order to enforce (if need be) an upper limit on the number
of words per frame.