Tips And Tricks

FPGASynth.TipsAndTricks History

Hide minor edits - Show changes to markup

March 07, 2009, at 10:21 PM by 98.119.118.140 -
Changed line 31 from:

If you are new to Verilog (or VHDL), you will probably not be familiar with the way the synthesis process infers the logic you describe. This can be frustrating because you will often not get error messages nor will the warnings necessarily mean much to you. IMO, It is worthwhile spending time looking at the design templates in WebPACK ISE. They can be accessed with the lightbulb icon in the toolbar or in the edit menu "Language Templates". Inside are found examples of common structures. These are divided into functional categories such as RAM & ROM, flipflops, multiplexors, etc. If you are trying to infer something, but synthesis is "missing" what you want, then a look at the language templates can tell you what is missing or malformed in your code. I use the language templates regularly. All it takes is something that looks rather innocent to prevent synthesis from inferring proper logic. For example, if you are trying to infer a single port block RAM, you can do a read and a write, but in only one state for each of those operations. Looking at the language template for a single port block RAM shows how this is done in a very simple example that describes only the RAM. You can copy and paste this structure as the basis for your RAM need if you like. Trying to read the RAM from 3 different states does not allow the use of a block RAM and ISE will try to use flipflops (LOTS of them) instead. The first time I saw the warning for this, I really didn't know what it was trying to tell me, but I could see that it wasn't doing what I wanted. To make that kind of thing (reading the RAM from 3 different states) work correctly, you need to follow the language template to make sure the RAM is properly inferred and then use other address substitution and storage techniques to get the same result.\\

to:

If you are new to Verilog (or VHDL), you will probably not be familiar with the way the synthesis process infers the logic you describe. This can be frustrating because you will often not get error messages nor will the warnings necessarily mean much to you. IMO, It is worthwhile spending time looking at the design templates in WebPACK ISE. They can be accessed with the lightbulb icon in the toolbar or in the edit menu "Language Templates". Inside are found examples of common structures. These are divided into functional categories such as RAM & ROM, flipflops, multiplexors, etc. If you are trying to infer something, but synthesis is "missing" what you want, then a look at the language templates can tell you what is missing or malformed in your code. I use the language templates regularly. All it takes is something that looks rather innocent to prevent synthesis from inferring proper logic. For example, if you are trying to infer a single port block RAM, you can do a read and a write, but in only one state for each of those operations. Looking at the language template for a single port block RAM shows how this is done in a very simple example that describes only the RAM. You can copy and paste this structure as the basis for your RAM need if you like. Trying to read the RAM from 3 different states does not allow the use of a block RAM and ISE will try to use flipflops (LOTS of them) instead. The first time I saw the warning for this, I really didn't know what it was trying to tell me, but I could see that it wasn't doing what I wanted. To make that kind of thing (reading the RAM from 3 different states) work correctly, you need to follow the language template to make sure the RAM is properly inferred and then use other address substitution and storage or cache techniques to get the same result.\\

November 11, 2008, at 03:47 PM by 98.119.9.157 -
Changed line 31 from:

If you are new to Verilog (or VHDL), you will probably not be familiar with the way the synthesis process infers the logic you describe. This can be frustrating because you will often not get error messages nor will the warnings necessarily mean much to you. IMO, It is worthwhile spending time looking at the design templates in WebPACK ISE. They can be accessed with the lightbulb icon in the toolbar or in the edit menu "Language Templates". Inside are found examples of common structures. These are divided into functional categories such as RAM & ROM, flipflops, multiplexors, etc. If you are trying to infer something, but synthesis is "missing" what you want, then a look at the language templates can tell you what is missing or malformed in your code. I use the language templates regularly. All it takes is something that looks rather innocent to prevent synthesis from inferring proper logic. For example, if you are trying to infer a single port block RAM, you can do a read and a write, but in only one state for each of those operations. Looking at the language template for a single port block RAM shows how this is done in a very simple example that describes only the RAM. You can copy and paste this structure as the basis for your RAM need if you like. Trying to read the RAM from 3 different states does not allow the use of a block RAM and ISE will try to use flipflops (LOTS of them) instead. The first time I saw the warning for this, I really didn't know what it was trying to tell me, but I could see that it wasn't doing what I wanted. To make that kind of thing (reading the RAM from 3 different states) work correctly, you need to follow the language template to make sure the RAM is properly inferred and then use other address substitution and storage techniques to get the same result\\

