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 82150

Article: 82150
Subject: Re: Sdram controller on the Altera Cyclone board!
From: Nick <no-email@published.nul>
Date: Thu, 07 Apr 2005 19:42:00 +0200
Links: << >>  << T >>  << A >>
On Thu, 7 Apr 2005 16:17:10 +0800, "kingkang" <305liuzg@163.net>
wrote:

>Hi
>I wrote a sdram controller which has pass the RTL simulation.
>But when it come to the Altera cyclone board,the read/write
>data were wrong.I have written sdram with some data,and then
>I read the data from sdram.But found the data is not equal to
>what have been written into the sdram.One or Some bits have
>wrong.It is random bit error!I don't know what's wrong.About
>the clock? or board delay? or else?Please help me out!
>Thanks and Regards!
>

Did you set up the right delay for the clock of the SDRAM ? I use a
288 deg phase shift on my pll to feed the SDRAM, at 50 MHz. It can be
something else for you thought.

That's one of the most important thing.

Regards
Nick

Article: 82151
Subject: Re: Hey Xilinx
From: vbetz@altera.com
Date: 7 Apr 2005 10:49:06 -0700
Links: << >>  << T >>  << A >>

Quiet Desperation wrote:
> Any chance of there ever being an FPGA where one or more of the
> SelectRAM blocks is nonvolatile?
>
> I design a lot of stuff that is programmable and reconfigurable
beyond
> the FPGAs. I commonly need to store the setting of digital delay
chips
> and switch settings and other control lines so that a unit powers up
> with everything in the state desired by the end user.
>
> Currently I use little automotive serial EEPROMs, but, dang but it'd
be
> nice to have a little EEPROM inside an FPGA. Just one 18Kbit block
> would do wonders.

The Altera MAX II parts can do this.  They contain 8kb of flash that
can be both read and written by your design to store anything you want.
 See
http://www.altera.com/products/devices/cpld/max2/features/flash/mx2-flash_memory.html
for details on how to use it.

Vaughn 
Altera
[v b e t z (at) altera.com]


Article: 82152
Subject: Re: Single Event Functional Interrupts (SEFI) in Virtex
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 07 Apr 2005 11:39:37 -0700
Links: << >>  << T >>  << A >>
Praveen,

Well, the problem is that a SEFI might hit the line which controls the 
"clean-out" (zeroization of all config and BRAM).

If that happens, then basically, the upset has caused the device to 
re-initialize (or just go stupid).  There is no way to prevent this from 
happening.  We are researching how to design so this can not occur, but 
this is a very tough problem.  An event can strike any transistor.

uP, ASSP, and ASICs also have SEFI behavior.  And yes, theirs is 
incredibly rare as well.  FPGAs are similar in SEFI behavior to all the 
other devices.  Maybe better.  I haven't see the SEFI x-section for a 
Pentium chip.

Yes, these SEFI cross sections are incredibly small, and the probability 
is also small that this happens, but presuming it does happen, there is 
really nothing at all that you can do (except detect that it happened, 
and reconfigure the device from scratch).

Systems that have to be hardened against SEFI will use a CPLD, or other 
device, to detect that a SEFI occured, and reconfigure the FPGA.  In the 
time it takes to recongize the SEFI, and reconfigure, all data is lost 
(unless it is part of a redundant system, which is commonly used for 
critical applications).

In the order of increasing robustness:

- no measures taken (susceptible to SEU, and SEFI):  the vast majority 
of all FPGA applications fall into this category, as do ASIC, ASSP, and uP.

- use TMR on the user pattern to remove the effcts of SEUs completely, 
still susceptible to SEFI:  a step that gets rid of SEU effects.  Also 
is used in some special ASICs for mil/aero.

- scrub the config memory (continually reload the config while 
operating): used my many space probes, still susceptible to SEU and 
SEFI, but recovers very quickly, and SEUs do not accumulate leading to 
an overall availability improvement.  This is what the Mars Lander Pryo 
controller did.  The landers themselves just reconfigure once a day 
(enough to mitigate the effects they anticipated).

- scrub and use TMR:  now we only have SEFI to worry about.  The best 
choice for getting to the level of reliability where the only thing that 
can be of any trouble is a SEFI.  Good enough for just about anything 
except where human life is concerned.

