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 11400

Article: 11400
Subject: Re: Security
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 10 Aug 1998 09:41:28 -0700
Links: << >>  << T >>  << A >>
Graeme Durant wrote:

>  It is possible to use
> the inherent volatility of sram-based fpgas as an asset to security.
> If you programme the design into the device in the factory, battery
> back it up to keep it in-situ for normal use, then fit tamper sensors
> on the casework of your product (microswitches, tilt switches
> whatever).

It's actually simpler than that:Find an "SRAM-based" FPGA with low
standby current consumption (XC3000 in Powerdown have the lowest, but
XC4000XL are not so bad ) and provide sufficient battery capacity to
maintain configuration during any ac power-outs.
Set the bit that diables Readback, and you can be sure that nobody can
reverse-engineer your code.
It would require keeping the device powered up, de-capping the (plastic)
package, and using a very sophisticated instrument to detect on-chip
voltage levels at undocumented locations. No way !
See the Xilinx data book, page 13-43 "Design Security by Hiding the
Configuration Bitstream".
Contact me, if you have additional questions

Peter Alfke, Xilinx Applications
 

Article: 11401
Subject: Re: PCI Core Thanks
From: "Andy Peters" <apeters@noao.edu.NOSPAM>
Date: 10 Aug 1998 23:23:57 GMT
Links: << >>  << T >>  << A >>
Simon Ramirez <s_ramirez@email.msn.com> wrote in article
<ugxDRW0w9GA.329@upnetnews05>...
> To Everyone Who Responded:
>    Thanks to everyone who responded to my plea for information
about FPGA
> PCI cores information.  I received some good and varied information
about
> these cores and what to do with them and without them.
>    The information I received makes me think that my silicon vendor
choice
> will be critical and the design effort will be moderately
difficult.
>    When I make my decision about which vendor to select, do my
design and
> gain some experience with the design, I will post another message
to let
> everyone know how it went.  I would like to see more information
posted
> about FPGA PCI designs as I have found out that FPGA PCI designs
are about
> to start taking off more and more.

Yes, Simon, let us know what you choose and how it goes.  It's
looking like I'll have to do a PCI design Real Soon Now and I do want
to know what happens with your design.

-andy

-- 
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatories
apeters@noao.edu.NOSPAM


Article: 11402
Subject: Re: Radiation and Relaibility
From: rk <stellare@erols.com>
Date: Mon, 10 Aug 1998 22:09:46 -0400
Links: << >>  << T >>  << A >>
jim granville wrote:

> <snip of some fantastic stuff :-) >
>

> Very interesting - can those with experience in Radiation Enginnering, bring a more
> terestial level to this, and quantify the difference in Radiation levels
>     - on the earths surface ?
>     - in Jumbo Jets ?
>     - and in Orbit ?

for ground stuff, it is starting to be a bit of concern, for extremely large memories, for
example.  there was a symposium on this last year, you might want to contact
michele.gates@gsfc.nasa.gov for info (can't remember if there's one 'l' or two in her name, i
always get it wrong).perhaps they put some proceedings together.    and recently one of the
trade rags had an article by an ibm engineer studying this for large computers.  obviously,
the higher you go the higher the radiation levels.  they run experiments by putting dosimetry
on airplanes, recently saw a paper where they loaded it onto a concorde (presented at ieee
nsrec '98).  of course, when you do some work in a radiation facility, they assure you that
the dose you got on the cross-country flight was higher than the dose you'll get there.
yeah, right. :-)  anyways, contact michele for rate info.  i think they're having a session
in another conference this fall on the topic, perhaps at sematech.  if anyone wants info,
drop me an email, i got the info somewhere.

also, at ieee nsrec, saab and xilinx had a paper on a topic related to this:

    Neutron Single Event Upsets In SRAM-Based FPGAs
    Abstract -
    SRAM-based FPGAs have been studied for their sensitivity to atmospheric high energy
    neutrons. FPGAs with the supply voltage 5V and 3.3V were irradiated by 0-11, 14 and
    100 MeV neutrons and showed a very low SEU susceptibility.

this is available on-line at: http://rk.gsfc.nasa.gov/papers.htm
____________________________________________________________________

