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 19925

Article: 19925
Subject: Re: hc11 core & fpga or cpld
From: "Steven K. Knapp" <sknapp@triscend.com>
Date: Tue, 18 Jan 2000 07:09:58 -0800
Links: << >>  << T >>  << A >>
I don't know of anyone that makes a combination device with an HC11 and CPLD
or FPGA.

However, Triscend (www.triscend.com) makes a combination device called the
E5 family that contains:

* a high-performance 8051/52 compatible, similar to the Dallas 80C320
* between 2K to 40K gates of on-chip, SRAM-based programmable logic
* between 8K bytes to 64K bytes of on-chip 15 ns memory
* an on-chip 40 MHz system bus, supporting wait-states and single-cycle
  DMA transfers.

The associated FastChip development system supports standard FPGA-style
design if you want to create your own functions.  The software ships with
pre-designed functions that you can drag-and-drop onto the device.  The
library consists of standard microcontroller peripherals such as UARTs, SPI
channels, two-wire serial, etc.

There is an on-line tutorial at
http://www.triscend.com/learning/IndexSelfPaced.html.


----

Steven K. Knapp
Director, Online Support and Services
Triscend Corporation -- The Configurable System-on-Chip Company
301 N. Whisman Rd.
Mountain View, CA 94043  USA
Tel: 650-968-8668 x166, FAX: 650-934-9393
sknapp@triscend.com, Web: www.triscend.com


"myself" <nojunk@nojunk.com> wrote in message
news:387c8739.145980691@news.magma.ca...
> Hi I have a system that uses a motorola hc11 micro
> Does enyone have a cpld or fpga built around a hc11 micro?
>
> cost?
>
>


Article: 19926
Subject: Re: hc11 core & fpga or cpld
From: edick@hotmail.com (Richard Erlacher)
Date: Tue, 18 Jan 2000 16:26:52 GMT
Links: << >>  << T >>  << A >>
Just how good a result is this guy going to get using his HC11 code on
the processor you recommend?  He did ask for HC11, didn't he?

Dick

On Tue, 18 Jan 2000 07:09:58 -0800, "Steven K. Knapp"
<sknapp@triscend.com> wrote:

>I don't know of anyone that makes a combination device with an HC11 and CPLD
>or FPGA.
>
>However, Triscend (www.triscend.com) makes a combination device called the
>E5 family that contains:
>
>* a high-performance 8051/52 compatible, similar to the Dallas 80C320
>* between 2K to 40K gates of on-chip, SRAM-based programmable logic
>* between 8K bytes to 64K bytes of on-chip 15 ns memory
>* an on-chip 40 MHz system bus, supporting wait-states and single-cycle
>  DMA transfers.
>
>The associated FastChip development system supports standard FPGA-style
>design if you want to create your own functions.  The software ships with
>pre-designed functions that you can drag-and-drop onto the device.  The
>library consists of standard microcontroller peripherals such as UARTs, SPI
>channels, two-wire serial, etc.
>
>There is an on-line tutorial at
>http://www.triscend.com/learning/IndexSelfPaced.html.
>
>
>----
>
>Steven K. Knapp
>Director, Online Support and Services
>Triscend Corporation -- The Configurable System-on-Chip Company
>301 N. Whisman Rd.
>Mountain View, CA 94043  USA
>Tel: 650-968-8668 x166, FAX: 650-934-9393
>sknapp@triscend.com, Web: www.triscend.com
>
>
>"myself" <nojunk@nojunk.com> wrote in message
>news:387c8739.145980691@news.magma.ca...
>> Hi I have a system that uses a motorola hc11 micro
>> Does enyone have a cpld or fpga built around a hc11 micro?
>>
>> cost?
>>
>>
>
>

Article: 19927
Subject: Re: Viterbi decoder in FPGA
From: Jerry English <jenglish@planetc.com>
Date: Tue, 18 Jan 2000 12:04:07 -0500
Links: << >>  << T >>  << A >>
mehmeto@my-deja.com wrote:

