- 19 Jun, 2017 40 commits
-
-
Denia Bouhired-Ferrag authored
-
Denia Bouhired-Ferrag authored
-
Denia Bouhired-Ferrag authored
Final version of the testbench.Fully working with 6 different tests: flush, timeout, tx_thr, tx_max words, fxd latency, drop frames.
-
Denia Bouhired-Ferrag authored
-
Denia Bouhired-Ferrag authored
-
Denia Bouhired-Ferrag authored
-
Denia Bouhired-Ferrag authored
Changed data type block so it no longer has wrd_cnt, first and last_wrd fields. Not really required anymore
-
Denia Bouhired-Ferrag authored
-
Denia Bouhired-Ferrag authored
-
Denia Bouhired-Ferrag authored
-
Denia Bouhired-Ferrag authored
-
Denia Bouhired-Ferrag authored
Working testbench. Runs 5 tests. Bug: does not cope with multiple block frames. only single block frames.
-
Denia Bouhired-Ferrag authored
-
Maciej Lipinski authored
-
Maciej Lipinski authored
there were some unfortunate sequences of characters that made to fail the compliation of the auto-generated altex documention. These unfortunate sequences were removed
-
Maciej Lipinski authored
-
Denia Bouhired-Ferrag authored
Work in progress. Rx tb will soon be deleted. Tx tb will be main one. Tx features testing working. Rx features must be fixed and also features relating to link quality (delay, drop frames, etx)
-
Denia Bouhired-Ferrag authored
-
Denia Bouhired-Ferrag authored
-
Denia Bouhired-Ferrag authored
-
Maciej Lipinski authored
added setting of new generics, in particular important is the simulation generic. added wait at the beginning of simulation, otherwise the drivers attempts to write data to tx_streamer when the reset is still LOW (there is 100us wait before reset is asserted HIGH).
-
Maciej Lipinski authored
-
Maciej Lipinski authored
when streamers are used in a simulation of top entity, the startup timer is needed, thought it should be appropriate for the simulation time. when streamers are simulated alone, the startup timer is not needed. the added generic allows to set the timer (i.e. override the default value to zero)
-
Denia Bouhired-Ferrag authored
-
Denia Bouhired-Ferrag authored
-
Denia Bouhired-Ferrag authored
small modifications modified signals names in xwrc_board_spec enity and package to much new WRPC release
-
Dimitris Lampridis authored
-
Maciej Lipinski authored
-
Maciej Lipinski authored
32-bit counters would overflow after few hours of btrain traffic. So, I increased counters to have max 64 bits and configured them to have 50 bits, which should be sufficient for 50 years of traffic with 500kHz. Conflicts: modules/wr_streamers/xrtx_streamers_stats.vhd
-
Dimitris Lampridis authored
-
Maciej Lipinski authored
-
Maciej Lipinski authored
-
Maciej Lipinski authored
I removed BTrain-specific debugging from wr_streamers. in that commit I only updated *.wb file. now comes the update of wb-generated files
-
Maciej Lipinski authored
this is an hdl part of new (additional) diagnostics for WR PTP Core. It allows to access diagnostics values through WB registers (e.g. PCI bus). This is useful for integration of WR with CERN cotrols infrastructure, such as FESA. It allows the host machine (of SPEC/SVEC/etc) to easily access information about the health of WR PTP Core.
-
Maciej Lipinski authored
When frames were sent to close to each other (high frequency), the timestamp of incoming frame would reset the delay counter of the previously received frame. This could potentially cause infinite fixed delay... Now, in such case, the counter is not reseted and so the following (too closely) frame will be exposed to the user immediatelly.
-
Maciej Lipinski authored
Such glitch happened after the autonegotation FSM was in pseudo AN_ENABLED state caused by synced=LOW (in this state, link_ok is HIGH). When synced goes HIGH, the FSM enters "proper" AN_ENABLED state, it drives link_ok LOW.s All in all, this glitch is avoided then we use delayed synced_d1 to produce the final link_ok_o. I did it here to avoid any changes to autonegotiation state machine.
-
Maciej Lipinski authored
sending streamer frames when link is down causes weird behavior: - the frames are counted as sent, while they are not - some frames are dropped, depending on PHY implementation - at startup, the link is reseted by software, so link is up for some time, then it goes down, than up again... mess two additions: - the dreq_o signal is gated with link_ok_i, so that frames cannot be sent when link is down - startup counter which delays the start of sending frames
-
Maciej Lipinski authored
- removed unnecessary reference to spec_top in one testbench that did not use top - removed obsolte cfg input signals - use default
-
Maciej Lipinski authored
-
Maciej Lipinski authored
the name of the top entity in the wr_streamers folder was missleading (xwr_transmission). It was recommended to rename, which I did. Additionally, names of two modules in wr_streamers start with gc_ which could indicate they are general-cores. This is not the case, moreover the entity names did not have gc_. I removed the gc_
-