to:

If you are new to Verilog (or VHDL), you will probably not be familiar with the way the synthesis process infers the logic you describe. This can be frustrating because you will often not get error messages nor will the warnings necessarily mean much to you. IMO, It is worthwhile spending time looking at the design templates in WebPACK ISE. They can be accessed with the lightbulb icon in the toolbar or in the edit menu "Language Templates". Inside are found examples of common structures. These are divided into functional categories such as RAM & ROM, flipflops, multiplexors, etc. If you are trying to infer something, but synthesis is "missing" what you want, then a look at the language templates can tell you what is missing or malformed in your code. I use the language templates regularly. All it takes is something that looks rather innocent to prevent synthesis from inferring proper logic. For example, if you are trying to infer a single port block RAM, you can do a read and a write, but in only one state for each of those operations. Looking at the language template for a single port block RAM shows how this is done in a very simple example that describes only the RAM. You can copy and paste this structure as the basis for your RAM need if you like. Trying to read the RAM from 3 different states does not allow the use of a block RAM and ISE will try to use flipflops (LOTS of them) instead. The first time I saw the warning for this, I really didn't know what it was trying to tell me, but I could see that it wasn't doing what I wanted. To make that kind of thing (reading the RAM from 3 different states) work correctly, you need to follow the language template to make sure the RAM is properly inferred and then use other address substitution and storage techniques to get the same result.\\

November 11, 2008, at 03:46 PM by 98.119.9.157 -
Added lines 28-31:

(Scott Gravenhorst)

  1. Language Templates
    If you are new to Verilog (or VHDL), you will probably not be familiar with the way the synthesis process infers the logic you describe. This can be frustrating because you will often not get error messages nor will the warnings necessarily mean much to you. IMO, It is worthwhile spending time looking at the design templates in WebPACK ISE. They can be accessed with the lightbulb icon in the toolbar or in the edit menu "Language Templates". Inside are found examples of common structures. These are divided into functional categories such as RAM & ROM, flipflops, multiplexors, etc. If you are trying to infer something, but synthesis is "missing" what you want, then a look at the language templates can tell you what is missing or malformed in your code. I use the language templates regularly. All it takes is something that looks rather innocent to prevent synthesis from inferring proper logic. For example, if you are trying to infer a single port block RAM, you can do a read and a write, but in only one state for each of those operations. Looking at the language template for a single port block RAM shows how this is done in a very simple example that describes only the RAM. You can copy and paste this structure as the basis for your RAM need if you like. Trying to read the RAM from 3 different states does not allow the use of a block RAM and ISE will try to use flipflops (LOTS of them) instead. The first time I saw the warning for this, I really didn't know what it was trying to tell me, but I could see that it wasn't doing what I wanted. To make that kind of thing (reading the RAM from 3 different states) work correctly, you need to follow the language template to make sure the RAM is properly inferred and then use other address substitution and storage techniques to get the same result\\
Deleted lines 32-35:
  1. Language Templates
    If you are new to Verilog (or VHDL), you will probably not be familiar with the way the synthesis process infers the logic you describe. This can be frustrating because you will often not get error messages nor will the warnings necessarily mean much to you. IMO, It is worthwhile spending time looking at the design templates in WebPACK ISE. They can be accessed with the lightbulb icon in the toolbar or in the edit menu "Language Templates". Inside are found examples of common structures. These are divided into functional categories such as RAM & ROM, flipflops, multiplexors, etc. If you are trying to infer something, but synthesis is "missing" what you want, then a look at the language templates can tell you what is missing or malformed in your code. I use the language templates regularly. All it takes is something that looks rather innocent to prevent synthesis from inferring proper logic. For example, if you are trying to infer a single port block RAM, you can do a read and a write, but in only one state for each of those operations. Looking at the language template for a single port block RAM shows how this is done in a very simple example that describes only the RAM. You can copy and paste this structure as the basis for your RAM need if you like. Trying to read the RAM from 3 different states does not allow the use of a block RAM and ISE will try to use flipflops (LOTS of them) instead. The first time I saw the warning for this, I really didn't know what it was trying to tell me, but I could see that it wasn't doing what I wanted. To make that kind of thing (reading the RAM from 3 different states) work correctly, you need to follow the language template to make sure the RAM is properly inferred and then use other address substitution and storage techniques to get the same result
    (Scott Gravenhorst)\\