>   I have searched the net for a viterbi decoder implementation ( vhdl
> source for FPGAs). I could not found any resources for free. VHDL codes
> for K=7 R=1/2 are sold for > $20000.Decoders for K=9 are even much
> expensive. So, why is this staff so expensive? I mean viterbi decoders
> are widely used and someone can easily find a cheap decoder IC. Can
> somebody explain the reason?
>   Is it too complex to build a VHDL model for K=7 R=1/2 ? Or is the
> incoming data rate (kbits/s or Mbit/s)the main factor.
>  I have found many C codes for viterbi decoders. How can I use them to
> translate to VHDL or Verilog for FPGAs?
>
> Thanks a lot
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

 Sounds like a good project for the IP public open core effort over on

the verilog board.



Article: 19928
Subject: Re: Random Number Generator
From: John Larkin <jjlarkin@highland_SnipThis_technology.com>
Date: Tue, 18 Jan 2000 09:49:30 -0800
Links: << >>  << T >>  << A >>
On Tue, 18 Jan 2000 14:33:29 GMT, Ray Andraka <randraka@ids.net> wrote:

>One of the things I considered was looking at the phase of the internal
>oscillator compared to an external clock, which would be random even with
>the same conditions, and would have a pretty much uniform distribution.  To
>do this, you need a fairly slow external clock (or divided clock), and
>after the FPGA is configured count the number of cycles of the internal
>oscillator until a specific transition of the external clock.  The slower
>the external clock with respect to the oscillator, the better the
>resolution.  Of course, for a slow clock, you want that independent of the
>time you start configuration or the variance will again be small.
>
>In any of these methods, the value obtained should be used as an initial
>seed to a digital PN sequence generator so that the distribution of your RN
>is controllable, even if the seed is not nicely distributed.
>
>Dave Decker wrote:
>
>> Don't forget the built in OSC that has a very poor tempco. You could
>> possibly substitute the internal OSC for the RC discussed below.
>>
>> Dave Decker


Ray, Dave

how about stirring the internal RC osc signal into the innards of a
pseudorandom shift register, say by xor'ing the RC signal into some midpoint
of a register clocked by something else. You now have a pseudorandom
sequence that is executing essentially random state jumps. Faster is better
here, I think.

John

Article: 19929
Subject: Re: Viterbi decoder in FPGA
From: s_clubb@NOSPAMnetcomuk.co.uk (Stuart Clubb)
Date: Tue, 18 Jan 2000 18:13:18 GMT
Links: << >>  << T >>  << A >>
Well said Sir!

It never ceases to amaze me how many engineers (and their managers)
fail to value their time, and associated on-costs to a given project.

On Mon, 17 Jan 2000 14:02:17 GMT, Ray Andraka <randraka@ids.net>
wrote:

>Engineering time to develop, verify and support a core is not
>insignificant.  Consider what the cost would be for you to roll you own and
>use that as a measure of the core's real cost.  I think with that in mind,

99% of Engineers always think their cost to develop the same thing
will be considerably less than the cost of the core. Probably 95% of
them are wrong, but they'll never know until it's too late (if they
ever know at all)

>even at the prices you cite, the cores are a bargain.  That is assuming
>they are fully verified on the target architecture, and that they come with
>some semblance of support.  The FPGA cores business is a tough business to
>make money in, for some reason people expect the cores to cost next to
>nothing, and yet perform better than anythng they could develop in house.

Prediction:

Because of the mindset in the FPGA community business of FPGA "cores"
will (within three years) have separated into three main areas

1 - Vendor I.P.

This is just the silicon vendors doing what ASIC vendors have been
doing in order to fill up the die/win orders/lock people in. The cores
will be "free" or "subsidised", but you'll be locked in. It will be a
means to an end, and a cost of doing business for the FPGA Vendors. We
already see a ramp in this activity today.

2 - Highly Complex I.P.

Stuff that everyone looks at and says "There's no way we could develop
that, but by $DEITY we need it". Things that fall into this class are
processors such as from the like of ARM, ARC, Lexra, MIPS,
VAutomation, etc. (It's the tool-chain and system level stuff that is
the hard part of developing a solution here) Other things that are
particularly esoteric or large and complex will be in this camp. They
will cost A LOT, because demand will be limited to a small number of
select organisations.

3 - Freeware/shareware/no-support.

Some of this will be good, some will be bad, but at least it'll be
free, or practically free, right?

Businesses will not (IMHO) make money selling low-end "noddy" cores
such as UARTs, Peripheral controllers, CRC's etc. It may be possible
for a "guru fred-in-the-shed" to make money through selling small HDL
source at very low cost on the web, but charging for support and
modifications.

