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 need some kind of IP module that implements an ISA bus interface. It could be in the form of a "black box" or in the form of synthesizable VHDL code. I believe Xilinx used to have something along those lines, but it seems to have been discontinued. Now they only offer a "PCI Development Kit" for the PCI bus, and it's rather expensive too (~9000 US dollars). My needs are not so great in terms of performance, and I'm not prepared to fork out that kind of money. So if someone could suggest an ISA solution that could be purchased for 1000 dollars or less, I'd be grateful. I need it for the design of a PC/104 board that is to be the interface between measurement devices and an embedded PC. The measurement devices use a proprietary, synchronous serial protocol. I'm planning to implement the whole thing in a single FPGA, preferably a Spartan-II device. TIA, Ernst Rattenhuber P.S. Email replies can be sent to the address in my header minus the obvious spam deterrent parts.Article: 30601
Utku Ozcan wrote: > > BTW, from a designer point of view, I would recommend Xilinx should > give more information what impacts for each cost table value are on > the design. It is not declared anywhere. Ie. are cost tables from 1 > to 50 for speed and 51 till 1000 for area? It would have been > superb. Cost table number doesn't mean anything. Therefore it would > be the best way to run for all cost tables, ie. at least 100 runs > for each design load. > > Utku In theory the idea is that you only run the placer passes for each cost table & then pick the best of those, say the top 5, for a full routing run(s). However if the MPPR & SPPR results for a given cost table are different then this breaks down. Wiht my new 1G3 DDR-266 Athlon I might try to do the whole thing, place & route for each cost table, while I'm away on a long weekend. BTW: I think I might have been responsible for the original answers database report or at least I may have been one of several. It took about 2 months of steady badgering to get Xilinx to admit there was a problem. They then claimed to have fixed it in 2.1i SP6 - an uninitialised variable was said to be the problem. I look back a few months later & this had changed to say ``There may still be some problems - wait for 3.1i''. I have a sneaking suspicion that heuristic arguments are red herrings here covering up what is still a bug. Its certainly true that MPPR isn't much use if to get a good route with cost table 67 you actually have to run full place & route from table 1,2,3, ..., 65,66,67!Article: 30602
Hi Mark, I'm also looking. Denis O'LearyArticle: 30603
Frode Vatvedt Fjeld wrote: > > Jim Granville <jim.granville@designtools.co.nz> writes: > > > We are doing work on Run-Length compression using CPLD, for > > two areas > > > > - Increasing apparent bandwidth > > - Reducing storage requirements > > This is exactly what I'm interested in. > > > What do you want to know ? > > I'd just like to know in general terms about the standard (if any) > techniques or "algorithms" used for implementing such things in > programmable logic. There is no 'std' and in a PLD, you are limited to just what can be done. Run Length compression is very doable, as this is a table of Value + Length, and the Length preloads a counter. The ECP printer port has a mode like this In very simple RLC, the length is taken direct from the compressed data, but you can compress using a length pointer, that then fetches from a 'tiny prom' in the PLD. We are looking into software that analyses the data to be compressed, and then chooses a best-fit 'tiny prom' table, that it creates along with the compressed data stream. Of course, it depends a lot on the data being handled... -jg -- ======= 80x51 Tools & PLD IP Specialists ========= = http://www.DesignTools.co.nzArticle: 30604
Since I am being quoted, I might as well answer.
The quoted statement is a warning that you should not shoot yourself
in the foot. It is also a disclaimer that protects me from the wrath
of my synchronous brethren.
I have published, years ago, a clock double-differentiator circuit
that works reliably inside an IC, since it is kind of adaptive: If
the circuit is cold and fast, the spikes get shorter, but the
circuit also needs only shorter pulses. And vice versa. There is
tracking inside a chip. Most of the neat analog tricks that Bob
Widlar is so famous for only work due to on-chip tracking. ( How's
that for name-dropping. I actually met that famous man during my
early days at Fairchild :-).
Here is the differentiator circuit:
Incoming clock drives XOR gate, output of XOR is double-frequency
output signal.
XOR output also clocks flip-flop. Flip-flop Q drives inverter.
Inverter output drives flip-flop D, and also the other input to the
XOR.
If you want a longer pulse, make the inverter slow, ( e.g. cascade
some gates )
Yes it's a dirty trick, and the pulse length is ill-defined. And you
should not do this at multiple 100 MHz. But when there is no other
solution, this works just fine. It gets you dirty comments from the
synchronous purists though. It's your choice.
Peter Alfke
("Synchronous wherever possible. Asynchronous only when you really
know what you are doing")
luigi funes wrote:
> Hi!
> The main clock of a system is a 50 MHz, 50% duty cycle (+/-10%)
> signal.
> I have to synchronize some activities of a PLD on the rising edge
> of this signal, some on falling edge and many on both edges.
> For example, the data transfers occur on both edges and
> I have to count it, calculate CRCs, and so on.
>
> I'm tempted to do a little asynchronous trick inside the PLD to
> make a 4-6 nS pulse for each main clock edge, and use this pulse
> to clock the FFs, but I'm scared of the Peters Alfke words:
> "Asynchronous design methods may ruin your project, your
> career and your health". =:-/
>
> Which alternatives there are?
> Thanks in advance!
>
> Luigi
Article: 30605Utku Ozcan wrote: > > Allan Herriman wrote: > > > > Hi, > > > > I'm routing a Virtex-E part, and I find that I get different routing > > results for a particular cost table depending on whether I use single > > pass or multi pass (the -n MPPR option) on par. > > > > E.g. for my current design, on cost table #1, I get a 5.830ns result > > with single pass, but 5.925ns with multi pass, also using cost table #1. > > > > Question: what does par do differently, so that it gets different > > results even though the cost table is the same? > > Program includes heuristic algorithms, ie. it doesn't find the optimal > but close result. Therefore at every try it might finish with different > result. Placer and router algorithms are NP-Complete, because P&R itself > is NP-Complete therefore you will never find the optimal (the only one) > result in a reasonable time, that's why program might cease operation > after a definite threshold. Decision is non-deterministic to the user. Heuristic algorithms are deterministic on a digital machine. This cannot explain the difference, unless they seed the random number generator differently depending on whether this is SPPR or MPPR. > > Which result should I believe? > > I think each is correct. > > > BTW, the 5.925ns route (MPPR) works when downloaded, and the 5.830ns > > (SPPR) one doesn't. > > SPPR by default must have used default cost table 1, but MPPR might > use a different cost table. Err, no. I used the -t 1 option on SPPR to select cost table 1, and the MPPR result appeared in the output file for cost table 1. Both were definitely cost table 1. The fact that one worked and one didn't was a red herring, as this was caused by a completely independent tool bug. > > I'm using Alliance Release 3.3.07i (par D.26), with speed files ver > > 1.56, but I've also seen this issue on other versions. > > > > I've read Xilinx answer 8746, which describes a bug with similar > > symptoms, but it says that it was fixed in version 3.1i about a year > > ago. > > It also says "Each MPPR result should be identical to an equivalent > > single pass result for the same cost table." > > We must pay attention to what it has been implied with "identical". > Say, for example, if you get two results 4.32 ns and 3.95 ns for the > same initial parameters (ie. cost table) then we might say the > results for all those runs are identical in a definite percent > region (statistically). I would have expected download files identical down to the bit level. When I run my design through the tools again with the same EDIF and the same command line options, I get identical download files. I'm fairly sure this is a tool bug. Regards, Allan.Article: 30606
>Yes it's a dirty trick, and the pulse length is ill-defined. And you >should not do this at multiple 100 MHz. But when there is no other >solution, this works just fine. It gets you dirty comments from the >synchronous purists though. It's your choice. OK, I'll keep the discussion going. Why doesn't that work at "multiple 100 MHz"? Is there some scaling property that I'm missing? I'm assuming that you are using fast enough silicon so that it will work in the slow corner. PS: I smile whenever I think of that circuit. It's one of those simple but neat/sneaky tricks that I wish I had thought of. -- These are my opinions, not necessarily my employeers. I hate spam.Article: 30607
> I would have expected download files identical down to the bit level. > When I run my design through the tools again with the same EDIF and > the same command line options, I get identical download files. > > I'm fairly sure this is a tool bug. > > Regards, > Allan. BTW have you got any chance to run 2 identical SPPRs? I mean, I wonder whether their results are different from each other. UtkuArticle: 30608
The DDS is normally straightforward but 240MHz is pretty fast for a Xilinx. I just had to do a fast one so here's a couple of hints: -The 32-bit phase accumulator can be fully pipelined by making it a group of 32 half adders, with the carries pipelined from one to the next. Then you need to delay the lower bits to match them with the upper bits; you can use the SRLs for this. This is bigger, but faster. -The BlockRAMs will never work at 240MHz. The clock->out time is about 3ns, but it also takes a while to route the output to the next register. One trick is to use both ports of the dual-port BRAM sine lookup table. You use the first port on one cycle, the next on the next cycle, etc, making the BRAM a 2-cycle path. (You have to commutate the two output ports into one.) But you probably can't have 2^18 precision, because that would require all the BRAM in an extended memory part. -There was an article in the Xilinx XCell magazine about the Cordic algorithm, which might be applicable to you. I think the phase ditherer is just a simple LFSR you can XOR with the LSBs. There's got to be a way to reduce the sine lookup table size. I wonder if you could linearly interpolate between two points in a smaller table? Or maybe calculate sine using some sort of hardware Maclaurin series calculator? "Paul Teagle" <pteagle@chariot.net.au> wrote in message news:3add9bf3_1@news.chariot.net.au... > Hi, > > I'm looking for a very rough back-of-the-envelope estimate on the > feasibility of implementing a complex DDS & modulator component in a FPGA. > The relevant specs are: > > - operating at 240 mega complex samples/sec > > - 16 bit I & Q inputs to the modulator > > - phase accumulator 32 bits > > - 18 bit sine/cosine look-up accuracy, 20 bit result > > - 5 bit phase dither (selectable) on lsb's > > Assume the data is sourced on-chip and goes to other destinations on-chip. > > A reasonable amount of pipeling can be tolerated. > > We have no preference of Altera/Xilinx at the moment. SRAM based is > required, though, as is having a fair amount of other FPGA area for other > functions. > > There are several other aspects of the design (interpolators, multipliers > etc) that I haven't mentioned, but its the DDS that I think is the most > complicated. > > Any of you contractors out there want to hazard a rough order of magnitude > of cost for developing this sort of thing, maybe in terms of hours & > dollars, and amount of area it would consume on device XYZ ? > > regards, > > Paul Teagle > Systems Engineer > CAE Electronics > > > > > >Article: 30609
Hi, I'm developing a board based on a virtex FPGA. The design summary indicates that the maximum operating frequency is about 30 MHz, but the actual frequency in the board seems to be slower than 15 MHz. I'm using both of clock edges (rising and falling) in my HDL code. Is this the main cause of this result ? Thanks. AlanArticle: 30610
Ernst Rattenhuber wrote: > > I need some kind of IP module that implements an ISA bus interface. It could be > in the form of a "black box" or in the form of synthesizable VHDL code. I > believe Xilinx used to have something along those lines, but it seems to have > been discontinued. Now they only offer a "PCI Development Kit" for the PCI bus, > and it's rather expensive too (~9000 US dollars). > > My needs are not so great in terms of performance, and I'm not prepared to fork > out that kind of money. So if someone could suggest an ISA solution that could > be purchased for 1000 dollars or less, I'd be grateful. > > I need it for the design of a PC/104 board that is to be the interface between > measurement devices and an embedded PC. The measurement devices use a > proprietary, synchronous serial protocol. I'm planning to implement the whole > thing in a single FPGA, preferably a Spartan-II device. > > TIA, > > Ernst Rattenhuber Ernst, The ISA bus is very simple, you could probably implement one yourself in a couple of days. It'd probably take as long to understand the operation of any IP you can get hold of. As far as I know it's _VERY_ slow, so you've no tight timing reuirements (like the PCI bus) to worry about. Nial.Article: 30611
Hello masters of the digital universe! I`m looking for a development board with following specs: 1) FPGA: Xilinx Virtex100 and beyond 2) processor: Speed: min. 40MHz ROM: the bigger the better RAM: min. 2Mbit Tools: ANSI C compiler 3) if possible: ethernet controller (only PHY needed) Thanx in advance! StevenArticle: 30612
Hi, As most people familiar with low power designs already know, there exist a technique based on voltage supply reduction for ASICS which allow (at the price of increased logic and routing delays) to reduce the overall circuit power dissipation. I was wondering if these thechniques could be applied to modern FPGAs such a SPARTANII or Virtex ? Does anyone knows about this ? Thanks StevenArticle: 30613
Hello everybody, I am a newcomer to the FPGA programming and design area and working on a project using Xess XSV board having Virtex fpga. I need some help for conversion of (720 X 486) format digital video to (640 X 480) VGA signal. One one side of the system I am getting the decoder output and on the other side my VGA controller (being designed on xess XSV Board) would take this data for rasterisation. Thanks GaurArticle: 30614
Utku Ozcan wrote: > > > I would have expected download files identical down to the bit level. > > When I run my design through the tools again with the same EDIF and > > the same command line options, I get identical download files. > > > > I'm fairly sure this is a tool bug. > > > > Regards, > > Allan. > > BTW have you got any chance to run 2 identical SPPRs? I mean, I wonder > whether their results are different from each other. I have run 2 SPPRs on the same computer. This resulted in identical download files, so I can rule out transient computer problems. I have also run an additional SPPR on a different computer, with the same EDIF and command line arguments. It produced a result that was different to both the SPPR and MPPR results from the first computer. It also worked ok in the lab, whereas the SPPR download from the first computer had functional problems. This implied to me that the installation of the Xilinx programs had been corrupted on one of the computers, so I compared all the executable files and speed files, etc. on the two computers, and they were identical. So why should two computers produce different results if they are running identical programs with identical input? I don't think that PAR uses the machine ID to seed the random number generator. I might have missed comparing one of the files though, or it could be a difference in a system DLL. Regards, Allan.Article: 30615
Ernst Rattenhuber ha scritto nel messaggio <4C01A18846D8F834.C53AD3E6B1E5410F.A773BB20C2D12EDB@lp.airnews.net>... >I need some kind of IP module that implements an ISA bus interface. It could be >in the form of a "black box" or in the form of synthesizable VHDL code. I >believe Xilinx used to have something along those lines, but it seems to have >been discontinued. Now they only offer a "PCI Development Kit" for the PCI bus, >and it's rather expensive too (~9000 US dollars). > >My needs are not so great in terms of performance, and I'm not prepared to fork >out that kind of money. So if someone could suggest an ISA solution that could >be purchased for 1000 dollars or less, I'd be grateful. > >I need it for the design of a PC/104 board that is to be the interface between >measurement devices and an embedded PC. The measurement devices use a >proprietary, synchronous serial protocol. I'm planning to implement the whole >thing in a single FPGA, preferably a Spartan-II device. > >TIA, > >Ernst Rattenhuber > > >P.S. Email replies can be sent to the address in my header minus the obvious >spam deterrent parts. > Ernst, I think you don't need really to buy a IP module for your purpose. The ISA bus is very easy to interface. I did a complete 16 bit interface with a 44 pins, 32 cells CPLD. You have only to decode the addresses, the memory R/W and the IO R/W signals and buffering the data bus (8 or 16 bits). The interrupt also is easy to handle. Perhaps the DMA transfer mode is more complex, I never used it because it seems me to have no benefits with a CPU > 386. If you miss the ISA bus specifications, you can find easily on the web, for example in http://www.epanorama.net LuigiArticle: 30616
Kevin Neilson <kevin_neilson@yahoo.com> wrote in message
news:i7wD6.268$cf6.37903@newsread2.prod.itd.earthlink.net...
> The DDS is normally straightforward but 240MHz is pretty fast for a
Xilinx.
my thinking as well - pretty fast, but not absolutely TOO fast.
> I just had to do a fast one so here's a couple of hints:
>
> -The 32-bit phase accumulator can be fully pipelined by making it a group
of
> 32 half adders, with the carries pipelined from one to the next. Then you
> need to delay the lower bits to match them with the upper bits; you can
use
> the SRLs for this. This is bigger, but faster.
One thing I forgot to mention was that the frequency value stays constant,
but I'm not sure if this helps.
> -The BlockRAMs will never work at 240MHz. The clock->out time is about
3ns,
> but it also takes a while to route the output to the next register. One
> trick is to use both ports of the dual-port BRAM sine lookup table. You
use
> the first port on one cycle, the next on the next cycle, etc, making the
> BRAM a 2-cycle path. (You have to commutate the two output ports into
one.)
> But you probably can't have 2^18 precision, because that would require all
> the BRAM in an extended memory part.
> -There was an article in the Xilinx XCell magazine about the Cordic
> algorithm, which might be applicable to you.
>
Ray Andraka's area, I think.
> I think the phase ditherer is just a simple LFSR you can XOR with the
LSBs.
>
> There's got to be a way to reduce the sine lookup table size. I wonder if
> you could linearly interpolate between two points in a smaller table? Or
> maybe calculate sine using some sort of hardware Maclaurin series
> calculator?
Perhaps a coarse/fine table:
sin(a+b) = sin(a)cos(b) + sin(b)cos(a)
where a = 9 bits coarse angle (say 0 to 360/(2^8)) = 0.7 degrees
b = 9 bits fine angle (say 0 to 0.7/(2^9)) = 1.37millidegrees
Thus two, 512 word look-up tables, rather than a single 262k table, to get
the same precision...Dual port to access the sine & cosine simultaneously,
with any caveats for look-up speed.
Maybe some complication to put the angle into an (a+b) format first, but how
hard can it be :-)
Obviously, we'll need a couple more multipliers & adders, but from the sound
of it, the Virtex-II multipliers will cope with the speed (?)
Time to start reviewing the device specs.
Thanks for the input so far.
regards,
Paul T.
Article: 30617"Peter Alfke" <palfke@earthlink.net> wrote in message news:3ADE5DDC.E6BD129E@earthlink.net... [...] > > Incoming clock drives XOR gate, output of XOR is double-frequency > output signal. > XOR output also clocks flip-flop. Flip-flop Q drives inverter. > Inverter output drives flip-flop D, and also the other input to the > XOR. > > If you want a longer pulse, make the inverter slow, ( e.g. cascade > some gates ) I see how this works. To double a clock pulse I have previously used a similar circuit where a 74LS86 (Quad XOR gate) was clocked at 5.333MHz giving an output of 10.666MHz (http://www.hanssummers.com/computers/newz80/circuit/circuit.htm#P2). In this circuit the incoming clock drives one input of the XOR directly, the other XOR input is driven by the same incoming clock but via an inverter. In my case the inverter consists of the other 3 XOR gates in the chip. Only one inverter would make the width of the output pulse too short, I had some trouble when I tried it. Is your circuit better than this one (e.g. more stable) or another way to acheive the same result? ------------------ Hans Summers http://www.HansSummers.ComArticle: 30618
Jim Granville <jim.granville@designtools.co.nz> writes: > [..] Of course, it depends a lot on the data being handled... Ok, thanks for the help. -- Frode Vatvedt FjeldArticle: 30619
Our client is the leading provider of highly integrated silicon solutions that enable broadband digital transmission of voice, video, and data. Using proprietary technologies and advanced design methodologies, the company designs, develops and supplies integrated circuits for a number of the most significant broadband communications markets, including the markets for cable set-top boxes, cable modems, high-speed local, metropolitan and wide area networks, home networking, Voice over Internet Protocol (VoIP), residential broadband gateways, direct broadcast satellite and terrestrial digital broadcast, optical networking, digital subscriber lines (xDSL) and wireless communications. They are currently seeking ASIC Designers with the following... Required Skills and Experiences: BSEE or equivalent; MSEE preferred, plus 5+ years' of VLSI hardware design experience. Position requires working knowledge of Verilog and Synopsys. Experience with back-end CAE, layout tools, 3D, video, and DSP is a plus. Responsibilities: Responsibilities include: definitions of the molecules specifications based on the system specification; RTL development and debugging, test bench development; design validation as part of an overall system, system integration; synthesis of the RTL at a certain clock speed; Implementation of the test strategy, scan insertion, ATPG test vectors generation. PROCOM: Established in 1978, Professional Computer Consultants Group Ltd. (Procom) is a national leader in the provision of Computer personnel on a contract and full-time basis. Our clients are comprised of the largest national and international corporations that utilize technical resources extensively across a wide range of disciplines. In the Financial Post (March 1999) Procom was ranked as the 6th largest professional Services Company in Canada. In November of 1999, Procom was named a Regional finalist in Canada' s 50 Best Managed Private companies. Our track record is proven with more than 180 consultants servicing Ottawa's high tech community and more than 1600 Procom consultants currently on assignment throughout. North America. For further information on this and other opportunities please visit our web site at www.procom.ca. Interested candidates are invited to forward their resumes or questions in confidence to: Derek Weber PROCOM 300 March Rd Suite 600 Kanata, Ontario K2K-2E2 613-270-9339 x231 613-270-9449 (FAX) derekw@procom.ca www.procom.caArticle: 30620
Our client is the world leader in sales of communications semiconductors. They design, develop and manufacture optoelectronic components for communications networks, and integrated circuits for use in a broad range of communications and computer equipment. They sell there products globally to the leading manufacturers of communications and computer equipment. There optoelectronic components transmit, process, change, amplify and receive light that carries data and voice traffic over optical networks. They provide optoelectronic components for use in both submarine and terrestrial networks, including high-speed transport networks, metropolitan networks, cable television networks and data communications networks. Our client offers integrated circuits, or chips, for a broad range of communications networks and computer equipment. Our integrated circuits are designed to perform various functions, such as processing electronic signals, controlling electronic system functions and processing and storing data. We also offer wireless local area networking products, which facilitate the transmission of data and voice signals within a localized area without cables or wires. As a Senior ASIC Design Engineer, this individual will lead a dedicated team designing very large (1M+gates), high speed (80+MHz) and complex ASICs targeting leading-edge SONET/SDH Datacom (ATM, POS) and Telecom (ADM, TM) applications with 5+ years experience. Responsibilities will include system level specification, architecture, documentation, project management and development team leadership. As a Senior ASIC Design Engineer, this individual will lead a small team (4-6) of talented Engineers in all phases of the ASIC development flow (design in RTL level HDL, verification, synthesis, DFT insertion, floor-planning and timing analysis) using UNIX-based CAD tools (eg: Verilog, Synopsys, static timing, formal checking). Other responsibilities include working with UNIX, Emacs, RCS and mentoring of junior Engineers and customer interaction. This individual must be legally employable in Canada and communicate fluently in English. This position is a permanent full-time reporting to the ASIC Department. PROCOM: Established in 1978, Professional Computer Consultants Group Ltd. (Procom) is a national leader in the provision of Computer personnel on a contract and full-time basis. Our clients are comprised of the largest national and international corporations that utilize technical resources extensively across a wide range of disciplines. In the Financial Post (March 1999) Procom was ranked as the 6th largest professional Services Company in Canada. In November of 1999, Procom was named a Regional finalist in Canada' s 50 Best Managed Private companies. Our track record is proven with more than 180 consultants servicing Ottawa's high tech community and more than 1600 Procom consultants currently on assignment throughout. North America. For further information on this and other opportunities please visit our web site at www.procom.ca. Derek Weber PROCOM 300 March Rd Suite 600 Kanata, Ontario K2K-2E2 613-270-9339 x231 613-270-9449 (FAX) derekw@procom.ca www.procom.caArticle: 30621
> I have run 2 SPPRs on the same computer. This resulted in identical > download files, so I can rule out transient computer problems. > > I have also run an additional SPPR on a different computer, with the > same EDIF and command line arguments. > It produced a result that was different to both the SPPR and MPPR > results from the first computer. > It also worked ok in the lab, whereas the SPPR download from the first > computer had functional problems. > > This implied to me that the installation of the Xilinx programs had been > corrupted on one of the computers, so I compared all the executable > files and speed files, etc. on the two computers, and they were > identical. > > So why should two computers produce different results if they are > running identical programs with identical input? > I don't think that PAR uses the machine ID to seed the random number > generator. > I might have missed comparing one of the files though, or it could be a > difference in a system DLL. Very tight observation, thank you very much for your comments. Then machine time might be different? Maybe tools use machine time for seed to obtain "random" behavior. Ok, you are using PC, probably it is similar under UNIX. Well, anyway, these things will be unanswered questions for a while then! > Regards, > Allan. UtkuArticle: 30622
Steven, If you lower the voltage to the FPGA, it will either trip the power on reset theshold voltage, and start over, or it will just slow down until it trips and resets. You can always choose to operate anywhere inside the recommended operating conditions limits, and expect the device to perform to specifications. You may also operate anywhere inside the absolute maximum ratings and expect thge device to function, but it may not meet timing, or some other specification. The smaller Spartan II devices XC2S15 and XC2S30 parts are measuring around 20 mA for turning on at room temperature, typical, and the quiescent current is a little less (2.5 V Vccint, 3.3 V Vcco's). We will have much better data once we see some process corners. Virtex II 2V40 is at about 24 mA to turn on, and about 8 mA in the power down mode at room temperature, typical (1.5 V Vccint, 3.3 V Vcco's). What do you feel is "low" power? Austin Steven Derrien wrote: > Hi, > > As most people familiar with low power designs already know, there exist > a > technique based on voltage supply reduction for ASICS which allow > (at the price of increased logic and routing delays) to reduce the > overall circuit power dissipation. > > I was wondering if these thechniques could be applied to modern FPGAs > such a SPARTANII or Virtex ? Does anyone knows about this ? > > Thanks > > StevenArticle: 30623
Why my warning about >100 MHz ? Mainly paranoia. In order to be reliable, the spike should not be too short, and at >100 MHz there are not so many ns. Fundamentally, I like to have plenty of timing margin for tricks like this. At the 50 MHz, a 5 ns spike would be just fine. But everything scales. So it's really paranoia and fear of the synchronous zealots. Thanks for the friendly compliment. Peter Alfke =========================== Hal Murray wrote: > >Yes it's a dirty trick, and the pulse length is ill-defined. And you > >should not do this at multiple 100 MHz. But when there is no other > >solution, this works just fine. It gets you dirty comments from the > >synchronous purists though. It's your choice. > > OK, I'll keep the discussion going. > > Why doesn't that work at "multiple 100 MHz"? > > Is there some scaling property that I'm missing? > > I'm assuming that you are using fast enough silicon so that it > will work in the slow corner. > > PS: I smile whenever I think of that circuit. It's one of those > simple but neat/sneaky tricks that I wish I had thought of. > > -- > These are my opinions, not necessarily my employeers. I hate spam.Article: 30624
The difference is that "your" circuit is open loop, while my circuit is closed loop. When the input level changes, the output goes High. This rising edge toggles the flip-flop, its Q gets inverted, and that shuts off the double-frequency clock spike. So the clock spike must first be successful in triggering the flip-flop before it can be terminated. That is a safer mechanism than the XORing of a signal and a delayed version of itself. Which of course works also, provided the delay is long enough. Greetings Peter Alfke, Xilinx Applications Hans Summers wrote: > Is your circuit better than this one (e.g. more stable) or another way to > acheive the same result? > > ------------------ > Hans Summers > http://www.HansSummers.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