- readback the config and fix the bits that flipped (use of V4 
FRAME_ECC):  similar to scrubbing, but faster and less hardware.  Same 
as above non-TMR scrubbing case.

- readback and fix config for a TMR design: only SEFIs to worry about. 
Good for just about anythign excepting a human life.

- monitor the device with another device (eg CPLD) for SEFI, reconfigure 
if a SEFI occurs: used in critical space and avionics.  May also be 
doing TMR, scrubbing, etc. as well.  This is still not good enough for a 
human life situation unless the time to recover is fast enough not to 
matter.

- provide one other FPGA, dual redundant:  use of dual rednundant allows 
for transfer away from a fault, used for even higher availability (each 
individual unit may be scrubbing, use TMR, etc.  There may also be a 
"voter" to switch between FPGA's in case of SEFI).  Almost the highest 
level of availability, in that we still don't trust even this 
arrangement for human life situations.  It may get used in military 
systems where the probabvility of death is much much higher than the 
probability of a systems failure, so added system availability is not 
needed (a real toght decision, one I gladly don't have to make).

- fully duplicated, dual redundant:  used by things like commercial 
airliners, and airports.  Two redundant systems that can be selected 
manually by the air traffic controllers or pilots in the unlikely event 
that one of the redundant systems fail.  Within each redundant system, 
various levels of protection may, or may not be necessary, since the 
entire system is duplicated.  A system with no scrubbing of the FPGAs, 
but with many self-checks that are done independent of the FPGA is used 
in fact in all US and Canadian Airports for all communications between 
the ground and air, and ground and ground.  I designed it.  If one 
redundant unit either detects a failure in itself, or the redundant unit 
it is paired with detects that its partner has gone stupid, it switches 
itself in, and the other out in less than 50 ms.  If the air traffic 
controllers can't talk to the airplanes for some reason, they have a 
manual switch they push to transfer everything over to another set of 
com links, radios, antennas, etc.

Austin

Article: 82153
Subject: Re: Single Event Functional Interrupts (SEFI) in Virtex
From: Kris Vorwerk <nothanks@noonehere.org>
Date: Thu, 07 Apr 2005 15:15:32 -0400
Links: << >>  << T >>  << A >>
> I am doing a literature survey on SEFIs in Xilinx FPGAs. Unfortunately,
> there are not many papers on this. It might either be because this is
> not a major issue or because there is not really much work done.


You might find the following interesting/relevant ...  (It's just
something I came across while Googling) ...

http://klabs.org/mapld04/presentations/session_c/4_c144_swift_s.ppt


Kris


Article: 82154
Subject: Re: ISA vs. patent/trademark
From: mojaveg@mojaveg.iwvisp.com (Everett M. Greene)
Date: Thu, 7 Apr 2005 11:47:58 PST
Links: << >>  << T >>  << A >>
Eric Smith <eric@brouhaha.com> writes:
> "JJ" <johnjakson@yahoo.com> writes:
> > If some processor that is not any way MIPs like can otherwise perform a
> > register ld/st for a word on any byte boundary is that a problem, or
> > only if the rest of it is MIPs like too.
> 
> It's not the unaligned load/store per se that is patented; many processors
> have done that.
> 
> What MIPS invented and patented was the idea that instead of having the
> hardware deal with unaligned bus accesses, they require software to
> issue *two* instructions to do an unaligned access.  One does the
> "left part" and one does the "right part" of the word.

This must be a misstatement or it's a ridiculous patent.
How can a patent be issued for NOT doing something?
I can get a patent for an anchor that requires the
addition of propulsion and lifting surfaces so that
it can fly on its own?

There's also the "obvious to anyone experienced with
the technology" thing.

> The normal MIPS load and store instructions require alignment just as
> on most other RISC processors.

-- 

----------------------------------------------------------------------
Everett M. Greene  (The Mojave Greene, crotalus scutulatus scutulatus)
Ridgecrest, Ca. 93555           Path: mojaveg@IWVISP.com

Murphy's law of aviation and large over-the-road vehicles:
Whichever direction you're going, it'll be into a stiff headwind.

Murphy's law of farming and earthmoving:  Whichever direction
you're going, there's a tailwind of the same speed and direction
as your movement.

Article: 82155
Subject: Re: Interesting article about Xilinx FPGAs in the new Cray
From: "JJ" <johnjakson@yahoo.com>
Date: 7 Apr 2005 13:08:37 -0700
Links: << >>  << T >>  << A >>
I'd imagine this is mostly the same as or is infact what they got from
the Octiga Bay purchase awhile back.

The article it self is fluff, but it would be interesting to know what
various customers are actually doing with these.

Anyone know the price?

I wonder though about some applications split between an FPGA and
Opterons. If the app doesn't need too much of the Opterons abilities,
probably better off using a couple of soft/PPC cpu cores right in the
fabric. Now if FPGAs ever get embedded FPUs maybe 1 for every n muls or
so, probably would'nt need the external cpu.

regards

johnjakson at usa dot com
transputer2 at yahoo dot com


Article: 82156
Subject: ADPCM IP core
From: "grupa1" <mariuszb@platan.pl>
Date: Thu, 07 Apr 2005 20:12:57 GMT
Links: << >>  << T >>  << A >>
I am looking for ADPCM IP core
Thanks for help



Article: 82157
Subject: Re: Slow rising strobe used to clock IOB's, can it cause trouble?
From: Brijesh <brijesh_xyz@cfrsi_xyz.com>
Date: Thu, 07 Apr 2005 16:14:08 -0400
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> If you use STROBE as a rising-edge clock input, then excessive noise
> might be superimposed on its falling edge, such that the falling edge
> actually contains a rising edge clock, which would give you weird
> timing.
> Just a wild guess...
> Peter Alfke
> 

Hello Peter,

Its DDR scheme. Data is clocked in both on the rising edge and falling edge.

My main question is still how slow is too slow?

Thanks

Brijesh

Article: 82158
Subject: Re: ISA vs. patent/trademark
From: "John Mashey" <old_systems_guy@yahoo.com>
Date: 7 Apr 2005 13:21:29 -0700
Links: << >>  << T >>  << A >>

Everett M. Greene wrote:
> Eric Smith <eric@brouhaha.com> writes:
> > "JJ" <johnjakson@yahoo.com> writes:
> > > If some processor that is not any way MIPs like can otherwise
perform a
> > > register ld/st for a word on any byte boundary is that a problem,
or
> > > only if the rest of it is MIPs like too.
> >
> > It's not the unaligned load/store per se that is patented; many
processors
> > have done that.
> >
> > What MIPS invented and patented was the idea that instead of having
the
> > hardware deal with unaligned bus accesses, they require software to
> > issue *two* instructions to do an unaligned access.  One does the
> > "left part" and one does the "right part" of the word.
>
> This must be a misstatement or it's a ridiculous patent.
> How can a patent be issued for NOT doing something?
> I can get a patent for an anchor that requires the
> addition of propulsion and lifting surfaces so that
> it can fly on its own?
>
> There's also the "obvious to anyone experienced with
> the technology" thing.
>
> > The normal MIPS load and store instructions require alignment just
as
> > on most other RISC processors.

It's a poor statement; it's not a ridiculous patent, although, as I
have explained before in comp.arch [search: mashey lwl], in retrospect,
I'd just as soon we hadn't done it. Even though it was easy at the time
[Summer 1985], but turned out to get far less use than we'd expected,
at least partly because the rise of RISCs with strict alignment got
many people to clean up code.  As noted elsewhere, if I were doing it
again, I'd probably do something different.

The patent is 4,814,976 by Hansen & Riordan.

The *point* of the patent was that if you have a straightforward RISC
pipeline that supports caches and paged virtual memory, then requiring
hardware to do all the work of handling arbitrarily-aligned data [i.e.,
crossing cache-line or worse, page boundaries] adds *greatly* to the
implementation complexity, and one doesn't want to do this.  [The
implementation penalty for some microcoded CISCs cn be much less.]

The MIPS solution was some much simpler hardware (very minimal
additions, and nothing tricky] beyond what was there, that allowed
compilers to generate code to deal with unaligned accesses that
sometimes came up from legacy code without burdening the base hardware
design.

[This is one of those classic "It takes a bunch of hardware to make
this both fast and right, and it means a lot of checking for cases that
hardly ever happen, but if the hardware is wrong, the bugs are horrible
to find." cases that hardware designers hate.]


Article: 82159
Subject: Re: Slow rising strobe used to clock IOB's, can it cause trouble?
From: Brijesh <brijesh_xyz@cfrsi_xyz.com>
Date: Thu, 07 Apr 2005 16:21:57 -0400
Links: << >>  << T >>  << A >>
Symon wrote:

Hello Symon,

> Brijesh,
> Have you considered using the strobe signal at a latch enable rather than a 
> clock? Rise time is then unimportant. t\The IOBs' storage elements can be 
> latches, IIRC.

Its DDR scheme so simple Latch scheme wont work, as data is only stable 
during the rising/falling edge of the strobe.

Even otherwise, as I mentioned there are multiple channels and all of 
them work just fine, except this one. Thats led me to believe its not 
design problem, but SI issue.

> As for pin impedances, you need to use the IBIS files to determine this. Do 
> you have HyperLynx?
Have not really worked with IBIS files. I did peek into IBIS files for 
the first time and found they do not have a direct number. :-)
Don't have HyperLynx, will read up about it.

Thanks
Brijesh


> Cheers, Syms. 
> 
> 


Article: 82160
Subject: Re: Slow rising strobe used to clock IOB's, can it cause trouble?
From: "Peter Alfke" <peter@xilinx.com>
Date: 7 Apr 2005 13:29:31 -0700
Links: << >>  << T >>  << A >>
There is no fundamental limit. A flip-flop will be clocked, even if the
clock takes seconds or minutes to rise. But the longer the transition
time, the bigger the chance of picking up noise, and creating a
double-pulse. And the fact that you use DDR does not invalidate my
prvious response. Noise then has a chance to disturb either edge or
both.
Peter Alfke
============
Brijesh wrote:
> Peter Alfke wrote:
>
> > If you use STROBE as a rising-edge clock input, then excessive
noise
> > might be superimposed on its falling edge, such that the falling
edge
> > actually contains a rising edge clock, which would give you weird
> > timing.
> > Just a wild guess...
> > Peter Alfke
> >
>
> Hello Peter,
>
> Its DDR scheme. Data is clocked in both on the rising edge and
falling edge.
>
> My main question is still how slow is too slow?
> 
> Thanks
> 
> Brijesh


Article: 82161
Subject: Re: ISA vs. patent/trademark
From: "John Mashey" <old_systems_guy@yahoo.com>
Date: 7 Apr 2005 13:38:15 -0700
Links: << >>  << T >>  << A >>

David wrote:
> On Wed, 06 Apr 2005 11:08:53 +1200, Jim Granville wrote:
>
> >
> >   I heard that the NIOS II is 'very similar' to MIPS - can anyone
who
> > knows both cores in detail comment ?
> >
> > -jg
>
> I don't know the MIPS in detail (long ago, I read a book on the
> R2000/R3000 architecture which I picked up in a second-hand
bookshop), but
> there are certainly some fundamental similarities.  Each is a 32-bit
RISC
> core, with 32x32-bit registers, orthogonal instruction set, etc.  The
NIOS
> II is a little odd (IMHO) in that it has some registers with
dedicated
> purposes and supervisor-only access.  I think, however, that quite a
lot
> of 32-bit RISC architectures (ARM, Microblaize) would be "very
similar" at
> this level.

