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
2017JanFebMarApr2017

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 30075

Article: 30075
Subject: Looking for Processor Core info/advice
From: Gaston Biessener <gaston@yuck.net>
Date: Thu, 22 Mar 2001 13:20:47 -0600
Links: << >>  << T >>  << A >>
I am working on a product design that is tentatively  planned to be
based around a Spartan-II device with a small Micro-P core implemented
in the FPGA as the system controller.
I was wondering if anybody here could give me any advice and/or direct
me to good information on purchased and/or open-source processor cores
for Xilinx FPGAs, particularly the Spartan and Spartan-II devices.  I
haven't managed to learn much so far via the obvious links on the Xilinx
web-site.

Gaston Biessener

Article: 30076
Subject: Re: BG575 socket recommendation?
From: Ryan Laity <laity@xilinx.com>
Date: Thu, 22 Mar 2001 12:50:58 -0700
Links: << >>  << T >>  << A >>
Luke,
  For BGA specifically, check out 3M Textool:
http://www.3m.com/ehpd/sockets/
3M Textool
6801 River Place Blvd.
Austin, TX 78726-9000
(800) 328-0411
(612) 736-7167

There are more manufacturers listed in the databook under "Packages and
Thermal Characteristics" http://www.xilinx.com/partinfo/pkgs_pdf/pkgs1.pdf
subsection "Sockets".  None of the other manufacturers besides 3M  show that
they supply a BG socket though.  Also check out
http://www.xilinx.com/support/programr/sockets.htm for a similar but more
complete list.  I hope this helps.

Ryan Laity
Xilinx Customer Apps


Luke Roth wrote:

>         After hearing all the whiz-bang new features of the Virtex-II
> series, we'd like to migrate our university project over (currently
> running original Virtex).  However, BGA packages are beyond our
> capabilities.  Does anybody have any recommendations for a
> BG575-to-something-reasonable (PGA would be ideal) socket?
>         It's too bad Xilinx is making things more difficult for those of
> us with limited resources.  Nothing that we shouldn't be able to work
> around, though.
>         Thanks,
>         Luke


Article: 30077
Subject: Virtex Em on a board?
From: Ray Andraka <ray@andraka.com>
Date: Thu, 22 Mar 2001 20:05:47 GMT
Links: << >>  << T >>  << A >>
Does anyone know of any commercially available boards offered with the XCV812E
on it?  Looking for one for a fast prototype.


-- 
-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

Article: 30078
Subject: Re: Virtex Em on a board?
From: "Johan Ditmar" <johan.ditmar@era.ericsson.se>
Date: Thu, 22 Mar 2001 21:24:19 +0100
Links: << >>  << T >>  << A >>
Alpha Data perhaps (the ADC-RC1000). Look at www.alphadata.co.uk.

/Johan

Ray Andraka wrote in message <3ABA5C75.68E00301@andraka.com>...
>Does anyone know of any commercially available boards offered with the
XCV812E
>on it?  Looking for one for a fast prototype.
>
>
>--
>-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



Article: 30079
Subject: Re: Xilinx XC18v04 programming via FPGA
From: Tom Biggs <tbiggs@pluris.com>
Date: Thu, 22 Mar 2001 12:36:34 -0800
Links: << >>  << T >>  << A >>
Why isn't it safe? It makes sense to me.

http://www.xilinx.com/xapp/xapp058.pdf

Stan Ramsden wrote:

> Here is the scenario:
> I know this is not safe to do, but the board has been layed out and we are
> stuck with what we have. I need to be able to program the XC18v04
> configuration memory thru the configured FPGA using the non dedicated JTAG
> pins.
> Has anyone done such a design?


Article: 30080
Subject: Re: Looking for Processor Core info/advice
From: Tom Dillon <tdillon@dilloneng.com>
Date: Thu, 22 Mar 2001 21:19:54 GMT
Links: << >>  << T >>  << A >>
Gaston,

We have worked with a open source 6502 core. We spent some time=20
optimizing it for the Spartan family.

You can find information about it at:

http://www.free-ip.com/6502/

It synthesized without a problem using the Xilinx tools. If I remember=20=

correctly without modifications it easily fit into a X2S50.

There are some others out there.

Also http://www.silicore.net/ has a low cost and very good PIC core.

Let me know if you need any more information.

Regards,=20

Tom Dillon
Dillon Engineering, Inc.
http://www.dilloneng.com





>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 3/22/2001, 1:20:47 PM, Gaston Biessener <gaston@yuck.net> wrote=20
regarding Looking for Processor Core info/advice:


> I am working on a product design that is tentatively  planned to be
> based around a Spartan-II device with a small Micro-P core implemented=

> in the FPGA as the system controller.
> I was wondering if anybody here could give me any advice and/or direct=

> me to good information on purchased and/or open-source processor cores=

