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
David, It sounds a bit like a machine problem. I suggest you at least run memtest86 (http://www.memtest86.com/) on it. JonArticle: 41351
"Sławomir Balon" wrote: > > Hi! > Is there any idea for multiplying clock in max7000 devices? Consider using a separate clock chip. Do a google search on: phase lock clock -- Mike TreselerArticle: 41352
"Sławomir Balon" wrote: > > Hi! > I'm looking for fast clock source (200MHz) for epm7032b, it will produce > four phase shifted by 90 degree 50MHz clocks. What oscilator should i use? > Crystal oscilators offer ends at 120MHz, i didn't ever use any plls at that An ecl design would work. a generator like: http://www.amis.com/tgp/feature_sheets/fs71429.cfm and some ecl flops in a johnson counter and level shift. -- Mike TreselerArticle: 41353
If you want four phases of a 50 MHz clock, you need not go higher than 100 MHz, since a 180 degree shift is just an inversion, and 270 is 90 inverted. BTW, Virtex-II does all that "for free" in its Digital Clock Manager(s). Peter Alfke, Xilinx Applications ===================== "S3awomir Balon" wrote: > Hi! > I'm looking for fast clock source (200MHz) for epm7032b, it will produce > four phase shifted by 90 degree 50MHz clocks. What oscilator should i use? > Crystal oscilators offer ends at 120MHz, i didn't ever use any plls at that > high freq's. I'm open for any ideas... > BTW how they make lets say: 1GSPS in oscilloscopes (i know that on > repetitions but how they get those phase shifts for ADCs? - ECL??) > > thanx > SlawekArticle: 41354
Dear Ray, I agree that a really safe design should also consider upsets. My tech Xclusive on the subject of resets in designs is very much about safe design techniques. The whole concept of a one-hot state machine is an issue if you need to trap the cases of 'n-hot' and 'cold states'. In these cases I would favour an encoded state machine (not that many people carry out full illegal state analysis on those either). In my design for a UART state machine described in part 2 of my TechX, I deliberately design the state machine to go 'cold' at the end of processing a character. The next start bit on the serial line is then used to inject the next 'hot' state. In this way, any induced error can be made to be short lived. The efficiency offered by the SRL16E could also be exploited to provide redundancy. 3 state machines working in parallel with a majority voting system for each output control bit (a LUT3) would be nice. In this way, we do not have to tolerate the error condition at all. Seems like we have got away from LFSR counters a bit, but a good thread anyway. Regards, Ken Ray Andraka wrote: > I agree, the SRL16 is a wonder drug. I don't however like to use it as a closed > loop state machine as described by Ken because such a design will not self > recover in the event of an upset. The SRL16 only gets initialized on > configuration, so if for some reason you get an upset (and in the .15 micron it > does sometimes happen), your state machine carries that upset state bit until > the device is reconfigured. In my book, that is poor design practice. As soon > as you add the logic to detect the illegal states, the size gets considerably > larger (it may be more advantageous to use TMR here).Article: 41355
Adrian - I agree with you in theory. Problem is, I always want to use the latest speedfiles on my designs, and that (I think) requires that I install the latest software. Does anyone know if th 4.2i speedfiles work with 4.1i? Thanks, Bob Perlman "Noddy" <g9731642@campus.ru.ac.za> wrote in message news:<1017155726.417024@turtle.ru.ac.za>... > Can't really tell you how to fix your problem, other than the advice that > you should always finish a design/project to completion using the same > software before upgrading. I'm still using Foundation 3.3 with ISE 4.1 & 4.2 > still in their boxes, and I'm not taking them out till I have finished my > project. > > adrian > > > > > David Frith wrote: > > > > > > > > Hello all > > > > > > > > I've just loaded on ISE 4.2i and the first design I ran through gives > me > an > > > > error at ngdbuild. This is with exactly the same input files as 4.1i > which > > > > > > Did you instal the SP1 already ? Probably it goes away ... > > > > Installed SP1. No difference. > > > > David > > > >Article: 41356
When is Celoxica going to kill of this useless proprietary Handel-C language in favor of moving to the industry standard SystemC ?? I've done a couple of experiments with DK1 3.0 and the language is painful to use, doesn't leverage C++ and once I do soemthing in Handel-C, I can't use with any other design or verification tools, like I can with SystemC. There's a germ of value in Celoxica stuff but not while it is encumbered by a dead-end proprietary language. When are these guys going to get real ??Article: 41357
Thanks - I know about Certify. Unfortunately I don't have tens of thousands of dollars available to me I'm afraid ! Muzaffer Kal wrote: > > On Thu, 21 Mar 2002 23:46:12 +0000, Craig McAdam > <craig.mcadam@ntlworld.com> wrote: > > >I'm implementing a board design that will include some FPGA prototyping > >capability in addition to other required functions. There will probably > >be multiple FPGA's, two or four perhaps, most likely Xilinx Virtex-E. > >Perhaps also some FPGA expansion capability either by populating more > >FPGA's or by a mezzanine card. > > > >Anybody got any good pointers to implementing an interconnect bus > >between the FPGA's ? I guess there are two possibilities - > > > >1. Each FPGA contains a number of individual modules that are complete > >in themselves and communicate with each other within each FPGA and also > >with the other FPGA > > > >2. Resources are shared between FPGA's to allow larger designs to be > >implemented. > > > >Thanks, > > > >Regards, Craig > > Check out Synplicity Certify > http://www.synplicity.com/products/certify.html. It is exactly for > partitioning a large design into multiple FPGAs. You can even get > Syplicity to optimize it for your board. > > Muzaffer Kal > > http://www.dspia.com > ASIC/FPGA design/verification consulting specializing in DSP algorithm implementationsArticle: 41358
"Peter Alfke" <peter.alfke@xilinx.com> schrieb im Newsbeitrag news:3CA0AE88.6324D106@xilinx.com... > If you want four phases of a 50 MHz clock, you need not go higher than 100 MHz, > since a 180 degree shift is just an inversion, and 270 is 90 inverted. But only if you have a nice 50% duty cycle. -- MfG FalkArticle: 41359
Thanks - this looks interesting, I hadn't seen it until now. Christopher Saunter wrote: > > Craig McAdam (craig.mcadam@ntlworld.com) wrote: > > : Anybody got any good pointers to implementing an interconnect bus > : between the FPGA's ? I guess there are two possibilities - > > : 1. Each FPGA contains a number of individual modules that are complete > : in themselves and communicate with each other within each FPGA and also > : with the other FPGA > > If you are following this approach and manually partitioning different > blocks into different chips, Xilinx appnote 234 (SelectLink comms) may be > of interest for Virtex / E series chips - I'm looking at it at the moment, > and it uses various virtex resources to provide a 'virtual fifo' between > two devices - data writen into the fifo on chip 1 appears in the fifo on > chip 2. The core generator takes care of all signalling etc, leaving you > to design a suitable PCB. > > This should suit what I am doing very well, as it processes data in > chunks, passing chunks between different blocks in a unidirectional flow. > I guess these 'SelectLink' channels are less suitable for designs such as > processors where data is flying all over the place, with a very low > latency requirement. > > Cheers, > Chris Saunter > (who is wondering why so many Xilinx components are prefaced with > 'Select'...)Article: 41360
"Mik e Payne" <halstoninaustin@yahoo.com> schrieb im Newsbeitrag news:b1946105.0203251449.4f439c23@posting.google.com... > Falk, > > to fix my grounding issues. There's not many more places I can solder > a wire to. ;-) How do you measure these "ugly" signals? At least you should use a 10:1 probe with a short (<1 inch) ground wire, connected close to the ground of the CPLD. Set up a small test circuit inside the CPLD. Make a 4 bit counter and connect the MSB to one output to the SRAM (data or address bus). Of cource, set Chip Select high to make the SRAM-IOs tristate. Then you have a good testsignal on your CPLD that you can watch (and evaluate) easyly. -- MfG FalkArticle: 41361
--------------9AB6393BC1015702C5091292 Content-Type: text/plain; charset=iso-8859-1; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 8bit There is a 200+ page reliability report on the web at http://www.xilinx.com/products/qa_data/relreprt.pdf start by looking at pages 10 and 19 Happy reading :-) BTW, I found this by going to the public Xilinx website and using its search facility to look for "reliability report". Simple, isn't it. Peter Alfke, Xilinx Applications ======================================= vlad@comsys.ntu-kpi.kiev.ua wrote: > Hi All , > Where can I find information about numerical characteristic of failure > rate of Xilinx Óhips(Spartan2, Virtex series)? This information is > needed for calculation reliability index of entire device. > > -- > Best regards, > Vladislav Vasilenko > Hardware engineer. National Technical University of Ukraine > > mailto:vlad@comsys.ntu-kpi.kiev.uaArticle: 41362
Hi I have built myself a ByteblasterMV cable according to the schematic in the BytblasterMV manual and a small PCB with an EPM7064S mounted on it. Running the board and Byteblaster on 5 Volts I could examine the chip but when running verify directly after it discovered somewhere between 300-3000 errors and also I could not get the blankcheck to pass although the chip is brand new. Then I started looking for errors everywhere and finally I got desperate changed the supply voltage. I started by raising the voltage to around 5.5 V and it didn't work at all then I lowered the voltage to 4.5 Volts and everything worked perfectly. Increasing the supply voltage above 4.7 Volts and the errors start to come back. It's great that I can program the chip but I would prefer if it worked at 5 Volts like its supposed to. After the chip is programmed its no problem to increase the supply voltage up to 5 Volts again. The PCB on which the EPM7064S is mounted is basically a card with pinheaders for all pins on the chip and a few decoupling caps. Any help is greatly appreciated ArbitraryArticle: 41363
Arbitrary wrote:
> Increasing the supply voltage above
> 4.7 Volts and the errors start to come back. It's great that I can program
> the chip but I would prefer if it worked at 5 Volts like its supposed to.
Check that you used a 74HC244 buffer.
^^
Your symptoms are consistent with
a 3.3V only buffer.
--Mike Treseler
Article: 41364
Ken,
Glad you agree. I do use SRL16's quite a bit in my control logic, but as you did in
your UART state machine, they get initialized by an external event rather than by the
FPGA configuration (in otherwords, I always include a mechanism for recharging the
proper state) so that any illegal conditions will self correct after some interval.
As for one-hots, I use the terminal state to force a reset on the entire state machine
rather than closing the loop to feed the end state back to the beginning. This has the
advantage of also recovering from any upsets, where the traditional one-hot can get into
a continous series of illegal states.
The SRL16s are also handy when it comes to TMR (triple mode redundancy), since the
individual state machines are small. In that case, the voting circuit can be put in the
feedback loop so that any upsets that are not common to two or more of the machines
don't get propagated back in. With the SRL16, this redundancy is fairly cheap because
the state machines are small.
Ken Chapman wrote:
> Dear Ray,
>
> I agree that a really safe design should also consider upsets. My tech Xclusive on
> the subject of resets in designs is very much about safe design techniques. The
> whole concept of a one-hot state machine is an issue if you need to trap the cases
> of 'n-hot' and 'cold states'. In these cases I would favour an encoded state machine
> (not that many people carry out full illegal state analysis on those either).
>
> In my design for a UART state machine described in part 2 of my TechX, I
> deliberately design the state machine to go 'cold' at the end of processing a
> character. The next start bit on the serial line is then used to inject the next
> 'hot' state. In this way, any induced error can be made to be short lived.
>
> The efficiency offered by the SRL16E could also be exploited to provide redundancy.
> 3 state machines working in parallel with a majority voting system for each output
> control bit (a LUT3) would be nice. In this way, we do not have to tolerate the
> error condition at all.
>
> Seems like we have got away from LFSR counters a bit, but a good thread anyway.
>
> Regards,
>
> Ken
>
> Ray Andraka wrote:
>
> > I agree, the SRL16 is a wonder drug. I don't however like to use it as a closed
> > loop state machine as described by Ken because such a design will not self
> > recover in the event of an upset. The SRL16 only gets initialized on
> > configuration, so if for some reason you get an upset (and in the .15 micron it
> > does sometimes happen), your state machine carries that upset state bit until
> > the device is reconfigured. In my book, that is poor design practice. As soon
> > as you add the logic to detect the illegal states, the size gets considerably
> > larger (it may be more advantageous to use TMR here).
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 41365>> >> Subject: Parallel Cable III/IV >> >> These JTAG pods have attachments called "flying leads", where end >> #1 is a fixed connector to plug into the pod (i.e., JTAG row of pins) >> and >> end #2 is the actual flying leads to connect to the target hardware. >> >> That's great for prototype & engineering development, but for >> production, the actual >> flying leads @ end #2 can easily be mis-placed by technicians on the >> assembly >> line. >> >> Is there any readily available, fixed-connection cables (and mating >> sockets) for the Xilinx-programming-pod-2-target-hardware connection? >> Or is that some tooling that every customer just has to make on their >> own >> w/ catalog parts from Newark, Digi-Key, etc., ? >------------------------------------------------------- > I have some jumpers with a 9-pin connector at each end that came with XChecker cable packages. I'm not sure if they're available separately. In a pinch, you can just plug the flying lead ends into the pod where they should stay put, leaving the single 9-pin body to plug into your device. -- Caleb Hess hess@cs.indiana.eduArticle: 41366
Synplify has a feature for statemachine generation which allows you to specify a "safe" generation of the state machine logic. Upsets leading to illegal states will result in eventually (within a few clocks) transitioning to the reset state. The overhead is quite low even for one-hot state machines. Ken Chapman wrote: > Dear Ray, > > I agree that a really safe design should also consider upsets. My tech Xclusive on > the subject of resets in designs is very much about safe design techniques. The > whole concept of a one-hot state machine is an issue if you need to trap the cases > of 'n-hot' and 'cold states'. In these cases I would favour an encoded state machine > (not that many people carry out full illegal state analysis on those either). > > In my design for a UART state machine described in part 2 of my TechX, I > deliberately design the state machine to go 'cold' at the end of processing a > character. The next start bit on the serial line is then used to inject the next > 'hot' state. In this way, any induced error can be made to be short lived. > > The efficiency offered by the SRL16E could also be exploited to provide redundancy. > 3 state machines working in parallel with a majority voting system for each output > control bit (a LUT3) would be nice. In this way, we do not have to tolerate the > error condition at all. > > Seems like we have got away from LFSR counters a bit, but a good thread anyway. > > Regards, > > Ken > > > > Ray Andraka wrote: > > >>I agree, the SRL16 is a wonder drug. I don't however like to use it as a closed >>loop state machine as described by Ken because such a design will not self >>recover in the event of an upset. The SRL16 only gets initialized on >>configuration, so if for some reason you get an upset (and in the .15 micron it >>does sometimes happen), your state machine carries that upset state bit until >>the device is reconfigured. In my book, that is poor design practice. As soon >>as you add the logic to detect the illegal states, the size gets considerably >>larger (it may be more advantageous to use TMR here). >> >Article: 41367
altera's byteblaster did include the 74hc244. the byteblastermv consists of an 74ls244. the schematic should be ok and it should work fine with the ls part. I assume that your cable is more than 20cm in length. shorten the cable and it will work fine.Article: 41368
Both, the PC and the Board have to be on the same potential. This can be achieved by a thick 1mm^2 cable from the PC chassis to the power supplies powering your board. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com Arbitrary wrote: > > Hi > I have built myself a ByteblasterMV cable according to the schematic in the > BytblasterMV manual and a small PCB with an EPM7064S mounted on it. Running > the board and Byteblaster on 5 Volts I could examine the chip but when > running verify directly after it discovered somewhere between 300-3000 > errors and also I could not get the blankcheck to pass although the chip is > brand new. Then I started looking for errors everywhere and finally I got > desperate changed the supply voltage. I started by raising the voltage to > around 5.5 V and it didn't work at all then I lowered the voltage to 4.5 > Volts and everything worked perfectly. Increasing the supply voltage above > 4.7 Volts and the errors start to come back. It's great that I can program > the chip but I would prefer if it worked at 5 Volts like its supposed to. > After the chip is programmed its no problem to increase the supply voltage > up to 5 Volts again. The PCB on which the EPM7064S is mounted is basically a > card with pinheaders for all pins on the chip and a few decoupling caps.Article: 41369
I'm glad this point has been brought up because I wanted to make an averaging filter using SRLs but I'm worried about what will happen if the Xilinx gets reset. The accumulator will reset to zero, but the values in the SRL delay line won't. That means that after a reset, the output of the averaging filter will be offset by the sum of all the values in the SRL delay lines. How should I clear out all the data after a reset? -Kevin "Ken Chapman" <chapman@xilinx.com> wrote in message news:3CA0B2AB.78F52ED6@xilinx.com... > Dear Ray, > > I agree that a really safe design should also consider upsets. My tech Xclusive on > the subject of resets in designs is very much about safe design techniques. The > whole concept of a one-hot state machine is an issue if you need to trap the cases > of 'n-hot' and 'cold states'. In these cases I would favour an encoded state machine > (not that many people carry out full illegal state analysis on those either). > > In my design for a UART state machine described in part 2 of my TechX, I > deliberately design the state machine to go 'cold' at the end of processing a > character. The next start bit on the serial line is then used to inject the next > 'hot' state. In this way, any induced error can be made to be short lived. > > The efficiency offered by the SRL16E could also be exploited to provide redundancy. > 3 state machines working in parallel with a majority voting system for each output > control bit (a LUT3) would be nice. In this way, we do not have to tolerate the > error condition at all. > > Seems like we have got away from LFSR counters a bit, but a good thread anyway. > > Regards, > > Ken > > > > Ray Andraka wrote: > > > I agree, the SRL16 is a wonder drug. I don't however like to use it as a closed > > loop state machine as described by Ken because such a design will not self > > recover in the event of an upset. The SRL16 only gets initialized on > > configuration, so if for some reason you get an upset (and in the .15 micron it > > does sometimes happen), your state machine carries that upset state bit until > > the device is reconfigured. In my book, that is poor design practice. As soon > > as you add the logic to detect the illegal states, the size gets considerably > > larger (it may be more advantageous to use TMR here). >Article: 41370
Jon Elson <jmelson@artsci.wustl.edu> wrote in message news:<3C9FB450.14E8EB9C@artsci.wustl.edu>... > Mik e Payne wrote: > > > Falk, > > > > Thanks for your reply. I am using short (less than 3") wires for the > > power and ground. I've got decoupling caps on both the SRAM and 8051. > > I'm using a 7805 5V regulator to supply the 5V to the SRAM/8051. I've > > got decoupling caps on the input (22uf) and the output (10uf and .1uf) > > of the 7805. I've run 4 wires from the ground of the 7805 to 4 of the > > decoupling capacitors on the CPLD to help my grounding issues. These > > are in addition to several other wires I have creating a common ground > > between the 5V and 3.3 volt logic. I'm using the thickest wire I can > > that will fit through the PCB holes. I'm not sure what else I can do > > to fix my grounding issues. There's not many more places I can solder > > a wire to. > > I'm not exactly clear on what the CPLD is mounted on. Is it on the > Avnet evaluation board? If so, then the power supply bypassing is > all by etched traces already on the board? The CPLD is in a 144pin TQFP package mounted on the evaluation board. The I/O pins from the CPLD go to a rectangular area on the evaluation board. The center of this rectangular area is a grid of PCB thru holes for prototyping. This is where I've placed my 8051, SRAM, 7805 and a 12MHz osc. for the 8051. The outter row of PCB holes are connected to the CPLD I/O pins. The evaluation PCB is only 2 sided with no ground plane or ground fills. You can hold it to a light and see the traces on the other side. I'm sure this is not helping my problem. If all that is so, then > bypassing of the CPLD should be adequate. I'e done a number of > XC9572 designs and not had any surprises with power decoupling, > the chips are quite well behaved. I would expect the CoolRunner should > be the same. But, there is the 5/3.3V interface that could be messing > things up. Could the 3.3 V outputs from the CoolRunner be causing the > 8051 or SRAM to go haywire? > > You mentioned a 32 KHz clock, but the VHDL looks pretty combinatorial, > not clocked. So, where does CLK0 go, and what does it do? If you are > not using the clock in your equations, then don't provide it to an input > of the chip. No telling what it has configured that pin for if it is not > specified in the equations. > > Jon There is a jumper on the evaluation board to disable the 32Khz clock going to CLK0. I disabled this and nothing changed. Thanks for your help. MikeArticle: 41371
Falk, I've got the Keil monitor programmed into the interal flash of the AT89S8252. I can use the dScope program to read/write to the SRAM. I can write to some locations so I've put a small looping program that continuously writes 0x00 to location 0x00ff. I run this program and then us a Tek 2246 100Mhz scope to examine the signals. The write to SRAM will fail if 6 or more of the low address/data lines have to transition from a '1'(for the low address) to a '0' (for the data to write). The failure is that the data ends up getting latched in the low address space. So, a write of 0x24 to location 0x20ff, it ends up writting 0x24 to location 0x2024. Knowing this, I assumed that when low address/data lines transition from a '1' to a '0' it causes a glitch and the ALE signal bounces causing the data to get latched in the low address space. I've looked at the ALE signal (at the CPLD pin and the 8051 pin) and it looks good. I put a 15pf cap between ALE and ground to see if it would help and it did not. Signals going into the CPLD look good. Signals comming out of the CPLD have noise, I see spikes and ringing on those signals. Thanks for your help, Mike "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:<a7qedt$n4bd4$2@ID-84877.news.dfncis.de>... > "Mik e Payne" <halstoninaustin@yahoo.com> schrieb im Newsbeitrag > news:b1946105.0203251449.4f439c23@posting.google.com... > > Falk, > > > > to fix my grounding issues. There's not many more places I can solder > > a wire to. > > ;-) > > How do you measure these "ugly" signals? At least you should use a 10:1 > probe with a short (<1 inch) ground wire, connected close to the ground of > the CPLD. > Set up a small test circuit inside the CPLD. Make a 4 bit counter and > connect the MSB to one output to the SRAM (data or address bus). Of cource, > set Chip Select high to make the SRAM-IOs tristate. Then you have a good > testsignal on your CPLD that you can watch (and evaluate) easyly.Article: 41372
Kevin Neilson wrote: > I'm glad this point has been brought up because I wanted to make an > averaging filter using SRLs but I'm worried about what will happen if the > Xilinx gets reset. The accumulator will reset to zero, but the values in > the SRL delay line won't. That means that after a reset, the output of the > averaging filter will be offset by the sum of all the values in the SRL > delay lines. How should I clear out all the data after a reset? > -Kevin > The only practical choice (short of reconfiguring the device !) is to flush the SRL16s out, by shifting in zeros. Takes 16 clock ticks. Peter Alfke, Xilinx ApplicationsArticle: 41373
Mik e Payne wrote: > > Falk, > > I've got the Keil monitor programmed into the interal flash of the > AT89S8252. I can use the dScope program to read/write to the SRAM. I > can write to some locations so I've put a small looping program that > continuously writes 0x00 to location 0x00ff. I run this program and > then us a Tek 2246 100Mhz scope to examine the signals. > > The write to SRAM will fail if 6 or more of the low address/data lines > have to transition from a '1'(for the low address) to a '0' (for the > data to write). The failure is that the data ends up getting latched > in the low address space. So, a write of 0x24 to location 0x20ff, it > ends up writting 0x24 to location 0x2024. Knowing this, I assumed > that when low address/data lines transition from a '1' to a '0' it > causes a glitch and the ALE signal bounces causing the data to get > latched in the low address space. I've looked at the ALE signal (at > the CPLD pin and the 8051 pin) and it looks good. I put a 15pf cap > between ALE and ground to see if it would help and it did not. > > Signals going into the CPLD look good. Signals comming out of the > CPLD have noise, I see spikes and ringing on those signals. There were comments before about bounce problems on coolrunner. Add in an external HC573 ALE latch, and check it's now 100%. Add in a HC688 ( 8==8 ), and use the compare out as a Coolrunner quality check. You can then try various things, until the HC688 gives a PASS. Try a falling edge latch, or even an internal delay line noise filter... eg A delay line on .CE disables the CLK outside a window Try an Atmel ATF1508 ( less MC, but fits more in a mcarocell.. ) -jg -- ======= 80x51 Tools & IP Specialists ========= = http://www.DesignTools.co.nzArticle: 41374
Sławomir Balon wrote: > > Hi! > Is there any idea for multiplying clock in max7000 devices? > thanx > Slawek By how much ? Clock doubling is doable with XOR + Register. We have done burst multiplies in ATF15xx, where a faster but not accurate OSC is built using foldback delays and then gated from a lower signal. -jg
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