>What you are buying with a core is time to market, and possibly design
>expertise you don't have in house.  Bottom line is you gets what you pays
>for.

Peanuts = Monkeys

Amen.

Cheers
Stuart
For Email remove "NOSPAM" from the address
Article: 19930
Subject: Re: Cores interfaces
From: Jonas Thor <thor@sm.luth.se>
Date: Wed, 19 Jan 2000 00:07:44 +0100
Links: << >>  << T >>  << A >>
You might want to check out WISHBONE at

http://www.silicore.net/wishbone.htm

/ Jonas

On Tue, 18 Jan 2000 11:28:50 +0200, Jamil Khaib <Khatib@ieee.org>
wrote:

>In the new world of SOC and design reuse the IP cores should be able to
>interface to each other easily. Some companies are trying to define
>their own cores interfaces and sometimes do not publish it.
>
>So we need to have a free open standard for cores interfaces that may be
>become more powerfull and usable for all designers
>
>Do you have any comments how to start defining these interfaces?
>
>all what I know that there are two types Bus style or point-to-point
>style but I do not know the advantages of each type.
>
>If you are intrested in defining this kind of interfaces please join us
>at openipcore project
>
>
>
>Thanks
>Jamil Khatib
>OpenIP Organization  http://www.openip.org
>OpenIPCore Project  http://www.openip.org/oc
>OpenCores   Project  http://www.opencores.org
>
>

Article: 19931
Subject: Re: Random Number Generator
From: murray@pa.dec.com (Hal Murray)
Date: 19 Jan 2000 00:16:14 GMT
Links: << >>  << T >>  << A >>

> how about stirring the internal RC osc signal into the innards of a
> pseudorandom shift register, say by xor'ing the RC signal into some midpoint
> of a register clocked by something else. You now have a pseudorandom
> sequence that is executing essentially random state jumps. Faster is better
> here, I think.

I get suspicious when I see suggestions like that.

If you are interested in random numbers, I suggest reading
Knuth's book.  Yes, it's mostly software, but the introduction
is a great eye-opener.  It describes a complicated algorithim that
you can't possibly predict.  It should make total garbage.  But it
doesn't!

I think you will be better off using techniques that you can
understand.  Then you will know how good they are and/or where
the limits are.

You also have to understand how your random numbers will be
used.  Again, it helps to be able to analyze your random number
generator to see if it fits into your application.

If you are thinking of using something like an external clock
to make your randomness more random, be sure you aren't just
making things harder to understand.  "random state jumps"
aren't random if they happen at predictable times.  All that does
is change the output sequence from one pseudo-random pattern to
a different one.

I think the key parameter is the bandwidth of the noise you can
get.  If the second clock comes from a crystal you probably won't
get much noise from it.  On the other hand, it may be a simple and
inexpensive to merge in a little more randomness.

-- 
These are my opinions, not necessarily my employers.
Article: 19932
Subject: Re: Virtex Temperature Sensing diode pins DXP, DXN
From: allan.herriman.hates.spam@fujitsu.com.au (Allan Herriman)
Date: Wed, 19 Jan 2000 00:31:08 GMT
Links: << >>  << T >>  << A >>
On Tue, 11 Jan 2000 08:12:36 GMT,
allan.herriman.hates.spam@fujitsu.com.au (Allan Herriman) wrote:

>On Mon, 10 Jan 2000 10:40:47 -0500, Matt Billenstein
><mbillens@one.net> wrote:
>
>>Virtex Temperature Sensing diode pins DXP, DXN
>>Has anyone used these or even know how they work?
>
>Matt,
>
>Look at the datasheet for the LM84 (NS) or MAX1617 (etc) (Maxim) or
>ADM1021 (Analog Devices).  Other manufacturers have them, but I can't
>remember the part numbers off hand.  These parts are designed to
>measure processor temperature for commodity motherboards, so they have
>an SMB (like I2C) interface.
>
>http://www.national.com/pf/LM/LM84.html
>http://dbserv.maxim-ic.com/pl_list.cfm?filter=ts
>http://products.analog.com/products/info.asp?product=ADM1021

Just found another one, the FMS2701 from Fairchild
http://www.fairchildsemi.com/pf/FM/FMS2701.html
It includes a fan speed control output.