November 11, 2008, at 03:45 PM by 98.119.9.157 -
Changed line 31 from:

If you are new to Verilog (or VHDL), you will probably not be familiar with the way the synthesis process infers the logic you describe. This can be frustrating because you will often not get error messages nor will the warnings necessarily mean much to you. IMO, It is worthwhile spending time looking at the design templates in WebPACK ISE. They can be accessed with the lightbulb icon in the toolbar or in the edit menu "Language Templates". Inside are found examples of common structures. These are divided into functional categories such as RAM & ROM, flipflops, multiplexors, etc. If you are trying to infer something, but synthesis is "missing" what you want, then a look at the language templates can tell you what is missing or malformed in your code. I use the language templates regularly. All it takes is something that looks rather innocent to prevent synthesis from inferring proper logic. For example, if you are trying to infer a single port block RAM, you can do a read and a write, but in only one state for each of those operations. Looking at the language template for a single port block RAM shows how this is done in a very simple example that describes only the RAM. You can copy and paste this structure as the basis for your RAM need if you like. Trying to read the RAM from 3 different states does not allow the use of a block RAM and ISE will try to use flipflops (LOTS of them) instead. The first time I saw the warning for this, I really didn't know what it was trying to tell me, but I could see that it wasn't doing what I wanted. To make that kind of thing (reading the RAM from 3 different states) work correctly, you need to follow the language template to make sure the RAM is properly inferred and then use other address substition and storage techniques to get the same result\\

to:

If you are new to Verilog (or VHDL), you will probably not be familiar with the way the synthesis process infers the logic you describe. This can be frustrating because you will often not get error messages nor will the warnings necessarily mean much to you. IMO, It is worthwhile spending time looking at the design templates in WebPACK ISE. They can be accessed with the lightbulb icon in the toolbar or in the edit menu "Language Templates". Inside are found examples of common structures. These are divided into functional categories such as RAM & ROM, flipflops, multiplexors, etc. If you are trying to infer something, but synthesis is "missing" what you want, then a look at the language templates can tell you what is missing or malformed in your code. I use the language templates regularly. All it takes is something that looks rather innocent to prevent synthesis from inferring proper logic. For example, if you are trying to infer a single port block RAM, you can do a read and a write, but in only one state for each of those operations. Looking at the language template for a single port block RAM shows how this is done in a very simple example that describes only the RAM. You can copy and paste this structure as the basis for your RAM need if you like. Trying to read the RAM from 3 different states does not allow the use of a block RAM and ISE will try to use flipflops (LOTS of them) instead. The first time I saw the warning for this, I really didn't know what it was trying to tell me, but I could see that it wasn't doing what I wanted. To make that kind of thing (reading the RAM from 3 different states) work correctly, you need to follow the language template to make sure the RAM is properly inferred and then use other address substitution and storage techniques to get the same result\\

November 11, 2008, at 03:44 PM by 98.119.9.157 -
Changed line 31 from:

If you are new to Verilog (or VHDL), you will probably not be familiar with the way the synthesis process infers the logic you describe. This can be frustrating because you will often not get error messages nor will the warnings necessarily mean much to you. IMO, It is worthwhile spending time looking at the design templates in WebPACK ISE. They can be accessed with the lightbulb icon in the toolbar or in the edit menu "Language Templates". Inside are found examples of common structures. These are divided into functional categories such as RAM & ROM, flipflops, multiplexors, etc. If you are trying to infer something, but synthesis is "missing" what you want, then a look at the language templates can tell you what is missing or malformed in your code. I use the language templates regularly. All it takes is something that looks rather innocent to prevent synthesis from inferring proper logic. For example, if you are trying to infer a single port block RAM, you can do a read and a write, but in only one state for each of those operations. Trying to read the RAM from 3 different states does not allow the use of a block RAM and ISE will try to use flipflops (LOTS of them) instead. The first time I saw the warning for this, I really didn't know what it was trying to tell me, but I could see that it wasn't doing what I wanted. To make that kind of thing (reading the RAM from 3 different states) work correctly, you need to follow the language template to make sure the RAM is properly inferred and then use other address substition and storage techniques to get the same result\\

