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.
The card uses an LPC connector.
Vadj is fixed to 2.5 Volt, i.e. the signalling levels are 2.5V
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
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
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.
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
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:
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
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 initgit 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
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
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
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
Q: How do I program the relocation registers of the SVEC to set up its base address?
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 , and it is part of the svec-base , 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 . There is also the spec-base, with exactly the same structure and purpose, but for the SPEC board.