> for Xilinx FPGAs, particularly the Spartan and Spartan-II devices.  I=

> haven't managed to learn much so far via the obvious links on the Xili=
nx
> web-site.

> Gaston Biessener

Article: 30081
Subject: Re: Is the carry logic for Virtex included in PAR timing report/check?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 22 Mar 2001 13:21:07 -0800
Links: << >>  << T >>  << A >>


Austin Franklin wrote:

> but something is broken, unless the
> carry chain really does take 0ns through 48 levels...
>

Carry delay through 48 bits should be between 2 and 3 ns.
Peter Alfke


Article: 30082
Subject: frequency measurement?
From: muzaffer@dspia.com
Date: 22 Mar 2001 22:09:34 GMT
Links: << >>  << T >>  << A >>
hi,
I have an application where I have to detect whether two clocks are
within a certain frequency range with each other. IOW, I need to be
able to detect whether the frequencies are within %2 of each other.
The idea I am using is to run two counters, one on each clock and when
one overflows, check the other to see how close it is. The decision is
made based on the value of the other counter being close enough to
zero or not. The other counter is then reset so that both start at
zero again. I am running the decision logic on one of the clocks and
the other counter is a gray counter. But of course there are a couple
of issues with respect to metastability here. The value of one counter
needs to cross one clock boundary to be compared against zero and the
reset signal on overflow needs to cross a clock boundary in the other
direction. I am having difficulty coming up with a robust design and
asking for suggestions.

thanks,

Muzaffer


Article: 30083
Subject: XS40 and XS95: Recommend books?
From: Mesner <mesner.strast@scotland.com>
Date: 22 Mar 2001 22:17:03 GMT
Links: << >>  << T >>  << A >>
Hi can anyone recommend books for beginner level programming of XS40 and XS95
boards for someone with zero knowledge of FPGA VHDL programming? These are
required to teach both staff and students, so it should preferably be easy to
follow.

Thanks very much.

-- 

Article: 30084
Subject: Re: TBUFs in Virtex and later chips, going out of fashion, what instead
From: "Simon Bacon" <simonb@tile.demon.co.cut_this.uk>
Date: Thu, 22 Mar 2001 22:19:05 -0000
Links: << >>  << T >>  << A >>

"Austin Lesea" <austin.lesea@xilinx.com> wrote in message
news:3ABA26B6.520A1AC7@xilinx.com...
>
> With > 95% of all FPGA designs being done in HDL's, we think we are spending
time and
> silicon on what makes that flow the fastest and best possible.

Well, picking an HDL:

  DataOut <= Reg0Val when Addr=REG0 else (others=>'z');
  DataOut <= Reg1Val when Addr=REG1 else (others=>'z');
  DataOut <= Reg2Val when Addr=REG2 else (others=>'z');

and the Verilog metaphor is similar.  This is HDL, easy to
understand, and a good mapping to TBUFs.

Of course, ASICs do not usually support T/S lines.  Even the
Xilinx implementation is an emulation in Virtex, though the
3K and 4K had the real thing.





Article: 30085
Subject: Re: Looking for Processor Core info/advice
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 22 Mar 2001 14:56:31 -0800
Links: << >>  << T >>  << A >>
Tom Dillon <tdillon@dilloneng.com> writes:
> We have worked with a open source 6502 core. We spent some time 
> optimizing it for the Spartan family.

Can you make your Spartan optimized version available?

Article: 30086
Subject: Re: frequency measurement?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 23 Mar 2001 11:10:56 +1200
Links: << >>  << T >>  << A >>
muzaffer@dspia.com wrote:
> 
> hi,
> I have an application where I have to detect whether two clocks are
> within a certain frequency range with each other. IOW, I need to be
> able to detect whether the frequencies are within %2 of each other.
> The idea I am using is to run two counters, one on each clock and when
> one overflows, check the other to see how close it is. The decision is
> made based on the value of the other counter being close enough to
> zero or not. The other counter is then reset so that both start at
> zero again. I am running the decision logic on one of the clocks and
> the other counter is a gray counter. But of course there are a couple
> of issues with respect to metastability here. The value of one counter
> needs to cross one clock boundary to be compared against zero and the
> reset signal on overflow needs to cross a clock boundary in the other
> direction. I am having difficulty coming up with a robust design and
> asking for suggestions.
> 
> thanks,
> 
> Muzaffer

 Since you know the window, you do not need to pass the whole counters
across the bondary.
 Generate a terminal count (eg 1024) and use to clear both counters to
00.
then generate a window close to 512 on one ( 502..522 is +/- 2% )
( one or 2 lines, 2 if you want dirn of error )
and use the other ctrs ==512 to sample these 2 lines.
- just 3 lines cross clock domains.

-jg

