Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 106500

Article: 106500
Subject: Re: synthesis intelligence of quartus regarding range of values
From: "John_H" <newsgroup@johnhandwork.com>
Date: Mon, 14 Aug 2006 16:18:34 GMT
Links: << >>  << T >>  << A >>
"homoalteraiensis" <fpgaengineerfrankfurt@arcor.de> wrote in message 
news:1155228893.682178.172540@p79g2000cwp.googlegroups.com...
>I got a "circuit", which is doing integer division with large values. I
> instantiated a MEGAWIZ-devider with currently 48bits / 16 Bits, which
> ist fed with some more bits (done be shifting) in order to obtain a
> result with a higher accuracy than 1 in one step without proceeding the
> remainder.
>
> E.g. I am shifting with 10 Bits and fill the rest with zero:
> input <= "0000" & Value (33 downto 0) & "0000000000"
>
> I recognize, that Quartus is obviously capable of synthesizing away to
> signals / paths in the devider which are not needed.
>
> Now, what is about the range of values ? In my design, the A / B have a
> certain relationship, so that the result can never exceed 18 bits,
> whereby the vector of the result (devider out) has of course 48 bits.
>
> Is it of an advantage if the range of values is restricted?
>
> Currently I am cutting away the first bits, which will always be zero.
> s there anything more, I can do, to keep the design small ?


If the result never exceeds 18 bits, I'd suggest writing the routine 
yourself.  If your device supports an add/subtract structure, you need 18 
stages to get 18 bits of result while the 48 stages produced with the 
MegaWizard might be more of a problem to optimize.

By having the dividend start off in the correct range relative to the 
divisor, you only need 34 bits divided by 18 bits to give you your 
consistent 18 bit result.  Any more bits just change add fractional bits to 
the remainder.

If you could specify whether either value is signed and what the dividend 
and divisor ranges are, I'd happily email you an excel spreadsheet showing 
how the equations come together for the add/sub stages.  Also please verify 
that you don't need the remainder. 



Article: 106501
Subject: Re: synthesis intelligence of quartus regarding range of values
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 14 Aug 2006 09:21:25 -0700
Links: << >>  << T >>  << A >>
Ah ha,

I knew that somewhere the ranges had to be described.

Since I don't code in VHDL, I didn't know.

Thanks.  Mystery solved.

Austin

Article: 106502
Subject: Re: synthesis intelligence of quartus regarding range of values
From: "John_H" <newsgroup@johnhandwork.com>
Date: Mon, 14 Aug 2006 16:24:13 GMT
Links: << >>  << T >>  << A >>
"John_H" <newsgroup@johnhandwork.com> wrote in message 
news:un1Eg.7568$oa1.3750@news02.roc.ny...
> By having the dividend start off in the correct range relative to the 
> divisor, you only need 34 bits divided by 18 bits to give you your 
> consistent 18 bit result.  Any more bits just change add fractional bits 
> to the remainder.

That should be "34 bits divided by 16 bits to give you your consistent 18 
bit result" 



Article: 106503
Subject: Re: JOP as SOPC component
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Mon, 14 Aug 2006 18:56:58 +0200
Links: << >>  << T >>  << A >>
>>>> You almost never want to have a fixed number of wait states but want to simply have the Avalon slave provide a wait request 
>>>> output and tell Avalon that by specifying that in the PTF file.
>>>
>>> Completely agree. When not writing and reading too many posts
>>> I'm working on that version of the SRAM interface. It was just
>>> a quick start as shown in the Quartus manual.
>>
>> BTW (to KJ): Do you have this type of Avalon slave
>> for an SRAM? Would save some time and errors for me ;-)
>>
> No, over the past several years my use of async SRAMs has gone to 0 even though I used to use them quite heavily.  They've been 
> replaced by internal
> I'm assuming that you've checked and that Altera didn't toss one in as a MegaCore?  Too bad.

Their core for the (older) NIOS boards just uses the tri-state
bridge .PTF approach - no VHDL

>
> Oh well, I'll stop posting and let you get back to work.
> KJ

Ok, I have now two versions of the SRAM interface: the plain
PTF version and the VHDL version (with I/O registers at
the FPGA pins to access a 15ns SRAM in two cycles at 100 MHz,
and the nwr with the neg. clock to save one cycle on write).

