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
On Jan 8, 2:56=A0pm, Mike Treseler <mike_trese...@comcast.net> wrote: <snip> > > 2) If such an input is sampled by two different FFs for different > > purposes, they may end up with different results. > > This is the case of the *missing* synchronizer. > This is often confused with metastability, > but it is really a design error. > I don't have to wait nearly as long to > observe an error in this case. > > =A0 =A0 =A0 =A0 -- Mike Treseler But... if the input goes to a synchronizer FF and the output of the synchronizer FF feeds more than one FF and the associated combinatorial paths between them are close to the clock period, a metastability delay can force different values for the shorter and longer paths. Without the synchronizing flop, #2 is just a design error. With the synchronizing flop, #2 can see a metastability error because the added (rare) metastability delay screws up the static timing. That's one main reason to specify a more restrictive timing constraint for synchronized paths. I usually tighten my synchronizer output timing paths by 2 ns to account for any rare metastability delays so the same value WILL get to all the destination flops under more circumstances rendering the probability to the 1000 year plus range. - John_HArticle: 127826
"Vagant" <vladimir.v.korostelev@rambler.ru> wrote in message news:81f5ec31-8be7-49e8-b6df-cfe671cfa232@d70g2000hsb.googlegroups.com... > I have Spartan 3E1600E Microblaze Development kit with FPGA marked as: > ----------------------------- > Xilinx > SPARTAN > XC3S1600E > FGG320DGQO617 > A1408025A1 > 4C > ----------------------------- > KOREA > > How I could know its package type? It should be either FG320, or > FG400, or FG484. > Looking at chip's appearance I thought that it is FG484 (as I know how > this looks) but it's marked as FGG320DGQO617 so I am not sure which > package type of my FPGA is? The "FGG320" portion of the fourth line tells you the package type. As shown on pages 6 and 7 in the Spartan-3E data sheet, the "FGG320" indicates that this is a Pb-free (RoHS) 320-ball BGA. Spartan-3E Data Sheet [5.14 MB] http://www.xilinx.com/support/documentation/data_sheets/ds312.pdf -- Steve Knapp Prevailing Technology, Inc. www.prevailing-technology.comArticle: 127827
Hi Guys, Has anybody used a V5 Sys Monitor.. I need some insight on the Aux IOs The UG 192 (refer pg 39) says that once you instantiate the Sys Mon, you can use any number of Aux IOs as analog and the rest as normal digital IOs. Any Comments on how you do that.. I mean do you need some configuration or the device automatically recognizes which IOs are analog and which are digital.Article: 127828
Thank you very much for replies!Article: 127829
On Jan 8, 9:10=A0pm, MikeShepherd...@btinternet.com wrote: > >...Here are two off the top of my head: > > >1... > >2)... > > Aren't those two reasons enough for avoiding it? > > Or are we just doing your homework? > > Mike Hi Mike, It's been a long time since I've had to do homework, thankfully :-) I'm preparing a set of slides on metastability and synchronization techniques at work. There's a lot of material online on how metastability happens, MTBF, synchronizers, etc. But I realized that it's difficult for me to imagine a real case in which metastability in a FF without a synchronizer causes trouble. This is probably so because the designs have lots of FFs and most of the paths are between FFs, so the first FF to sample the asynchronous event is "kind of" a syncrhonizer anyway. EliArticle: 127830
> > 2) If such an input is sampled by two different FFs for different > > purposes, they may end up with different results. > > This is the case of the *missing* synchronizer. > This is often confused with metastability, > but it is really a design error. > I don't have to wait nearly as long to > observe an error in this case. > Yes, and my question was about the "missing synchronizer", which is a design error as you said. I just wanted an example of real code from real life doing something useful that is susceptible to this design error. EliArticle: 127831
On Jan 8, 9:41=A0pm, Peter Alfke <pe...@xilinx.com> wrote: > On Jan 8, 6:20=A0am, Eli Bendersky <eli...@gmail.com> wrote:> Hello, > > > Suppose that I'm sampling an asynchronous signal with a FF, without > > using any synchronizers before it. This FF will become metastable from > > time to time with a MTBF depending on the device's parameters, the > > clock rate and the input signal change rate. > > Eli, Look at XAPP094 (you can easily google it) It shows the circuit I > have used to quantify metastable delay. > The delay is short, so you have to be quick to catch it... > Peter Alfke > Hi Peter, I downloaded this application note a couple of weeks ago and went through it. Would you say that your metastability-catching circuit could be useful for some real application ?Article: 127832
Is it possible to use DDR SDRAM as single data rate SDRAM and thus eliminate the need for DCM's and tight clock frequency specifications ..? The idea is to ignore the data sent on the second flank, and the timings associated with the DLL. The price is ofcourse half the datacapacity and half the speed. But the benefit is less complicated setup.Article: 127833
On 8 Jan., 18:57, Eli Bendersky <eli...@gmail.com> wrote: > On Jan 8, 6:38 pm, Peter Alfke <pe...@xilinx.com> wrote: > > > On Jan 8, 6:20 am, Eli Bendersky <eli...@gmail.com> wrote:> Hello, > > > > Suppose that I'm sampling an asynchronous signal with a FF, without > > > using any synchronizers before it. This FF will become metastable from > > > time to time with a MTBF depending on the device's parameters, the > > > clock rate and the input signal change rate. > > > Your item #2 describes the most common problem, exacerbated by > > excessive routing delay differences. > > Peter Alfke > > Hi Peter, thanks for answering. > Could you provide a piece of VHDL/Verilog code that is realistic and > has this problem ? In my opinion, this problem is not direct visible from vhdl code. Metastability in real devices is a question of timing and real HW after synthesis. if rising_egde(clk) then internal <= external; high_fanout <= internal; end if is no problem, if your timing allows metastability to settle if it occurs on the FF internal. Assume a technology with metastability often happening for 500 ps and always settling after 2 ns. This means you have no problem if your slack is >2 ns. But what happen if synthesis uses massive registerdoubling for the register high_fanout and layout sets some registers far away reducing your slack to 100 ps for some registers? bye ThomasArticle: 127834
On Jan 9, 7:43=A0am, posedg...@yahoo.com wrote: > Is it possible to use DDR SDRAM as single data rate SDRAM and thus > eliminate the need for DCM's and tight clock frequency > specifications ..? You still have to feed the DDR with appropriate clock signals, because it'll always work with differential clock. If you're working with the Spartan 3E starter kit this means that the clock frequency should be in the range of 75-133 MHz, the DCM is handy because it easily synthesizes these frequencies starting from the 50 MHz soldered clock. > The idea is to ignore the data sent on the second flank, and the > timings associated with the DLL. The price is ofcourse half the > datacapacity and half the speed. But the benefit is less complicated > setup. I'm not sure, but I think that once yuo've done the setup (initialization) correctly, it doesn't make any sense to ignore the second data trunk because it should come at (almost) no additional expense. AndrewArticle: 127835
On Jan 9, 7:57 am, quark.flav...@gmail.com wrote: > On Jan 9, 7:43 am, posedg...@yahoo.com wrote: > > > Is it possible to use DDR SDRAM as single data rate SDRAM and thus > > eliminate the need for DCM's and tight clock frequency > > specifications ..? > > You still have to feed the DDR with appropriate clock signals, because it'll > always work with differential clock. If you're working with the Spartan 3E > starter kit this means that the clock frequency should be in the range of > 75-133 MHz, the DCM is handy because it easily synthesizes these > frequencies starting from the 50 MHz soldered clock. But does the clock frequency have to be within 75-133 MHz range when the data provided by the DLL on the second flank is ignored?, plain SDRAM can be clocked down to a few kHz according to Micron (a dram manufacturer). It would at least save some DCMs and pcb layout headache.Article: 127836
Hi, I've a basic question about spartan3. I'm used to work with altera's FPGA with size unit in logic cells. I've to use a spartan 3 FPGA, and its size is in gates. My question : how can I compare the two FPGA ( just for having an estimation in logic cells ) ? Thanks by advance, Best regards, Michel.Article: 127837
Using a mux on the spi bus does not solve the problem. Since the select signal of this mux is driven by the software, the select mux command will also be called when the uB pointer jumps to the spi_write_subroutine. I had tried that before. Now I will try the solution which checks who called the spi_write_subroutine. Many thanks for your reations!Article: 127838
"Andreas Ehliar" <ehliar-nospam@isy.liu.se> wrote in message news:slrnfo81b1.2gl.ehliar-nospam@sabor.isy.liu.se... > On 2008-01-08, Rgr <rgrworking@hotmail.com> wrote: >> Hi all. >> I am doing a small Processor implementation (with the performance >> somewhat >> like an 8051 CPU), and I am designing for "as low power as possible". >> I want to use reconfigurable logic as I am interested in the the >> flexibility >> and the possibility of adding additional logic to my design. > > I'm no expert in low-power CPLD design, but my first idea is that if you > chose a CPLD without internal memories you will burn quite a lot of power > while communicating with your external program/data memories. > (I could also add the Lattice has a few CPLDs (more like CPLD/FPGA hybrid > with built in RAM which you also might to look into.) If he goes for an Igloo AGL600 then he can use 14Kbyte of internal memory. For "young" engineers :-) that might sound like absolute peanuts, but if you grew up in the ZX81/Acorn Atom/Vic20/Junior/.. era then this is plenty of memory. I just ported one of my designs to a Spartan-3E S500 and could create a 40Kbyte internal memory using just the blockrams, this is plenty of memory for a small embedded control system. http://www.ht-lab.com/hardware/drigmorn1/drigmorn1.html Hans www.ht-lab.com > The question is of course if you are doing this for fun or for a product. > If it is for fun, do whatever you wish and learn from it :) (And if you > learn something interesting while doing this, why not report it to this > newsgroup.) > > If it is for a product I am very doubtful about using a processor in a > CPLD, > especially if low power is a requirement... > > /AndreasArticle: 127839
Hi all, I wonder if it possible to make a MIG1.73 compliant design by connecting 32Mx16 DDR SDRAM to a single bank on a FG320 Spartan3E1200? Btw MIG1.73 compliance is a must for using the MPMC3 memory controller in EDK9.2. Unfortunatelly the MIG coregen does not allow to put all of the DDR pins in a single bank. Since we have a very good example that this is possible - Spartan3E Starter Kit uses only bank3, I wonder how to replicate this design in MIG coregen? Is it the ony way to accomplish that by using the Spartan3E Starter Kit pinout or are there other solutions? Cheers, AlesArticle: 127840
Eli Bendersky wrote: > > > 2) If such an input is sampled by two different FFs for different > > > purposes, they may end up with different results. > > > > This is the case of the *missing* synchronizer. > > This is often confused with metastability, > > but it is really a design error. > > I don't have to wait nearly as long to > > observe an error in this case. > > > > Yes, and my question was about the "missing synchronizer", which is a > design error as you said. > > I just wanted an example of real code from real life doing something > useful that is susceptible to this design error. > > Eli Case 2 is an aperture effect, and as stated, you can create cicuits that will catch this, and cause real problems. It is not so much a VHDL construct as a HW detail error. Pure metastability extends the settling time, but on a very narrow actual trigger window and so is harder to catch causing a problem, but I have often thought as an academic exercise it would be interesting to try to plot the actual statistical tail of the settling time window. Most discussions use a simple model ot a log-log plot, on a couple of data points - fine as a 'there be dragons' type warning, but not what I'd call true engineering.. -jgArticle: 127841
<michel.talon@gmail.com> wrote in message news:8eacbd9c-84fb-425d-804a-8aef977a8be9@v46g2000hsv.googlegroups.com... > Hi, > > I've a basic question about spartan3. I'm used to work with altera's > FPGA with size unit in logic cells. > I've to use a spartan 3 FPGA, and its size is in gates. > My question : how can I compare the two FPGA ( just for having an > estimation in logic cells ) ? Take a number of designs, synthesize using both XST and QNS (or Precision/Synplify if you have an all vendor version) and compare. Hans www.ht-lab.com > > Thanks by advance, > > Best regards, Michel.Article: 127842
On 9 jan, 10:37, "HT-Lab" <han...@ht-lab.com> wrote: > <michel.ta...@gmail.com> wrote in message > > news:8eacbd9c-84fb-425d-804a-8aef977a8be9@v46g2000hsv.googlegroups.com... > > > Hi, > > > I've a basic question about spartan3. I'm used to work with altera's > > FPGA with size unit in logic cells. > > I've to use a spartan 3 FPGA, and its size is in gates. > > My question : how can I compare the two FPGA ( just for having an > > estimation in logic cells ) ? > > Take a number of designs, synthesize using both XST and QNS (or > Precision/Synplify if you have an all vendor version) and compare. > > Hanswww.ht-lab.com > > > > > Thanks by advance, > > > Best regards, Michel. Thank you for your answer, but I've synplify only for Xilinx FPGA.. regards, MichelArticle: 127843
"Andy" <jonesandy@comcast.net> wrote in message news:f4ec2a67-2950-4160-b52c-4dad2f670664@i3g2000hsf.googlegroups.com... > On Jan 8, 3:49 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: >> >> I would have called this an ordinary setup/hold violation. >> >> If the problem is due to timing of bad_input, propagated >> through the MUX that I presume it generates, then it should >> be setup/hold violation. >> >> Metastability should occur due to clock rate issues, through >> the appropriate propagation delay, but independent of bad_input, >> and only if bad_input does satisfy setup/hold. >> >> I would say that the usual cause of option 2 in the previous >> post is also setup/hold violation. >> >> Note that this system can fail even with perfect FFs due to >> different propagation delays. >> >> -- glen > > I agree, #2 is independent of metastability; it is a parallel > synchronizer, which is a bad thing. If the propagation skew is more > than setup+hold to all of the destination registers, it could meet > setup and hold on all of them (avoiding metastability), while still > failing functionally (incrementing by 3). > > Andy Hi Andy, Glen, If bad_input is metastable or asynchronous, you get the same bad effect. HTH., Syms.Article: 127844
Rgr wrote: > Hi all. > I am doing a small Processor implementation (with the performance somewhat > like an 8051 CPU), and I am designing for "as low power as possible". > I want to use reconfigurable logic as I am interested in the the flexibility > and the possibility of adding additional logic to my design. > > Already with aid of the helpful users of this NG I am looking at three > competing products. > The Coolrunner II CPLD from Xilinx > The MAXII from Altera > The IGLOO FPGA from Actel > > When looking at the specs, IGLOO seems to provide the best scores, however, > these come from the manufacturer themselves, so I wondered if somebody has > worked with low power designs with the above mentioned devices - and could > give me some "real-life" experiences? > > If Actels figures are correct, I must admit I have never worked with their > development tools. How are these in user-friendlyness and quality in > comparison with for example the Xilinx product (ISE and EDK). Any > experiences? > "as low power as possible" and PLD are somewhat mutually exclusive. Real designs need some form of timebase, and FPGAs have no low power OSC solutions, so you will need two chips. The better microcontrollers (SiLabs have good 80C51 examples) have sub uA RTC modes, and low uA on chip Osc, and also very fast wakeup of their fast CAL osc's. 32KHz crystals can give very low uA, precison timebase solutions, if you can tolerate their size/startup times/cost/shock trade offs. RC Osc's represent a compromise in uA and precison : choose one, not both :) CAL-OSC offerings are improving all the time. Then you likely also need Brown out detection So you will be best sweeping all the low power timing/analog stuff you can into a STD uC device, and then doing what is left over in a FPGA/ CPLD. For very lowest power, you may want to remove the FPGA core Vcc, and run just the uC. The Lattice MACH4000Z, and Atmel ATF1502BE series are low uA CPLD offerings, for moderate amounts of Logic. Altera have just released their MAX IIZ, so for more logic that's another candidate. -jgArticle: 127845
"Mike Treseler" <mike_treseler@comcast.net> wrote in message news:5uidctF1g9gcdU1@mid.individual.net... > >> 2) If such an input is sampled by two different FFs for different >> purposes, they may end up with different results. > > This is the case of the *missing* synchronizer. > This is often confused with metastability, > but it is really a design error. > I don't have to wait nearly as long to > observe an error in this case. > > -- Mike Treseler Hi Mike, I thought from the OP's post that he means that this 'input' has already been sampled in the system clock domain, although it's not clear. If that is the case, assuming setup and hold are met, this is a metastability problem. If metastable signals only ever go to one place it's not a problem. That's how the input resampler works. Of course, I quite agree that this type of fault most often appears with an asynchronous input going to two destinations. Cheers., Syms. p.s. FYI http://www-ee.eng.hawaii.edu/~msmith/ASICs/HTML/Problems/asp06/PDF/8175.pdf this FF is immune. (Actually, of course it isn't, but it's interesting to see why it doesn't work.)Article: 127846
Rgr wrote: > "John_H" <newsgroup@johnhandwork.com> wrote in message > news:lt6dncs0fYiIrx_anZ2dnUVZ_j-dnZ2d@comcast.com... > > Rgr wrote: > >> Hi. > >> > >> I would like to hear your opinion on the possibility of implementing a > >> processor in a CPLD? > >> The functionality does not have to be greater than the old 8051 CPU, but > >> I would like the flexibility and the possibility of adding additional > >> logic to my design. > >> > >> Has someone worked on this issue, or have an opinion on how to complete > >> this task? > >> > >> Looking forward to your replies > >> Best Regards > > > > The Xilinx PicoBlaze or the open-source Mico-8 from Lattice should both be > > achievable in a CPLD but most CPLDs don't have memory. > > > > While it's more of a simple FPGA than an ASIC, the Altera Max-II series of > > "CPLDs" has some user Flash memory available on-chip. Most CPLDs will > > require external memory. > > > > - John_H > > Thank you both for your very useful replies. > I can see the benefits in utilizing the Max-II series, but have they made a > soft-core processor usable for these CPLD's? Like the PicoBlaze? You can probably find example of Mico8 on Lattice MachXO series. However, if you want low power, using a CPLD is not a good path, and you have to add external code storage in projects of any reasonable size. That's more power, cost, and EMC hits... - much better to choose a small uC that has Code memory on-chip, already power-optimised, and EMC minimised!. Use the FPGA when you have a problem you cannot solve with std devices. -jgArticle: 127847
Michel Worth trying a comparison using ISE Webpack for Xilinx and Quartus Webpack for the Altera. The LUT structures on the Altera are not massively different to Xilinx with the exception the Altera often uses one of the LUT inputs to feed the flip-flop input and Xilinx does not. That sometimes gives a small advantage to Xilinx. The other thing Xilinx have that might be better for some designs is the use of LUTs for local SRAM and possibly more useful the SRL16 mode of the LUT. The latter mode can save lots of logic versus an Altera solution in some designs where it is useful. Other things to consider are how well the number and size of blockrams fit your application. Same goes for the DSP features. On pricing which of the 2 vendors is best is very much design dependent, volume dependent, and often just how much a given vendor wants the business at that moment in time. Sectors and customers go in and out of favour so in 2 different weeks you might get different answers. John Adair Enterpoint Ltd. - Home of Craignell. The Obsolete Component Solution. On 9 Jan, 09:41, michel.ta...@gmail.com wrote: > On 9 jan, 10:37, "HT-Lab" <han...@ht-lab.com> wrote: > > > > > > > <michel.ta...@gmail.com> wrote in message > > >news:8eacbd9c-84fb-425d-804a-8aef977a8be9@v46g2000hsv.googlegroups.com... > > > > Hi, > > > > I've a basic question about spartan3. I'm used to work with altera's > > > FPGA with size unit in logic cells. > > > I've to use a spartan 3 FPGA, and its size is in gates. > > > My question : how can I compare the two FPGA ( just for having an > > > estimation in logic cells ) ? > > > Take a number of designs, synthesize using both XST and QNS (or > > Precision/Synplify if you have an all vendor version) and compare. > > > Hanswww.ht-lab.com > > > > Thanks by advance, > > > > Best regards, Michel. > > Thank you for your answer, but I've synplify only for Xilinx FPGA.. > > regards, Michel- Hide quoted text - > > - Show quoted text -Article: 127848
Guru wrote: > Hi all, > > I wonder if it possible to make a MIG1.73 compliant design by > connecting 32Mx16 DDR SDRAM to a single bank on a FG320 Spartan3E1200? > Btw MIG1.73 compliance is a must for using the MPMC3 memory controller > in EDK9.2. > > Unfortunately the MIG coregen does not allow to put all of the DDR > pins in a single bank. It wasn't a problem in MIG 1.5, and when MIG 1.6 came out, I verified that it generated a ucf with the same pinouts as MIG1.5. I haven't tried MIG 1.7. --- Joe Samson Pixel VelocityArticle: 127849
On Tue, 8 Jan 2008 22:19:02 -0800 (PST), Eli Bendersky <eliben@gmail.com> wrote: >On Jan 8, 9:10 pm, MikeShepherd...@btinternet.com wrote: >> >...Here are two off the top of my head: >> >> >1... >> >2)... >> >> Aren't those two reasons enough for avoiding it? >> >> Or are we just doing your homework? >> >> Mike > >Hi Mike, > >It's been a long time since I've had to do homework, thankfully :-) >I'm preparing a set of slides on metastability and synchronization >techniques at work. There's a lot of material online on how >metastability happens, MTBF, synchronizers, etc. But I realized that >it's difficult for me to imagine a real case in which metastability in >a FF without a synchronizer causes trouble. This is probably so >because the designs have lots of FFs and most of the paths are between >FFs, so the first FF to sample the asynchronous event is "kind of" a >syncrhonizer anyway. Here's something you can include in your training material. It's from a c.a.f. post I made in 2003: "When I was at Agilent I analysed the causes of failures in some FPGA developments. About half of all FPGA design related bugs (weighted by the time spent finding them) were associated with asynchronous logic and clock domain crossings. I guess that's not too surprising. What you may find surprising is that 0% of the clock domain crossing bugs had anything to do with metastability. Glitches and races were the cause. My interpretation: I think that most designers have heard of metastability, so they put retiming flip flops everywhere. Consequently, metastability related problems don't occur often. YMMV." Regards, Allan
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