Article: 30087
Subject: Re: frequency measurement?
From: Ray Andraka <ray@andraka.com>
Date: Thu, 22 Mar 2001 23:58:03 GMT
Links: << >>  << T >>  << A >>
This is probably best done like a frequency counter.  Use one clock to generate
a measurement interval, then count the cycles of the other clock that occur
within that interval.  This reduces the 
signals that cross the clock boundary to just one, and that can be synchronized
with as many FFs as you want.

Choose one clock you want on the output side,this is what the output is sync'd
to, and is the clock you will count.  Now, with the other clock, run a free
running counter with a modulo that is convenient for the accuracy you wish to
measure (this is your measurement interval).  All you need out of that counter
is a terminal count.  Pass the terminal count across your clock domain boundary,
synchronizing it to the other clock as you do.  You want your synchronizer to
produce a one clock wide pulse in the output domain in response to a TC from the
input domain. More on that in a second.  Use the one clock wide TC pulse to
synchronously reset a second counter that is incremented on each cycle of the
output side clock.  If you want to measure the relative frequency, use the TC to
clock-enable a register fed by the second counter outputs on the same cycle you
apply the sync reset.  In your case though, you are only interested in the
frequency being in/out of range.  For that, decode the counter outputs to
generate an in-range/out-of-range signal, and then register that using a
flip-flop clock enabled by TC. You can get this to whatever accuracy you desire
by extending the time interval of the TC generated by the first counter.

Only 1 signal crosses the clock domain boundary.  What I do to generate a 1
cycle clock in the synchronized side uses 3 FFs.  The first is a toggle FF
clocked in the input side domain and toggled each time you get a trigger event
(in this case a TC), so that it is high for one cycle of the first counter, low
for the second.  This goes to a 4 state state machine clocked in the second
domain which generates a pulse each time the toggle input changes.  If the state
machine is coded properly, no sync flip-flop between is needed because the
signal only affects one flip-flop.  The state machine has 2 stable states
corresponding to the two toggle states:

case SM is=>
	when "00"=>
		if toggle='0' then
			SM<="00";
		else
			SM<="01";
		end if;
	when "01"=>
		SM<="11";
	when "11"=>
		if toggle='1' then
			SM<="11";
		else
			SM<="10";
		end if;
	when "10"=>
		SM<="00";
	when others=>
		null;
end case;

SM(0) is the one cycle wide pulse output.  Note that that flip-flop is the only
one affected by the toggle input.  This synchronizer works as long as the toggle
input cycles slower than half the clock of the state machine.  Of course if you
want, you can always add additional sync FF's on the toggle input.


Jim Granville wrote:
> 
> muzaffer@dspia.com wrote:
> >
> > hi,
> > I have an application where I have to detect whether two clocks are
> > within a certain frequency range with each other. IOW, I need to be
> > able to detect whether the frequencies are within %2 of each other.
> > The idea I am using is to run two counters, one on each clock and when
> > one overflows, check the other to see how close it is. The decision is
> > made based on the value of the other counter being close enough to
> > zero or not. The other counter is then reset so that both start at
> > zero again. I am running the decision logic on one of the clocks and
> > the other counter is a gray counter. But of course there are a couple
> > of issues with respect to metastability here. The value of one counter
> > needs to cross one clock boundary to be compared against zero and the
> > reset signal on overflow needs to cross a clock boundary in the other
> > direction. I am having difficulty coming up with a robust design and
> > asking for suggestions.
> >
> > thanks,
> >
> > Muzaffer
> 
>  Since you know the window, you do not need to pass the whole counters
> across the bondary.
>  Generate a terminal count (eg 1024) and use to clear both counters to
> 00.
> then generate a window close to 512 on one ( 502..522 is +/- 2% )
> ( one or 2 lines, 2 if you want dirn of error )
> and use the other ctrs ==512 to sample these 2 lines.
> - just 3 lines cross clock domains.
> 
> -jg

-- 
-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

Article: 30088
Subject: Re: Virtex Em on a board?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 23 Mar 2001 00:00:43 GMT
Links: << >>  << T >>  << A >>
Thanks.  ANy others?

Johan Ditmar wrote:
> 
> Alpha Data perhaps (the ADC-RC1000). Look at www.alphadata.co.uk.
> 
> /Johan
> 
> Ray Andraka wrote in message <3ABA5C75.68E00301@andraka.com>...
> >Does anyone know of any commercially available boards offered with the
> XCV812E
> >on it?  Looking for one for a fast prototype.
> >
> >
> >--
> >-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

-- 
-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

Article: 30089
Subject: Re: Is the carry logic for Virtex included in PAR timing report/check?
From: "Austin Franklin" <austin@dark99room.com>
Date: Thu, 22 Mar 2001 19:07:26 -0500
Links: << >>  << T >>  << A >>
> > but something is broken, unless the
> > carry chain really does take 0ns through 48 levels...
> >
>
> Carry delay through 48 bits should be between 2 and 3 ns.
> Peter Alfke
>

