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
>Reasonably, such a chip will need to have an external flash memory >and the pins between the FPGA and the Flash. Good point, but... It depends upon the problem. Lots of interesting problems will fit into on-chip RAM. They might fit better into a special purpose CPU. That costs more design time. External serial flash will be horribly slow, but might be good enough for some problems. Only takes a few pins. You could use on chip RAM for a cache or load it explicitly (bank switching). -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 77901
What if i design an asynchronous memory in Stratix devices?? Will it create any design problems??Article: 77902
Hal Murray wrote: >>Reasonably, such a chip will need to have an external flash memory >>and the pins between the FPGA and the Flash. > > > Good point, but... It depends upon the problem. > > Lots of interesting problems will fit into on-chip RAM. > They might fit better into a special purpose CPU. That > costs more design time. The PicoBlaze, and tiniest variant of NIOS are interesting forthis > > External serial flash will be horribly slow, but might be good > enough for some problems. Only takes a few pins. You could > use on chip RAM for a cache or load it explicitly (bank switching). Yes, a core that used 50MHz SPI memory, and was optimised for serial-code fetch could be quite interesting.... -jgArticle: 77903
I have an unpublished success-story about using MicroBlaze in Commercial Product using XC2S100 with no external memory. Thats I think the smallest FPGA where Microblaze (at least Xilinx version!) can be used. The open- source MicroBlaze used in simple controller fashion could possible be useable in S50 too. Or small smallest Cyclone :) And some comments to previous posters it is possible: 1) to run NIOS-II in Xilinx FPGA 2) to run Microblaze in Altera FPGA well at least I have tried both :) AnttiArticle: 77904
Hi Rick, If you have such a board, would you sell me one ? I need just one! Thanks OlivierArticle: 77905
James Morrison wrote: (snip) > Not true. Its not the frequency that matters but the edge rate. Given > the 4 bits and clock it sounds an awful lot like the TigerSHARC link > port and it has a very fast edge rate. The data sheet indicates a MAX > of 200ps (that's pico-seconds). If you believe in Fourier you know that edge rate is frequency. > Anyways, at that edge rate any change in impedance in the trace will > cause reflections. If the path of the differential pair through the > connector has a different impedance than the rest of the trace you will > get a reflection. In fact you'll get two--one at each side of the > connector. That is the difference in high-speed connectors--they pay > attention to this. Well, the two reflections will partially cancel in many cases. That is why you don't notice them at lower frequencies. Even at 200ps the wavelength is still significantly longer than most connectors. > Now it is true that the trace length through the connector needs to be > matched as well. Otherwise you'll get the + and - signals getting out > of phase. Out of phase relative to what? There are coaxial cables where the center conductor is helical to increase its inductance. Signal velocity depends on the inductance per unit length of the shield and center conductor, but one doesn't arrive at the other end ahead of the other. -- glenArticle: 77906
I am a bit confused. I have never seen such syntax even though I read a lot
of
C++ codes.
Thanks for your suggestion...
BluetoothReceiver::BluetoothReceiver()
: bandpassFilter(BPLENGTH),
differentiatorFilter(DIFFLENGTH)
{
m_bitrate = 1;
m_bitDelay = BITDELAYBT;
// Compute Bandpass filter coefficients and
const double h0 = sqrt(2.0) * Br;
const double kexp = -twopi * Br * Br;
for (int i=0; i<bandpassFilter.size(); ++i) {
double temp = i - (BPLENGTH *1.)/2.+.5;
temp /= Ns;
double hreal = h0 * exp(kexp * temp * temp);
bandpassFilter[i] = Sample(hreal,0.0);
}
// Set Differentiator filter coefficients
differentiatorFilter[0] = Sample(-0.0062, 0.0);
differentiatorFilter[1] = Sample(0.0372, 0.0);
differentiatorFilter[2] = Sample(-0.4566, 0.0);
differentiatorFilter[3] = Sample(0.4566, 0.0);
differentiatorFilter[4] = Sample(-0.0372, 0.0);
differentiatorFilter[5] = Sample(0.0062, 0.0);
}
Article: 77907Compared with a normal Stratix, is a HardCopy version immune to SEUs? I'd have thought the possibility of a configuration error is reduced to zero as the configuration SRAM cells have gone but an event in the logic is still possible. Does anyone have any ideas (or figures maybe)? TIA Rog.Article: 77908
Hi Georgi, For Higher speeds, I would recommend the AMP Mictor connectors. This document is a useful design guide: http://www.latticesemi.com/lit/docs/technotes/tn1033.pdf Regards Mark Smith Strategic Marketing Lattice SemiconductorArticle: 77909
James Morrison wrote: > On Wed, 2005-01-19 at 17:29 -0800, Marc Randolph wrote: > > I hate to say that it doesn't matter, but in the grand scheme of > > things, the type or style of the connector is not of huge importance at > > that speed, as long as one pin isn't massively longer than another > > (which occurs with some types of right angle connectors). We run many > > times that speed using the worst connector you can imagine. > > > > Much more important is the stuff that Brad mentioned: keep _p/_n pair > > trace length the same and routed as a diff pair into and out of the > > connector - and routed against a ground plane if possible. Give > > yourself a ground pin next to each pair within the connector. > > Not true. Its not the frequency that matters but the edge rate. Howdy James, I was figuring that someone would disagree with what I said - I just didn't figure it would be within a half hour! I was actually referring to the whole solution when I was referring to the speed: signalling type (LVDS, which has slower edges than PECL and CML), termination location (hopefully on-chip), voltage swing, etc. > Given > the 4 bits and clock it sounds an awful lot like the TigerSHARC link > port and it has a very fast edge rate. The data sheet indicates a MAX > of 200ps (that's pico-seconds). No arguing that 200ps is fast. But it is fast enough to cause problems on a properly terminated and routed differential pair? Our extensive experience on our telecom boards have shown it isn't even close to causing problems. In fact, I was referring to both CML *and* LVDS when I was mentioning our past experience. CML has edge rates closer to 100ps. > Anyways, at that edge rate any change in impedance in the trace will > cause reflections. If the path of the differential pair through the > connector has a different impedance than the rest of the trace you will > get a reflection. In fact you'll get two--one at each side of the > connector. That is the difference in high-speed connectors--they pay > attention to this. And the the termination that differential signals have do an excellent job of minimizing those reflections. Go check out the people running LVDS buses with 20 drops! > Now it is true that the trace length through the connector needs to be > matched as well. Otherwise you'll get the + and - signals getting out > of phase. > > You'll always have slight mismatches in impedance and trace length. But > with a 200ps edge rate you have a lot less margin for error than at more > reasonable rates. The beauty of terminated differential signalling is that you have such an improved signal infrastructure, I think you actually have more margin than you had with signal ended, unterminated signals that swing all the way from 3.3v, even if their edge rates were "only" 1.5ns. I think that's where people go wrong... while the concepts between unterminated single-ended and terminated differential are close to the same, the rules of thumb for one don't translate well to the other. I stand by my original post. Let the flames begin. MarcArticle: 77910
Hi. A colleague and me are having problems getting the SignalTap II Logic Analyzer from Quartus II running on our Stratix device. We compiled a NIOS example-design and programmed it to the device. We know the example is working because we loaded a little C-program to the NIOS which resulted in correct output. We also tried to use Signaltap with a self-created simple design but this also didn't work. We tried to use the SignalTap II Logic Analyzer in two ways: 1) We opened the Signaltap II Logic Analyzer from the Tools menu in Quartus. There we added the nodes we tried to analyze. We enabled SignalTap II Logic Analyzer in the project's settings and chose the created stp-file there. We followed the instructions we got from the program which told us to compile the design and then to program the device. After programming the device, SignalTap still told us to program the device. In the documention it says that "Ready to acquire" should be the next message but we still get "Program the device to continue". When we try to ignore the message and acquire data anyway we get a JTAG communication error. 2) The second way was to create an instance of a SignalTap II Logic Analyzer using the MegaWizard Plug-In Manager and added it to the design. We connected the inputs (clock, data, trigger), then we created a stp-file using the menu item as described in the documentation. This way we encountered the same problems as before. We don't know what we are doing wrong, can anybody help us getting the SignalTap II Logic Analyzer running? Thanks.Article: 77911
Which part, in particular, is confusing?
"BluetoothReceiver::BluetoothReceiver() : bandpassFilter(BPLENGTH),
differentiatorFilter(DIFFLENGTH) {...}" is the default constructor. The
stuff after the ":" is the initialization list and may be used to
initialize member objects or base class portions of a derived object.
My guess is that bandpassFilter and differentiatorFilter are both
contained by BluetoothReceiver and are initialized with BPLENGTH and
DIFFLENGTH upon construction.
Article: 77912Hi vlsi_learner, > What if i design an asynchronous memory in Stratix devices?? > Will it create any design problems?? If you model fully asynchronous memory in whatever modern FPGA it will be implemented as latches (= 1 logic cell) behind a big address multiplexer. If it's 32 bits in total that's not a big problem but if you go for several Kbytes then, yes you're in trouble. Best regards, BenArticle: 77913
Hi all, I have a legacy design for an XC4000 that I'm trying to program through the X-checker pod, and this has not worked under Windows 2000 or XP. Windows 98 works fine. What can I do to get this to work under the new OS? Thanks, VadimArticle: 77914
On Thu, 2005-01-20 at 05:00 -0800, Marc Randolph wrote: > I was figuring that someone would disagree with what I said - I just > didn't figure it would be within a half hour! Life is all about timing! > I was actually referring to the whole solution when I was referring to > the speed: signalling type (LVDS, which has slower edges than PECL and > CML), termination location (hopefully on-chip), voltage swing, etc. I don't disagree with what you've said and appreciate the insight from your past experience. I guess what I was reacting to is the concept that the connector doesn't matter. It does matter, but as I said, it all depends on how much margin you have in your design. In a particular design it may or may not matter based on a hundred other factors. As you mentioned, in a lot of ways differential signalling is a whole lot easier to deal with. Of course there is no such thing as a single-ended signal. Ground is typically the other end that happens to be common among all signals. James.Article: 77915
Hi- I need to add something to my UCF file and I am not entirely sure how to do it. We have a chip that is going to operate in one of two modes. We will have a pin which will be tied high on one side- and low on the other. The problem is is that this signal fans out throughout the whole device- but that timing analyzer thinks that this is an input it has to run timing analysis on. What we would like to do is tell the timing analyzer that the pin "mode" will not change- and that it should not consider this in its timing calculations. Thanks, WPArticle: 77916
Hi Vadim, vadim wrote: > Thanks for your responses to my posting. > > I would like to ask you if you would know why are they interested in > bringing me down from Canada ? > The reason I am asking is, I am a recent graduate and have been > working in Toronto only for couple of months. So I am not some expert > they can't find in Silicon Valley.. > This raises my suspicion abit and am afraid of being "lured" by the > glorious image of Silicon Valley to exchange my current job for > something that doesn't worth it. > > I know this is my decision and at the end of the day you have to take > some chances to get anywhere, but I am just trying to gather some > opinions from either edges of the spectrum to understand whats > "cooking" down there and what > people have experienced. > > Everyone of my US relatives and friends are saying: > "Jump on it!" > "Once there you will have lots of opportunities" > > and I realize that there are dozens of others in SV who would gladly > take > this position....so is it a genuine opportunity ? > > PS > Toronto is not a cheap place. Yet is safe and very multi-cultural. Whether SJ is the right place for you or not largely depends on what it is you're looking for. Are you looking to move ? And, if so, why ? BrendanArticle: 77917
Roger, The simple answer is that it is "they claim to be better". That used to be the one big advantage an ASIC used to have over a FPGA: (note the past tense -- the fact that there are "so many fewer memory cells" means that "the upset rate is much less" - all else being equal). The facts are less clear, at the latest technology nodes. Since we, and the SRAM vendors do SEU testing (eg Cypress has a similar project to our Rosetta where they to simulation, beam testing, and atmospheric testing), we are the only two vendors that "know" what is happening (see our MAPLD presentation for the last few years). But, look carefully at what Cypress is saying: SRAM at 90 nm is ~ 3000 FIT/Mb for atmospheric SEU's at sea level (which Cypress has improved to better than 1500 by design, doing things similar to what we are doing). Our configuration latches in comparison are ~180 FIT/Mb at 90nm (latest extrapolation of all testing, with a margin of error of 1/2 to 2X -- just need more time (or more errors). Good position to be in. Our promise is to get better with each technology, not worse. And we are proving that to be true. Well, a D FF in an ASIC (or hardened solution) is a pretty small animal at 90nm. Our studies show its upset rate to be significantly higher than one would first suppose. In fact, the 90nm standard cell D FF is the most sensitive element! They are by, our calculations, 10X our CMOS configuration latch in terms of FIT/Mb. If the FIT/Mb for 90 nm CMOS configuration latch is ~180, and it takes on average 10 tries to hit something 'critical' (a LUT, a piece of interconnect that matters - open/shorting something), then the mean time to fail is 18 FIT/Mb of config memory in our FPGAs. Gee, 10X better. If the ASIC has even 1/10 the D FF and memory that the FPGA has, then they are equal in time to fail by atmospheric upsets.... By the way, the D FF in the CLB is 1 FIT/Mb, so it is so unlikely to be flipped, it is not even on the radar screen (can be ignored). Now let us say that I use a XC4VLX60, and once I am done, I use a 2M gate ASIC (an actual customer story, one million gates + 1 million D FF's). If we make a few reasonable calculations, I get ~500 years between functional failures in the FPGA (assuming you do not use our correction features, which would make this much much better (longer)), and ~500 years between functional failures for the 90nm ASIC. So, given we are no better, no worse (on paper), and we can be better by using the FRAME_ECC, and other easy built in error correction techniques, we win in the SEU MTBF with the longest time to a failure category. Now, we know what we do, and we tell you. For fun, go ask your vendors what their atmospheric MTBF is for soft errors (SEU, SEE, SER, SEL) for their hardened solution. Many large companies are doing this (have done this). They don't know. Ask more closely, and do they know how to do Qcrit studies? Can they follow JESD89? Ask for the results. We will talk about ours, just contact your FAE. Are they hiding just how bad they really are? Or, are they just afraid that they are really bad, and have no way to know (predict)? Do they do beam testing? (we do) Do they test for latch-up (which may destroy the chip)? (we do, and have to latch-up) Do they do atmospheric experiments? (we do) Do they promise to only get better from one generation to the next? (we and Cypress both do) So, we can not say they are "worse" but we can certainly say that they are not "better." The truth is somewhere in between. But I would choose the technology that knows what is going on, and has a means to predict the MTBF, and extend the MTBF hours by using simple built in features, if it is something that is needed. Make a reliability spreadsheet for your system. Set goals (hard and soft). Then work with our FAEs to meet those goals. It is called reliability engineering, and it may surprise you that the FPGA will win. After all, being in satellites, autonomous aircraft, jet fighters, automobiles, and on Mars has taught us a lot about reliability engineering, and SEUs. Go Mars Rovers! One year and counting! Austin Roger wrote: > Compared with a normal Stratix, is a HardCopy version immune to SEUs? > > I'd have thought the possibility of a configuration error is reduced to zero > as the configuration SRAM cells have gone but an event in the logic is still > possible. Does anyone have any ideas (or figures maybe)? > > TIA > > Rog. > >Article: 77918
On 20 Jan 2005 08:41:44 -0800, "wpiman@aol.com" <wpiman@aol.com> wrote: >Hi- >I need to add something to my UCF file and I am not entirely sure how >to do it. > >We have a chip that is going to operate in one of two modes. We will >have a pin which will be tied high on one side- and low on the other. > >The problem is is that this signal fans out throughout the whole >device- but that timing analyzer thinks that this is an input it has to >run timing analysis on. > >What we would like to do is tell the timing analyzer that the pin >"mode" will not change- and that it should not consider this in its >timing calculations. > >Thanks, >WP >From the Constraints Guide: TIG (Timing IGnore) is a basic timing constraint and a synthesis constraint. It causes paths that fan forward from the point of application (of TIG) to be treated as if they do not exist (for the purposes of the timing model) during implementation. The basic UCF syntax is: NET “net_name” TIG; PIN “ff_inst.RST” TIG=TS_1; INST “instance_name” TIG=TS_2; TIG=TSidentifier1,..., TSidentifiern Regards, AllanArticle: 77919
Hi, We are currently using virtexIIpro and virtex4 fpga to prototype a dsp processor. All the code is synthesizable verilog and we are using Xilinx ISE to do synthesis and place and route. Everything works fine and the processor runs at full speed (50Mhz). However, this is only good for functionnal verification on the bench. The ASIC flow and the FPGA flow are very different so the actual gates in the FPGA are different than what will be on the ASIC. For example, we can't use the FPGA to verify the test vectors and scan chains that the test engineer is working on. Is it possible to prototype the EXACT same gates that will be in the ASIC? We use Synopsys Design Compiler to generate the ASIC gates. Basically is there a way to take the gates generated by Design Compiler, and map them in the FPGA? We don't really care if this runs slower, but it would allow the test engineer to start working on all the test vectors before we receive silicon. Thank you very much, DavidArticle: 77920
Which part? Probably you are refering to the part that passes arguments to the object's super-classes constructor. Maybe. Cheers, JonArticle: 77921
On 20 Jan 2005 09:11:59 -0800, "gretzteam" <david.lamb@gmail.com> wrote: >Hi, >We are currently using virtexIIpro and virtex4 fpga to prototype a dsp >processor. All the code is synthesizable verilog and we are using >Xilinx ISE to do synthesis and place and route. Everything works fine >and the processor runs at full speed (50Mhz). However, this is only >good for functionnal verification on the bench. The ASIC flow and the >FPGA flow are very different so the actual gates in the FPGA are >different than what will be on the ASIC. For example, we can't use the >FPGA to verify the test vectors and scan chains that the test engineer >is working on. > >Is it possible to prototype the EXACT same gates that will be in the >ASIC? We use Synopsys Design Compiler to generate the ASIC gates. >Basically is there a way to take the gates generated by Design >Compiler, and map them in the FPGA? We don't really care if this runs >slower, but it would allow the test engineer to start working on all >the test vectors before we receive silicon. > >Thank you very much, >David Yes of course. What you need to do is to take the standard cell library file(s) which define the behavior of individual gates and add it your gate level netlist during synthesis. All combinational gates will have their behaviour described in a synthesizable way in the library. The only case where this will not work are the latches and flip-flops as they are most probably defined as udps which are not synthesizable but they are relatively easy to code in behavioral rtl. the same situation may exists for muxes but that's doable too. but of course you have to understand that even these gates will be mapped to the luts on the fpga.Article: 77922
I'm working on a Xilinx demonstration board equipped with a jtag chain including a SystemACE CF and a Virtex-II FPGA. My goal is to configure the FPGA via Jtag bypassing the SystemACE. Unfortunaly, after the hardware reset, the SystemACE is configured by default to look for a bitstream on the Compact Flash: in this way, it doesn't allow me to reach the FPGA through the Jtag. I have to use Impact software to configure for the first time, and then I can access to FPGA. So, I think that Impact configures the SystemACE in order to transfer data to FPGA. It's possible to program the SystemACE via Jtag?On Xilinx 080 Datasheet (SystemACE CF solution) I can find only 4 instructions (idcode, sample, extest, bypass); in adding to this, it seems that Jtag Configuration Register is not present. Are there any others not documented commands which allow me to configure SystemAce (for example cgfin and cfgout)? Otherwise, have anybody a solution for my problem? Thank you very much. SalvatoreArticle: 77923
"James Morrison" <spam1@emorrison.ca> wrote in message news:1106192534.5033.8.camel@oxygen.emorrison.ca... > > Not true. Its not the frequency that matters but the edge rate. Given > the 4 bits and clock it sounds an awful lot like the TigerSHARC link > port and it has a very fast edge rate. The data sheet indicates a MAX > of 200ps (that's pico-seconds). > Hi James, Not true either! You've brought out the pedant in me! It's not edge rate, but rise time. For example, what's the edge rate in a 400kV power line? Still only 50 or 60 Hz though! Also, In the context of this thread, I assume you mean bit-rate when you say frequency. Marc didn't mention frequency anywhere. (And as Glen meant, rise time and frequency are equivalent anyway.) If that's the case, here's a counter-example where bit rate does matter. The bus is required to get data from one end to the other. If the bit-rate was 1Mbps instead of 400Mbps, a 200ps edge rate would give you overshoot/undershoot problems through a shoddy connector plus lots of EMI, but you'd still have a big enough eye to recover the data. So, bit-rate is a part of the design exercise. That said, I understand what you're saying. I'm just being pedantic.... Cheers, Syms.Article: 77924
Marie wrote: > Hello, > > I am using Actel Libero 6.0. > I would like to decrease the slew rate of some of the outputs of my > FPGA. > I found an option in Designer PinEdit where the slew rate can be set > low or high. Does someone have an idea of what means low or high? > Are there any numbers (in ns) available somewhere? Is it programmable > in ns? > Is it possible to see the rise time on the simulation (I use > ModelSim)? > Will the fall time also be influenced? Is it possible to influence it > separately? > > Thank you very much. > > Marie Van Quickelberghe Hi, It turns out the only place to get the actual numbers is from the ibis file for that device. We have done it in the past, real painful to figure out. Good luck! Dave Colson
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