See http://www.altera.com/literature/lit-nio2.jsp.


NIOS II is clearly different from MIPS I, but I'd guess that whoever
designed NIOS II was quite familiar with MIPS, as a lot of nomenclature
(register names, many of the register allocations, some opcode names)
are rather MIPS-reminiscent.  Of course, lots of ISAs have borrowed
from each other, and and ADD is an ADD :-). However, of 32 registers,
at least 25 [0-23, 31] are allocated exactly as in MIPS, and generally
have same names, even when those aren't obvious.

People may recall my comments in the WIZ discussion about wishing not
to have done MUL and DIV the way we did in MIPS, but to have done it
more like the way Alpha did it later, and NIOS II does that.
NIOS II has no (MIPS) LUI instruction, but has ANDHI, ORHI, XORHI.  We
almost did  ANDHI or ORHI (as they subsume LUI, but have other uses),
but thought about it a little too late [Summer 1985] to get in.

In general, NIOS II feels like a sensible design for a small embedded
core, a bit more like MIPS than like any other RISC, but in general,
doing things different that in fact match with things that in
retrospect, we might well ahve done different.


Article: 82162
Subject: Re: Single Event Functional Interrupts (SEFI) in Virtex
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 07 Apr 2005 13:49:59 -0700
Links: << >>  << T >>  << A >>
Kris,