Er, then why does FPGA Editor say 0.0 for each of the carry elements?




Article: 30090
Subject: Re: TBUFs in Virtex and later chips, going out of fashion, what instead
From: muzaffer@dspia.com
Date: 23 Mar 2001 01:13:19 GMT
Links: << >>  << T >>  << A >>
"Simon Bacon" <simonb@tile.demon.co.cut_this.uk> wrote:

>
>"Austin Lesea" <austin.lesea@xilinx.com> wrote in message
>news:3ABA26B6.520A1AC7@xilinx.com...
>>
>> With > 95% of all FPGA designs being done in HDL's, we think we are spending
>time and
>> silicon on what makes that flow the fastest and best possible.
>
>Well, picking an HDL:
>
>  DataOut <= Reg0Val when Addr=REG0 else (others=>'z');
>  DataOut <= Reg1Val when Addr=REG1 else (others=>'z');
>  DataOut <= Reg2Val when Addr=REG2 else (others=>'z');
>
>and the Verilog metaphor is similar.  This is HDL, easy to
>understand, and a good mapping to TBUFs.
>
>Of course, ASICs do not usually support T/S lines.  

By ASIC I take it you mean Standard cell based ASIC; if that's the
case, this has not been my experience. Almost all SC libraries have
T/S buffers and inverters. Some even have T/S DFFs and T/S bus
holders. Of course with a full custom ASIC, there is no limit on what
you can do.

> Even the
>Xilinx implementation is an emulation in Virtex, though the
>3K and 4K had the real thing.

I think the problem with T/S busses are well known. Difficult to time,
potential for electrical conflicts, potential for very high power
consumption etc. Being more of an analog feature, one has to spend
extra effort with RTL verification. You might even have to spice some
paths god forbid ;-)

Muzaffer


Article: 30091
Subject: what to do with I/O pins during powerup or during jtag programming
From: "Daniel Nilsson" <danielnilsson@REMOVE_THIShem3.passagen.se>
Date: Fri, 23 Mar 2001 02:36:16 +0100
Links: << >>  << T >>  << A >>
Hi.
I have a cpld (xilinx xc9500) in my system, mainly used for controlling
buffers, and I suspect I will need to add pull up or pull down resistors
where appropriate to prevent damage on system because of strange levels on
I/O pins during jtag programming or power-up.  Is it common practice to do
like this, and if so, what are the appropriate values to add to force out
pins to a safe level (to prevent bustranscievers from being turned on)
during high-z ?

/ Daniel Nilsson



Article: 30092
Subject: Re: XS40 and XS95: Recommend books?
From: Dave Vanden Bout <devb@xess.com>
Date: Thu, 22 Mar 2001 20:55:52 -0500
Links: << >>  << T >>  << A >>
Mesner wrote:

> Hi can anyone recommend books for beginner level programming of XS40 and XS95
> boards for someone with zero knowledge of FPGA VHDL programming? These are
> required to teach both staff and students, so it should preferably be easy to
> follow.

You have several choices, none of which completely meet your needs:

1) "The Practical Xilinx Designer Lab Book 1.5" is a complete tutorial that shows
how to design logic using VHDL and/or schematics for the XS40 and XS95 Boards and
Xilinx Foundation 1.5.  Prentice Hall discontinued publication of this book last
year.  You might get a used copy from somebody.  But the current Xilinx Student
Edition software is based on Foundation 2.1i so the book is a bit out of date.
If you get a copy, perhaps Prentice Hall will give you permission to copy the
material for use in your class.

2) XESS is releasing chapters of its "Pragmatic Logic Design with Foundation
2.1i" on http://www.xess.com.  The chapters try to show detailed steps of how to
use the various tools in Foundation 2.1i to create logic designs for the XS40 and
XS95 Boards.  However, while the examples may show you how to create, synthesize,
implement, and download a VHDL-based design, it does not purport to instruct you
in the details of VHDL coding.  Also, only three of the eight chapters are
currently available and the author habitually fails to meet the deadlines for
releasing new chapters.

3) "Introductory VHDL" by Sudhakar Yalamanchili (ISBN 0-13-080982-9) gives a
decent introduction to VHDL coding using the Xilinx Foundation 2.1i tools.  It
also includes the Student Edition of the Foundation 2.1i software.  It doesn't
discuss how to download or test any of its example designs on the XS40 or XS95
Boards.  It costs $100 but it's not available yet.  (It should be soon since I
have a production copy on my desk.)

Perhaps some combination of items 1, 2, and 3 will meet your needs.


--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||



Article: 30093
Subject: Re: Is the carry logic for Virtex included in PAR timing report/check?
From: Peter Alfke <palfke@earthlink.net>
Date: Fri, 23 Mar 2001 02:57:15 GMT
Links: << >>  << T >>  << A >>


