Skip to content

S
Simple VME FMC Carrier SVEC

Faq

Last edited by Erik van der Bij
Page history

Frequently Asked Questions

Hardware

Q: Is there a users manual available?

A: A [Hardware manual]https://ohwr.org/project/svec/uploads/7aedb3c2fea71ef926fbbe73ab4e99ee/manual_svec_hardware.pdf) has been written by Janz Tec that shows clearly the block diagram and pinout of all connectors.

The best starting points for additional information are:

Q: Does any FMC card work on the SVEC?

A: No, you cannot use any FMC card. The FMC standard allows many options in the use of the signals on the FMC connector. Signalling levels, differential or single ended signals and the level of Vadj may all be chosen rather freely. And of course there is the major option of using a High Pin-Count (HPC) or Low Pin-Count (LPC) connector which has, indeed, less pins than the HPC.
To make the SVEC design simple, we had to make some design choices that may make it not be compatible the FMC mezzanines you'd like to use. Notably:

  • The card uses an LPC connector.
  • Vadj is fixed to 2.5 Volt, i.e. the signalling levels are 2.5V LVTTL.
  • FMC connectivity: all 34 differential pairs connected, 1 GTP transceiver with clock, 2 clock pairs, JTAG.

To fully check for compatibility the best thing is to verify, signal by signal, the connections in the schematic of the SVEC and of the mezzanine you want to use. You may let us know once you've done this excercise for a particular mezzanine and we possibly can add it to a list of compatible mezzanines.

Q: Does the SVEC work in a 'classic' VME crate as opposed to a VME64x crate?

A: No, the SVEC does not work in a classic VME crate. Notably the 3V3 supply is taken from the D-row of the connector. The D and Z rows are the additional rows that are added on the VME64x connector. These two rows do not exist in the classic VME specification. Actually a classic VME crate does not have a 3V3 supply at all.
However, a dedicated add-on board has been designed and is commercially available that solves this problem and that allows the SVEC to be used in a 'classic' VME crate. Please see the documentation of the 3.3V Adapter for SVEC project.

Q: Could I have more DDR memory on the card?

A: The design is with 2x 256 MByte (2 Gbit) DDR3 on the board. Looking at the schematics one can read the note on pages 3 and 4: "DDR3_A14 is wired for compatibility with higher memory capacity".
Indeed pin T7 of the memory IC MT41J128M16JT-125, which is an NC pin, is connected to the FPGA. Likely for an 256 chip (instead of 128) this would be address line A14.
With the additional address pin the size would be doubled, so you would be able to have 2x 512 MByte (4 Gbit) DDR3.
Note that this never has been tried, and it should be checked.

The SVEC7, that is currently under design, has a similar functionality as the SVEC and has a larger memory (April 2020).

Q: Are the front-panel LEMOs configurable as input or output?

A: Yes, they are configurable as input or output. Connectors L1 and L2 can be independently be programmed to be an input or an output. The direction for L3 and L4 is set together, i.e., they are both input or both output. One can have 0, 1, 2, 3 or 4 inputs with 4, 3, 2, 1 or 0 outputs respectively. There may just be a limit in the assignment of which connectors to use.

Q: does the card have a MAC address stored in a memory?