Regards,
Allan.
Article: 19933
Subject: Re: Random Number Generator
From: Ray Andraka <randraka@ids.net>
Date: Wed, 19 Jan 2000 02:10:25 GMT
Links: << >>  << T >>  << A >>
As i mentioned in an earlier post, Any of these suggestions should be used only
for a random seed for a more conventional and predictable generator.  My caution
is to be sure that the seed generator is random enough and has enough of a
distribution that you won't be getting repeatable seeds if that is what your
application calls for.  That said, if there is a real-time clock somewhere in the
system, it is a time-proven source of unique seeds.  You will probably also want
to consider a mechanism for manually setting the seed so you can get a repeatable
sequence during debug.

Hal Murray wrote:

> > how about stirring the internal RC osc signal into the innards of a
> > pseudorandom shift register, say by xor'ing the RC signal into some midpoint
> > of a register clocked by something else. You now have a pseudorandom
> > sequence that is executing essentially random state jumps. Faster is better
> > here, I think.
>
> I get suspicious when I see suggestions like that.
>
> If you are interested in random numbers, I suggest reading
> Knuth's book.  Yes, it's mostly software, but the introduction
> is a great eye-opener.  It describes a complicated algorithim that
> you can't possibly predict.  It should make total garbage.  But it
> doesn't!
>
> I think you will be better off using techniques that you can
> understand.  Then you will know how good they are and/or where
> the limits are.
>
> You also have to understand how your random numbers will be
> used.  Again, it helps to be able to analyze your random number
> generator to see if it fits into your application.
>
> If you are thinking of using something like an external clock
> to make your randomness more random, be sure you aren't just
> making things harder to understand.  "random state jumps"
> aren't random if they happen at predictable times.  All that does
> is change the output sequence from one pseudo-random pattern to
> a different one.
>
> I think the key parameter is the bandwidth of the noise you can
> get.  If the second clock comes from a crystal you probably won't
> get much noise from it.  On the other hand, it may be a simple and
> inexpensive to merge in a little more randomness.
>
> --
> These are my opinions, not necessarily my employers.

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19934
Subject: Anyone interested?
From: "Kevin Lyons" <klyons@tsrc.net>
Date: Wed, 19 Jan 2000 03:03:13 GMT
Links: << >>  << T >>  << A >>
In a contract FPGA position. Location is Melbourne FL.  Need some for a 4-6
month contract. 5 yrs. experience......40-45 hr.   If interested and
qualified, please email resume to klyons@tsrc.net.
                                Thanks
                        Kevin Lyons


Article: 19935
Subject: Virtex Fine Pitch BGA pcb layout
From: "Matt Billenstein" <mbillens@one.net>
Date: Wed, 19 Jan 2000 04:04:17 GMT
Links: << >>  << T >>  << A >>
All,

I've not seen (or cannot find) an appropriate appnote or reference design
for laying down these fine pitch BGA parts (say FG256 for example)  There
doesn't seem to be a lot of room between BGA solder pads (0.400 millimeters
nominal) to route out or drop vias of any substantial size...  I can route
out two rows around the whole part with very little trouble, but I think I
have to dogbone anything further inside the part.  How are you folks here
doing it?

thx

m



Matt Billenstein
http://w3.one.net/~mbillens/
REMOVEmbillens@one.net




Article: 19936
Subject: Need advice on timing problem
From: Oh Sheau Pyng <ASSPOh@ntu.edu.sg>
Date: Wed, 19 Jan 2000 14:25:39 +0800
Links: << >>  << T >>  << A >>
hi,
  I have problem running a design at the max frequency  recommended in
the Timing analyse report.
  the s/w is foundation series 2.1, target is Virtex -4 bg560, the
function of the design is image processing

  The report give a min period of 29.222ns , but when i downed the
design into the virtex and clock it at 33.33ns , 30 mhz
  some of the output image is wrong, ( white dot/pixel can be seen at
the resultant image).

  When i reduce the frequency to.. say 400K hz , the resultant image is
Ok.

  So i deduce that it must be because of timing violation. 

  just like to know, how to you'll solve this ?
  at 30 mhz, it is already ~10% slower than the reported worst case. but
it still didn't work.
  is this normal, or i should have clock it at ~20% slower then
reported, which is 36ns,27.7mhz?

  next, when the design have timing violation at run time, is there any
way to know which path is causing the problem by probing or some
measure. or is it alway the path/paths reported by the timing analyzer.?