Austin Franklin wrote:

> Er, then why does FPGA Editor say 0.0 for each of the carry elements?

Maybe round-off, since each individual carry ( per bit) is <0.05 ns ??
Not a good reason...

Peter



Article: 30094
Subject: Re: TOA measurement
From: Charles Lyttle <lyttlec@earthlink.net>
Date: Fri, 23 Mar 2001 03:04:24 GMT
Links: << >>  << T >>  << A >>
Michal Kvasnicka wrote:
> =

> OK...
> From my point of view delay measurement needs two delayed signal which =
are
> compared in the TDE (time delay estimation) algorithm, but TOA measurem=
ent
> work only with one precisely sampled signal and any available additiona=
l
> apriory knowledge (pulse shape, noise model, etc.).
> =

> Radar pulse can be approximated by trapezoidal (symmetric or asymmetric=
)
> pulse wit the following parameters:
> pulse width =3D 0.5 - 500us (50% amplitude level)
> rise time =3D 20-100ns
> fall time =3D 20-200ns
> sample interval =3D 1 - 10ns
> Pulse repetition interval =3D 1 - 5000us
> =

> These pulses (pulse train) is contaminated by noise of the general form=

> (colored nongaussian, spread spectrum, etc.) with low S/N ration (in ma=
ny
> cases). Finally is represented by 1-channel data stream sampled by 1-10=
ns
> and with precise time stamping.
> =

> Time sampling is realized by Rubidium normal (short term stability abou=
t
> 10^-12 ) connected with GPS time receiver for long term stability about=

> 10^-13 - 10^-15.
> =

> Required TOA accuracy is about 1-10ns.
> =

> So, I need effective and robust TOA algorithm which can be realized on =
DSP
> or FPGA chip sufficiently fast (see PRI value ~ 1-5000us).
> =

> Regards,
> =

> Michal
> =

> "Kolja Sulimma" <kolja@bnl.gov> p=EDse v diskusn=EDm pr=EDspevku
> news:3AB65BBE.2055F00D@bnl.gov...
> > Can you describe the rwquirements in more detail?
> > Is it just delay measurement with high resolution?
> > What resolution do you need? And how many channels?
> >
> > CU,
> >         Kolja Sulimma
> >
> > Michal Kvasnicka wrote:
> >
> > > Does anyone know of any texts or references concerning implementing=
 TOA
> > > (time of arrival) measurement of the radar signal on FPGA or DSP ch=
ips?
> > >
> > > Thanks,
> > >
> > > Michal
> >
I take it you have a passive multichannel receiver monitoring returns
from a vehicle illuminated with multiple radars. You can use correlation
techniques : each return stream will correlate with itself well enough
to give you a probable time of return. By itself, a radar would not have
that much variability pulse to pulse. Is your situation one where the
radars transmit random seeming patterns as part of an
identification/EW/multi-target scheme? In that case you are lost unless
you have independent data as to the pattern transmitted.

Differential GPS is now often used to do what I think you need. Each
radar transmission encodes GPS data for a satellite. If the receiver can
also see the satellite, it can then estimate the path delay. Having path
delays to multiple radars solves the problem for a most probable
location of the target. Use DGPS for the coarse measurement, then use
doppler to estimate velocities relative to the radars and get fine
measurements. Estimate position, velocity, use velocity to predict next
position. use predicted - measured as position errors to feed back and
correct the next position measurement. =

-- =

Russ Lyttle
"World Domination through Penguin Power"
The Universal Automotive Testset Project at
<http://home.earthlink.net/~lyttlec>

Article: 30095
Subject: Help! DLL Feedback in Virtex-E
From: "Guibert, Martin" <guibert@americasm01.nt.com>
Date: Thu, 22 Mar 2001 22:09:05 -0500
Links: << >>  << T >>  << A >>
Hello, 

I'm currently targeting a Virtex-E for a project where I'm using a DLL
to de-skew a board level clock and another dll to route the same clock
internally.  It's the same thing as the dll_mirror_1.v file from the
xapp132 because I get the same problem with that file:

-------
module dll_mirror_1 (CLKIN, CLKFB, CLK0_ext, CLK0_int);
input  CLKIN, CLKFB;
output CLK0_ext, CLK0_int;

wire CLKIN_w, CLKFB_w, CLK0_int_dll, CLK0_ext_dll;
wire logic0;

assign logic0 = 1'b0;

IBUFG clkpad   (.I(CLKIN), .O(CLKIN_w));
IBUFG clkfbpad (.I(CLKFB), .O(CLKFB_w));

CLKDLL dllint (.CLKIN(CLKIN_w), .CLKFB(CLK0_int), .RST(logic0), 
               .CLK0(CLK0_int_dll), .CLK90(), .CLK180(), .CLK270(),
               .CLK2X(), .CLKDV(), .LOCKED());