>  My understanding of this is that you still get radiation hits at gnd level, just not as
> many of them.
>
>  What is statistically significant depends on your point of view.
>
>  I also recall seeing something about Radiation triggering LATCHUP - how do the redundant
> engineering approaches handle that problem :-)

not very well.  gotta be able to isolate power, etc., etc., etc.  typically a latchup
detection circuit is used that can control power.  system design must be able to tolerate the
light's blinking by saving state, restoring, etc.  this type of stuff is done.

> - jg

rk
p.s. someone spelled 'reliability' wrong in the subject :-)

Article: 11403
Subject: Re: Gray code counter in ABEL HDL?
From: "Mankit Wong" <mankit_wong@latticesemi.com>
Date: 11 Aug 1998 05:43:30 GMT
Links: << >>  << T >>  << A >>
Hi,

This is ABEL code for grey code up counter (CGU14) in Lattice Macro
Library.
Hope this can help you.

Regards,
Man Kit

MODULE CGU14

CLK,CD,EN,PS	PIN;
D3..D0,LD	PIN;
Q3..Q0		PIN ISTYPE 'REG_D';
N_Q3..N_Q0	NODE ISTYPE 'COM';

count = [Q3..Q0];
data = [D3..D0];
n_count = [N_Q3..N_Q0];

EQUATIONS
count.CLK = CLK;
count.AR = CD;
count.D = n_count;
N_Q0 = (Q0 & !LD & !EN) # (D0 & LD) # (!Q3 & !Q2 & !Q1 & !LD & EN) # (!Q3 &
Q2 & Q1 & !LD & EN) # 
       (Q3 & Q2 & !Q1 & !LD & EN) # (Q3 & !Q2 & Q1 & !LD & EN) # PS;
N_Q1 = (Q1 & !LD & !EN) # (D1 & LD) # (Q1 & !Q0 & !LD & EN) # (!Q3 & !Q2 &
Q0 & !LD & EN) # 
       (Q3 & Q2 & Q0 & !LD & EN) # PS;
N_Q2 = (Q2 & !LD & !EN) # (D2 & LD) # (!Q3 & Q1 & !Q0 & !LD & EN) # (Q2 &
!Q1 & !LD & EN) # 
       (Q2 & Q0 & !LD & EN) # PS;
N_Q3 = (Q3 & !LD & !EN) # (D3 & LD) # (Q2 & !Q1 & !Q0 & !LD & EN) # (Q3 &
Q0 & !LD & EN) # 
       (Q3 & Q1 & !LD & EN) # PS;
END


Marc Heuler <marc@aargh.franken.de> wrote in article
<+-pMC*BFo@aargh.franken.de>...
> I want to implement a Gray code counter (16 bit) in ABEL HDL for the
> Lattice 1016 device.
> 
> Are there gray-code-counter examples on the net?
> 
Article: 11404
Subject: Re: Security
From: z80@ds2.com (Peter)
Date: Tue, 11 Aug 1998 08:05:59 GMT
Links: << >>  << T >>  << A >>

>In the past, I have always assumed that the 'hide it away' approach to
>security in fpgas was the only one available. However, I recently came
>accross a much more interesting approach.  It is possible to use
>the inherent volatility of sram-based fpgas as an asset to security.
>If you programme the design into the device in the factory, battery
>back it up to keep it in-situ for normal use, then fit tamper sensors
>on the casework of your product (microswitches, tilt switches
>whatever).  These tamper sensors need to 'evaporate' the design
>by resetting the device.  In this way an attack on the product will
>find nothing of a proprietory nature.  This approach can be taken
>further as regards any microprocessor program storage or whatever.

This self-destruct feature has been used for many years in line
encryptors used in banking etc comms.

One has switches on the lid, the PCB is potted in epoxy with sensing
wire wrapped round it, light sensitive devices inside the box (to
detect someone opening the box and looking inside), etc. There is a
battery+capacitor and the EPROM/EEPROM/SRAM/whatever gets destroyed if
tampering is detected.


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.
Article: 11405
Subject: Announcement: Now available 200.000 Gates Development Boards
From: Lothar Brodbeck <brod@lts.sel.alcatel.de>
Date: Tue, 11 Aug 1998 10:48:00 +0200
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------19E5BB001702AC4EF3F31801
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello reader,

