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
fpga_toys@yahoo.com wrote: > > This is not the first time, or the last, that I will call Peter (and > Austin, which is why he joined in they way he did) to task for being > insulting, to even valid questions and others responses. Check a ways > back, and you will find me objecting to Peter 's rude slaming a poster > for using some chat/texting short hand. You will also find them rudely > slamming me for bringing up power instability in early BG560 product. > Check even further back an you will find many warnings to play nice in > relatively polite responses to their abuse. > Speaking as an FPGA little-better-than-neophyte, I find the people from Xilinx and Altera who frequent this group an incredibly valuable resource to the community, who are more than willing to answer sane questions even when they come from mostly-hobby neophytes like myself who are very unlikely to ever run a mass-produced FPGA project[*]. Rants like yours can only serve to make that resource unavailable to the community, which would be an absolutely enormous loss. So: Peter, Austin, Subroto, Vaughn, and everyone else, thanks for your presence. -hpa [*] That almost changed -- at a previous employer I suddenly found myself de facto in charge of a highly sophisticated project based on EP2S180 with scheduled migration to HardCopy II for production. A bit unexpected for a systems software guy, but it was a fun experience doing something different. Unfortunately the company ran out of funding and the IP was bought out by a large computer manufacturer.Article: 119251
Sean Durkin wrote: > Amit wrote: > >>Hello, >> >>I have a DDR2 Controller ASIC rtl, which i need to put on FPGA and >>validate it. The problem is, i am not able to get this controller run >>on more than 50-60 Mhz on Virtex4 FPGA. Now, as everyone says minimum >>clock frequency for DDR2 devices is 100Mhz, i am simply not able to >>get DDR2 interface working on FPGA. >> >>I want to know if the DDR2 Devices can work on the clock frequencies >>which are much lower than 100Mhz. Has anyone tried it and got any >>success? > > 125MHz is the lowest specified clock rate for DDR2 SDRAM, not 100MHz. Hmmm.. If the fMin of these devices is getting faster, quicker than FPGAs are increasing in speed, then FPGA's might be outflanked in the memory interface stakes ? Could mandate custom silicon blocks ? Or, SDRAM suppliers might consider a special test flow, or silicon variant, just for FPGAs, but that does not sound cheap ?. Back to the specific issue: The RAM is tested only over the range the data sheet states, and it has a PLL for alignment. That makes the limits fairly important. So one FPGA workaround, would be to try a double-frequency BUS - ie you design for 2 clocks at the pins, for every one inside the controller. Yes, it will be wasteful in current consumption, but it might get you into the validated space, which is what matters. -jgArticle: 119252
On May 15, 1:08 pm, "H. Peter Anvin" <h...@zytor.com> wrote: > Rants like yours can only serve to make that resource unavailable to the > community, which would be an absolutely enormous loss. > > So: Peter, Austin, Subroto, Vaughn, and everyone else, thanks for your > presence. And Austin and Peter have been exceptionally rude at times, lacking the basic restraint for their frustration and anger that make online experiences less than pleasing for their targets. It's responses like yours that continue to allow them complete freedom to bully and abuse those they choose too. That is simply wrong. JohnArticle: 119253
MM wrote: > I was wondering if there is such a thing available? I found a few free and > commercial tools to edit/create bubble diagrams, which would then generate > VHDL code, but I would like to be able to generate a FSM diagram from the > code... The quartus state machine viewer can do it. http://home.comcast.net/~mike_treseler/pseudo.vhd http://home.comcast.net/~mike_treseler/pseudo_states.pdf -- Mike TreselerArticle: 119254
"Mike Treseler" <mike_treseler@comcast.net> wrote in message news:5aukqdF2qoaprU1@mid.individual.net... > > The quartus state machine viewer can do it. > > http://home.comcast.net/~mike_treseler/pseudo.vhd > http://home.comcast.net/~mike_treseler/pseudo_states.pdf > Thanks Mike. Do you know if the viewer is included in the web(free) edition? It is not clear from the editions' comparison at the Altera web site: http://www.altera.com/products/software/products/quartus2web/features/sof-quarweb_features.html#notes /MikhailArticle: 119255
MM wrote:
> "Mike Treseler" <mike_treseler@comcast.net> wrote in message
> news:5aukqdF2qoaprU1@mid.individual.net...
>> The quartus state machine viewer can do it.
>>
>> http://home.comcast.net/~mike_treseler/pseudo.vhd
>> http://home.comcast.net/~mike_treseler/pseudo_states.pdf
>>
>
> Thanks Mike. Do you know if the viewer is included in the web(free) edition?
It's included, but won't run without a license.
What doesn't show in the .pdf is that the
diagram is interactive with the HDL viewer and hierarchy list.
I can click on any yellow schematic block
to see the state diagram,
click any arrow and see the equation,
click on the hierarchy list and locate the code, etc.
-- Mike Treseler
Article: 119256
Hello,
I am graduate student in the Dept. of Computer Sc. & Engg. in
USF.
We are using a Digilent XUP2vpPro board for one of our research
projects. I am trying to interface a Kingston 512 MB DDR RAM in DIMM
to Xilinx virtex 2 Pro FPGA. The DDR RAM is the same that is
recommended at the board's webpage. I am using the MIG 007 tool to
generate the memory controller and modify it according to our needs.
I was looking for some specifications of the DDR RAM like number
of
banks, # of row and column address counts. I was curious if there are
any specification docs that lists these details from Kingston?
Also since the DDR Memory is from a third party, xilinx does not
provide any simulation libraries (like it does for BRAM's for eg).
Hence the only way to do a system level simulation is either testing
"on-board" or using ChipScope Pro. I was curious if RTL level models
or simulation libraries are provided for these DDR RAMs so that I
could do a system simulation from inside ISE itself?
If any reference designs are avialable for the memory
controllers for DDR
RAMs for interfacing to Xilinx V2P, that would be greatly helpful as
well.
Any sort
Thanks,
Koustav
Article: 119257
Hello,
I am graduate student in the Dept. of Computer Sc. & Engg. in
USF.
We are using a Digilent XUP2vpPro board for one of our research
projects. I am trying to interface a Kingston 512 MB DDR RAM in DIMM
to Xilinx virtex 2 Pro FPGA. The DDR RAM is the same that is
recommended at the board's webpage. I am using the MIG 007 tool to
generate the memory controller and modify it according to our needs.
I was looking for some specifications of the DDR RAM like number
of
banks, # of row and column address counts. I was curious if there are
any specification docs that lists these details from Kingston?
Also since the DDR Memory is from a third party, xilinx does not
provide any simulation libraries (like it does for BRAM's for eg).
Hence the only way to do a system level simulation is either testing
"on-board" or using ChipScope Pro. I was curious if RTL level models
or simulation libraries are provided for these DDR RAMs so that I
could do a system simulation from inside ISE itself?
If any reference designs are avialable for the memory
controllers for DDR
RAMs for interfacing to Xilinx V2P, that would be greatly helpful as
well.
Any sort of tips/suggestion will be very helpful.
Thanks,
Koustav
Article: 119258Sean Durkin wrote: > Jonathan Bromley wrote: >> Is there a memory expert in the house? :-) > Not exactly an expert, but I'm trying to figure out the same thing at > the moment. > > This is what Micron is saying on the subject on their website > (http://www.micron.com/support/designsupport/faq/ddr2): > > "Q: Will the device run at a slow clock (well under the slowest data > sheet speed)? ... > > So if you're designing a product that might be around for awhile, I > strongly suggest to stick *very* closely to all the DRAM specs. Or test > with *one* type of chip and buy a whole bunch of those to support the > product's entire lifetime. > Recently I was tasked with getting a DRAM controller working on a slow part, and my plan was to disable the DLL and run the DRAM at a low frequency (like 50MHz). It seemed to me that the minimum clock speed was just a spec for the DLL. Since most FPGA-based DRAM controllers used some sort of dynamic alignment to synchronize the read data with the internal clock, the use of the DRAM's DLL shouldn't be necessary. Unfortunately I never got to finish this and have no results, but I would think that you could turn off the DLL and operate at low rates as long as you are dynamically adjusting for the read path delay. But the manufacturers won't even print any specs in the datasheet for usage with the DLL switched off. -KevinArticle: 119259
koustav79@gmail.com wrote: > Hello, > > I am graduate student in the Dept. of Computer Sc. & Engg. in > USF. > We are using a Digilent XUP2vpPro board for one of our research > projects. I am trying to interface a Kingston 512 MB DDR RAM in DIMM > to Xilinx virtex 2 Pro FPGA. The DDR RAM is the same that is > recommended at the board's webpage. I am using the MIG 007 tool to > generate the memory controller and modify it according to our needs. > > I was looking for some specifications of the DDR RAM like number > of > banks, # of row and column address counts. I was curious if there are > any specification docs that lists these details from Kingston? > > Also since the DDR Memory is from a third party, xilinx does not > provide any simulation libraries (like it does for BRAM's for eg). > Hence the only way to do a system level simulation is either testing > "on-board" or using ChipScope Pro. I was curious if RTL level models > or simulation libraries are provided for these DDR RAMs so that I > could do a system simulation from inside ISE itself? > > If any reference designs are avialable for the memory > controllers for DDR > RAMs for interfacing to Xilinx V2P, that would be greatly helpful as > well. > > Any sort > > Thanks, > Koustav > You can see what parts are on the DIMM (e.g., Micron, Infineon) and then figure out what the row size is from that. You can also get good HDL simulation models from Micron. They are somewhat slow, but accurate. You instantiate one DRAM model for each DRAM chip on the DIMM. -KevinArticle: 119260
I know that an FPGA's power consumption is basically linear with clock frequency, but does anybody know what happens when the maximum clock frequency for the design is approached? Does power consumption remain linear in this region where failures and setup violations begin to occur, or would it then be expected to go up or down? Or is it totally design-dependent? -KevinArticle: 119261
Hi! I need to design a simple serializer/deserializer as part of my bigger experimental project. I've started with reading various application notes from Lattice, Xilinx and Altera, as I don't feel very comfortable with multiple clock domain designs, nor with very high speed clocks in general. I've found one slightly confusing sketch in Lattice app. note, available here http://www.latticesemi.com/lit/docs/technotes/tn1020.pdf Figure 5 shows a basic serializer. My understanding: - 'LS Clock' is derived by dividing HSTCLK by n, so both clocks are in phase - 'Align' block is clocked with HSTCLK and it asserts 'Parallel Load' output for one HSTCLK period, when it detects rising edge of 'LS Clock' - looking at serializer timing diagrams (p. 27) I can see that output (and thus parallel load) is delayed by 2 HSTCLK cycles, which confirms my understanding so far Q: Given all that - why do we need 'Parallel Sync Register' ? Parallel load to Shift Register is delayed by 2 HSTCLK cycles from 'LS Clock' rising edge, so 'Parallel Load Register' outputs have enough time to settle. Where is my misunderstanding? Best Regards, PrzemekArticle: 119262
Kevin, It remains linear with increased frequency until the frequency gets so high that the transitions no longer go 'rail to rail'. Generally, the point at which the signal does not go rail to rail is far beyond where the timing has failed, and there are things not meeting the required constraints. At that point, power begins to decrease, as the V squared the signal charges and discharges to is decreased (so it goes down quickly -- almost like you hit a wall). It is also design dependent,as each resource will have its own frequency where the rail to rail is no longer happening. Austin Kevin Neilson wrote: > I know that an FPGA's power consumption is basically linear with clock > frequency, but does anybody know what happens when the maximum clock > frequency for the design is approached? Does power consumption remain > linear in this region where failures and setup violations begin to > occur, or would it then be expected to go up or down? Or is it totally > design-dependent? > -KevinArticle: 119263
Kevin Neilson wrote: > I know that an FPGA's power consumption is basically linear with clock > frequency, but does anybody know what happens when the maximum clock > frequency for the design is approached? Does power consumption remain > linear in this region where failures and setup violations begin to > occur, or would it then be expected to go up or down? Or is it totally > design-dependent? It would depend. If (eg) counters start skipping clocks, then power consumption would be expected to decrease, but only for the cells that were hitting their thresholds. ( so a small % of total Icc ) However, if something like a state engine starts short-cycling, then power consumption could increase, again slighty. Why the question - are you thinking of using changes in Icc to flag timing failures ? -jgArticle: 119264
Hi i'm developping an architecture using Libero and Actel FPGA, i had a problem with global ressources, i had 8 global ressources and the FPGA contains only 6, is there any way to oblige the compiler to not consider some signals as global ressources, synthesysing tool used: Synplify, regards, A.Article: 119265
Thank you, Paul >Hello Leon, > >The quality of a power estimate depends on many factors. Let's talk >only about dynamic power, since our worst-case static power is a >specification and thus pessimistic by nature. > >*Models* The power models in Quartus II for our recent FPGAs are >extremely detailed and are correlated against silicon with many >thousands of different targeted designs. Whatever Austin may think, >the models for Stratix II & Cyclone II predict dynamic power within a >range of +20..-10%. We try to err on the side of slightly over- >predicting power since underpredicting has worse consequences for our >customers. However, this assumes that we have *perfect vectors* for >the operation of your design. And designs that have very glitchy >paths (for example, long XOR chains) could be over-predicted by the >tools even more. > >*Design Information* You've used the PowerPlay Power Analyzer on your >full design, so it knows everything - synthesis, placement, routing, >and bit settings. However, for people who use the Early Power >Estimator spreadsheet, then it doesn't know everything -- it must make >guesses for LUT functions and length/fanout of routes, and you must >make guesses for block modes, etc. > >*Vectors/Toggle Rates* Assuming the tools & models are of high >quality, this is where the biggest source of error comes from. Did >you provide vectors from a gate-level simulation of your full design? >Did your vectors truly reflect the worst-case mode of operation you >will encounter in the real system? If you only had partial vectors, >Quartus will fill in the blanks (for example, for combinational logic >between registers in RTL simulations) -- and it's fairly good at this, >but this is another source of error. > >Even with good models and perfect vectors, the power tools are >designed primarily for estimating power dissipation for thermal design >and/or battery life. When it comes to adequately sizing your supply, >you begin to run into a new problem -- current transients. Vectors >turn into average power over the period of simulation -- but you will >have periods of time where the switching exceeds this average. But >then again, you have on-chip and off-chip decoupling capacitors that >filter/smooth out these spikes. There is no quick-and-easy answer >here... > >So at the end of the day, I can't help you with what a reasonable >guard-band is to apply to determine your power supply. 2X is a number >I know some customers use -- but that could be too low or horribly >over-engineered. Some customers over-engineer their prototype, but >downsize their supplies after characterizing the first batch without >needing to respin the board design. > >Sorry I can't give you a more concrete answer, > >Paul Leventis >Altera Corp. > >Article: 119266
On May 15, 5:05 pm, Kevin Neilson <kevin_neil...@removethiscomcast.net> wrote: > I know that an FPGA's power consumption is basically linear with clock > frequency, but does anybody know what happens when the maximum clock > frequency for the design is approached? Does power consumption remain > linear in this region where failures and setup violations begin to > occur, or would it then be expected to go up or down? Or is it totally > design-dependent? > -Kevin It might well be design and device dependent, especially if your design speed is near the max operating frequency of the device. With CMOS processes logic speed falling back significantly at the upper end of the temp operating scale, combined with clock jitter, significant setup violations might create some significant metastability problems that aren't likely to be linear in power. Actually the extra dynamic power from the metastability events might well be self reinforcing from die heating slowing the circuit response more and increasing the number of metastable events and their duration. certainly an interesting question :)Article: 119267
On May 15, 7:05 pm, Kevin Neilson <kevin_neil...@removethiscomcast.net> wrote: > I know that an FPGA's power consumption is basically linear with clock > frequency, but does anybody know what happens when the maximum clock > frequency for the design is approached? Does power consumption remain > linear in this region where failures and setup violations begin to > occur, or would it then be expected to go up or down? Or is it totally > design-dependent? > -Kevin Totally design dependent. Generally, we see non-linear behaviour when you start crossing into the domain of timing failures -- but the degree of the change and where it occurs vs. the theoretical Fmax of the design varies considerably. It will also depend on your input vectors. Regards, Paul Leventis Altera Corp.Article: 119268
Thank you all for giving your expert insights. I am a bit confident now that, atleast i can try out some of the options like Disabling DLLs, Developing a small wrapper on DDR2 interface (if at all logically possible) and others. Previously, I have put a DDR controller/Interface on FPGA with Micron device running at 40Mhz. 40Mhz is again out of spec but somehow it worked. Regards, AmitArticle: 119269
Hi, Please suggest me how to transfer a single clockwide pulse from high frequency clock domain and create a single clockwide pulse in a slow clock domain? What are different methods available? Thanks in advance. Regards, Himassk.Article: 119270
himassk wrote: > Hi, > > Please suggest me how to transfer a single clockwide pulse from high > frequency clock domain and create a single clockwide pulse in a slow > clock domain? > What are different methods available? > 1. Stretch the pulse in the fast clock domain so that it is guaranteed to be long enough to capture in the slow domain. 2a. If the two domains are *synchronous* (derived from a common clock source), just put a capture flop in the slow clock domain. You're done. 2b. If the two domains are asynchronous, put a synchronizer (a chain of flip-flops with as much slack time as possible) followed by a strobe generator in the slow clock domain. -hpaArticle: 119271
And perhaps the more important potential homework question: why would you want to do this? Hint: the real world is generally asynchronous, and one needs to synchronize to external events. JTW "himassk" <himassk@gmail.com> wrote in message news:1179293749.474907.116570@e65g2000hsc.googlegroups.com... > Hi, > > Please suggest me how to transfer a single clockwide pulse from high > frequency clock domain and create a single clockwide pulse in a slow > clock domain? > What are different methods available? > > Thanks in advance. > > Regards, > Himassk. >Article: 119272
Pardon my initial response; however, the question is one that you could
expect in a digital logic class, or perhaps in an interview.
With a simple google on "pulse clock domain crossing", I come up with this
article in EDN a few years back:
http://www.edn.com/index.asp?layout=article&articleid=CA276202
JTW
"jtw" <wrightjt @hotmail.invalid> wrote in message
news:J6x2i.144$4Y.81@newssvr19.news.prodigy.net...
> And perhaps the more important potential homework question: why would you
> want to do this? Hint: the real world is generally asynchronous, and one
> needs to synchronize to external events.
>
> JTW
>
>
> "himassk" <himassk@gmail.com> wrote in message
> news:1179293749.474907.116570@e65g2000hsc.googlegroups.com...
>> Hi,
>>
>> Please suggest me how to transfer a single clockwide pulse from high
>> frequency clock domain and create a single clockwide pulse in a slow
>> clock domain?
>> What are different methods available?
>>
>> Thanks in advance.
>>
>> Regards,
>> Himassk.
>>
>
>
Article: 119273On Tue, 15 May 2007 16:19:01 +0100, Andrew Greensted <ajg112@ohm.york.ac.uk> wrote: >Antti wrote: > >> it all depends how efficient the memory controller and bus arbitration >> really is. >> in some cases the memory performance can be rather low. >> >> Antti >> > >Antti, thanks for the input. I realise this is a bit difficult to answer >without some real specific peripheral info, but can you suggest a faster >method of interfacing a peripheral? > >I guess PLB is faster, but this will limit it to PPC use, or microblaze >via a bus bridge, but I guess that will be slower still. > >Is some kind of DMA approach the only way to improve transfer rates? > I would design the memory interface myself. OPB_IPIF imposes a great delay, while designing a direct OPB<->memory interface may speed up the thing. I tailored my own design to interface OPB to and synchronous flow-through SRAM, taking the access time downto 2 clock cycles Regards, ZaraArticle: 119274
On 2007-05-15, koustav79@gmail.com <koustav79@gmail.com> wrote: > If any reference designs are avialable for the memory > controllers for DDR > RAMs for interfacing to Xilinx V2P, that would be greatly helpful as > well. I think you generally have two decent options here. The cheapest is to get hold of the EDK. (Since you are associated with a university you should be able to get it very cheap. Or you might already have it.) That is by far the easiest method to get the DDR ram interface up and running on that board. Otherwise you could take a look at the Memory interface generator at xilinx.com (aka MIG). This doesn't look to be nearly as easy to get up and running but might be an idea if you don't have the EDK or if you really cannot use the OPB or PLB bus protocol. Finally, you could roll your own, I wouldn't recommend it though since it will probably take you a lot of time to get right. There are some open source DDR controllers available which you might be able to modify, like the one at opencores. However, at least the opencores one hasn't worked very well for me unfortunately. Anyway, unless your purpose is to do research on the memory controller, my advice is to use the EDK's memory controller. You will be able to get the board up and running with an example running in about an hour if you have a tutorial to follow. /Andreas
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