Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
I am sorry to say this design will not work reliably. I assume that OLDCLK is slower than NEWCLK by at least a factor of 2. I am also assuming that the two clocks are asynchronous to each other. On Fri, 11 Jul 2003 14:24:36 +0200, "Morten Leikvoll" <mleikvol@online.nospam> wrote: >Does anyone see a weakness in this circuit? (inputs,outputs in capital) >What if I put a timing ignore attribute on restrig? >It should create a one clock pulse in the NEWCLK domain when OLDCLK rises. > >----- >signal trig,restrig,delrestrig, > >if(restrig='1') then > trig<='0'; >elsif(OLDCLK'event and OLDCLK='1') then > trig<='1'; >end if; So trig is in the OLDCLK domain. The following is all synchronous in the NEWCLK domain. >if(NEWCLK'event and NEWCLK='1') then > restrig<=trig; The restrig FF D input is comming from the OLDCLK domain, so you will have setup and hold violations. This FF WILL go metastable. This signal can not be used to asynchronously clear a FF, which you are doing on trig. > delrestrig<=restrig; Depending on the cycle time of NEWCLK, the amount of settling time for restrig (going metastable) till it is loaded on the following cycle into delrestrig, the probability of delrestrig also going metastable may be higher than desired. > if(delrestrig='0' and restrig='1') then --Positive edge detector > OUTTRIG='1'; > else > OUTTRIG='0'; > end if Depending on the cycle time of NEWCLK, the amount of settling time for restrig (going metastable) till it is used to create OUTTRIG may not be sufficient to give you a sufficiently reliable OUTTRIG. >end if; >--------- This is a classic metastability problem. I suggest you read the following: http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm and (Crossing a clock domain) http://www.fpga-faq.com/archives/37175.html#37176 http://www.fpga-faq.com/archives/37250.html#37250 http://www.fpga-faq.com/archives/37250.html#37252 <<< especially this one The solution to your requirements is to put a 2 or 3 FF synchronizer in the NEWCLK domain, and use the output to generate your OUTTRIG and restrig signals. Philip Freidin Philip Freidin FliptronicsArticle: 58001
I think I understand what you're saying but I'm not sure it would work in my situation. I understand that if my master clock is much faster than any possible input sample rate, I should be able to perform the necessary calculations on each input sample. However, the output sample rate is also important (this is for a 1-bit sigma-delta modulator). For example, if the audio sample rate is 44.1khz, and I oversample 64 times, the output data rate is 2.8224Mhz. My master clock has to be a multiple of 2.8224Mhz (I think...). Now if I change the audio sample rate to 48khz, and I still oversample 64 times, the output data rate should be 3.072Mhz. This is not a multiple of the previous output data rate. The only solution I see would be to oversample the 48khz signal only 58.8 times, so that the output data rate would be the same for both input rate. I don't think this make any sense practically though. Am I complicating this thing? Are there any other workaround except using the 256Fs clock provided by the CS8416 (see first post)? Thank you very much David > It depends on exactly what you are doing with the data. If you are > processing word samples, then you only need a clock as fast as the > fastest sample rate you expect to see. If you are doing work at a > multiple rate then you need a clock at that multiple rate of your > highest sample rate. > > When a sample comes in, your interface circuit provides an enable for > that clock cycle. The next stage of logic will process the data and > pass the enable on to the next stage. On any clock cycle where there is > no data from the interface, no enable should be provided and the data > and enable are not clocked through to the next stage. > > The only tricky part is generating the enable since that will have to > cross clock domains. But since the sample rate is much slower than the > clock rate, if I understand what you are doing, then you will be passing > one enable pulse every 256 clocks (at the most) and the circuit in the > high speed clock domain will generate how ever many enables are needed > to complete the processing. > > Depending on the exact nature of your processing and clocks, you may > need a double register or possibly a FIFO if the clock rate is close to > the sample rate. > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 58002
Alan Nishioka wrote: > > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > > news:3F0DC966.43F838F6@yahoo.com... > > > When I compile my program I get a warning on the range of these two > > > constants under Quartus 3.0 web edition. I checked some other > > copies of > > > NUMERIC_STD that I have on my hard drive and found them all to be > > the > > > same. What is this about? What are these constants for and why are > > > they defined this way? Should this report as a warning? > > > > > > package body NUMERIC_STD is > > > > > > -- null range array constants > > > > > > constant NAU: UNSIGNED(0 downto 1) := (others => '0'); > > > constant NAS: SIGNED(0 downto 1) := (others => '0'); > > > > > "Alan Fitch" <alan.fitch@doulos.com> wrote in message > news:<belqfe$rna$1$8300dec7@news.demon.co.uk>... > > I personally don't think it should be a warning, as it's quite legal > > to declare null vectors - however I guess it would require more > > careful > > perusal of the standard to be absolutely sure, > > > > The compiler is complaining because of the range (0 downto 1) and 0 is > less than 1, right? Yes, it is a warning because it is most likely that the user goofed up. How many times have you used a NULL vector? I just got an email from Altera that said they would no longer provide this warning when such an issue is found in a library (or something like that). Either way, this is a very small issue. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 58003
Hello Anup, For existing designs, we would suggest you to keep using the Spartan-XL PROM(OTP) or the XC18V(ISP) PROMs. If it's a new design, then use the Platform Flash ISP PROMs. See here for more info on Flash PROMs. Ashok Spam Hater wrote: > If the little XC18V's will do it, the big ones will too. Just ignore > the extra bits. The Spartan will stop clocking when it's done. > > What you're really looking for doesn't exist, and won't. The Spartan > and the SpartanXL are dead parts (in Xilinx's view). > > Sorry, > SH > > On Thu, 10 Jul 2003 12:36:57 +0930, Anup Kumar Raghavan > <> wrote: > > >I need to select a Configuration solution for programming the Spartan XL > >XCS10XL device. I have chosen to use the Master Serial Mode > >configuration using the PROM XC17S10XL, which is OTP. I havent found any > >reference to ISP (EPROM) solutions for the Spartan XL and hence need > >some advice on this. I know there is this device XC18V256PC20C, but > >Xilinx mentions that this is not supported anymore. > > > >Thanks and regards > >AnupArticle: 58004
On Fri, 11 Jul 2003 10:15:33 -0400, rickman wrote: > hamish@cloud.net.au wrote: >> >> lecroy <lecroy7200@chek.com> wrote: >> > If the code were structured, supporting the older devices would not >> > be a problem. >> >> Can you tell us why it's such a hardship to use an older tool version? >> >> Don't say they don't co-exist, because that's not true. > > There are a lot of issues concerning co-compatibility. I have seen > older software that won't run under the newer OS and the newer software > is not supported under the older OS. > > Even those issues aside, it is hard to maintain proficiency on the older > tools since they change the GUI and even the synthesis tool every few > years. This can make it very hard to maintain an older design since > under a newer tool a design can get much larger. But if you try to run > the older tools, they require different tweeks to get a design to run at > all. Of cource this can be dealt with by good documentation of each > design, but often there are a number of little quirks that no one thinks > of putting in the documentation at the time since it is just part of > running the tool at the time. I have been there, done that! Try > getting an answer from FPGA support on a five year old tool! I can see why we've been talking at cross purposes, this is the difference between the perspective of a Windows user and a Linux/Unix user. Windows makes it difficult, and sometimes impossible, to keep multiple copies of an application on a single system. There is likely to be all sorts of registry conflicts as well as search path problems because Windows manipulates it's search paths behind your back. In addition Windows users tend to do everything from a GUI which means that they have to remember how everything works. On *NIX systems the only limit to how many versions of a program you can have is disk space. To switch from one version to another all you have to do is change an environment variable or two and set a path, all of which can be put into a script. We also tend to drive tools from scripts not from GUIs. Scripts can be archived along with the source code and constraint files so you don't have to remember anything. It's for these reasons that ASIC designs are always done on *NIX systems, the only application of Windows systems that I've ever seen in ASIC design environments is to act as X terminals and to do documentation.Article: 58005
Philip Freidin wrote: > > I am sorry to say this design will not work reliably. I assume > that OLDCLK is slower than NEWCLK by at least a factor of 2. > I am also assuming that the two clocks are asynchronous to each > other. Actually, that is not a bad assumption since OLDCLK is really a signal, not a clock. OLDCLK is a poor choice of names perhaps. > On Fri, 11 Jul 2003 14:24:36 +0200, "Morten Leikvoll" <mleikvol@online.nospam> wrote: > >Does anyone see a weakness in this circuit? (inputs,outputs in capital) > >What if I put a timing ignore attribute on restrig? > >It should create a one clock pulse in the NEWCLK domain when OLDCLK rises. > > > >----- > >signal trig,restrig,delrestrig, > > > >if(restrig='1') then > > trig<='0'; > >elsif(OLDCLK'event and OLDCLK='1') then > > trig<='1'; > >end if; > > So trig is in the OLDCLK domain. > > The following is all synchronous in the NEWCLK domain. > > >if(NEWCLK'event and NEWCLK='1') then > > restrig<=trig; > > The restrig FF D input is comming from the OLDCLK domain, so you > will have setup and hold violations. This FF WILL go metastable. > > This signal can not be used to asynchronously clear a FF, which > you are doing on trig. > > > delrestrig<=restrig; > > Depending on the cycle time of NEWCLK, the amount of settling time > for restrig (going metastable) till it is loaded on the following > cycle into delrestrig, the probability of delrestrig also going > metastable may be higher than desired. > > > if(delrestrig='0' and restrig='1') then --Positive edge detector > > OUTTRIG='1'; > > else > > OUTTRIG='0'; > > end if > > Depending on the cycle time of NEWCLK, the amount of settling time > for restrig (going metastable) till it is used to create OUTTRIG > may not be sufficient to give you a sufficiently reliable OUTTRIG. The restrig signal is done poorly in my opinion. You should check out my modified example. It gets around all the metastable issues, I beieve. > >end if; > >--------- > > This is a classic metastability problem. I suggest you read > the following: > > http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm > > and > > (Crossing a clock domain) > > http://www.fpga-faq.com/archives/37175.html#37176 > http://www.fpga-faq.com/archives/37250.html#37250 > http://www.fpga-faq.com/archives/37250.html#37252 <<< especially this one > > The solution to your requirements is to put a 2 or 3 FF synchronizer > in the NEWCLK domain, and use the output to generate your OUTTRIG and > restrig signals. He is generating the OUTTRIG signal correctly. As to the restrig signal, all he needs to do is change the way he uses it in the other clock domain. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 58006
"David" <gretzteam@hotmail.com> schrieb im Newsbeitrag news:BbCPa.21428$Pe2.654126@wagner.videotron.net... > For example, if the audio sample rate is 44.1khz, and I oversample 64 times, > the output data rate is 2.8224Mhz. My master clock has to be a multiple of > 2.8224Mhz (I think...). > Now if I change the audio sample rate to 48khz, and I still oversample 64 > times, the output data rate should be 3.072Mhz. This is not a multiple of > the previous output data rate. The only solution I see would be to > oversample the 48khz signal only 58.8 times, so that the output data rate > would be the same for both input rate. I don't think this make any sense > practically though. > > Am I complicating this thing? Are there any other workaround except using > the 256Fs clock provided by the CS8416 (see first post)? Do a prime factor analysis of the two sample rates and find the smallest common multiple. dumdidum 44100 Hz = 2^2 * 3^2 * 5^2 *7^2 Hz 48000 Hz = 2^7 * 3^1 * 5^3 Hz multiplying this with 64 = 2^6 gives 44100 * 64 = 2^8 *3^2 * 5^2 *7^2 48000 * 64 = 2^13 * 3^1 *5^3 the smallest common multiple is so 2*13 * 3^2 * 5^3 * 7^2 = 451.58 Mhz Huhhh, quite fast, so this simple straight forward approach will most possible not be practical. Nevertheless, you may need some kind of clock alignment /PLL stuff, since the Xtal clock on the FPGA is not phase locked to the incomming datastream, so they will drift away from eah other. So you will possible end up be using the 256 times oversampled clock from the CS8416. -- Regards FalkArticle: 58007
rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F0DC966.43F838F6@yahoo.com>... > When I compile my program I get a warning on the range of these two > constants under Quartus 3.0 web edition. I checked some other copies of > NUMERIC_STD that I have on my hard drive and found them all to be the > same. What is this about? What are these constants for and why are > they defined this way? Should this report as a warning? > > package body NUMERIC_STD is > > -- null range array constants > > constant NAU: UNSIGNED(0 downto 1) := (others => '0'); > constant NAS: SIGNED(0 downto 1) := (others => '0'); > > From my days of C programming, I am uncomfortable with warning > statements. If there are warnings, even if they are not problems, I get > rid of them so that they don't obscure warnings about *real* problems. > > -- > > Rick "rickman" Collins > NAU and NAS are constants that are used to return error conditions in the arithmetic packages, and are deliberately declared to be a NULL range. The warning is there to give information to users about a possible typo -- in the same spirit as the C warning "assignment in conditional expression". It is perfectly legal VHDL, but is quite likely to indicate a user error. Obviously, these warnings are not useful when they occur in the standard package numeric_std.vhd, and they will be not be issued for null ranges in the standard packages in the next release of Quartus (3.1). - Subroto Datta Altera Corp.Article: 58008
It takes more real-estate to get more performance. In most cases, the DDS is
coupled either with a DAC or an ADC, and those devices already have a noise
floor associated with them. With that in mind, there is not much incentive to
throw excess real-estate at reducing the DDS noise much below the noise floor
established by the converter in the system.
Sasa Bremec wrote:
> Hi !
>
> I have a question about DDS. I discovered that most of DDS application in
> SDR use the SFDR factor around 60dBc and frequency resolution around 1 Hz.
> Why is so, and Why don't use SFDR around 120 dBc and freq. resolution about
> 0.02 Hz. Yes I know there is a space trade-off and I wan to know how to
> decide parameters I need for my specific application.
>
> Thanks, Sasa
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 58009
For what it is worth, I'll be presenting that seminar, and at the conference
pricing it is well below the pricing for my 2 day seminar, plus you get to
go to a decent conference on FPGAs. Hope to see ya'll there.
"Richard B. Katz" wrote:
> A seminar on "Digital Signal Processing, Programmable Device
> Architecture, and Military/Aerospace Applications" will be presented at
> the 2003 MAPLD International conference on September 8th, 2003, in
> Washington, D.C.
>
> http://www.klabs.org/richcontent/MAPLDCon03/tutorials/
>
> Abstract
> ========
>
> Digital signal processing has traditionally been done using Von-Neuman
> or Harvard type processors with enhancements such as single cycle
> multiplies. Recent advances in speed, density, and features have made
> Field Programmable Gate Arrays (FPGAs) very attractive for digital
> signal processing applications, particularly when performance
> requirements are beyond the capability of microprocessors.
> Unfortunately, the majority of signal processing work over the last
> quarter century has been implemented as software on computers.
> Consequently, there is currently very little overlap between hardware
> design and DSP expertise. Algorithms developed for software platforms
> are usually very inefficient for direct hardware implementation, and
> without the overlapping areas of expertise, the resulting FPGA
> realization is bound to disappoint.
>
> This seminar helps to bridge the gap between DSP and FPGA design, aiding
> the designer in achieving the performance potential of FPGAs. This
> seminar will first review computer arithmetic and then look in detail at
> efficient FPGA implementations of common DSP elements such as
> multipliers, filters, and mixers. Tradeoffs between clock rate and
> performance will be discussed along with several design examples.
>
> Conference home page: http://klabs.org/mapld03
>
> Additional info: Richard B. Katz, NASA Office of Logic Design
> richard.b.katz@nasa.gov
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 58010
Praveen,
have a look at the multipliers page on my website. I cover several ways
to do multiplication there. The fastest in-the-fabric multipliers in
Xilinx use 2xN partial products combined in an adder tree. The embedded
multiplier blocks aren't constrained by the FPGA LUT structure, so they
use a modified booth design that is appropriate to ASICs, but not to
multipliers done using FPGA LUTs.
praveen wrote:
> Hello,
> I am implementating Fixed point signed multiplication. Is there a
> algorithm to implement it. I have done the usual method of
> multiplication i.e partial products ...shift and add method. But its
> very slow. If you know any algorithm which will faster do mention. Any
> reference will be great. How does the signed multipliers in xilinx
> that fast. what algorithm do they use. I need to first implement in on
> MATLAB and see the result.
>
> waiting for reply
> praveen
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 58011Jared, If you add the LPM_TYPE parameter to your megafunction, that should also allow it to be recognized in the MAX+PLUS II software, even with the other generics appended to the name in the EDIF. The parameter is listed as optional in the documentation but you need it for third-party synthesis. The MAX+PLUS II MegaWizard doesn't add the parameter because it assumes you'll be compiling the function natively in MAX+PLUS II (the Quartus II MegaWizard now adds it automatically, BTW). In MAX+PLUS II Help you should see the syntax for LPM_TYPE; you set it to the string name for your megafunction. Hope that helps! jaz_shnat@hotmail.com (Jared) wrote in message news:<98bc4967.0307082238.2879b984@posting.google.com>... > I'm trying to create a 20-bit pipelined adder using the lpm_add_sub > megafunction, but when I try and compile my project in leonardo it > changes the name in the .edf file from lpm_add_sub to > lpm_add_sub_20_add_no_5 which Altera Max+PLUS does not recognize. In > order for it to place and route correctly, I have to manually change > the name back to lpm_add_sub. Does anybody know if there is a way to > prevent this from happening. I've already tried setting the noopt and > dont_touch attribute in the architecture block.Article: 58012
..:: Gabster ::.. wrote: >Hi, > >I'm made many 2-layer PCB's in the past years, but I'm about to start the >desgin of my first 4-layer PCB. The board is basically a FPGA (Xilinx >Spartan IIE XC2S300 in PQ208 package running at ±12MHz), 3 power supply >regulators, an oscillator block, a PROM and a logic IC. > >In addition to other literature, I read the following document: >http://www.xilinx.com/xapp/xapp623.pdf >but it is rather complicated and not straight foward for a rookie like me in >FPGA design! So here's a few direct questions: > >1) 4-layer, why is it so important? > > It allows you to have wide power and ground planes, which drastically reduces inductance. I have successfully made some boards with 5 V Spartan FPGAs with just 2 layers, but I had to pay a lot of attention to providing wide ground and power nets in a manner that was likely to keep impedance low. Having layers dedicated to power and ground frees up routing area for the signal traces. >2) In what order should I stack the layers (TOP/GND/POWER/BOTTOM or >TOP/POWER/GND/BOTTOM), why? > > For lowest power impedance, either of these are fine. For best shielding, power/signal1/signal2/ground is used in a lot of mil-spec gear. >3) Decoupling caps surroung the FPGA: I figured out I needed one 0.1µF per >power pin (1.8V and 3.3V) + one 10µF per power supply (1.8V and 3.3V). Is >that accurate? Should I do more? What should I avoid? > > That is most likely fine. Especially if Xilinx recommends that, it should be OK. >4) What is the concept surrounding islands on the power plane? What should >that plane look like? What should I avoid? What the hell about it, this >plane is a mystery for me!!! > > Well, you need to carve the power plane regions based on the geometry of the power pins on each net. If you can get it so that a net is a simple rectangle, that's nice, but it often comes out as a very convoluted region. There isn't much you can do about it in some cases. But, it is best to avoid having one net made up of lots of thin fingers, as that raises impedance. Also, (been there, done that) board manufacturers may alter the clearance around holes in the inner layers, causing regions that were connected by ample copper in your Gerber plots to become isolated in the finished board! Not a good situation, then you have to argue whether it is a manufacturing defect or whether your original design violated their manufacturing specs on inner-plane clearance. JonArticle: 58013
Hi, I'm made many 2-layer PCB's in the past years, but I'm about to start the desgin of my first 4-layer PCB. The board is basically a FPGA (Xilinx Spartan IIE XC2S300 in PQ208 package running at ±12MHz), 3 power supply regulators, an oscillator block, a PROM and a logic IC. In addition to other literature, I read the following document: http://www.xilinx.com/xapp/xapp623.pdf but it is rather complicated and not straight foward for a rookie like me in FPGA design! So here's a few direct questions: 1) 4-layer, why is it so important? 2) In what order should I stack the layers (TOP/GND/POWER/BOTTOM or TOP/POWER/GND/BOTTOM), why? 3) Decoupling caps surroung the FPGA: I figured out I needed one 0.1µF per power pin (1.8V and 3.3V) + one 10µF per power supply (1.8V and 3.3V). Is that accurate? Should I do more? What should I avoid? 4) What is the concept surrounding islands on the power plane? What should that plane look like? What should I avoid? What the hell about it, this plane is a mystery for me!!! In order to avoid asking 1000's other questions, I wonder if someone could also direct me toward a complete document talking about PCB design guidelines for PQ package FPGA's. I found that for the BGA packages on xilinx website, but it didn't help me much. Thanks a lot, GabrielArticle: 58014
Power design is one of those things that is full of mysterious incatations and voodoo. That is because even though the science behind it is not hard to understand, it is very difficult to apply and then verify that what you have done works the way you think it will. Basically either your board will work or it won't and you won't have the time to figure out exactly what was wrong. If it fails due to noise you will throw the kitchen sink at it to make sure it works the next time. Not much learning involved there. I think there is a lot that people agree on and much that they don't. Based on everything I have read and my personal experience, your board will not be a tough one to design with quiet power. "..:: Gabster ::.." wrote: > > Hi, > > I'm made many 2-layer PCB's in the past years, but I'm about to start the > desgin of my first 4-layer PCB. The board is basically a FPGA (Xilinx > Spartan IIE XC2S300 in PQ208 package running at ±12MHz), 3 power supply > regulators, an oscillator block, a PROM and a logic IC. I would advise using an isolated region of the ground plane for each switching regulator with a single connection to the rest of the ground plane. They tend to create very large ground currents. Also pay close attention to the design notes for that device. The key to minimizing EMI as well as the voltage spikes is to minimize the area of high current loops. This is a common theme in power supply design and distribution. It may also help to provide an isolated power to the oscillator using a ferrite bead or filter. Many PLLs require this. > In addition to other literature, I read the following document: > http://www.xilinx.com/xapp/xapp623.pdf > but it is rather complicated and not straight foward for a rookie like me in > FPGA design! So here's a few direct questions: I would also recommend that you check with the capacitor manufacturers. I believe AVX has some good notes on this. > 1) 4-layer, why is it so important? The important part is using two layers for the power and ground. This reduces the resistance to nearly zero and provides a well defined impedance for the high frequency noise. The two planes should be very close together (10 mil) to maximize the capacitance and reduce the impedance. > 2) In what order should I stack the layers (TOP/GND/POWER/BOTTOM or > TOP/POWER/GND/BOTTOM), why? I have never heard anyone say one is preferred over the other. I would say pick one based on any logistical issues you may have. > 3) Decoupling caps surroung the FPGA: I figured out I needed one 0.1µF per > power pin (1.8V and 3.3V) + one 10µF per power supply (1.8V and 3.3V). Is > that accurate? Should I do more? What should I avoid? If you can get a cap on each pin you will be doing fine. The main point is to minimize the total loop area from a power pin, through the cap and back to a ground pin. So more than just lead length, you need to optimize cap placement. > 4) What is the concept surrounding islands on the power plane? What should > that plane look like? What should I avoid? What the hell about it, this > plane is a mystery for me!!! I have heard about the island theory, but never tried it myself. Your board is not going to be a critcal one, so just stick to one large power plane, divided up for each power region of course. If the board is really as simple as you describe above you don't really have any big issues. > In order to avoid asking 1000's other questions, I wonder if someone could > also direct me toward a complete document talking about PCB design > guidelines for PQ package FPGA's. I found that for the BGA packages on > xilinx website, but it didn't help me much. The quad flat packages are inherently more noisy for the chip inside due to the longer leads. So your board design can only do so much. A big help will be to drive your outputs as lightly as possible and as slow as possible. The SpartanIIE's have several variations in drive strength and speed. Also if you are concerned about a lot of outputs switching at the same time, you can try to stagger them a bit. But this is not normally needed except in extreme cases. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 58015
One other point I would like to make. A lot of people will tell you to use multiple Tantalum caps, including the Xilinx app notes. But Tantalum caps are inherently slow compared to the noise on the board. So you can get away with a single cap anywhere on each power plane it will fit. But 10 uF may be a bit small. I build a board with a 10 uF cap and found that the power line impedance coming to the board created voltage spikes enough to show up in the analog circuits. A larger Tantalum cap on the board would have prevented this. Of course better power conductors solved the problem as well. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 58016
This is really an appropriate reply and I feel confident to start the design of my board. Thanks, this is really appreciated. Gabriel "rickman" <spamgoeshere4@yahoo.com> wrote in message news:3F0F2A63.C758E3FE@yahoo.com... > One other point I would like to make. A lot of people will tell you to > use multiple Tantalum caps, including the Xilinx app notes. But > Tantalum caps are inherently slow compared to the noise on the board. > So you can get away with a single cap anywhere on each power plane it > will fit. But 10 uF may be a bit small. I build a board with a 10 uF > cap and found that the power line impedance coming to the board created > voltage spikes enough to show up in the analog circuits. A larger > Tantalum cap on the board would have prevented this. Of course better > power conductors solved the problem as well. > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 58017
Here is some code showing a problem I am having with Quartus. Seems
using a type cast with an aggregate throws it all off. This is just a
simple test case which uses a 16 bit bidir bus to write to an 8 bit
register and read it back.
-- VHDL created by Rick Collins
Library ieee;
Use ieee.std_logic_1164.all;
Use ieee.numeric_std.all;
ENTITY Test1 is
PORT (
Data : INOUT STD_LOGIC_VECTOR (15 DOWNTO 0);
Addr : IN STD_LOGIC_VECTOR (7 DOWNTO 0);
CSN : IN STD_LOGIC;
RDN : IN STD_LOGIC;
WRN : IN STD_LOGIC;
LED : OUT STD_LOGIC;
Reset : IN STD_LOGIC;
SysClk : IN STD_LOGIC); -- 50 MHz Clock
END Test1;
ARCHITECTURE behavior OF Test1 IS
constant SysClkRate : real := 50000.0; -- Rate in KHz
signal ScratchReg : STD_LOGIC_VECTOR (7 downto 0);
signal DataOut : STD_LOGIC_VECTOR (15 downto 0);
signal ReadScratchReg : STD_LOGIC;
BEGIN
ReadScratchReg <= (not RDN) WHEN (Addr="00001000") and (CSN='0')
ELSE '0';
-- VERSION 1
-- These lines work correctly
-- Data (15 downto 8) <= (others => '0') WHEN (ReadScratchReg = '1')
-- ELSE (others => 'Z');
-- Data (7 downto 0) <= ScratchReg WHEN (ReadScratchReg = '1')
-- ELSE (others => 'Z');
-- VERSION 2
-- This line fails by disabling the tristate buffers
-- Data <= STD_LOGIC_VECTOR (15 downto 8)'(others => '0') &
ScratchReg WHEN (ReadScratchReg = '1')
-- ELSE (others => 'Z');
-- The difference seems to be the use of the type cast.
-- Using a type cast with the (others => aggregate seems to fail in
other cases as well.
-- VERSION 3
-- This version produces open drain outputs
Data <= DataOut WHEN (ReadScratchReg = '1')
ELSE (others => 'Z');
-- This seems to work ok
-- DataOut <= "00000000" & ScratchReg;
-- This produces no register and open drain drivers
DataOut <= STD_LOGIC_VECTOR (15 downto 8)'(others => '0') &
ScratchReg;
ScratchRegister: process (SysClk, Reset) begin
if (Reset = '1') then
ScratchReg <= (others => '0');
elsif (rising_edge(SysClk)) then
if (Addr = "00001000") THEN
if (WRN = '0' and CSN = '0') THEN
ScratchReg <= Data (7 downto 0);
end if;
end if;
end if;
end process ScratchRegister;
LED <= ScratchReg(0) AND ReadScratchReg;
END behavior;
As seen under VERSION 3, using the type cast on an aggregate produces a
design with the register not driving the bidir output pins. I don't see
any messages saying the registers were deleted, but the only bit that
remains is the zero bit which drives the LED output. All of the DataOut
nets are listed as undriven and tied to ground.
Using a fixed size vector seems to work ok. It also works ok if I
separate the two halves of the bus and don't use a type cast on the
aggregates. Is this a Quartus bug?
I tried contacting Altera support, but after waiting on hold to talk to
someone, I got put on hold again and then cut off.
--
Rick "rickman" Collins
rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Article: 58018"Peter Alfke" <peter@xilinx.com> wrote in message news:3F01F99B.94B76799@xilinx.com... > Spartan3 is not the fastest, in some areas it is slower than Virtex-II, > since the priorities for Spartan3 were: 1. low cost, 2. low cost, and 3. > low cost. We don't throw away speed, but we did not increase the chip > size to gain performance. So the rep who told me that the slowest speed grade 3S was always faster than the slowest speed grade 2VP was mistaken?Article: 58019
Pete, I believe so. 90nm is not faster than 130 nm per se. In order to get faster transistors, you need to also reduce Vt (threshold voltage), and that increases leakage (by a LOT). With the change from 150 nm to 130 nm we begin to see successive generations without any performance increases due to the raw transistors. Now performance comes only with architectual improvements, or new designs, or with "hardening" soft IP. To make a future transistor faster and not accure undo leakage, we (and everyone else on the planet) need a hi-k gate dielectric process (yet to be invented and proven to be robust). Smaller is less cost per die, but not necessarily better performance like we have been used to in the past. Perfomance now comes at a greater cost! Spartan 3 had to meet the 311 MHz "magic number" for DDR 622 MHz data applications, but did not have to be any faster than that to meet 99% of its intended applications. The raw speed of the transistors is only one factor. There is also the speed of the interconnect (smaller in 90 nm means slightly faster), as well as architectual differences in Spartan 3 that actually yield some improvements. So to say "is S3 faster than V2P?" requires a lot of definitions, and caveats to answer. But basically, the transistors are no faster in S3 than they are in V2P. Austin Pete Fraser wrote: > "Peter Alfke" <peter@xilinx.com> wrote in message > news:3F01F99B.94B76799@xilinx.com... > > > Spartan3 is not the fastest, in some areas it is slower than Virtex-II, > > since the priorities for Spartan3 were: 1. low cost, 2. low cost, and 3. > > low cost. We don't throw away speed, but we did not increase the chip > > size to gain performance. > > So the rep who told me that the slowest speed grade 3S was > always faster than the slowest speed grade 2VP was mistaken?Article: 58020
I have a CPU core and testbench in synthesizable VHDL. I can synthesize using Xilinx ISE 5.1 and it will tell me such-and-such maximum frequency. However, the CPU won't exercise all datapath combinations and it does different things in different cycles so I don't really trust the fitter's max frequency estimate. My plan is to run the post-fit simulation model through my testbench with different clock frequencies until the CPU fails. Then I'll add a little overhead to meet minimum register setup times and that will be my minimum clock period. Am I being too pessimistic about XST's timing estimating capability, and if not, does this sound like a reasonable approach? -- Brad EckertArticle: 58021
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:3F0EFE65.6E432EF8@yahoo.com... > Philip Freidin wrote: > > > > I am sorry to say this design will not work reliably. I assume > > that OLDCLK is slower than NEWCLK by at least a factor of 2. > > I am also assuming that the two clocks are asynchronous to each > > other. > > Actually, that is not a bad assumption since OLDCLK is really a signal, > not a clock. OLDCLK is a poor choice of names perhaps. > True, but the oldclk(signal) will just last for one oldclk cycle. But I guess the period of this clock doesn't matter as it is positive edge triggered.Article: 58022
Morten Leikvoll wrote: > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:3F0EFE65.6E432EF8@yahoo.com... > > Philip Freidin wrote: > > > > > > I am sorry to say this design will not work reliably. I assume > > > that OLDCLK is slower than NEWCLK by at least a factor of 2. > > > I am also assuming that the two clocks are asynchronous to each > > > other. > > > > Actually, that is not a bad assumption since OLDCLK is really a signal, > > not a clock. OLDCLK is a poor choice of names perhaps. > > > > True, but the oldclk(signal) will just last for one oldclk cycle. But I > guess the period of this clock doesn't matter as it is positive edge > triggered. Yes, that is the point of the circuit the way I provided it. A coworker showed it to me and explained how it had many uses in different forms. I don't remember all the applications, but it works so well because it deals with the metastable issues and is very simple. You can even shave a FF off the newclk side by xoring the output of the oldclk FF and the output of the newclk FF and clocking that signal before use. This final FF should remove any metastability in either the newclk FF or the oldclk FF. The only trick with that circuit is to make sure the delay from the oldclk FF through the XOR to the final FF is longer than the path from the oldclk FF to the first newclk FF. If not, you can miss an edge. So it is not worth the trouble unless you are really counting your FFs or you are using a lot of these circuits. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 58023
Unfortunately the I/O compliance isn't selectable when the part is configured - it's a constraint used to define the configuration file. You can have the different supplies accommodated by reconfiguring the Virtex-II with the other voltage if necessary. I expect that having 3.3V on 2.5V defined rails (or vice-versa) won't damage the part though logic thresholds might be confused. If the 3.3V logic you're interfacing to can accept 2.5V levels from the Xilinx device, just adding 100 ohm series resistors - as is used to interface 5V logic with 3.3V inputs - may also give you a design that interfaces to both voltages while being powered from 2.5 only. Krzysztof Szczepanski wrote: > Hello, > > I have a design for the VIRTEX -II chip with two I/O standards (3.3V and > 2.5V). Selected banks have switching I/O voltage after configuration. The > voltage depends on project type. One VIRTEX configuration has 3.3V standard > and other configuration has 2.5V standard. I have to switch the appropriate > voltage after configuration of the VIRTEX. > > My problem is if I can switch the I/O voltage form 3.3V to 2.5V after > configuration of the VIRTEX with I/O (input, output and input-output) pasd's > standard set to 2.5V? > In this case selected VCCO power pins will have 3.3V for several mil. > seconds. > > Is the opposite situation possible when I have default 2.5V VCCO? Then I > switch form 2.5V to 3.3V after configuration (project have 3.3V I/O standard > and VIRTEX pins are connected to other system pins with 3.3V). > > Regards, > Krzysiek > > >Article: 58024
In article <3F0F40EB.946703FB@xilinx.com>, Austin Lesea <Austin.Lesea@xilinx.com> wrote: >To make a future transistor faster and not accure undo leakage, we (and >everyone else on the planet) need a hi-k gate dielectric process (yet to be >invented and proven to be robust). > >Smaller is less cost per die, but not necessarily better performance like we >have been used to in the past. Perfomance now comes at a greater cost! Fortunatly, many of the interesting FPGA applications benefit from effectively arbitrary fine pipelining, which means they can always benefit from replication. Thus reducing size, and thereby getting more gates/$, results in higher performance even if the gates still run at the same speed. -- Nicholas C. Weaver nweaver@cs.berkeley.edu
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z