thanks
Sheau Pyng

Project Officer

Center for High Performance Embedded System
Nanyang Technological University,
School Of Applied Science
N4-B3b-06, Nanyang Avenue
Singapore 639798

Tel : (65)-790 6967
Fax : (65)-7926559

Article: 19937
Subject: Re: Need advice on timing problem
From: Ray Andraka <randraka@ids.net>
Date: Wed, 19 Jan 2000 06:52:45 GMT
Links: << >>  << T >>  << A >>
Are you sure you got all the paths covered with the timing constraints?  Run
the timing analyzer and confirm you results there.  Also, make sure you are
meeting timing with the external interfaces.  A common place to have
problems is in an FPGA to memory interface.  The i/o timing isn't covered by
a period constraint.

Oh Sheau Pyng wrote:

> hi,
>   I have problem running a design at the max frequency  recommended in
> the Timing analyse report.
>   the s/w is foundation series 2.1, target is Virtex -4 bg560, the
> function of the design is image processing
>
>   The report give a min period of 29.222ns , but when i downed the
> design into the virtex and clock it at 33.33ns , 30 mhz
>   some of the output image is wrong, ( white dot/pixel can be seen at
> the resultant image).
>
>   When i reduce the frequency to.. say 400K hz , the resultant image is
> Ok.
>
>   So i deduce that it must be because of timing violation.
>
>   just like to know, how to you'll solve this ?
>   at 30 mhz, it is already ~10% slower than the reported worst case. but
> it still didn't work.
>   is this normal, or i should have clock it at ~20% slower then
> reported, which is 36ns,27.7mhz?
>
>   next, when the design have timing violation at run time, is there any
> way to know which path is causing the problem by probing or some
> measure. or is it alway the path/paths reported by the timing analyzer.?
>
> thanks
> Sheau Pyng
>
> Project Officer
>
> Center for High Performance Embedded System
> Nanyang Technological University,
> School Of Applied Science
> N4-B3b-06, Nanyang Avenue
> Singapore 639798
>
> Tel : (65)-790 6967
> Fax : (65)-7926559

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19938
Subject: configurable 8-16 bits processor IP
From: "Pierre VERNEL" <vernel@ensem.u-nancy.fr>
Date: Wed, 19 Jan 2000 16:11:48 +0100
Links: << >>  << T >>  << A >>
On request of S M E, we have designed a configurable 8-16 bits processor IP,
called ProMic, to be best fitted in FPGA. It can be implemented in ACTEL
(ProAsic), ALTERA (Flex 1OK and APEX) or XILINX (VIRTEX).

ProMic is a  fast CPU (more than 30 Millions instructions/s with the today
available FPGA). It can be easily programmed in assembly or in C language

You can download an evaluation version of the development software tools at
this web site:

http://www.design-reuse.com/TOOL/tool_demo.html

and see how you can easily determine the best configuration of ProMic for
your application.

Pierre VERNEL

CRITT MICROLOR
2 avenue de la foret de Haye
F 54516 VANDOEUVRE les NANCY
Tel : +33 (0)3 83 59 55 70
Fax: +33 (0)3 83 59 55 73
Email:vernel@ensem.u-nancy.fr



Article: 19939
Subject: Patent licences for circuits in FPGA
From: Paul Walker <paul@walker.demon.co.uk>
Date: Wed, 19 Jan 2000 16:10:36 +0000
Links: << >>  << T >>  << A >>
It is obvious that if company A makes a UART chip say, and company B has
a patent on the generic features of a UART, then Company A is liable to
have to pay a licence and/or royalty to company B.

Does anyone know of any case history or legal advice concerning company
C who sells an FPGA containing said UART function? No one in Company B
can point to circuitry in the FPGA that embodies the patented
intellectual property. It is possible, I suppose, that if the patent
includes method claims, then it might be possible to use these against a
soft emulation of the patented invention.

I can see a number of possible outcomes:

1: every company who owns an FPGA that is downloaded with a "UART"
program is liable to pay a licence

2: every company that sells design IP of a "UART" is liable to pay a
licence

3: if an FPGA vendor pays a licence, then any customer can use that
vendor's chips to implement the "UART" function

4: no licence is payable at all.

Any ideas which of these might apply?

Paul
-- 
Paul Walker                            Chair of the 1355 Association
                                                        www.1355.org
