Return to Answer

I find myself in a similar situation, Ironstein. In my application I need to support Spartan-6 FPGAs (requiring use of XST) and also Artix-7 FPGAs (requiring Vivado in some cases, and XST or Vivado with other models). I’ve become facile with the memory and clock management tiles.

I agree with your assessment that using IPcores is easiest, but then from a project management standpoint I find it can become tricky to manage as there are so many files which need to be at the correct location 'just so'. I prefer to only use IPcores to instantiate distributed memory elements.

I am a bit wary of inferred designs in general as the slightest change may 'break' the DSP architecture, or some of the subtleties of how registers are allocated as Alex.Forencich pointed out.

I prefer to have explicit control of precisely what is going on, and so I am on the arduous learning curve to understanding the DSP48A1 block, and the related macro blocks: ADDMACC_MACRO, ADDSUB_MACRO, COUNTER_LOAD_MACRO, MULT_MACRO, and MACC_MACRO. These macros address common functions which can get you started without having to know all of the complexity of the full DSP48A1 primitive of the Spartan-6 family.

You can find VHDL/Verilog templates for the DSP48A1 primitive and these macros in the UG615 user guide as has been suggested. However, these templates are long enough that I prefer to make use of the Language Templates feature in XST to more directly copy/paste them into my designs. That's accessed via the "Edit > Language Templates… > VHDL || Verilog > Device Macro Instantiation" (for macros) or "Edit > Language Templates… > VHDL || Verilog > Device Macro Primitives" (for the primitive modules). You then select the FPGA family and DSP, and you're all set. Since my designs also span the Spartan-6 / Artix-7 families that are supported by XST, I find the Language Templates feature to be quite handy.

I find myself in a similar situation, Ironstein. In my application I need to support Spartan-6 FPGAs (requiring use of XST) and also Artix-7 FPGAs (requiring Vivado in some cases, and XST or Vivado with other models). I’ve become facile with the memory and clock management tiles.

I agree with your assessment that using IPcores is easiest, but then from a project management standpoint I find it can become tricky to manage as there are so many files which need to be at the correct location 'just so'. I prefer to only use IPcores to instantiate distributed memory elements.

I am a bit wary of inferred designs in general as the slightest change may 'break' the DSP architecture, or some of the subtleties of how registers are allocated as Alex.Forencich pointed out.

I prefer to have explicit control of precisely what is going on, and so I am on the arduous learning curve to understanding the DSP48A1 block, and the related macro blocks: ADDMACC_MACRO, ADDSUB_MACRO, COUNTER_LOAD_MACRO, MULT_MACRO, and MACC_MACRO. These macros address common functions which can get you started without having to know all of the complexity of the full DSP48A1 primitive of the Spartan-6 family.

You can find VHDL/Verilog templates for the DSP48A1 primitive and these macros in the UG615 user guide as has been suggested. However, these templates are long enough that I prefer to make use of the Language Templates feature in XST to more directly copy/paste them into my designs. That's accessed via "Edit > Language Templates… > VHDL || Verilog > Device Macro Instantiation" (for macros) or "Edit > Language Templates… > VHDL || Verilog > Device Macro Primitives" (for the primitive modules). You then select the FPGA family and DSP, and you're all set. Since my designs also span the Spartan-6 / Artix-7 families that are supported by XST, I find the Language Templates feature to be quite handy.

I find myself in a similar situation, Ironstein. In my application I need to support Spartan-6 FPGAs (requiring use of XST) and also Artix-7 FPGAs (requiring Vivado in some cases, and XST or Vivado with other models). I’ve become facile with the memory and clock management tiles.

I agree with your assessment that using IPcores is easiest, but then from a project management standpoint I find it can become tricky to manage as there are so many files which need to be at the correct location 'just so'. I prefer to only use IPcores to instantiate distributed memory elements.

I am a bit wary of inferred designs in general as the slightest change may 'break' the DSP architecture, or some of the subtleties of how registers are allocated as Alex.Forencich pointed out.

I prefer to have explicit control of precisely what is going on, and so I am on the arduous learning curve to understanding the DSP48A1 block, and the related macro blocks: ADDMACC_MACRO, ADDSUB_MACRO, COUNTER_LOAD_MACRO, MULT_MACRO, and MACC_MACRO. These macros address common functions which can get you started without having to know all of the complexity of the full DSP48A1 primitive of the Spartan-6 family.

You can find VHDL/Verilog templates DSP48A1 primitive and these macros in the UG615 user guide as has been suggested. However, these templates are long enough that I prefer to make use of the Language Templates feature in XST to more directly copy/paste them into my designs. That's accessed via the "Edit > Language Templates… > VHDL || Verilog > Device Macro Instantiation" (for macros) or "Edit > Language Templates… > VHDL || Verilog > Device Macro Primitives" (for the primitive modules). You then select the FPGA family and DSP, and you're all set. Since my designs also span the Spartan-6 / Artix-7 families that are supported by XST, I find the Language Templates feature to be quite handy.