to:

If you are new to Verilog (or VHDL), you will probably not be familiar with the way the synthesis process infers the logic you describe. This can be frustrating because you will often not get error messages nor will the warnings necessarily mean much to you. IMO, It is worthwhile spending time looking at the design templates in WebPACK ISE. They can be accessed with the lightbulb icon in the toolbar or in the edit menu "Language Templates". Inside are found examples of common structures. These are divided into functional categories such as RAM & ROM, flipflops, multiplexors, etc. If you are trying to infer something, but synthesis is "missing" what you want, then a look at the language templates can tell you what is missing or malformed in your code. I use the language templates regularly. All it takes is something that looks rather innocent to prevent synthesis from inferring proper logic. For example, if you are trying to infer a single port block RAM, you can do a read and a write, but in only one state for each of those operations. Looking at the language template for a single port block RAM shows how this is done in a very simple example that describes only the RAM. You can copy and paste this structure as the basis for your RAM need if you like. Trying to read the RAM from 3 different states does not allow the use of a block RAM and ISE will try to use flipflops (LOTS of them) instead. The first time I saw the warning for this, I really didn't know what it was trying to tell me, but I could see that it wasn't doing what I wanted. To make that kind of thing (reading the RAM from 3 different states) work correctly, you need to follow the language template to make sure the RAM is properly inferred and then use other address substition and storage techniques to get the same result\\

November 11, 2008, at 03:40 PM by 98.119.9.157 -
Changed line 31 from:

If you are new to Verilog (or VHDL), you will probably not be familiar with the way the synthesis process infers the logic you describe. This can be frustrating because you will often not get error messages nor will the warnings necessarily mean much to you. IMO, It is worthwhile spending time looking at the design templates in WebPACK ISE. They can be accessed with the lightbulb icon in the toolbar or in the edit menu "Language Templates". Inside are found examples of common structures. These are divided into functional categories such as RAM & ROM, flipflops, multiplexors, etc. If you are trying to infer something, but synthesis is "missing" what you want, then a look at the language templates can tell you what is missing or malformed in your code. I use the language templates regularly. All it takes is something that looks rather innocent to prevent synthesis from inferring proper logic. For example, if you are trying to infer a single port block RAM, you can do a read and a write, but in only one state for each of those operations. Trying to read the RAM from 3 different states does not allow the use of a block RAM and ISE will try to use flipflops (LOTS of them) instead. To make that kind of thing work correctly, you need to follow the language template to make sure the RAM is properly inferred and then use other address substition and storage techniques to get the same result\\

to:

If you are new to Verilog (or VHDL), you will probably not be familiar with the way the synthesis process infers the logic you describe. This can be frustrating because you will often not get error messages nor will the warnings necessarily mean much to you. IMO, It is worthwhile spending time looking at the design templates in WebPACK ISE. They can be accessed with the lightbulb icon in the toolbar or in the edit menu "Language Templates". Inside are found examples of common structures. These are divided into functional categories such as RAM & ROM, flipflops, multiplexors, etc. If you are trying to infer something, but synthesis is "missing" what you want, then a look at the language templates can tell you what is missing or malformed in your code. I use the language templates regularly. All it takes is something that looks rather innocent to prevent synthesis from inferring proper logic. For example, if you are trying to infer a single port block RAM, you can do a read and a write, but in only one state for each of those operations. Trying to read the RAM from 3 different states does not allow the use of a block RAM and ISE will try to use flipflops (LOTS of them) instead. The first time I saw the warning for this, I really didn't know what it was trying to tell me, but I could see that it wasn't doing what I wanted. To make that kind of thing (reading the RAM from 3 different states) work correctly, you need to follow the language template to make sure the RAM is properly inferred and then use other address substition and storage techniques to get the same result\\