Nice ppt presentation.  They quote 65 years in orbit around the earth 
mean time between SEFI.

We have published results of heavy ion testing that states we are at 
(least) 1.5E-6 SEFI/day in earth orbit, which is 1,800 years between 
SEFI.  Not sure where the discepancy comes from.

It may be that work was done on commercial parts, instead of using the 
Qpro series (which has EPI wafers).  If you are going to go into space, 
you are better off using the Qpro devices.

http://direct.xilinx.com/bvdocs/publications/ds124.pdf
Page 3, Table 3.

Not sure that EPI alone would have more than a factor of 2 improvement 
in upset rate (SEU or SEFI).

Could be that the authors of the ppt also divided by 24 (thinking our 
specification was in hours).  That yields a number closer (76 years--but 
wrong nonetheless).

Sea level is ~ 40 times less upsets, so a SEFI at sea level is ~ 7,300 
years.

We have some customers with more than 250,000 Virtex II's in the field 
(monitored), and that would mean they would have ~ 35 SEFI's a year. 
Since they have had far fewer (in fact:  none reported), one has to take 
even this projection as overly conservative for us earthlings on the ground.

Also, space based projection of failures use heavy ions, and earth based 
projections of failures use protons, and neutrons.  There is factor of 
(at least) 1e5 to 1e6 there in terms of the size of the "bullet!"