Here are some performance numbers of this JOP/SRAM
interface on an embedded benchmark. It measures iterations/s
and therefore higher numbers are better. All versions are clocked
at 100 MHz, 4 KB instruction cache and 512 Byte stack cache.
FPGA is Cyclone EP1C6-6, Memory is 32-bit SRAM 15ns. The only
difference is the memory interface.

SimpCon: 16,633
Avalon (PTF version): 14,015
Avalon (VHDL version): 13,920

So for me, the additional latency cycle(s) and not having
the early ack information for the CPU pipeline degrades
JOP's performance. Perhaps some Avalon specialist can do better.

However, it is compensated by the many peripherals that are
now just a mous click away ;-)

Martin




Article: 106504
Subject: Re: consistancy in synthesis/ simulation model
From: "KJ" <kkjennings@sbcglobal.net>
Date: Mon, 14 Aug 2006 17:00:50 GMT
Links: << >>  << T >>  << A >>

"Mike Treseler" <mike_treseler@comcast.net> wrote in message 
news:4kbjdbFb9mhbU1@individual.net...
>> post-route sim is an attempt to give the warm fuzzies because of 
>> inadequate or incorrect static timing analysis or incomplete testbench 
>> coverage.
>
> A post-route sim is a final check-off item to
> prove that synthesis and my design rules
> have worked for at least one case.

I agree.  To the extent that one has high quality functional test coverage 
and has performed static timing analysis, post-route sim 'should be' just a 
formality final check-off item, something that needs to be done but doesn't 
provide much value (because of the above mentioned 'high quality....')

If you don't have that high quality test coverage or don't properly perform 
static timing analysis in the first place then post-route sim's value might 
increase dramatically but is still inferior to just doing the 'high 
quality...' work in the first place.

> I keep it out of the edit, sim, edit loop
> because it is slow to run, adds
> little to timing or functional coverage,
> and rarely fails.
>
Yep, start it up on Friday afternoon and see if it has completed on Monday 
morning.

> It is more efficient to work on coverage
> at full speed.

Tons more efficient ('mucho kilograms' for those outside the US)

> An interesting measurement
> is to sim the clock frequency outside the
> specified range to see if there are
> any logical limits built into the design.
>

Yep, and more specifically not just a single out of range frequency but run 
it at several different frequencies both in and out of the design range to 
catch those logical limits that you don't quite realize are in there.

KJ 



Article: 106505
Subject: Re: RocketIO MGT Tile/Column Question
From: "MM" <mbmsv@yahoo.com>
Date: Mon, 14 Aug 2006 13:04:52 -0400
Links: << >>  << T >>  << A >>
Table 7-3 is in the RocketIO manual (UG076 v3.0, May 23, 2006)...

/Mikhail


"Peter Mendham" <petermendham@NOCANNEDMEAT.computing.dundee.ac.uk> wrote in
message news:ebq05h$1h2$1@dux.dundee.ac.uk...
> Dear all,
>
> I am struggling to find the information I need from the Xilinx
> datasheet, perhaps someone could provide me with some pointers.  I am
> working with a Virtex 4 FX100 in a FF1152 package.  I have 20 MGTs to
> play with, arranged in 10 tiles numbered 101, 102, 103, 105, 106, 109,
> 110, 112, 113 and 114.  These are further arranged into columns.  There
> must be a simple method for determining which tiles are in which
> columns, but I haven't worked it out.  Perhaps a related problem is that
> I have no idea where the odd numbering scheme comes from.  Any help
> would be greatly appreciated.
>
> TIA,
>
> -- Peter



Article: 106506
Subject: Re: JOP as SOPC component
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Mon, 14 Aug 2006 19:21:58 +0200
Links: << >>  << T >>  << A >>
> Here are some performance numbers of this JOP/SRAM
> interface on an embedded benchmark. It measures iterations/s
> and therefore higher numbers are better. All versions are clocked
> at 100 MHz, 4 KB instruction cache and 512 Byte stack cache.
> FPGA is Cyclone EP1C6-6, Memory is 32-bit SRAM 15ns. The only
> difference is the memory interface.
>
> SimpCon: 16,633
> Avalon (PTF version): 14,015
> Avalon (VHDL version): 13,920
>
some additional numbers from the Altera DE2 board with
Cyclone II at 100 MHz with SDRAM and using on-chip
memory (the EP2C35 is big enough to run the benchmark
in on-chip memory).

