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
Antti wrote: > you cant get it all. > getting GOOD smd oscillators at 0.50$ at low qty While we're speaking about oscillators, I have a couple of remarks : - power consumption : I see that many osc draw from 6 to 32mA (depending on some factors). That's a lot ! I know it is specified for a 15pf load and a short trace to a FPGA pin won't draw as much, but it's still an order of magnitude above what I imagined. I can choose a lower frequency (like 3.5458MHz) to reduce the toggle rate but are there other methods ? Can a discrete oscillator consume less ? I doubt, but I could compare with circuits based on the SN74LVC2G14 or LMV7219. - output signal : my first proto used a 25MHz osc, directly connected to the PLL input pin of the A3P250. I checked that it worked with my 'scope and I saw a distorded signal with almost 1V of undershoot and overshoot. The trace is short (15mm ?) so no such effect should occur. I added a series SMT resistor (68 Ohms that I had around) and the trace looked better. I have not seen schematics that add a series resistor (I analysed Actel's and ACME's boards), and I have never heard about oscillator overshoot. The power rails are abundantly decoupled and the PLL works well with the serie resistor. Did I miss something ? > Antti yg -- http://ygdes.com / http://yasep.orgArticle: 144326
On Nov 26, 6:41=A0pm, whygee <y...@yg.yg> wrote: > Antti wrote: > > you cant get it all. > > getting GOOD smd oscillators at 0.50$ at low qty > > While we're speaking about oscillators, I have a couple > of remarks : > > =A0 - power consumption : I see that many osc draw from 6 to 32mA > (depending on some factors). That's a lot ! I know it is specified > for a 15pf load and a short trace to a FPGA pin won't draw as much, > but it's still an order of magnitude above what I imagined. > I can choose a lower frequency (like 3.5458MHz) to reduce the > toggle rate but are there other methods ? Can a discrete > oscillator consume less ? I doubt, but I could compare with > circuits based on the SN74LVC2G14 or LMV7219. > > =A0 - output signal : my first proto used a 25MHz osc, > directly connected to the PLL input pin of the A3P250. > I checked that it worked with my 'scope and I saw a distorded > signal with almost 1V of undershoot and overshoot. > The trace is short (15mm ?) so no such effect should occur. > I added a series SMT resistor (68 Ohms that I had around) > and the trace looked better. I have not seen schematics > that add a series resistor (I analysed Actel's and ACME's > boards), and I have never heard about oscillator overshoot. > The power rails are abundantly decoupled and the PLL works > well with the serie resistor. Did I miss something ? > > > Antti > > yg > --http://ygdes.com/http://yasep.org canned oscillator make extreme power supply noise, and their output can easy overshoot as well I had a design(protoboard) where 100mhz canned oscillator did give such noise that the Spartan 3E did constantly return Virtex-4 JTAG ID, problems was noise on VCCINT (from the osciallor, passing via LDO or GND) series resistor is not un-common, and local inductor-cap or res-cap on osc supply is always a good idea so small inverter with crystal may be a better option AnttiArticle: 144327
Hi,
Antti wrote:
> canned oscillator make extreme power supply noise, and their output
> can easy overshoot as well
This is never explained in the datasheets.
but when a small thing like that draws 32mA,
it rings an alarm bell...
> I had a design(protoboard) where 100mhz canned oscillator did give
> such noise that the Spartan 3E did constantly return Virtex-4 JTAG ID,
> problems was noise on VCCINT (from the osciallor, passing via LDO or GND)
OK, I have an inductor on the Vpll but not for the supply of the osc.
It would not solve the overshoot problem, because this probably comes
from the crystal itself, it looks unbuffered.
Then if this is the case, the output is probably unsufficiently
capacitively loaded ?
> series resistor is not un-common, and local inductor-cap or res-cap on
> osc supply is always a good idea
I'll add an inductor next time, a resistor seems unsufficient.
> so small inverter with crystal may be a better option
now, the questions are
- how to correctly tune the circuit ?
by a strange coincidence I just got an old frequency meter
but this device certainly requires a good recalibration :-/
- how to be sure that the circuit consumes less ?
well... we'll have to measure. But hints are welcome...
> Antti
yg
--
http://ygdes.com / http://yasep.org
Article: 144328On Nov 27, 5:41=A0am, whygee <y...@yg.yg> wrote: > Can a discrete oscillator consume less ? Yes, but you need care. Numbers from a 74LVC1GX04 on the test bench : http://pdf.dzsc.net.cn/CAR/CARD_74LVC1GX04.pdf Xtal: 25.8MHz Vcc_Start =3D 1.3V Vcc_stop =3D 0.9V Icc@1.8V =3D 1.93mA [6MHz ~ 500uA] Icc@2.5V =3D 4.04mA Icc@3.3V =3D 8.26mA -jgArticle: 144329
-jg wrote: > On Nov 27, 5:41 am, whygee <y...@yg.yg> wrote: >> Can a discrete oscillator consume less ? > Yes, but you need care. of course ... > Numbers from a 74LVC1GX04 on the test bench : > http://pdf.dzsc.net.cn/CAR/CARD_74LVC1GX04.pdf I know this circuit already. But it is as expensive as a cheap osc :-/ (at least from my resellers) > Xtal: 25.8MHz > Vcc_Start = 1.3V > Vcc_stop = 0.9V > Icc@1.8V = 1.93mA [6MHz ~ 500uA] > Icc@2.5V = 4.04mA > Icc@3.3V = 8.26mA Sweeeeet ! So if I use a 3.6468MHz crystal, it will draw even less. I could use the 1.5V core voltage as well but it will require some capacitive coupling and some resistors for level translation to 3.3V-land. What about frequency stability ? > -jg yg -- http://ygdes.com / http://yasep.orgArticle: 144330
On Nov 27, 7:45=A0am, whygee <y...@yg.yg> wrote: > > What about frequency stability ? You get what you pay for :) If you need 2.5ppm, then you have to get a TCXO. (eg the FOX924 series - 6mA Icc is good for a TCXO) Simple Crystals are usually 50ppm-100ppm, and you ADD the tempco curves on top of that. You can pay more, and get down to 10ppm initial, but that still leaves the tempco curves... The advantage of using a OscModule, is you can usually choose what Price/ppm balance your product needs, without a PCB change. (or, offer a premium product model, with a TXCO) Most important step: What ppm do you ACTUALLY NEED ? -jgArticle: 144331
rOn Thu, 26 Nov 2009 12:05:24 -0000, "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote: >YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA. > This maybe true to some extent >The tools aren't designed to handle/analyse them. but this is simple not true in general, especially for the analyse case. Here is what a timing report from Xilinx flow looks like: ========================================= Timing constraint: TS_clkdiv2 = PERIOD TIMEGRP "clkdiv2" TS_clk / 2 HIGH 50%; 9 paths analyzed, 9 endpoints analyzed, 8 failing endpoints 8 timing errors detected. (8 setup errors, 0 hold errors, 0 component switching limit errors) Minimum period is 3.108ns. -------------------------------------------------------------------------------- Slack (setup path): -0.608ns (requirement - (data path - clock path skew + uncertainty)) Source: datar1_6 (FF) Destination: dataout_6 (FF) Requirement: 2.500ns Data Path Delay: 0.971ns (Levels of Logic = 0) Clock Path Skew: -2.102ns (1.205 - 3.307) Source Clock: clk_BUFGP rising at 0.000ns Destination Clock: clkdiv2 rising at 2.500ns Clock Uncertainty: 0.035ns ... So TRCE is perfectly capable (I'm sure Quartus Timer is similarly so) of timing the source and target clock delays and reporting a path between the two clocks correctly. Whether you are interested/capable of fixing this issue is another problem but I don't think it's necessary to blame the tools, at least not anymore. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 144332
Jurgen Defurne wrote: > I have a hobby project which consists of developing a complete > computer system from the ground up. With complete I mean that it > should have character display capabilities, keyboard input > capabilities and mass storage capabilities. Graphics and networking > might come in the future, but I feel that adding these is probably > more a team effort than a single person effort, and I need time first > to implement what should be a reasonable system stack. > > This is what I mean with from the ground up : a system stack > consisting of an ISA, a simulator for the ISA and processor > architecture, basic display and keyboard capabilities for the > simulator, and system software which is based on Lisp. I have already > the simulator running, together with the IO capabilities and an > assembler. > Maybe you would like to take a look at http://www.aviduratas.de/lisp/lispmfpga/ > > Regards, > > Jurgen Greetings Jürgen -- Jürgen Böhm www.aviduratas.de "At a time when so many scholars in the world are calculating, is it not desirable that some, who can, dream ?" R. ThomArticle: 144333
I would like to use SerialLite II on Altera Cyclone IV GX22 (when available). I already studied the literature, and there's an open question concerning configuration of the SerialLite interface: I plan to use all 4 high-speed transceivers in unidirectional transmitter mode to send bursts of image data (I've an additional low- speed control path where I can return link status and errors), and want to include the link layer for package encapsulation, CRC, lane striping; I do not need priority packets, retry-on-error handling, flow control. So in my opinion there is no need for a high-speed receiver line. Nevertheless the Quartus MegaWizard Plug-In Manager does not allow this configuration. In transmitter only mode it restricts the number of lanes to 1, saying "the number of lanes is limited to 1 while Self-Synchronized Link-Up is enabled" - but I cannot disable it. In bidirectional mode the selectable number of receivers is >= 1. Obviously, the 4 transmitters only configuration is not supported? Why and how to solve? Who can help? Thanks, Roland.Article: 144334
> So TRCE is perfectly capable (I'm sure Quartus Timer is similarly so) > of timing the source and target clock delays and reporting a path > between the two clocks correctly. Whether you are interested/capable > of fixing this issue is another problem but I don't think it's > necessary to blame the tools, at least not anymore. Aye, that was badly worded, although I wouldn't fancy having to get a design working with a multitude of ripple clocks driving between clock domains! NialArticle: 144335
On Nov 25, 5:33=A0pm, Andy Botterill <a...@plymouth2.demon.co.uk> wrote: > webpack crashed whilst synthesising my design. This is the first time > that I have had this. I have managed to get the design to synthesise > properly and do a p&r netlist. I didn't change the design. > > The things that are missing are mainly cosmetic but I would like to > reinstate them. The snapshot list is blank. I can see a snapshot > directory and there are files inside it. How do I get webpack to > re-create the snapshot area? When I do a synthesis run I don't get an > errors/warnings report. Yes I can look at the synthesis log. It would be > good to get the list of errors and warnings on the design summary page. > > Any ideas/pointers. Thanks in advance Andy If you're running ISE version 10.1 you should have a restore script for the project <project_name>.restore Instructions for regenerating the project from the restore script are inside the script. Basically: In the GUI click the TCL Shell tab change the directory to your project directory type "source <project_name>.restore" type "restore" If you're lucky and the original restore file hasn't already been clobbered, you should get back all of your settings. Regards, GaborArticle: 144336
On Nov 26, 5:09=A0pm, Muzaffer Kal <k...@dspia.com> wrote: > >YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA. > > This maybe true to some extent > Yes...to the extent that you want to have a working, robust design in the end...to that extent. If that's not where you're trying to get to, then generate all of the clocks that you want. > >The tools aren't designed to handle/analyse them. > > but this is simple not true in general, especially for the analyse > case. Here is what a timing report from Xilinx flow looks like: > Nial wasn't quite correct about the analyze portion of his statement. The tools certainly can analyze them, what he was getting at is that you just shouldn't use them. The issue is that there will be a skew between a flop that receives the master clock and a flop that receives ANY generated clock (whether that clock is generated combinatorially, or is the output of a flop like in a ripple counter) and there will be nothing you can do from a design perspective to compensate for that skew short of hand placement and routing and cross your fingers, hope for the best. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Timing constraint: TS_clkdiv2 =3D PERIOD TIMEGRP "clkdiv2" TS_clk / 2 > HIGH 50%; > =A09 paths analyzed, 9 endpoints analyzed, 8 failing endpoints > =A08 timing errors detected. (8 setup errors, 0 hold errors, 0 component > switching limit errors) > =A0Minimum period is =A0 3.108ns. > -------------------------------------------------------------------------= --=AD----- > Slack (setup path): =A0 =A0 -0.608ns (requirement - (data path - clock > path skew + uncertainty)) > =A0 Source: =A0 =A0 =A0 =A0 =A0 =A0 =A0 datar1_6 (FF) > =A0 Destination: =A0 =A0 =A0 =A0 =A0dataout_6 (FF) > =A0 Requirement: =A0 =A0 =A0 =A0 =A02.500ns > =A0 Data Path Delay: =A0 =A0 =A00.971ns (Levels of Logic =3D 0) > =A0 Clock Path Skew: =A0 =A0 =A0-2.102ns (1.205 - 3.307) > =A0 Source Clock: =A0 =A0 =A0 =A0 clk_BUFGP rising at 0.000ns > =A0 Destination Clock: =A0 =A0clkdiv2 rising at 2.500ns > =A0 Clock Uncertainty: =A0 =A00.035ns > ... > > So TRCE is perfectly capable (I'm sure Quartus Timer is similarly so) > of timing the source and target clock delays and reporting a path > between the two clocks correctly. Whether you are interested/capable > of fixing this issue is another problem but I don't think it's > necessary to blame the tools, at least not anymore. It's not apparent to me at least that the fast path was analyzed...that's where the hold time problems will get fingered. The tool can probably do it (Quartus does, you have to specify it since it's not in the 'default' analysis). Anyway, take your ripple counter and put a heat gun or cold spray on it and watch it change from working to not working. Kevin JenningsArticle: 144337
On Fri, 27 Nov 2009 12:23:39 -0800 (PST), KJ <kkjennings@sbcglobal.net> wrote: >On Nov 26, 5:09 pm, Muzaffer Kal <k...@dspia.com> wrote: >> >YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA. >> >> This maybe true to some extent >> > >Yes...to the extent that you want to have a working, robust design in >the end...to that extent. If that's not where you're trying to get >to, then generate all of the clocks that you want. > No only to the extent of simple designs which don't require much from the designer, this is certainly good advice. There are times when a surgical knife is required and in good hands they're an indispensible and irreplaceble tool. >The tools certainly can analyze them, what he was getting at is that >you just shouldn't use them. I have no problem you or Nial not using them. >there will be >nothing you can do from a design perspective to compensate for that >skew short of hand placement and routing and cross your fingers, hope >for the best. > Again this maybe your experience base but it's certainly not true in general. >It's not apparent to me at least that the fast path was >analyzed...that's where the hold time problems will get fingered. The >tool can probably do it (Quartus does, you have to specify it since >it's not in the 'default' analysis). > Why do you expect the tool to understand your design? It's your responsibility to do so and specify the required timing constraints and checks. >Anyway, take your ripple counter and put a heat gun or cold spray on >it and watch it change from working to not working. I understand if that's your experience with some of your past designs but please don't attribute it to others. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 144338
On Fri, 27 Nov 2009 10:20:14 -0000, "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote: >> So TRCE is perfectly capable (I'm sure Quartus Timer is similarly so) >> of timing the source and target clock delays and reporting a path >> between the two clocks correctly. Whether you are interested/capable >> of fixing this issue is another problem but I don't think it's >> necessary to blame the tools, at least not anymore. > > >Aye, that was badly worded, although I wouldn't fancy having to get a >design working with a multitude of ripple clocks driving between >clock domains! I don't think anyone would force you to do something which you're uncomfortable doing. It's certainly easier to work with single synchronous clock but it's possible to do with multiple generated ones too. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 144339
On Nov 27, 4:37=A0pm, Muzaffer Kal <k...@dspia.com> wrote: > >On Nov 26, 5:09=A0pm, Muzaffer Kal <k...@dspia.com> wrote: > >> >YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA. > > >> This maybe true to some extent > > >Yes...to the extent that you want to have a working, robust design in > >the end...to that extent. =A0If that's not where you're trying to get > >to, then generate all of the clocks that you want. > > No only to the extent of simple designs which don't require much from > the designer, this is certainly good advice. Hand placement and routing is the only other way to get there. That was an effective and productive technique in the 80s and 90s when the place and route tools weren't that good, not today. You've also got it backwards since only the 'simple designs' or the 'cost is no concern' designs might be able to afford this kind of additional effort. Neither of those scenarios is typical. > There are times when a > surgical knife is required and in good hands they're an indispensible > and irreplaceble tool. > A ripple counter is not a 'surgical knife' nor an 'irreplaceble tool', it is just a ripple counter. Trying to make it sound like something only to be understood by the high priests is a load of you-know-what, stick to actual specifics of the topic. What a ripple counter brings along is 1. Generally less logic than a synchronous counter 2. Generally less power consumption than a synchronous counter 3. Generally can be clocked faster than a synchronous counter 4. Generally more propagation delay than a synchronous counter 5. Generally more timing uncertainty in when the outputs are valid than a synchronous counter to the point that there may be no time when it is even theoretically possible to sample the counter output accurately. While one can always contrive a problem where the benefits of #1, #2 and #3 outweigh the drawbacks of #4 and #5, when you're operating in an FPGA environment, those opportunities are at best very rare, possibly non-existent. The additional baggage of having to hand tweak each design revision that adds some new feature makes for a fragile design. > >The tools certainly can analyze them, what he was getting at is that > >you just shouldn't use them. =A0 > > I have no problem you or Nial not using them. > OK...not that either of us, or anyone else for that matter needs your blessing. > >there will be > >nothing you can do from a design perspective to compensate for that > >skew short of hand placement and routing and cross your fingers, hope > >for the best. > > Again this maybe your experience base but it's certainly not true in > general. > It has nothing to do with anyone's 'experience', it has only to do with the absolute basics: 1. The output of any flip flop will not change until some delay after the input clock has changed 2. It is quite possible for the delay from #1 plus the routing delay to get to some other flop to use as a clock (even on an adjacent logic block) may exceed the delay of some other logic signal to the 'D' input of that other flop...that's a hold time violation. In an FPGA environment, the ONLY mechanism to control this skew is hand placement and routing. 3. Hand place/route is costly (designer time =3D money) 4. Free running counters that have no outside control are not of much use. 5. Any control of counters comes from clock domains other than the plethora of clock domains created by the ripple counter. So, if you want to refute any of the above points, feel free to do so rather than being fuzzy about 'experiences'. > >It's not apparent to me at least that the fast path was > >analyzed...that's where the hold time problems will get fingered. =A0The > >tool can probably do it (Quartus does, you have to specify it since > >it's not in the 'default' analysis). > > Why do you expect the tool to understand your design? It's your > responsibility to do so and specify the required timing constraints > and checks. > 1. Specifying timing constraints does not guarantee you a working design. After the fact, it tells you when your design has a problem because it is an *analysis* step. 2. Timing constraints can not change a setup or hold time problem on a ripple counter into a working design. The only thing that can do that is hand place and route or getting lucky. 3. As it relates to ripple counters, ANY design specific constraints exist only to allow the timing analyzer to ignore what it would ordinarily flag as an error. 4. No tool exists to validate that any timing constraints are actually correct. Again, feel free to refute any of the above. > >Anyway, take your ripple counter and put a heat gun or cold spray on > >it and watch it change from working to not working. > > I understand if that's your experience with some of your past designs > but please don't attribute it to others. Those are my experiences when working with other people's async designs, I didn't attribute anything to anyone. I simply suggested that if someone thinks that they have a working FPGA design that uses asynchronous design techniques such as a ripple counter, than they should try running that design over the full temperature range of the part and verify whether or not the design is still 'working'. Kevin JenningsArticle: 144340
On Fri, 27 Nov 2009 14:52:32 -0800 (PST), KJ <kkjennings@sbcglobal.net> wrote: >On Nov 27, 4:37 pm, Muzaffer Kal <k...@dspia.com> wrote: >> >On Nov 26, 5:09 pm, Muzaffer Kal <k...@dspia.com> wrote: >> >> >YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA. >> >> >> This maybe true to some extent >> >> >Yes...to the extent that you want to have a working, robust design in >> >the end...to that extent. If that's not where you're trying to get >> >to, then generate all of the clocks that you want. >> >> No only to the extent of simple designs which don't require much from >> the designer, this is certainly good advice. > >Hand placement and routing is the only other way to get there. I think you should add the caveat "that you know of" at the end of that statement. Your response might be "tell me what else" but I already spent more time than it's worth here. >> >there will be >> >nothing you can do from a design perspective to compensate for that >> >skew short of hand placement and routing and cross your fingers, hope >> >for the best. >> >> Again this maybe your experience base but it's certainly not true in >> general. >> > >It has nothing to do with anyone's 'experience', it has only to do >with the absolute basics: >1. The output of any flip flop will not change until some delay after >the input clock has changed >2. It is quite possible for the delay from #1 plus the routing delay >to get to some other flop to use as a clock (even on an adjacent logic >block) may exceed the delay of some other logic signal to the 'D' >input of that other flop...that's a hold time violation. In an FPGA >environment, the ONLY mechanism to control this skew is hand placement >and routing. You seem to be under the impression that in today's FPGAs the clock trees are absolutely perfect zero-skew and the FPGA PAR tools don't have to do any hold fixes. I don't think that ever was the case but today with 45nm processes and 10s if not hundreds of mmsq die sizes that's definitely not true anymore. Open a timing report of any decent size design and look at a certain path to see what the delays of the clocks are. Also pay attention to what PAR is telling you in later stages of the routing. FPGA tools try to hide most of the complexity of digital design and give the illusion of a simple environment but this is not true in reality and certainly limits the amount of design capabilities one has. >4. No tool exists to validate that any timing constraints are actually >correct. >Again, feel free to refute any of the above. I am not sure how we got from divided clocks to ripple counters so I'll discount the other comments but this one is certainly wrong. You don't seem to think so but making such strong and wrong statements is an indication of one's experience. There are no real zero-skew clock trees, FPGA flops are not zero-hold and FPGA routers do hold fixing and yes there are tools which can analyze your design and verify your constraints. The fact that you don't know about them doesn't make them disappear. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 144341
On Fri, 27 Nov 2009 10:01:03 -0800 (PST), Gabor <gabor@alacron.com> wrote: >On Nov 25, 5:33 pm, Andy Botterill <a...@plymouth2.demon.co.uk> wrote: >> webpack crashed whilst synthesising my design. ... >> Any ideas/pointers. Thanks in advance Andy > >If you're running ISE version 10.1 you should have a restore >script for the project <project_name>.restore >If you're lucky and the original restore file hasn't >already been clobbered, you should get back all of >your settings. Trouble is, running ISE to discover the broken project file, you are liable to rewrite the .restore file... - BrianArticle: 144342
"KJ" <kkjennings@sbcglobal.net> wrote in message news:7eb143ac-bc28-489b-a753-b7c9469c5a27@d21g2000yqn.googlegroups.com... On Nov 27, 4:37 pm, Muzaffer Kal <k...@dspia.com> wrote: > >On Nov 26, 5:09 pm, Muzaffer Kal <k...@dspia.com> wrote: > >> >YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA. > > No only to the extent of simple designs which don't require much from > the designer, this is certainly good advice. > >A ripple counter is not a 'surgical knife' nor an 'irreplaceble tool', >it is just a ripple counter. Trying to make it sound like something >only to be understood by the high priests is a load of you-know-what, >stick to actual specifics of the topic. What a ripple counter brings >along is >1. Generally less logic than a synchronous counter >2. Generally less power consumption than a synchronous counter >3. Generally can be clocked faster than a synchronous counter Right and this is the reason why they are used in ASIC designs and why Muzaffer is experienced with them. However, it might not be the best design style for an FPGA and hence high-end synthesis tools like Precision automatically translates rippled counters to their synchronous equivalent (part of their ASIC ->FPGA prototyping conversion). Hans. www.ht-lab.comArticle: 144343
I am an electronics student and pretty new in FPGAs' use.
I am interested in to send images to a monitor from the FPGA.
I have already performed a test using the Spartan 3 xilinx board based on
an example I found at the Internet and it worked perfectly. Now I am trying
to translate the same example to the ML405 xilinx board, however it doesn't
work correctly.
I wonder if someone could give me a hand to solve this problem. I add my
vhdl code and ucf file
lalo
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;
entity top is
port(clk100_in : in std_logic;
red_out : out std_logic_vector(4 downto 0);
green_out : out std_logic_vector(4 downto 0);
blue_out : out std_logic_vector(4 downto 0);
hs_out : out std_logic;
vs_out : out std_logic);
end top;
architecture Behavioral of top is
signal clk25 : std_logic;
signal clk50 : std_logic;
signal hcounter : integer range 0 to 800;
signal vcounter : integer range 0 to 521;
signal color: std_logic_vector(2 downto 0);
begin
-- generate a 50Mhz clock
process (clk100_in)
begin
if clk100_in'event and clk100_in='1' then
clk50 <= not clk50;
end if;
end process;
-- generate a 55Mhz clock
process (clk50)
begin
if clk50'event and clk50='1' then
clk25 <= not clk25;
end if;
end process;
-- change color every one second
p1: process (clk25)
variable cnt: integer;
begin
if clk25'event and clk25='1' then
cnt := cnt + 1;
if cnt = 25000000 then
color <= color + "001";
cnt := 0;
end if;
end if;
end process;
p2: process (clk25, hcounter, vcounter)
variable x: integer range 0 to 639;
variable y: integer range 0 to 479;
begin
-- hcounter counts from 0 to 799
-- vcounter counts from 0 to 520
-- x coordinate: 0 - 639 (x = hcounter - 144, i.e., hcounter -Tpw-Tbp)
-- y coordinate: 0 - 479 (y = vcounter - 31, i.e., vcounter-Tpw-Tbp)
x := hcounter - 144;
y := vcounter - 31;
if clk25'event and clk25 = '1' then
-- To draw a pixel in (x0, y0), simply test if the ray trace to it
-- and set its color to any value between 1 to 7. The following example
simply sets
-- the whole display area to a single-color wash, which is changed every
one
-- second.
if x < 640 and y < 480 then
-- red_out <= "0000" & color(0);
-- green_out<= "0000" & color(1);
-- blue_out <= "0000" & color(2);
red_out <= "11111";
green_out<= "11111";
blue_out <= "11111";
else
-- if not traced, set it to "black" color
red_out <= "00000";
green_out<= "00000";
blue_out <= "00000";
end if;
-- Here is the timing for horizontal synchronization.
-- (Refer to p. 24, Xilinx, Spartan-3 Starter Kit Board User Guide)
-- Pulse width: Tpw = 96 cycles @ 25 MHz
-- Back porch: Tbp = 48 cycles
-- Display time: Tdisp = 640 cycles
-- Front porch: Tfp = 16 cycles
-- Sync pulse time (total cycles) Ts = 800 cycles
if hcounter > 0 and hcounter < 97 then
hs_out <= '0';
else
hs_out <= '1';
end if;
-- Here is the timing for vertical synchronization.
-- (Refer to p. 24, Xilinx, Spartan-3 Starter Kit Board User Guide)
-- Pulse width: Tpw = 1600 cycles (2 lines) @ 25 MHz
-- Back porch: Tbp = 23200 cycles (29 lines)
-- Display time: Tdisp = 38400 cycles (480 lines)
-- Front porch: Tfp = 8000 cycles (10 lines)
-- Sync pulse time (total cycles) Ts = 416800 cycles (521 lines)
if vcounter > 0 and vcounter < 3 then
vs_out <= '0';
else
vs_out <= '1';
end if;
-- horizontal counts from 0 to 799
hcounter <= hcounter+1;
if hcounter = 800 then
vcounter <= vcounter+1;
hcounter <= 0;
end if;
-- vertical counts from 0 to 519
if vcounter = 521 then
vcounter <= 0;
end if;
end if;
end process;
end behavioral;
Net "clk100_in" Loc = "AB14";
#------------------------------------------------------------------------------
# Viretex-4 VGA P2 Port:
#------------------------------------------------------------------------------
#RED
# LOC = R6; #VGA_R0
# LOC = R7; #VGA_R1
#NET red_out<0> LOC = P9; #VGA_R2
NET red_out<0> LOC = F3; #VGA_R3
NET red_out<1> LOC = H7; #VGA_R4
NET red_out<2> LOC = E3; #VGA_R5
NET red_out<3> LOC = G5; #VGA_R6
NET red_out<4> LOC = D3; #VGA_R7
# drive strength and speed for VGA
NET red_out<*> SLEW = FAST;
NET red_out<*> DRIVE = 8;
#GREEN
# LOC = N9; #VGA_G0
# LOC = N6; #VGA_G1
#NET green_out<0> LOC = P6; # VGA_G2
NET green_out<0> LOC = J3; # VGA_G3
NET green_out<1> LOC = K7; # VGA_G4
NET green_out<2> LOC = K3; # VGA_G5
NET green_out<3> LOC = G10; # VGA_G6
NET green_out<4> LOC = K6; # VGA_G7
# drive strength and speed for VGA
NET green_out<*> SLEW = FAST;
NET green_out<*> DRIVE = 8;
#BLUE
# LOC = P10; #VGA_B0
# LOC = P11; #VGA_B1
#NET blue_out<0> LOC = P8; # VGA_B2
NET blue_out<0> LOC = F4; # VGA_B3
NET blue_out<1> LOC = J4; # VGA_B4
NET blue_out<2> LOC = G9; # VGA_B5
NET blue_out<3> LOC = J5; # VGA_B6
NET blue_out<4> LOC = H3; # VGA_B7
# drive strength and speed for VGA
NET blue_out<*> SLEW = FAST;
NET blue_out<*> DRIVE = 8;
NET clk25 LOC = AC7; #VGA_CLK
NET clk25 IOSTANDARD = LVDCI_33;
NET clk25 SLEW = FAST;
NET clk25 DRIVE = 8;
NET hs_out LOC = C3; #HSYNC
NET hs_out SLEW = FAST;
NET hs_out DRIVE = 8;
NET vs_out LOC = D4; #VSYNC
NET vs_out SLEW = FAST;
NET vs_out DRIVE = 8;
Article: 144344On Nov 27, 6:16=A0pm, Muzaffer Kal <k...@dspia.com> wrote: > >> >> >YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA. > > >> >> This maybe true to some extent > > >> >Yes...to the extent that you want to have a working, robust design in > >> >the end...to that extent. =A0If that's not where you're trying to get > >> >to, then generate all of the clocks that you want. > > >> No only to the extent of simple designs which don't require much from > >> the designer, this is certainly good advice. > > >Hand placement and routing is the only other way to get there. =A0 > > I think you should add the caveat "that you know of" at the end of > that statement. Your response might be "tell me what else" but I > already spent more time than it's worth here. > No need for any caveats. I covered the reasons in the list of points starting with "The output of any flip flop will not change..." and asked you to refute anything that is not accurate, you came up empty. Apparently you'd like people here to believe that you know of something that will guarantee proper operation of a ripple counter in an FPGA that does not involve any form of hand place/route. Since you haven't refuted any of my points and you haven't backed up your own claim, I'll simply leave it at that as speaking quite clearly about your claim. > >It has nothing to do with anyone's 'experience', it has only to do > >with the absolute basics: > >1. The output of any flip flop will not change until some delay after > >the input clock has changed > >2. It is quite possible for the delay from #1 plus the routing delay > >to get to some other flop to use as a clock (even on an adjacent logic > >block) may exceed the delay of some other logic signal to the 'D' > >input of that other flop...that's a hold time violation. =A0In an FPGA > >environment, the ONLY mechanism to control this skew is hand placement > >and routing. > > You seem to be under the impression that in today's FPGAs the clock > trees are absolutely perfect zero-skew and the FPGA PAR tools don't > have to do any hold fixes. No, I'm not under any of those impressions. This is basic stuff, the signal that is being sampled will always have a setup and hold requirement around the time of the sampling edge. Rather than responding to what I actually post and instead responding to your impressions about what *you* think I may or may not know, is a sign of arrogance on your part. > Open a timing report of any decent > size design and look at a certain path to see what the delays of the > clocks are. Also pay attention to what PAR is telling you in later > stages of the routing. As it relates to the ripple counter also pay attention to what static timing analysis is telling you for the 'minimum' delay paths and hold times. > > >4. No tool exists to validate that any timing constraints are actually > >correct. > >Again, feel free to refute any of the above. > > I am not sure how we got from divided clocks to ripple counters so > I'll discount the other comments but this one is certainly wrong. Maybe you should read the postings to see how we got on to ripple counters. The originating comment has been there all along. Discount my comments if you'd like. I asked you to refute them if you can, your reply speaks volumes and again implies arrogance. Place and route may take timing constraints into account to help it do its job, but it does guarantee that it will meet them. If it did, there would never be a failing timing path when it comes time to performing static timing analysis. > You > don't seem to think so but making such strong and wrong statements is > an indication of one's experience. I'm accepting of when I've posted something incorrectly. In this particular thread I've also explicitly invited you to correct something that is incorrect. You've yet to refute any of my points but seem to think that simply saying that I'm wrong is sufficient. Good luck using that tact. > and yes there are tools which can analyze your design and verify =A0your > constraints. You've possibly misread or misinterpreted my statement which was "No tool exists to validate that any timing constraints are actually correct". I didn't say there were no tools that would take a design and verify it meets the constraints, I said a tool that would verify that the constraints themselves are correct. > The fact that you don't know about them doesn't make them > disappear. The fact that you don't list them just makes your postings of low information content. > -- > Muzaffer Kal > > DSPIA INC. > ASIC/FPGA Design Services > Hopefully you don't represent your company with these postings. End of Jennings' input to the Kal/Jennings thread Kevin JenningsArticle: 144345
On Nov 28, 9:29=A0am, "lalop" <euar...@yahoo.com.mx> wrote: > I am an electronics student and pretty new in FPGAs' use. > > I am interested in to send images to a monitor from the FPGA. > I have already performed a test using the Spartan 3 xilinx board based on > an example I found at the Internet and it worked perfectly. Now I am tryi= ng > to translate the same example to the ML405 xilinx board, however it doesn= 't > work correctly. > > I wonder if someone could give me a hand to solve this problem. I add my > vhdl code and ucf file > > lalo > [snip] lalo, In what way doesn't it work right? I assume you pretty much copied the code from the other project. You did check the pinout definitions in your .ucf file against the board documentation? Does the Virtex 4 board have the same hardware for VGA output (D/A Converter or just resistors) as the old board? Most video D/A Converters need a clock signal as well as synch and data. Your clocking is a bit of a mess. I imagine you may have inherited some of it from the prior project, but it's not generally good practice to make ripple counters in an FPGA. Your net clk25 in the .ucf doesn't correspond to a top module port. Is this supposed to drive the D/A converter clock? Regards, GaborArticle: 144346
On Sat, 28 Nov 2009 06:37:19 -0800 (PST), KJ <kkjennings@sbcglobal.net> wrote: >> and yes there are tools which can analyze your design and verify your >> constraints. > >You've possibly misread or misinterpreted my statement which was "No >tool exists to validate that any timing constraints are actually >correct". I didn't say there were no tools that would take a design >and verify it meets the constraints, I said a tool that would verify >that the constraints themselves are correct. What was said was quite clear and there are such tools. Here is one example: http://www.bluepearlsoftware.com/products/azure.html >> The fact that you don't know about them doesn't make them >> disappear. > >The fact that you don't list them just makes your postings of low >information content. The web is full of information. You should spend some time to acquire some on your own. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 144347
Hi Jonathan, Fred Kennedy, who is the leader of this project, has managed to arrange for someone to pick up the programmer from you, at a time to suit you. I think Fred has already contacted you. If not, his details are Fred Kennedy email fredk@kcbbs.gen.nz Again thank you for your assistance here. Regards Clayton On Nov 26, 8:16=A0am, Claytong_nz <clay...@isnotcrazy.com> wrote: > On Nov 26, 1:10=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> > wrote: > > > > > > > On Wed, 25 Nov 2009 03:30:36 -0800 (PST), Claytong_nz wrote: > > >These FPGAs are apparently okay in low earth orbit. My understanding > > >is that they are already up there and working fine - at least the > > >older technologies such as this part > > > yeah, I guess they are fairly bulletproof (antifuse, 0.18um, ...) > > > >now hand-tied by ITAR - hence the US guys are not permitted to help > > > sheesh! > > > >I'd like to take you up on your programmer offer > > > I'd be happy to see it go to a good home; I don't see myself ever > > using it again. =A0You get three or four 12x16B 84PLCC thrown in :-) > > And I'll try to find my archived copy of the software, but > > no promises on that; I haven't used it for years. > > > > (or possibly purchasing it) > > > Nah, you can have it - but we need to find a shipment method > > that doesn't cost me anything, and doesn't cost you very much. > > > >BTW, where are you? > > > Oxford, England - but working in Munich, Germany for much of > > the next few weeks. > > -- > > Jonathan Bromley, Verification Engineer > > > Verilab =A0www.THAT_COMPANY.com > > Thank you. Your offer is very much appreciated Jonathan. I'll see if > we can find someone local to you to collect or some other arrangement. > > ClaytonArticle: 144348
On Sun, 29 Nov 2009 01:42:22 -0800 (PST), Claytong_nz wrote: >Fred Kennedy, who is the leader of this project, has managed to >arrange for someone to pick up the programmer from you Cool. I'll ping him today. > Fred Kennedy email fredk@<snip> I hope he has a good spamtrap :-) >Again thank you for your assistance here. As I said, it's a pleasure to see it going to good use. -- Jonathan Bromley, Verification Engineer Verilab www.THAT_COMPANY.comArticle: 144349
hi,all
i am facing a problem when obtaining port signals with chipscope in
edk. I can get only one right data from ports,but following samples(total
16384 samples) are in high status (High-impedance state)at all ports ,then
the signal data are 1,8,64,0(width=8 port)or 0,2,16,128,1024,8192 (width=16
port) and so on.then these data display with loop. what is the problem?
who can help me.
thanks in advance..
---------------------------------------
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com
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