You have a better chance of getting a good answer back from members
of the PIC list if you make the problem as specific as possible.
For example, if the person asking the question had said:
"Can I use a PIC to measure a frequency that is greater than 1 Mhz?"
then I could readily give them a number of inexpensive PIC based
solutions. And a few that don't require a PIC at all.

No, you can not "soup up" the PIC to run with a 4 GIGA Hz clock.
That option is out. But as Frank intimates in his response below,
there may well be other things you can do with the PIC to make it
do things that you might *think* you needed a 4 GHz clock to
accomplish. Tell us in general terms at least what you want to
do. If no one here has a PIC way of doing that, then just
maybe some one can aim you in some other direction that *will* work
for you. Or at least you will know right up front that you are
seeking to do the impossible.

Input. We need more input! Otherwise it does not compute!

Fr. Tom McGahee

----------
> From: Frank Vorstenbosch <frank@FALSTAFF.DEMON.CO.UK>
> To: PICLIST@MITVMA.MIT.EDU
> Subject: Re: Beginners question on increasing pic internal clock spee
> Date: Wednesday, June 17, 1998 3:01 PM
>
> > Is there presently anyway I can get a Pic16c54 or any other Pic for that
> > matter to be able to execute code at 1 nanosecond per instruction? If
> > not possible with Pics are there any other microcontrollers that can
> > execute instructions this fast? Thanx in advance for for responding.
>
> I think the best you can do cheaply nowadays is about 250MIPS in a
> microprocessor.  My current favourite is the StrongARM, which will do
> internal cycles at 235Mhz, with a bus of up to 66MHz.  This requires
> 32-bit memory though (ROM and RAM).
>
> Alternatively, you can use programmable logic to build a state machine --
> this will go up to the same kind of speed if you've got fast devices.
> Using ECL it should be possible to hit 500-600MHz clock rates.  Beyond
> that you're talking transmission lines anyway, so you can use transmission
> lines as delay elements.  Programmability goes out of the window, of course.
>
> Try to see if the problem you're trying to solve can be approached from
> a different angle (massive parallelism, improved algorithms, off-the-shelf
> test&measurement kit, etc.).
>
> Frank