- 06 Nov, 2014 6 commits
-
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
This function now returns more Linux-oriented error codes (0 is success, 2 is failure)
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
-
- 05 Nov, 2014 3 commits
-
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
The following changes have been made to improve test script outputs: - add numbers of ICs to test - change CONV-TTL-BLO for CONV-TTL-RS485 where appropriate (the former was there because the scripts were imported from the CONV-TTL-BLO PTS) - TTL pulse test: clearer output, indicating the channels and the ICs to check in case of error
-
Theodor-Adrian Stana authored
-
- 04 Nov, 2014 5 commits
-
-
Theodor-Adrian Stana authored
An addition has been made in the top-level file to not run the tests if the output of xc3sprog is not the expected one. This prevents blindly running the tests on no gateware downloaded to the FPGA, and thus prevents wasted time.
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
The issue was an error in the schematics, where the names of the SDA line and the RATE_SELECT lines were swapped. This led to the definitions of the pins in the UCF file to be wrong and the SFP test not working. With the proper pin names in the UCF file, the SFP test now works.
-
- 03 Nov, 2014 6 commits
-
-
Theodor-Adrian Stana authored
As mentioned in the previous commit, the SFP EEPROM test is not yet working. Still under investigation as to why.
-
Theodor-Adrian Stana authored
The EEPROM test doesn't work yet, but that may be related to the wrong-ish SFP connector placed on the board. Lengthy clarification: the PTS for the CONV-TTL-RS485 boards is inspired from the PTS of CONV-TTL-BLO, where an SFP+ connector is used. Since the CONV-TTL-RS485 uses just an SFP connector (not the SFP+), there might be something wrong when reading the I2C interface. Reading the manuals yielded no relevant reasons why this would occur, but I'm still investigating. Either way, the link up test works, just the EEPROM test needs to be clarified why it doesn't work. And the SFP changed for an SFP+.
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
The issue was an errant reset signal presented to the clock counters, which had an active-high reset signal instead of the normally-used active-low reset. This has been fixed and the test logic now works as expected.
-
- 31 Oct, 2014 10 commits
-
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
-
- 30 Oct, 2014 4 commits
-
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
-
Theodor-Adrian Stana authored
-
- 28 Oct, 2014 1 commit
-
-
Theodor-Adrian Stana authored
-