HyperTransport Tunnel

FAQ

Q: The core is written in SystemC, isn't that only a simulation language? A: Just like VHDL was originally a language that was only for simulation and eventually evolved into a language that allowed synthesis, SystemC can now be used for synthesis as long as a synthesisable subset is used. The core was designed to be used with Synopsys SystemC Compiler that translates the SystemC to VHDL or Verilog, but that tool is now discontinued. Other products that do synthesis are Celoxica Agility Compiler, Forte Cynthesizer and SytemCrafter SC. Agility Compiler 1.0 (missing support for common SystemC operators/syntax) and SystemCrafter SC 2.0 (missing capability for combinatorial process) both don't support all features used in the core...yet. I have not had the chance to test Cynthesizer or Agility Compiler 1.1, let me know if you have the chance to do so! Q: But if there is no SystemC synthesis tools available, how can I use the core? A: Hopefully, current tools will mature enough soon to support the core. But for now, the core can at least be simulated using any C++ compiler with the SystemC library. Keep in mind that the core IS RTL code, so simulation is not very fast. The core could also fairly easily be translated by hand to Verilog or VHDL if one was inclined to do so. Q: Don't you have Verilog or VHDL produced by SystemC Compiler when it was available? A: Yes, but that code is not very useful as some bugs have been fixed since then and there surely will be others that will be fixed with time. That code is also not really human-readable. Also, there are compile-time variables that must be set for every individual applications (like the address space required) so the core must be synthesized after settings those options. Q: What part of the HyperTransport protocol does the core cover? A: The core handles the validation, routing and buffering of packets. This means that an application using the core must understand HT packets, but it does not need to buffer them or handle any flow control. To be platform independent, the core does not define the PHY layer and does not include embedded memories. The core does use embedded memories but they must be connected to the core's in and out ports. The missing PHY layer consists simply of HT drivers and receivers and shift registers with counters to do serialization/deserialization. On Altera, this is all included in hardware. On Xilinx, the drivers/receivers are in hardware but the serialization/deserialization must be done with programmable logic. Q: Does the core have any limitations? A: The core is based on version 2.0b of HyperTransport and so should work with any versions of HT prior to 2.0. So the only limitations are on how the core is implemented: - It is quite big for use inside an FPGA (around 18 kLUTs for a Xilinx Virtex II pro and 21 kLEs for an Altera Stratix). If Retry , DirectRoute and in-vc packet reordering are disabled, the complexity can be reduced by about 30-40%. - Frequency wise, the core can go up to 100MHz in a FPGA, but 75MHz or even 50MHz is more realistic in a standard grade FPGA. Removing the Retry mode support can increase the performance a little bit. - The core handles 32 bits per clock cycle when most commercial cores handle 64 bits per clock cycle. The core could be modified to handle 64 bits at the time to effectively double its throughput, but it would necessitate some big modifications since in 64 bits, there can be two 32 bits HT packets and storing two packets per cycle in the buffers is currently not supported. Q: What I want is a core with a single HT link (an HT Cave instead of an HT tunnel), can I use your core for that? A: The short answer is yes, you can by connecting the inputs of one side of the core to logic 0. But doing it this way, you waste a good part of the resources of the tunnel because they are never used. A fast and better way to do it would be to rip all the parts from one side of the tunnel to save a good 40% of the complexity and it would only require to modify the top level or the core, not the actual modules. To save an extra 10% of complexity, the CSR, User Interface and buffers would need to be modified to remove unnecessary logic. Q: Most other cores use the GPL/LGPL, why use the Mozilla Public License (MPL)? A: The GPL is very centred on software and since this is not software, even the Free Software Foundation is not sure if the GPL would cover a circuit generated from GPLed code. On the other hand, MPL only talks about source code and executable. Executable is defined as being anything derived from the source code, so it does properly cover a netlist or circuit. The MPL is incompatible with the GPL, so this core cannot be used with GPL cores! It can be with BSD and LGPL cores, but how to actually legally integrate MPL and LGPL cores is outside the scope of this FAQ. Q: Why is the core dual-licensed MPL/Ecole Polytechnique License? A: We want to open the source code and allow anybody to use it under the MPL, but we also want to keep the right to do something else with the code later on. To do this, the code is dual-licensed so that we can revert our own license at a later time. But you have the complete right to download the code and use it under only the MPL. In other words, the development here will continue under the dual-license but you could fork the project under only the MPL at any time.