1. Home
  2. Field-Programmable Gate Arrays
  3. Configuration Management Best Practices

Configuration Management Best Practices

I am currently working on a project that takes the same high level behavioral model and ultimately targets both an Altera and a Xilinx chip. About 95% of the code can by synthesized for either Altera or Xilinx. Meaning the bulk of the code can be generic without specifying architecture specific primitives. However, the last 5% is presenting some configuration management issues. For instance, I have to instantiate a DCM for Xilinx and a PLL for Altera. Both primitives have similar high level functionality. Considering this I would like to be able to simply exchange a DCM for a PLL when synthesizing between the two architectures. However there are enough differences in port definitions that this idea is not as easy as it would first seem to be. My question to the community is, does anyone have best practices techniques that address the multiple FPGA target problem? Is there a good way to write your code to encourage multiple FPGA development? Also, is there a good way to construct your directory structure within a code repository?

Reply to
Erik Anderson
Loading thread data ...

Try to make an architecturally independent wrapper that has internal implementations for each target device. As far as directory structure, I like the method commonly used for embedded OSes of making a clear division between device independent and device dependent code. The rest of the structure depends heavily on the complexity and structure of the project but I tend to create a folder for each high-level function.

---Matthew Hicks

Reply to
Matthew Hicks

The top synthesis entity would instance the rtl entities and unbound netlist components. The top simulation UUT would instance the same rtl entities and sim models of the device netlists.

Minimize or eliminate the use of device netlists. If the netlists differ between brands, one or the other will need wrapper logic to make up the difference.

I don't think that matters much as long as it is simple and doesn't change. Synthesis is controlled by a file list anyway. Simulation is controlled by a makefile or script. The important thing is that everyone commits changes and someone runs a daily sim and synth build that starts from scratch.

-- Mike Treseler

Reply to
Mike Treseler

I would have to agree completely with Matthew.

I have a project which spans both Xilinx and Altera, and a number of different target platforms of each! I've had moderate success by doing exactly as Matthew descibes...

The common code is situated in the main code trunk.

I have device-dependent implementations in a per-device directory (and PLL/DCM is exactly one example of this), (eg. Cyclone II, Spartan III), but wrapped with a high-level device-independent wrapper.

Similarly, I have a target platform independent "top level" design which is wrapped again by target-dependent code in per-target directories (eg. DE1, DE2, RC-10) to form the top level of each project build.

FWIW I also have re-usable "modules" at a lower level to further complicate matters, but I won't confuse the issue here.

It's taken a bit of time and a lot of maintenance to get to this point as the project has evolved, adding platforms and devices, but I think in your case there's less build options so it should pull together with minimal effort.

I also wrote a Pearl script to elaborate and/or synthesise the entire code tree (using wildcards etc) so at any point I can quickly see what I may have "broken" with my last set of changes...

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
Reply to
Mark McDougall

I forgot to mention that I like to make use of Verilog's pre-processor, when I can, and as Mark mentioned, a script/program that generates code with specific parameters based on a template also works in certain situations.

---Matthew Hicks

Reply to
Matthew Hicks

specific

You can also use cpp as a preprocessor.

It helps to be good with makefiles and/or may not fit your style if you like the big green button on the GUI.

--
These are my opinions, not necessarily my employer's.  I hate spam.
Reply to
Hal Murray

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.