For example, the cross section for a Virtex II memory cell is ~2.283E-14 
for neutrons, and is ~8E-8 for a heavy ion.  These are from recent tests 
with neutrons and with heavy ions (Xilinx Radiation Effects Consortium).

Sort of like a grain of sand vs. a locomotive engine.

This is a good analogy:  if you are hit by a train, what do you do?  If 
you are hit by a grain of sand, what do you do?

Compare our Xilinx Virtex II FPGA with a popular uP: (for SEFI)

http://www.spacemicro.com/services_files/SM_NSREC_Paper_2004.pdf

with up to a few SEFI per day (worst case), to one SEFI a year (best case).

So the next time you see the "blue screen of death" on your laptop 
computer, was that a SEFI, or was it Microsquat?

Austin

Article: 82163
Subject: Re: ISA vs. patent/trademark
From: nmm1@cus.cam.ac.uk (Nick Maclaren)
Date: 7 Apr 2005 20:59:06 GMT
Links: << >>  << T >>  << A >>
In article <1112905289.368801.161230@g14g2000cwa.googlegroups.com>,
John Mashey <old_systems_guy@yahoo.com> wrote:
>
>The MIPS solution was some much simpler hardware (very minimal
>additions, and nothing tricky] beyond what was there, that allowed
>compilers to generate code to deal with unaligned accesses that
>sometimes came up from legacy code without burdening the base hardware
>design.

And the Nick Maclaren comment is that most of those codes are so
horrible that they probably aren't getting right answers anyway.
I strongly disapprove of fixing up alignment in software - it is
much better to diagnose the failure and get the programmer to fix
the broken code.

Notice that this requires the hardware to do even less :-)


Regards,
Nick Maclaren.

Article: 82164
Subject: Re: ISA vs. patent/trademark
From: Terje Mathisen <terje.mathisen@hda.hydro.com>
Date: Thu, 07 Apr 2005 23:06:35 +0200
Links: << >>  << T >>  << A >>
John Mashey wrote:
[re. misaligned load patent]
> It's a poor statement; it's not a ridiculous patent, although, as I
> have explained before in comp.arch [search: mashey lwl], in retrospect,
> I'd just as soon we hadn't done it. Even though it was easy at the time
> [Summer 1985], but turned out to get far less use than we'd expected,
> at least partly because the rise of RISCs with strict alignment got
> many people to clean up code.  As noted elsewhere, if I were doing it
> again, I'd probably do something different.
> 
> The patent is 4,814,976 by Hansen & Riordan.
> 
> The *point* of the patent was that if you have a straightforward RISC
> pipeline that supports caches and paged virtual memory, then requiring
> hardware to do all the work of handling arbitrarily-aligned data [i.e.,
> crossing cache-line or worse, page boundaries] adds *greatly* to the
> implementation complexity, and one doesn't want to do this.  [The
> implementation penalty for some microcoded CISCs cn be much less.]
> 
> The MIPS solution was some much simpler hardware (very minimal
> additions, and nothing tricky] beyond what was there, that allowed
> compilers to generate code to deal with unaligned accesses that
> sometimes came up from legacy code without burdening the base hardware
> design.

