White Rabbit core collection issueshttps://ohwr.org/project/wr-cores/issues2023-05-26T07:03:50Zhttps://ohwr.org/project/wr-cores/issues/97Expose `g_interface_mode` on `xwrc_board_vfchd`2023-05-26T07:03:50ZTom LevensExpose `g_interface_mode` on `xwrc_board_vfchd`Can you please expose the generic `g_interface_mode` of `xwrc_board_common` on the top level of `xwrc_board_vfchd`?https://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/95Fix description of WR Streamers registers to indicate that latency is always ...2022-05-12T11:50:58ZMaciej LipinskiFix description of WR Streamers registers to indicate that latency is always provided in 8ns cyclesThis is not stated, but latency (max/min/acc) is always expressed in the stats regs in cycles of 8ns:
See pulse_stamper.vhd used in rx_streamer:
https://ohwr.org/project/wr-cores/blob/proposed_master/modules/timing/pulse_stamper.vhd#L178
On the other hand for the config of fixed_latency the document says that 16ns is assumed:
https://gitlab.cern.ch/BTrain-TEAM/Btrain-over-WhiteRabbit/-/issues/21
while:
https://ohwr.org/project/wr-cores/blob/proposed_master/modules/wr_streamers/fixed_latency_ts_match.vhd#L152
and in the end it seems that it depends on the system clock...https://ohwr.org/project/wr-cores/issues/96
wrpc-v5.0https://ohwr.org/project/wr-cores/issues/94Applying areset_n_i in board support package causes LM32 to hang2022-03-28T07:53:29ZMaciej LipinskiApplying areset_n_i in board support package causes LM32 to hangWe have encountered operational problem in which
1. FEC is remotely reseted which causes toggling of VmeSysReset_iarn but not a reload of FPGA
2. VmeSysReset_iarn is connected to areset_n_i in the xwrc_board_vfchd
4. Toggling areset_n_i causes the LM32 to hang completely
It seems that an asynchronous reset should to cause the core to hang...wrpc-v5.0https://ohwr.org/project/wr-cores/issues/93WR Streamers: fixed latency2022-03-22T15:53:27ZMaciej LipinskiWR Streamers: fixed latencyFor CERN RF, fixed latency is used (the variant with the wr ref clk used for application):
- we measure max latency at 7.5us level
- the fixed-latency is set for 8us
- we can observer late frames cnt increase
The above seems to be a bug.
Moreover, the latency of nearly 8us over a single switch and 1m cables... it is too much. Looking at different systems in operation, this seems consistant (i.e. ~6-8us over 1 wr switch measured using WR Streamers). When another switch is added, the latency is at 11-12us level (increase of 4us). It is a bit too much to have the overhead of up to 4 us. It is possible that this can be introduced inside the streamers module itself... and could be optimized.https://ohwr.org/project/wr-cores/issues/92Add simple stats counters for endpoint events2021-04-09T07:08:02ZGrzegorz DanilukAdd simple stats counters for endpoint eventsEquivalent of pstats in the switch, but simpler.wrpc-v5.0https://ohwr.org/project/wr-cores/issues/91Replace LM32 with uRV (RISC-V)2021-02-02T14:36:29ZGrzegorz DanilukReplace LM32 with uRV (RISC-V)The binary is more compact, WRPC is the last design where we still use LM32, uRV has proven its reliable operation in other designs (e.g. [MockTurtle](https://ohwr.org/project/mock-turtle))wrpc-v5.0https://ohwr.org/project/wr-cores/issues/90Endpoint: incorrect error handling of rx error (causes WR switch's SW core to...2021-01-27T14:08:40ZMaciej LipinskiEndpoint: incorrect error handling of rx error (causes WR switch's SW core to hang)**Brief description:**
1. The problem was observed on WR Switch with GTP, yet it is likely to occur on other nodes
2. The problem concerns RX PCS/Path in the Endpoint
3. The usecase when it occurs:
- WR Node is connected to WR Switch
- WR Node transmits frames
- WR Node enters reset (e.g. gateware is reloaded) while it transmits Ethernet Frame
- WR Switch PCS/RX Path starts reception of this Ethernet Frame and outputting it on wrf_source outputs, yet it never finishes cycle (in v5.0.1 of WR switch and respective version of Endpoint/wr-cores vesion) or finishes the cycle (v6.0 of WR switch and the respective Endpoint/wr-cores version) but the information about Rx error is not propagated.
**The reason for this is as follows:**
- The rdy_i input from PHY is used to reset the PCS/RX path of Endpoint.
- The err_i input from PHY (indicating incorrect signal) can come before or after rdy_i goes low (so PCS/RX path are resetted). The PCS/RX path of the Endpoint is a pipe with few stages. The reset triggerd by rdy_i prevents the information about err_i to be propagated. In v5.0.1 it also prevented the cycle output signal to go low, for v6.0 of the switch this was fixed and the synchronizer of rdy_i signal to sys_clk domain added delay of reset... still, often the err_i signal does not propagate outside Endpoint (e.g. to SWcore in the WRS) causing problems.
In the switch, this results in the SWcore of the switch to hang on the input and or output port (where the corrupted frame is to be propagated). It was also observed that the error propagates through the next layer(s) of switch(es) and likely cause problem in the receiving WR node (under investigation).
Note that the problem depends on PHY (i.e. the time relation between asserting err_i and deserting rdy_i). For example the bug occurs in the "standard Virtex6 WR GTP" and it does not occur in the "low phase drift Virtex6 GTP"wrpc-v5.0Maciej LipinskiMaciej Lipinskihttps://ohwr.org/project/wr-cores/issues/89wr_si57x_interface: seems SI_START2 state is never reached2020-12-09T01:40:14ZLucas Maziero Russowr_si57x_interface: seems SI_START2 state is never reached`SI_START2` state seems to be never reached by the current FSM here: https://ohwr.org/project/wr-cores/blob/proposed_master/modules/wr_si57x_interface/wr_si57x_interface.vhd#L326
Maybe line 324 (https://ohwr.org/project/wr-cores/blob/proposed_master/modules/wr_si57x_interface/wr_si57x_interface.vhd#L324) should have been:
`f_i2c_iterate(i2c_tick, seq_count, x"00", STOP, scl_out_fsm, sda_out_fsm, state, SI_START2);`
instead of:
`f_i2c_iterate(i2c_tick, seq_count, x"00", STOP, scl_out_fsm, sda_out_fsm, state, IDLE);`
Thanks!https://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/86Inconsistency in servo state enumeration2020-07-06T15:03:56ZMaciej LipinskiInconsistency in servo state enumerationConcerns wr-cores and ppsi repositories. Issue reported by David Emrich:
For starters, in ppsi/include/hw-specific/wrh.h we can see:
```
/* Servo state */
typedef enum {
WRH_UNINITIALIZED = 0,
WRH_SYNC_TAI,
WRH_SYNC_NSEC,
WRH_SYNC_PHASE,
WRH_TRACK_PHASE,
WRH_WAIT_OFFSET_STABLE,
}wrh_servo_state_t;
```
While, in ppsi/proto-ext-common/wrh-servo.c, the states are described in
the following order:
```
static const char *wrh_servo_state_name[] = {
[WRH_UNINITIALIZED] = "Uninitialized",
[WRH_SYNC_NSEC] = "SYNC_NSEC",
[WRH_SYNC_TAI] = "SYNC_SEC",
[WRH_SYNC_PHASE] = "SYNC_PHASE",
[WRH_TRACK_PHASE] = "TRACK_PHASE",
[WRH_WAIT_OFFSET_STABLE] = "WAIT_OFFSET_STABLE",
};
```
You can see that the ordering between the NSEC and TAI terms is reversed
between the two. So, when executed, the array contents actually look
like...
```
static const char *wrh_servo_state_name[] = {
[0] = "Uninitialized",
[2] = "SYNC_NSEC",
[1] = "SYNC_SEC",
[3] = "SYNC_PHASE",
[4] = "TRACK_PHASE",
[5] = "WAIT_OFFSET_STABLE",
};
```
On the face of it I don't think this is crucial as long as all users of
that array ONLY reference the first argument as the numeric state
variable and never reference the index/position within the array itself.
However for consistency and clarity, I would suggest that the ordering
inside ppsi/proto-ext-common/wrh-servo.c be changed to match the
enumerated type in the wrh.h header file.
Moving on, once again, inside
wr-cores/modules/wrc_core/wrc_syscon_wb.wb, we see
```
reg {
name = "WRPC Diag: servo status";
prefix = "WDIAG_SSTAT";
field {
name = "WR valid";
prefix = "wr_mode";
description = "0: not valid\1:valid";
type = BIT;
access_bus = READ_WRITE;
access_dev = READ_ONLY;
};
field {
name = "Servo State";
prefix = "servostate";
description = "0: Uninitialized\
1: SYNC_NSEC\
2: SYNC_TAI\
3: SYNC_PHASE\
4: TRACK_PHASE\
5: WAIT_OFFSET_STABLE";
type = SLV;
size = 4;
align = 8;
access_bus = READ_WRITE;
access_dev = READ_ONLY;
};
```
And inside wr-cores/modules/wrc_core/wrc_diags_wb.wb we see:
```
reg {
name = "WRPC Diag: servo status";
prefix = "WDIAG_SSTAT";
field {
name = "WR valid";
prefix = "wr_mode";
description = "0: not valid\
1:valid";
type = BIT;
access_bus = READ_ONLY;
access_dev = WRITE_ONLY;
};
field {
name = "Servo State";
prefix = "servostate";
description = "0: Uninitialized\
1: SYNC_NSEC\
2: SYNC_TAI\
3: SYNC_PHASE\
4: TRACK_PHASE\
5: WAIT_OFFSET_STABLE";
type = SLV;
size = 4;
align = 8;
access_bus = READ_ONLY;
access_dev = WRITE_ONLY;
};
};
```
Barring minor formatting, these two extracts from the .wb files are the
same thing but they are BOTH different from the order enumerated in the
original wrh.h header.
Does this mean that the state numbers that are running inside the WR
hardware are different from the numbers assigned in the MIB databases?
(And wherever else these .wb files are used?) Is that important or does
"everyone" reference the name only and the numbers are ignored?
What about if there is a similar servo state variable within any FPGA code?
I bring this to your awareness in case it might be the heart of some
as-yet un-diagnosed issue that only appears when any given White Rabbit
system is "out of lock", either during initialisation or if something
fails during operation.https://ohwr.org/project/wr-cores/issues/85wr streamers: tx FIFO interace - tx_dreq_o is synchronous to clk_ref only2020-05-12T09:39:52ZMaciej Lipinskiwr streamers: tx FIFO interace - tx_dreq_o is synchronous to clk_ref onlyIt should depend on the configuration, it should be synchronous to clk_sys_i by default, see:
xtx_streamers.vhd
U_SyncReset_to_RefClk : gc_sync_ffs
port map (
clk_i => clk_ref_i,
rst_n_i => '1',
data_i => rst_int_n,
synced_o => rst_n_ref);
U_SyncLinkOK_to_RefClk : gc_sync_ffs
port map (
clk_i => clk_ref_i,
rst_n_i => rst_n_ref,
data_i => link_ok_i,
synced_o => link_ok_ref);
U_SyncLinkDelayExpired_to_RefClk : gc_sync_ffs
port map (
clk_i => clk_ref_i,
rst_n_i => rst_n_ref,
data_i => link_ok_delay_expired,
synced_o => link_ok_delay_expired_ref);
p_tx_dreq_gen : process(link_ok_delay_expired_ref, tx_almost_full, link_ok_ref)
begin
if link_ok_delay_expired_ref = '0' then
tx_dreq_o <= '0';
else
tx_dreq_o <= not tx_almost_full and link_ok_ref;
end if;
end process;https://ohwr.org/project/wr-cores/issues/84wr-streamers: stats2020-03-20T18:22:46ZMaciej Lipinskiwr-streamers: statsThere is a use-case in which, after reset of stats, the number of lost frames is reported. This happens when:
- we unplug the fiber
- we reset the stats
- we plug the fiber.
Possibly, another combination of these actions will result in the same.
To be investigated whether link-up should reset lost frames count or stats in generalMaciej LipinskiMaciej Lipinskihttps://ohwr.org/project/wr-cores/issues/83Wiki link to wr-node-core is broken2020-01-21T14:12:36ZOlof KindgrenWiki link to wr-node-core is brokenThe wiki page at https://www.ohwr.org/project/wr-cores/wikis/wrpc-core links to https://www.ohwr.org/project/wr-node-core/wiki which appears to be deadhttps://ohwr.org/project/wr-cores/issues/82Possible problem with Endpoint when replugging fiber with high WR-Btrain traffic2019-06-04T14:49:21ZMaciej LipinskiPossible problem with Endpoint when replugging fiber with high WR-Btrain trafficThis problem was observed on WR NODE and SWITCH as described below:
1. Two WR Nodes (as slaves) connected to one WR Switch (master) over cross-point switch (from BTrain guys), BTrain traffic sent by both WR Nodes at 500kHz. When switching between masters, one of the WR Node slaves was left hanging in "listening" state. the counter of received frames was being increased in GUI, yet it seems that no PTP Frames reached the PTP daemon. Restarting PTP did not help, re-plugging switching/replugging (link down/up) helped. It happens +/- 1 in 10 times
2. The same setup as above, the link of the same WR Node slave is unplugged and plugged. If this is done with minimal duration, i.e. the link is barely removed and than put into place again (on the Master site, I think), it happened once that the WR Node did not detect link to go UP, it stayed down.
3. Two WR Switches are connected over cross-point switch (and directly), i.e.
a) wri2 (master) of WRS1 is connected to wri1 (slave) of WRS2 (over the cross-point switch and directly)
b) wri11 (master) of WRS1 is connected to wri11 (passive) of WRS2
BTrain traffic (500kHz) is sent in both directions over both links (using VLANs). The link is re-plugged from wri2 of WRS1. This is done in the same manner as in 2). +/- 1 out of 5, the slave link does not detect link up and stays down while the master port is up and traffic is transmitted. This happens in both cases, over the cross-point switch and with direct connection.
NOTE: we did not reproduce problem 1) with setup 3), i.e. when switching between ports using the cross-point switch
It is likely a problem in Endpoint (HDL)Grzegorz 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/80Transfer data through Ethernet in WRPC2019-02-25T21:07:26ZGhost UserTransfer data through Ethernet in WRPCWe are making WRPC work on our hardware platform, which is based on Kintex-7.
Thank you for your help, and we have made it work.
Now, we want to transfer data through the Ethernet(use the SFP module) .
I got some information from the user manual:
1. "If built with CONFIG_IP=y, wrpc-sw implements the following udp-based network services"---from Netwrok Service;
2. "all the traffic from VIDs 10, 11, 20 is forwarded and available on the WR PTP Core external fabric interface."--from VLAN Support;
So I do an "echo test" as follow(the figure of top design is attached):
1. In FPGA design(wr-core and wrpc-sw):
1.1 WRF Source is connected to WRF Sink directly;
1.2 g_fabric_iface => PLAIN;
1.3 VLAN is on;
1.4 configure the IP manually;
2. In PC:
2.1 install VLAN module to make PC send the VLAN frame, and configure the VID to 10, which has been confirmed by wireshark;
2.2 add the IP and MAC address to the ARP list;
2.2 send test data through UDP(I'm not sure what the port is, and I set it to 123);
2.3 monitor the data flow by wireshark(Enable promiscuous mode);
I think wireshark will get some information from the VLAN interface, if everything is right.
However, there is nothing from the VLAN interface.
How can I finish the "echo test" through UDP?
Is my understanding incorrect?
Thank you!![Screenshot_from_2019-02-24_18-39-52](/uploads/1bdeb99ee2b5da35a71d7de7d123e10d/Screenshot_from_2019-02-24_18-39-52.png)https://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 Daniluk