A: No. There is no memory where the MAC address is stored. So SVEC boards do not come with a MAC address that is set or programmed by the manufacturer.
When you use the White Rabbit PTP core, it uses the ID of digital 1-wire thermometer available on the SPEC board to generate unique MAC address for each board. There is a specific [WRPTP FAQ entry about MAC addresses(https://www.ohwr.org/project/wr-cores/wikis/Wrpc-faq#mac-addresses).

Q: what about the 125 MHz clocks to the P2 or U.FL connectors?

The main thing we know is that it was apparently to make it compatible to the VFC (the very first one, maybe also other ones like the VFC-HD). It makes that a 125 MHz clock can be sent to either P2 (RTM, default), or to the U.FL connector that could be cabled to a connector on a dedicated FMC mezzanine. You may look at the connectivity in the schematics, page 9, bottom right.
In CERN BE-CO we have no RTMs, nor FMC mezzanine cards that are using this possibility.

Gateware

Q: Is the FPGA programmable from the JTAG header on the board?

A: Yes, both FPGAs are programmable from the JTAG header on the board. After powering down you will loose the configuration.

With this same JTAG header you can also program the Configuration EEPROM that is connected to the "system FPGA", so that the "system FPGA" can start up with the firmware that is preloaded into the EEPROM.
The "system FPGA" firmware allows access to the EEPROM from the VME and also to load the "application FPGA" with a firmware located in the EEPROM. See the svec-gateware-manual for details.

Actually the board will be delivered with the "system FPGA" EEPROM pre-loaded with a VME bus interface (the bootloader). With a program writing over the VME bus one is able to program the "application FPGA" who would then take over the control of the VME bus and disable the "system FPGA".

Q: How do I generate the .mcs file that is described in the svec-gateware-manual

A: The IMPACT flasher needs an Intel HEX-formatted file as .mcs. You can prepare the MCS file from the binary flash image by using "Create PROM File" flow in Impact and clicking through all the wizards (the flash type is M25P128) or by using Xilinx's promgen tool directly:

promgen -p mcs -o image.mcs -spi -data_file up 0 image.bin  -w

where image.bin is the binary file made by following the steps from section 4.5.1 of the Gateware Manual.

Q: Is there a FPGA reference design available?

A: We have not yet a fully documented reference design. However, the "Golden bitstream" is a good start. This is the code that will be loaded in the "application FPGA" and that is able to read the I2C bus on the mezzanines. For the "system FPGA" you may look at the bootloader

Q: What version of the Xilinx tools are you using?

A: We use Xilinx ISE. Currently versions 13.3 and 14.1 are working fine.

Q: The VME flasher utility says "the bootloader is too old".

A: It's probably right... The first version of the bootloader that was shipped with early series of the SVEC cards did not support booting the AFPGA from Flash and re-programming it through VME. This feature has been added in the second version of the bootloader. The instructions for updating are in the svec-gateware-manual

Q: In my system the extended pins (rows z and d) on connectors P1/P2 will be left unconnected. What to do?

A: Just don’t put these lines in the .ucf file and then the Xilinx tool will find a safe solution for these pins.

Q: Is it possible to simulate the project with Xilinx ISIM?

A: To that advantage of the SystemVerilog VME bus functional model, you need a simulator with SV support. Nevertheless, a VME testbench in vhdl is available (see hdl/sim/ddr_test/).

Q: Are all necessary files uploaded on the GIT repository?

A: The SVEC GIT repository relies on sub-modules. Therefore, you have to run the following commands (from the toplevel):

git submodule init
git submodule update

Q: Can I use the SVEC with a VME core other than the VME64x-core

A: Yes, just make sure the core is connected correctly: check VME I/O signals assignment, in particular the polarity of the buffer enable/direction signals. You may also have to install drivers specific to your VME core and operating system.

Q: Is it possible use the SVEC with the VmeIntfce core used in many places at CERN?

A: Yes. In this case, do not install the SVEC driver and do not declare the card as FMC-SVEC in CCDB. You may use the svec-flasher tool to program the AFPGA flash or load the AFPGA bitstream from the command line of the frontend.

Q: Is there a command line tool for loading a bitstream to the AFPGA over VME (without rebooting the frontend)?

A: Yes, svec-flasher can do it. Please read the section 4.2 of the Gateware Manual for instructions.

Q: Is there a possibility to determine (in software), whether the application FPGA is already loaded and configured or not?

A: The current bootloader version has no "direct" check for that. If the AFPGA is already programmed, the bootloader's CSRs are not visible and will throw a VME bus error when read. If the bootloader is active (= AFPGA not programmed), reading the IDR register value (CR/CSR @ 0x7000C) will return 0x53564543 (SVEC signature in ASCII).

Q: How do I program the relocation registers of the SVEC to set up its base address?

Probably the example in the documentation of the VME core of the SVEC is the most helpful reference about this, as it contains worked examples:
https://www.ohwr.org/project/vme64x-core/blob/master/documentation/user_guides/vme64x_user_manual.pdf (sorry, link fails, 11/8/22)

In addition, the code of svec_setup_csr() in the svec device driver can also be very helpful in understanding how you can do the configuration by writing to the Address Relocation Registers:
https://www.ohwr.org/project/svec-sw/tree/master/

The base address is the geographical slot number times 0x80000, so slot 11 would be at 0x580000 (and slot 12 at 0x600000). When the card is in slot 11, and you add the 0x70000 and the 0x4 of the BTRIGR register you arrive at the 0x5F0004.

Q: Is there a kind of generic ucf file for the SVEC?

A: Yes, there is [1], and it is part of the svec-base [2], an HDL module that can be used to instantiate all the carrier-specific part in a design in a way that is guaranteed to be compatible with our drivers (UCF files do not play any role in that, but it is something that you gain if you use the svec-base, apart from predefined pinouts).

The UCF files are split and "included" in the top-level design based on the values passed to the svec_base_ucf variable in the top-level Manifest.py for hdlmake, so that you only use the parts that are relevant to your application and reduce the number of warnings generated by the tools.

A good example of how this is used is the development version of FMC-ADC for SVEC, top-level Manifest.py at line 36 [3]. There is also the spec-base, with exactly the same structure and purpose, but for the SPEC board.

See also Generic UCF files for SVEC FMC.

[1] https://ohwr.org/project/svec/tree/master/hdl/syn/common
[2] https://ohwr.org/project/svec/blob/master/hdl/rtl/svec_base_wr.vhd
[3] https://ohwr.org/project/fmc-adc-100m14b4cha/blob/release/5.0.0-rc8/hdl/syn/svec_ref_design_wr/Manifest.py#L36

Erik van der Bij, Tom Wlostowski, Matthieu Cattin, Dimitris Lampridis - 11 August 2022