i would announce two development boards of Alcatel Telecom.
The two boards are useful for ASIC prototyping and simulation.
We already used the boards to verify DSP algorithms written in
VHDL, to test the behaviour of PLL circuits, to built test
equippment (complex signal generators written in VHDL) for our
fab and for other applications.


Short description of the boards:

HW_SIM

* 200.000 gates logical resources (4*Altera EPF10K50)
  (300.000 gates if equpipped with 1EPF10K70)
* 2 Slots for SIMM memory modules (30 pin types)
* 2 on board oscillators (48,640 MHz, 16,384MHz)
* PBA size 233mm*210mm
* breadboard area
* reset circuit
* ...

DEV_KIT

* 20.000 gates logical resource (2*Altera EPF81188)
* on board oscillator (16,384 MHz)
* PBA size 233mm*160mm (possible splitting 2 times 100mm*160mm)
* breadboard area
* reset circuit
* ...

For more information about the development boards contact
one of the persons listed below.


Financial Questions:    R.Prestin@alcatel.de

Technical Questions:    brod@lts.sel.alcatel.de


Best regards Lothar Brodbeck

p.s.

An user wrote:  ... We successfully used the HW_SIM development
                board to verify our complex signal processing
                algorithm. ... The programming and the handling
                of the evaluation board stands out. ...


You can find a description and pictures of the boards using the
following address:

http://www.dev.alcatel.de/telecom/asd/test_hw/topdevboard.htm


--------------19E5BB001702AC4EF3F31801
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Lothar Brodbeck
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Lothar Brodbeck
n:              Brodbeck;Lothar
org:            Alcatel Telecom
adr:            Lothar Brodbeck;;Department AS/HEC;Lorenzstrasse 10;70435 Stuttgart;;Germany
email;internet: brod@lts.sel.alcatel.de
title:          Development Engineer
tel;work:       +49 711 821 47334
tel;fax:        +49 711 821 45069
note;quoted-printable:Telephone 	+49 711 821 47334=0D=0A=
	Fax		+49 711 821 45068	
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


--------------19E5BB001702AC4EF3F31801--

Article: 11406
Subject: VHDL-C
From: benjamin.carrion-schaefer@hl.siemens.de
Date: Tue, 11 Aug 1998 12:42:50 GMT
Links: << >>  << T >>  << A >>
Hello to everbody !!!

I want to insert C functions in VHDL code .I have heard that this can be done
using foreign architectures,but how do I have to write my C code in order to
get the parameters passed by the VHDL code and how can I return values ?

Thank you very much in advanced .

Benjamin

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


Article: 11407
Subject: THE CHEAPEST ORCAD SOFTWAREZ!
From: turas@takas.lt
Date: Tue, 11 Aug 1998 13:19:25 GMT
Links: << >>  << T >>  << A >>
>>>>>>>>>  SPAM deleted by Archive Owner


Article: 11408
Subject: Re: Security
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Date: 11 Aug 1998 13:26:45 GMT
Links: << >>  << T >>  << A >>


gd@nospamheliontech.com (Graeme Durant) writes:

>On 8 Aug 1998 00:32:13 GMT, "Robert Semenoff"
><robert_semenoffNOSPAM@phoenix.com> wrote:

>>I am trying to determine the most secure way of implementing
>>proprietary algorithms.

>In the past, I have always assumed that the 'hide it away' approach to
>security in fpgas was the only one available. However, I recently came
>accross a much more interesting approach.  It is possible to use
>the inherent volatility of sram-based fpgas as an asset to security.
>If you programme the design into the device in the factory, battery
>back it up to keep it in-situ for normal use, then fit tamper sensors
>on the casework of your product (microswitches, tilt switches
>whatever).  These tamper sensors need to 'evaporate' the design
>by resetting the device.  In this way an attack on the product will
>find nothing of a proprietory nature.  This approach can be taken
>further as regards any microprocessor program storage or whatever.

It depends on what level of sophistication you're expecting from your 
attackers.  DRAM contents can be recovered hours after power is removed, even 
longer if you store it at low temperatures.  SRAM is even worse, in extreme 
cases it's possible to recover the state months later.  I touch on this 
briefly towards the end of 
http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html, one day I'll 
finally get around to extending this section a bit.
 
Peter.