I have never seen either the patent or the relevant MIPS asm code 
generated, but it seems to me that the hw I'd want would look like this:

a)

   LoadAligned r1=[r0]

where any low-order bits in r0 would be ignored.

b)

either

   LoadAligned r2=[r0+regsize]

or

   LoadAlignedRight r2=[r0]

Both of these would load the next aligned word

c) (The somewhat tricky one!)

   ShiftToAlign r3=r1,r2,r0

which is defined to merge r1 & r2, using the loworder bits from r0 to 
determine the number of bytes to shift.

Since this opcode takes four register operands, I'd suggest forcing the 
destination to be the same as the low-order source register, i.e.:

   ShiftToAlign r1=r2,r0

   defined as

   r1 = (r1 >> (r0 & 7)*8) | (r2 << (8-(r0 & 7))*8);

Doing it this way makes it easy to process an array of misaligned data, 
since the second source register is unmodified, so it can be used as the 
primary (modified) source during the next iteration.

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

Article: 82165
Subject: xilinx embedded MAC
From: "geoffrey wall" <wallge@eng.fsu.edu>
Date: Thu, 7 Apr 2005 17:42:39 -0400
Links: << >>  << T >>  << A >>
we are using xilinx xc2v3000 (virtex II) FPGA
we are trying to do 42 MACs.
right now we are doing the multiplication, followed by the addition.
is there an MAC component available that can do this in one clock cycle?


-- 
Geoffrey Wall
Masters Student in Electrical/Computer Engineering
Florida State University, FAMU/FSU College of Engineering
wallge@eng.fsu.edu
Cell Phone:
850.339.4157

ECE Machine Intelligence Lab
http://www.eng.fsu.edu/mil
MIL Office Phone:
850.410.6145

Center for Applied Vision and Imaging Science
http://cavis.fsu.edu/
CAVIS Office Phone:
850.645.2257 



Article: 82166
Subject: Re: Reverse engineering ASIC into FPGA
From: Philip Freidin <philip@fliptronics.com>
Date: Thu, 07 Apr 2005 21:43:28 GMT
Links: << >>  << T >>  << A >>
On Mon, 4 Apr 2005 15:49:44 +0000 (UTC), weingart@cs.ualberta.ca (Tobias Weingartner) wrote:
>Does anyone have experience with reverse engineering ASIC (black box)
>into equivelant FPGA devices (pin equivelant with a sub-board if necessary)?

I did a project like this about 8 years ago, except it was
ASIC to FPGA to ASIC.

The original ASIC was a standard product from a company you know,
as in it was a standard product, but they used ASIC design methodology.

A data sheet was available, but had insufficient info about behavior
for all possible input scenarios.

The client was using thousands of these parts per month, and had big
expensive boards that they could not respin for a different package.
The original ASIC had a package and pinout that did not match any
FPGA. The original vendor was surprisingly unhelpful, as no more chips,
no hand over of product to one of the after market silicon houses,
no willingness to find their design files to help us.