CLKDLL dllext (.CLKIN(CLKIN_w), .CLKFB(CLKFB_w), .RST(logic0), 
               .CLK0(CLK0_ext_dll), .CLK90(), .CLK180(), .CLK270(),
               .CLK2X(), .CLKDV(), .LOCKED());

BUFG   clkg      (.I(CLK0_int_dll), .O(CLK0_int));
OBUF   clkextpad (.I(CLK0_ext_dll), .O(CLK0_ext));

endmodule
--------

The package that I'm targeting is a XCV2000E-7-FG680 and I'm using the
GCLK0 P and N pins for the clock input and feedback:
AW19 = Clock (CLKIN in the example)
AT21 = Clock feedback (CLKFB in the example).

I'm also using the following UCF file:

NET "CLKIN" LOC = "AW19";
NET "CLKFB" LOC = "AT21";


Synthesis runs fine (synplify 6.0 and synplify_pro with amplify 2.1.2). 
Ngdbuild runs fine.  

The problem is with the mapper.  I get a segmentation fault every time I
run it:

>map -pr b -p xcv2000e-6-fg680 test
Release v3.3.07i - Map D.26
Copyright (c) 1995-2000 Xilinx, Inc.  All rights reserved.
Using target part "v2000efg680-6".
Reading NGD file "test.ngd"...
Processing FMAPs...
Removing unused or disabled logic...
Running cover...
Writing file test.ngm...
Running directed packing...
Segmentation fault (core dumped)


Anyone has an idea about what could be the problem?  Our Xilinx FAEs
told us that it should be possible to do it, they have no clue about why
it does not work and the datasheet & xapp132 does not mention that it's
not possible.  They are working on the problem but I need a solution
ASAP!

BTW, no, we can't change the pinout because the board is ready.  It
works if the feed-back is at the P input of another GCLK so it really
seems to be a problem with the tool.  


Thanks!


Martin Guibert

Article: 30096
Subject: Re: Looking for Processor Core info/advice
From: Phil Hays <spampostmaster@home.com>
Date: Fri, 23 Mar 2001 03:11:15 GMT
Links: << >>  << T >>  << A >>
Gaston Biessener wrote:

> I am working on a product design that is tentatively  planned to be
> based around a Spartan-II device with a small Micro-P core implemented
> in the FPGA as the system controller.

Might checkout:

http://www.fpgacpu.org/

http://tech-www.informatik.uni-hamburg.de/vhdl/vhdl.html


-- 
Phil Hays

Article: 30097
Subject: Re: Is the carry logic for Virtex included in PAR timing report/check?
From: "Austin Franklin" <austin@dark99room.com>
Date: Thu, 22 Mar 2001 22:22:17 -0500
Links: << >>  << T >>  << A >>
As a note, the PAR report said there were 11 levels of logic MAX on this
clock...yet this delay report shows 24 levels...so how can I believe that in
the PAR report it actually DID take into account the carry chain?

Here is what FPGA Editor delay gives me (not all the 0s):

Path (0) "CLB_R25C39.S0.YQ" to "CLB_R14C41.S1.G2": contains 24 levels of
logic:
Path starting from Comp: CLB_R25C39.S0.YQ
To                   Delay type         Delay(ns)  Physical Resource
                                                   Logical Resource(s)
-------------------------------------------------  --------
CLB_R24C29.S1.G4     net (fanout=2)        0.000R  source_gain/acc_reg[1]
CLB_R24C29.S1.COUT   Topcyg                0.000R
ce_gain/comp_acc_reg_cry_1/O
                                                   source_gain/acc_reg_i[1]

urce_gain/comp_acc_reg_cry_1
CLB_R23C29.S1.CIN    net (fanout=1)        0.000R
ce_gain/comp_acc_reg_cry_1/O
CLB_R23C29.S1.COUT   Tbyp                  0.000R
ce_gain/comp_acc_reg_cry_3/O

urce_gain/comp_acc_reg_cry_2

urce_gain/comp_acc_reg_cry_3
CLB_R22C29.S1.CIN    net (fanout=1)        0.000R
ce_gain/comp_acc_reg_cry_3/O
CLB_R22C29.S1.COUT   Tbyp                  0.000R
ce_gain/comp_acc_reg_cry_5/O

urce_gain/comp_acc_reg_cry_4

urce_gain/comp_acc_reg_cry_5
CLB_R21C29.S1.CIN    net (fanout=1)        0.000R
ce_gain/comp_acc_reg_cry_5/O
CLB_R21C29.S1.COUT   Tbyp                  0.000R
ce_gain/comp_acc_reg_cry_7/O

urce_gain/comp_acc_reg_cry_6