Article: 11409
Subject: Combinatoric Divide-by-3 Algorithm
From: "Kenneth W. Wagner" <Kenneth.W.Wagner.1@gsfc.nasa.gov>
Date: Tue, 11 Aug 1998 09:50:52 -0400
Links: << >>  << T >>  << A >>
I need to implement in an fpga an algorithm that will divide an integer
by 3.  The dividend length is still to be determined but will be
somewhere between 20 and 30 bits, and the divisor is always the number
3.

Does anyone know an efficient combinatoric algorithm that can accomplish
this?

Thanks in advance,
Ken


Article: 11410
Subject: software measurement for realtime systems
From: "Total Metrics Editor" <editor@totalmetrics.com>
Date: 11 Aug 98 13:57:20 GMT
Links: << >>  << T >>  << A >>
Hi,

We have just launched a new Software Metrics site at
http://www.totalmetrics.com

We have an interest in software measurement for realtime and embedded
systems.  There is some information on training courses in this area and we
will be posting papers on this subject soon.  Look at our html newsletter
for more information.
http://www.totalmetrics.com/newsletter/news9807.htm

If you have any experience, links or news you would like to share in this
area, please forward it to
editor@totalmetrics.com

Thank you,

Jin Ng
editor@totalmetrics.com

Article: 11411
Subject: Re: Security
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Tue, 11 Aug 1998 10:19:10 -0400
Links: << >>  << T >>  << A >>
> It depends on what level of sophistication you're expecting from your
> attackers.  DRAM contents can be recovered hours after power is removed, even
> longer if you store it at low temperatures.  SRAM is even worse, in extreme
> cases it's possible to recover the state months later.  I touch on this
> briefly towards the end of
> http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html, one day I'll
> finally get around to extending this section a bit.
>
> Peter.

 The military cryptos I dealt with some 12-13 years ago re-wrote the memory
several times with a random pattern as part of the destruct sequence.  The SRAM
FPGA configuration memory cell is more akin to a shift register made of
flip-flops than to SRAM memory.  I'm not sure how that affects retention of
residual levels (I suspect it makes the residual even stronger).  I don't see any
reason you couldn't write in a couple of dummy configurations during the destruct
sequence to obliterate the real configuration though.

--
-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: 11412
Subject: Re: Combinatoric Divide-by-3 Algorithm
From: jeroen@cs.uu.nl (Jeroen Fokker)
Date: 11 Aug 1998 14:32:18 GMT
Links: << >>  << T >>  << A >>
>I need to implement in an fpga an algorithm that will divide an integer
>by 3. 

   // PRE: a>=0
   q = 0;
   r = a+1;
   while (r>=4)
   {
      x = r/4;  // can be implemented by shifting
      y = r%4;  // can be implemented by ANDing
      q = q+x;
      r = x+y;
   }
   // POST: a==3*q+r && 0<=r && r<3
   // that is:  q==a/3

--   
Jeroen Fokker                                 |  jeroen@cs.uu.nl
dept.of Computer Science, Utrecht University  |  tel.+31-30-2534118
PObox 80089, 3508TB Utrecht, the Netherlands  |  fax.+31-30-2513791
Article: 11413
Subject: ANNOUNCEMENT: The Programmable Logic Jump Station (www.optimagic.com)
From: "Steven K. Knapp" <sknapp@optimagic.com>
Date: Tue, 11 Aug 1998 07:42:55 -0700
Links: << >>  << T >>  << A >>
See the latest on FPGAs, CPLDs, and related software on
The Programmable Logic Jump Station at


                   http://www.optimagic.com/


The Programmable Logic Jump Station is a comprehensive set of
links to nearly all matters related to programmable logic.



Featuring:
---------


          --- Frequently-Asked Questions (FAQ) ---


Programmable Logic FAQ - http://www.optimagic.com/faq.html
A great resource for designers new to programmable logic.



          --- FPGAs, CPLDs, FPICs, etc. ---


Recent Developments - http://www.optimagic.com
Find out the latest news about programmable logic.


Device Vendors - http://www.optimagic.com/companies.html
FPGA, CPLD, SPLD, and FPIC manufacturers.


Device Summary - http://www.optimagic.com/summary.html
Who makes what and where to find out more.


Market Statistics - http://www.optimagic.com/market.html
Total high-density programmable logic sales and market share.



            --- Development Software ---