Avalon SDRAM: 7,288
Avalon on-chip memory: 15,769

The performance issue with the SDRAM is clear. Just needs
some more caching to get a big (8 MB) memory with
acceptable performance ;-)
However, even the fast on-chip memory Avalon solution is
slightly slower than the two cycle SRAM connected via
SimpCon.

Martin 



Article: 106507
Subject: Re: RocketIO MGT Tile/Column Question
From: "Jim Wu" <jimwu88NOOOSPAM@yahoo.com>
Date: 14 Aug 2006 10:35:28 -0700
Links: << >>  << T >>  << A >>
ADEPT shows the MGT map in Excel. The tool is freely available at
      http://home.comcast.net/~jimwu88/tools/adept/

Below is what you need to do:
* Select and load Device
* View->Display MGT
* Excel->Show MGT Map in Excel

HTH,
Jim


Peter Mendham wrote:
> Dear all,
>
> I am struggling to find the information I need from the Xilinx
> datasheet, perhaps someone could provide me with some pointers.  I am
> working with a Virtex 4 FX100 in a FF1152 package.  I have 20 MGTs to
> play with, arranged in 10 tiles numbered 101, 102, 103, 105, 106, 109,
> 110, 112, 113 and 114.  These are further arranged into columns.  There
> must be a simple method for determining which tiles are in which
> columns, but I haven't worked it out.  Perhaps a related problem is that
> I have no idea where the odd numbering scheme comes from.  Any help
> would be greatly appreciated.
> 
> TIA,
> 
> -- Peter


Article: 106508
Subject: Spartan3 dev board... will USB keyboard work?
From: aiiadict@gmail.com
Date: 14 Aug 2006 10:50:39 -0700
Links: << >>  << T >>  << A >>
Hello,

Will a USB keyboard work with the Spartan3 dev board?

I know that USB keyboards will work with a PS2 connector
on a desktop computer...  all you need is a USB to PS2
adaptor plug..

anyway, one's on it's way and I'll find out then, I guess.


Thanks!

Rich


Article: 106509
Subject: Error building mpmc2
From: "Jeremy Price" <jpriceelvis.removeme.andme@gmail.com>
Date: Mon, 14 Aug 2006 10:58:40 -0700
Links: << >>  << T >>  << A >>
Hello all,

In my quest to evaluate multicast performance on the ML403 board I have downloaded the mpmc2 example. I am attempting to build the ml403_ddr_idpoc_100mhz_gsrd on winXP and it bombs out with the following error: Running DRC Tcl procedures for OPTION IPLEVEL_DRC_PROC... ERROR:MDT - No Bus with instance name cdmac_to_gmac_0 found ERROR:MDT - No Bus with instance name gmac_to_cdmac_0 found

Anyone else seen this? Any pointers as to how to fix it?

thanks

Article: 106510
Subject: Re: JOP as SOPC component
From: "KJ" <kkjennings@sbcglobal.net>
Date: Mon, 14 Aug 2006 18:01:48 GMT
Links: << >>  << T >>  << A >>

"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> wrote in message 
news:44e0b13c$0$11352
> However, even the fast on-chip memory Avalon solution is
> slightly slower than the two cycle SRAM connected via
> SimpCon.
>

Well now THAT is incredibly surprising since the on-chip memory should be 
giving you 0 wait state, 0 latency performance (i.e. WaitRequest should 
always be low when accessing memory).  That would seem to point to either 
some issue that comes up every now and then in your 'CPU to Avalon' bridge 
master interface logic or something equally odd inside the Avalon fabric 
itself connecting the CPU to the memory.

I'd be interested to hear what you find.

KJ 



Article: 106511
Subject: Re: Error building mpmc2
From: "MM" <mbmsv@yahoo.com>
Date: Mon, 14 Aug 2006 14:11:39 -0400
Links: << >>  << T >>  << A >>
I've seen something similar to this, but I had somewhat modified the project
before trying to build it, so I was kind of expecting errors... I don't
remember precisely what was the problem, but I guess you should be able to
figure it out by looking at the MHS file and possibly at MPMC2 MPD file...


