Frequently asked questions

No, after the initial configuration, the GRSCRUB is self-standing, which releases the processor core to perform other tasks. The GRSCRUB can be configured to periodically scrub the FPGA. Periodic scrubbing is performed independently and requires no additional monitoring. Interrupts can be configured to alert the processor in case of detected errors in the FPGA configuration memory.

‍

No, GRSCRUB is intended to be used as an external entity to the FPGA being supervised.

Yes. You may copy and redistribute the Open Source models, both at home and at work, without restrictions.

The main difference is in what the license allows you to use them for. Certain models and test benches are only available in the commercial versions. Finally, our technical support service is only provided for the commercial versions.

You must buy a commercial license.

To unpack a TSIM/GRSIM archive, use the tar command:

tar xzf tsim-leon3-3.1.11.tar.gz

Installation is described in the Appendix "License key installation" of the GRMON User' Manual

The evaluation version of GRMON can be downloaded from our website. The evaluation version may be used during a period of 21 days without purchasing a license. After this period, any commercialuse of GRMON is not permitted without a valid license. The following features are not available in the evaluation version:

• GUI• Support for LEON3-FT, LEON4

• GRLIB commercial licensed cores

• FT support• Custom JTAG configuration

• Profiling

• TCL API (drivers, init scripts, hooks, I/O forward to TCL channel etc)

The LGPL is designed to "permit developers of non-free designs to use free libraries" (quote from the LGPL). In other words, if the Open Source models were LGPL'd, companies would not have to purchase our commercial editions in order to make commercial/proprietary software, they could just use the Open Source Edition, free of charge. That would mean we would not get the revenue necessary for improving and extending the models. Note also that the Free Software Foundation discourages the use of the LGPL.

No. Designs developed with the Open Source models are always open source designs, i.e. it can only be distributed under an open source license. In particular, all the source code for all the modules your design is based on, regardless of whether they have been written by you or by others, must be open source design (because of the "viral" nature of the GPL). This is part of our commitment to the open source community, and enables those who contribute to the open source do so without paying license fees.

Although it is possible to develop open source designs for internal use, it is difficult to ensure that such design is used and distributed legally. For example, if your open source design requires any models that impose conditions on you that contradict the conditions of the GNU GPL, including, but not limited to, patents, commercial license agreements, copyrighted interface definitions or any sort of non-disclosure agreement, then you cannot distribute it at all; hence it cannot be given to consultants, employees for their personal computers, subsidiaries, other divisions, or even to new owners.

Consequently we recommend using commercial licenses for all internal development.

No. Our commercial license agreements only apply to designs that were developed with our models under commercial license agreement. They do not apply to design that was developed with the Open Source Models prior to the agreement. Any design developed with our models without a commercial license agreement must be released as Open Source code.

No, you must supply the source code that corresponds to the final netlist. Corresponding source means the source from which users can rebuild the same netlist. Part of the idea of open source code is that users should have access to the source code for the deign they use. Those using your version should have access to the source code for your version. If you release an improved version of a GPL-covered design, you must release the improved source code under the GPL.

It is possible to apply the GPL to any kind of work, as long as it is clear what constitutes the "source code" for the work. Program and Software shall be interpreted as the design (in EDIF, netlist) of the models and the source code as the RTL design of the models.

Yes. The Open Source models are free models both as in "no cost" and as in "free speech". Even more, it is actually available under the terms of the GNU GPL. This means you can link GPL'ed models to it, and you can take code from our models and put it into other GPL'ed models.

If you want to develop an Open Source design, you are welcome to use our Open Source VHDL models. If you don't want to release you design in Open Source (for example to keep your source code secret or to produce commercial designs), you must purchase a commercial license.

The fault tolerant models have been developed to withstand the radiation effects seen in space applications. We regard these applications as specific, with a limited value for the open source community. The use of the FT models also requires deeper interaction with the user, thus the models are only available under commercial licenses

They are our contribution to the open source community. Part of our commitment is to enable those who contribute to open source models to receive something back. We also benefit, as open source users contribute to the quality of the products by providing bug reports and feedback.

CAN FD (Controller Area Network with Flexible Data-Rate) is an extension of the original CAN protocol, offering higher data transfer rates and greater flexibility. It supports data rates up to 8 megabits per second and allows for data lengths up to 64 bytes per frame, compared to the original CAN’s 8 bytes. This improves efficiency and bandwidth utilization. CAN FD is also backward compatible with the original CAN, ensuring interoperability with existing systems.

The draft standard for SPI (Space Peripheral Interface) is a draft ECSS (European Cooperation for Space Standardization) protocol aimed at defining a formal standard for SPI in space applications. This document outlines the SPI communication framework across three layers: Physical, Data Link, and Network. Its goal is to enhance reliability, interoperability, and reusability of space systems. The draft is based on demonstrator development, simulations, and tests that validate SPI characteristics. It serves as a foundation for future ECSS workgroups to develop and refine formal SPI standards.

MIL-STD-1553B is a military standard for a data bus used in aircraft and spacecraft. It defines a dual-redundant bus system with a 1 Mbps transfer rate, organized in time-division multiplexing. The standard outlines the physical, electrical, and protocol aspects of communication, using command, status, and data words to exchange information between a central bus controller and various remote terminals. Its robust design includes fault tolerance to ensure reliable operation in harsh environments.

No, only the AMD/Xilinx Kintex UltraScale and Virtex-5 FPGA families are supported.

SpaceWire Remote Memory Access Protocol (RMAP) is an extension of the SpaceWire standard that enables remote access to memory devices, such as memory boards, on a SpaceWire network. RMAP is a high-level protocol that runs on top of the SpaceWire standard and provides a standardized method for accessing memory devices on a SpaceWire network.

SpaceWire is a data communication protocol designed for use in space applications. The SpaceWire links are high-speed, bi-directional, point-to-point communication links operating  at a baud rate of between 2 and 400 Mbits/s. SpaceWire is used in a variety of space-based systems,  such as satellites and spacecraft. It is also used in ground-based systems, such as spacecraft test and simulation equipment. The standard was developed by the European Space Agency (ESA) and is now maintained by the SpaceWire Consortium. SpaceWire is designed to be highly reliable and robust in the harsh radiation environment of space. It uses a number of error-detection and correction  techniques, such as cyclic redundancy check (CRC) and packetization, to ensure data integrity. SpaceWire is also designed to be low-cost, making it well-suited for use in space-borne systems, where cost and weight are major considerations.

At each end of a SpaceWire link is a coder/decoder (CODEC) which encodes packets of data to be transmitted into a serial bit-stream and decodes an incoming serial bit-stream into a data packets.

WizardLink is a line of transceivers produced by Texas Instruments. One of the products in this line, the TLK2711, commonly used in space applications, follows a basic protocol that includes 8b/10b encoding, serialization/deserialization, comma detection and alignment, and error codes for loss of signal

SpaceFibre is a high-speed fiber optic technology that is compatible with the widely-used SpaceWire protocol and offers even faster data rates. With a capability of up to 6.25 Gbps and beyond per lane, SpaceFibre can provide up to 15 times the data rate of SpaceWire. In addition to its impressive speed, SpaceFibre also includes built-in fault detection and recovery, as well as deterministic communication mechanisms, ensuring reliable and consistent data transmission. SpaceFibre can be used with both copper and optical fibers, and offers significant reductions in harness size compared to SpaceWire, with a 50% reduction when using optical fibers and over 90% when comparing data transfer per bit.