Free and Low-Cost Software - http://www.optimagic.com/lowcost.html
Free, downloadable demos and evaluation versions from all the major
suppliers.


Design Software - http://www.optimagic.com/software.html
Find the right tool for building your programmable logic design.


Synthesis Tutorials - http://www.optimagic.com/tutorials.html
How to use VHDL or Verilog.



              --- Related Topics ---


FPGA Boards - http://www.optimagic.com/boards.html
See the latest FPGA boards and reconfigurable computers.


Design Consultants - http://www.optimagic.com/consultants.html
Find a programmable logic expert in your area of the world.


Research Groups - http://www.optimagic.com/research.html
The latest developments from universities, industry, and
government R&D facilities covering FPGA and CPLD devices,
applications, and reconfigurable computing.


News Groups - http://www.optimagic.com/newsgroups.html
Information on useful newsgroups.


Related Conferences - http://www.optimagic.com/conferences.html
Conferences and seminars on programmable logic.


Information Search - http://www.optimagic.com/search.html
Pre-built queries for popular search engines plus other
information resources.


The Programmable Logic Bookstore - http://www.optimagic.com/books.html
Books on programmable logic, VHDL, and Verilog.  Most can be
ordered on-line, in association with Amazon.com



            . . . and much, much more.


Bookmark it today!




Article: 11414
Subject: Re: Combinatoric Divide-by-3 Algorithm
From: "John L. Smith" <jsmith@visicom.com>
Date: Tue, 11 Aug 1998 13:12:20 -0400
Links: << >>  << T >>  << A >>

Kenneth W. Wagner wrote:

> I need to implement in an fpga an algorithm that will divide an integer
> by 3.  The dividend length is still to be determined but will be
> somewhere between 20 and 30 bits, and the divisor is always the number
> 3.
>
> Does anyone know an efficient combinatoric algorithm that can accomplish
> this?
>
> Thanks in advance,
> Ken

Approximation to N/3:

  [Image]
Hope you can read the above. The quantities in parentheses only
needs to be evaluated once, all others are shifts and adds.  Extend the
ellipses
to desired output accuracy. Do summation from right to left to minimize
size of adders.

Alternatively, use KCM (constant coefficient multiplier), which breaks
dividend
into 4-bit groups, feeds each group k( =  0..m)  into 16 x (4k+n) LUT, then
sums
all LUT outputs. Read further about KCMs at Xilinx web site.

The KCM is more efficient in a Xilinx part than an unrolled version of the
adder only
circuit.
Both adder and KCM may be 'rolled-up'.

>>>>>>>>>  File binary deleted by Archive Owner



Article: 11415
Subject: Re: Combinatoric Divide-by-3 Algorithm
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Tue, 11 Aug 1998 14:47:01 -0400
Links: << >>  << T >>  << A >>


Kenneth W. Wagner wrote:

> I need to implement in an fpga an algorithm that will divide an integer
> by 3.  The dividend length is still to be determined but will be
> somewhere between 20 and 30 bits, and the divisor is always the number
> 3.
>
> Does anyone know an efficient combinatoric algorithm that can accomplish
> this?
>
> Thanks in advance,
> Ken

You can treat this as a constant multiply by 1/3.  The multiplication can
then be done as a look up of partial products.  Each 4 bits of the dividend
goes into a look up that is as wide as necessary to get the required output
precision.  Each look up outputs 0/3, 1/3, 2/3, ... ,15/3.  The outputs of
each lookup are then shifted and summed in an adder tree.  The tree depth is
proportional to log(input bits). This can be entirely combinatorial, can be
pipelined, or can be broken down into a sequential algorithm depending on
your performance needs.  The xilinx core generator can generate pre-placed
optimized constant multipliers for you.

--
-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: 11416
Subject: Re: Combinatoric Divide-by-3 Algorithm
From: Catalin <baetoc@nt.com>
Date: Tue, 11 Aug 1998 15:18:01 -0400
Links: << >>  << T >>  << A >>
Keneth,

1/4+1/16+1/64+1/256+1/1024+...=1/3. So shift your number by 2, 4, 6, 8, etc.
and add everithing.

Catalin Baetoniu

Kenneth W. Wagner wrote:

> I need to implement in an fpga an algorithm that will divide an integer
> by 3.  The dividend length is still to be determined but will be
> somewhere between 20 and 30 bits, and the divisor is always the number
> 3.
>
> Does anyone know an efficient combinatoric algorithm that can accomplish
> this?
>
> Thanks in advance,
> Ken



Article: 11417
Subject: International Corp. looking for Digital/microprocessor Designer
From: rsizingsol@aol.com (RSizingSol)
Date: 11 Aug 1998 20:13:28 GMT
Links: << >>  << T >>  << A >>
There are multiple positions open for the following direct hire position. 
Interested individuals should responde to RSizingSol@aol.com

Description:  You will design chips and/or boards and assist with sytem
integrations.  Products will include the design of high bandwidth electro-optic
interfaces, sensors, laser modulators/controllers, photodectors,
micro-positioning control circuits, microprocessor subsystems and power/ground
systems.  Work will be performed using state of the art design and analysis
tools.  Experience with most of the following is required:
Design/simulation/test using TTL, ECL, PECL and CMOS technologies
Design/simulation/test using FPGA (alters), and PLD devices (HDL languge
experience is desired)
Design, simulation and test of microprocessor or DSP subsystems (some
programming experience is desired)
EDA tools (e.g. viewlogic, mentor, candence)

This position requires relocation to western NY.  Excellent benefits and salary
with goal sharing option and relocation.

Article: 11418
Subject: Re: Combinatoric Divide-by-3 Algorithm
From: "John L. Smith" <jsmith@visicom.com>
Date: Tue, 11 Aug 1998 16:33:49 -0400
Links: << >>  << T >>  << A >>

John L. Smith wrote:

> Kenneth W. Wagner wrote:
>
>> I need to implement in an fpga an algorithm that will divide an
>> integer
>> by 3.  The dividend length is still to be determined but will be
>> somewhere between 20 and 30 bits, and the divisor is always the
>> number
>> 3.
>>
>> Does anyone know an efficient combinatoric algorithm that can
>> accomplish
>> this?
>>
>> Thanks in advance,
>> Ken
>
[Image]


Extending this to 20 bits would require 3 (LUT) + 11.5(Adder) more CLBs
for total of 49.
    "             24                    3       +
13.5                               65.5
                  28                    3       +
15.5                               84
                  32                    3       +
17.5                              104.5

Unfortunately, the fully parallel implementation of the KCM is O(N^2)
due to the increasing
size of the adders required. A rolled up (serialized) version would be
O(N), but would
also take O(N) time.

I hope no one minds the JPG, it's how the cut and paste worked.

>>>>>>>>>  Stupid file binary deleted by Archive Owner


Article: 11419
Subject: Power Consumption
From: Philllip Cook <cook-pa@eelab.usyd.edu.au>
Date: Wed, 12 Aug 1998 16:53:27 +1000
Links: << >>  << T >>  << A >>
Hi,
I was wondering if anyone knew how to simulate the power
consumption from a Xilinx FPGA. I have completed the 
design(first draft) and would like to estimate if I can
get further power consumption with modifications to the 
design.

TIA,
Phil.
Article: 11420
Subject: Re: Combinatoric Divide-by-3 Algorithm
From: "Erwin Oertli" <oertli@inf.ethz.ch>
Date: Wed, 12 Aug 1998 09:50:39 +0200
Links: << >>  << T >>  << A >>
You can further reduce additions. With only 4 additions you can divide 32
bits by 3, the divisions are free.

  1/4
  + [1/4] / 4
  + [1/4 + [1/4] / 4 ] / 16
  + [1/4 + 1[1/4] / 4 + [1/4 + [1/4] / 4 ] / 16] / 256
  + ...

--
Erwin Oertli
mailto:oertli@inf.ethz.ch
http://www.cs.inf.ethz.ch/~oertli

Catalin wrote in message <35D098E9.764ABCC0@nt.com>...
>Keneth,
>
>1/4+1/16+1/64+1/256+1/1024+...=1/3. So shift your number by 2, 4, 6, 8,
etc.
>and add everithing.
>
>Catalin Baetoniu
>
>Kenneth W. Wagner wrote:
>
>> I need to implement in an fpga an algorithm that will divide an integer
>> by 3.  The dividend length is still to be determined but will be
>> somewhere between 20 and 30 bits, and the divisor is always the number
>> 3.
>>
>> Does anyone know an efficient combinatoric algorithm that can accomplish
>> this?
>>
>> Thanks in advance,
>> Ken
>
>
>