4Links: 
Boards, chips, IP and consultancy ... for links 
                                                           phone/fax
paul@4Links.co.uk             P O Box 816, Two Mile Ash     +44 1908
http://www.4Links.co.uk       Milton Keynes MK8 8NS, UK       566253
Article: 19940
Subject: Re: Virtex to ASIC conversion
From: s_clubb@NOSPAMnetcomuk.co.uk (Stuart Clubb)
Date: Wed, 19 Jan 2000 16:11:37 GMT
Links: << >>  << T >>  << A >>
I'm sure a major ASIC house such as LSI would be able to help,
depending on your Order Value etc.

On a (perhaps more sensible level?) I think AMI also may have
something similar that would meet your needs:

http://www.amis.com/trans/xilinx.html

Cheers
Stuart

On Tue, 18 Jan 2000 11:58:25 +0000, Rick Filipkiewicz
<rick@algor.co.uk> wrote:

>Does anybody know which ASIC vendors - if any - have dual-port
>independently clocked RAM macros that match the Virtex's Block RAMs ?
For Email remove "NOSPAM" from the address
Article: 19941
Subject: Re: Random Number Generator
From: John Larkin <jjlarkin@highland_SnipThis_technology.com>
Date: Wed, 19 Jan 2000 09:53:22 -0800
Links: << >>  << T >>  << A >>
On 19 Jan 2000 00:16:14 GMT, murray@pa.dec.com (Hal Murray) wrote:

>
>> how about stirring the internal RC osc signal into the innards of a
>> pseudorandom shift register, say by xor'ing the RC signal into some
midpoint
>> of a register clocked by something else. You now have a pseudorandom
>> sequence that is executing essentially random state jumps. Faster is
better
>> here, I think.
>
>I get suspicious when I see suggestions like that.
>
>If you are interested in random numbers, I suggest reading
>Knuth's book.  Yes, it's mostly software, but the introduction
>is a great eye-opener.  It describes a complicated algorithim that
>you can't possibly predict.  It should make total garbage.  But it
>doesn't!
>
>I think you will be better off using techniques that you can
>understand.  Then you will know how good they are and/or where
>the limits are.
>
>You also have to understand how your random numbers will be
>used.  Again, it helps to be able to analyze your random number
>generator to see if it fits into your application.
>
>If you are thinking of using something like an external clock
>to make your randomness more random, be sure you aren't just
>making things harder to understand.  "random state jumps"
>aren't random if they happen at predictable times.  All that does
>is change the output sequence from one pseudo-random pattern to
>a different one.
>
>I think the key parameter is the bandwidth of the noise you can
>get.  If the second clock comes from a crystal you probably won't
>get much noise from it.  On the other hand, it may be a simple and
>inexpensive to merge in a little more randomness.


Hal,

agreed, a random number generator certainly isn't cryptographically, or even
statistically, secure simply because it's confusing to the designer. People
have lost wars making that assumption. But as a source of truly random
addresses for, say, networking applications, something like this is useful
without the hassle of zener noise-diode things and such. Stirring an async
clock into a pseudorandom shift register can be a nice way to 'spread out'
the available randomness, and viewed as random state jumps in the PRN
sequence, is not totally idiotic.

John




Article: 19942
Subject: Re: Patent licenses for circuits in FPGA
From: "Austin Franklin" <austin@da33rkroom.com>
Date: 19 Jan 2000 22:25:00 GMT
Links: << >>  << T >>  << A >>
> It is obvious that if company A makes a UART chip say, and company B has
> a patent on the generic features of a UART, then Company A is liable to
> have to pay a licence and/or royalty to company B.

You can't patent a 'feature' you can only patent a 'method' and possibly
'apparatus' for implementing that 'feature'.  Concepts are not patentable.

> Does anyone know of any case history or legal advice concerning company
> C who sells an FPGA containing said UART function? No one in Company B
> can point to circuitry in the FPGA that embodies the patented
> intellectual property.

Company B would bring suit against company C, and during the 'disclosure'
phase of litigation, company C would have to produce the design documents
to the expert witness chosen by company B to examine them.  Company C would
never see the documents.

> It is possible, I suppose, that if the patent
> includes method claims, then it might be possible to use these against a
> soft emulation of the patented invention.

