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 11375

Article: 11375
Subject: Re: Silicore VHDL 8-bit RISC uC core for FPGA
From: "Austin Franklin" <dark6room@ix.netcom.com>
Date: 7 Aug 1998 15:11:07 GMT
Links: << >>  << T >>  << A >>
Eric Ryherd <"vauto@tiac.net"@tiac.net> wrote in article
<6q7ef1$av1@news-central.tiac.net>...
> 
> However, I recommend using VAutomations V8-microRISC CPU 

Er, Eric, are you at all affiliated with VAutomation in any way that you
would 'recommend' your...oops, their ;-) product over any other?

Article: 11376
Subject: Re: PCI Core In FPGA
From: Al Zimmerman <alz@RayCast.com>
Date: Fri, 07 Aug 1998 09:02:23 -0700
Links: << >>  << T >>  << A >>
Evan,

I'm sure you know what you talking about.  But I guarantee you that
graphics chip vendors are avoiding any & all ring3/ring0 transitions.
I've worked at enough.  All drivers written by the chip vendor are
memory mapped in chipset (BX, LX, Triton,....etc).  The OS is not even
involved in determining whether to transfer the info to main memory or
onto the PCI bus.  Alternatively, you could use the DDK from Microsoft
and have the OS determine whether to access the pci bus.

With all that said, the graphics chip will do most of the transferring
anyway by mastering the pci bus and reading the data from main memory.
The goal is to get the request command to the graphics chip ASAP.  The
fastest way to do this is to get the OS out of the way.

All the above applies to 3d graphics.  AS I think about it, you could
very well have the OS involved in 2d graphics.  Most applications will
not have speed issues with 2d graphics so the having the OS performing
virtual addressing onto the pci bus will not be a big deal.  In 3d, you
are moving vast amounts of data (polygons & textures) where any latency
will slow down the 3d rendering. 

If you still disagree....I've not doubt you know what you are talking
about.  I really can't say anymore so I won't respond further on this.
Besides, we are getting out of the realm of this newsgroup.

All the Best !!

Al