November 11, 2008, at 03:37 PM by 98.119.9.157 -
Added lines 29-32:
  1. Language Templates
    If you are new to Verilog (or VHDL), you will probably not be familiar with the way the synthesis process infers the logic you describe. This can be frustrating because you will often not get error messages nor will the warnings necessarily mean much to you. IMO, It is worthwhile spending time looking at the design templates in WebPACK ISE. They can be accessed with the lightbulb icon in the toolbar or in the edit menu "Language Templates". Inside are found examples of common structures. These are divided into functional categories such as RAM & ROM, flipflops, multiplexors, etc. If you are trying to infer something, but synthesis is "missing" what you want, then a look at the language templates can tell you what is missing or malformed in your code. I use the language templates regularly. All it takes is something that looks rather innocent to prevent synthesis from inferring proper logic. For example, if you are trying to infer a single port block RAM, you can do a read and a write, but in only one state for each of those operations. Trying to read the RAM from 3 different states does not allow the use of a block RAM and ISE will try to use flipflops (LOTS of them) instead. To make that kind of thing work correctly, you need to follow the language template to make sure the RAM is properly inferred and then use other address substition and storage techniques to get the same result
    (Scott Gravenhorst)\\
November 09, 2008, at 03:37 PM by 98.119.9.157 -
Changed line 25 from:

ISE is somewhat surprising (to me) in the way it assigns "error" or "warning" status to possibly problematic code. IMO, some things that are considered warnings ought to be errors. For example, you will receive a warning if a state machine contains states which can never be reached.\\

to:

ISE is somewhat surprising (to me) in the way it assigns "error" or "warning" status to possibly problematic code. IMO, some things that are considered warnings ought to be errors. For example, you will receive a warning if a state machine contains states which can never be reached. If you are testing something, I suppose that's OK because your intention may be to not have these states active, but if you're compiling for actual use and not testing, it seems that something like this would get lost in the ocean of "normal" warnings one always gets, especially in a larger design.\\

November 09, 2008, at 03:34 PM by 98.119.9.157 -
Added lines 24-27:


ISE is somewhat surprising (to me) in the way it assigns "error" or "warning" status to possibly problematic code. IMO, some things that are considered warnings ought to be errors. For example, you will receive a warning if a state machine contains states which can never be reached.

ISE has compiled designs I've created that use more resources than are available in the device. I noticed this with a recent project that actually used more block RAMs and multipliers (combined) than the device had, yet there wasn't even a warning. So make sure you know how to count...\\

November 07, 2008, at 02:13 AM by 98.119.9.157 -
Changed line 21 from:

That said, when my design is not sane, i.e., while I'm troubleshooting it, ISE may do some impolite things. It can crash, but remain running and the crashed instance can interfere with a new instance. The only way to tell if that is happening is if you use the task manager to see if a process with image name of _pn.exe exists. If there are two of them, you must close the one you just opened and then kill the other one (there isn't a GUI presentation after it crashes). Sometimes, even after correcting bad code, odd things may happen, but you may have already set the conditions for odd behavior with previous code compiles. Things happen that don't make sense. I've found that if I'm not at fault (insane code), sometimes Project -> Cleanup Project Files helps. Sometime, however restarting that application and making sure all instances of it are gone before invoking again. Rarely, but still notably, occasionally a PC hardware restart seems to fix it...\\

to:

That said, when my design is not sane, i.e., while I'm troubleshooting it, ISE may do some impolite things. It can crash, but remain running and the crashed instance can interfere with a new instance. The only way to tell if that is happening is if you use the task manager to see if a process with image name of _pn.exe exists. If there are two of them, you must close the one you just opened and then kill the other one (there isn't a GUI presentation after it crashes). Sometimes, even after correcting bad code, odd things may happen because you may have already set the conditions for odd behavior with previous code compiles. Things happen that don't make sense. I've found that if I'm not at fault (insane code), sometimes Project -> Cleanup Project Files helps. Sometime, however restarting that application and making sure all instances of it are gone before invoking again. Rarely, but still notably, occasionally a PC hardware restart seems to fix it...\\

November 07, 2008, at 02:11 AM by 98.119.9.157 -
Changed line 21 from:

That said, when my design is not sane, i.e., while I'm troubleshooting it, ISE may do some impolite things. It can crash, but remain running and the crashed instance can interfere with a new instance. The only way to tell if that is happening is if you use the task manager with image name of _pn.exe. If there are two, close the one you just opened and then kill the other one (there isn't a GUI presentation after it crashes). Sometimes, even after correcting bad code, odd things may happen, but you may have already set the conditions for odd behavior with previous code compiles. Things happen that don't make sense. I've found that if I'm not at fault (insane code), sometimes Project -> Cleanup Project Files helps. Sometime, however restarting that application and making sure all instances of it are gone before invoking again. Rarely, but still notably, occasionally a PC hardware restart seems to fix it...\\