Article: 11421
Subject: Re: VHDL-C
From: Chris.omitthisbit.Brown@arm.andthisbit.com
Date: 12 Aug 1998 09:43:16 GMT
Links: << >>  << T >>  << A >>
In article <6qpe8a$uqp$1@nnrp1.dejanews.com>,
 <benjamin.carrion-schaefer@hl.siemens.de> wrote:
>Hello to everbody !!!
>
>I want to insert C functions in VHDL code .I have heard that this can be done
>using foreign architectures,but how do I have to write my C code in order to
>get the parameters passed by the VHDL code and how can I return values ?
>
>Thank you very much in advanced .

Depends entirely on which simulator you are using.
--
/*  _  */main(int k,char**n){char*i=k&1?"+L*;99,RU[,RUo+BeKAA+BECACJ+CAACA"
/* / ` */"CD+LBCACJ*":1[n],j,l=!k,m;do for(m=*i-48,j=l?m/k:m%k;m>>7?k=1<<m+
/* |   */8,!l&&puts(&l)**&l:j--;printf("  \0_/"+l));while((l^=3)||l[++i]);}
/* \_,hris Brown -- All opinions expressed are probably wrong. */
Article: 11422
Subject: Re: Combinatoric Divide-by-3 Algorithm
From: Harald Vefling <hv@vingmed.no>
Date: Wed, 12 Aug 1998 12:23:15 +0200
Links: << >>  << T >>  << A >>
Nice, 

Can one systematically find similar fast converging recursive algorithms
for scaling by other fixed but freely chosen numbers?  

For example: What if one would like to scale a CORDIC generated result
back to same reference level as the inputs had? (Rect. to Polar
conversion) Output should then be a fixed multiply by 0.607253 (for 16
bit precision)

I tried this once and I think I came close to 16 bit precision with 4
(19 bit) adders, but I found the shifts and add/subtracts by trial and
error, not by formal analysis.  I always wondered if it could be reduced
to 3 adders, but didn't find time to take it any further.

How did you find the series expansion you used? 
(maybe I should dig out my old math books to find this, Sorry if the
answer is obvious)

Harald Vefling
Vingmed Sound AS





Erwin Oertli wrote:
> 
> You can further reduce additions. With only 4 additions you can divide 32
> bits by 3, the divisions are free.
> 
>   1/4
>   + [1/4] / 4
>   + [1/4 + [1/4] / 4 ] / 16
>   + [1/4 + 1[1/4] / 4 + [1/4 + [1/4] / 4 ] / 16] / 256
>   + ...
> 
> --
> Erwin Oertli
> mailto:oertli@inf.ethz.ch
> http://www.cs.inf.ethz.ch/~oertli
> 
> Catalin wrote in message <35D098E9.764ABCC0@nt.com>...
> >Keneth,
> >
> >1/4+1/16+1/64+1/256+1/1024+...=1/3. So shift your number by 2, 4, 6, 8,
> etc.
> >and add everithing.
> >
> >Catalin Baetoniu

-- snip
Article: 11423
Subject: Re: Security
From: ems@nospam.riverside-machines.com (ems)
Date: Wed, 12 Aug 1998 11:17:30 GMT
Links: << >>  << T >>  << A >>
i did a Z80 board about 15 years ago, with test code in a windowed
eprom. there was one occasion when i erased the eprom, and wrote in a
completely different program. the board wasn't working correctly, and
I eventually froze the eprom. amazingly, for a couple of minutes, the
processor executed the old, 'erased', code sequence, before reverting
to the new code. it only happened once - i never managed to duplicate
it.

evan

Article: 11424
Subject: FFT-Speed
From: Thomas Focke <thomas.focke@himh1.hi.bosch.de>
Date: Wed, 12 Aug 1998 17:08:46 +0200
Links: << >>  << T >>  << A >>
I'm looking for a comparison regarding achievable FFT-speed between
FPGA vs. DSP-solutions. 
For instance: DSP TMS C6x can manage a 1024 point-FFT in 104 µs.
Which FPGA can achieve which speed?
Is there a comprehensive table in the web? 

Who can help me?

Thomas


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