ems wrote:
> 
> On Thu, 06 Aug 1998 09:05:29 -0700, alz <alz@lanminds.com> wrote:
> 
> >> i can't think of any specific ring 3/ring 0 transitions which have a
> >> significant (or any) impact on a user. however, there are issues
> >> related to scheduling information transfers between the driver and the
> >> user (at interrupt time, for example).
> >
> >
> >For computer graphics the ring3/ring0 transition is significant.  Every
> >graphics chip company around avoids ring3/ring0 transitions in their
> >drivers.
> 
> it doesn't matter what sort of chip or board you're putting on the
> bus. the vast majority of windows pci drivers will not require the use
> of signalling mechanisms, which would involve ring0/ring3 transitions,
> between the driver and the user.
> 
> the only point in most drivers, after initialisation, at which a
> transition occurs, is when a hardware interrupt arrives (and the S3
> card in my test system doesn't even generate interrupts). your ring 0
> driver will receive control fairly quickly, and will then schedule
> some sort of information transfer to the user code. this will involve
> another transition, but this is part of the normal scheduling
> mechanisms and so isn't relevant. in short, ring0/ring3 transitions
> simply aren't relevent, whether or not you're using interrupts.
> 
> what you're thinking about may be the issue of virtualising the PC
> display. there are circumstances in which the OS will create multiple
> virtual copies of physical display memory, and will then trap any
> accesses to this memory, so that display drivers can pretend that they
> have exclusive control over the display. this isn't an issue with pci
> drivers, and you still need the ddk, or an equivalent, to write your
> pci driver.
> 
> evan
Article: 11377
Subject: Re: Delay Element for async design.
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Fri, 07 Aug 1998 09:16:18 -0700
Links: << >>  << T >>  << A >>
Rickman wrote:

> One source of variation that you left out is changes (over the
> lifetime
> of a part) in the detail design and techology of a part. Xilinx
> published an app note on this and indicated that they reserve the
> right
> to alter the internal workings of a part to make it more
> manufacturable.
> So even if you make the logic delay dominate over routing delay, the
> logic delay of any given portion of the chip may be greatly
> accelerated.
>
> For example, they may reduce the feature size of the part and end up
> making the H block much faster than the F or G blocks relative to the
> old design. The new part will still meet spec, but some paths of your
> design may become much faster than the others.
>
> As you point out, implementing this circuit in an FPGA is most likely
> a
> testbench. But it is a pretty poor testbench for this particular
> circuit.
>
> But all of our comments are relative to the Xilinx. I don't know the
> Altera 10K so well, but don't they have much more deterministic
> routing?
> This may make it more pratical if the routing delay dominates.
>  

Here is the Xilinx Applications spin on this subject:
I agree with most of the cautious remarks. Trying to use an FPGA ( or
actually any other non-specialized device ) to create a fixed delay is
hopeless. Temperature, voltage, processing tolerances and potential chip
redesigns will cause the delay to vary by a factor of 4 to 10. ( Altera
is in the same boat as Xilinx ).

There are, however cases where it is possible to rely on on-chip delays:
differentiating a clock edge, or doubling a clock by differentiating
both edges can be made to work reliably, if the generated "glitch" is
deliberately made long, and is used in a reasonable way ( not routed all
over the chip ). As a last resort, when no digital solution is
available, such a design can be made to work reliably.
Another application is in a feedback loop, where you use a variable
number of gate delays to compensate for a specific delay. If this is
designed in an adaptive way, it will obviously be reliable, as long as
the range is appropriately defined.
Phase-locked-loop and delay-locked-loops are becoming popular for
"eliminating" on-chip clock delays, and such circuits are more or less
analog and asynchronous in nature.

So, don't throw out the baby with the bathwater. But you have to be real
smart when using asynchronous tricks. Truly synchronous designs are
always preferrable, but sometimes they cannot solve the problem.

Peter Alfke, Xilinx Applications

Article: 11378
Subject: Re: PCI Core In FPGA
From: Darrell Ray <dray@SPAM_NOT_MEmizarinc.com>
Date: Fri, 07 Aug 1998 16:05:23 -0500
Links: << >>  << T >>  << A >>
alz wrote:

> Paul,
>
> Check out www.plda.com   They have a very easy to implement pci core.
> The core is limited to Altera devices only.
>
> Al
>

Along those lines, does anybody have experience with Eureka Technology
cores? (www.eurekatech.com) We are also evaluating them...

Darrell Ray             Senior Logic Design Engineer
Blue Wave Systems       Email: dray@mizarinc.com
2410 Luna Rd            Phone: 972.277.4605
Carrollton, TX 75006    Fax:   972.277.4666

Article: 11379
Subject: Re: PCI Core In FPGA
From: "Austin Franklin" <dark6room@ix.netcom.com>
Date: 7 Aug 1998 21:28:13 GMT
Links: << >>  << T >>  << A >>
> the vast majority of windows pci drivers
.....
> this isn't an issue with pci
> drivers, and you still need the ddk, or an equivalent, to write your
> pci driver.

Sorry to be so pesky, but why do you specify "PCI" driver?  Aside from PCI
configuration (which is done by the BIOS before any O/S is loaded) how is
it any different than, say an ISA or EISA driver? Aside from a BIOS call to
get the table of PCI boards and find your device ID so you can get the
interrupt and address....

A PCI device appears at an I/O address and/or a memory address, these
addresses aren't special for PCI.  It may have an interrupt, which means
you put a vector at the appropriate spot in the interrupt vector table,
again, nothing special for PCI.  DMA is done by programming the PCI card
(if it supports master mode) specific to the chip being used....not
particulary particular to PCI, but particular to the chip....but again,
these are just registers in either memory or I/O space....nothing special
to PCI.

Austin

Article: 11380
Subject: Security
From: "Robert Semenoff" <robert_semenoffNOSPAM@phoenix.com>
Date: 8 Aug 1998 00:32:13 GMT
Links: << >>  << T >>  << A >>
I am trying to determine the most secure way of implementing
proprietary algorithms.
It seems to me you could either
code the alorithm into a ROM image of a microcontroller, or 
burn a PLD.  In either case I suppose
a hacker or anyone who wanted to "reverse-engineer" the design (for
whatever reason) could always grind the packaging away and  
physically view the fusemap, although I have no idea how easy
or difficult this would be.  (Anyone hacked a cell phone before ? )

Right now I like the PLD approach just for simplicity
reasons but I haven't found
any vendor hype about about any type of device
anti-read features, (except for the Atmel smart card chips,
but they do not have a general purpose external interface
like an MCU or PLD). 
Any input, including vendor plugs are welcomed.

Rgds,
Article: 11381
Subject: Usb info here : hard and soft
From: Pepito <jpbelin@myrica.com>
Date: Sat, 08 Aug 1998 17:07:21 +0100
Links: << >>  << T >>  << A >>
Hi All,
I found a good reading about the USB interface.
So please, check this url

http://www.angelfire.com/ok/jpbelin/TOPPAGE.html

Hope this will help.
Please, add it in your bookmark.
Pepito

Article: 11382
Subject: New engineering page: please visit
From: Scott Paul Johnston <metad@globalnet.co.uk>
Date: Sat, 08 Aug 1998 10:24:09 -0700
Links: << >>  << T >>  << A >>
Please visit and comment on my Electronics and Electrical Engineering
pages located at:

http://www.users.globalnet.co.uk/~metad/eee.htm

Containing:
Introduction to EEE
Resources (over 100 web links)
Employment Statistics and newspaper excerpts
Engineering Poems, Quotations and Jokes
EEE at Glasgow University

In addition my homepage (http://www.users.globalnet.co.uk/~metad/)
contains:

A section about me
My CV
A James Bond Section
A guestbook
500+ cool links in the "new look" bookpage
Cool background MIDI and graphics
Literary quotations
Photo Album
Awards Page
Poems...

Basically, something for everyone!

PLEASE VISIT VIA MY MAIN HOMEPAGE ADDRESS!

Please send you comments via the guestbook or by Email (containing
your full name and Email and webpage addresses) and visit via 
http://www.users.globalnet.co.uk/~metad/.

Thanks 
Scott Johnston
metad@globalnet.co.uk
Article: 11383
Subject: PCI Core Thanks
From: "Simon Ramirez" <s_ramirez@email.msn.com>
Date: Sat, 8 Aug 1998 23:26:29 -0000
Links: << >>  << T >>  << A >>
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.
   Again, thanks everyone.
-Simon Ramirez
 Consultant/Contractor
 407-365-8928
 s_ramirez@msn.com



Article: 11384
Subject: Re: Async design/minimum prop delays
From: "Simon Ramirez" <s_ramirez@email.msn.com>
Date: Sat, 8 Aug 1998 23:28:03 -0000
Links: << >>  << T >>  << A >>
A big fat NO!


ems wrote in message <35bd9e48.6963996@news.dial.pipex.com>...
><previous thread snipped>
>
>Has anyone managed to do any successful complex asynchronous design in
>an FPGA? Presumably the various async processor research projects are
>prototyping on FPGAs.
>
>Or, alternatively, does anyone know of an FPGA which guarantees
>minimum propagation delays?
>
>Evan
>


Article: 11385
Subject: Re: Radiation and Relaibility
From: jim granville <Jim.Granville@xtra.co.nz>
Date: Sun, 09 Aug 1998 20:15:58 +1200
Links: << >>  << T >>  << A >>
Wade D. Peterson wrote:
> 
> >> > Correct, it is very simple, in my case I changed each FF to three FF with a
> >> > majority voting system on the output. Thus if any FF is changed due to
> >> > radiation effects (e.g. heavy protons) the majority voting system will output
> >> > the correct value (majority is always right??). The possibility of two FF being
> >> > hit at the same time or before the FF is used is relative small.
> >>
<snip>
> >hamming codes or a tmr which has similar characteristics.  in this case a reed-solomon
> >could would be used, but is inconvenient since it's a block code.  data shows that
> >these sort of chips do have multiple bit errors and it's not just a theoretical thing.
> 
> >another consideration is the circuit design of the cell.  excluding access
> >transistors, a 4-T storage cell should be used.  if a 2-T + 2-R configuration is used,
> >where the value of R is EXTREMELY high (as in commercial SRAMs), then a single heavy
> >ion strike can cause a tad of leakage resulting in a 'stuck bit' with obvious
> >implications on error correcting coding schemes.  again, this is seen in real data.
> 
> >what does this mean for fpga?  well, it depends on the device architecture and
> >layout.  for devices with sram the work previously done for discrete sram chips needs
> >to be applied, carefully, both in circuit design and layout.

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 ?

 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 :-)
 
- jg

Article: 11386
Subject: Re: Security [0/4]
From: Daniel K Elftmann <elftmann@ix.netcom.com>
Date: Sun, 09 Aug 1998 14:14:47 GMT
Links: << >>  << T >>  << A >>
In article <01bdc263$8ce4d600$cd037a86@rsemenoff.phoenix.com>,
	"Robert Semenoff" <robert_semenoffNOSPAM@phoenix.com> wrote:

>I am trying to determine the most secure way of implementing
>proprietary algorithms.
>It seems to me you could either
>code the alorithm into a ROM image of a microcontroller, or 
>burn a PLD.  In either case I suppose
>a hacker or anyone who wanted to "reverse-engineer" the design (for
>whatever reason) could always grind the packaging away and  
>physically view the fusemap, although I have no idea how easy
>or difficult this would be.  (Anyone hacked a cell phone before ? )
>
>Right now I like the PLD approach just for simplicity
>reasons but I haven't found
>any vendor hype about about any type of device
>anti-read features, (except for the Atmel smart card chips,
>but they do not have a general purpose external interface
>like an MCU or PLD). 
>Any input, including vendor plugs are welcomed.
>
>Rgds,

 Here's a vendor plug, from Actel.  Antifuse is the most secure method of implementing digital
functions in silicon.  Please see the attached Acrobat document.


Article: 11387
Subject: Re: Security [1/4]
From: Daniel K Elftmann <elftmann@ix.netcom.com>
Date: Sun, 09 Aug 1998 14:14:49 GMT
Links: << >>  << T >>  << A >>

>>>>>>>>>  Stupid PDF file binary (1000 lines) deleted by Archive Owner





Article: 11388
Subject: Re: Security [2/4]
From: Daniel K Elftmann <elftmann@ix.netcom.com>
Date: Sun, 09 Aug 1998 14:15:10 GMT
Links: << >>  << T >>  << A >>
>>>>>>>>  UUENCODE DELETED BY ARCHIVE OWNER


Article: 11389
Subject: Re: Security [3/4]
From: Daniel K Elftmann <elftmann@ix.netcom.com>
Date: Sun, 09 Aug 1998 14:15:31 GMT
Links: << >>  << T >>  << A >>
>>>>>>>>  UUENCODE DELETED BY ARCHIVE OWNER


Article: 11390
Subject: Re: Security [4/4]
From: Daniel K Elftmann <elftmann@ix.netcom.com>
Date: Sun, 09 Aug 1998 14:15:53 GMT
Links: << >>  << T >>  << A >>
>>>>>>>>  UUENCODE DELETED BY ARCHIVE OWNER


Article: 11391
Subject: Re: Radiation and Relaibility
From: peter299@maroon.tc.umn.edu (Wade D. Peterson)
Date: Sun, 09 Aug 1998 16:15:40 GMT
Links: << >>  << T >>  << A >>
jim granville <Jim.Granville@xtra.co.nz> wrote:

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

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


I'm by no means a radiation expert.  However, I was over at CERN in
Switzerland a couple of months ago (CERN is a big 'atom smasher',
among other things), and in their lobby they had a really cool
operating 'cosmic ray' detector.  This thing was about 10' x 20' in
size, and it showed that at ground level you would get about 1 or 2
hits every 10 seconds or so (over the entire area).  I'm not sure if
that thing was even detecting the same kind of particles that whack
microchips, but I suppose you could scale these numbers down to a die
size.

Wade Peterson
Silicore Corporation  www.silicore.net


Article: 11392
Subject: Re: Gray code counter in ABEL HDL?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Sun, 09 Aug 1998 14:13:58 -0700
Links: << >>  << T >>  << A >>
Marc Heuler wrote:

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

Here is the equation for converting Binary to Gray code. 

Qn (Gray ) = Qn(binary) XOR Qn+1 ( binary).

In other words, you just XOR any binary output with the next more
significant binary output.

Hope that helps a little.

Viele Gre, ( yes, we can do umlauts and eszets  :-)

Peter Alfke, Xilinx Applications
  

Article: 11393
Subject: Gray code counter in ABEL HDL?
From: marc@aargh.franken.de (Marc Heuler)
Date: Sun, 09 Aug 1998 17:40:14 CET
Links: << >>  << T >>  << A >>
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: 11394
Subject: Re: Food poison
From: madmarsu@mygale.org
Date: 10 Aug 1998 05:26:56 GMT
Links: << >>  << T >>  << A >>

This sounded like a hoax. Taking a look, I found that although it 
_sounds_ like one, it somehow makes sense. After all, there are 
several things that work, even if we cannot explain them. Users of
wishing-wands are an example. They do find water, but nobody knows
or can proof how it works.

Anyway, I'm thinking of ordering one of their glass wands. It's not 
a lot of money if it can do what they claim.

Any opinions?


    Surfin'



On 5 Aug 1998 09:18:33 GMT, info@NO-SPAMcleanfood.com wrote:

>  Hello, everybody,
> 
> Let me tell you about a new approach to free your food of viruses,
> bacteria, fungus, etc.
> 
> We produce Polarizers. These are wands made of rock-crystal glass. 
> They deactivate the poisonous influence of pathogenes like viruses, 
> bacteria, spores, fungus and eggs of intestinal worms, which can be 
> found in food supplies. In *your* food supplies. 
> 
>              http://www.cleanfood.com
> 
> You will also find that the Polarizer is a simple, easy to use
> device.
> 
> Take a look, it's a surprising, effective and cheap approach to 
> deactivate the pathogenes in your food.
> 
> 
>         Clean Food Corp.
>     http://www.cleanfood.com
> 
> 
> Please remove the obvious when replying via email. If you don't eat, 
> you may consider this message off-topic. Sorry for that. 

Article: 11395
Subject: Re: PCI Core In FPGA
From: ems@nospam.riverside-machines.com (ems)
Date: Mon, 10 Aug 1998 10:39:49 GMT
Links: << >>  << T >>  << A >>
On 7 Aug 1998 21:28:13 GMT, "Austin Franklin"
<dark6room@ix.netcom.com> wrote:

>Sorry to be so pesky, but why do you specify "PCI" driver?  Aside from PCI
>configuration (which is done by the BIOS before any O/S is loaded) how is
>it any different than, say an ISA or EISA driver? 

just for convenience, i guess.
when writing VxDs (for Win9x), there are 2 categories of hardware
devices - plug'n'play and legacy. it just happens that most p'n'p
devices are on PCI. people in the VxD newsgroup tend to refer to their
drivers as PCI drivers, or PC(mcia)-card drivers, or whatever, rather
than as pnp drivers. a pnp driver uses a microsoft VxD called the CM
(configuration manager) to provide its basic services, such as finding
out what resources the device requires, and making sure that there are
no resource conflicts. the CM itself relies on various other
(microsoft) VxDs to do such things as enumerating all the devices on a
given bus, loading drivers when required, and so on. in principle,
there are only minor differences between a pnp driver for PCI and, for
example, a PC-card.
legacy drivers for, for example, an old ISA card are very different.

>Aside from a BIOS call to
>get the table of PCI boards and find your device ID so you can get the
>interrupt and address....
>A PCI device appears at an I/O address and/or a memory address, these
>addresses aren't special for PCI.  It may have an interrupt, which means
>you put a vector at the appropriate spot in the interrupt vector table,
> <snip>

you could, in principle, ignore the CM/pnp services, and write a
legacy driver for a PCI card, using bios services as you suggest (you
have to do this for win3.x). this comes up occasionally in the
newsgroup, but the suggestion is normally shouted down quickly.

evan

Article: 11396
Subject: Re: PCI Core In FPGA
From: ems@nospam.riverside-machines.com (ems)
Date: Mon, 10 Aug 1998 10:41:06 GMT
Links: << >>  << T >>  << A >>
On Fri, 07 Aug 1998 09:02:23 -0700, Al Zimmerman <alz@RayCast.com>
wrote:

> But I guarantee you that
>graphics chip vendors are avoiding any & all ring3/ring0 transitions.

my point was that there weren't any to avoid.

>Alternatively, you could use the DDK from Microsoft
>and have the OS determine whether to access the pci bus.

you have to use the ddk, or equivalent, to write your driver. this is
unrelated to the memory window issue.

>With all that said, the graphics chip will do most of the transferring
>anyway by mastering the pci bus and reading the data from main memory.
>The goal is to get the request command to the graphics chip ASAP.  The
>fastest way to do this is to get the OS out of the way.

that's the point of having a memory window.

>Most applications will
>not have speed issues with 2d graphics so the having the OS performing
>virtual addressing onto the pci bus will not be a big deal.

there's no virtual addressing overhead. the OS sets up the processor's
page tables during initialisation, and translation is automatic. all
system memory, with one minor exception, must be accessed as virtual
memory.

evan

Article: 11397
Subject: Re: Security
From: gd@nospamheliontech.com (Graeme Durant)
Date: Mon, 10 Aug 1998 12:42:40 GMT
Links: << >>  << T >>  << A >>
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.

I agree, this approach is not appropriate for many applications, but
it just goes to show that there are many ways to skin a cat!


Graeme Durant
HELION Technology Limited
Programmable Logic Solutions
Cambridge, UK
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.heliontech.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Article: 11398
Subject: Looking for a Sr. ASIC DESIGN Engineer / Consultant
From: abhayjoshi@my-dejanews.com
Date: Mon, 10 Aug 1998 13:19:47 GMT
Links: << >>  << T >>  << A >>
Hello

This is Abhay Joshi from Solution Machines, Ahmedabad, India

We are a solutions company actively focussed on ASIC DESIGN services. We 
have a team of engineers who are working on the SYNTHESIZABLE CORE
DEVELOPMENT OF USB and FIREWIRE IEEE1394

We are looking at a fulltime ASIC XDESIGN / VERILOG consultant to be based at
Ahmedabad.

Remuneration not a constraint at all.

Luxurious Accomodation will be offered over and above an attractive ESOP
arrangement.

Excellent Opportunity to lead a team of dynamic engineers, make the products
silicon proven and head the Hardware Modeling Profit Centre.

Job might involve spending some time in the heart of Silicon Valley.

Pls visit our site www.solutionmachines.com for more info on SolMac

Send in your resume immediately on

solmac@ad1.vsnl.net.in
or ajjoshi@hotmail.com

Regards

Abhay Joshi

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
Article: 11399
Subject: Re: Gray code counter in ABEL HDL?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 10 Aug 1998 09:29:07 -0700
Links: << >>  << T >>  << A >>
Marc Heuler wrote:

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

  Yesterday I provided the simple binary-to-Gray conversion algorithm.
But here comes a warning: Do not just hang this XOR on the binary
counter outputs. Then the binary asynchronous weird codes ( going from 7
to 8 with unknown codes happening in-between ) are just passed through
to the Gray side. Instead, re-synchronize the Gray outputs with the
counter clock, and you will have no problem.
Of course, that's easier in a flip-flop rich architecture, like (hm)
Xi...  :-)

Peter Alfke, Xilinx Applications



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