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
>let us assume the following situation: > >I have an 16bit bus which is synchronous to an external clock 30MHz. >If I sychronize this bus with a set of three stage-flip flop-chains >clocked by an internal generated 90MHz clock >will the sampled pattern be wrong? >I do not know if you were talking about asynchronous bus without any clock >or if you were talking about asynchronous bus with regard to the FPGA internal >sampling clock. What have you gained by running the bus through 3 stages of FF? You have solved the metastability problem, but you haven't solved the problem of how to get a data word from one clock domain to the other. The simple approach is to use a FIFO. Just look in your cookbook. That's a lot of resources for such a simple problem. So you can build a special purpose bus transfer module. The general idea is that the source domain togles a data-ready FF and loads the data into a holding register. Data-ready goes through the classic pair of metastability FFs. Then it goes to an edge detector to enable copying the data from the holding register to the output clock domain. One problem is that 3 is a small number. Can you get through all that logic before the holding register gets reloaded? Maybe, but I think it requires pushing logic back into the "metastability" FFs. 90 MHz is not fast with modern logic. You might have enough time to do that. Plan two is to use 2 holding registers. If the data-ready FF is high, load into one register. When it's low, load into the other. That gives you 6 clocks on the output side to grab the data before it changes. Should be simple. -- 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: 78501
Why do you want to re-invent the wheel when there are perfectly good mp3 decoder chips which will do the job? As for usb memory sticks they are designed to use IDE under the USB interface so the problem of driving them is the same as a IDE disk plus the USB driver. If you don't know anything about the mp3 alogo then what makes you think that its a suitable project?Article: 78502
hi, I'm working in VHDL with ISE6.3 and ModelSim5.3. I'm using synchronous and asynchronous reset. process(clk,ARST) if ARST='1' then -- elsif rising_edge(clk) then if SRST = '1' then -- else -- end if; end if; end process; I put constraint on synchronous reset, but I don't know constraints need by an asynchronous reset. When I simulate my design, it's working with the synchronou reset and I have Hold/setup error with asynchronous reset.Article: 78503
The only 'sensible' approach is to get people into the habit of using strong encryption of sensitive data when travelling,using something like pgp,anything else just shows a lack of trust.Article: 78504
On 1 Feb 2005 12:01:58 -0800, daveb_24_7@yahoo.co.uk (Dave) wrote: >Does anyone have a suggestion for a practical book (Horowitz & Hill >style) or links, papers, etc. for VHDL, especially synthesis for FPGAs >? The books I've come across are a bit lacking in this respect. Have you seen these? Both of them press the right buttons for me: Rushton, A: VHDL for Logic Synthesis (Wiley) Zwolinski, M: Digital System Design using VHDL (Prentice-Hall) >Lastly, I get "Unable to retrieve message ..." when clicking on the >post follow-up button. Am I doing something wrong? No idea. There are so many newsreader tools around. I use the free version of Forte Agent and never have any trouble like that (although the free version lacks a few features that some people would probably miss, such as cross-posting). -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 78505
Peter Alfke <alfke@sbcglobal.net> wrote: > Thanks, "Bob". > There was some confusion about the apparent or virtual delay between > slides, and I should perhaps have talked more slowly. But totally I am > happy. ... Is the recording of the talk available on the net? -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 78506
Peter Alfke wrote: > Thanks, "Bob". > There was some confusion about the apparent or virtual delay between > slides, and I should perhaps have talked more slowly. But totally I am > happy. It was interesting to note that the slides seemed to appear on this side of the pacific, before you were able to see them ? > No responses yet (except yours), but perhaps later. > The emotional words about benchmarks were no play-acting. I still have > scars from Altera's reckless destruction of the old PREP cooperation, > more than a dozen years ago. And they are still up to their same old > trickery. I did think (evil grin) of asking about "Why not use PREP for FPGA benchmarks ? " > Their newest game is giving leakage current values at 25 degrees. Nice > numbers, but totally meaningless and utterly misleading. How does one > expose this? Legally, it's not exactly a lie, but it has the same > effect as if it were. Some engineers and managers may even be > inexperienced enough to fall for this kind of nonsense. The question is > just: How fast will it backfire? The earlier, the better ! ... Wait for the app notes covering thermal runaway on FPGAs ? > No wonder smart engineers have developed a deep suspicion of > marketing... -jgArticle: 78507
Rudolf Usselmann wrote: > Antti Lukats wrote: > >> confirmed: chipscope can be used, in case the PLD is added to chain (the >> 3 jumpers fix in V4LC board) when bitstream is loaded with impact and >> chipscope ICON sits on BSCAN/USER1. downloading with chipscope does not >> work, simultanuous use of MDM and Chiscope in EDK doesnt work. >> >> antti BTW, the PLD is add in front of the FPGA, so it does NOT fix the TDO timing (which goes directly to the cable). Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and SynthesisArticle: 78508
Oops, turned out the problem lay with a missing line of code in one of the files assigning a signal to an output. This meant that most of the logic in the parent file was 'dropped' by the compiler and synthesis stages. Only it was doing it without warning or error, hence the focus of attention being on the compiler behaviour. memo to self: must upgrade to current tool versions :) Thanks to all those who responded to me directly. nigel g. -- Nigel Gunton Phone : +44/0 117 32 83167 /"\ Senior Lecturer, School of Electrical & Computer Engineering, \ / CEMS, University of the West of England, Bristol. X ASCII Ribbon Campaign against HTML email & microsoft attachments / \Article: 78509
Hello, > I am thinking of building a fully functional mp3 player with an FPGA. I > will appreciate any help if your guys can give me any suggestion. I > want the design to be as original as possible. For example: I prefer to > implement mp3 decoding mechanism inside an FPGA by myself, rather than > purchasing an off the shelf mp3 decoder. Doing the whole MP3 decoding in hardware is a huge amount of work, you might instead consider doing some hard-soft co-design, and put in hardware only the most time consuming kernel of the App. Even though this is still a *very* ambitious project. > My preliminary spec is a > simple mp3 player with an FPGA, USB memory stick, an LCD display, a > keypad and whatever other external components necessary to build a > complete system. What type of FPGA ? > 1. If I use USB memory stick, is it significantly more difficult than > using IDE harddrive? Yes, since you will have to handle the USB protocol stack, and handle a filesystem on the USB stick. This must be done in software. > 2. Where can I download the mp3 specification and algorithm? Is it in > public domain, or is it a copyright secret? You could start from a simple C code application (others implementation such as libmad exist, but there a much more complex) : http://www.mp3-tech.org/programmer/sources/dist10.tgz > 3. What kind of other external components needed to implement this > project? A digital to analog converter for sound output ! > 4. Do I need an advanced knowledge in DSP for this project? I have > basic background in DSP, but not at advanced level. You have to be able to understand the use of fixed point arithmetci, since floating point will be very difficult to implement in an FPGA. > Thanks in advance! You are welcome, Steven > > Hendra >Article: 78510
Peter Alfke wrote: > There seems to be a misconception that you can Gray-code any bus. Not > true. > Gray-coding applies only to counters, where it guarantees that only one > bit changes on any transition. There is no "general purpose" Gray > coding ... Sure, a bus cannot live from 1 bit transitions. I was unclear about that. A clock as qualifier is appropriate. ReneArticle: 78511
ALuPin wrote: > Dear Mr Tschaggelar, > > let us assume the following situation: > > I have an 16bit bus which is synchronous to an external clock 30MHz. > If I sychronize this bus with a set of three stage-flip flop-chains > clocked by an internal generated 90MHz clock > will the sampled pattern be wrong? > > I do not know if you were talking about asynchronous bus without any clock > or if you were talking about asynchronous bus with regard to the FPGA internal > sampling clock. Sorry I was unclear. You need the clock(or alike) together with the data. Say the data is valid when the clock(or alike) is high. That makes it much simpler. Discard everything unless the clock(or alike) is high. If the clock is the real clock of the data, then the data may be valid from the rising slope. Some delay and perhaps pulseforming circuit may be required. ReneArticle: 78512
scheidt@gmail.com wrote: > Only using 2-stage ganged synchronizer flops to move a data > bus from one clock domain to another is GUARANTEED to fail. > > A metastable event on any of the synchronizers will > delay the transition on that bit causing a wrong value to > appear on the bus in the receiving clock domain. > > Now if your data is an incrementing Gray code pattern, where > only one bit changes per increment, you can use synchronizers over a > bus, but this is a special case. (We > use this in implementing asynchronous FIFOs where we > need to pass read and write pointers across the clock > domains - but that's another story...) > As Peter mentioned : A bus that allows only one bit changes is boring and rather limited. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 78513
Hello, i'm writing some software for the ppc405 on a virtex2pro using a standalone-environment (EDK6.2). At some point i need to do some memory alloctions. I read about xil_malloc in the xilinx-docs. But all i can find when enabling the "needs xil_malloc" checkbox is a xil_malloc.h (redirecting malloc-calls to xil_malloc). But i can find no implementation for xil_malloc, xil_free.. . When using xil_malloc the linker complains about udefined references to xil_malloc. Using malloc works but takes a lot of space. So if someone used xil_malloc successfully and could give me a hint where to find it?Article: 78514
Hi, Probably you can try the following 1.constrain asynch reset to pass through a global net- this will clean the hold violations. 2.To clean set-up violations- may be you have to take care adjust time between asynch reset removal and clock active edges. Hope this will help.Article: 78515
On 02/01/2005 05:48 PM, JT wrote: > How can you get ModelSim to print the wave window in color? I tried printing to a color printer and only got BW. Select File -> Page setup... in the wave window. There is a radio button for the output color. My version is Modelsim 6.0b. HTH & HAND, StefanArticle: 78516
Hello, while I have no answer to your question, I was intrigued enough to play around in the FPGA editor for some (too long) time. One way to approach this problem is to try and free the BY input, which I assume is used as DI input of site G (through the DIG_MUX). If BY can be freed, it can be used for REV of the FFX and FFY. Now, one can not use the ALTDIG input with a shift register (why?), leaving only SHIFTIN as a candidate. Paradoxally it may be possible to construct a delay line "SRL32+FF" by placement of a SRL16 in RLOC X0Y1 BEL constraint "F", which shifts out to a SRL16 cascaded in RLOC X0Y0 BEL constraint "G". The output of this second SRL16 goes to FFY. The input to this SRL32+FF is to BX of RLOC X0Y1 BEL "F". Intrigued, NossumArticle: 78517
Hi,
I'm working on a small research project, for which I'd really like to be able
to modify a post-PAR Xilinx design. Specifically, I'd like to remove routing
information for a single net, add have it rerouted with new timing constraints.
So far I have come accross two possible ways of realistically doing this, but
they both have problems.
1. Use JBits
The problem with using JBits is that it doesn't look like it has
a router advanced enough to (among other things) take into account
timing constraints. Also the bitfile format loses all symbolic naming
information, which is something it would be very helpful to use to guide
this process.
2. Modify the PAR'ed NCD directly a'la FPGA Editor but automated
I came accross XDL which looked like it might do the trick. So I tried
a simple experiment:
1. PAR a simple design to NCD format
2. convert the NCD to XDL
3. remove the PIP information for a single net in the XDL file
4. convert the XDL back to NCD (including compensating for the lost ISET
information as in Xilinx Answer record #17204)
5. re-run PAR on the original (unplaced) NCD using the modified ncd->xdl->ncd
file as a guide in 'exact' guide mode.
This sort of works, but the guide report suggests that there isn't a
100% match between the guide file and the original NCD (see below),
and seems to think that 129 signals rather than 1 need re-routing. This
really isn't ideal for me, as I'd like to leave as much of the initially
PAR'ed design intact as possible.
It'd be really good if I could get this technique to work, but I can't
understand why there are mismatches between the two NCD files and more
than one net that needs re-routing. I also found that even if I omitted
stages 2-4 from my expt. above and just used the fully PARed NCD as a
guide, there are still mis-matches between this and the unPARed NCD.
Does anyone have any comments or suggestions on how I could refine this
process, or an alternate method I could use?
Thanks,
- Jake
Snippet of output from the guided PAR:
Xilinx Place and Route Guide Results File
=========================================
Guide Summary Report:
Design Totals:
Components:
Name matched: 1873 out of 1873 100%
Total guided: 1873 out of 1873 100%
Signals:
Rejected Implicit/Internal: 3046 out of 7238
Name matched: 4192 out of 4192 100%
Total guided: 4191 out of 4192 99%
Total connections guided: 8582
Guide file: "modified_xdl.ncd" Guide mode: "exact"
Components:
Name matched: 1873 out of 1873 100%
Total guided: 1873 out of 1873 100%
Signals:
Name matched: 4192 out of 7238 57%
Total guided: 4191 out of 4192 99%
Total connections guided: 8582
...
Phase 1: 129 unrouted; REAL time: 8 secs
Phase 2: 0 unrouted; REAL time: 31 secs
...
Article: 78518Sorry I just found a solution to my own problem. I realised that the FPGA editor is scriptable. Some preliminary playing leads to me believe I can do what I need to using a combination of this and XDL. I would still be interested to hear why the guide NCD file failed to match the unPARed NCD file if anyone knows... Thanks, - JakeArticle: 78519
"Jim George" <jimgeorge_@_gmail.dot.com> wrote in message news:xN6dncF6IvN47J3fRVn-tQ@comcast.com... > Hi, > Why is it that you cant put a FDRE and an SRL16E on the same slice? I > looked at a V2 slice within FPGA Editor (woohoo, got the full version of > ISE at last!) and it shows me there's a WE signal going to the SRL16, > driven by the slice's SR input. Now why would you want to drive it with > the SR input when there's already a CE input available??? I wanted to > construct a delay line (SRL16 + FF), whose output FF can be reset but > then this is not allowed. Any workarounds? > Thanks. > -Jim If you need to reset the flop, use an external flop. You can still pipe the SRL through the non-reset flop if your shift clock is so fast you can't tolerate the clock-to-Q plus routing for the final, external, resettable flop.Article: 78520
I saw the material and Altera's story as well. Why is Altera talking these unknown design based benchmarks that deal only with the fabric ? I have had more problems meeting I/O bandwidth and timings for 266Mhz I/O designs than anything else.Article: 78521
Hi Brian, Comments below. "Brian Davis" <brimdavis@aol.com> wrote in message news:1107316023.395368.177070@c13g2000cwb.googlegroups.com... > Kolja wrote: > > Also, if the A/D is only 4 mm distant from the FPGA, I'd start > worrying about power/gnd plane noise & bypass problems, and then > start considering moving it farther away :) > > Or, are you splitting A/D and FPGA ground & power to provide > supply isolation, and then running coupled pairs across the > plane cuts to the FPGA? > Ah well, here I go. This may generate some traffic. Don't split the ground plane. Ever. It's your reference. I hear all this stuff about currents flowing through the plane giving voltage noise. Doesn't matter, with _proper_ bypassing, everything is coupled to the ground plane so it all goes up and down locally with the plane anyway. Separate power is of course a good idea, and in fact probably necessary. Each power area is isolated from other power areas but tightly coupled to the ground plane locally. As for your digital signals, keep them close to the ground plane all the way to their destination. Occasionally you'll see an app note from a ADC vendor saying you can use a split plane, but all their sample/demo boards always have a single non-split plane. I've come to think this is because they want to keep die-hard plane-splitters using their parts. I guess these customers make a LOT of prototypes! Cheers, Syms. p.s. Hey Kolja, did you look at those resistor packs?Article: 78522
"Symon" <symon_brewer@hotmail.com> wrote in message news:36cireF4vupthU1@individual.net... > Ah well, here I go. This may generate some traffic. > Don't split the ground plane. Ever. It's your reference. Just to clarify, I'm not saying a split plane won't work. I'm saying that with proper bypassing/decoupling it won't work any better than a single plane. Cheers, Syms.Article: 78523
Here's a question I know has already been asked but I was not satisfied with the answer. How could I get Quartus II to support the FLEX 8000 devices? I've already got a couple of FLEX 8000 chips and a complete version of Quartus II 4.1. All the FLEX family is supported (6000, 10K, 10KA and 10KE) except for the 8000. Is there a way to add the FLEX 8000 to this list? I would really prefer working with Quartus II than Max Plus II. thx, VincentArticle: 78524
Symon wrote: > > Just to clarify, I'm not saying a split plane won't work. I'm saying > that with proper bypassing/decoupling it won't work any better than a > single plane. > I didn't intend to wholeheartedly endorse splitting up the ground plane, but only to question how Kolja was planning to lay out the board, and suggest that appropriate care and attention be paid if attempting such a crossing with the LVDS pairs in question. Brian
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