We did find an ASIC vendor that could match the package and power,
ground, I/O pin requirements. (FPGA on carrier board was also considered
but we didn't have the vertical clearance.)

I reverse enginered the original part based on the application circuit,
the incomplete data sheet, and common sense about how the original
(reasonable I hope) designers must have done things. I created an FPGA
design. The customer created a very large set of test vectors, and ran
it through their system, and recorded the results.

I designed a PCB that plugged into a PC, and had a socket for the original
ASIC, and the FPGA. I got one of the original ASICs, put it on my board
and ran the test vectors from the client against the ASIC, and checked
that their result vectors matched. I wrote a test coverage program and
ran their vectors through it, and identified what they weren't testing.
I wrote a few million more vectors, and ran them through the original
ASIC. I updated the test vector set, and the expected response. I wrote
an addendum to the data sheet that covered the ommisions and ambiguities.

I ran the test vectors against my FPGA design in a simulator and resolved
any mis-matches.

I then ran the test vectors against my FPGA design.
I got the customer to sign off on the results.

A new ASIC was designed from the FPGA design. I ran the test vectors
against my ASIC design in a simulator. There were no mis-matches.
I got the customer to sign off on the results.

The new design was sent off to the ASIC vendor, who insisted on adding
scan test to the design. Their ATPG program got 93% coverage. My test
vectors were about the same size and got 99.8% coverage. The scan test
was removed from the design. Chips were fabricated.

The new ASICs came back, and I plugged one into my test board, and
ran all my test vectors. The chip worked perfectly.

The client loaded one of their production boards with the new chips
and it worked fine.

Philip Freidin

Philip Freidin
Fliptronics

Article: 82167
Subject: Re: ISA vs. patent/trademark
From: "JJ" <johnjakson@yahoo.com>
Date: 7 Apr 2005 14:51:57 -0700
Links: << >>  << T >>  << A >>
I don't buy this argument, at least some of the time.

I can think of atleast 1 application in mind which guarantees most
accesses not aligned and for which a SW aligned version would be ugly
either by doing the align in SW or by accessing sequential bytes.

Example parser performing lexing of string matches straight from the
lcc compiler by Hanson-Fraser..

In lcc each pattern match is something like this, mostly auto generated
for a given dictionary, so for matching "while"

if (cp[0]=="while"[0] &&
cp[1]=="while"[1] &&
cp[2]=="while"[2] &&
cp[3]=="while"[3] &&
cp[4]=="while"[4]) xxxx

This obviously requires 5 possible byte matches and 5 conditional
branches, and most matches will fail until the right production rule is
reached and all matches pass.

VC6 compiler produces good code without trying, lots of byte cmp and
bxx.pairs

In a rewrite I'd would (and do) use
if (same5(cp,"while")) xxxx

where same5 is an inlined match of 2 longs, at byte offset 0, then 1.
Now thats 2 long matches and 2 branches.

Now C might have a tiny dictionary of mostly small words but the
Verilog language has 200 plus words and many can be as long as 20chars
with many words giving false initial matches.

So there is an inline sameN as fn() from 1 to 20chars which takes upto
5matches ie 4x less work. Again VC6 produces good asm, nearly 4x less
than using byte serial checking.

Ofcourse I know this is a problem for RISCs that don't do nonaligned
accesses, but I really hate to see code 4x slower even if its probably
<1% of the total runtime. Now the cpu has to do a bit more work  some
of the time as JM pointed out.

I few more mostly-unaligned kernals come to mind pretty quickly without
thinking too hard, compression etc.

I wonder if the RISC criteria for extreme simplicity need to be
reexamined when most RISCs are way more complex in other depts that are
far less visible to the programmer.

regards

johnjakson at usa dot com
transputer2 at yahoo dot com


Article: 82168
Subject: Re: Interesting article about Xilinx FPGAs in the new Cray
From: "Kryten" <kryten_droid_obfusticator@ntlworld.com>
Date: Thu, 07 Apr 2005 22:18:19 GMT
Links: << >>  << T >>  << A >>

"Leon Heller" <leon_heller@hotmail.com> wrote in message 
news:42556b03$0$289$cc9e4d1f@news-text.dial.pipex.com...
> http://www.fpgajournal.com/articles_2005/20050405_cray.htm

Apart from abusing the word 'leverage' as a verb,
the article seems big on gas and small on substance.
Which is essentially

"Cray machines are using Xilinx FPGA as computing engines".

BFD.

The Sanger Centre has used FPGA solutions to accelerate pattern-matching in 
DNA sequencing.

And that was not rocket science either, as this is essentially comparing a 
pattern with bits in a shift register.







Article: 82169
Subject: Re: Slow rising strobe used to clock IOB's, can it cause trouble?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 08 Apr 2005 10:57:15 +1200
Links: << >>  << T >>  << A >>
Brijesh wrote:
> Symon wrote:
> 
> Hello Symon,
> 
>> Brijesh,
>> Have you considered using the strobe signal at a latch enable rather 
>> than a clock? Rise time is then unimportant. t\The IOBs' storage 
>> elements can be latches, IIRC.
> 
> 
> Its DDR scheme so simple Latch scheme wont work, as data is only stable 
> during the rising/falling edge of the strobe.
> 
> Even otherwise, as I mentioned there are multiple channels and all of 
> them work just fine, except this one. Thats led me to believe its not 
> design problem, but SI issue.

I'd look to see why is that channel slower ?
Slow edges also mean timing skew.
You could also deliberately slow a good one down, to see if that causes 
similar errors, and slow the poor one a little more, to see if it
worsens.
-jg


Article: 82170
Subject: Re: Xilinx V2-Pro + Select Map programming
From: "johnp" <johnp3+nospam@probo.com>
Date: 7 Apr 2005 16:10:06 -0700
Links: << >>  << T >>  << A >>
Dave -

I think the CCLK pin is either open or blown out.  I changed the FPGA
to be Master Serial mode, lifted the CCLK pin at my driver, and
powered up.  No sign of the FPGA producing a CCLK.  Unfortunately,
the FPGA is in a BGA package, so I can't examine the pin.  I think
this expereiment shows either a floating or blown out CCLK pin
on the FPGA.  :(

Thanks for your help.

John P


Article: 82171
Subject: Re: Xilinx V2-Pro + Select Map programming
From: "Bob" <nimby1_notspamm_@earthlink.net>
Date: Fri, 08 Apr 2005 00:38:28 GMT
Links: << >>  << T >>  << A >>

"johnp" <johnp3+nospam@probo.com> wrote in message
news:1112915406.501227.138250@g14g2000cwa.googlegroups.com...
> Dave -
>
> I think the CCLK pin is either open or blown out.  I changed the FPGA
> to be Master Serial mode, lifted the CCLK pin at my driver, and
> powered up.  No sign of the FPGA producing a CCLK.  Unfortunately,
> the FPGA is in a BGA package, so I can't examine the pin.  I think
> this expereiment shows either a floating or blown out CCLK pin
> on the FPGA.  :(
>
> Thanks for your help.
>
> John P
>

BGAs are like women -- you can't live with them and you can't live without
them. IMHO.

Bob




Article: 82172
Subject: FPGA Layout question
From: "Jason Berringer" <jberringer.at@sympatico.dot.ca>
Date: Thu, 7 Apr 2005 21:32:05 -0400
Links: << >>  << T >>  << A >>
Hello all,

I have a question regarding the layout of a BGA packaged FPGA. For the first
time I am using multiple ground planes, and I am curious if when routing the
ground balls from the BGA package, do I need to have a via that attaches to
both ground planes, or is having it attach to one plane directly under the
package enough, as long as there are vias elsewhere that tie the two planes
together. I would ideally like to use blind vias for the BGA layout so I can
get components on the underside of the PCB as well without any through hole
vias getting in the way. My satckup is as follows:

1 - signal/components
2 - ground plane
3 - signal
4 - signal
5 - power plane
6- ground plane
7 - signal
8 - signal
9 - power plane
10 -signal

I was planning on mounting the caps underneath the BGA package on the
underside, again using blind vias so there is more room for signal routing,
but I'm considering mounting them around the package on the top side now.
100 MHz is the highest frequency signal anywhere on the board, and most
signals are 50 MHz speed (or there abouts).

Any comments would be greatly appreciated.

Thanks,

Jason

jberringerNOSPAMatNOSPAMsympatico.ca (remove NOSPAM)



Article: 82173
Subject: Re: Reverse engineering ASIC into FPGA
From: Ray Andraka <ray@andraka.com>
Date: Thu, 07 Apr 2005 23:44:58 -0400
Links: << >>  << T >>  << A >>
Tobias Weingartner wrote:

>If I had specifications, I'd not waste my time on trying to reverse
>engineer the ASIC.  :-)
>
>  
>
If you have a working copy of the ASIC, you can develop your own set of 
specs based on observations of the ASIC's behavior, no?  Granted, it may 
take a bit of work to ferret out all the operation, but it is likely 
still easier than trying to reverse engineer from masks.

-- 
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 82174
Subject: Re: ISA vs. patent/trademark
From: "John Mashey" <old_systems_guy@yahoo.com>
Date: 7 Apr 2005 21:05:02 -0700
Links: << >>  << T >>  << A >>
All of this was fairly well-covered in a *1988* comp.arch thread called
"RISC data alignment", including the reasons why computer *vendors*
were forced to deal with these alignment issues, i.e., IBM (& then DEC
VAX) FORTRAN (interaction of EQUIVALENCE & COMMON, INTEGER*2, and
sometimes call-by-reference) .




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