They're not required to, but it's the first time I've seen an FPGA development board without schematics. Some vendors may leave out parts like an integrated JTAG interface, but the main FPGA and all peripherals connected to it are generally shown.bobrocks95 wrote:Are they required in any way to send schematics if you request them, or is it just that other companies are being maybe a bit more consumer-friendly and posting schematics as their own decision?
That depends a lot on the way the code is written. If it uses a lot of vendor/architecture-specific primitives, porting requires more work than code that relies on the synthesis software to infer everything. Since in my (small, mostly Xilinx-based) experience the FPGA tools these days are at least ok in that regard (e.g. Quartus can be a bit touchy if you're trying to describe dual-ported RAMs) the gcvideo code is written using generic VHDL whereever possible. It seems to have worked - the decoder and color space conversion modules have been successfully synthesized for Xilinx, Altera and Lattice FPGAs with no changes except modifications to the top-level module to account for the different peripherals connected to the FPGA.Also, is porting between architecture a very extensive process?
The exception to this is the DVI encoder which is based on code from the Hamsterworks wiki. It currently uses a few Spartan 6-specific primitives for the differential output signals and clock multiplication as there is no way to infer these modules from generic VHDL code. These parts would need to be adapted for use on a Spartan 3A, but this shouldn't be too hard as there is a Xilinx application note showing how to implement HDMI transmitters and receivers on a Spartan 3A and there is a wizard for generating a configuration for the clock managers in the Xilinx IDE.
It's all in VHDL. Although it's more verbose than Verilog I prefer it because it has much stricter type checking.Is your code written in Verilog or VHDL? Or maybe it's hardware specific?