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
James Morrison wrote: > 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. Thanks for the replies, they really help me get a better picture! I don't have TigerSHARCs, just two Spartan-3 FPGAs. I wonder what is the acceptable mismatch between the traces of an LVDS pair? Given ~6 in/ns propagation speed and, let's say 0.2 ns rise time, the rise time length is 1.2 inches. Is something like 10% of that, or 120 mils, acceptable trace length mismatch? I think it will be even lower than that when the final routing of the board is done. Any thoughs about vias on the signal traces? Thanks again, -- GeorgiArticle: 77926
"Jim Granville" <no.spam@designtools.co.nz> skrev i meddelandet news:41ef3cfd$1@clear.net.nz... > 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. One of the few reasons why you would want to have a soft processor today, is if you can boost your application through a non standard instruction set. Why would you choose an FPGA with a soft Microblaze/Leon/OpenRISC over an FPGA with a hardwired Microblaze/Leon/OpenRISC? If you come to the conclusion that a hardwired Leon is better than a soft one, then you need to ask yourself, if it is very important having a Leon, or will an external ARM7 chip do? The AT91FR40162 is 10 x 10 mm so it is not a lot of board space yuou can save by just having an external flash. If you had a low cost coverification tool for the specific architecture then it is easier to develop the FPGA, and this could be one motivation. I have not heard about coverification for the cores mentioned above though. A multichip package with flash and FPGA would make the proposal more attractive if you need certain combinations not available in std micros like PCI bus enabled controller. This would result in smaller board space. You can of course do a multichip FPGA + Flash Micro, but market might be smaller > 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). You mean an FPSLIC ;-) Loads from -- Best Regards Ulf at atmel dot com These comments are intended to be my own opinion and they may, or may not be shared by my employer, Atmel Sweden.Article: 77927
Mark Smith wrote: > 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 Semiconductor That's great, thanks! -- GeorgiArticle: 77928
hi, I'm using ISE6.3.03i and ModelSim5.6. I have a disign whitch work in simulation "Post Translate" and "Post Map". But when I try to execute a simulation "Post Place And Route", resutl are strange. The delay between rising egde and a new data change the result of my simulation. Sometimes it's ok, and sometimes it's doesn't work. I try several delay but I don't understand why!! My constraint file : clk = 160MHz offset in = 6.25ns offset out =6.25ns thnaks for your answers. CédricArticle: 77929
cedric wrote: > hi, > I'm using ISE6.3.03i and ModelSim5.6. > I have a disign whitch work in simulation "Post Translate" and "Post Map". > But when I try to execute a simulation "Post Place And Route", resutl are > strange. The delay between rising egde and a new data change the result of > my simulation. Sometimes it's ok, and sometimes it's doesn't work. > I try several delay but I don't understand why!! > > My constraint file : > clk = 160MHz > offset in = 6.25ns > offset out =6.25ns It seems your clock speed is too fast for your design. Try to modify the design, or choose a faster chip, or do both. vax, 9000 > > thnaks for your answers. > > CédricArticle: 77930
I am trying to use Signal Tap with a Cyclone. I have added nodes and set trigger conditions, data enable, compiled, etc and nothing ever triggers. I noticed that three of my nodes have red trigger conditions. The rest of the line is Black. Could this be my problem? What does it mean and how do I work around it if it is? -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.comArticle: 77931
Hi Austin, So, in your opinion, would the FIT/Mb for a V2Pro (on 130nm) be higher or lower than a V4 (on 90)? The area of a V2Pro DFF is larger, but the amount of energy required to create an actual fault is higher too. PS: feeling much better after (1) fixing just eentsily oxidized soldering connection causing the boot failure and (2) getting my motorcycle permit. Ben > 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: 77932
CALL FOR PARTICIPATION _____________________________________________________________________ International Workshop on Applied Reconfigurable Computing (ARC 2005) URL: http://w3.ualg.pt/~jmcardo/arc2005 Algarve, Portugal, February 22-23, 2005 _____________________________________________________________________ To register, please fill in the form in http://w3.ualg.pt/~jmcardo/arc2005/registration_arc2005.pdf and sent it by FAX to: +351 21 3151244. PROGRAM: ------------------------------- Tuesday 22 February 2005 ------------------------------- 9:30 Registration 10:00 Opening Session 10:15 Invited Speaker: Pedro Diniz University of Southern California / Information Sciences Institute, CA, USA "Exploiting Data Reuse in Modern FPGAs: Opportunities and Challenges for Compilers" 11:00 COFFE BREAK 11:15 SESSION A: (3 distinguished papers) APPLICATIONS I 11:15 "Optimized FPGA Implementation of a Multi Program PCR Measurement System in DVB-T" Authors: C. Mannino, H. Rabah, C. Tanougast, Y. Berviller, M. Janiaut and S. Weber Affiliation: Laboratoire d'Instrumentation Electronique de Nancy (L.I.E.N.), U.H.P., Faculte des Sciences, France 11:40 "An FPGA Implementation of a Flexible Secure Elliptic Curve Cryptography Processor" Authors: T. Kerins, W. P. Marnane, E. M. Popovici Affiliation: University College Cork, Ireland 12:05 "Network Intrusion Detection Systems on FPGAS with On-Chip Network Interfaces" Authors: Chris Clark, Craig Ulmer Affiliation: Georgia Tech, Sandia National Labs, USA 12:30 LUNCH 14:00 SESSION B: (5 regular papers) DYNAMIC RECONFIGURATION AND ARCHITECTURES 14:00 "Function Replacement of Hard Real-Time Systems using Partial Reconfiguration" Authors: Thomas Reinemann, Roland Kasper Affiliation: IMAT, Otto-von-Guericke-University Magdeburg, Germany 14:20 "A Methodology for Hardware Tasks Scheduling Optimized in Time for Partial and Dynamic Reconfiguration of FPGAS" Authors: Remy Eskinazi, Paulo Maciel, Manoel Eusebio de Lima, Paulo Sergio Nascimento, Abel Guilhermino, Carlos Valderrama Affiliation: Federal University of Pernambuco, Brasil 14:40 "Towards a Runtime Reconfigurable Network-on-chip-based Network Processor" Authors: Jürgen Foag, Roman Koch Affiliation: University of Luebeck, Germany 15:00 "Adopting the Small-World Network in Routing Structure of FPGA" Authors: Masahiro IIDA, Shinya ABE, Hisashi TSUKIASHI, Ryoji OGATA, and Toshinori SUEYOSHI Affiliation: Kumamoto University, Japan 15:20 "Novel Switch-Block Architecture Using Reconfigurable Context Memory for Multi-Context FPGAs" Authors: Wei Sheng CHONG, Masanori HARIYAMA, and Michitaka KAMEYAMA Affiliation: Tohoku University, Japan 15:40 COFFE BREAK 16:10 SESSION C: (5 regular papers) APPLICATIONS II 16:10 "Realisation of Real-Time Control Flow Oriented Automotive Applications on a Soft-core Multiprocessor System based on Xilinx Virtex II FPGAs" Authors: Katarina Paulsson, Michael Hübner, Hong Zou, and Jürgen Becker Affiliation: Universitaet Karlsruhe (TH), Germany 16:30 "Optimise FPGA Implementation of an AES Algorithm for Embedded Application" Authors: T. Liu, C. Tanougast, P. Brunet, Y. Berviller, H. Rabah, and S. Weber Affiliation: Université Henri Poincaré Nancy I, France 16:50 "Efficient Decoding of Variable-Length Encoded Image Data on the Nios II Soft-Core Processor" Authors: Peter Mårtensson, Jans Persson, Shang Xue, and Bengt Oelmann Affiliation: Mid Sweden University, Sweden 17:10 "An Efficient, Low Resource, Architecture for Backpropagation Neural Networks" Authors: Pedro O. Domingos, and Horácio C. Neto Affiliation: INESC-ID, IST, Portugal 17:30 "FPGA Based Architecture for the Data Acquisition Electronics of the Clear-PEM System" Authors: J. Varela, P. Bento, C. Leong, I. C. Teixeira, J. P. Teixeira, J. Nobre, J. Rego, P.Lousã, P. Relvas, P. Rodrigues, and A. Trindade Affiliation: LIP-Lisboa, Lisbon, Portugal; Universidade Técnica de Lisboa, Instituto Superior Técnico, Lisbon, Portugal; INESC-ID, Lisbon, Portugal; INOV, Lisbon, Portugal ------------------------------- Wednesday 23 February 2005 ------------------------------- 8:45 SESSION D: (3 distinguished papers) ARCHITECTURES AND APPLICATIONS 8:45 "A RISC Architecture Extended by an Efficient Tightly Coupled Reconfigurable Unit" Authors: N. Vassiliadis, N. Kavvadias, G. Theodoridis, and S. Nikolaidis Affiliation: Section of Electronics and Computers, Department of Physics, Aristotle University of Thessaloniki,54124 Thessaloniki, Greece 9:10 "A Dynamic Optically Reconfigurable Gate Array using Dynamic Method" Authors: Minoru Watanabe, and Fuminori Kobayashi Affiliation: Kyushu Institute of Technology in Japan, Japan 9:35 "A Fault Tolerant Gesture Recognition System for Mobile Robot" Authors: Vanderlei Bonato, Márcio M. Fernandes, and Eduardo Marques Affiliation: Institute of Mathematics and Computing Sciences, University of São Paulo, Brasil 10:05 COFFE BREAK 10:35 SESSION E: (5 regular papers) TOOLS,TECHNIQUES, AND METHODOLOGIES 10:35 "A Methodology for Parameterized Algorithm Design to Support Flexible FPGA Based System Design" Authors: Aparna Nagargadde, Sridhar Gangadharpalli, and Sridhar V. Affiliation: Applied Research Group, Satyam Computer Services Limited; Entrepreneurship Centre, Indian Institute of Science Campus, Bangalore 10:55 "Pipelining Sequences of Loops: A First Example" Authors: Rui Rodrigues, and João M. P. Cardoso Affiliation: University of Algarve, Portugal 11:15 "Open Architecture Hierarchical Placement for FPGA Datapath Designs" Authors: Dong Kwan Kim, Cameron Patterson, and Peter Athanas Affiliation: Virginia Polytechnic Institute and State University, USA 11:35 "Optimizing Area on the Generation of Specific Circuits in FPGAs for SIMD Applications" Authors: Germán León, José M. Claver, and Germán Fabregat Affiliation: University Jaume I, Spain 11:55 "A Test Infrastructure for Compilers Targeting FPGAS" Authors: Rui Rodrigues, and João M. P. Cardoso Affiliation: University of Algarve, Portugal 12:10 Closing SessionArticle: 77933
I am trying reproduce a Macintosh 128k using CMOS parts. It has some 16R4, 16R8, and 16L8 PALs. If you could give me any advice about how I should "learn" the logic in these that would be GREAT! Maybe a method of bit twiddling all the inputs to see what happens? The 16L8 should be simple, but that is only one of the 6. I have signal names and a schematic, but the internal design of the 'R' chips scares me. :) Is there any programmer that can use a brute force technique of trying all possible logic combinations? I want to do this to learn another aspect of old computers, and because I'd like to replace all the chips with new CMOS and see if I can't get overclock the thing. ;) Thanks for your time, GrantArticle: 77934
Hi Georgi, > Any thoughs about vias on the signal traces? Avoid them as much as possible (they're major jitter sources), make them blind vias or counter-bore them to make them as short as possible (cheaper), and make sure that the signal path goes from the top end of the metal to the bottom (or the other way around). Leftover metal does nasty things to the signal. See http://www.tycoelectronics.com/products/simulation/files/papers/dc00brdh.pdf for some great information on this. Ok, you're not running at 5Gbps, but it never hurts following these rules. Best regards, BenArticle: 77935
Hi, thanks for the reply. Its good news to know that it is possible to do. However, I'm not quite sure I understand what you are saying. Could you please give more details of the things to do? Have you ever done it? How good is performance? Thanks, David mk wrote: > 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: 77936
Hi Sebastian, The first two things to try in this this situation are: 1) Ensure all unused pins are "Inputs tri-stated" 2) Use a USBB instead of BB If these do not work, let me know and I will have a support person contact you for more details. Hope this helps, Subroto Datta Altera Corp. Sebastian Schmidt wrote: > 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: 77937
Hello FPGA group,
I have to create this sum
A+2B+C
where A, B, and C are 8 bit std_logic_vector
as part of a Sobel function.
What is the best way of doing this?
I have been able to get correct results
with the following:
signal sum : std_logic_vector(9 downto 0);
begin
sum <= ("00"&in1) + ('0'&in2&'0') + ("00"&in3) ;
However I find this code looks a bit sticky and I
wonder if it may be synthesizing 10 bit adders to
do 8 bit work. The Map report says that I am
using 15 LUTs and 9 slices.
Spartan 3, and most of the other Xilinx parts, have an
ADD8 macro, according to the library guide, but I
couldn't find how to instantiatie this as a component.
Are macros components?
Thanks for your consideration,
Brad Smallridge
brad at www.aivision.com
Article: 77938Fat Cat wrote: > I am a bit confused. I have never seen such syntax even though I read a > lot of C++ codes. I am a bit confused. I don't know how you could've read more than 1 or 2 examples of C++ code without coming across everything in your example?!? Regards, -- | Mark McDougall | "Electrical Engineers do it | <http://to be announced> | with less resistance!"Article: 77939
Antti Lukats wrote: > 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 :) Have you tried the OpenSource MicroBlz, from serial FLASH memory ? With the 50MHz SPI models, you peak at ~6MBaud streaming bandwidth, (which of course drops on jumps). That's enough for many apps, and with a little cache using one block ram, inner loops could fit on-chip. -jgArticle: 77940
Brad Smallridge wrote: > However I find this code looks a bit sticky and I > wonder if it may be synthesizing 10 bit adders to > do 8 bit work. The Map report says that I am > using 15 LUTs and 9 slices. Umm, you're *not* 'doing 8 bit work'?!? -- | Mark McDougall | "Electrical Engineers do it | <http://to be announced> | with less resistance!"Article: 77941
In a similar way to when you use the Xilinx tools to take a placed and routed design and produce a VHDL (for example) file which contains a whole load of simple gates. To simulate this, you either use their library which includes timing information, or a simple functional description of the gates. This allows you to test the final design rather than just simulating the source files. You should be able to take the output of Design Compiler, and write a simple functional (and synthesizable) cell library. You could then push all this through the xilinx tool set and produce a routed design. Of course, the Xilinx devices use luts as the logic primitive, but you would at least be starting from the Asic gate description. /Mike > Hi, > thanks for the reply. > Its good news to know that it is possible to do. However, I'm not quite > sure I understand what you are saying. Could you please give more > details of the things to do? Have you ever done it? How good is > performance? > > Thanks, > David > > > mk wrote: > > 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: 77942
"logjam" <grant@cmosxray.com> wrote in message news:1106249347.233017.138400@f14g2000cwb.googlegroups.com... >I am trying reproduce a Macintosh 128k using CMOS parts. It has some > 16R4, 16R8, and 16L8 PALs. If you could give me any advice about how I > should "learn" the logic in these that would be GREAT! Maybe a method > of bit twiddling all the inputs to see what happens? The 16L8 should > be simple, but that is only one of the 6. I have signal names and a > schematic, but the internal design of the 'R' chips scares me. :) Hmm. I think that noting the connections to the CPU will provide some useful clues. Is the circuit diagram online? I have a copy of the 3rd edition of "The Programmable Logic Handbook" by MMI. Antique technology but since it was from the dawn of PLD days it has very useful code examples. Like connecting the 68K to Zilog peripheral chips. I can scan the notes that you want. MikeJ of FPGA arcade is resurrecting the Atari ST, so some fundamentals may match the Mac. Cheers, K.Article: 77943
Dear all, Normally SDRAM needs tens of MS to refresh bank of memory,while what happens when I happened to visit this memory address,either read or write. Dose the SDRAM controller(say,IP core from Xilinx) makes this read/write operation waiting for this refresh period and execute read/write command afterwards(That's unacceptable in term of time or speed for this read/write operation!)? Or it handles such condition in another way? Thanks for your information. regardsArticle: 77944
Thanks for the advice. I was able to get it working, turns out my problem was a timing issue on the IP2Bus_Ack line. For the interrupts I figured out that I could not just set the global interrupt handler in the Microblaze S/W settings in EDK, but had to do it explicitly by adding the line: microblaze_register_handler(int_handle, (void*)0); to my setup routine.Article: 77945
> Umm, you're *not* 'doing 8 bit work'?!? Hello Mark, OK, it seems to me that the best solution is one eight bit adder with a carry, going into a nine bit adder (maybe not if I don't care about the lower bits) with a carry, giving me a 10 bit sum. My question is (was), does this VHDL give me 10 bit adders throughout, instead of an optimised solution, on a Xilinx XST platform? And is this, overall, the best way of doing a sum like this? Mark, is that clearer? BradArticle: 77946
Ben, Well, based on the numbers I gave, V2P has a higher FIT/Mb rate than V4, but generally speaking the V2P chip folks use is smaller (less memory cells, less logic) than the V4 chips. So, at one time the sweet spot part for Virtex was a XCV300. Then for the Virtex E it went up to a XCV600E. With Virtex II, it was 2V1000. In Virtex 2 Pro, is is the 2VP30. In Virtex 4, we suspect it will be the XC4VLX60. At least that is what a lot of folks are getting shipped as samples right now. Although the LX25 is pretty popular as well. Not to mention their is a huge volume application for FX12's that might outstrip all of the others....predicting the high runner a-priori is just gambling. So, if customers would just stop using more logic, we would be getting 'better' in each device (of the same size) since Virtex II. But, customers will pack more stuff in (for less money), so the FIT/family gets slightly worse, even though the FIT/Mb is better, just because larger parts are being compared to smaller parts. Hence the reason why we have to work so hard to get better, so we don't get worse overall. That is the reason why we added the FRAME_ECC to correct errors in V4: parts are growing faster than we are decreasing the FIT/Mb rate (although we are doing that, too). So on a system basis, we still must get better. Austin Ben Twijnstra wrote: > Hi Austin, > > So, in your opinion, would the FIT/Mb for a V2Pro (on 130nm) be higher or > lower than a V4 (on 90)? The area of a V2Pro DFF is larger, but the amount > of energy required to create an actual fault is higher too. > > PS: feeling much better after (1) fixing just eentsily oxidized soldering > connection causing the boot failure and (2) getting my motorcycle permit. > > Ben > > > >>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: 77947
Brad Smallridge wrote: > OK, it seems to me that the best solution is > one eight bit adder with a carry, going into > a nine bit adder (maybe not if I don't care about > the lower bits) with a carry, giving me a 10 bit sum. > My question is (was), does this VHDL give me > 10 bit adders throughout, instead of an optimised > solution, on a Xilinx XST platform? From the software I know, it likely will generate that, but during place and route any redundant gates will be removed. The result, then, should be just what you say, unless the addition is done in a different order. Systems I know about will remove FF's with constant inputs, combine registers with the same inputs, remove gates where all the inputs, or all but one are constant, eliminate inverters by inverting the output of the preceding device, and probably more. Usually there are messages telling what it is doing. -- glenArticle: 77948
On Thu, 20 Jan 2005 15:06:52 -0800, jeffsen <xjf77@yahoo.com> wrote: >Dear all, Normally SDRAM needs tens of MS to refresh bank of memory,while what happens when I happened to visit this memory address,either read or write. Dose the SDRAM controller(say,IP core from Xilinx) makes this read/write operation waiting for this refresh period and execute read/write command afterwards(That's unacceptable in term of time or speed for this read/write operation!)? Or it handles such condition in another way? Thanks for your information. regards You misunderstand. Each memory row needs to be refreshed every <x> milliseconds, but the refresh cycle itself only takes a few clock cycles. I'd recommend reading one of the Micron SDRAM datasheets as they have pretty good explanations of SDRAM.Article: 77949
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:10v0fe7igutmt55@corp.supernews.com... [ snip ] > OK, it seems to me that the best solution is > one eight bit adder with a carry, going into > a nine bit adder (maybe not if I don't care about > the lower bits) with a carry, giving me a 10 bit sum. > > My question is (was), does this VHDL give me > 10 bit adders throughout, instead of an optimised > solution, on a Xilinx XST platform? > > And is this, overall, the best way of doing a sum > like this? [ snip ] Since your synthesis shows 15 LUTs used, I expect that the sum is the cascade of 2 9-bit adders. Consider that A+C is a 9 bit value but the LSbit is added to zero so it can pass straight through without going to another adder. The second adder takes the top 8 bits of the 9-bit A+C result and adds it to the 8-bit shifted B value. I would have expected 16 LUTs in the two 8-bit adders (with "free" carry-outs) but the synthesizer might have combined something for the LSbits saving you a LUT. I use Synplify for my synthesis and go to the HDL Analyzer to check the synthesizer's implementation when I have efficiency concerns. I get full visibility into the technology level implementation, no questions. You're probably doing great on efficiency.
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