urce_gain/comp_acc_reg_cry_7
CLB_R20C29.S1.CIN    net (fanout=1)        0.000R
ce_gain/comp_acc_reg_cry_7/O
CLB_R20C29.S1.COUT   Tbyp                  0.000R
ce_gain/comp_acc_reg_cry_9/O

urce_gain/comp_acc_reg_cry_8

urce_gain/comp_acc_reg_cry_9
CLB_R19C29.S1.CIN    net (fanout=1)        0.000R
ce_gain/comp_acc_reg_cry_9/O
CLB_R19C29.S1.COUT   Tbyp                  0.000R
e_gain/comp_acc_reg_cry_11/O

rce_gain/comp_acc_reg_cry_10

rce_gain/comp_acc_reg_cry_11
CLB_R18C29.S1.CIN    net (fanout=1)        0.000R
e_gain/comp_acc_reg_cry_11/O
CLB_R18C29.S1.COUT   Tbyp                  0.000R
e_gain/comp_acc_reg_cry_13/O

rce_gain/comp_acc_reg_cry_12

rce_gain/comp_acc_reg_cry_13
CLB_R17C29.S1.CIN    net (fanout=1)        0.000R
e_gain/comp_acc_reg_cry_13/O
CLB_R17C29.S1.COUT   Tbyp                  0.000R
e_gain/comp_acc_reg_cry_15/O

rce_gain/comp_acc_reg_cry_14

rce_gain/comp_acc_reg_cry_15
CLB_R16C29.S1.CIN    net (fanout=1)        0.000R
e_gain/comp_acc_reg_cry_15/O
CLB_R16C29.S1.COUT   Tbyp                  0.000R
e_gain/comp_acc_reg_cry_17/O

rce_gain/comp_acc_reg_cry_16

rce_gain/comp_acc_reg_cry_17
CLB_R15C29.S1.CIN    net (fanout=1)        0.000R
e_gain/comp_acc_reg_cry_17/O
CLB_R15C29.S1.COUT   Tbyp                  0.000R
e_gain/comp_acc_reg_cry_19/O

rce_gain/comp_acc_reg_cry_18

rce_gain/comp_acc_reg_cry_19
CLB_R14C29.S1.CIN    net (fanout=1)        0.000R
e_gain/comp_acc_reg_cry_19/O
CLB_R14C29.S1.COUT   Tbyp                  0.000R
e_gain/comp_acc_reg_cry_21/O

rce_gain/comp_acc_reg_cry_20

rce_gain/comp_acc_reg_cry_21
CLB_R13C29.S1.CIN    net (fanout=1)        0.000R
e_gain/comp_acc_reg_cry_21/O
CLB_R13C29.S1.COUT   Tbyp                  0.000R
e_gain/comp_acc_reg_cry_23/O

rce_gain/comp_acc_reg_cry_22

rce_gain/comp_acc_reg_cry_23
CLB_R12C29.S1.CIN    net (fanout=1)        0.000R
e_gain/comp_acc_reg_cry_23/O
CLB_R12C29.S1.COUT   Tbyp                  0.000R
source_gain/comp_acc_reg[24]

rce_gain/comp_acc_reg_cry_24

rce_gain/comp_acc_reg_cry_25
CLB_R11C29.S1.CIN    net (fanout=1)        0.000R
e_gain/comp_acc_reg_cry_25/O
CLB_R11C29.S1.COUT   Tbyp                  0.000R
source_gain/comp_acc_reg[26]

rce_gain/comp_acc_reg_cry_26

rce_gain/comp_acc_reg_cry_27
CLB_R10C29.S1.CIN    net (fanout=1)        0.000R
e_gain/comp_acc_reg_cry_27/O
CLB_R10C29.S1.COUT   Tbyp                  0.000R
source_gain/comp_acc_reg[28]

rce_gain/comp_acc_reg_cry_28

rce_gain/comp_acc_reg_cry_29
CLB_R9C29.S1.CIN     net (fanout=1)        0.000R
e_gain/comp_acc_reg_cry_29/O
CLB_R9C29.S1.COUT    Tbyp                  0.000R
source_gain/comp_acc_reg[30]

rce_gain/comp_acc_reg_cry_30

rce_gain/comp_acc_reg_cry_31
CLB_R8C29.S1.CIN     net (fanout=1)        0.000R
e_gain/comp_acc_reg_cry_31/O
CLB_R8C29.S1.COUT    Tbyp                  0.000R
source_gain/comp_acc_reg[32]

rce_gain/comp_acc_reg_cry_32

rce_gain/comp_acc_reg_cry_33
CLB_R7C29.S1.CIN     net (fanout=1)        0.000R
e_gain/comp_acc_reg_cry_33/O
CLB_R7C29.S1.COUT    Tbyp                  0.000R
source_gain/comp_acc_reg[34]

rce_gain/comp_acc_reg_cry_34

