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
I can obviously not speak for Altera, but here are some general observations: If the manufacturer made sure that all dc-consuming utilities are turned off as soon as the normal Vcc disappears, and if the process is somewhat old-fashioned ( >0.5 micron), then there is a chance. XC3000L used to consume <50 microamps, which is an acceptable (barely!) value. If the manufacturer did not pay special attention, and does not indicate so in the data sheet, your hopes are slim. For all really up-to-date devices with geometries below 0.2 microns, (or 200 nanometers as it is more fashionably called), there is no hope. The inherent so-called leakage current is milliamps ( and more). But you can always try it out by measuring, both at room and at slightly elevated temperature... Peter Alfke, Xilinx Applications ==================================== Chris Cowdery wrote: > I am considering using a lithium battery on a board instead of a > config device to enable my Altera FLEX10KA to retain its > configuration. > > Has anyone any idea of the absolute min quiescent current I can expect > a 10KA to draw? > > Thanks, > > Chris.Article: 40426
Lars Rzymianowicz <larsrzy@atoll-net.de> wrote in message news:3C85C76F.3B5FA1A5@atoll-net.de... > And since Xilinx and most other EDA vendors support Linux now, why > step down to the bluescreen? Just to be clear here, the Xilinx Linux solution is currently limited to command-line only on WINE. For those unfamiliar with this approach, check out http://www.winehq.com . Briefly, WINE is a piece of software that sits between a Windows application and Linux and maps your Windows system calls to Linux OS calls. The whole point to WINE is that you don't have to change your Windows application at all - rather you make sure that WINE is smart enough to handle all the pieces of Windows that your program uses. Running Xilinx tools on Linux via WINE means that Xilinx made sure that WINE was able to handle all the system calls the the command-line version of their tools required. There were probably few (if any) changes made to the original Xilinx Windows software. Any limitations that the Xilinx Windows software has under Windows will still exist on WINE-on-Linux. BLATANT ALTERA PROMOTIONAL PLUG: The Altera Quartus II Linux port is a true Linux port tested for compatibility with RedHat's v7.1 Linux release. END BLATANT ALTERA PROMOTIONAL PLUG. -Pete-Article: 40427
Wow, I don't normally like to get involved, but here goes: > One of my major complaint of QII 1.1/2.0 (only tried Web Edition > though) is that for some reason, QII drains Windows 9x's system > resources much more heavily than ISE WebPACK. > Because Windows 98 is so bad, I always have to put Resource Meter on the > side of my screen, and whenever QII is running, I see it draining large > amounts of system resources, which comes back if I exit QII, but each > time this happens, I have to interrupt what I was doing, and I don't > like that. > Altera seemed to have made no improvements there compared to QII 1.1. > I read somewhere that Altera doesn't recommend using QII under Windows > 98, and instead recommend using Windows NT 4.0 or 2000, but I sort of > suspect that is because the system resource issue. > I do notice that Altera uses much more graphics than Xilinx in QII, and > that might be another reason why it drains system resources heavily. All I have to say here is avoid QII on Win 98. I ran into several bugs, and had to work around them... > From what I see, the improvements made from QII 1.1 to 2.0 seems > small, although I do appreciate that Altera added ACEX1K support in QII > 2.0 WE, but other than that not too much has changed. > Perhaps, Altera should have called QII 2.0 as QII 1.2. > I guess raising the version number is important to show that major > improvements are being made, so that people will upgrade, but I think if > things don't improve too much, that turns into disappointment. Altera made some "major" improvements moving from V1.1 to V2.0. Some of which include smaller installation size, better database management (ie smaller databases (approx 30x reduced vs V1.1) taking up less HD space), faster compile times (relative term though), and better performance (higher fmax). I suspect that the change in the version number (to 2.0) corresponds with the change in year (2002). From what I gather, V2.1 will be out in the June/July timeframe. > The problem I had with QII 2.0 + LS-Altera (NativeLink) + > FLEX10KE was something that QII 2.0's NativeLink script tried to > reference "flex10ke.syn" instead of "flex10e.syn." > Being a beginner of QII tools, I had no idea what was going on until I > was told to look at the LS-Altera's directory for the file, and after I > noticed that small file name difference, it was easy to workaround it > (make a copy, and rename it to match QII 2.0's NativeLink script), but > it also shows that Altera must have forgotten to test QII 2.0 (Verilog > flow) + LS-Altera (NativeLink) + FLEX10KE or ACEX1K combination before > releasing. > Not only that, in QII 1.1, NativeLink with LS-Altera (2001.1a_28) didn't > even start (crashed at Quartus_cmp.exe), and I suspect lack of testing > for the crash. NativeLink... I gotta tell ya, I don't use it. There's a warm and cozy feeling I get running the LS front-end tool, then importing the .EDF into QII. That way I know that everything gets done "right"... > Having seen these software problems, it is not surprising to me > that no wonder Altera has only 10% of a highend FPGA market, and rest of > 90% belongs to Xilinx. Hmmm, while I believe that Xilinx has a larger market share, it wouldn't suprise me to see the market turn (since it always does). > I read some time ago on EE Times that much of the reason customers > choose Virtex instead of APEX20K several years ago is because the > quality of Quartus wasn't as good as Xilinx's software offering at the > time. > To me, software stability seems to be Altera's weakest point even now. Stability was definitely a huge issue with the first release of Quartus. Now that Quartus II is released, stability has gotten quite (I mean a whole lot) better. I suppose that's my two cents worth, and I hope its not too biased since I am an Altera advocate... rgds, -TerryArticle: 40428
On Wed, 06 Mar 2002 14:49:06 GMT, Ray Andraka <ray@andraka.com> wrote: >It sounds like we are all barking up the wrong tree. The solution is not to >go to more and more memory...There is something to be said about using low >cost PCs...instead, Xilinx needs to get the modular flow working so that one >can truely partition a design and run each partition through the entire >process, including place and route. The individual completed parts can then >be stitched together. Until the modular flow is working though, we are stuck >with the memory limits of the machines we work on. Quite apart from the reduction in memory, this would also make PAR much quicker! I'm sure some of the algorithms they use must be at least O(N^2), so breaking the problem into two halves will halve the total time taken. (Or something like that.) BTW, I see a significant speedup for large designs in Synplify if I use the syn_hier attribute, which stops optimisations across module boundaries. Regards, Allan. >Johann Glaser wrote: > >> Hi! >> >> > The best solution is to move to 64-bit processors: Sun, IBM and HP (and >> > some others) offer 64-bit workstations now, and there are a lot of EDA >> > tools available (including all Xilinx tools). This is also a pretty >> > expensive solution: workstations are much more expensive than PCs >> > (probably slower nowaday), and EDA S/W for Unix is usually much more >> > expensive than the same S/W for Windows (not familiar with Linux >> > pricing). >> > >> > Right now, we are eagerly waiting for the AMD Hammer - this appears to >> > be the perfect solution for us Windows users who are trying to build big >> > FPGAs. >> >> This is the one solution. Use 64-bit pointers. Available in Linux >> nowadays, upcoming for Windows in the future (but perhaps only in special >> versions). Or on Workstations. >> >> Another idea would be to use a cluster for P&R. So, therefore P&R must be >> done for some independant and seperabel parts. I don't know how P&R >> software works and I'm afraid, it always needs the whole memory region, >> but if smart programmers find a way to split P&R into several standalone >> processes with only few communication, the easiest solution is a cluster. >> >> On machines with more than 3GB RAM each process itself can use 3GB. >> Several processes so can use the whole memory. So, it isn't even necessary >> to distribute the processes to numerous PCs. >> >> Linux is used very often for clusters, look for Mosix or Beowulf. In an >> office with several FPGA designers all their PCs can be equiped with e.g. >> Mosix and if one of them needs to do a P&R cycle, all PCs work together. >> The priority system in Linux will do the rest, so all other workers don't >> recognize a lot of the heavy load on their machine, because local >> processes get fast reaction. >> >> "Fork and forget". Use more than one process for P&R and the rest is done >> by the OS and the cluster Software. >> >> Advantage: >> - each PC can be a "normal" one with a rational amount of RAM and a not >> too expensive processor >> - enormous speed up of P&R >> - we will get native Linux tools :-) >> >> Or, why should your processor wait for your next keypress running at >> 2GHz? ;-) >> >> Bye >> Hansi >Article: 40429
In article <3c86fdd9.8868772@netnews.agilent.com>, Allan Herriman <allan_herriman.hates.spam@agilent.com> wrote: >I'm sure some of the algorithms they use must be at least O(N^2), so >breaking the problem into two halves will halve the total time taken. >(Or something like that.) No to mention that if you can do a good partitioning, you are a long way towards making the tools able to use SMP and SMT architectures. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 40430
On Wed, 06 Mar 2002 18:19:46 -0500, Greg Neff <gregeneff@yahoo.com> wrote: >On Wed, 06 Mar 2002 21:08:39 GMT, John_H <johnhandwork@mail.com> >wrote: > >I have not looked at the CEPT standard. We are using E1 physical >layer stuff for a non-telecom application. Does the CEPT standard >talk about mutual clock synchronization? If so, I would appreciate a >pointer to this standard. I though that E1/T1 systems were typically >clocked in a master/slave arrangement, or lived with slips. > > With regard to stability, I was thinking about the stability of the >democratic clock, due to multiple feedback paths to the multiple phase >error detectors on each PLL. > >>The references for stability... shouldn't they be contained in the >>ITU-T specifications regarding E1 reference timing? The clock >>distribution schemes, switchover conditions on signal loss, acceptable >>jitter transfer and tolerance are all part of the CEPT standard. Very >>constrained. >(snip) As the other posters have mentioned, a "democratic" approach to timing is unusual, and (to me) doesn't make sense. Regarding the ITU-T specifications, I think you should look at the SONET/SDH specs instead of the E1 ones. Try: ITU-T G.707 (SDH) and the G.810 series (SDH timing). Also GR-253 (SONET). Even the Network Time Protocol (RFC1305) that is used to synchronise time of day clocks on computers has a hierarchy of timing sources. But it might give you some ideas that will help you with your problem. http://www.ietf.org/rfc/rfc1305.txt Oh, you should probably look at the datasheets for chips that are designed for phone network timing, e.g. Zarlink (nee Mitel) MT90401 http://products.zarlink.com/partfinder/prodprofile.cgi?device=1127 or maybe this one from Semtech: http://www.semtech.com/products/sets.html Regards, Allan.Article: 40431
Hi everyone in my design, some module use high active reset, and other use low active reset, and the global reset is low active, so all high active reset is generate by pass global reset through an inverter, if this will cause any problem?Article: 40432
ssy wrote: > > Hi everyone > > in my design, some module use high active reset, and other use low > active reset, and the global reset is low active, so all high active > reset is generate by pass global reset through an inverter, if this > will cause any problem? Only if that inverter is placed inside a device that needs reset :-) A tiny logic gate is ideal. -jgArticle: 40433
Maybe I don't quit understand the working of the fpga, so explain me whem I'm wrong. I want to give you give you an example why my resolution needs to be so high. When I'm switching the fets with 300 kHz and I can switch my output with 300MHz, the following is possible. Let's say the duty cycle of my pulse is 40% ( it's always less than 50%). When I switch with 300 kHz, one period is 3,33333 us. the next frequncy I can create at my output = 1/300k + 1/300M = 3,33666 us. That is a frequency of 299,700kHz. That is a difference of 300Hz. Such a difference means at the output of the power supply a change of current of 0.2A. This is because the working frequency is very small. I hope I made clear why I need the high frequency. Ray Andraka <ray@andraka.com> wrote in message news:<3C862BFA.6BD14523@andraka.com>... > See my post to your previous post. Knowing now what you are doing, I am > sure you can get away with a much slower clock. Jitter is not likely to > be much of a problem in this application. If, for example, you use a 10 > MHz clock and a 32 bit accumulator you get a frequency resolution of 0.002 > Hz with jitter no greater than 100ns (1 cycle of the master clock). Your > master clock determines the amount of jitter and the maximum output > frequency (Fclk/2). Resolution is determined just by the number of bits. >Article: 40434
who can introduce some knowledge about pipeline(books/link)?Article: 40435
"Peter Ormsby" <faepete.deletethis@attbi.com> writes: > Lars Rzymianowicz <larsrzy@atoll-net.de> wrote in message > news:3C85C76F.3B5FA1A5@atoll-net.de... > > And since Xilinx and most other EDA vendors support Linux now, why > > step down to the bluescreen? > > Just to be clear here, the Xilinx Linux solution is currently limited to > command-line only on WINE. For those unfamiliar with this approach, check [...snip...] Does anybody know why Xilinx did this rather than porting their Solaris/HP-UX version to Linux? Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 40436
Ray Andraka <ray@andraka.com> writes: > It sounds like we are all barking up the wrong tree. The solution is not to > go to more and more memory...There is something to be said about using low > cost PCs...instead, Xilinx needs to get the modular flow working so that one > can truely partition a design and run each partition through the entire [snip] Johann Glaser: > > Another idea would be to use a cluster for P&R. So, therefore P&R must be > > done for some independant and seperabel parts. I don't know how P&R [snip] I agree with both of you. Even in a hierarchical/modular design methodology you could benefit greatly of a cluster of cheap PCs do do your job. The EDA vendors seems to spend a lot of effort working on their GUIs. I would like to see some effort spent on parallel synthesis and PAR tools. The problem is that this is difficult to add later, you have to design it in from the start. Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 40437
F. Modderkolk wrote: > > Maybe I don't quit understand the working of the fpga, so explain me > whem I'm wrong. > I want to give you give you an example why my resolution needs to be > so high. > When I'm switching the fets with 300 kHz and I can switch my output > with 300MHz, the following is possible. Let's say the duty cycle of > my pulse is 40% ( it's always less than 50%). When I switch with 300 > kHz, one period is 3,33333 us. the next frequncy I can create at my > output = 1/300k + 1/300M = 3,33666 us. That is a frequency of > 299,700kHz. That is a difference of 300Hz. Such a difference means at > the output of the power supply a change of current of 0.2A. This is > because the working frequency is very small. I hope I made clear why I > need the high frequency. Since this sounds like a series resonant power supply, rather than a energy-transfer design, you could look at a 12 bit DAC and a VCO. At 300KHz, this will be 1 part in 4096 in Freq, or in your case, a four fold improve in dI. ( same as a 1.2GHz FPGA :) I believe 300MHz toggle & PLL is do-able in newest generation FPGA, but a 12 bit loadable counter at 300MHz is a bigger ask. Peter or Ray will know the quick answer :-) -jg > Ray Andraka <ray@andraka.com> wrote in message news:<3C862BFA.6BD14523@andraka.com>... > > See my post to your previous post. Knowing now what you are doing, I am > > sure you can get away with a much slower clock. Jitter is not likely to > > be much of a problem in this application. If, for example, you use a 10 > > MHz clock and a 32 bit accumulator you get a frequency resolution of 0.002 > > Hz with jitter no greater than 100ns (1 cycle of the master clock). Your > > master clock determines the amount of jitter and the maximum output > > frequency (Fclk/2). Resolution is determined just by the number of bits. > >Article: 40438
Rick Filipkiewicz <rick@algor.co.uk> wrote: > What are the limitations on the modular design flow in real life ? I've looked at > it and it seems clumsy and awkward but useable as long as the device density > isn't too high, otherwise the limitation to rectangular regions will make layout > difficult. I found that the tool was just unable to properly place the logic. In particular it had no idea how to place the interconnecting flip-flops between the blocks. The modules I defined had very clean interfaces (of up to 100 bits). P&R times were huge with very poor results. I conclude that the idea is good but the current implementation is unusable in my application. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 40439
Hi Is there any equivalent verilog LPM/ALTPM function module from altera for xillinx dualport ram block RAMB4_S16_S16 module.The currently available DPRAM functions from altera(like LPM_RAM_DP,ALTSYNCRAM,ALT3PRAM) do not match the above xillinx DPRAM module. If not how can I implement the DPRAM in altera device. awaiting reply thanx in adv. regards MPSArticle: 40440
Hi my question may seem a bit stupid, but if you know about my condition, you can understand it. these days. I met with serious problem about simulation/synthesis mismatch , so I search everywhere to find the cause, to make the problem even worse, the post syn simulation just can not run correctly. thank you Jim Granville <jim.granville@designtools.co.nz> wrote in message news:<3C8712F0.5DEE@designtools.co.nz>... > ssy wrote: > > > > Hi everyone > > > > in my design, some module use high active reset, and other use low > > active reset, and the global reset is low active, so all high active > > reset is generate by pass global reset through an inverter, if this > > will cause any problem? > > Only if that inverter is placed inside a device that needs reset :-) > A tiny logic gate is ideal. > > -jgArticle: 40441
Hi, We have an old project that used a Mach 5 PLD, programmed in DSL using MachXL software, around 3 years ago. We are now looking at updating the project, and using a Mach 4 PLD instead (when we started, there were no Mach 4 chips that were big enough). But the current design software does not support the old DSL language. Are there any tools or shortcuts that we could use to convert the old DSL project to newer VHDL code? We don't actually need to make any significant changes to the functionality of the design, just to fit it into a newer chip, so we'd really like to avoid having to re-write everything in VHDL (or Verilog). Many thanks for any help or tips. David Brown WestControl a.s Norway. david@westcontrol.comArticle: 40442
Petter Gustad wrote: > > "Peter Ormsby" <faepete.deletethis@attbi.com> writes: > > > Lars Rzymianowicz <larsrzy@atoll-net.de> wrote in message > > news:3C85C76F.3B5FA1A5@atoll-net.de... > > > And since Xilinx and most other EDA vendors support Linux now, why > > > step down to the bluescreen? > > > > Just to be clear here, the Xilinx Linux solution is currently limited to > > command-line only on WINE. For those unfamiliar with this approach, check > [...snip...] > > Does anybody know why Xilinx did this rather than porting their > Solaris/HP-UX version to Linux? > > Petter We've found that Xilinx tools running on HP Unix aren't as fast as those running on a (comparable ?) PC. I think this is because the tools are written on PCs and ported to Unix/workstation architecture. Porting this port back to Linux/PC architecture again might have the effect of slowing them even more. Nial (speculating wildly).Article: 40443
Hi Sorry to bother you. i found the problem. Thanks for all the advice. Paul paul.lee@sli-institute.ac.uk (Paul) wrote in message news:<9aeb7852.0203060848.10327822@posting.google.com>... > Hi > > Basically the circuit input and output consist of a decoder and > encoder. All the signals are clocked before entering the system. I > have done some test today and everything seem to be working fine when > I connect the output to the input of the system but when using a GPS > system to produced the input datastream, the system decodes it > incorrectly. I have measured the signals/datastream produced by the > GPS and it seem to be correct but once it enters the system and that > is when it all goes wrong. The clock used to produced the trailing > edge comes from the GPS system but it isn't the system clock. The GPS > clock signal is used for the decoding process. > What could be wrong with system? > > Thanks > > Paul > > > > kayrock66@yahoo.com (Jay) wrote in message news:<d049f91b.0203051241.14abc58d@posting.google.com>... > > Maybe you can describe the circuit you're using, but if you're doing > > something asynchronous that depends on the relative delays of gates > > then all bets are off. When you say this signal is a clock, is it THE > > clock for the design, or can you sample it with another higher > > freuency clock? > > > > paul.lee@sli-institute.ac.uk (Paul) wrote in message news:<9aeb7852.0203050323.12f72b04@posting.google.com>... > > > Hi everyone, > > > > > > I'm producing a trailing edge pulse from a clock and passing it > > > straight out as an output port for testing purposes but some of the > > > pulses are missing when implementing onto a FPGA. It works fine when > > > simulating with Modelsim. > > > The clock going into the FPGA is correct. > > > > > > Could it be a metastability issues? > > > > > > > > > Any help will be great. > > > > > > Thanks > > > > > > Paul LeeArticle: 40444
Yes, I installed and configured WINE. And WINE works fine for many Windows programs. Then I typed $ wine setup in the Installation directory. Then I entered my CDKEY. Then I select the components I want to use. Everything seemed perfect before the real installation begun. It just stuck at 0%. Finally, I lose my patience and ^C-ed the WINE. The message on console indicated that the whole thing froze when "Create ProcessA" for the JRE1.2.2 which ISE 4.1 is bundled with. I checked the Internet, but find nothing about how to install Xilinx ISE 4.1 on my Debian GNU/Linux box. I am runing unstable dist. Any suggestion? Thank you.Article: 40445
"ssy" <shengyu_shen@hotmail.com> wrote in message news:f4a5f64f.0203070350.2067c750@posting.google.com... > > these days. I met with serious problem about simulation/synthesis > mismatch , so I search everywhere to find the cause, to make the > problem even worse, the post syn simulation just can not run > correctly. > > A first step might be to run the clock very slowly and see if the synthesised chip behaves correctly. Good luck Phil -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 40446
It's not the FPGA you don't follow, it is the direct digital synthesis that is eluding you. You can clock modern FPGAs at 300 MHz with careful design, but in your case there is really no need to do so. Clocking at a more comfortable 10-50 MHz will make the design much easier, will permit a smaller part, will reduce your power, and will eliminate any chance of needing a heatsink on the FPGA. To the point, the reason a DDS gives you finer resolution than might be apparent is that it accumulates fractional cycles. This is manifested at the output by essentially sampling the accumulated phase at the clock interval. what that means is you can get very fine frequency resolution but with some jitter due to the time sampling. Picture the DDS as a phase accumulator. The accumulator bits represent a fraction of a revolution. So if you have a 4 bit accumulator, 0000 represents phase angle of 0, 0101= 5/16 of a revolution, 1111=15/16 of a revolution. Now if we have a fixed increment of 0101 or 5/16 then after 16 clocks we have gone around the phase circle exactly 5 times in the sequence: 0,5,10,15,4,9,14,3,8,13,2,7,12,1,6,11,0. by setting the increment value we can go 1/16 to 8/16 times the input frequency, in steps with 1/16 the input frequency resolution. For a simple square wave, you can take the msb of the accumulator out. In the example above with an increment of 5 we then get the sequence: 0,0,1,1,0,1,1,0,1,1,0,0,1,0,0,1 Note that it gets better frequency resolution than would otherwise be apparent by modulating the sequence of bits. If you look closely, what it is doing is putting the transitions at the clock interval closest to where it would be in an infinitely sampled situation. Now if we wanted to increase the resolution, we can add a bit to the accumulator. Sa instead of 5/16 * fclk we really needed 21/64* fclk. If we have 32 bits then we might use 11/32, getting the sequence: 0,11,22,1,12,23,2,13,24,3,14,25,4,15,26,5,16,27,6,17,28,7,18,29,8,19,30,9,20,31,10,21,0 which gives. 0, 0, 1 ,0, 0, 1 ,0, 0, 1, 0, 0, 1, 0, 0, 1,0 , 1, 1 ,0, 1 , 1 ,0, 1, 1,0, 1, 1, 0, 1, 1, 0, 1, As you can see you now get 11 rising edges in 32 clocks instead of 5 in 16 (10 in 32). By adding a bit, we essentially increase the resolution by extending the time for the sequence to repeat. In all these sequences, the edges are as evenly spaced as possible with the clock used, Hence the jitter of 1 cycle of your master clock we were speaking of. Unless your jitter requirement is less than 3ns, you have no reason to be working at 300 MHz. In fact, if you use more than one of the MSBs, you can use the fractional pahse angle with a DAC to get sub clock slicing. "F. Modderkolk" wrote: > Maybe I don't quit understand the working of the fpga, so explain me > whem I'm wrong. > I want to give you give you an example why my resolution needs to be > so high. > When I'm switching the fets with 300 kHz and I can switch my output > with 300MHz, the following is possible. Let's say the duty cycle of > my pulse is 40% ( it's always less than 50%). When I switch with 300 > kHz, one period is 3,33333 us. the next frequncy I can create at my > output = 1/300k + 1/300M = 3,33666 us. That is a frequency of > 299,700kHz. That is a difference of 300Hz. Such a difference means at > the output of the power supply a change of current of 0.2A. This is > because the working frequency is very small. I hope I made clear why I > need the high frequency. > > Ray Andraka <ray@andraka.com> wrote in message news:<3C862BFA.6BD14523@andraka.com>... > > See my post to your previous post. Knowing now what you are doing, I am > > sure you can get away with a much slower clock. Jitter is not likely to > > be much of a problem in this application. If, for example, you use a 10 > > MHz clock and a 32 bit accumulator you get a frequency resolution of 0.002 > > Hz with jitter no greater than 100ns (1 cycle of the master clock). Your > > master clock determines the amount of jitter and the maximum output > > frequency (Fclk/2). Resolution is determined just by the number of bits. > >Article: 40447
Thank you Peter for reply, yes i have a 100MHz free running receiver clock (4x oversampling). Just few questions. In the case of NRZ transmission is correct to synchronize the incoming signal with my 100MHz clock (with a classic two stage flip-flops, no problem for me two clock cycles delay) and after to do sampling on synchronized signal or is better to do sampling directly on incoming signal ? In the case of Manchester transmission (50MHz transmission clock in this case) receiver clock should be 200MHz (4x oversampling). Maybe this frequency is too high for me. Can i do a manchester decoder with different technique, maybe PLL with 50MHz reference clock ? Thanks. Roberto Capobianco Consorzio RFX - CNR di Padova C.so Stati Uniti, 4 35127 - Camin (PD) email: capobianco@igi.pd.cnr.it web: www.igi.pd.cnr.it tel.: +39-049-8295048 fax: +39-049-8700718 "Peter Alfke" <peter.alfke@xilinx.com> wrote in message news:3C86944B.F4D25F0@xilinx.com... > NRZ is fine if you have exactly the same clock at the transmitting and the > receiving end. > If there is any question about clock accuracy, then Manchester is much better, > since it is kind of self-clocking. But it has far more transitions ( max two per > bit, vs max 1 for NRZ). That limits the max bandwidt, but may not be a problem > with fibre. > 8 or even 4 times oversampling with a free-running receiver clock is ok, > provided you have solid signals, and almost no clock frequency uncertainty. > > Peter Alfke, Xilinx Applications > ============================== > Roberto Capobianco wrote: > > > Hi all, > > i want to send on fiber a digital pattern of approximately 50 bits with Tbit > > = 40ns (25MHz transmission clock). > > First question : NRZ or Manchester code ? > > Second question: UART and Manchester decoders in FPGA often use 16x > > oversampling to sample at mid-bit of data cell. > > This is impossible for me. > > In the design at http://www.xilinx.com/xcell/xl17/xl17-30.pdf we have a 8x > > oversampling manchester decoder > > but with my flex (Altera ACEX 1K) is very difficult to have a single global > > clock at 200MHz for all. > > Exist different ways to realize a good sampling with a low frequency ? > > > > Thanks. > > > > -- > > Roberto Capobianco > > Consorzio RFX - CNR di Padova > > C.so Stati Uniti, 4 > > 35127 - Camin (PD) > > email: capobianco@igi.pd.cnr.it > > web: www.igi.pd.cnr.it > > tel.: +39-049-8295048 > > fax: +39-049-8700718 >Article: 40448
Ray,
How does one instantiate the BRAM directly? I am using VHDL if that has any
impact on the question. Can you give me a code snippet as an example?
Thanks,
Theron Hicks
Ray Andraka wrote:
> Personally, I prefer to instantiate the BRAM primitives directly rather than
> using the coregen. That way you lose the extra layer of abstraction, that in
> this case does little more than make it harder to simulate. If you do use the
> BRAM generator and select register inputs under the design options, then putting
> a small combinatorial mux in front of it should put the mux with the registers
> (at least the last layer of the mux if it is more than 2 inputs). If you are
> instantiating the BRAMs, then your muxes should be registered. One note of
> caution: if you are trying to get the most speed, keep in mind that you want the
> registers as close as possible to the BRAM. Putting muxes with those registers
> is going to tend to congest the routing there, which may slow your critical BRAM
> connections. For that matter, it also helps to keep the width of the BRAM
> relatively small so you don't have a ton of data lines going in and out
> (especially for dual ports with both ports used in both directions).
>
> "H.L" wrote:
>
> > Hello Ray,
> > thanks a lot your post clarified things.
> > Xilinx Core Generator cant put additional register on the EN signal, so the
> > only thing is to instantiate a D flip-flop and put it in the right place?
> >
> > Regarding my project I have to arbitrate the access in 3 BRAMs (registered
> > for the reason described above) so I think I must use a MUX_BUS from the
> > CORE GENERATOR (one MUX_BUS for each BRAM). I will use 3 MUX_BUS with 3
> > input 41-bit buses (32 for the data, 7 for the address, 2 bits for EN,WE).
> > If I use non-registered MUXs I think is not good for the following reasons:
> > 1) The timing analysis will not include them in the period calculation so I
> > will not be able to see if my FPGA meets the timing constraints
> > 2) Combinatorial logic in the BRAM paths. Here is my second question, as I
> > said before I am going to use registered BRAMs do you think that these
> > registers are capable to cope with the inserted MUXs' combinatorial logic? I
> > don't know if these MUXs I'll use can be described as "large" or "small"
> > combinatorial logic.
> >
> > So the right thing to do is to use registered MUXs (LUT based only as Xilinx
> > says)?
> >
> > Best Regards,
> > Harris
> >
> > "Ray Andraka" <ray@andraka.com> wrote in message
> > news:3C824FD0.71540235@andraka.com...
> > >
> > >
> > > "H.L" wrote:
> > >
> > > > Hi Ray,
> > > > I have seen these tips written by you many times in this group. I have
> > them
> > > > always as a guide but I want to see if I understand them right. Please
> > > > correct me where I am wrong:
> > > >
> > > > 1) The need for additional registers in DATA_IN and ADDR signals.
> > > > In BRAMs the EN and WE signals have long set-up times thats why we need
> > to
> > > > register the data_in and addr of the BRAM, in this way the addr and
> > data_in
> > > > signals have a clock period delay.As EN,WE reach the BRAM 1 clock period
> > > > earlier (at 155MHz clock speed that means about 6 ns) the setup-time
> > for
> > > > these signals is not violated resulting BRAM to be in the operation mode
> > we
> > > > wish (read or write) the moment addr and data_in arrive.
> > >
> > > If you look at the data sheet, there are fairly long set-up times on all
> > the
> > > BRAM inputs. Routing to the BRAMs also adds to the delay, as does any
> > > combinatorial logic on these inputs. The idea of putting registers on the
> > > inputs (which includes the EN and WE inputs) is to minimize the amount of
> > delay
> > > added externally to these signals. Your understanding is a bit incorrect,
> > as
> > > what you are suggesting is delaying signals to allow a long combinatorial
> > > delay. That is dangerous, because there is no guarantee on the minimum
> > delay.
> > > Instead, what I am suggesting is to remove as much of the delay as
> > possible
> > > between the registers driving the BRAM inputs and the BRAM inputs, which
> > meahs
> > > avoiding combinatorial logic on these paths, minimizing the fanout of
> > these
> > > signals, and physically locating the registers close to the BRAMs.
> > >
> > > >
> > > > 2) The need for floorplanning
> > > > Xilinx software tool maybe has put the additional registers far from the
> > > > BRAMs, if this is the case we must manual place them near the BRAM to
> > > > decrease the propagation delay of the signals.
> > >
> > > That is correct. Routing in FPGAs is not just wire, it also consists of
> > > switches which add to the propagation delay of signals on the connections
> > > between logic. Manually placing the registers near the BRAM helps to
> > minimize
> > > the added delay.
> > >
> > > >
> > > > 3) Tying the WE,EN inputs and contol access through the address when
> > working
> > > > at high speeds.
> > > > Do you mean to keep WE,EN high all the time and when we wish not to use
> > the
> > > > BRAMs to write dummy data in some (or just one) specified addresses (or
> > > > address) reserved for this reason?
> > >
> > > That is correct. The set up times for EN and WE are nearly twice the
> > set-up
> > > times for address and data, so if we can eliminate these from the equation
> > we
> > > can run at a higher clock rate. They can be eliminated by always writing,
> > but
> > > directing the writes of invalid data to locations where it does not affect
> > the
> > > operation of the design. In the case of FIFOs, you can just park the
> > write
> > > address until you have a valid write, since you are presumably not reading
> > that
> > > data until it is valid.
> > >
> > > >
> > > >
> > > > Also I have another one question about BRAMs, Xilinx says that BRAMs'
> > DATA
> > > > OUT are already registered. In Xilinx Floorplanner I believe this
> > register
> > > > is "inside" the BLKRAM box so no manual floorplanning for the output is
> > > > needed. You need to manual floorplan (in the same way you do for the
> > inputs)
> > > > only if you choose to add an additional output register, correct?
> > >
> > > That is correct, the BRAM acts as though it is registered, although I
> > believe
> > > the actual implementation has the register on the address, not on the
> > memroy
> > > outputs. In any event, the clock to out time is long compared to that of
> > the
> > > CLB flip-flops. The system clock rate can be increased by putting an
> > additional
> > > register on the BRAM data outputs and placing that register physically
> > close to
> > > the BRAM (that register should have no combinatorial logic in front of
> > it).
> > >
> > > >
> > > >
> > > > I really appreciate your help.
> > > >
> > > > Best Regards,
> > > > Harris
> > > >
> > > > "Ray Andraka" <ray@andraka.com> wrote in message
> > > > news:3C7FD73D.F6A3109A@andraka.com...
> > > > > VirtexE BRAMs can be written at 155MHz in any speed grade. To do so,
> > you
> > > > will
> > > > > likely have to put registers near to and with no logic between them
> > and
> > > > the
> > > > > BRAMs. Watch the loading too, routing to more than 1 BRAM for each
> > > > register may
> > > > > cause you some heartburn. At higher speeds, you probably should also
> > > > consider
> > > > > tying the WE, and ENA inputs active and controlling your access
> > through
> > > > the
> > > > > address registers instead. You'll also need to floorplan the
> > registers to
> > > > make
> > > > > sure they are located physically close to the BRAMs.
> > > > >
> > > > > "H.L" wrote:
> > > > >
> > > > > > Hi Peter, thanks for your reply
> > > > > > I was confident of this method's effectiveness but now I am worried
> > :))
> > > > . I
> > > > > > have already done a timing analysis in the paper and also the
> > simulation
> > > > > > waveforms seem promising.
> > > > > > I didnt understand what do you mean when telling me that one of my
> > words
> > > > > > arrives early and the other one late. The transmitter sends to my
> > FPGA
> > > > an
> > > > > > external clock (thats the 155MHz clock), a valid signal (1 bit
> > > > indicating
> > > > > > the transmission time period) and of course the 16-bit words that I
> > have
> > > > to
> > > > > > store. Every clock period (~6 ns) I have available in my ports one
> > > > 16-bit
> > > > > > word, I register two sequential words from the in port to a 32-bit
> > > > register
> > > > > > (31->16 the first incoming word, 15->0 the second one). Then , in
> > > > another
> > > > > > 32-bit register I register (2 nd time) the 32-bit word I just "made"
> > > > which
> > > > > > are the BRAM data_in. All the above operations are in a process that
> > has
> > > > in
> > > > > > its sensitivity list the 155 clock. I write to the BRAM at 77MHz
> > using
> > > > the
> > > > > > incoming clock divide by 2 using a DLL. BRAM input signals are
> > assigned
> > > > in
> > > > > > the falling edge of the 77MHz clock so as to be before the rising
> > edge
> > > > (of
> > > > > > the same clock) where the BRAM samples them. The write operations
> > are in
> > > > > > another process with the slow clock in its sensitivity list.
> > > > > > The timing waveforms of the simulation are the same with the timing
> > > > analysis
> > > > > > in paper but does this is a valid hardware design technique?
> > > > > > Thanks for your time and help!
> > > > > >
> > > > > > Best Regards,
> > > > > > Harris
> > > > > >
> > > > > > p.s: thats a small part of my design. I use DLL because other parts
> > need
> > > > > > them (BUS_MUX e.t.c) , I tried to implement my whole design @ 155
> > MHz
> > > > and I
> > > > > > got many timing errors (floorplanning managed to reduce them but
> > still
> > > > lot
> > > > > > of work to be done)
> > > > > >
> > > > > > "Peter Alfke" <peter.alfke@xilinx.com> wrote in message
> > > > > > news:3C7E621F.1E77A244@xilinx.com...
> > > > > > > I suggest you grab pencil and paper and do a clock-by-clock timing
> > > > > > analysis. You
> > > > > > > will find that your clock-speed reduction buys you nothing, unless
> > you
> > > > > > also
> > > > > > > double-buffer the data.
> > > > > > > One of your words arrives nice and early, the other one late.
> > However
> > > > you
> > > > > > clock
> > > > > > > the BRAM, one of the two words has the same old short set-up
> > time...
> > > > > > > Double-buffering would help. But Ray has mentioned some neat
> > tricks to
> > > > > > avoid the
> > > > > > > long set-up time of the control inputs.
> > > > > > >
> > > > > > > I will get back with more constructive notes. "Gotta run"
> > > > > > >
> > > > > > > Peter Alfke
> > > > > > > ===================
> > > > > > > "H.L" wrote:
> > > > > > >
> > > > > > > > Hello all,
> > > > > > > >
> > > > > > > > I have a module that accepts 16 bit words at 155MHz and I want
> > to
> > > > store
> > > > > > then
> > > > > > > > in an 128x32 BRAM. I am going to use a DLL (in a Virtex-E FPGA)
> > to
> > > > > > divide by
> > > > > > > > 2 the 155MHz clock as this frequency seems to be pretty high to
> > > > write in
> > > > > > the
> > > > > > > > BRAM. So far I think 2 processes are enough to do my job, one
> > > > operating
> > > > > > @
> > > > > > > > 155MHz to accept the 16-bit data and store them in a 32-bit
> > register
> > > > and
> > > > > > the
> > > > > > > > another one @ 75MHz to write the content of the 32-bit register
> > in
> > > > the
> > > > > > BRAM.
> > > > > > > > I am thinking to assign the BRAM's signals
> > > > > > (ENABLE,WRITE,ADDRESS,DATA_IN) in
> > > > > > > > the falling edge of the 75MHz clock, the main reason for this is
> > the
> > > > > > setup
> > > > > > > > time of the BRAMs signals (in this way the address,data are 6 ns
> > > > before
> > > > > > next
> > > > > > > > rising edge of the clock where BRAM samples its inputs). My
> > question
> > > > now
> > > > > > :)
> > > > > > > > , if one process uses the falling edge of one clock does this
> > causes
> > > > > > > > problems to other processes in the design , e.g to processes
> > that
> > > > use a
> > > > > > > > different clock or to processes using the rising edge of the
> > same
> > > > > > clock?
> > > > > > > >
> > > > > > > > Best Regards,
> > > > > > > > Harris.
> > > > > > >
> > > > >
> > > > > --
> > > > > --Ray Andraka, P.E.
> > > > > President, the Andraka Consulting Group, Inc.
> > > > > 401/884-7930 Fax 401/884-7950
> > > > > email ray@andraka.com
> > > > > http://www.andraka.com
> > > > >
> > > > > "They that give up essential liberty to obtain a little
> > > > > temporary safety deserve neither liberty nor safety."
> > > > > -Benjamin Franklin, 1759
> > > > >
> > > > >
> > >
> > > --
> > > --Ray Andraka, P.E.
> > > President, the Andraka Consulting Group, Inc.
> > > 401/884-7930 Fax 401/884-7950
> > > email ray@andraka.com
> > > http://www.andraka.com
> > >
> > > "They that give up essential liberty to obtain a little
> > > temporary safety deserve neither liberty nor safety."
> > > -Benjamin Franklin, 1759
> > >
> > >
Article: 40449On 7 Mar 2002 03:50:04 -0800, shengyu_shen@hotmail.com (ssy) wrote: >Hi > >my question may seem a bit stupid, but if you know about my condition, >you can understand it. > > these days. I met with serious problem about simulation/synthesis >mismatch , so I search everywhere to find the cause, to make the >problem even worse, the post syn simulation just can not run >correctly. it's usually a bit of detective work unless the problem is obvious. It could be a problem with your RTL where the synthesized hardware is not what you think it will be. Or it could be a synthesizer bug which is less likely. The solution is to try to isolate the bug. First do a simulation without any timing annotated. If that works but not the annotated netlist, you know you have a timing problem. If you have a multi-module design, you should individually synthesize the modules and do a mixed RTL, gate level simulation and see which module breaks. Of course by looking at how the gate level breaks, you should have some idea which module could be the problem. If all the modules singly synthesized, work correctly it is more likely a cross-boundry optimization problem with synthesis. If you find one of the modules breaking when synthesized, read the RTL carefully to see if you're following all the rules of the specific tool for synthesizable subset of the HDL you're using. These are some of the ways you can try to pinpoint the problem. Good luck. Muzaffer Kal http://www.dspia.com ASIC/FPGA design/verification consulting specializing in DSP algorithm implementations
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