Simple VME FMC Carrier SVEC issueshttps://ohwr.org/project/svec/issues2019-02-12T10:09:46Zhttps://ohwr.org/project/svec/issues/10V3 - M25P128-VME6GB last time buy 12-20172019-02-12T10:09:46ZErik van der BijV3 - M25P128-VME6GB last time buy 12-2017End Of Life and Last Time Buy date of December 2017 announced of 128
Mbit SPI flash for FPGA firmware storage (M25P128-VME6GB).
See attached PCN notice.
Thanks to Janz Technologies for informing us.
### Files
* [Arrow_Product_Change_Notification_1202469.pdf](/uploads/5cb4d0318d50aef060ba24865d305e6e/Arrow_Product_Change_Notification_1202469.pdf)Erik van der BijErik van der Bijhttps://ohwr.org/project/svec/issues/11V3 Bootloader - VMEbus reset locks up SVEC2019-02-12T10:09:47ZErik van der BijV3 Bootloader - VMEbus reset locks up SVEC(FW, 28/10/15):
After reboot of the VMEbus-CPU, which generates a VMEbus reset pulse
(length approx. 250 ms), the software is unable to access the SVEC
boards application FPGA or reconfigure it with a new bitstream file
using the system FPGA. This error condition has to be resolved by a
VMEbus power cycle.
The bootloader version 3 causes this problem. After downgrading the
bootloader to version 2 the software is able to access the SVEC boards
application FPGA after a reboot of the VMEbus-CPU (VMEbus reset). So it
seems that there is a bug in the bootloader version 3 that prevents the
VMEbus-CPU from accessing the application or system FPGA of the SVEC
board.Dimitris LampridisDimitris Lampridishttps://ohwr.org/project/svec/issues/18HDL: bootloader causing bus error2019-02-12T10:09:51ZTomasz WlostowskiHDL: bootloader causing bus errorThe bootloader cuts off the VME signals immediately after writing to the
CSR.EXIT bit. This leaves no time for the SFPGA VME interface to produce
a DTACK for the VME master, causing an ugly looking bus error message
(but not doing any real harm).Tomasz WlostowskiTomasz Wlostowskihttps://ohwr.org/project/svec/issues/22V2 - Swapped FMC slot number on front-panel2019-02-12T10:09:55ZProjectsV2 - Swapped FMC slot number on front-panelOn the SVEC front panel, the FMC slot 1 is above FMC slot 2.
But on the PCB, FMC slot 1 is below FMC slot 2\!https://ohwr.org/project/svec/issues/23V1 - LED silkscreen DBG LED1/2 twice2019-02-12T10:09:55ZErik van der BijV1 - LED silkscreen DBG LED1/2 twiceOn the board are LEDs that have the same text on the silkscreen: DBG LED
1 (twice) and DBG LED 2 (twice). One set is for the AFPGA and one for
the SFPGA, but this will not be clear for a user.https://ohwr.org/project/svec/issues/24V1 - Front-panel holes need modification2019-02-12T10:09:56ZErik van der BijV1 - Front-panel holes need modificationThe hole for the pushbutton should be slightly larger.
The holes for the LEDs should be slightly shifted to be centered with
the LEDs.https://ohwr.org/project/svec/issues/25V1 - Front panel GTP numbering is wrong2019-02-12T10:09:57ZProjectsV1 - Front panel GTP numbering is wrongOn the schematics, the comment should be changed as follow:
GTP0 -\> GTP1
GTP1 -\> GTP2
This is to be coherent with signal names and front-panel printing.https://ohwr.org/project/svec/issues/28V1 - Front-panel push button fails2019-02-12T10:09:58ZErik van der BijV1 - Front-panel push button failsThe V0 boards produced have non-functional front-panel push buttons. The
same model is used in the V1 design.
Likely the switch type is not made to be washed.
See C1 (page 6) and E1 (page 7) of the datasheet (attached).
- C1: following the soldering process, do not try to clean the switch
with a solvent or the like.
- E1: Foreign matter invaded from outside. Since this switch does not
have sealed structure, it may have contact failure caused by the
dust from outside up to the environment.
<!-- end list -->
- Study the cause of the problem
- Propose a solution
### Files
* [SKHHLQA010-ALPS.pdf](/uploads/5eec3d225d2672bee1076d8e514670cc/SKHHLQA010-ALPS.pdf)https://ohwr.org/project/svec/issues/33V1-0 - Front panel has name "CVEC" instead of "SVEC"2019-02-12T10:10:01ZErik van der BijV1-0 - Front panel has name "CVEC" instead of "SVEC"The text at the bottom of the front-panel reads "CVEC" instead of
"SVEC".
https://edms.cern.ch/document/1219029/1
- Correct
Note that this is on the unreleased, not final version of V1-0.https://ohwr.org/project/svec/issues/34V0 - VME Data Strobe lines wrong naming2019-02-12T10:10:02ZErik van der BijV0 - VME Data Strobe lines wrong namingIn VME the Datastrobe lines are called DS1 and DS0.
In the V0 schematics they are called VMEPX\_DS1\_N (correctly) and
VMEPX\_DS2\_N respectively (1/2 instead of 1/0).
This is confusing. See attached file.
*Actions**
- Rename in schematics VMEPX\_DS2\_N to VMEPX\_DS0\_N (all pages where
name is occurring).
- VMEPX\_DS1\_N is OK. Do not change.
*For info**
The ucf file should be like this:
```
NET "VME_DS_n_i[0]" LOC = Y7;
NET "VME_DS_n_i[1]" LOC = Y6;
```
Issue detected by Davide P.
### Files
* [issueSVEC.jpg](/uploads/08388aedb4984d3a57c74750e9588ef1/issueSVEC.jpg)https://ohwr.org/project/svec/issues/35V0 - Quad level LED not easily available2019-02-12T10:10:02ZProjectsV0 - Quad level LED not easily availableThe Bivar H485CHDL quad level LED is not easily available from
suppliers.
Consider replacing by Dialight 568-0721-111 rectangular quad level
bi-color LED.
Using a VME buffer (SN74VMEH22501DGGR), it is possible to drive 8
bi-color LEDs with only 8 signals from the FPGA.https://ohwr.org/project/svec/issues/36V0 - DDR3 pending End-of-life2019-02-12T10:10:03ZErik van der BijV0 - DDR3 pending End-of-lifeThe DDR3 chosen on the SVEC (same type as on the SPEC) is approaching
End-of-life.
On the Micron site MT41J128M16HA-15E has EOL
pending.
http://www.micron.com/products/dram/ddr3-sdram\#fullPart&236=1&173=2&192=1
However, the faster versions are fully in production
- MT41J128M16JT-125 (800MHz)
- MT41J128M16JT-107 (933MHz)
According to the datasheet (pages 76-77), both references are backward
compatible to the
-15E.
http://www.micron.com/~/media/Documents/Products/Data%20Sheet/DRAM/2Gb_DDR3_SDRAM.pdf
The only difference is that the package is 1mm less wide on the faster
versions.
*Recommendation**
- <s>Replace MT41J128M16HA-15E by MT41J128M16JT-125</s>
Earlier recommendation outdated. See updates of this issue.https://ohwr.org/project/svec/issues/37V0 - Wrong speed grade for application FPGA2019-02-12T10:10:05ZProjectsV0 - Wrong speed grade for application FPGAThe speed grade of the xc6slx150t FPGA is -2, but it should be -3 to be
compatible with the SPEC board.https://ohwr.org/project/svec/issues/38V0 - VME_IRQ[7..1] signals are active low2019-02-12T10:10:05ZProjectsV0 - VME_IRQ[7..1] signals are active lowAdd \_N to VME\_IRQ\[7..1\] signal name as they are active low.https://ohwr.org/project/svec/issues/39V0 - Use G25 for bank5 ddr3 controller calibration resistor2019-02-12T10:10:06ZProjectsV0 - Use G25 for bank5 ddr3 controller calibration resistorMove R127 calibration resistor from L25 to G25.
G25 is the default location for this resistor.
Choosing L25 gives a warning in coregen -\> timing not verified for non
default pin.https://ohwr.org/project/svec/issues/40Clean-up git repo2019-02-12T10:10:07ZProjectsClean-up git repoAll SVFC files and directories should be removed from circuit\_board/https://ohwr.org/project/svec/issues/41V0 - R219/R220 too big, can't boot SFPGA from flash2019-02-12T10:10:07ZTomasz WlostowskiV0 - R219/R220 too big, can't boot SFPGA from flashR219/R220 (driving M0/M1 SFPGA pins) are too big and the SFPGA can't
boot up from flash. Replacing with 0-ohm fixes the problem.https://ohwr.org/project/svec/issues/42V0 - missing pulldown on VME_D_DIR signal2019-02-12T10:10:08ZTomasz WlostowskiV0 - missing pulldown on VME_D_DIR signalThe signal is floating when the FPGAs are not (yet) configured, causing
undefined direction of the VME data buffers. Add a pulldown resistor.https://ohwr.org/project/svec/issues/43V0 - Wrong pullups on VME address/data buffer enable lines2019-02-12T10:10:09ZTomasz WlostowskiV0 - Wrong pullups on VME address/data buffer enable linesThe current configuration of pullup/resistors on the VME buffer control
lines sets the default direction of FPGA-\>VME bus and disables the
buffer outputs. This is incompatible with applications that require
passive monitoring of VME accesses (i.e. bootloaders).
Changing the pullups to pulldowns will reverse the direction and enable
the buffers by default.
Components concerned: R157, R203, R316, R175.https://ohwr.org/project/svec/issues/8Gateware: missing timing constraint in golden bitstream2019-02-12T10:09:45ZDimitris LampridisGateware: missing timing constraint in golden bitstreamThe current gateware design for the golden bitstream is missing the
timing constraint for the 20MHz VCXO clock input, which is used to
derive the system clock. The design is essentially running
unconstrained\!
A new 50ns PERIOD timing constraint should be put in place for the
clk\_20m\_vcxo\_i NET.
### Files
* [0001-golden-add-missing-timing-constraint-for-20MHz-VCXO-.patch](/uploads/58e2511f7db04601438a44e06406c399/0001-golden-add-missing-timing-constraint-for-20MHz-VCXO-.patch)Dimitris LampridisDimitris Lampridis