/Mikhail


"Jeremy Price" <jpriceelvis.removeme.andme@gmail.com> wrote in message
news:ee9dae7.-1@webx.sUN8CHnE...
> Hello all,
>
> In my quest to evaluate multicast performance on the ML403 board I have
downloaded the mpmc2 example. I am attempting to build the
ml403_ddr_idpoc_100mhz_gsrd on winXP and it bombs out with the following
error: Running DRC Tcl procedures for OPTION IPLEVEL_DRC_PROC... ERROR:MDT -
No Bus with instance name cdmac_to_gmac_0 found ERROR:MDT - No Bus with
instance name gmac_to_cdmac_0 found
>
> Anyone else seen this? Any pointers as to how to fix it?
>
> thanks



Article: 106512
Subject: [Xilinx] MIG V1.6 Reduced max Speed for DDR2 controllers ??
From: Markus Meng <meng.engineering@bluewin.ch>
Date: Mon, 14 Aug 2006 20:23:42 +0200
Links: << >>  << T >>  << A >>
Hi all,

working on DDR2 controllers generated with MIG V1.6 I did
notice the reduction in max speed for "Direct Clocking Mode"

Up to now a speedgrade -11 LX60 Virtex-IV device did support up to
267MHz in Clock Synchronous mode.

Using the MIG V1.6 that has some fixes this technique can
only be used for ~210 MHz, a reduction of 20% in speed.

I haven't found any information on the Xilinx Web-Site
why this is so.

I get the impression that from the beginning on up to now, Xilinx
did reduce the max speed for their devices from time to time.

The problem I face, is that we have boards that require at
least 250 MHz in Direct Clocking Techniques Mode, and I really
would like to understand, why Xilinx did this reduction in
terms of max speed using a 512MBit DDR2 from Micron -37.

Any Idea?

Best Regards
Markus

BTW the post layout simulation on the DDR2 controllers with
a build in Testbench is not working properly. On the Data Mask
pins after calibration, these signals drive XX and the comparison
fails. Seems to be in the Sim Library ...

Article: 106513
Subject: Any interest in a v8 uRISC/Arclite clone?
From: "radarman" <jshamlet@gmail.com>
Date: 14 Aug 2006 11:42:32 -0700
Links: << >>  << T >>  << A >>
I have been working with a group that reverse-engineered the
PureDigital "one-time-use" cameras based on a chipset from SMaL Inc.
The CPU core was licensed from Arc Internation, who bought the IP from
vAutomation. It is presently called the Arclite, but was previously
sold as the v8 uRISC.

In the process of disassembling the firmware for the camera, the group
modified the WLA assembler and linker, and wrote a new disassembler and
simulator for the v8 uRISC architecture. With all these tools handy, I
decided to rewrite the v8 uRISC core from scratch using documentation
available on the web. As far as I know, there should be no legal issues
with the core, but I can't guarantee that. I plan to release my core
with a different name to avoid trademark issues, but I haven't selected
a name as yet.

The core is written in VHDL, and should be '93 compliant. I have pretty
well debugged the ALU and microcode, but I haven't had a chance to test
the interrupt system yet.

Although the core does strive to be 100% compatible with the orginal v8
ISA, I have added some enhancements (which can be disabled via
generics) such as the ability to allow RSP instruction to actively
place the stack pointer, instead of merely resetting it, and the
ability to do auto-increments on indexed load & store instructions. In
addition, I replaced the unused USR and USR2 instructions with a DBNZ
(Decrement, and Branch if Not Zero) and MUL (Multiply) instruction.
Lastly, I made the interrupt mask immediately available to the core
through to unmapped opcodes SMSK and GMSK, which transfer the contents
of R0 to the mask, and vice-versa.

This was the first CPU I've developed in VHDL, and may not be 100%
optimal - so I could use some extra eyes to suggest performance
enhancements or look for bugs. As it is, the core will run at > 112 MHz
(by itself) on an Altera Cyclone II 2C35-C6. I have a small SoC design
with UART, LCD interface, 7-segment display interface, 32kB RAM, 8kB
ROM, and a 16-bit timer running on an Altera DE2 board at > 75 Mhz. The
modules are connected in a wired-or configuration, where they only
drive data when selected to eliminate muxing.

