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
Hi Bernhard, thank you for your reply! I shall have a good look..... Gary. Bernhard Josef Rieder <bernhard@ratte.tuwien.ac.at> wrote in message news:8jufdf$38i$1@news.tuwien.ac.at... > In article "gary" <dont.spam@me.net> wrote: > > > (1) How complex is the decoder, how much logic would I need? > > have a look at http://www.mpg123.de/ for the C source of a software > decoder. It seems difficult ...... > > > > (2) Do you have to pay to use MPEG in your own codecs? > > I think you only have to pay if you use the algorithm published by > frauenhofer institute*. If you are not living in the US or in Germany > it is likely to be legally anyway :) > > * It seems to be almot impossible NOT to use it > > > BernhardArticle: 23826
Savekar, Thanks for replying! I'll have a good look at tsec.com. Gary. Savekar Santosh <ssavekar@my-deja.com> wrote in message news:8juuj3$sg2$1@nnrp1.deja.com... > In article <M5P65.1136$HR.19533@news6-win.server.ntlworld.com>, > "gary" <dont.spam@me.net> wrote: > > Dear all, > > > > I am considering implementing an MPEG layer 2 audio decoder in an > fpga. > > Around 128kbit/s. > > > > What I need to know is.... > > > > (1) How complex is the decoder, how much logic would I need? > > I think with highly optimized design you should be able to do the audio > decoder layer-I, not sure about layer-II, in around 8K gates or so. I am > not thinking about the space to store constants here. See: > > http://www.tsec.com/p_audio.htm > > > > > (2) Do you have to pay to use MPEG in your own codecs? > > You have to pay only if you buy the standards from ITU. > which are priced at around $125. But you can get the know-how by some > other means such as free sources on web. > > > > > All help much appreciated. > > > > Gary. > > > > > > Good luck, > Santosh > > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 23827
There are four 4 LUTs and some other stuff per CLB. Really though you can do any function of 6 inputs and it is really a 6 LUT. If you just used 4 LUTs to do any function of 6 inputs you would need more than four 4 LUTs. So 4.5 4 LUTs per CLB is a conservative in my opinion. Steve Casselman "Rickman" <spamgoeshere4@yahoo.com> wrote in message news:392AB1C4.556B80FC@yahoo.com... > First let me say that I am not trying to pick on Xilinx by asking so > many questions about their devices and practices. But I am looking at > switching to their parts for my next design and want to discuss some of > the things I don't understand. > > With that said, can anyone tell me how Xilinx comes up with their "Logic > Cell" counts? In the XC4000 line of parts, they seem to have 2.375 Logic > Cells per CLB. I can understand this since they have the two 4 input > LUTs and a 3 input LUT which they must be counting as .375 Logic Cells. > > But in the Spartan II line they get 4.5 Logic Cells per CLB. But if I > understand the architechture correctly, there is no extra 3 input LUT in > these devices. Although they have extra logic to combine the outputs of > the four LUTs in a CLB, this logic can not be used independantly as can > the 3 input LUT in the XC4000 series. So the maximum number of logic > outputs you can have is determined by the number of LUTs you have, not > the number of "Logic Cells". > > So how can they count this as .5 Logic Cells per CLB? Is Logic Cell > count the same as gate count and should be ignored? > > I guess this is not really a significant issue, but it does make their > documentation a bit harder to interpret since I have to calculate the > LUT count myself for every device I want to consider. > > On a more significant note, I can't say that I understand the carry > chain description in the Spartan II datasheet. I can't seem to cut and > paste from the document (odd, I can do that with most other PDF > files...) but the text says, "The Spartan-II CLB supports two separate > carry chains, one per Slice. The height of the carry chains is two bits > per CLB." The Virtex carry chain is described the same way so that sheds > no additional light on the matter. > > Is this saying that the two slices are separate and only one carry chain > can be used at a time? Or are the two cascadable to produce a four bit > slice of a counter/adder? I checked the timing data and there is no > indication of a fast connect from Cout to Cin on the same CLB or to > adjacent CLBs. Has this gone away with the Virtex/Spartan II parts? > > > -- > > Rick Collins > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > removed. > > > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.comArticle: 23828
Joel Kolstad wrote: > ed, synthesizing hardware is a rather complex > task, but so is building a C++ compiler, and the guys at Microsquish sure > seem to end up with better quality programmers than Synopsys did. (Or maybe > they just have so many more...?) Nah, just a lot more beta testers.. Oops I mean users :-) > > > > ---Joel Kolstad -- -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 or http://www.fpga-guru.comArticle: 23829
Thanks for your reply. 64 Point or 512 Point FFT/IFFT Sent via Deja.com http://www.deja.com/ Before you buy.Article: 23830
Whenever we have this discussion, which does recur, there is one important distinction that needs to be made: in both C++ and Java, it is possible to write both *generators* as well as *synthesis* systems. They are quite different beasts. Some examples: 1. Netlist generators (explicit hardware specification systems), such as * C++: PamDC [1], PAM-Blox [2], CNets [3], * Java: Chu et al (Berkeley) 'OO Circuit Generator in Java' [4], JHDL [5] * Others: Lola/Trianus/Hades [6] 2. HLL synthesis (behavioral compilers / hardware inference systems), such as * C/C-like: Napa-C [7], Streams-C [8], Handel-C [9], Leong's lcc-VHDL system [10], 'Tsukuba' C-HDL compiler [11] * Java: Galadriel/Nenya [12], LavaLogic Forge [13] (Apologies if I have miscategorized or overlooked your favorite.) And then there's SystemC [14] and others, which I think support both paradigms. Comparing generators to synthesizers is just like comparing schematics to HDL synthesis. In the former, you have explicit control over what you get, and in some cases, how it is technology mapped and placed. But then you *do* have to explicitly instantiate everything. In a synthesis system, you have tools that do that for you, but tend to achieve inefficient results quickly. In my opinion, generators can have all the 'explicitness' advantages of schematics, plus text representation, HLL integration and programmability, with none of the disadvantages. There is just a critical mass adoption issue -- in lieu of one dominant approach, there is no opportunity for reuse across existing experimental systems and none have seemed to gain traction. HLL synthesis, I'm ambivalent about. I hate wasting hardware, but I understand others are more sanguine about that. I wonder just how much of an improvement over HDLs they are, given you often don't get the full HLL semantics, and apparently you often need to add pragmas and directives to help synthesis make the right things parallel and/or sequential, put the right data in registers or internal RAM or external RAM, etc. Just as C compilers sometimes outperform assembly hackers, it is (remotely) possible that someday these can generate designs that approach a careful schematic design? Are they a revolutionary development that will make it easy for your average C/Java programmer to design hardware? Will they let you push a button and get hardware from a dusty deck C or Java library? I doubt it. Software design concerns are quite different from hardware design concerns. Also, I believe that a good C programmer can pick up Verilog and Verilog concepts about as easily as they can learn the additional keywords and directives and restrictions necessary to infer comparable hardware with an HLL synthesis system. Perhaps someone who uses and prefers HLL synthesis can share their experiences. Jan Gray Gray Research LLC References [1] http://www.research.digital.com/SRC/pamette/Software.html) [2] http://umunhum.stanford.edu/PAM-Blox/ [3] http://www.fpgacpu.org/usenet/cnets_datapath.html [4] http://brass.cs.berkeley.edu/documents/Generators_FCCM98.html [5] http://www.jhdl.org/ [6] http://www.cs.inf.ethz.ch/projects/lola/trianus/ [7] FCCM98 [8] Gokhale et all, FCCM00, also e.g. http://www.arpa.gov/ito/psum1998/F282-0.html [9] http://www.embeddedsol.com/technology/info_sheets/info_sheet_01.htm [10] "Automatic Floating to Fixed Point Translation and its Application to Post-Rendering 3D Warping", FCCM99, http://www.cse.cuhk.edu.hk/~phwl/papers/fccm99_fixed.ps.gz [11] Maruyama, FCCM00 [12] http://www.acm.org/crossroads/xrds5-3/rcconcept.html [13] http://www.lavalogic.com/product/wp_forge.htmlArticle: 23831
Jan Gray wrote: > > Whenever we have this discussion, which does recur, there is one important > distinction that needs to be made: in both C++ and Java, it is possible to > write both *generators* as well as *synthesis* systems. They are quite > different beasts. Some examples: > > 1. Netlist generators (explicit hardware specification systems), such as > * C++: PamDC [1], PAM-Blox [2], CNets [3], > * Java: Chu et al (Berkeley) 'OO Circuit Generator in Java' [4], JHDL [5] > * Others: Lola/Trianus/Hades [6] > > 2. HLL synthesis (behavioral compilers / hardware inference systems), such > as > * C/C-like: Napa-C [7], Streams-C [8], Handel-C [9], Leong's lcc-VHDL system > [10], 'Tsukuba' C-HDL compiler [11] > * Java: Galadriel/Nenya [12], LavaLogic Forge [13] ...snip... > In my opinion, generators can have all the 'explicitness' advantages of > schematics, plus text representation, HLL integration and programmability, > with none of the disadvantages. There is just a critical mass adoption > issue -- in lieu of one dominant approach, there is no opportunity for reuse > across existing experimental systems and none have seemed to gain traction. Can you be a little more specific about the advantages and disadvantages? I think I understand the advantages of schematics, text representation..., but what would the disadvantages of using an HLL be for "generation"? Are you talking about the verboseness? In summary, you feel that using a HLL such as C or Java for synthesis is not a good idea for now, but using them as a generator may work well? > References > > [1] http://www.research.digital.com/SRC/pamette/Software.html) > [2] http://umunhum.stanford.edu/PAM-Blox/ > [3] http://www.fpgacpu.org/usenet/cnets_datapath.html > [4] http://brass.cs.berkeley.edu/documents/Generators_FCCM98.html > [5] http://www.jhdl.org/ > [6] http://www.cs.inf.ethz.ch/projects/lola/trianus/ > [7] FCCM98 > [8] Gokhale et all, FCCM00, also e.g. > http://www.arpa.gov/ito/psum1998/F282-0.html > [9] http://www.embeddedsol.com/technology/info_sheets/info_sheet_01.htm > [10] "Automatic Floating to Fixed Point Translation and its Application to > Post-Rendering 3D Warping", FCCM99, > http://www.cse.cuhk.edu.hk/~phwl/papers/fccm99_fixed.ps.gz > [11] Maruyama, FCCM00 > [12] http://www.acm.org/crossroads/xrds5-3/rcconcept.html > [13] http://www.lavalogic.com/product/wp_forge.html I will keep this list for use later. -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23832
And what company's marketing department do you work for? ;) Steve Casselman wrote: > > There are four 4 LUTs and some other stuff per CLB. > Really though you can do any function of 6 inputs and it is really a 6 LUT. > If you just used 4 LUTs to do any function of 6 inputs you would need more > than four 4 LUTs. So 4.5 4 LUTs per CLB is a conservative in my opinion. > > Steve Casselman -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23833
[context is my gripes about blinking/bouncing stuff.] > I don't remember Xilinx having much of this on their web site, but it > doesn't hurt to mention it. I use a hack to supress flashing junk, mostly from banner ads. I was annoyed enough at two of the gifs on the Xilinx site that I added them to my reject list. Xilinx isn't bad when compared to many sites. But check out their main page. The "ASIC Cost Estimator" blinks out and then fades back in. (Rats, now I have to go update my list.) Note that the link behind that is javascript (jumpBillboard()) so even if I click on it it nothing happens. > > And self decompressing exe files are out. Please just give me the > > raw file set. I'll take the space/time/bandwidth penalty. > But in any case, please don't stop zipping these files. I'm happy with compressed files - it's the exe part that I don't like. First, it won't run on my machine. Second, even if it did, I would have to trust it. Why should I make that leap? It might contain a virus or trojan. Or it might just install some junk that I don't want on my machine. -- These are my opinions, not necessarily my employers. I hate spam.Article: 23834
Rick, thanks reposting my announcement / ad. Let me say that I am biassed, because my company sells the mentioned FPGA kits, but I have to second Rick's suggestion. The kits are designed to be a fast and easy way to try out circuits in the lab. And low cost. Check them out at www.BurchED.com.au If you don't own any design tools, the Altera kit plus the free Max+PlusII Baseline software downloadable from www.altera.com are a low cost way to start. Or if you prefer Xilinx, Actel, Atmel or Lucent, their "Base" design tools can be had at low cost (ie. about US$99 for the Xilinx tools, and similar costs for the other vendors). rickman wrote in message <396A327C.6F6D7D2A@yahoo.com>... >I saw this ad in comp.arch.embedded awhile back. I have no idea how good >or bad the product is. They are very good :) BED-LUCENT-BASE+ are great for Lucent users :) :) As I said, I am biassed. Cheers Tony Burch www.BurchED.com.au rickman wrote in message <396A327C.6F6D7D2A@yahoo.com>... >I would make two recommendations to you. The first is to forget about >using the XC2018 chip. This is not only no longer made, it has very >little capability compared to the chips available today. > >Secondly, I would recommend that you not try to use a chip. Most of the >FPGAs from Xilinx are only available in surface mount packages that are >hard to work with compared to the other options available to a hobbiest. >Instead, use a demo board available from many sources. There is a list >available at http://www.optimagic.com/. See what you can find there. > >I saw this ad in comp.arch.embedded awhile back. I have no idea how good >or bad the product is. Just make sure the chip on any board you buy is a >recent one (Spartan, XC4000, Virtex, Spartan II). I recommend that you >hold out for the new Spartan II which should be shipping in a month or >two. > >****************************************** >Burch Electronic Designs FPGA Prototyping >kits are now 25% cheaper. >Xilinx kits are now US$66 ! > >The price rollback is due to the abolition >of the crippling "Wholesale Sales Tax" >in Australia, plus the recent streamlining >of our production process. > >Xilinx, Altera, Atmel, Lucent and Actel kits >are available. > >For product details, secure online shop and >subscription to our free online newsletter >please go to >www.BurchED.com.au > >International orders are very welcome. > >Best regards >Tony Burch >www.BurchED.com.au >****************************************** > > > >Ottwald Holler wrote: >> >> I got some pcs of XC2018-fpga's. I'm hamradio operator and would like to >> realize some ideas with this fpgas. The only one problem is that the >> current versions of xilinx software doesnt support the xc2018. >> I'm therefore hardly looking for a working version of XACT5 (DOS&UNIX) >> or XACT6 (Windows) to buy! >> Anybody on the forum who could help me? >> Thanks a lot for thinkig about! >> >> Ottwald J.Holler >> Callsign OE2OHA, ex.5B4EC, ex VK4ZOH >> Liechtensteinklammstrasse 78 >> A-5600 ST.JOHANN/PG >> AUSTRIA - EUROPE >> >> oe20ha@eunet.at >> >> www.members.eunet.at/oe20ha/index.html > >-- > >Rick Collins > >rick.collins@XYarius.com > >Ignore the reply address. To email me use the above address with the XY >removed. > > > >Arius - A Signal Processing Solutions Company >Specializing in DSP and FPGA design > >Arius >4 King Ave >Frederick, MD 21701-3110 >301-682-7772 Voice >301-682-7666 FAX > >Internet URL http://www.arius.comArticle: 23835
> Can you be a little more specific about the advantages and > disadvantages? I think I understand the advantages of schematics, text > representation..., but what would the disadvantages of using an HLL be > for "generation"? Are you talking about the verboseness? > > In summary, you feel that using a HLL such as C or Java for synthesis is > not a good idea for now, but using them as a generator may work well? If you are a programmer, then using a library package from c or Java as a generator feels just like schematics - each box on a schematic turns into a subroutine call. You call a subroutine to make a gate or flip-flop. The library provides a collection of primitives - just like the schematic package does. You can easily extend what the system provides by writing your own code. The library remembers each call in an internal data structure. At the end, you call a cleanup routine which writes out the net list. If you have that internal data structure, it's pretty easy to add a simulator to the package. The advantages and disadvantages are just like schematics. You can do whatever you want. You have to do everything, or at least everything you want to end up in the wire list. If you are a programmer, writing code in a familiar language may be easier than using schematics. You can use grep and friends on your source text. One potential disadvantage with text systems is that some technicians don't like them. I've never worked with a commercial schematic package. I have looked at a lot of drawings that I consider pretty ugly. Why should I use a schematic to describe the mapping from signal name to pin number? Especially when the box is so tall that it wraps over several sheets. It's just a pile of text. I'd rather use my choice of text editor. I don't understand the synthesis path yet. -- These are my opinions, not necessarily my employers. I hate spam.Article: 23836
Jens, It's easy just to instantiate the primitives in your code. To keep it modular just make a wrapper architecture and instantiate into that. Cheers Chris Jens Popp wrote: > Hi, > > is it possible to import the Xilinx Libraries for FPGA XC 4000E Series > in Renoir as Blocks for the Block Diagrams? > > Regards > -- > > Jens Popp > Institut fuer Rechnerstrukturen > Universitaet Siegen > Hoelderlinstr.3 > D-57068 Siegen > Germany > > TEL +49 271 740 2376 > FAX +49 271 740 2473 > mailto:popp@rs.uni-siegen.deArticle: 23837
Hi, I have to automate board level tests with tools from JTAG technologies. The documentation gives an overview. But I don't exactly know how to start. I miss the "big idea". Questions: 1) How can I test the test vectors. Is it possible to simulate the test and different failures? 2) JTAG Technologies uses a Boundary-scan Test Specification Language (BTSL). I believe that this is a proprietary solution, isn't it? 3) I would like to write the tests in VHDL and simulate them. Would it be possible to create BTSL files (application data file .apl, general data file .gen, ...) for the JTAG tools from this VHDL source? Thx Franz Hollerer -- Institut fuer Hochenegiephysik Nikolsdorfer Gasse 18 1050 Wien Austria Tel: (+43-1)5447328/50Article: 23838
Hi all, I would like to learn something more about fpgas, from the hw and sw poit of view. Can anyone suggest me a good book to study? TIA RenzoArticle: 23839
XESS Corp. is releasing the third section of its "myCSoC" tutorial for free downloading at http://www.xess.com/myCSoC-CDROM.html. We will release a new section each week. Each section describes a design example for the Triscend configurable system-on-chip device (CSoC). The Triscend TE505 CSoC integrates an 8051 microcontroller core with a programmable logic array to create a chip whose software and hardware are both reprogrammable. The tutorial examples show how the Triscend FastChip development software is used to configure the TE505's programmable logic into peripheral functions that cooperate with the microcontroller core. -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||Article: 23840
Are you an ASIC Guru? Here is the domain for you: AsicGuru.com.. http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=377615972Article: 23841
FPGA designers, I was wondering if any of you have seen hold-time violations in your FPGA's (for paths between internal flops). I had thought that hold times were "taken care of", i.e. the designer doesn't need to worry about them. For instance, the Xilinx data book quotes a 0ns hold time requirement. However, I believe I have seen hold time violations in my design, which was first in an Altera Flex10K, and is now in a Xilinx Virtex 400. The problem has occurred in both FPGA's. The specific logic involves a flop that is clocked by an externally generated (off-chip) clock. This flop is supposed to "toggle" (i.e go from x to x_bar) when this external clock rises, and another internal condition is detected. Thus the output of this flop wraps back to the input quite quickly (although it does go through some logic.) Still, I would not expect this to fail hold unless the clock was poor (it seems to be quite clean). However, this toggle flop (as described above) fails in the FPGA in lab, from 1 to 10% of the time. It is definitely not a setup timing issue, since all flop inputs arrive well before the clock. It sure look like a hold time problem, since I see the input and the output of the flop glitch, then return to their original state, when the clock rises. I added some extra delay to the feedback path yesterday, and now it works great. Anyone have any comments? I would be interested in hearing similar experiences. Matt Gavin Rockwell CollinsArticle: 23842
Work on the cutting edge of wireless technology! A firm in Portland, Oregon, specializing in the design of wireless products for consumers, is looking for RF and baseband designers. You must have a minimum of 3 years of professional experience designing electronic devices. Visa sponsorship will be considered for the right candidates. Please send your resume and contact information to margaret_dailey@oxfordcorp.com, or call Margaret at 503-291-5250. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 23843
Hi - The thing that makes me think that this is not a device-related hold time problem is the fact that you have seen malfunctions in both your Altera and Xilinx implementations. You commented that the clock seems to be fine. What kind of 'scope and probe did you use to look at the signal? For modern logic, you'd want a scope/probe combination with a bandwidth of around ~1GHz minimum (I'm referring to analog bandwidth here, not sampling rate). And even 1GHz bandwidth might obscure a glitch that's less than ~0.5ns wide. Be sure to look at both rising and falling edges of the clock, as a glitch on either may be misread by the FPGA. Your observation that adding delay in the flip-flop's output-to-input path seems to fix the problem is consistent with clock glitching. If the flip-flop is seeing two closely-spaced rising edges instead of one, delaying the feedback might keep the flip-flop from seeing its output change until after the second clock. This may be why, when you don't add delay, you see the flip-flop change state very briefly (after the first clock event) and then change back (after the second clock event caused by the glitch). Another possibility is that the other signals that condition the toggle are not synchronous to the target flip-flop. Are they clocked out of flip-flops that are clocked by the same clock as the target flip-flop, and are you using a global buffer to distribute that clock? Bob Perlman On Wed, 12 Jul 2000 07:13:10 -0500, Matt Gavin <mtgavin@collins.rockwell.com> wrote: >FPGA designers, > >I was wondering if any of you have seen hold-time violations in your >FPGA's >(for paths between internal flops). > >I had thought that hold times were "taken care of", i.e. the designer >doesn't >need to worry about them. For instance, the Xilinx data book >quotes a 0ns hold time requirement. However, I believe I have seen >hold time violations in my design, which was first in an Altera Flex10K, > >and is now in a Xilinx Virtex 400. The problem has occurred in both >FPGA's. > >The specific logic involves a flop that is clocked by an externally >generated (off-chip) clock. This flop is supposed to "toggle" (i.e go >from >x to x_bar) when this external clock rises, and another internal >condition >is detected. Thus the output of this flop wraps back to the input >quite quickly (although it does go through some logic.) Still, I would >not >expect this to fail hold unless the clock was poor (it seems to be quite >clean). >However, this toggle flop (as described above) fails in the FPGA in lab, > >from 1 to 10% of the time. > >It is definitely not a setup timing issue, since all flop inputs arrive >well before the clock. >It sure look like a hold time problem, since I see the input and the >output of the flop >glitch, then return to their original state, when the clock rises. > >I added some extra delay to the feedback path yesterday, >and now it works great. > >Anyone have any comments? I would be interested in >hearing similar experiences. > >Matt Gavin >Rockwell Collins ----------------------------------------------------- Bob Perlman Cambrian Design Works Digital Design, Signal Integrity http://www.best.com/~bobperl/cdw.htm Send e-mail replies to best<dot>com, username bobperl -----------------------------------------------------Article: 23844
Bob, thanks much for your comments. I will check the scope/probe I am using, but I suspect it isn't close to 1GHz. In reference to your question about signals that condition the toggle flop: The only inputs to the flop are its own output, and signals which are synchronous to the clock (which I do have on a global buffer). These signals all are setup early since I am using numerous wait states. So there should be no metastability issues due to asynchronous inputs toggling just when the clock rises. Actually, the clock is a "strobe" which asserts for a bus cycle to my FPGA (IOSTRBF from the TI C54 DSP). Its rising edge clocks in data, address and control signals which stay asserted for a clock cycle after the strobe rises. These (address and control) are decoded to toggle the flop input when a read is done to a specific address. FYI, I looked at the original gates in the Xilinx FPGA Editor (nice tool, BTW) and there are two muxes and a LUT in the feedback path that seems to be failing. (so there is at least SOME delay there.) Thanks, MattArticle: 23845
Hi Vivek, Insteadof Max+2, you can try Quartus from Altera, which also keep the link between netlist from Certify/Synplify(may be) through the Native link advanced feature in the tool. You can trace back the signal in your RTL. for more detailed information abt Quartus go to www.altera.com. For my design I am using Certify and Quartus flow and it seems to be fine.... Sanjay <khanzode@yahoo.com> wrote in message news:8kfs1h$2e6$1@nnrp1.deja.com... > Hi, > > We have recently started desinging using Verilog and I have a question > regarding the timing simulation. Altera FPGAs (10KE series) is used for > the most part. > > The design flow is as follows: > > 1. Write code in Verilog > > 2. Functional simulation using VCS > (Synopsys Verion 5.1NT running on an NT workstation) > > 3. Synthesis using Synplify. > > 5. Place and route using Max+PlusII 9.6 > > I have not been able to perform the full chip timing simulations very > effectively. > > After synthesis, Synplify changes a _lot_ of internal nodenames and I > have not found a way to observe the timing between some of these > signals. Is there a way this can be performed with the above set of > tools? I would appreciate any help from someone who has used the .vo > file generated by Max+Plus II for timing simulation of the whole design. > > I am running into situations where the functional simulations (with > phantom delays in combinational statements) are fine, but the > synthesized design doesnot work on the bench. I also need the timing > simulation to accurately estimate the top speed of the design. > > Thanks, > > -- Vivek > > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 23846
Jan Gray wrote: > . . . > HLL synthesis, I'm ambivalent about. I hate wasting hardware, but I > understand others are more sanguine about that. I don't like wasting gates and flops either, even though they aren't very expensive anymore. What I do like is finishing on time and knowing the thing is going to work as well as the simulation. > I wonder just how much of an > improvement over HDLs they are, given you often don't get the full HLL > semantics, If you are into data structures and algorithmic processes, the improvement is significant. The best tools can infer counters and memory. The only significant semantic restriction is WAIT delays. > and apparently you often need to add pragmas and directives to > help synthesis make the right things parallel and/or sequential, > put the right data in registers or internal RAM or external RAM, etc. Apparently you haven't tried Exemplar. No pragmas. Just code. > Are they a revolutionary development that will make it > easy for your average C/Java programmer to design hardware? Will they let > you push a button and get hardware from a dusty deck C or Java library? I > doubt it. I agree. You might recover a function or single process. Real hardware involves multiple concurrent processes. > Software design concerns are quite different from hardware design > concerns. Also, I believe that a good C programmer can pick up Verilog and > Verilog concepts about as easily as they can learn the additional keywords > and directives and restrictions necessary to infer comparable hardware with > an HLL synthesis system. It can be done, but not without lots of learning time. Knowing C helped me a little with VHDL. My main problem was learning from examples left over from first-generation synthesis and simulation tools. > Perhaps someone who uses and prefers HLL synthesis can share their > experiences. I am a logic designer who started with schematics and a logic analyzer with lots of little clip-probes. I now do HLL design, sim and synthesis. I don't need the logic analyzer any more -- just a single logic probe. If it wiggles, it's working. -- mike.treseler@flukenetworks.com or -- tres@tc.fluke.comArticle: 23847
In article <yeSa5.1842$4U4.326883@paloalto-snr1.gtei.net>, Jan Gray <jsgray@acm.org> wrote: >In my opinion, generators can have all the 'explicitness' advantages of >schematics, plus text representation, HLL integration and programmability, >with none of the disadvantages. There is just a critical mass adoption >issue -- in lieu of one dominant approach, there is no opportunity for reuse >across existing experimental systems and none have seemed to gain traction. As one of the primary developers of one of the generator systems [Chu, Weaver, et al], I have to disagree somewhat. The explicitness of generators is VERY good for certain aspects of a design, namely datapath and datapath macros, especially parameterized macros, but it ends up suffering severly when trying to do a complete design. What I believe would be effective would be a generation system integrated into a conventional cad tool flow. The current CoreGen system from Xilinx would offer this potential, but they haven't released their API so that joe-ranodm-user can use the system to create new cores, only instantiate Xilinx designed ones. Probably because creating a good API for module generation is not easy, and the languages don't help things. You want to do a great deal of introspection, deducing structure from what the programmer specified and created, yet both C++ and Java fail miserably at it. C++ doesn't even attempt metalinguistic abstractions, and Java's (the Reflection interface) is almost hopelessly crippled by security restrictions. And Java doesn't have good overloading mechanisms of operators, which would make the syntax much cleaner for many operations. A language like CLOS might be better suited, but then you have an even harder task of adoption, at least with C++ or Java. Unfortunatly, I have got to take off now, so I can't add more thoughts at this time. But I will try to post a good discussion when I get back (fri/sat), explaining my thoughts in more detail. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 23848
In article <396C60D5.4DFFE2F6@collins.rockwell.com>, Matt Gavin <mtgavin@collins.rockwell.com> wrote: (snip) > > It is definitely not a setup timing issue, since all flop inputs arrive > well before the clock. > It sure look like a hold time problem, since I see the input and the > output of the flop > glitch, then return to their original state, when the clock rises. > > I added some extra delay to the feedback path yesterday, > and now it works great. > > Anyone have any comments? I would be interested in > hearing similar experiences. > > Matt Gavin > Rockwell Collins > > Did you use a global glock input and net? The 0ns hold time spec is only valid if you do this. If you use normal inputs and routing resources for clocks, then you can have hold time violation problems. -- Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.com Sent via Deja.com http://www.deja.com/ Before you buy.Article: 23849
Matt Gavin wrote: > FPGA designers, > > I was wondering if any of you have seen hold-time violations in your > FPGA's > (for paths between internal flops). > > I had thought that hold times were "taken care of", i.e. the designer > doesn't > need to worry about them. For instance, the Xilinx data book > quotes a 0ns hold time requirement. However, I believe I have seen > hold time violations in my design, which was first in an Altera Flex10K, > > and is now in a Xilinx Virtex 400. The problem has occurred in both > FPGA's. > > The specific logic involves a flop that is clocked by an externally > generated (off-chip) clock. This flop is supposed to "toggle" (i.e go > from > x to x_bar) when this external clock rises, and another internal > condition > is detected. Thus the output of this flop wraps back to the input > quite quickly (although it does go through some logic.) Still, I would > not > expect this to fail hold unless the clock was poor (it seems to be quite > clean). > However, this toggle flop (as described above) fails in the FPGA in lab, > > from 1 to 10% of the time. > > It is definitely not a setup timing issue, since all flop inputs arrive > well before the clock. > It sure look like a hold time problem, since I see the input and the > output of the flop > glitch, then return to their original state, when the clock rises. > > I added some extra delay to the feedback path yesterday, > and now it works great. > > Anyone have any comments? I would be interested in > hearing similar experiences. > > Matt Gavin > Rockwell Collins Have you tried running the Xilinx timing analyser with the -min flag set to get a minimum timing analysis. This will work o.k. with Virtex if you have the later service packs (SP4+ ?) that put the min values in the timing files. The Xilinx help line has just told me that the min values for -E parts aren't released yet.
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