Patents HAVE to include method claims, that's what a patent is.  Soft
emulation (such as software that does the same thing as hardware) more than
likely won't infringe, because the 'method' is completely different, as
well as the implementation.  There is a big todo about the importance of
the QCOM and IDC patents for CDMA, since DSPs are so much more powerful,
there is no need to do CDMA in dedicated hardware (which is what the
patents are), so one can completely get around their patents by using a
cheap DSP and some software...

> I can see a number of possible outcomes:
> 
> 1: every company who owns an FPGA that is downloaded with a "UART"
> program is liable to pay a licence
> 
> 2: every company that sells design IP of a "UART" is liable to pay a
> licence
> 
> 3: if an FPGA vendor pays a licence, then any customer can use that
> vendor's chips to implement the "UART" function
> 
> 4: no licence is payable at all.
> 
> Any ideas which of these might apply?
> 

Any of those can apply, depending on what the agreement is.  No one is the
'rule'.  If there is no patent infringement, there is no 'royalty' due. 
Royalties must be negotiated, and they may not be given by the patent
holder.  If we're talking about a UART here, I really doubt any patent
would be violated, since most everything to do with a UART will have prior
art, which would negate the possible patent claims.

Realize, just because a patent is issued does not mean it is valid.  The
only time a patent is valid, is when it is upheld in court, period.  The
patent examiners (with all due respect) aren't the brightest bulbs on the
tree for computer hardware/software.

For fishing lure patents, they are the best in the world!  Where else could
you get paid $60k to talk about fishing lures day in and day out....so, if
your patent involves fishing lures, you can be sure, they got it right. 
Now, for electronics, they patent office isn't going to attract the best
there is for $60k, these guys are going to be working for some electronics
company drawing 2x the salary the patent office will pay them...  Just
something to keep in mind about computer hardware/software patents...

It's not really clear what you are trying to find out here.  If you could
tell me a bit more about what it is your concern is, I could possibly try
to help...

Be aware that copyright is entirely different than patent.  If you find a
copy of my schematic, and decide to re-enter it, and use it, with no or
'little' change, you are violating my copyright (assume the original was
properly marked as such).


Article: 19943
Subject: looping FIFO?
From: "Austin Franklin" <austin@da33rkroom.com>
Date: 19 Jan 2000 22:29:18 GMT
Links: << >>  << T >>  << A >>
I know this isn't REALLY an FPGA question, but there are a LOT of bright
people here..so I figured I'd ask.

I am looking for an 8k x 32 FIFO (minimum) that I can load up with data of
arbitrary length, then free-run it so it just keeps outputting data,
looping on the data that is in it, without having to re-load it.

Any ideas?

Article: 19944
Subject: Re: looping FIFO?
From: Ray Andraka <randraka@ids.net>
Date: Wed, 19 Jan 2000 22:50:26 GMT
Links: << >>  << T >>  << A >>
If you are looking for a FIFO device to do that, use the retransmit feature
that is present on many FIFOs.  You do have to do a reset of the FIFO before
you load your data so that the retransmit starts at the right place.

If this is to go with an FPGA, then it would be cheaper and easier to use an
SRAM with the FPGA and have the FPGA take care of loading then 'looping' on
the data in it.

Austin Franklin wrote:

> I know this isn't REALLY an FPGA question, but there are a LOT of bright
> people here..so I figured I'd ask.
>
> I am looking for an 8k x 32 FIFO (minimum) that I can load up with data of
> arbitrary length, then free-run it so it just keeps outputting data,
> looping on the data that is in it, without having to re-load it.
>
> Any ideas?

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19945
Subject: Altera Quartus vs Xilinx Place and Route tools (help needed)
From: "giuseppe giachella" <il_templare@hotmail.com>
Date: Thu, 20 Jan 2000 00:57:09 +0100
Links: << >>  << T >>  << A >>
It's almost four days that I'm having some devastating experiences using
Quartus
99.10 SP2. It happens that sometimes the fitter goes into an endless loop
(showing
the same fitting percentage for hours and hours). Sometimes the fitting is
completed
but the Delay Annotation causes an internal error.
I fear I'm only wasting my time: this Quartus release seems to be full of
bugs and
I'm planning to abandon Altera in favour of Xilinx Virtex.
But what about Xilinx place and route tools? Are they so buggy ?
Should I expect the same neverending fitting loops using Xilinx tools
(Alliance or
Foundation) ?


 Sent via Deja.com http://www.deja.com/
 Before you buy.