I realize there are a plethora of 8-bit microprocessor cores floating
around, but I would be curious to know if there is any interest in this
CPU. I had planned to release it to Opencores.org under the GPL. I
understand there was some interest in porting gcc to this processor,
but it looks like it never happened - so at the moment, there is only
the HiTech compiler, or raw assembly. However, the current open-source
assembler is based on WLA, which has a lot of nice features.

If there is any interest, I'll start trying to package the
documentation, which presently exists in the form of notebooks and
Excel spreadsheets.


Article: 106514
Subject: Re: Lattice Blogs
From: "bart" <bart.borosky@latticesemi.com>
Date: 14 Aug 2006 11:42:33 -0700
Links: << >>  << T >>  << A >>
Ben Popoola wrote:
> What about small order quantities in the U.K?

Mouser ships worldwide and has stated that their shipping time is very
good to Europe and Asia.
http://www.mouser.com/latticesemi/

If you do try Mouser for your shipment for the U.K., please let me know
how your experience is, how long it took, etc.


Thanks!
Regards,
Bart Borosky, 
Manager, Online Marketing
Lattice Semiconductor


Article: 106515
Subject: Crystal input for FPGA
From: shrutisumit@gmail.com
Date: 14 Aug 2006 12:03:38 -0700
Links: << >>  << T >>  << A >>

I am posting this just as a suggestion for future FPGAs. It would be
nice if a crystal can be connected to FPGA to provide clock instead of
a oscillator. The cost difference between an oscillator and a crystal
is significant. A 50MHz oscillator (2.5v) fro S3E costs $3.27. A 100MHz
one is around $6. But all the crystals are less than $1. I have worked
with PIC microcontrollers in past and they have the option of
connecting both.

I may be missing something here or may be this is already solved in
some other way. I searched through Xilinx website but could not find
anything. Please let me know if there is an existing solutiuon.

Thanks
Sumit


Article: 106516
Subject: Re: Crystal input for FPGA
From: Tim Wescott <tim@seemywebsite.com>
Date: Mon, 14 Aug 2006 12:26:48 -0700
Links: << >>  << T >>  << A >>
shrutisumit@gmail.com wrote:

> I am posting this just as a suggestion for future FPGAs. It would be
> nice if a crystal can be connected to FPGA to provide clock instead of
> a oscillator. The cost difference between an oscillator and a crystal
> is significant. A 50MHz oscillator (2.5v) fro S3E costs $3.27. A 100MHz
> one is around $6. But all the crystals are less than $1. I have worked
> with PIC microcontrollers in past and they have the option of
> connecting both.
> 
> I may be missing something here or may be this is already solved in
> some other way. I searched through Xilinx website but could not find
> anything. Please let me know if there is an existing solutiuon.
> 
> Thanks
> Sumit
> 
If you're counting pennies like that, consider rolling your own crystal 
oscillator using one of the tiny logic inverters (M74VHC1GU04 or 
equivalent).  The inverter will cost pennies, the crystal will still be 
a buck, you'll still need the handful of parts you'd need with the PIC, 
and you'll still need the months of engineering time and hassle with 
purchasing and manufacturing to get and keep things at a rock-solid 
reliable level under all conditions and manufacturing variations.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

Article: 106517
Subject: Re: Embedded clocks
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 15 Aug 2006 07:51:45 +1200
Links: << >>  << T >>  << A >>
rickman wrote:
> Jim Granville wrote:
> 
>>  What we need is a CPLD like the Freescale RS08, or the SiLabs
>>C8051F41x - that works from 1.8V to 5.5V, and draws 1uA static Icc :)
>>  [ ATF1502BE draws 2.3uA, but needs two rails.... ]
> 
> 
> The Coolrunner XPLA3 parts are pretty good.  Other than not having
> schmitt trigger inputs, what don't you like about them?

I like their JTAG enable pin, so you don't have to loose valuable pins
for JTAG - but they are narrow Vcc operation, and only promise < 100uA,
and Xilinx do not have them on the on-line store, and are sparse
elsewhere, so have that NFND look about them....