As I get further along in my project, which is non-commercial in nature and related to mathematics, I'll post public domain source code to GitHub to which will demonstrate the use of the DSP48A1 to perform vector and matrix addition, subtraction, and various forms of multiplication.

I find myself in a similar situation, Ironstein. In my application I need to support Spartan-6 FPGAs (requiring use of XST) and also Artix-7 FPGAs (requiring Vivado in some cases, and XST or Vivado with other models). I’ve become facile with the memory and clock management tiles.

I agree with your assessment that using IPcores is easiest, but then from a project management standpoint I find it can become tricky to manage as there are so many files which need to be at the correct location 'just so'. I prefer to only use IPcores to instantiate distributed memory elements.

I am a bit wary of inferred designs in general as the slightest change may 'break' the DSP architecture, or some of the subtleties of how registers are allocated as Alex.Forencich pointed out.

I prefer to have explicit control of precisely what is going on, and so I am on the arduous learning curve to understanding the DSP48A1 block, and the related macro blocks: ADDMACC_MACRO, ADDSUB_MACRO, COUNTER_LOAD_MACRO, MULT_MACRO, and MACC_MACRO. These macros address common functions which can get you started without having to know all of the complexity of the full DSP48A1 primitive of the Spartan-6 family.

You can find VHDL/Verilog templates for the DSP48A1 primitive and these macros in the UG615 user guide as has been suggested. However, these templates are long enough that I prefer to make use of the Language Templates feature in XST to more directly copy/paste them into my designs. That's accessed via the "Edit > Language Templates… > VHDL || Verilog > Device Macro Instantiation" (for macros) or "Edit > Language Templates… > VHDL || Verilog > Device Macro Primitives" (for the primitive modules). You then select the FPGA family and DSP, and you're all set. Since my designs also span the Spartan-6 / Artix-7 families that are supported by XST, I find the Language Templates feature to be quite handy.

I find myself in a similar situation, Ironstein. In my application I need to support Spartan-6 FPGAs (requiring use of XST) and also Artix-7 FPGAs (requiring Vivado in some cases, and XST or Vivado with other models). I’ve become facile with the memory and clock management tiles.

I agree with your assessment that using IPcores is easiest, but then from a project management standpoint becomes tricky as there are so many files which need to be at the correct location 'just so'.

I am a bit wary of inferred designs in general as the slightest change may 'break' the DSP architecture, or some of the subtleties of how registers are allocated as Alex.Forencich pointed out.

I prefer to have explicit control of precisely what takes place, and so I am on the arduous learning curve to understanding the DSP48A1 block in Verlog from the bottom-up, beginning with simple implementation of an 18-bit adder/subtractor producing a 19-bit result. This could of course easily be implemented in fabric using the '+' and '-' operators, but I am deliberately 'wasting' DSP48A1 blocks as a simple first step to using the DSP48A1 block. For computing dot products of integer vectors, or matrix multiplication, I’ll then move on to simple state machines which will be able to compute the results sequentially or across multiple DSP48A blocks.

If I get it figured out, I’ll post some Verilog source code to GitHub since there is no commercial intent in what I'm doing, and so I could poke it all out into the public domain.

I find myself in a similar situation, Ironstein. In my application I need to support Spartan-6 FPGAs (requiring use of XST) and also Artix-7 FPGAs (requiring Vivado in some cases, and XST or Vivado with other models). I’ve become facile with the memory and clock management tiles.

I agree with your assessment that using IPcores is easiest, but then from a project management standpoint I find it can become tricky to manage as there are so many files which need to be at the correct location 'just so'. I prefer to only use IPcores to instantiate distributed memory elements.

I am a bit wary of inferred designs in general as the slightest change may 'break' the DSP architecture, or some of the subtleties of how registers are allocated as Alex.Forencich pointed out.

I prefer to have explicit control of precisely what is going on, and so I am on the arduous learning curve to understanding the DSP48A1 block, and the related macro blocks: ADDMACC_MACRO, ADDSUB_MACRO, COUNTER_LOAD_MACRO, MULT_MACRO, and MACC_MACRO. These macros address common functions which can get you started without having to know all of the complexity of the full DSP48A1 primitive of the Spartan-6 family.

You can find VHDL/Verilog templates DSP48A1 primitive and these macros in the UG615 user guide as has been suggested. However, these templates are long enough that I prefer to make use of the Language Templates feature in XST to more directly copy/paste them into my designs. That's accessed via the "Edit > Language Templates… > VHDL || Verilog > Device Macro Instantiation" (for macros) or "Edit > Language Templates… > VHDL || Verilog > Device Macro Primitives" (for the primitive modules). You then select the FPGA family and DSP, and you're all set. Since my designs also span the Spartan-6 / Artix-7 families that are supported by XST, I find the Language Templates feature to be quite handy.

As I get further along in my project, which is non-commercial in nature and related to mathematics, I'll post public domain source code to GitHub to which will demonstrate the use of the DSP48A1 to perform vector and matrix addition, subtraction, and various forms of multiplication.