to:

That said, when my design is not sane, i.e., while I'm troubleshooting it, ISE may do some impolite things. It can crash, but remain running and the crashed instance can interfere with a new instance. The only way to tell if that is happening is if you use the task manager to see if a process with image name of _pn.exe exists. If there are two of them, you must close the one you just opened and then kill the other one (there isn't a GUI presentation after it crashes). Sometimes, even after correcting bad code, odd things may happen, but you may have already set the conditions for odd behavior with previous code compiles. Things happen that don't make sense. I've found that if I'm not at fault (insane code), sometimes Project -> Cleanup Project Files helps. Sometime, however restarting that application and making sure all instances of it are gone before invoking again. Rarely, but still notably, occasionally a PC hardware restart seems to fix it...\\

November 07, 2008, at 02:09 AM by 98.119.9.157 -
Changed line 20 from:
to:

\\

Changed line 22 from:
to:

\\

November 07, 2008, at 02:08 AM by 98.119.9.157 -
Changed lines 19-24 from:

First, let me say that I have found WebPACK ISE (for Windows) to be extremely useful. When my design is "sane", ISE has created reliable bit files.

That said, when my design is not sane, i.e., while I'm troubleshooting it, ISE may do some impolite things. It can crash, but remain running and the crashed instance can interfere with a new instance. The only way to tell if that is happening is if you use the task manager with image name of _pn.exe. If there are two, close the one you just opened and then kill the other one (there isn't a GUI presentation after it crashes). Sometimes, even after correcting bad code, odd things may happen, but you may have already set the conditions for odd behavior with previous code compiles. Things happen that don't make sense. I've found that if I'm not at fault (insane code), sometimes Project -> Cleanup Project Files helps. Sometime, however restarting that application and making sure all instances of it are gone before invoking again. Rarely, but still notably, occasionally a PC hardware restart seems to fix it...

I realize how anecdotal that all sounds - because it is. Your milage may vary. (Scott Gravenhorst)

to:

First, let me say that I have found WebPACK ISE (for Windows) to be extremely useful. When my design is "sane", ISE has created reliable bit files.
That said, when my design is not sane, i.e., while I'm troubleshooting it, ISE may do some impolite things. It can crash, but remain running and the crashed instance can interfere with a new instance. The only way to tell if that is happening is if you use the task manager with image name of _pn.exe. If there are two, close the one you just opened and then kill the other one (there isn't a GUI presentation after it crashes). Sometimes, even after correcting bad code, odd things may happen, but you may have already set the conditions for odd behavior with previous code compiles. Things happen that don't make sense. I've found that if I'm not at fault (insane code), sometimes Project -> Cleanup Project Files helps. Sometime, however restarting that application and making sure all instances of it are gone before invoking again. Rarely, but still notably, occasionally a PC hardware restart seems to fix it...
I realize how anecdotal that all sounds - because it is. Your milage may vary.
(Scott Gravenhorst)\\

November 07, 2008, at 02:07 AM by 98.119.9.157 -
Changed line 18 from:
  1. Using WebPACK ISE
to:
  1. Using WebPACK ISE\\
November 07, 2008, at 02:07 AM by 98.119.9.157 -
Added lines 17-24:
  1. Using WebPACK ISE

First, let me say that I have found WebPACK ISE (for Windows) to be extremely useful. When my design is "sane", ISE has created reliable bit files.

That said, when my design is not sane, i.e., while I'm troubleshooting it, ISE may do some impolite things. It can crash, but remain running and the crashed instance can interfere with a new instance. The only way to tell if that is happening is if you use the task manager with image name of _pn.exe. If there are two, close the one you just opened and then kill the other one (there isn't a GUI presentation after it crashes). Sometimes, even after correcting bad code, odd things may happen, but you may have already set the conditions for odd behavior with previous code compiles. Things happen that don't make sense. I've found that if I'm not at fault (insane code), sometimes Project -> Cleanup Project Files helps. Sometime, however restarting that application and making sure all instances of it are gone before invoking again. Rarely, but still notably, occasionally a PC hardware restart seems to fix it...

I realize how anecdotal that all sounds - because it is. Your milage may vary. (Scott Gravenhorst)

August 04, 2008, at 05:32 PM by 71.116.254.78 -
Deleted line 15:

\\

August 04, 2008, at 05:31 PM by 71.116.254.78 -
Changed line 15 from:

See the procedure starting on page 32 of the user guide: ug320.pdf (available from Xilinx).\\

to:

See the procedure starting on page 32 of the user guide: ug230.pdf (available from Xilinx).\\

August 04, 2008, at 05:31 PM by 71.116.254.78 -
Changed line 15 from:

See the procedure starting on page 32 of the ug320.pdf (available from Xilinx).\\

to:

See the procedure starting on page 32 of the user guide: ug320.pdf (available from Xilinx).\\

August 04, 2008, at 05:30 PM by 71.116.254.78 -
Changed lines 1-2 from:

Tips, Tricks and observations

to:

Tips, Tricks and Observations

August 04, 2008, at 05:30 PM by 71.116.254.78 -
Changed line 14 from:
  1. Programming the Platform PROM (Spartan-3E Start Kit)
to:
  1. Programming the Platform PROM (Spartan-3E Start Kit)\\
August 04, 2008, at 05:29 PM by 71.116.254.78 -
Added line 16:

\\

August 04, 2008, at 05:29 PM by 71.116.254.78 -
Changed line 15 from:

See the procedure starting on page 32 of the ug320.pdf (available from Xilinx).

to:

See the procedure starting on page 32 of the ug320.pdf (available from Xilinx).\\

August 04, 2008, at 05:28 PM by 71.116.254.78 -
Changed lines 14-15 from:
to:
  1. Programming the Platform PROM (Spartan-3E Start Kit)

See the procedure starting on page 32 of the ug320.pdf (available from Xilinx).

August 04, 2008, at 05:26 PM by 71.116.254.78 -
Added lines 13-15:
July 29, 2008, at 02:55 PM by 71.189.44.199 -
Changed line 7 from:
  1. You can't put more devices in a UCF then you actually reference in your design. This does mean you can't have one global/common UCF file for all your projects unless you comment out the ones that don't apply to a particular design. \\
to:
  1. You can't put more connections in a UCF then you actually reference in your design. This does mean you can't have one global/common UCF file for all your projects unless you comment out the connections that don't apply to a particular design. \\
July 29, 2008, at 02:53 PM by 71.189.44.199 -
Changed line 7 from:
  1. You can't put more devices in a UCF then you actually reference in your design. This does mean you can't have one global/common UCF file for all your projects. \\
to:
  1. You can't put more devices in a UCF then you actually reference in your design. This does mean you can't have one global/common UCF file for all your projects unless you comment out the ones that don't apply to a particular design. \\
July 09, 2006, at 10:45 AM by Paul Maddox -
Changed lines 8-9 from:

(Scott Gravenhorst)

to:
Changed lines 11-12 from:

A copy of the contents of the CPLD is included here for restoration if necessary - http://fpga.synth.net/beginners/files/original_cpld.jed
(Mike Both)

to:

A copy of the contents of the CPLD is included here for restoration if necessary - xc2c64a_original.jed
(Mike Both)

July 06, 2006, at 06:20 AM by MikeBoth -
Changed line 11 from:

A copy of the contents of the CPLD is included here for restoration if necessary - http://fpga.synth.net/beginners/files/original_cpld.jed

to:

A copy of the contents of the CPLD is included here for restoration if necessary - http://fpga.synth.net/beginners/files/original_cpld.jed\\

July 06, 2006, at 06:14 AM by MikeBoth -
Changed line 11 from:

A copy of the contents of the CPLD is included here for restoration if necessary - original_cpld.zip\\

to:

A copy of the contents of the CPLD is included here for restoration if necessary - http://fpga.synth.net/beginners/files/original_cpld.jed

July 05, 2006, at 10:36 PM by MikeBoth -
Changed lines 10-13 from:
  1. The FPGA on the Spartan 3E board can be configured a number of ways, the precise method being determined by settings of header J30 (ref UG p26). The default / as received method is for the FPGA to be configured from (i.e. programmed by) the 4Mbit Xilinix XCF04S serial Flash PROM in 'Master Serial mode' (all three jumpers for header J30 present). Note that the on-board XC2C64A CPLD *must* have the original program loaded for the FPGA to be configured in Master Serial mode, as the CPLD is used in a 'helper' role to (as the UG states, p125) "...help reduce the number of jumpers on the board and simplifies the interaction of all the possible FPGA configuration memory sources."