How long is your product lifetime ?

>>Two Pin A : Bidirectional pins ( see 4046 ) Open Collector, Res Pullups,
>>Swings from GND to VthP, Nominally 50% duty cycle. Gates very well
>>Can VCO modulate.
> 
> 
> I don't get this one at all.  I looked up the 4046 but all descriptions
> I could find treat the VCO as a black box.  I am guessing that the two
> pins are driven with opposite polarity and the cap is grounded at one
> end or the other all the time.  So it would be charged like the one pin
> approach and then discharged like the one pin approach.  So this is a
> pair of the one pin drivers to give you 50/50 duty cycle?
> 
> This seems simple.  Any issues with startup? Does it need FFs anywhere
> to make it work without noise?  I would think that the lack of schmitt
> trigger inputs would require a FF.

Yes, normally it is simply a SR latch, with some logic to catch S=R=H.
When running, S,R cross their thresholds only briefly, to trigger the
other phase.

-jg


Article: 106518
Subject: Re: Crystal input for FPGA
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 15 Aug 2006 07:59:50 +1200
Links: << >>  << T >>  << A >>
shrutisumit@gmail.com wrote:

> I am posting this just as a suggestion for future FPGAs. It would be
> nice if a crystal can be connected to FPGA to provide clock instead of
> a oscillator. The cost difference between an oscillator and a crystal
> is significant. A 50MHz oscillator (2.5v) fro S3E costs $3.27. A 100MHz
> one is around $6. But all the crystals are less than $1. I have worked
> with PIC microcontrollers in past and they have the option of
> connecting both.
> 
> I may be missing something here or may be this is already solved in
> some other way. I searched through Xilinx website but could not find
> anything. Please let me know if there is an existing solutiuon.

XTAL osc were there, but removed many generations ago.

These days, you can get cheap SOT23 Osc from Linear/maxim, that
can clock FPGAs in many applications.

-jg


Article: 106519
Subject: Re: Crystal input for FPGA
From: "Peter Alfke" <peter@xilinx.com>
Date: 14 Aug 2006 13:29:21 -0700
Links: << >>  << T >>  << A >>
Been there, done that.
XC3000 had (has) two pins that wrap around a single-stage buffer, and
are meant to be connected to a xtal. Add a biaing resistor plus the
obligatory caps to form a Colpitts oscillator.
It was a support nightmare. Even if 99% of applications had no problem,
the remaining 1% drove us crazy. Too little gain, too much gain, too
low a frequency (32 kHz), too high a frequency (>100 MHz), doesn't
start at cold, bad pc-board layout, etc
Canned oscillators are made by experts, using exactly the best chip for
the particular frequency, and use the smallest amount of power. And
they are surprisingly cheap, far less than the $6 quoted in the posting
here.
You can even get a 312.5 MHz oscillator for a few dollars...(Sits in
every cellphone)
Never again will we put that driver into an FPGA !
Peter Alfke, Xilinx
PS: when I was at AMD, we second-sourced the 8051. Most of Intel's mask
revisions were caused by their oscillator circuit...
===================================


Article: 106520
Subject: Re: Spartan3 dev board... will USB keyboard work?
From: Mike Harrison <mike@whitewing.co.uk>
Date: Mon, 14 Aug 2006 20:36:31 GMT
Links: << >>  << T >>  << A >>
On 14 Aug 2006 10:50:39 -0700, aiiadict@gmail.com wrote:

>Hello,
>
>Will a USB keyboard work with the Spartan3 dev board?
>
>I know that USB keyboards will work with a PS2 connector
>on a desktop computer...  all you need is a USB to PS2
>adaptor plug..

These are not strictly USB keyboards. They are dual mode USB/PS2 keyboards that decide which
language to talk by detecting what they are plugged into. Assuming it is one of these, and the S3
hardware looks sufficiently like a real PS2 port, then it ought to work, no different from a real
PS2 keyboard. 

Article: 106521
Subject: Re: Crystal input for FPGA
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 15 Aug 2006 09:04:40 +1200
Links: << >>  << T >>  << A >>
Tim Wescott wrote:

> shrutisumit@gmail.com wrote:
> 
>> I am posting this just as a suggestion for future FPGAs. It would be
>> nice if a crystal can be connected to FPGA to provide clock instead of
>> a oscillator. The cost difference between an oscillator and a crystal
>> is significant. A 50MHz oscillator (2.5v) fro S3E costs $3.27. A 100MHz
>> one is around $6. But all the crystals are less than $1. I have worked
>> with PIC microcontrollers in past and they have the option of
>> connecting both.
>>
>> I may be missing something here or may be this is already solved in
>> some other way. I searched through Xilinx website but could not find
>> anything. Please let me know if there is an existing solutiuon.
>>
>> Thanks
>> Sumit
>>
> If you're counting pennies like that, consider rolling your own crystal 
> oscillator using one of the tiny logic inverters (M74VHC1GU04 or 
> equivalent).  The inverter will cost pennies, the crystal will still be 
> a buck, you'll still need the handful of parts you'd need with the PIC, 
> and you'll still need the months of engineering time and hassle with 
> purchasing and manufacturing to get and keep things at a rock-solid 
> reliable level under all conditions and manufacturing variations.

Good idea, but the FPGA will NOT like the sine drive - there are 1G 
variants, that ARE designed for Crystal Osc, [1GU04+1G14 in one package]
Philips have a couple, TI have one,
eg 74AUP1Z04

-jg


Article: 106522
Subject: Re: Crystal input for FPGA
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 14 Aug 2006 14:54:20 -0700
Links: << >>  << T >>  << A >>
All,

Nothing like failure to cause one to abandon a feature forever.

A crystal oscillator that: always starts, is always the right frequency,
and is cheap -- is best left to those who have solved it for a few dozen
useful frequencies (and even they have their share of headaches).

It would be (and is) a horrible business risk to attempt to supply a
circuit that would always work for every possible crystal from near DC
to daylight.

Can anyone guess how many different parameters there are to specify for
a crystal?  It is not just the frequency....

Austin

Article: 106523
Subject: Re: Open source Xilinx JTAG programmer with Digilent USB support
From: ptkwt@aracnet.com (Phil Tomson)
Date: 14 Aug 2006 22:14:21 GMT
Links: << >>  << T >>  << A >>
In article <1154993195.996004.266830@m73g2000cwd.googlegroups.com>,
fpgakid@gmail.com <fpgakid@gmail.com> wrote:
>I've written a Xilinx JTAG programmer. It runs on Win32 and Linux
>
>Following cables are supported:
>
>Parallel III
>Digilent USB (on Linux it needs libusb, Win32 needs the original driver
>from digilent, utilizes full USB transfer speed!)
>
>Following chips are implemented:
>Spartan-3 Family
>XCF Family
>Virtex-II Pro family
>
>If it seems people are interested I'll clean up the code and put it up
>on sourceforge.net.
>The most interesting part is  the Digilent USB driver. It could be used
>in other applications too :)
>

I'd be interested.  Is the code available?  I've been having some problems 
with xc3sprog - specifically getting it to program a Spartan 3 1500 - so 
I'd like to give your program a try.

Phil


Article: 106524
Subject: Re: Crystal input for FPGA
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 15 Aug 2006 10:43:24 +1200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> All,
> 
> Nothing like failure to cause one to abandon a feature forever.
> 
> A crystal oscillator that: always starts, is always the right frequency,
> and is cheap -- is best left to those who have solved it for a few dozen
> useful frequencies (and even they have their share of headaches).
> 
> It would be (and is) a horrible business risk to attempt to supply a
> circuit that would always work for every possible crystal from near DC
> to daylight.
> 
> Can anyone guess how many different parameters there are to specify for
> a crystal?  It is not just the frequency....

The companies that do this properly, typically have 4 gm's or transfer 
gains selectable by fuses, that cover 1-2 decades of frequency/option.

Most vanilla Osc circuits struggle with overtone crystals (above appx 
25-40MHz), and for FPGAs that is on the 'low' side of useful.
So above this, and you are pretty much into Osc-Modules (or the cheaper 
SOT23's if you can tolerate their precision )

Silicon MEMS 'crystals' have been talked about, but still seem niche 
devices. - and no, these will not appear inside your FPGAs :)

-jg




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search