rce_gain/comp_acc_reg_cry_35
CLB_R6C29.S1.CIN     net (fanout=1)        0.000R
e_gain/comp_acc_reg_cry_35/O
CLB_R6C29.S1.COUT    Tbyp                  0.000R
source_gain/comp_acc_reg[36]

rce_gain/comp_acc_reg_cry_36

rce_gain/comp_acc_reg_cry_37
CLB_R5C29.S1.CIN     net (fanout=1)        0.000R
e_gain/comp_acc_reg_cry_37/O
CLB_R5C29.S1.COUT    Tbyp                  0.000R
source_gain/comp_acc_reg[38]

rce_gain/comp_acc_reg_cry_38

rce_gain/comp_acc_reg_cry_39
CLB_R4C29.S1.CIN     net (fanout=1)        0.000R
e_gain/comp_acc_reg_cry_39/O
CLB_R4C29.S1.COUT    Tbyp                  0.000R
source_gain/comp_acc_reg[40]

rce_gain/comp_acc_reg_cry_40

rce_gain/comp_acc_reg_cry_41
CLB_R3C29.S1.CIN     net (fanout=1)        0.000R
e_gain/comp_acc_reg_cry_41/O
CLB_R3C29.S1.COUT    Tbyp                  0.000R
source_gain/comp_acc_reg[42]

rce_gain/comp_acc_reg_cry_42

rce_gain/comp_acc_reg_cry_43
CLB_R2C29.S1.CIN     net (fanout=1)        0.000R
e_gain/comp_acc_reg_cry_43/O
CLB_R2C29.S1.COUT    Tbyp                  0.000R
source_gain/comp_acc_reg[44]

rce_gain/comp_acc_reg_cry_44

rce_gain/comp_acc_reg_cry_45
CLB_R1C29.S1.CIN     net (fanout=1)        0.000R
e_gain/comp_acc_reg_cry_45/O
CLB_R1C29.S1.Y       Tciny                 0.000R
source_gain/comp_acc_reg[46]

rce_gain/comp_acc_reg_cry_46

ource_gain/comp_acc_reg_s_47
CLB_R14C41.S1.G2     net (fanout=1)        0.000R
source_gain/comp_acc_reg[47]
-------------------------------------------------
Total (0.000ns logic, 0.000ns route)       0.000ns (to I_clk_50m_c)
      (0.0% logic, 0.0% route)

I will say that FPGA editor is so much more difficult to use than the old
XACT editor for things like path delay to name one.  I know it's got a lot
of improvements, but it is a giant slide backwards in certain functionality
that I find very useful.


"Peter Alfke" <palfke@earthlink.net> wrote in message
news:3ABABB88.9E594630@earthlink.net...
>
>
> Austin Franklin wrote:
>
> > Er, then why does FPGA Editor say 0.0 for each of the carry elements?
>
> Maybe round-off, since each individual carry ( per bit) is <0.05 ns ??
> Not a good reason...
>
> Peter
>
>



Article: 30098
Subject: Re: Looking for Processor Core info/advice
From: Kent Orthner <korthner@hotmail.nospam.com>
Date: 23 Mar 2001 13:04:05 +0900
Links: << >>  << T >>  << A >>


Does anyone know off-hand the licensing for these cores? Can we 
use a free 6502 core in a commercial product?  Ditto for PIC-
compatabile cores.  I know that the licensing on Jan gray's 
web site (www.fpgacpu.org) specifies no commercial uses.

Some of these other cores might be free but the instuction sets 
copyrighted?  (I'd like to put together a instructoin-compatable 
PIC core, but I can't figure out if I'd be allowed to use it. )

Anyone know?

-Kent

> Gaston Biessener wrote:
> > I am working on a product design that is tentatively  planned to be
> > based around a Spartan-II device with a small Micro-P core implemented
> > in the FPGA as the system controller.

Phil Hays <spampostmaster@home.com> writes:
> Might checkout:
> 
> http://www.fpgacpu.org/
> 
> http://tech-www.informatik.uni-hamburg.de/vhdl/vhdl.html
> 
> 
> -- 
> Phil Hays

Article: 30099
Subject: Re: Senior I/O Designer - Canada
From: "Lee I." <leei@starpower.nospam.net>
Date: Thu, 22 Mar 2001 23:15:47 -0500
Links: << >>  << T >>  << A >>
Also as opposed to "Dead Meat" or "Red Meat" from Cali.

-Lee - Former Jersey Punk myself.

"Andy Peters noao [.] edu>" <"apeters <"@> wrote in message
news:99bdm9$2gi6$1@noao.edu...
> Lee Iovino wrote:
> >
> > "Aggressive Meat" sounds like the name of a punk band from New Jersey.
>
> No, they were from across the river in Brooklyn.  You're thinking of the
> Meatmen, who were actually from Chicago.
>
> -andy
> former NJ punk rocker.





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
2017JanFebMarApr2017

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