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
AMDyer@gmail.com <amdyer@gmail.com> wrote: > On Nov 11, 8:45 am, "noob13" > <matija.draganovic@n_o_s_p_a_m.hotmail.com> wrote: > > Hi, > > > > I'm developing a certain controller using Spartan3 FPGA. Since I have to > > communicate with another circuit that is using 5V signaling (similar to > > TTL, but HV level is above 3.5V) I was wondering if someone could > > recommend a good solution in a form of a "level shifter" circuit > > (I searched the > > internet and found a few ICs that could do the job. However, I could use a > > good recomendation though :) ). > > > check out the TI TXB0102 and other parts in the series. They're very > versatile covering a lot of voltage levels, no need to deal with > direction like on the 74LVC8T245 and similar parts. They have good > ESD protection, support powering down one side without loading down > the other, and come in microscopic packages if you need that sort of > thing. There is also a TXS010x series that is similar, but used for > open-drain type interfaces like I2C. With the TXB parts, be sure not to go on a cable with that signal. Reflections from the end of the cable will easily switch the direction, leading to oscillations. Been there, done that :-) For going 3.3V <-> 5 Volt, FET Switches like the 74CBTD3861 are also a good choice. Either provide some pullup on the 5 Volt side or if the part has "keeper", like the AVR AT90 Bus lines, activate these keepers and you have true 5 Volt CMOS levels on the 5 Volt side even if the 3.3 Volt side drives. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 149651
Hey all, It was basic mistake. Even though, modulator was working fine, this block introduces some additional bits at the start, which I couldn't observe in Hardware. So it made the decoder to interpret the data in different way. Now I could solve it. thanks all for the reply >On Nov 12, 7:54=A0am, "sridar" <srisridar@n_o_s_p_a_m.gmail.com> wrote: >> Hi all, >> >> I am working on a design, where there are n modules. Each module is >> connected with next module in sequential fashion. >> >> like, =A0data generator -> encoder 1 -> encoder 2-> modulator -> demodula= >tor >> -> decoder2 -> decoder1 >> >> The output of decoder1 should be same as data generator. I have tested ea= >ch >> module in FPGA =A0and also the following configurations >> >> data generator -> encoder 1 -> encoder 2-> =A0decoder2 ->decoder1 =A0 =A0= > =A0 =A0 =A0 =A0 >> =A0 ----------Works fine >> >> data generator -> encoder 2 -> =A0modulator -> demodulator =A0-> decoder2= > =A0 =A0 =A0 >> =A0----------Works fine >> >> But, when I integrate the all the modules, the design is not working as >> expected. I need to reset the board for 5,6 times for the output to come >> correctly. The timing analyzer reported no error. >> >> BTW, I designed all the modules using VHDL in ISE 12.3 and tried in two >> hardware boards 1. Spartan-6 sp601 kit =A02. Spartan-3 based baord >> >> --------------------------------------- =A0 =A0 =A0 =A0 >> Posted throughhttp://www.FPGARelated.com >How about an occasional bit error between the modulator and >demodulator causes the decoder1 to get lost where as decoder2 is more >robust. > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149652
On Nov 11, 6:45=A0am, "noob13" <matija.draganovic@n_o_s_p_a_m.hotmail.com> wrote: > Hi, > > I'm developing a certain controller using Spartan3 FPGA. Since I have to > communicate with another circuit that is using 5V signaling (similar to > TTL, but HV level is above 3.5V) I was wondering if someone could recomme= nd > a good solution in a form of a "level shifter" circuit (I searched the > internet and found a few ICs that could do the job. However, I could use = a > good recomendation though :) ). > > Tnx in advance.. > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com I have a number of potential solutions, but the best depends on a few questions. 1. How many I/O do you need? 2. How fast must they be? 3. Do you have some extra board space for external resistors?Article: 149653
> > John > > [1] We're migrating away from Xilinx. Great silicon, insanely broken > software.- Hide quoted text - > > - Show quoted text - Just curious, but what in specific are the biggest gripes? Is there a specific feature or features that are insanely broken? I've been a user since 1986 and certainly had/have much to complain about on the software, but I use it on almost a daily basis. Sure, there are various Xilinx tools that do things "the Xilinx way" instead of using the typical industry-standard method. I also use the Altera tools regularly and love/hate them as well. Are you using high-density or lower-density parts? Which family? Steve Knapp Prevailing Technology, Inc.Article: 149654
On Sat, 13 Nov 2010 09:32:44 -0800 (PST), Prevailing over Technology <steve.knapp@prevailing-technology.com> wrote: > >> >> John >> >> [1] We're migrating away from Xilinx. Great silicon, insanely broken >> software.- Hide quoted text - >> >> - Show quoted text - > >Just curious, but what in specific are the biggest gripes? Is there a >specific feature or features that are insanely broken? I've been a >user since 1986 and certainly had/have much to complain about on the >software, but I use it on almost a daily basis. Sure, there are >various Xilinx tools that do things "the Xilinx way" instead of using >the typical industry-standard method. I also use the Altera tools >regularly and love/hate them as well. > >Are you using high-density or lower-density parts? Which family? > >Steve Knapp >Prevailing Technology, Inc. I don't drive the tools myself, but I have two very good guys who do. I negotiate architectures with them, and they do the actual design. A typical design takes 3 or 4 times as long as it should, because of tool problems. They tell me... Schematic design (which we use for top level, and occasional special blocks) is broken. Always has been, just different versions of broken. Asking for hard features (like, force this flop to be an i/o cell flop) is difficult and erratic. The tools like to just ignore what we want to do. The Spartan6 DRAM controller couldn't be made to work. At 128 MHz! We gave up. Things crash. Things give cryptic error messages. Placement makes no sense and wastes nanoseconds, even in low density apps. The GUI is flakey. And lots of other gripes; I could ask them for a list. One of my guys took an existing design, all VHDL, and ported it to Altera in a couple of hours. It just worked. Maybe the biggest problem is support. There may be simple things we could do to fix most of our problems, but "support" is in the business of retiring trouble tickets, not actually helping. And once they do close a ticket, you have to start all over, usually with someone else. And they apparently can't transfer the case to that someone else. We did have some decent people at NuHo who harassed Xilinx on our behalf, but you know what happened there. Altera *sends smart people to our shop* when we need help. Too bad. The Xilinx silicon is great. I'd been a Xilinx fan ever since Peter Alfke talked me into using Xilinx, after an accidental meeting of heads (literally, inside a big cardboard box full of books for sale) at the Foothill Flea Market. But my guys have convinced me that we should switch. JohnArticle: 149655
On Nov 13, 1:02=A0pm, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > On Sat, 13 Nov 2010 09:32:44 -0800 (PST), Prevailing over Technology > > > > <steve.kn...@prevailing-technology.com> wrote: > > >> John > > >> [1] We're migrating away from Xilinx. Great silicon, insanely broken > >> software.- Hide quoted text - > > >> - Show quoted text - > > >Just curious, but what in specific are the biggest gripes? =A0Is there a > >specific feature or features that are insanely broken? =A0I've been a > >user since 1986 and certainly had/have much to complain about on the > >software, but I use it on almost a daily basis. =A0Sure, there are > >various Xilinx tools that do things "the Xilinx way" instead of using > >the typical industry-standard method. =A0I also use the Altera tools > >regularly and love/hate them as well. > > >Are you using high-density or lower-density parts? =A0Which family? > > >Steve Knapp > >Prevailing Technology, Inc. > > I don't drive the tools myself, but I have two very good guys who do. > I negotiate architectures with them, and they do the actual design. A > typical design takes 3 or 4 times as long as it should, because of > tool problems. They tell me... > > Schematic design (which we use for top level, and occasional special > blocks) is broken. Always has been, just different versions of broken. > > Asking for hard features (like, force this flop to be an i/o cell > flop) is difficult and erratic. The tools like to just ignore what we > want to do. > > The Spartan6 DRAM controller couldn't be made to work. At 128 MHz! We > gave up. > > Things crash. Things give cryptic error messages. Placement makes no > sense and wastes nanoseconds, even in low density apps. The GUI is > flakey. > > And lots of other gripes; I could ask them for a list. One of my guys > took an existing design, all VHDL, and ported it to Altera in a couple > of hours. It just worked. > > Maybe the biggest problem is support. There may be simple things we > could do to fix most of our problems, but "support" is in the business > of retiring trouble tickets, not actually helping. And once they do > close a ticket, you have to start all over, usually with someone else. > And they apparently can't transfer the case to that someone else. We > did have some decent people at NuHo who harassed Xilinx on our behalf, > but you know what happened there. > > Altera *sends smart people to our shop* when we need help. > > Too bad. The Xilinx silicon is great. I'd been a Xilinx fan ever since > Peter Alfke talked me into using Xilinx, after an accidental meeting > of heads (literally, inside a big cardboard box full of books for > sale) at the Foothill Flea Market. But my guys have convinced me that > we should switch. > > John John, I don't think your experience with Xilinx is typical. We have working hardware using Spartan 6 and DDR2 DRAM running at 333 MHz. I agree that there are support issues, and there are some things that are very hard to use, including the memory interface generator. I'll also agree that schematics are broken, at least since they dumped Aldec after Foundation version 4.1i. It's pretty clear that schematics are very low on their software support priority list. I stopped using schematics when I moved from the Aldec-based Foundation tools to ISE. However I have had very good luck with the back-end tools. There are a lot of switches in each tool and once you find the proper settings you can get very good results. I have also found that the recent versions of XST compare favorably to third-party tools like Synplify. Again there are a lot of knobs to turn to get the best performance from XST. I hope someone from Xilinx listens to these threads. The real issue in your case seems to be the lack of support. I'm sure their bean-counters had a good reason to dump NuHorizons and get rid of most of the FAE's (there are still large Xilinx customers who get regular visits from Xilinx FAE's). However they should realize that you can only get so far with good silicon. Good Luck, GaborArticle: 149656
First of all, tnx for all of your replies! I believe that I'll use some of the IC solutions mentioned above. The only restrictions that are important are that I need to use 5-7 I/O, and signals with fmax = 20 MHz. In accordance to that I'll choose some IC solution (I have to check availability with my supplier, etc. ..). --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149657
> > In the 12 release, the Tcl infrastructure in PlanAhead changed to > > accommodate the long-term plans for > > Xilinx to migrate toward Synopsys Design Constraints (SDC) for timing > > constraints. > I guess we can say "There is a Father Christmas after all ....." > I think we'll all be much happier with ISE 13. Big companies can do > great things when motivated, and from what I hear, Xilinx are very > motivated in this area. In this respect they're just playing catch up with Altera, Quartus has used SDC files with Timequest for a couple of years now. NialArticle: 149658
On Nov 15, 10:12=A0am, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > > In the 12 release, the Tcl infrastructure in PlanAhead changed to > > > accommodate the long-term plans for > > > Xilinx to migrate toward Synopsys Design Constraints (SDC) for timing > > > constraints. > > I guess we can say "There is a Father Christmas after all ....." > > I think we'll all be much happier with ISE 13. Big companies can do > > great things when motivated, and from what I hear, Xilinx are very > > motivated in this area. > > In this respect they're just playing catch up with Altera, Quartus has > used SDC files with Timequest for a couple of years now. > > Nial Point taken, but the point I was trying to make is there is a real concerted effort underway to improve quality, as well as comparability, standards support, etc. This effort has been underway for sometime, or so I'm told, and is about the bear fruit. (note: I don't know if this is the 13.x release, I just assume so?) I'm somewhat looking forward to what comes out - I know people are cynical, but I think it is a positive indication that action is being taken. SW quality to match the silicon is something we can all be happier about. I think it would be worth feeding back some of the anecdotal issues people have had here to Xilinx - the issues that come from migration. the more information they have, the better they can react. Is there some e-mail or website where such feedback can be given directly and constructively?Article: 149659
On 13/11/2010 05:11, rickman wrote: > On Nov 12, 6:27 pm, John Larkin > <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >> On Fri, 12 Nov 2010 14:20:19 -0800 (PST), d_s_klein >> >>> Back to the OP's original topic: Yeah, these new packages are tough. >>> Good thing itty-bitty ceramics come in large values, and thank the >>> heavens for 'via in pad'. >> >> We just splatter a few 0603 caps on the top side of the board, far >> enough from the FPGA that production can get their little optical >> inspection gidget in there. Works fine. >> >> Is via in pad safe? Is solder slurping a serious issue? I'd sure like >> to eliminate those dogbone things. >> >> John > > No first hand experience, but I'm told if the vias are plated shut > there is no solder slurping. > When the vias are properly plated, there is no hole any more - it's just copper (with appropriate finish). The only thing you have to watch out for is that the plates should be flush with the rest of the surface - I have heard that some manufacturers have problems keeping them planar, and you end up with the plated vias being slightly higher than non-via pads. But that should not be a problem with a decent manufacturer. You can leave the other end of the via open for marginally lower costs, or fill the hole and plate on the other side. This should be standard and error-free for a modern manufacturer. > More interesting to me is the decoupling capacitor issue. I took a > class on high speed digital design once and the instructor claimed > decoupling caps do not need to be as close as possible to the chip to > be effective when power and ground planes are used. In essence the > planes provide the current the chip needs as the wave front propagates > to the cap. Certainly the trace from the via to the cap should be as > short as possible. I believe that is what you are saying works for > your dense BGAs. > That's my understanding of the theory too - you want your caps to be within a quarter wavelength and with low inductance paths to the pins. Mind you, the stuff I made isn't very high frequency, nor does it have a lot of transients. > He did also make a case for using multiple values of caps to minimize > resonances in the power decoupling circuits. BTW, he didn't just hand > wave this stuff. Everything he told us in class was analyzed in > theory, simulated in software and then tested in hardware. Lee > Ritchey of Speeding Edge consultants. > Resonances are only a problem if you get peeks of high inductance or standing waves. The rule I use is to pick the smallest package production is happy using, then the largest capacitance in that package, and use that consistently. With the smallest package you get the smallest inductance - smaller capacitances in the same package are no better for bypassing at high frequencies, and worse at lower frequencies. Avoid standing waves and resonance on the power planes by avoiding power planes - use polygons instead of planes, or add tracks to the power planes, so that there are no nice straight edges for reflecting waves. But as I said, that's my theory - and I don't have the practice to back it up.Article: 149660
On 11 Nov., 18:03, Andy <jonesa...@comcast.net> wrote: > On Nov 10, 12:54=A0pm, Jaime Andr=E9s Aranguren Cardona > > > > > > <jaime.arangu...@gmail.com> wrote: > > On 10 Nov., 19:50, Jaime Andr=E9s Aranguren Cardona > > > <jaime.arangu...@gmail.com> wrote: > > > On 10 Nov., 19:16, Andy <jonesa...@comcast.net> wrote: > > > > > On Nov 10, 10:53=A0am, Jaime Andr=E9s Aranguren Cardona > > > > > <jaime.arangu...@gmail.com> wrote: > > > > > Dear all, > > > > > > In my current project I have an entity for which I which arhitect= ure > > > > > to use on a VHDL file where I instantiate the entity, like follow= ing > > > > > configuration code: > > > > > > -- Embedded configuration > > > > > -- Select control architecture to use > > > > > for all : Ctrl2D use entity work.Ctrl2D(rtl_small); > > > > > > Within the VHDL file where Ctrl2D is defined, I have different > > > > > configurations, namely rtl_tiny and rtl_small. Within each of tho= se, > > > > > are processes which have variables whose length depend on some > > > > > constants (KA, KB), like: > > > > > > process_out : process (in_a, in_b) > > > > > =A0 =A0 variable var : std_logic_vector (KA-KB-1 downto 0) =A0:= =3D (others =3D> > > > > > '0'); > > > > > =A0 begin > > > > > > I should select which architecture to use in the configuration > > > > > (rtl_tiny or rtl_small) depending on a given a given set of value= s KA > > > > > and KB. For a set of values KA and KB that works fine with rtl_sm= all > > > > > and having rtl_small selected in the configuration, XST, when par= sing, > > > > > gives me warnign and error messages: > > > > > > Entity <Ctrl2D> compiled. > > > > > WARNING:HDLParsers:3350 - "D:/Projects/Ctrl2D.vhd" Line 157. Null > > > > > range: -33 downto 0 > > > > > ERROR:HDLParsers:804 - "D:/Projects/Ctrl2D.vhd" Line 214. Size of > > > > > concat operation is different than size of the target. > > > > > Entity <Ctrl2D> (Architecture <rtl_small>) compiled. > > > > > > But those lines (157 and 214) are within the architecture rtl_tin= y, > > > > > not rtl_small. > > > > > > I was confident that by selecting the right architecture in the > > > > > configuration I was completely bypassing everything related to no= n- > > > > > desired architectures, but it seems like I was wrong. > > > > > > How can I direct XST to ignore the code of the non-interesting > > > > > architectures, and parse and synthesize only the one that I selec= ted > > > > > in the configuration? > > > > > > Thanks a lot in advance, > > > > > > JaaC > > > > > Unlike simulation tools, synthesis tools combine the analysis and > > > > elaboration phases into one. This is probably leading to your probl= em. > > > > Leaving something out in a configuration is not quite like > > > > conditionally compiling it. Everything gets analyzed (if it is in a > > > > file that is being analyzed), whether it is chosen at elaboration o= r > > > > not. Some simulators have options for compiling (analyzing) only > > > > certain types of units (packages, package bodies, entities, > > > > architectures, etc.) and ignoring others in the same file. I have n= ot > > > > seen that in a synthesis tool. > > > > > Other than fixing the problem with the mismatched size (if even > > > > possible), I would suggest moving the two architectures into separa= te > > > > files, and only including the appropriate file in the project. > > > > > Andy > > > > Hi Andy, > > > > Thanks for your reply, I found the solution however: adding pragmas: > > > > architecture struct of Stack2D is > > > > =A0 signal dat_2ext : buf2dwrd; > > > =A0 signal rd_2ext =A0: std_logic; > > > =A0 signal dat_2slv : buf2dwrd; > > > =A0 signal wr_2slv =A0: std_logic; > > > > =A0 -- pragma synthesis on > > > =A0 for all : Ctrl2D use entity work.Ctrl2D(rtl_small); > > > =A0 -- pragma synthesis off > > > > begin > > > > The commented pragmas did the job. > > > > Regards. > > > Dear all, > > > By the way, is there a way to make a conditional selection of > > architecture to use, something in the lines of: > > > for all : Ctrl2D if A =3D 0 use entity work.Ctrl2D(architecture_a) =A0e= lse > > use entity work.Ctrl2D(architecture_b); =A0 ??? > > > Or is there an alternative approach? > > > Thanks lot in advance. > > > JaaC- Hide quoted text - > > > - Show quoted text - > > The only way to do that is with an if-generate on the instantiation, > not the configuration. > > In fact, since the '93 standard, you can directly instantiate an > entity and its architecture: > > if a =3D 0 generate > u1: entity work.entity_name(architecture_name)... > end generate; > > if a /=3D 0 generate > u1: entity work.entity_name(alternative_architecture_name) ... > end generate; > > You don't even need to mess with a configuration! > > Andy- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - Dear all, Thanks for the feedback. Andy's suggestion seems to be very in the direction I was heading for, thanks a lot. Kindest regards, JaaCArticle: 149661
On Mon, 15 Nov 2010 13:39:37 +0100, David Brown <david@westcontrol.removethisbit.com> wrote: >On 13/11/2010 05:11, rickman wrote: >> On Nov 12, 6:27 pm, John Larkin >> <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >>> On Fri, 12 Nov 2010 14:20:19 -0800 (PST), d_s_klein >>> >>>> Back to the OP's original topic: Yeah, these new packages are tough. >>>> Good thing itty-bitty ceramics come in large values, and thank the >>>> heavens for 'via in pad'. >>> >>> We just splatter a few 0603 caps on the top side of the board, far >>> enough from the FPGA that production can get their little optical >>> inspection gidget in there. Works fine. >>> >>> Is via in pad safe? Is solder slurping a serious issue? I'd sure like >>> to eliminate those dogbone things. >>> >>> John >> >> No first hand experience, but I'm told if the vias are plated shut >> there is no solder slurping. >> > >When the vias are properly plated, there is no hole any more - it's just >copper (with appropriate finish). The only thing you have to watch out >for is that the plates should be flush with the rest of the surface - I >have heard that some manufacturers have problems keeping them planar, >and you end up with the plated vias being slightly higher than non-via >pads. But that should not be a problem with a decent manufacturer. > >You can leave the other end of the via open for marginally lower costs, >or fill the hole and plate on the other side. This should be standard >and error-free for a modern manufacturer. > >> More interesting to me is the decoupling capacitor issue. I took a >> class on high speed digital design once and the instructor claimed >> decoupling caps do not need to be as close as possible to the chip to >> be effective when power and ground planes are used. In essence the >> planes provide the current the chip needs as the wave front propagates >> to the cap. Certainly the trace from the via to the cap should be as >> short as possible. I believe that is what you are saying works for >> your dense BGAs. >> > >That's my understanding of the theory too - you want your caps to be >within a quarter wavelength and with low inductance paths to the pins. >Mind you, the stuff I made isn't very high frequency, nor does it have a >lot of transients. > >> He did also make a case for using multiple values of caps to minimize >> resonances in the power decoupling circuits. BTW, he didn't just hand >> wave this stuff. Everything he told us in class was analyzed in >> theory, simulated in software and then tested in hardware. Lee >> Ritchey of Speeding Edge consultants. >> > >Resonances are only a problem if you get peeks of high inductance or >standing waves. The rule I use is to pick the smallest package >production is happy using, then the largest capacitance in that package, >and use that consistently. With the smallest package you get the >smallest inductance - smaller capacitances in the same package are no >better for bypassing at high frequencies, and worse at lower frequencies. > >Avoid standing waves and resonance on the power planes by avoiding power >planes - use polygons instead of planes, or add tracks to the power >planes, so that there are no nice straight edges for reflecting waves. Planes are superb, low-impedance, low-Q bypass capacitors. The added discrete bypass caps just help the planes at low frequencies. If you TDR a power:ground plane pair, it looks like an almost perfect capacitor with a little ESR (which is actually the transmission line impedance of the structure) and just hints of edge reflections. Seed it with randomly places caps, and it just gets better. There are lots of dollars spent on courses and consultants that have bypassing theories, but on a multilayer board with power and ground planes, practically anything works. What can get tricky is things like Intel CPUs that idle at low current and need 50 amps in a few nanoseconds. But that's a low-frequency issue. Hmmm, software or microcode could ramp those currents... JohnArticle: 149662
I've avoided these to date but have been approached by someone to look at implementing the digital aspects to their design. What's required is _very_ simple, it's basically a 24 bit up counter feeding a down counter with half it's value when an input changes. This is two or three lines of VHDL but I can't get their pre-defined components to do what I need. I don't have time to wade through reams of data sheets and have done a quick google with no results so.... Does anyone know if it's possible to use vhdl (or verilog) to define these digital sections? Thanks for any pointers, Nial.Article: 149663
Nial >From the PSOC wiki page :- PSoC resembles an FPGA in that at power up it must be configured, but this configuration occurs by loading instructions from the built-in Flash memory. Unlike an FPGA, the current generation of PSoC cannot have its digital functions reprogrammed by VHDL or Verilog, it can only be configured with register settings. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149664
> From the PSOC wiki page :- > it can only be configured with register settings. Bugger. Thanks Jon. Nial.Article: 149665
On Nov 15, 10:55=A0am, "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote: > Nial > > From the PSOC wiki page :- > > PSoC resembles an FPGA in that at power up it must be configured, but thi= s > configuration occurs by loading instructions from the built-in Flash > memory. Unlike an FPGA, the current generation of PSoC cannot have its > digital functions reprogrammed by VHDL or Verilog, it can only be > configured with register settings. > > Jon =A0 =A0 =A0 =A0 I'm not sure where that info came from, but I have read multiple times that the PSOC3 and PSOC5 will be programmable using Verilog. The wiki page may be referring to the original PSoC chips. I would suggest that the OP post this question in the forums at psocdeveloper.com. Answers there come directly from the PSoC engineers. RickArticle: 149666
On Nov 15, 7:39=A0am, David Brown <da...@westcontrol.removethisbit.com> wrote: > On 13/11/2010 05:11, rickman wrote: > > > > > On Nov 12, 6:27 pm, John Larkin > > <jjlar...@highNOTlandTHIStechnologyPART.com> =A0wrote: > >> On Fri, 12 Nov 2010 14:20:19 -0800 (PST), d_s_klein > > >>> Back to the OP's original topic: =A0Yeah, these new packages are toug= h. > >>> Good thing itty-bitty ceramics come in large values, and thank the > >>> heavens for 'via in pad'. > > >> We just splatter a few 0603 caps on the top side of the board, far > >> enough from the FPGA that production can get their little optical > >> inspection gidget in there. Works fine. > > >> Is via in pad safe? Is solder slurping a serious issue? I'd sure like > >> to eliminate those dogbone things. > > >> John > > > No first hand experience, but I'm told if the vias are plated shut > > there is no solder slurping. > > When the vias are properly plated, there is no hole any more - it's just > copper (with appropriate finish). =A0The only thing you have to watch out > for is that the plates should be flush with the rest of the surface - I > have heard that some manufacturers have problems keeping them planar, > and you end up with the plated vias being slightly higher than non-via > pads. =A0But that should not be a problem with a decent manufacturer. > > You can leave the other end of the via open for marginally lower costs, > or fill the hole and plate on the other side. =A0This should be standard > and error-free for a modern manufacturer. > > > More interesting to me is the decoupling capacitor issue. =A0I took a > > class on high speed digital design once and the instructor claimed > > decoupling caps do not need to be as close as possible to the chip to > > be effective when power and ground planes are used. =A0In essence the > > planes provide the current the chip needs as the wave front propagates > > to the cap. =A0Certainly the trace from the via to the cap should be as > > short as possible. =A0I believe that is what you are saying works for > > your dense BGAs. > > That's my understanding of the theory too - you want your caps to be > within a quarter wavelength and with low inductance paths to the pins. > Mind you, the stuff I made isn't very high frequency, nor does it have a > lot of transients. > > > He did also make a case for using multiple values of caps to minimize > > resonances in the power decoupling circuits. =A0BTW, he didn't just han= d > > wave this stuff. =A0Everything he told us in class was analyzed in > > theory, simulated in software and then tested in hardware. =A0Lee > > Ritchey of Speeding Edge consultants. > > Resonances are only a problem if you get peeks of high inductance or > standing waves. =A0The rule I use is to pick the smallest package > production is happy using, then the largest capacitance in that package, > and use that consistently. =A0With the smallest package you get the > smallest inductance - smaller capacitances in the same package are no > better for bypassing at high frequencies, and worse at lower frequencies. Yes, smaller packages are lower inductance. But the resonance is from the inductance of the capacitor interacting with the capacitance of the power planes. Using multiple values of caps creates multiple resonances, but where one pair has a resonance another device has low impedance in parallel, so the net is a fairly low value across frequencies. The ESR of the caps prevents the resonance from being extremely high like a pure parallel LC circuit would be. > Avoid standing waves and resonance on the power planes by avoiding power > planes - use polygons instead of planes, or add tracks to the power > planes, so that there are no nice straight edges for reflecting waves. > > But as I said, that's my theory - and I don't have the practice to back > it up. Yes, I've heard that theory, but Lee Ritchey debunked it IIRC. The effect of the capacitors attached to the planes swamps out the wave and the standing wave does not develop to any degree. but I won't say I am sure about how this works. I do remember that he could not find any issues with the standing wave effect. I wish I had the book handy. He had some good measurements to illustrate the matter. RickArticle: 149667
On Nov 15, 10:01=A0am, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > On Mon, 15 Nov 2010 13:39:37 +0100, David Brown > > > > <da...@westcontrol.removethisbit.com> wrote: > >On 13/11/2010 05:11, rickman wrote: > >> On Nov 12, 6:27 pm, John Larkin > >> <jjlar...@highNOTlandTHIStechnologyPART.com> =A0wrote: > >>> On Fri, 12 Nov 2010 14:20:19 -0800 (PST), d_s_klein > > >>>> Back to the OP's original topic: =A0Yeah, these new packages are tou= gh. > >>>> Good thing itty-bitty ceramics come in large values, and thank the > >>>> heavens for 'via in pad'. > > >>> We just splatter a few 0603 caps on the top side of the board, far > >>> enough from the FPGA that production can get their little optical > >>> inspection gidget in there. Works fine. > > >>> Is via in pad safe? Is solder slurping a serious issue? I'd sure like > >>> to eliminate those dogbone things. > > >>> John > > >> No first hand experience, but I'm told if the vias are plated shut > >> there is no solder slurping. > > >When the vias are properly plated, there is no hole any more - it's just > >copper (with appropriate finish). =A0The only thing you have to watch ou= t > >for is that the plates should be flush with the rest of the surface - I > >have heard that some manufacturers have problems keeping them planar, > >and you end up with the plated vias being slightly higher than non-via > >pads. =A0But that should not be a problem with a decent manufacturer. > > >You can leave the other end of the via open for marginally lower costs, > >or fill the hole and plate on the other side. =A0This should be standard > >and error-free for a modern manufacturer. > > >> More interesting to me is the decoupling capacitor issue. =A0I took a > >> class on high speed digital design once and the instructor claimed > >> decoupling caps do not need to be as close as possible to the chip to > >> be effective when power and ground planes are used. =A0In essence the > >> planes provide the current the chip needs as the wave front propagates > >> to the cap. =A0Certainly the trace from the via to the cap should be a= s > >> short as possible. =A0I believe that is what you are saying works for > >> your dense BGAs. > > >That's my understanding of the theory too - you want your caps to be > >within a quarter wavelength and with low inductance paths to the pins. > >Mind you, the stuff I made isn't very high frequency, nor does it have a > >lot of transients. > > >> He did also make a case for using multiple values of caps to minimize > >> resonances in the power decoupling circuits. =A0BTW, he didn't just ha= nd > >> wave this stuff. =A0Everything he told us in class was analyzed in > >> theory, simulated in software and then tested in hardware. =A0Lee > >> Ritchey of Speeding Edge consultants. > > >Resonances are only a problem if you get peeks of high inductance or > >standing waves. =A0The rule I use is to pick the smallest package > >production is happy using, then the largest capacitance in that package, > >and use that consistently. =A0With the smallest package you get the > >smallest inductance - smaller capacitances in the same package are no > >better for bypassing at high frequencies, and worse at lower frequencies= . > > >Avoid standing waves and resonance on the power planes by avoiding power > >planes - use polygons instead of planes, or add tracks to the power > >planes, so that there are no nice straight edges for reflecting waves. > > Planes are superb, low-impedance, low-Q bypass capacitors. The added > discrete bypass caps just help the planes at low frequencies. > > If you TDR a power:ground plane pair, it looks like an almost perfect > capacitor with a little ESR (which is actually the transmission line > impedance of the structure) and just hints of edge reflections. Seed > it with randomly places caps, and it just gets better. > > There are lots of dollars spent on courses and consultants that have > bypassing theories, but on a multilayer board with power and ground > planes, practically anything works. What can get tricky is things like > Intel CPUs that idle at low current and need 50 amps in a few > nanoseconds. But that's a low-frequency issue. > > Hmmm, software or microcode could ramp those currents... > > John Or using async design rather than huge clock trees. RickArticle: 149668
On Nov 16, 6:32=A0am, rickman <gnu...@gmail.com> wrote: > On Nov 15, 10:55=A0am, "maxascent" > > <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote: > > Nial > > > From the PSOC wiki page :- > > > PSoC resembles an FPGA in that at power up it must be configured, but t= his > > configuration occurs by loading instructions from the built-in Flash > > memory. Unlike an FPGA, the current generation of PSoC cannot have its > > digital functions reprogrammed by VHDL or Verilog, it can only be > > configured with register settings. > > > Jon =A0 =A0 =A0 =A0 > > I'm not sure where that info came from, but I have read multiple times > that the PSOC3 and PSOC5 will be programmable using Verilog. =A0The wiki > page may be referring to the original PSoC chips. > > I would suggest that the OP post this question in the forums at > psocdeveloper.com. =A0Answers there come directly from the PSoC > engineers. > > Rick Sounds like a reply for the older PSoC series. The new ones (PSoC3/PSoC5) can be programmed in Verilog, but it helps to keep the fan-in below a certain ceiling (rusty here, I think it is 12 ? ) which matches the macrocells fanin. Above that, and the reports are less readable, and the tools juggle more, so everything gets less predictable. -jgArticle: 149669
Hello, I want to use SPI between two xilinx's FPGA, but I don't know how maximum speed can be make communication stable? Thanks! --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149670
On Nov 16, 4:14=A0pm, "atutu" <tuanna.hni@n_o_s_p_a_m.gmail.com> wrote: > Hello, > I want to use SPI between two xilinx's FPGA, but I don't know how maximum > speed can be make communication stable? > Thanks! > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com It will depend on the chip spacing/track length and drive/termination you choose. Try it and see. There are Double and Quad bit SPI, and memory devices can go to 80MHz.Quad, or 100MHz Quad. (320-400MBd) If you are doing full custom, and those speeds are not enough, a Double Data rate design could double speeds. -jgArticle: 149671
On 11.11.2010 17:03, John Larkin wrote: > [1] We're migrating away from Xilinx. Great silicon, insanely broken > software. Quartus 10.0(sp1) is quite buggy and likes to crash. So nothing is perfect ;) Overall the Altera software is better than Xilinx software. And the timing engine is better with sdc support etc. --KimArticle: 149672
On 15/11/2010 16:01, John Larkin wrote: > On Mon, 15 Nov 2010 13:39:37 +0100, David Brown > <david@westcontrol.removethisbit.com> wrote: > >> On 13/11/2010 05:11, rickman wrote: >>> On Nov 12, 6:27 pm, John Larkin >>> <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >>>> On Fri, 12 Nov 2010 14:20:19 -0800 (PST), d_s_klein >>>> >>>>> Back to the OP's original topic: Yeah, these new packages are tough. >>>>> Good thing itty-bitty ceramics come in large values, and thank the >>>>> heavens for 'via in pad'. >>>> >>>> We just splatter a few 0603 caps on the top side of the board, far >>>> enough from the FPGA that production can get their little optical >>>> inspection gidget in there. Works fine. >>>> >>>> Is via in pad safe? Is solder slurping a serious issue? I'd sure like >>>> to eliminate those dogbone things. >>>> >>>> John >>> >>> No first hand experience, but I'm told if the vias are plated shut >>> there is no solder slurping. >>> >> >> When the vias are properly plated, there is no hole any more - it's just >> copper (with appropriate finish). The only thing you have to watch out >> for is that the plates should be flush with the rest of the surface - I >> have heard that some manufacturers have problems keeping them planar, >> and you end up with the plated vias being slightly higher than non-via >> pads. But that should not be a problem with a decent manufacturer. >> >> You can leave the other end of the via open for marginally lower costs, >> or fill the hole and plate on the other side. This should be standard >> and error-free for a modern manufacturer. >> >>> More interesting to me is the decoupling capacitor issue. I took a >>> class on high speed digital design once and the instructor claimed >>> decoupling caps do not need to be as close as possible to the chip to >>> be effective when power and ground planes are used. In essence the >>> planes provide the current the chip needs as the wave front propagates >>> to the cap. Certainly the trace from the via to the cap should be as >>> short as possible. I believe that is what you are saying works for >>> your dense BGAs. >>> >> >> That's my understanding of the theory too - you want your caps to be >> within a quarter wavelength and with low inductance paths to the pins. >> Mind you, the stuff I made isn't very high frequency, nor does it have a >> lot of transients. >> >>> He did also make a case for using multiple values of caps to minimize >>> resonances in the power decoupling circuits. BTW, he didn't just hand >>> wave this stuff. Everything he told us in class was analyzed in >>> theory, simulated in software and then tested in hardware. Lee >>> Ritchey of Speeding Edge consultants. >>> >> >> Resonances are only a problem if you get peeks of high inductance or >> standing waves. The rule I use is to pick the smallest package >> production is happy using, then the largest capacitance in that package, >> and use that consistently. With the smallest package you get the >> smallest inductance - smaller capacitances in the same package are no >> better for bypassing at high frequencies, and worse at lower frequencies. >> >> Avoid standing waves and resonance on the power planes by avoiding power >> planes - use polygons instead of planes, or add tracks to the power >> planes, so that there are no nice straight edges for reflecting waves. > > Planes are superb, low-impedance, low-Q bypass capacitors. The added > discrete bypass caps just help the planes at low frequencies. > Yes, but planes are also low capacitance. The other way to think about this is that plane capacitance is very good at high frequency bypassing, and augments the normal bypass capacitors. I don't think the size of the plane makes a big difference, assuming you have other capacitors for the lower frequencies, so a polygon plane will do the same job. If I understand it correctly (and I know that's a big "if"), the inductance of the chip balls and pads will dominate the impedance of the plane capacitor to chip path. > If you TDR a power:ground plane pair, it looks like an almost perfect > capacitor with a little ESR (which is actually the transmission line > impedance of the structure) and just hints of edge reflections. Seed > it with randomly places caps, and it just gets better. > > There are lots of dollars spent on courses and consultants that have > bypassing theories, but on a multilayer board with power and ground > planes, practically anything works. What can get tricky is things like > Intel CPUs that idle at low current and need 50 amps in a few > nanoseconds. But that's a low-frequency issue. > > Hmmm, software or microcode could ramp those currents... > > John >Article: 149673
On 15/11/2010 19:21, rickman wrote: > On Nov 15, 7:39 am, David Brown<da...@westcontrol.removethisbit.com> > wrote: >> On 13/11/2010 05:11, rickman wrote: >> >> >> >>> On Nov 12, 6:27 pm, John Larkin >>> <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >>>> On Fri, 12 Nov 2010 14:20:19 -0800 (PST), d_s_klein >> >>>>> Back to the OP's original topic: Yeah, these new packages are tough. >>>>> Good thing itty-bitty ceramics come in large values, and thank the >>>>> heavens for 'via in pad'. >> >>>> We just splatter a few 0603 caps on the top side of the board, far >>>> enough from the FPGA that production can get their little optical >>>> inspection gidget in there. Works fine. >> >>>> Is via in pad safe? Is solder slurping a serious issue? I'd sure like >>>> to eliminate those dogbone things. >> >>>> John >> >>> No first hand experience, but I'm told if the vias are plated shut >>> there is no solder slurping. >> >> When the vias are properly plated, there is no hole any more - it's just >> copper (with appropriate finish). The only thing you have to watch out >> for is that the plates should be flush with the rest of the surface - I >> have heard that some manufacturers have problems keeping them planar, >> and you end up with the plated vias being slightly higher than non-via >> pads. But that should not be a problem with a decent manufacturer. >> >> You can leave the other end of the via open for marginally lower costs, >> or fill the hole and plate on the other side. This should be standard >> and error-free for a modern manufacturer. >> >>> More interesting to me is the decoupling capacitor issue. I took a >>> class on high speed digital design once and the instructor claimed >>> decoupling caps do not need to be as close as possible to the chip to >>> be effective when power and ground planes are used. In essence the >>> planes provide the current the chip needs as the wave front propagates >>> to the cap. Certainly the trace from the via to the cap should be as >>> short as possible. I believe that is what you are saying works for >>> your dense BGAs. >> >> That's my understanding of the theory too - you want your caps to be >> within a quarter wavelength and with low inductance paths to the pins. >> Mind you, the stuff I made isn't very high frequency, nor does it have a >> lot of transients. >> >>> He did also make a case for using multiple values of caps to minimize >>> resonances in the power decoupling circuits. BTW, he didn't just hand >>> wave this stuff. Everything he told us in class was analyzed in >>> theory, simulated in software and then tested in hardware. Lee >>> Ritchey of Speeding Edge consultants. >> >> Resonances are only a problem if you get peeks of high inductance or >> standing waves. The rule I use is to pick the smallest package >> production is happy using, then the largest capacitance in that package, >> and use that consistently. With the smallest package you get the >> smallest inductance - smaller capacitances in the same package are no >> better for bypassing at high frequencies, and worse at lower frequencies. > > Yes, smaller packages are lower inductance. But the resonance is from > the inductance of the capacitor interacting with the capacitance of > the power planes. Using multiple values of caps creates multiple > resonances, but where one pair has a resonance another device has low > impedance in parallel, so the net is a fairly low value across > frequencies. The ESR of the caps prevents the resonance from being > extremely high like a pure parallel LC circuit would be. > My gut feeling here is that you are not going to get significant resonance between the power plane and the bypass capacitors, especially if the power "plane" is actually just a polygon, and therefore fairly small, while the capacitors are large. The power "plane" is then far too small in comparison to have a noticeable effect on the bypass capacitor, and therefore the bypass capacitor will work as expected. The power "plane" (viewed as a capacitor) is mainly for bypassing very high frequencies - these will be isolated from the bypass capacitors by the capacitors' inductance and ESR, thus it will also continue to work as expected. And again the disclaimer - I haven't worked with this sort of thing in practice (the fastest card I have made was about 200 MHz), nor have I studied the theory or the maths here in detail. My theories are based on reading articles and guides, thinking about how things work, reading c.a.f., etc. I am posting here to ask and learn, and perhaps also to make the experts here think. > >> Avoid standing waves and resonance on the power planes by avoiding power >> planes - use polygons instead of planes, or add tracks to the power >> planes, so that there are no nice straight edges for reflecting waves. >> >> But as I said, that's my theory - and I don't have the practice to back >> it up. > > Yes, I've heard that theory, but Lee Ritchey debunked it IIRC. The > effect of the capacitors attached to the planes swamps out the wave > and the standing wave does not develop to any degree. but I won't say > I am sure about how this works. I do remember that he could not find > any issues with the standing wave effect. I wish I had the book > handy. He had some good measurements to illustrate the matter. > > RickArticle: 149674
I have the following letters with frequency,and can anyone pls help me how to start for the encoding the huffman tree? Thanks Freq. Letter 56 space 2 . 17 a 4 b 16 c 14 d 42 e 18 f 7 g 9 h 15 i 13 l 10 m 21 n 23 o 3 p 3 q 26 r 32 s 13 t 9 u 5 y 1 z just give me the hint pls,pls,pls --------------------------------------- Posted through http://www.FPGARelated.com
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