Article: 19946
Subject: Re: looping FIFO?
From: allan.herriman.hates.spam@fujitsu.com.au (Allan Herriman)
Date: Thu, 20 Jan 2000 01:23:58 GMT
Links: << >>  << T >>  << A >>
On 19 Jan 2000 22:29:18 GMT, "Austin Franklin" <austin@da33rkroom.com>
wrote:

>I know this isn't REALLY an FPGA question, but there are a LOT of bright
>people here..so I figured I'd ask.
>
>I am looking for an 8k x 32 FIFO (minimum) that I can load up with data of
>arbitrary length, then free-run it so it just keeps outputting data,
>looping on the data that is in it, without having to re-load it.
>
>Any ideas?

You might like to try some of the newer dual port ram devices from
Cypress or IDT.
They have synchronous parts with burst counters.  The burst counters
can be made to free run over the entire size of the ram.
The burst counters can be reset (there's a dedicated pin per port for
this), or preset (using another dedicated pin, which causes the
counter to be loaded from the address input for that port).

You can load the data using the other port (with random access from a
microprocessor, for example).

They're not cheap though, particularly for the fastest or largest ones
(up to 133MHz, 64k x 36, IIRC).  They eat power, too.

Sounds like an arbitrary waveform or pattern generator?

http://www.cypress.com/dualport/index.html
http://www.idt.com/products/pages/Multi-Port.html

Regards,
Allan.
Article: 19947
Subject: Re: looping FIFO?
From: "Austin Franklin" <austin@darkroom88.com>
Date: 20 Jan 2000 02:44:56 GMT
Links: << >>  << T >>  << A >>
Thanks Ray.  I looked at that re-transmit feature, but it isn't really
explained well (on the spec I have)...it eludes that it is only the
'current' 'word' that is re-transmitted, not the entire FIFO...but, if you
say it works, I'll check into it further...

Problem with using SRAM, is I am pinbound at this point...8k is another 14
pins...don't think I can do it...but that would be my first choice....if I
had the pins...


Ray Andraka <randraka@ids.net> wrote in article
<3886400E.FD27C2B9@ids.net>...
> If you are looking for a FIFO device to do that, use the retransmit
feature
> that is present on many FIFOs.  You do have to do a reset of the FIFO
before
> you load your data so that the retransmit starts at the right place.
> 
> If this is to go with an FPGA, then it would be cheaper and easier to use
an
> SRAM with the FPGA and have the FPGA take care of loading then 'looping'
on
> the data in it.
> 
> Austin Franklin wrote:
> 
> > I know this isn't REALLY an FPGA question, but there are a LOT of
bright
> > people here..so I figured I'd ask.
> >
> > I am looking for an 8k x 32 FIFO (minimum) that I can load up with data
of
> > arbitrary length, then free-run it so it just keeps outputting data,
> > looping on the data that is in it, without having to re-load it.
> >
> > Any ideas?
> 
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email randraka@ids.net
> http://users.ids.net/~randraka
> 
> 
> 
Article: 19948
Subject: Re: looping FIFO?
From: "Austin Franklin" <austin@darkroom88.com>
Date: 20 Jan 2000 02:46:27 GMT
Links: << >>  << T >>  << A >>
Thanks for the idea...I'll look into it.
 
> Sounds like an arbitrary waveform or pattern generator?

You are right, sir!  It is for a pattern generator...

Article: 19949
Subject: Re: looping FIFO?
From: murray@pa.dec.com (Hal Murray)
Date: 20 Jan 2000 03:00:23 GMT
Links: << >>  << T >>  << A >>

In article <01bf62f0$415d2640$207079c0@drt1>,
 "Austin Franklin" <austin@darkroom88.com> writes:

> Thanks Ray.  I looked at that re-transmit feature, but it isn't really
> explained well (on the spec I have)...it eludes that it is only the
> 'current' 'word' that is re-transmitted, not the entire FIFO...but, if you
> say it works, I'll check into it further...

I've never used that feature on a FIFO, but the data sheet seems
as though it was describing what you would want if you were
going to "retransmit" a packet after an Ethernet collision.

[A comment about the "current" word may be telling you something
about a pipeline stage that you have to flush.]
-- 
These are my opinions, not necessarily my employers.


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