Simple VME FMC Carrier SVEC issueshttps://ohwr.org/project/svec/issues2023-10-09T08:25:33Zhttps://ohwr.org/project/svec/issues/32V0 - Wrong name for 12V testpoint2023-10-09T08:25:33ZProjectsV0 - Wrong name for 12V testpoint12V testpoint is named "P12V VME" on the silkscreen.
Should be "P12V".https://ohwr.org/project/svec/issues/26V1 - various PCB layout issues2023-10-09T08:25:33ZErik van der BijV1 - various PCB layout issuesVarious PCB layout issues have been found, mostly related to
tolerances.
See attached Excel file.
### Files
* [0019-4929-1.xls](/uploads/6942a6013515fdb5191ff4be39c7b7d2/0019-4929-1.xls)https://ohwr.org/project/svec/issues/31V0 - Add SO16 footprint for FPGA config flash2023-10-09T08:25:33ZProjectsV0 - Add SO16 footprint for FPGA config flashCurrently the FPGA config flash (IC14) is in MPL8 package -\>
M25P128-VME6G
An alternative SO16 footprint should be added in order to overcome
supplier stock shortage.
So16 reference -\> M25P128-VMF6Ghttps://ohwr.org/project/svec/issues/20V2 - Front-panel BOM missing EMC Gasket. Change screw.2023-10-09T08:25:33ZErik van der BijV2 - Front-panel BOM missing EMC Gasket. Change screw.The [arrangement
BOM](https://edms.cern.ch/file/1249647/2/EDA-02530-V2-0_arrangement-mat.pdf)
is wrong:
It specifies
- ELMA 66-514-26 - EMC Front Panels - Aluminium With EMC Gasket acc.
IEEE - Thickness 2.5mm
- But this order number does *not* contain the EMC Gasket
- EMC Gasket needs to be ordered separately (ELMA 81-062-06)
<!-- end list -->
- Add EMC Gasket to BOM
- (while at it, also correct filename inside the BOM: arrangemet -\>
arrangement)
See also
- [ELMA
datasheet](http://www.elma.com/Admin/ProductionFiles//ProductTypeFile/919/English/IEC_Ergonomic_Handle_Total.pdf)Erik van der BijErik van der Bijhttps://ohwr.org/project/svec/issues/27V1 - GTP clock inverted2023-10-09T08:25:33ZTomasz WlostowskiV1 - GTP clock invertedThe reference clock for GTP 245 (part IC19L) is inverted on
FPGA\_GTP.SchDoc (FPGA\_PLL\_REF\_CLK0\_N port connected via C162 to
MGTREFCLK0P and vice versa).https://ohwr.org/project/svec/issues/30V1 - Review 12V generation schematics2023-10-09T08:25:33ZErik van der BijV1 - Review 12V generation schematicsThe step-up converter and associated components add many unique items to
the BOM.
- Review schematics design of 12V generation
- unique BOM items (unique valued resistors, non-generic 0.02 Ohm)
- why 2 power transistors in parallel
- Consider using a ready-made modulehttps://ohwr.org/project/svec/issues/17HDL: increase space for the AFPGA bitstream in the flash2022-12-05T15:07:08ZTomasz WlostowskiHDL: increase space for the AFPGA bitstream in the flashThe current version of the flash memory layout reserves too little space
for the AFPGA configuration bitstream (4 MB vs 4.04 MB).
Workaround: enable bitstream compression in ISE.Tomasz WlostowskiTomasz Wlostowskihttps://ohwr.org/project/svec/issues/12V3 - schematics: VMEPX_SERA and SERB shown, but not used2022-12-05T15:07:08ZErik van der BijV3 - schematics: VMEPX_SERA and SERB shown, but not usedThe VMEPX\_SERA and SERB on VME P1, pins B21 and B22 are shown on pages
18 and 19 of the schematics. But they are actually not used (they are
only connected on the P1 connector).
These are the serial I2C lines that are for example on an ELMA VME
crate. They cannot be used on the SVEC as they are not connected.
- Remove from schematics to remove confusion *or*
- Add a buffer and connect to Xilinx (cf. CONV-TTL-BLO) so that they
can used for stand-alone systems not requiring a processor with VME
busEDA-02530-V4-0Tomasz WlostowskiTomasz Wlostowskihttps://ohwr.org/project/svec/issues/4DS locs are swapped in golden UCF2022-12-05T15:07:08ZTristan GingoldDS locs are swapped in golden UCFThe mapping of the VME\_DS\[1:0\] pins in the ucf file are swapped (wrt
the schema).
As a consequence, it may be swapped in many designs too (like wr-cores)
using svec.
(Bytes access look unused).Dimitris LampridisDimitris Lampridishttps://ohwr.org/project/svec/issues/16Reset CDCM61004 PLL on powerup2022-12-05T15:07:08ZTomasz WlostowskiReset CDCM61004 PLL on powerupRelated to issue \#894.
Pulse PLL\_CE pin low to reset the PLL some time after the startup of
the reference oscillator. This prevents the PLL from calibrating its VCO
with wrong reference clock and locking on incorrect frequency.Tomasz WlostowskiTomasz Wlostowskihttps://ohwr.org/project/svec/issues/15V2 - Mini DisplayPort connector is obsolete2022-12-05T15:07:08ZProjectsV2 - Mini DisplayPort connector is obsoleteThe reference 64L020S-331N-B is no longer
manufactured:
http://uk.farnell.com/multicomp/64l020s-331n-b/receptacle-mini-dp-r-a-tht-30au/dp/1895014
### Files
* [MDPR-2020-BK63U1F.pdf](/uploads/5af3eea4399f2b2cb48f7645a59bd62d/MDPR-2020-BK63U1F.pdf)https://ohwr.org/project/svec/issues/7Gateware: missing support for hdlmake2022-12-05T15:07:08ZDimitris LampridisGateware: missing support for hdlmakeGolden AFPGA design does not support hdlmake (missing Manifest.py). It
only includes a hard-coded (and outdated) Xilinx project file.
Bootloader SFPGA design does not support newer versions of hdlmake.
Attached two patches to introduce full support for hdlmake.
### Files
* [0003-sfpga_bootloader-remove-Xilinx-ISE-project-file-and-.patch](/uploads/890a0b973465772d7aa6c20d3d56e884/0003-sfpga_bootloader-remove-Xilinx-ISE-project-file-and-.patch)
* [0002-golden-remove-Xilinx-ISE-project-file-and-introduce-.patch](/uploads/351b0f1b73fd6157c9804602f144c7a4/0002-golden-remove-Xilinx-ISE-project-file-and-introduce-.patch)Dimitris LampridisDimitris Lampridishttps://ohwr.org/project/svec/issues/5Gateware: SFPGA Bootloader mini-VME FSM can get stuck2022-12-05T15:07:08ZDimitris LampridisGateware: SFPGA Bootloader mini-VME FSM can get stuckWhen in the DECODE\_ADDR state, if the address and AM and data type are
matched, but the offset is not within the "magic" numbers
(0x70000-0x70020), then the FSM will not move to the EXEC\_CYCLE state
(correct), but it will also not return to IDLE (wrong). It will instead
stay in DECODE\_ADDR, and will move out only if a new request comes in
with the correct offset.
The easiest fix for now is to probably put a default transition to IDLE
when in DECODE\_ADDR, and override it below if the conditions are ok
with a transition to EXEC\_CYCLE.Tristan GingoldTristan Gingoldhttps://ohwr.org/project/svec/issues/14PTS: timing violation in DAC signal.2022-12-05T15:07:08ZErik van der BijPTS: timing violation in DAC signal.See [attached file](https://www.ohwr.org/project/svec/uploads/5f2da47ee102a92e58c5a17a3ee5f469/PTS_7Sv02.pdf)
According to the Fig. 2 shown in the AD5662 datasheet, it is clear that
chip uses the negative clock
edge to latch the data, with a setup/hold time given by t5 and t6.
The PTS test used for the SVEC/SPEC board changes DAC DIN signal at
exactly the falling SCLK
edge. Therefore, it violates the timing conditions indicated in the
datasheet (setup time=5ns and hold
time=4.5ns) as shown in Figure 1.
This produces that voltage values written from Python code are wrong and
do not correspond with the
real values presented at the DAC output (as measured with an
oscilloscope).
Problem not urgent as the PTS basically only has to check if every
solder connection is correctly done, even with the problem present, it
will detect if the DAC would not be correctly connected.
### Files
* [PTS_7Sv02.pdf](/uploads/5f2da47ee102a92e58c5a17a3ee5f469/PTS_7Sv02.pdf)https://ohwr.org/project/svec/issues/2V3 - PCB and schematics wrong for use of optional USB - FTDI chip2022-12-05T15:07:08ZErik van der BijV3 - PCB and schematics wrong for use of optional USB - FTDI chipWhen the option for the USB - FTDI chip (FT2232HL) needs to be used, it
will not work. There is a problem that appears when the optional
components for this will be mounted.
See the attached image. Page 13 of the schematics shows that the line
connected on the left of R248 is called USB\_TMS (like the one connected
to R243). The line to R248 should be USB\_TDI.
Schematics at:
https://edms.cern.ch/file/1421529/1/EDA-02530-V3-0_sch.pdf (page 13)
*Problem reported by JanzTec (16/5/18)*
### Files
* [USB_TMSx2_bottom_one_wrong.png](/uploads/f4219c9bc8b7cf31cf94b81dfa26da77/USB_TMSx2_bottom_one_wrong.png)EDA-02530-V4-0Tomasz WlostowskiTomasz Wlostowskihttps://ohwr.org/project/svec/issues/9V3 - debug LEDs ROHM SML-311UTT86K not available2022-12-05T15:07:08ZErik van der BijV3 - debug LEDs ROHM SML-311UTT86K not availableThe ten LEDs on the board, used for debugging (SML-311UTT86K) is not
available anymore.
The SML-311UTT86 would be the same LED but they have a difference in
brightness:
with K: 4.0 – 6.3 mcd at 2mA
without K: 0.9 – 2.5 mcd at 2mA
Suggest to replace
SML-311UTT86K by
SML-311UTT86
Problem and solution from Janz. Agreed with Erik.
LED type will be different on productions from August 2017 on.EDA-02530-V4-0Tomasz WlostowskiTomasz Wlostowskihttps://ohwr.org/project/svec/issues/1V3 - D1 Shottky Diode Vishay 50WQ06FNPbF EOL, obsolete2022-12-05T15:07:08ZErik van der BijV3 - D1 Shottky Diode Vishay 50WQ06FNPbF EOL, obsoleteD1 1 60V 5.5A Schottky Rectifier 50WQ06FNPbF VISHAY SEMICONDUCTOR
50WQ06FNPbF is at EOL.
JanzTec recommends to replace by Vishay 50WQ06FN-M3 that has all the
same parameters. This will be used in the 2018 production run.EDA-02530-V4-0Tomasz WlostowskiTomasz Wlostowskihttps://ohwr.org/project/svec/issues/6SVEC Bootloader FPGA CR/CSR space2022-12-05T15:07:08ZFederico VagaSVEC Bootloader FPGA CR/CSR spaceThe current version of the bootloader provides an incorrect CR/CSR.
It answers only to addresses within 0x70000 and 0x70020; those addresses
are used then to program the big FPGA with our real application. This is
fine, but incorrect:
- it does not respect the VME standard
- 0x70000, 0x70020 are magic addresses that software developer must
hard-code in the low level software. The correct solution should be
to take these values from their standard place in the CR space.
Fixing this can bring the following advantages:
- it becomes standard :)
- the programming addresses can be auto-discovered from the CR
definition
- the low level software can distinguish between the bootload FPGA and
an application FPGA by using the CR. \[1\]
So, if it fits the small FPGA, the bootloader should have a proper CR
space.
\[1\] the vendor, device, and revision ID should depend on the gateware
that we load and not on the hardware plugged (the svec).https://ohwr.org/project/svec/issues/3V3 - SFP cage type is obsolete, EOL2022-12-05T15:07:07ZErik van der BijV3 - SFP cage type is obsolete, EOLThe two-piece SFP Cage from Tyco Electronics
([6367034-1](http://www.te.com/usa-en/search.html?q=6367034-1) and
[6367035-1](http://www.te.com/usa-en/search.html?q=6367035-1)) is at
End-of-Life (EOL).
The supplier suggests the use of the one-piece solution
[2227303-3](http://www.te.com/usa-en/product-2227303-3.html).
This solution will be used (with agreement from CERN) for new
productions by JanzTec from January 2018 on.
*Reported by JanzTec on 22/1/18.*EDA-02530-V4-0Tomasz WlostowskiTomasz Wlostowskihttps://ohwr.org/project/svec/issues/61Bug in software/tools/vme-flasher/svec-flasher.c2022-11-10T07:39:21ZRené GeißlerBug in software/tools/vme-flasher/svec-flasher.c**This bug makes Flash programming fail on SVEC v3**
The reason is an incomplete initialization of the `sector_map` memory, which leeds to some Flash sectors not beeing erased before writing.
**Bugfix:**
change line 253 of software/tools/vme-flasher/svec-flasher.c
from:
`memset(sector_map, 0, sizeof(sector_map));`
to:
`memset(sector_map, 0, sizeof(int) * FLASH_SIZE / sector_size);`
**Explanation:**
`sizeof(sector_map)` returns the size of the pointer to the `sector_map`, not the size of the `sector_map` itself. This leads to an incomplete initialization.