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
"Michael J." <michajo@gmx.de> wrote in message news:ae9hkj$a11$1@nets3.rz.RWTH-Aachen.DE... > Hi all, > > in my design a EP20K200CQ240C7 gets his > configuration from 2 EPC2. After configuration > the APEX runs for ~500 ms then configuration > restarts ~200 ms and so on. > An endless loop ....... > > What may be wrong ? > > Thanks in advance > Michael Have you put the proper pullup resistors to the nConfig etc. lines? Download the latest version of Appnote 116 from the Altera website and compare it with your schematic. Could also be crosstalk or so. Best regards, BenArticle: 44201
I don't want to spoil your fun but this sounds like something that might already be available. Look at those PC intrumentation guys like National Instruments and the like, they may have something you can use or that can be gated. Regards p.s. PDP-11, I haven't seen those used for a while. John_H <johnhandwork@mail.com> wrote in message news:<3D067F61.FADAE0B@mail.com>... > Another idea for lots of capability in small space depending on the detail of your > needs. If you want your read value accurate to a few nanoseconds *and* you need > access to multiple values with a few 10s of nanoseconds, this approach wouldn't > work. > > Use a Virtex-II XC2V40 device. > > Bring the gate in on the DDR input registers. > > For N counters, use N lower count stages of only a few bits to add zero, one, or two > bits depending on the DDR gate. > > Cycle through a dual-port CLB SelectRAM (or BlockRAMs for that matter), replacing > the LSbits with the live lower stage value and incrementing the upper bits by one as > appropriate. This function can be done at a slower speed than the counter. > > Read the count value directly from the dual-port RAM. > > If you need a read strobe to catch a live count value rather than one that's a few > cycles off due to the cycling, you can add a little logic to preempt the normal > cycling and process the live value. > > The resolution and capabilities you want could probably support up to 64 counters of > 32 bits each at nearly 800MHz (based on DDR capabilities but possibly limited by > 8-bit 0/+1/+2 adders) in a part you can get for a decent price. > > A fun little project.Article: 44202
Aw man! I'm still using mostly 7.03 because I have a couple projects that started before 7.1
came out and I don't like switchin horses midstream. I guess we now will have to put the syn
keeps before the LUT (!!!). That does get messy. I'm still very annoyed that Synplify thinks
that if it can figure out what is in a black box (by virtue of the black box happening to be a
xilinx primitive) it has a right to muck with it. As far as I am concerned, if it is a black
box, it should not be mucked with PERIOD. Of course the Synplicity response is that they don't
see it as a real problem. This is right up there with the tristate push through issue. It
completely wrecks the libraries I've put together over the past 3 years. Guess I'll be
spending time looking for a work-around once again :-(
John_H wrote:
> I "hadn't" had many problems with MUXCYs either. 7.1 is messing me up. With a syn_keep on
> the LUT outputs, Synplify is adding a LUT1_2 (through-wire) between the keepbuf and the
> MUXCY select. Since the Xilinx P&R tools don't expect such superfluous slop, it dutifully
> implements the LUT1_2 with the MUXCY and the LUT that *should* drive it ends up in the
> adjacent LUT, out through .Y and back in through .BX - yeesh.
>
> Ray Andraka wrote:
>
> > I haven't had too much trouble with the MUXCY's if I put syn_keeps on the LUT output
> > driving the select.
> >
> > Brian Davis wrote:
> >
> > > John_H wrote:
> > > >
> > > >I tried a MUXCY primitive redefinition (I called it MUXCYdammit) with
> > > >syn_hier="hard" like I did earlier with an FDRE but if you push down
> > > >into the instance in HDL_Analyst, there's a pass-LUT on the sel input.
> > > >
> > >
> > > By "redefinition", do you mean:
> > >
> > > A) put a MUXCYdammit wrapper with syn_hier="hard" around a MUXCY
> > >
> > > or,
> > >
> > > B) black box something called MUXCYdammit and edit the EDIF
> > > post-synthesis to fix up the primitive names
> > >
> > > I think "B" is fairly bulletproof, but you need a search-and-replace
> > > to fix up the EDIF names, and a wrappered simulation library to let you
> > > sim the primitives that have the tiny brown paper bags over their heads.
> > >
> > > Brian
> > >
> > > John_H <johnhandwork@mail.com> wrote in message news:<3D07B0CB.F77B1634@mail.com>...
> > > > I'm having MUXCY trimming problems *right now*. I tried to take my 29 MUXCY
> > > > instantiations and convert them into an array of instances. Yuck! The physical
> > > > implementation of my chain became toast once Synplify started "optimizing" the pass
> > > > elements out of the chain (I have several in the middle).
> > > >
> > > > The inclusion of oh-so-many LUT1_2 elements is getting at my nerves as well: I
> > > > tried a MUXCY primitive redefinition (I called it MUXCYdammit) with syn_hier="hard"
> > > > like I did earlier with an FDRE but if you push down into the instance in
> > > > HDL_Analyst, there's a pass-LUT on the sel input. Once again Synplify knows
> > > > better. Oy.
> > > >
> > > > The apps engineers are looking at my chain, but I imagine it's back to the 29
> > > > individual instances. I hope those aren't broken!
> > > >
> > > > - John_H
> > > >
> > > >
> >
> > --
> > --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
--
--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: 44203You are probably asserting nCONFIG somehow. That would initiate a reconfiguration. Monitor that line, and see if something is pulling it down, or if there are any glitches on it once in user-mode good luck "Michael J." <michajo@gmx.de> wrote in message news:<ae9hkj$a11$1@nets3.rz.RWTH-Aachen.DE>... > Hi all, > > in my design a EP20K200CQ240C7 gets his > configuration from 2 EPC2. After configuration > the APEX runs for ~500 ms then configuration > restarts ~200 ms and so on. > An endless loop ....... > > What may be wrong ? > > Thanks in advance > MichaelArticle: 44204
John_H wrote: <snip> > The wide range of frequencies is, indeed, very important. I had kept close to my > engineering heart the "truth" that more capacitance is most often a good thing, that low > capacitance values were silly. If I throw together a dozen 1uF ceramic caps, I end up > with a nice low impedance at the SRF but not so very low a decade or two above or > below. One graph I'm looking at shows an SRF of about 7MHz for a 1uF 1206. The > impedance at 7MHz is about 0.1 Ohm each. The impedance drops to 1ohm around 250kHz and > 150MHz. While these values aren't bad, consider the current demands for 150MHz: 1/12 > Ohm (12 1uF caps in parallel, ignoring other parasitics for the moment) will keep the > voltage tolerance within 100mV for 1.2A surges. Sudden load step-response is very important. The Pentium power supplies know all about this, and bigger FPGA ones should too. > Maybe this is sufficient, but one cap > with an SRF around 150MHz would give you performance nearly as good at 150MHz. Not sure you can move from load step, to this SRF comment - a load step cannot have a single-point 150Mhz spectrum ? > The 7MHz > filtering in the 12 cap configuration above is probably significant overkill at 8.3 > milliOhm. A mix would allow a low overall impedance floor without overkill. I think where SRF _can_ help, is not so much in total lowering, but in a 'focus on area of complaint' - eg a marine radio telephone user at 156MHz etc. The tolerances and tempco's are such that the notch will move about a bit anyway... -jgArticle: 44205
Hello, when writing to ram (e.g. block ram in a virtex) must the signals to the ram come from a register? The timing diagrams I found implicate this (e.g. http://www.free-ip.com/ramlib/ram_dp.html ). The adress signal or the 'write enable' signal have a very short delay in my design. But the data word I want to store is the critical path and so arrives at the end of the clock period. Is this sufficient for the ram to sample the data? Kind regards, HolgerArticle: 44206
Damir Danijel Zagar wrote: > Hi, > > I've successfuly implemented design on Spartan II 200 but during > JTAG programming (Parallel Cable IV) verification fails on 257 > location. Also, when manualy identifying the JTAG chain, Spartan > is reported as Virtex. Otherwise FPGA works fine and user ID > code is readable without any problem. What could cause the > verification problems? Regards, The Parallel Cable does not work with certain motherboards, due to the particular chip in the parallel port. Others work with very high reliability. So, you might try it with a different PC and see if it works better. I have experienced this in a couple of cases, and then found a PC that worked well, and used that one for the JTAG programming or download. JonArticle: 44207
BurchED now sells a low cost board based on the XC2S300E. http://www.burched.com.au/B5Spartan2.html Excellent value at US$190. Best regards Tony Burch http://www.BurchED.com Low cost FPGA boards, for System-On-Chip prototyping and education "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:aeao2h$5bfsh$1@ID-84877.news.dfncis.de... > "Roger King" <roger@king.com> schrieb im Newsbeitrag > news:lRvN8.287033$t8_.195817@news01.bloor.is.net.cable.rogers.com... > > I don't have the info, but what about the XC2S50 chip/family? > > XC2S50 is a Spartan-II, 50k gates (whatever gates means . .;-) > > It has also 6 BlockRams, 4kbit each. > > > and is that a good number? > > XC2S50 is a nice chip to start with. But as others already said, go for a > 200K or 300K gates device, they cost not much more (together with a > demoboad). > Also remember, the bigger the device, the cheaper the logic funktions > ($/LUT), with some minor exceptions. > > -- > MfG > Falk > > > >Article: 44208
Hristo Stevic wrote: > > Hellom > is there any compatibility issue between the Foundation 3.1 and > Foundation 4.1. I use schematic entry Hristo, I don't think schematics from 3.1 can be read into 4.1. Regards, JohnArticle: 44209
The "notch" isn't a 20dB dip in a 1% bandwidth as notch filters would. The SRF gives the bottom of a somewhat wide bottom. My point is that - rather than paralleling a bunch of these "bathtubs" to get an overall "bathtub" curve so that the ends provide a low enough impedance - one should get the SRFs lined up across a wide enough coverage that the overall impedance floor is much wider at a target impedance. A 10:1 impedance for the 1uF cap I mentioned is about 250kHz to 150 MHz. If the minimum impedance on the chosen caps are low and the SRFs are distributed, the overall effect is greater wideband stiffness. Load-step response is addressed by spreading the SRFs across a range of frequencies. The clock has harmonics and the data tends to downspread, including those harmonics. There's a time domain for the step and a frequency domain for the impedances that need to line up to each other. The balance can be struck without "one 0.1uF and one 0.01uF cap per power/ground pin pair." The single-point spectrum isn't my concern as much as "covering holes." Make sure your impedance at all frequencies is low. If the impedance could be improved across a frequency band that isn't stiff enough, add a cap that covers that hole. The tolerances and tempcos will move the bottom around a little, but compared to the 2x bottom of around 2-20MHz, (0.2 ohm @ 2MHz, 0.1 ohm @ 7 MHz, 0.2 ohm at 20 MHz), several percent changes won't skew a decade of good impedance. Jim Granville wrote: > John_H wrote: > <snip> > > The wide range of frequencies is, indeed, very important. I had kept close to my > > engineering heart the "truth" that more capacitance is most often a good thing, that low > > capacitance values were silly. If I throw together a dozen 1uF ceramic caps, I end up > > with a nice low impedance at the SRF but not so very low a decade or two above or > > below. One graph I'm looking at shows an SRF of about 7MHz for a 1uF 1206. The > > impedance at 7MHz is about 0.1 Ohm each. The impedance drops to 1ohm around 250kHz and > > 150MHz. While these values aren't bad, consider the current demands for 150MHz: 1/12 > > Ohm (12 1uF caps in parallel, ignoring other parasitics for the moment) will keep the > > voltage tolerance within 100mV for 1.2A surges. > > Sudden load step-response is very important. The Pentium power supplies > know all > about this, and bigger FPGA ones should too. > > > Maybe this is sufficient, but one cap > > with an SRF around 150MHz would give you performance nearly as good at 150MHz. > > Not sure you can move from load step, to this SRF comment - a load step > cannot have > a single-point 150Mhz spectrum ? > > > The 7MHz > > filtering in the 12 cap configuration above is probably significant overkill at 8.3 > > milliOhm. A mix would allow a low overall impedance floor without overkill. > > I think where SRF _can_ help, is not so much in total lowering, but in > a > 'focus on area of complaint' - eg a marine radio telephone user at > 156MHz etc. > > The tolerances and tempco's are such that the notch will move about a > bit anyway... > > -jgArticle: 44210
You can treat the BlockRAM inputs as if they were a register. There is a clock edge, and you have to meet the set-up times for CE, WE, Address, and Data (if write). That's all. The enabled clock edge starts a sequence of actions, latches up the address, then reads and if required writes data. But you only have to abide by the timing requirements, i.e. the set-up times. Viele Gruesse Peter Alfke, Xilinx Applications =================================== Holger Kleinegraeber wrote: > Hello, > > when writing to ram (e.g. block ram in a virtex) must the signals to the ram > come from a register? The timing diagrams I found implicate this (e.g. > http://www.free-ip.com/ramlib/ram_dp.html ). The adress signal or the 'write > enable' signal have a very short delay in my design. But the data word I > want to store is the critical path and so arrives at the end of the clock > period. Is this sufficient for the ram to sample the data? > > Kind regards, > HolgerArticle: 44211
In article <3D092CA2.60C1A024@xilinx.com>, Peter Alfke <Peter.Alfke@xilinx.com> wrote: >You can treat the BlockRAM inputs as if they were a register. >There is a clock edge, and you have to meet the set-up times for CE, WE, >Address, and Data (if write). That's all. >The enabled clock edge starts a sequence of actions, latches up the address, >then reads and if required writes data. But you only have to abide by the timing >requirements, i.e. the set-up times. However, note that the set-up time can be considerable, especially for the WE, so that if performance is a goal, having a register in front of the BlockRAM may be useful, but it isn't manditory. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 44212
Ray Andraka wrote: > Aw man! I'm still using mostly 7.03 because I have a couple projects that started before 7.1 > came out and I don't like switchin horses midstream. I guess we now will have to put the syn > keeps before the LUT (!!!). That does get messy. I'm still very annoyed that Synplify thinks > that if it can figure out what is in a black box (by virtue of the black box happening to be a > xilinx primitive) it has a right to muck with it. As far as I am concerned, if it is a black > box, it should not be mucked with PERIOD. Of course the Synplicity response is that they don't > see it as a real problem. This is right up there with the tristate push through issue. It > completely wrecks the libraries I've put together over the past 3 years. Guess I'll be > spending time looking for a work-around once again :-( Look like once again we have a good->v.good product being damaged by post-IPO arrogance ... or is it just another symptom of the constant drift towards the ``push the big green button'' approach ? I don't instantiate as much as you do but I absolutely concur that an instantiated black box component should just be left alone, FULL STOP (US = PERIOD), no questions - its *my* decision to do this *not* the tool's If I have to instantiate then its because the tool, together with any syn directives/attributes, is not getting me what I want from the RTL so the last thing I want is yet more messing about. Instead of wasting time on this rubbish [and tri-state push through is even more ludicrous] why can't Synplicity get the register replication stuff working as well it did for 5.x ? In the sprirt of this thread I'd like to add a new directive: syn_dont_buffer_signals_or_replicate_luts_since_it_always_makes_things_worse or syn_if_you_cant_reduce_fanout_by_replicating_ffs_then_leave_the_net_aloneArticle: 44213
John_H wrote: > > The "notch" isn't a 20dB dip in a 1% bandwidth as notch filters would. The SRF gives the > bottom of a somewhat wide bottom. My point is that - rather than paralleling a bunch of these > "bathtubs" to get an overall "bathtub" curve so that the ends provide a low enough impedance - > one should get the SRFs lined up across a wide enough coverage that the overall impedance > floor is much wider at a target impedance. A 10:1 impedance for the 1uF cap I mentioned is > about 250kHz to 150 MHz. If the minimum impedance on the chosen caps are low and the SRFs are > distributed, the overall effect is greater wideband stiffness. > > Load-step response is addressed by spreading the SRFs across a range of frequencies. The > clock has harmonics and the data tends to downspread, including those harmonics. There's a > time domain for the step and a frequency domain for the impedances that need to line up to > each other. The balance can be struck without "one 0.1uF and one 0.01uF cap per power/ground > pin pair." > > The single-point spectrum isn't my concern as much as "covering holes." Make sure your > impedance at all frequencies is low. If the impedance could be improved across a frequency > band that isn't stiff enough, add a cap that covers that hole. > > The tolerances and tempcos will move the bottom around a little, but compared to the 2x bottom > of around 2-20MHz, (0.2 ohm @ 2MHz, 0.1 ohm @ 7 MHz, 0.2 ohm at 20 MHz), several percent > changes won't skew a decade of good impedance. Sounds right to me. Anyone got any practical experience with SRF spread & deployment, on real PCBs ? -jgArticle: 44214
Hi. Im new to FPGA world. I must say I havent stepped in. But am very interested. Ive access to some fpga material mostly data books of Xilinx. Could you pls suggest where do I start learning the programming. thanks ananthArticle: 44215
Ananth wrote: > Hi. > > Im new to FPGA world. I must say I havent stepped in. But am very > interested. Ive access to some fpga material mostly data books of > Xilinx. Could you pls suggest where do I start learning the > programming. > > thanks > ananth Ananth, welcome to the exciting world of programmable logic, where you can create and change circuits almost without effort. I would suggest that you first look at the FPGA architecture, i.e. logic, flip-flops, and memory available on these chips. Then you must come up with some idea what you want to implement. Finally, you decide on a design methodology, schematic or High-Level Language. There are design kits available from various distributors and other manufacturers. Have fun! Peter Alfke, Xilinx ApplicationsArticle: 44216
Rick Filipkiewicz wrote: > In the sprirt of this thread I'd like to add a new directive: > > syn_dont_buffer_signals_or_replicate_luts_since_it_always_makes_things_worse > > or > > syn_if_you_cant_reduce_fanout_by_replicating_ffs_then_leave_the_net_alone Actually, that was my other call to the help line... <quote> Hello John, I am very sorry but I gave you some wrong info. The attribute to prevent the replication for speed is not syn_preserve, it is called syn_replicate. This attribute can either be set globaly or on a specific register. </quote> The syn_replicate is supported starting in 7.1. I haven't used it yet but it sounds like *just* the thing I wanted. The _fast replicants are one of my biggest sore spots making my synthesize at "50 MHz" instead of "133 MHz" just to avoid that nonsense.Article: 44217
Rick Filipkiewicz wrote:
>
> In the sprirt of this thread I'd like to add a new directive:
>
> syn_dont_buffer_signals_or_replicate_luts_since_it_always_makes_things_worse
>
> or
>
> syn_if_you_cant_reduce_fanout_by_replicating_ffs_then_leave_the_net_alone...
...and_if_it_is_an_instantiated_ff_then_don't_replicate_it_either
--
--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: 44218
John_H wrote:
> Rick Filipkiewicz wrote:
>
> > In the sprirt of this thread I'd like to add a new directive:
> >
> > syn_dont_buffer_signals_or_replicate_luts_since_it_always_makes_things_worse
> >
> > or
> >
> > syn_if_you_cant_reduce_fanout_by_replicating_ffs_then_leave_the_net_alone
>
> Actually, that was my other call to the help line...
>
> <quote>
> Hello John,
> I am very sorry but I gave you some wrong info. The attribute to prevent
> the replication for speed is not syn_preserve, it is called syn_replicate.
> This attribute can either be set globaly or on a specific register.
> </quote>
>
> The syn_replicate is supported starting in 7.1. I haven't used it yet but it sounds like *just* the
> thing I wanted. The _fast replicants are one of my biggest sore spots making my synthesize at "50 MHz"
> instead of "133 MHz" just to avoid that nonsense.
Ayup, I often set the target speed to ZERO to keep it from doing that nonsense...of course that kills any
RTL stuff that has more than 4 inputs.
--
--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: 44219Asked an Application engineer today and he mentioned that there is about 5-1 ratio between custom ASICs and the Xilinx basic FPGA. So I guess a 20K Xilinx part would actually be a 4K custom ASIC in size. I tend to think in the ASIC sizes so the rule is good for estimation. From our latest work in verifying our DSP IP for FPGAs I would say that he is pretty close if your synthesizer doesn't use some of the newer blocks like the multipliers in the new Virtex 2 line. If your synthesizer maps to these new blocks then that ratio can improve a bit. Sam Gladstone Digital Design Engineer Acculent Corporation samg@acculentdsp.com On Fri, 14 Jun 2002 09:01:22 +1000, "Tony Burch" <tony@burched.com.au> wrote: >BurchED now sells a low cost board >based on the XC2S300E. >http://www.burched.com.au/B5Spartan2.html >Excellent value at US$190. > >Best regards >Tony Burch >http://www.BurchED.com >Low cost FPGA boards, for System-On-Chip >prototyping and education > >"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message >news:aeao2h$5bfsh$1@ID-84877.news.dfncis.de... >> "Roger King" <roger@king.com> schrieb im Newsbeitrag >> news:lRvN8.287033$t8_.195817@news01.bloor.is.net.cable.rogers.com... >> > I don't have the info, but what about the XC2S50 chip/family? >> >> XC2S50 is a Spartan-II, 50k gates (whatever gates means . .;-) >> >> It has also 6 BlockRams, 4kbit each. >> >> > and is that a good number? >> >> XC2S50 is a nice chip to start with. But as others already said, go for a >> 200K or 300K gates device, they cost not much more (together with a >> demoboad). >> Also remember, the bigger the device, the cheaper the logic funktions >> ($/LUT), with some minor exceptions. >> >> -- >> MfG >> Falk >> >> >> >> > >Article: 44220
Gate count is known to be a meaningless measure of FPGA capability. Take the simple case of a Xilinx look-up table. Xilinx counts it as about 6 gates ( 12 gates together with the associated flip-flop). The user might see it as a single gate, or, at the other extreme, as a 16-bit shift register, in which case it is worth at least sixty ASIC gates. Anything with an uncertainty range from 1 to 60 is a lousy measuring stick. And how do you count clock management, carry, I/O flexibility etc ? Five-to-one? Just give up, and realize that it's futile! Peter Alfke, Xilinx Applications ================= samg@codenet.net wrote: > Asked an Application engineer today and he mentioned that there is > about 5-1 ratio between custom ASICs and the Xilinx basic FPGA. > So I guess a 20K Xilinx part would actually be a 4K custom ASIC in > size. I tend to think in the ASIC sizes so the rule is good for > estimation. > From our latest work in verifying our DSP IP for FPGAs I would > say that he is pretty close if your synthesizer doesn't use some of > the newer blocks like the multipliers in the new Virtex 2 line. > If your synthesizer maps to these new blocks then that ratio can > improve a bit. > > Sam Gladstone > Digital Design Engineer > Acculent Corporation > samg@acculentdsp.com > > On Fri, 14 Jun 2002 09:01:22 +1000, "Tony Burch" <tony@burched.com.au> > wrote: > > >BurchED now sells a low cost board > >based on the XC2S300E. > >http://www.burched.com.au/B5Spartan2.html > >Excellent value at US$190. > > > >Best regards > >Tony Burch > >http://www.BurchED.com > >Low cost FPGA boards, for System-On-Chip > >prototyping and education > > > >"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message > >news:aeao2h$5bfsh$1@ID-84877.news.dfncis.de... > >> "Roger King" <roger@king.com> schrieb im Newsbeitrag > >> news:lRvN8.287033$t8_.195817@news01.bloor.is.net.cable.rogers.com... > >> > I don't have the info, but what about the XC2S50 chip/family? > >> > >> XC2S50 is a Spartan-II, 50k gates (whatever gates means . .;-) > >> > >> It has also 6 BlockRams, 4kbit each. > >> > >> > and is that a good number? > >> > >> XC2S50 is a nice chip to start with. But as others already said, go for a > >> 200K or 300K gates device, they cost not much more (together with a > >> demoboad). > >> Also remember, the bigger the device, the cheaper the logic funktions > >> ($/LUT), with some minor exceptions. > >> > >> -- > >> MfG > >> Falk > >> > >> > >> > >> > > > >Article: 44221
On Thu, 13 Jun 2002 11:28:09 GMT, in comp.arch.fpga, Allan Herriman and Ray Andraka wrote: [snip] : :3. Set the generic TimingChecksOn to FALSE when you instantiate the :FD. You will need to put in pragmas to stop the synthesiser from :seeing the generics: : :ff : FD : -- synopsys translate_off : generic map ( : TimingChecksOn =3D> FALSE : ) : -- synopsys translate_on : port map ( : .... Hmm, I try that, & get "undefined identifier TimingChecksOn" messages. This seems to imply that TimingChecksOn is not a generic of FD. Have I missed something? (I am using the standard mapping of UNISIM). Also, is it possible to get the timing checks turned off when running VSIM from the GUI, or is it only possible from the command line? (I see no parameter in MODELSIM.INI that would control it.) TIAArticle: 44222
Hi,Everybody! I am a novice at FPGA design,but I am very interested in it. I have completed a multiplexer design based on FPGA,and I feel I am so poor at the FPGA and its relative technologies such as:system plan,simulation,verification, etc. So welcome anyone interested in FPGA and Me(^_^) contact with me.Article: 44223
Thank you Mike and Ben, nCONFIG wasn't connected propperly. Now it works !! MichaelArticle: 44224
Jim Granville <jim.granville@designtools.co.nz> writes: > Anyone got any practical experience with SRF spread & deployment, on > real PCBs ? > My last design (2 Altera 10KE100s and a TI C6711 amongst other things) has a power distribution system designed in just such a way as to keep the imppedance flattish and beneath a target impedance (as suggested in http://groups.yahoo.com/group/si-list/files/Signal%20Integrity%20Documents/Published%20SI%20Papers%20from%20Sun/cpmt_1999.pdf - apologies for a the long link!) Seems to work well, although I haven;t had chance to get any actual numbers from it - other than the noise on the various power planes (as viewed on a Tek LogiScope @ up to 2Gs/sec) is much less than the 5% tolerance. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conekt
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