A copy of the contents of the CPLD is included here for restoration if necessary -

to:
  1. The FPGA on the Spartan 3E board can be configured a number of ways, the precise method being determined by settings of header J30 (ref UG p26). The default / as received method is for the FPGA to be configured from (i.e. programmed by) the 4Mbit Xilinix XCF04S serial Flash PROM in 'Master Serial mode' (all three jumpers for header J30 present). Note that the on-board XC2C64A CPLD *must* have the original program loaded for the FPGA to be configured in Master Serial mode, as the CPLD is used in a 'helper' role to (as the UG states, p125) "...help reduce the number of jumpers on the board and simplifies the interaction of all the possible FPGA configuration memory sources."
    A copy of the contents of the CPLD is included here for restoration if necessary - original_cpld.zip\\
July 05, 2006, at 10:32 PM by MikeBoth -
Added lines 11-13:

A copy of the contents of the CPLD is included here for restoration if necessary -

July 03, 2006, at 09:45 PM by MikeBoth -
Changed lines 8-11 from:

(Scott Gravenhorst)

to:

(Scott Gravenhorst)

  1. The FPGA on the Spartan 3E board can be configured a number of ways, the precise method being determined by settings of header J30 (ref UG p26). The default / as received method is for the FPGA to be configured from (i.e. programmed by) the 4Mbit Xilinix XCF04S serial Flash PROM in 'Master Serial mode' (all three jumpers for header J30 present). Note that the on-board XC2C64A CPLD *must* have the original program loaded for the FPGA to be configured in Master Serial mode, as the CPLD is used in a 'helper' role to (as the UG states, p125) "...help reduce the number of jumpers on the board and simplifies the interaction of all the possible FPGA configuration memory sources."
    (Mike Both)
July 03, 2006, at 08:29 PM by MikeBoth -
July 03, 2006, at 08:29 PM by MikeBoth -
Changed line 7 from:
  1. You can't put more devices in a UCF then you actually refference in your design. This does mean you can't have one global/common UCF file for all your projects. \\
to:
  1. You can't put more devices in a UCF then you actually reference in your design. This does mean you can't have one global/common UCF file for all your projects. \\
June 28, 2006, at 09:48 PM by Paul Maddox -
Changed line 7 from:
  1. You can't put more devices/pins in a UCF then you actually refference in your design. This does mean you can't have one global/common UCF file for all your projects. \\
to:
  1. You can't put more devices in a UCF then you actually refference in your design. This does mean you can't have one global/common UCF file for all your projects. \\
June 28, 2006, at 09:47 PM by Paul Maddox -
Changed lines 1-2 from:

Tips, Tricks and observations

to:

Tips, Tricks and observations

June 28, 2006, at 09:47 PM by Paul Maddox -
Changed line 7 from:
  • You can't put more devices/pins in a UCF then you actually refference in your design. This does mean you can't have one global/common UCF file for all your projects. \\
to:
  1. You can't put more devices/pins in a UCF then you actually refference in your design. This does mean you can't have one global/common UCF file for all your projects. \\
June 28, 2006, at 09:46 PM by Paul Maddox -
Changed line 7 from:
  • You can't put more devices/pins in a UCF then you actually refference in your design. This does mean you can't have one global/common UCF file for all your projects. \\
to:
  • You can't put more devices/pins in a UCF then you actually refference in your design. This does mean you can't have one global/common UCF file for all your projects. \\
June 28, 2006, at 09:39 PM by Paul Maddox -
Changed lines 1-3 from:

Tips and Tricks

  • You can't put more devices/pins in a UCF then you actually refference in your design. This does mean you can't have one global/common UCF file for all your projects.
to:

Tips, Tricks and observations

Feel free to suggest any common tips/tricks/observations you make whilst working with WebPACK or your FPGA project.


  • You can't put more devices/pins in a UCF then you actually refference in your design. This does mean you can't have one global/common UCF file for all your projects.
    (Scott Gravenhorst)
June 28, 2006, at 09:37 PM by Paul Maddox -
Added lines 1-3:

Tips and Tricks

  • You can't put more devices/pins in a UCF then you actually refference in your design. This does mean you can't have one global/common UCF file for all your projects.