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 26550

Article: 26550
Subject: Re: Very Lucrative FPGA Jobs
From: Ray Andraka <ray@andraka.com>
Date: Fri, 20 Oct 2000 00:52:24 GMT
Links: << >>  << T >>  << A >>
If it really were that lucrative, I would expect the position to be already
filled!

Austin Franklin wrote:
> 
> > Consultants or FPGA Designers (Field Programmable Gate Array) will be
> > involved with designing Programmable Logic Chips, otherwise known as
> PLD's.
> > These PLD's make up a high density field of gates called FPGA
> Architectures.
> > The FPGA designers will be involved with designing a "gate array" which
> is
> > an unfinished chip...
> 
> Now, do you REALLY think someone would be qualified to do this job if you
> had to explain this to them...especially like this?

-- 
-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  or http://www.fpga-guru.com

Article: 26551
Subject: Re: Very Lucrative FPGA Jobs
From: "S. Ramirez" <sramirez@deleet.cfl.rr.com>
Date: Fri, 20 Oct 2000 01:14:36 GMT
Links: << >>  << T >>  << A >>
Austin,
     Obviously this is a headhunter or a human resources person that posted
this.  (S)he probably had some input from a manager or engineer, and they
had to decipher that input, the end-result being a menage-a-trois of
buzzwords.  This poster is probably not technically inclined.
-Simon Ramirez, Consultant
 Synchronous Design, Inc.


"Austin Franklin" <austin@darkroo99.com> wrote in message
news:01c03a2b$fe9869a0$e602f7a5@drt1...
> > Consultants or FPGA Designers (Field Programmable Gate Array) will be
> > involved with designing Programmable Logic Chips, otherwise known as
> PLD's.
> > These PLD's make up a high density field of gates called FPGA
> Architectures.
> > The FPGA designers will be involved with designing a "gate array" which
> is
> > an unfinished chip...
>
> Now, do you REALLY think someone would be qualified to do this job if you
> had to explain this to them...especially like this?
>
>
>



Article: 26552
Subject: Off subject-FPGA DESIGNERS for new PDA start up in San Jose
From: howard@recruitexpress.com (Recruit Express)
Date: Fri, 20 Oct 2000 01:42:34 GMT
Links: << >>  << T >>  << A >>
PDA  DEVELOPERS - San Jose
ASIC, FPGA, Windows Device Drivers 

Pre-IPO firm in San Jose area needs several developers for
new modules and components to be developed for use with
wireless PDA devices.  This is a new technology and a 'fresh
paint' - clean canvas' opportunity for you!

Hardware engineers should have 3 years design experience
in FPGA and ASIC.   

Software engineers should have 2 years development experience -  
on Windows device drivers and be proficient in C.   

We want to hire you immediately!  Our salary range is from
$80K to $125K plus other financial opportunities - based upon
the depth of your skills and the breadth of your experience.  

We are interested in persons living in the Bay Area only.  
We prefer to offer permanent employment but will consider
contractors.  U.S. citizenship or work permit required.  
We will sponsor visas of persons living in the Bay Area.


Recruit EXpress, our search firm, will pay you a $3,000.00
bonus if you are hired - or if the persons you refer to them 
are also hired for our openings. We have six openings.


Call or send your resume to Rex or Howard Frankel, at
Recruit EXpress
 (713) 666-1001 ....  or fax (713) 666-9993.  Their email is: 

REX@RecruitEXpress.com

or

HOWARD@RecruitEXpress.com

 


Article: 26553
Subject: Re: PCI Core : Clock Problem
From: yuryws@my-deja.com
Date: Fri, 20 Oct 2000 03:18:41 GMT
Links: << >>  << T >>  << A >>
In article <ee6e536.-1@WebX.sUN8CHnE>,
  "Walter Haas" <walter_haas@pmc-sierra.com> wrote:
> I'm using the PCI core from Xilinx, and I'm having some problems when
I try to synthesize with Synplify Pro.
>
> This problem comes in two parts:
>
> 1) Because the core is a Black Box, Synplify doesn't know that it has
it's own pads and especially it's own Global Clock. I usually have to
edit out the pad and buffer it instantiates for the core from the EDF
netlist, and that
> usually works. It's a pain in the ass though, and I only seem to see
it sporadically. Anyone know the cause?
>
> 2) The output (and globally buffered) clock from the PCI core is a
clock I use extensively in my design. However, because Synplify doesn't
know that it's globally buffered, it inserts more buffers all over the
place, which in turn makes the Xilinx Skew analysis puke. Anyone know
how to solve this?
>
> This posting is mirrored on the xilinx general newsgroup, as well as
news.synplicity.com, on the synplicity.synplify. I'm a bit of a newbie
when it comes to newsgroups...
>
> Cheers,
>
> Wally
>


   In my PCI core based design I use FPGA Express. I have been following
Xilinx's Implementation Guide, which indicates that it is necessary to
include in my FPGA Express project two behavioral HDL files describing
the core in addition to my synthesisable design files. That works
without any problems. The NGD2VHDL's search path includes the actual
location of the core .xnf files, so they are properly inserted in the
design.

--Yury



Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 26554
Subject: Re: DS2401 security from pirating an FPGA
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 19 Oct 2000 23:23:33 -0400
Links: << >>  << T >>  << A >>
Ray,

Unless Dallas is doing something that they are not showing in all of
their data sheets and app notes, they guarantee that each and every part
in the one wire family has a unique serial number. To the best of my
knowledge, you can not order parts with the same number. They have a
portion of the number which they will set to a given value to indicate
you as a customer, and 8 bits indicate the device type. But the rest of
the number, 48 bits IIRC, is always unique.  

But I am pretty sure that you can't use this as security in an FPGA,
even if you tailor each bit stream to match the SN. The problem is that
the one wire part can be duplicated very easily in a very inexpensive
microP. In fact, I think you can get the microP cheaper than the one
wire part!!!


Ray Andraka wrote:
> 
> you can order many with the same number.  Part of the serial number is a
> manufacturer ID that is unique to a customer.  The rest is specified by the
> customer.  The problem with a DS2401 is that it is trivial to capture the serial
> number, and then that is easy to duplicate with a CPLD.  The timing spec on
> those is pretty loose to make sure they work in your application. It is easy to
> duplicate the timing within the tolerance of the part.
> 
> Dan wrote:
> >
> > Hi,
> >
> > This security method can be broken by replicating the serial number.
> >
> > How much more secure would it be to not only check the serial number but
> > also check the timing. For example: read it a bit too slow and a bit too
> > fast and expect it to fail. If it passes, it must be a copy stored in some
> > other device with different timing ?
> >
> > Does every purchaser of the DS2401 get a unique number ?? How could this be
> > ??
> >
> > If I buy 100 and later buy another 100 how will they have the same serial
> > number ??
> >
> > How would they know how many to produce with each number ?
> >
> > Makes it sound like each one is unique. This means every FPGA board must be
> > reprogrammed to look for a unique number. Is this the case ?
> >
> > Dan
> 
> --
> -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  or http://www.fpga-guru.com

-- 

Rick "rickman" Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 26555
Subject: Any takers for "UCF Question" posted 10/19/2000?
From: yuryws@my-deja.com
Date: Fri, 20 Oct 2000 03:31:54 GMT
Links: << >>  << T >>  << A >>
Thanks


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 26556
Subject: Re: How safe is the algorithm implemented with FPGA?
From: "Jan Gray" <jsgray@acm.org>
Date: Fri, 20 Oct 2000 04:18:15 GMT
Links: << >>  << T >>  << A >>
See also Brian Dipert's new article on PLD design security in EDN, "Cunning
circuits confound crooks",
http://www.ednmag.com/ednmag/reg/2000/10122000/21df2.htm.

Jan Gray, Gray Research LLC




Article: 26557
Subject: Mailbox (was "Asynchronous pulse generation with Spartan.")
From: Eric Montreal <ervNOSPAM@sympatico.ca>
Date: Fri, 20 Oct 2000 04:19:07 GMT
Links: << >>  << T >>  << A >>
Hi,

Thanks for the answer, I now understand the problem better :
while the mailbox flag reset pulse is in progress and this can be pretty long, it will miss
the rising edge of the clock. It could work if a quite long delay (>40 ns) is observed from
the time the mailbox is found empty to the leading edge of the pulse writing new data.

looks like the whole synchro described in the 74F552 data sheet that I was trying to duplicate
is somehow flawed.

I've made my own little mailbox, and it seems to work much better, read and write clock
being completely independent and edge triggered (CLR is no more used except as a global
reset). Delay from reading the flag to either reading/writing the next data (the one you
mentionned as being tREC in the '552 data sheet) is now 1 FD delay + 1combinatorial delay
+ routing, and output should be glitch free (only 1 input of the XOR changes at a time).

Schematic diagram :
http://www3.sympatico.ca/erv/mailbox.gif

Simulated behavior (various illegal condition tested, always behaved as expected) :
http://www3.sympatico.ca/erv/mailbox_sim.gif
(write data supposed valid on the rising edge of W)

Is here a better, standard solution to design a mailbox ?

Thank you for pinpointing the problem and taking time to explain it !

Best regards,

Eric.

BTW, do you know about schematic libraries of little logic circuits for such
common functions that would prevent re-inventing the wheel over and over ?
------------------------------------------------------------------------

rickman wrote:

> Eric Montreal wrote:
> > Your answer is interesting to me, because you both state that there are no reasons
> > why it would not work, but at the same time, you suggest that I should better stay
> > away from it.
> > Looks like a kind of race condition between reason and doubt, and it's what most
> > peoples (including me, else I would not have asked !) seem to think about such designs.
> >
> > A point in your answer that I don't completely get what you mean by "it all depends on
> > how you are using the part" ?
> >
> > Do you refer to variable conditions such as voltage, temperature, lot to lot variation or
> > to routing delays or large output loads degrading the pulse waveform ?
>
> My caution of using a design like this is not in the ability of such a
> design to mimic the behavior of the chip, but rather a caution in how
> you use the design just as I would caution you in how you use the chip.
>
> Part of the problem is the uncharacterized elements that you are working
> with which will prevent you from having good data on the maximum width
> of the generated reset pulse. This will prevent you from knowing the
> maximum frequency of operation. After all, the internal FF reset pulse
> must be gone a certain amount of time before you can set it again with
> the clock.
>
> But I have not done a detailed analysis of your circuit or of any of the
> timing issues. I will leave that to you since you seem capable. In
> general you seem to understand the issues (temp, voltage, etc...).
>
> My main concern is that this circuit will be hard to test, simulate and
> may give unexpected results depending on just how you use it in the
> larger circuit. It not only has limitations in how you implement it, but
> it has limitations in how you can use it. I guess my main concern is the
> recovery time from rising edge of OExx to the rising edge of CPx when
> CEx is asserted (tREC in the data sheet). This will be very poorly
> characterized in your FPGA since this is determined by the max width of
> the reset pulse which is determined by all the unknown stuff like the
> routing, etc...
>
> So if you are running slow and your other circuits are synchronous, you
> can likely work with this.
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
>
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com


Article: 26558
Subject: DSP-Core C31
From: "Andreas Kirchgraber" <andreas.kirchgraber@vs.dasa.de>
Date: Fri, 20 Oct 2000 08:21:58 +0200
Links: << >>  << T >>  << A >>
I am looking for a Core for the TI C31 DSP. Does anybody know where I can
buy this Core ?

Thanks

Andreas

-------------------------------------------
Andreas Kirchgraber // Andreas.Kirchgraber@vs.dasa.de
-------------------------------------------



Article: 26559
Subject: Re: Synopsys FPGA Compiler II on Solaris
From: Lars Rzymianowicz <larsrzy@ti.uni-mannheim.de>
Date: Fri, 20 Oct 2000 09:40:50 +0200
Links: << >>  << T >>  << A >>
Georg Acher wrote:
> A bit OT, but it may help:
> I haven't actually tried it with this particular Synopsys version, but KDE can move
> windows with <ALT>+<Button1> and resize them with <ALT>+<Button3>, this can be adjusted
> in the KDE Control Center under Windows/Mouse. A window frame is not necessary, it works
> even with the shaped windows of xeyes.

Gee, it works!
Thanks, Georg. Some solutions are so trivial... ;-)

Lars
-- 
Address:  University of Mannheim; B6, 26; 68159 Mannheim, Germany
Tel:      +(49) 621 181-2716, Fax: -2713
email:    larsrzy@{ti.uni-mannheim.de, atoll-net.de, computer.org}
Homepage: http://mufasa.informatik.uni-mannheim.de/lsra/persons/lars/

Article: 26560
Subject: Re: Mailbox (was "Asynchronous pulse generation with Spartan.")
From: Philip Freidin <philip@fliptronics.com>
Date: Fri, 20 Oct 2000 01:16:34 -0700
Links: << >>  << T >>  << A >>
On Fri, 20 Oct 2000 04:19:07 GMT, Eric Montreal <ervNOSPAM@sympatico.ca> wrote:
>Hi,
>
>Thanks for the answer, I now understand the problem better :
>while the mailbox flag reset pulse is in progress and this can be pretty long, it will miss
>the rising edge of the clock. It could work if a quite long delay (>40 ns) is observed from
>the time the mailbox is found empty to the leading edge of the pulse writing new data.

As with most flag/mailbox type applications, there is the assumption that there
is the equivalent of a token that is passed back and forth between two domains,
in your case the "writer" and the "reader" . It is important that each domain
not touch the data until it has the token, and should not pass the token back
until it has finished with it (either completed the write or read operation).

In your case the owner of the token is indicated by the state of the FF
in your first design, and the output of the XOR in your second design.

The tragic problem of using the asynchronous reset for passing the token
in one of the two directions is that it must meet some minimal pulse width
to guarantee that the reset occurs. To calculate the delay, you must use
the minimum delay of the various delay elements, and your use of a slew
rate limited output certainly was novel. (the permanently enabled input
latch would have always been trimmed, so that would have been
problematic). Unfortunately the real silicon is probably not at its very
best and so the typical delay would have been longer. As Rick Collins
pointed out, there then arises the issues of recovery time, since the
write side will be ignored during the reset pulse, and for a little time
more.

What you really want is a flipflop with two edge triggered clock pins.

>looks like the whole synchro described in the 74F552 data sheet that I was trying to duplicate
>is somehow flawed.

Yep. It is a sucky design.

>I've made my own little mailbox, and it seems to work much better, read and write clock
>being completely independent and edge triggered (CLR is no more used except as a global
>reset). Delay from reading the flag to either reading/writing the next data (the one you
>mentionned as being tREC in the '552 data sheet) is now 1 FD delay + 1combinatorial delay
>+ routing, and output should be glitch free (only 1 input of the XOR changes at a time).
>
>Schematic diagram :
>http://www3.sympatico.ca/erv/mailbox.gif
>
>Simulated behavior (various illegal condition tested, always behaved as expected) :
>http://www3.sympatico.ca/erv/mailbox_sim.gif
>(write data supposed valid on the rising edge of W)

Your circuit is one of that I have seen many times (which is good, because it
means great minds think alike) and I have used it several times my self. This
circuit was in fact used in the PAL22IP6 from MMI (at the time a wholly owned
subsidiary of AMD) in 1988, and made the cover of Electronic Design magazine
on July 14, 1988. Unfortunately the claims for it included getting rid of
metastability (it doesn't, it just pushes it somewhere else).

More recently, this circuit appeared in Xilinx's XCELL magazine this month, on
page 54. (Fall 2000 issue, #37.) Although it has yet to appear on the Xilinx
web site, the author (from Memec Design Services) has had it available
at his web site for several months.

    http://www.memecdesign.com/resources/guides/Flancter_App_Note.pdf

>Is here a better, standard solution to design a mailbox ?

There are lots of solutions. This one is fairly good.

But you must still be careful with it. We will assume that your reader and
writer are in different clock domains (otherwise you wouldn't be using this
circuit). As such, each side will be looking at the output of the circuit when
it does not have the token (i.e. waiting). When the token is passed (the
circuit toggles to the other state), the leading edge of the transition
occurs in the other clock domain, and cannot be reliably used directly
to initiate state changes, as there is the very real probability of setup or
hold time violation. This can be reasonably dealt with by following the
circuit with a two stage synchronizer, for each domain (total of 4
flip flops.). In the Memec article, two of these are shown in their figure
4, for the SYSCLK domain. I believe they should have also shown
two more for the uP domain. Let me clarify for your application:
The output of the XOR feeds the D input of two flipflops, one
clocked by the W domain clock, and the other clocked by the R
domain clock. The output of the W domain FF feeds a second FF
also clocked by the W domain clock, and the output of this second
synchronizing FF can then be used in the W domain. Likewise,
the output of the first R domain synchronizing FF feeds a second FF
clocked by the R domain clock, and its output can be used in the R
domain. This adds two cycles of latency in transfering the token, but
it is necessary to minimize metastability issues. So the whole circuit
is 6 FFs and an XOR and an inverter. FFs are cheap in an FPGA, so
its not like this is expensive.

>Best regards,
>Eric.
>
>BTW, do you know about schematic libraries of little logic circuits for such
>common functions that would prevent re-inventing the wheel over and over ?

Unfortunately the only book I regularly refer to is the 1973 TTL applications
handbook (out of print for about 25 years), much of which is still relevant
in todays high speed logic designs. My copy is autographed by the editor,
Peter Alfke.


========================
Philip Freidin
Mindspring that acquired Earthlink that acquired Netcom has
decided to kill off all Netcom Shell accounts, including mine.
My new primary email address is    philip@fliptronics.com
Please update your address book, sorry for the inconvenience

Article: 26561
Subject: Re: 5V compatible Virtex
From: "Grumps" <grumps@here.com>
Date: Fri, 20 Oct 2000 11:04:58 +0100
Links: << >>  << T >>  << A >>
I need to provide 24 TTL I/O lines. Each signal must be able to be set to an
IN or an OUT (micro control through FPGA register). When set to OUT, I need
the ability to sink 20mA (ish). This (and other) is the reason I've gone for
Spartan-II. Anyway, they are really cheap.

<eml@riverside-machines.com.NOSPAM> wrote in message
news:39ed83ab.12538305@news.dial.pipex.com...
> On Sat, 14 Oct 2000 11:12:09 +0100, Rick Filipkiewicz
> <rick@algor.co.uk> wrote:
>
> >Jonas Thor wrote:
> >
> >> Hello!
> >>
> >> I have a follow up question. Do you know of any 3.3V <-> 5V integrated
> >> translaters around? I can do the translation with a few discrete
> >> componentents but I rather use a IC. Any hints???
> >>
> >> / Jonas
> >>
> >
> >The best way is to use parts generically called ``QuickSwitch'' from the
> >company that first made them [now owned by IDT]. These are basically a
bunch
> >of pass transistors that have the characteristic that the resistance
> >increases as the voltage on the driving size approaches the device's VCC.
In
> >effect they clamp the output side to about VCC - 0.7. For our 3.3V
conversion
> >we power the 5V parts from a 3.9V supply. You can now get 3.3V versions
which
> >we are about to use in the same way to get LVTTL <-> SSTL2 conversion.
> >
> >These parts have the huge advantage that they add almost no delay - about
> >250ps or so - in the transition range of 0 -> 3.0V where Ron stays at
about
> >10R.
> >
> >The best place to look for this stuff is probably Pericom's web site.
>
> Also, the additional power supply is easier than it might seem. You
> can just use a diode to drop your 5V to ~4.3V, and power your
> QuickSwitch off that. I prefer an active diode, ie. a transistor and a
> resistor. You can get 8-bit bidirectional switching with just a
> transistor, a resistor, and something cheap like a QS3244.
>
> Evan



Article: 26562
Subject: Re: How safe is the algorithm implemented with FPGA?
From: kolja@prowokulta.org
Date: Fri, 20 Oct 2000 10:12:50 GMT
Links: << >>  << T >>  << A >>

>  For a the guy who wants to copy your design exactly, it is easily
> done.  You can make it harder by using unmarked or custom markings
> on the device, and requiring the device to interact with other
> elements in  the system that may be harder to copy the board design
> (like a micro with an embedded instruction store).

You should think about what you are trying to protect.

If you are concerned about bitwise copying of your FPGAs than a marking
really should be sufficient. If the market penetration of the forged
designs is that low that you can not find them, then they do not hurt
your profits very much, and it is not worth going after them anyway.
When they start hurting your sales it should be easy to find them.

If you implemented a well known algorithm I can not imagine a competitor
doing the very cumbersome process of reverse engineering just to be
able to use your design tricks and architechture decisions.
Someone with manpower and knowhow to do this propably could outperform
your work with a redesign.

So, what is left:
New algorithms invented by you and secret parts of known algorithms,
such as decryption keys.
Especially for the latter paranoid protection could be useful.
But, as Nick pointed out, that's almost impossible to achieve.
There is - expensive - equipment that can read the content of SRAM
cells. This would even break Xilinx Virtex-II DES approach.

CU,
    Kolja





Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 26563
Subject: Re: DS2401 security from pirating an FPGA
From: Ray Andraka <ray@andraka.com>
Date: Fri, 20 Oct 2000 12:05:28 GMT
Links: << >>  << T >>  << A >>
With enough $ you can get anything you want :-)

Anyway, my point was that it doesn't provide much if any security

rickman wrote:
> 
> Ray,
> 
> Unless Dallas is doing something that they are not showing in all of
> their data sheets and app notes, they guarantee that each and every part
> in the one wire family has a unique serial number. To the best of my
> knowledge, you can not order parts with the same number. They have a
> portion of the number which they will set to a given value to indicate
> you as a customer, and 8 bits indicate the device type. But the rest of
> the number, 48 bits IIRC, is always unique.
> 
> But I am pretty sure that you can't use this as security in an FPGA,
> even if you tailor each bit stream to match the SN. The problem is that
> the one wire part can be duplicated very easily in a very inexpensive
> microP. In fact, I think you can get the microP cheaper than the one
> wire part!!!
> 
> Ray Andraka wrote:
> >
> > you can order many with the same number.  Part of the serial number is a
> > manufacturer ID that is unique to a customer.  The rest is specified by the
> > customer.  The problem with a DS2401 is that it is trivial to capture the serial
> > number, and then that is easy to duplicate with a CPLD.  The timing spec on
> > those is pretty loose to make sure they work in your application. It is easy to
> > duplicate the timing within the tolerance of the part.
> >
> > Dan wrote:
> > >
> > > Hi,
> > >
> > > This security method can be broken by replicating the serial number.
> > >
> > > How much more secure would it be to not only check the serial number but
> > > also check the timing. For example: read it a bit too slow and a bit too
> > > fast and expect it to fail. If it passes, it must be a copy stored in some
> > > other device with different timing ?
> > >
> > > Does every purchaser of the DS2401 get a unique number ?? How could this be
> > > ??
> > >
> > > If I buy 100 and later buy another 100 how will they have the same serial
> > > number ??
> > >
> > > How would they know how many to produce with each number ?
> > >
> > > Makes it sound like each one is unique. This means every FPGA board must be
> > > reprogrammed to look for a unique number. Is this the case ?
> > >
> > > Dan
> >
> > --
> > -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  or http://www.fpga-guru.com
> 
> --
> 
> Rick "rickman" Collins
> 
> rick.collins@XYarius.com
> 
> Ignore the reply address. To email me use the above address with the XY
> removed.
> 
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
> 
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
> 
> Internet URL http://www.arius.com

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

Article: 26564
Subject: Re: Virtex E development boards
From: Jerry English <jenglish@planetc.com>
Date: Fri, 20 Oct 2000 08:30:00 -0400
Links: << >>  << T >>  << A >>
Might be easier to recommend something if you stated your requirements.
;>)

Domagoj wrote:

> Hi,
>     I'm looking for Virtex E development boards. I had a look on
> http://www.xilinx.com/products/protoboards/protoboards.htm
> but couldn't find any company offering what I'm looking for.
>
> Any recomendations ?
>
> Thanks. Regards,
>
> -------------------------------------------
> -             Domagoj              -
> - Domagoj@engineer.com -
> -------------------------------------------


Article: 26565
Subject: Re: Very Lucrative FPGA Jobs
From: Ron Huizen <rhuizen@bittware.com>
Date: Fri, 20 Oct 2000 09:17:54 -0400
Links: << >>  << T >>  << A >>
OK, this is just too hard to let pass by.  See comments inserted below:

Edwin wrote:

> Our client is looking for FPGA(Field Programmable Gate Array) designers to
> work on a major effort to become the embedded technology supplier of choice
> for the world's leading telecommunications and networking companies.

Wow! That's quite a goal!  Can I buy some of their stock?

> The
> project is part of the effort to utilize FPGA designers

Another lofty goal - utilizing FPGA designers :-)  This may be harder than the
first one.

> to help develop a
> new line of CPU boards, communication interfaces such as T1/E1 spans or fast
> serial ports) and protocol subsystems that can be sold off the shelf to
> customers

What a novel idea!  Boy, this sure is ground breaking stuff! Maybe these guys
are going to
invent COTS just like Mr. Gore invented the internet.

> so that their internal engineers and designers can utilize these
> platforms that will be used to develop chips

Hang on, are these development tools or end products?

> to be used in mobile phones and
> telecommunications equipment.

>
>
> Day-to-Day Responsibilities:
>
> Consultants or FPGA Designers (Field Programmable Gate Array) will be
> involved with designing Programmable Logic Chips, otherwise known as PLD's.

I wonder if he knows what PLD stands for?

>
> These PLD's make up a high density field of gates called FPGA Architectures.

Hmm, better check with XILINX and Altera to see if they are aware of this.

>
> The FPGA designers will be involved with designing a "gate array" which is
> an unfinished chip with electronic components that have not yet been
> connected.

Oh, maybe when they say FPGA designer, they mean actually designing the FPGA
itself!

> The designer will complete the chip by designing and adhering
> the top metal layers which provide interconnecting pathways.

What do they use for that?  An arc welder?  Super glue?

> Once these
> chips are designed, then they will be turned over to manufacturing for mass
> production.

If its so mass, wouldn't they be ASICs?

> These chips will make up final products such as CPU boards,
> communication interfaces, and protocol subsystems that will be used in the
> telecommunications industry.

So, the FPGA designer designs a chip which is mass produced and then used on
your other
boards??  Wonder what that "FP" stands for in FPGA??

>
> There are a total of 9 groups for that have anywhere from 4 to 14 FPGA
> designers and Hardware Engineers that are working on the 3 major products
> for different customers.  Submitted candidates will be placed in groups that
> need the most help.

That seems like a novel management approach.  Put people where they are needed
the
most.  I'd better write that one down so I don't forget it.

> This is a cross functional project environment.

Yeah, you're working with anywhere from 36 to 126 FPGA designers.  Sounds pretty

cross functional to me.

>
> Candidates will always work under a principal engineer.

Uh-oh. Sounds like trouble.

> FPGA designers will
> track their performance and product development with Microsoft Project that
> will be reported to the head engineer.

What!  You want an FPGA designer to use Microsloth Project?  Oh well, at least
they
get to track their own performance.  Who's the head engineer?  Is he the guy who

picks which programming head we get to use?

>
>
> Essential Skills:
>
> Power PC

Power PC? I never thought of that as a marketable skill, although I guess have
years of
experience plugging in my PC.

> PCI Hardware and Software

> VHDL
> Embedded Hardware Design
> 3 years experience in the industry
>
> Plus Skills:
>
> View Logic (Schematic Capture Product)
> Simulation Experience (Signal Quality or Timing Simulation experience)
> UNIX Experience
> Telecom Experience (T1/E1 Interfaces)

----
Ron Huizen
BittWare


Article: 26566
Subject: Re: Mailbox (was "Asynchronous pulse generation with Spartan.")
From: Eric Montreal <ervNOSPAM@sympatico.ca>
Date: Fri, 20 Oct 2000 13:35:13 GMT
Links: << >>  << T >>  << A >>
Hi,


Philip Freidin wrote:

> On Fri, 20 Oct 2000 04:19:07 GMT, Eric Montreal <ervNOSPAM@sympatico.ca> wrote:
> >Hi,
> >
> >Thanks for the answer, I now understand the problem better :
> >while the mailbox flag reset pulse is in progress and this can be pretty long, it will miss
> >the rising edge of the clock. It could work if a quite long delay (>40 ns) is observed from
> >the time the mailbox is found empty to the leading edge of the pulse writing new data.
>
> As with most flag/mailbox type applications, there is the assumption that there
> is the equivalent of a token that is passed back and forth between two domains,
> in your case the "writer" and the "reader" . It is important that each domain
> not touch the data until it has the token, and should not pass the token back
> until it has finished with it (either completed the write or read operation).
>

I use it for a bi directional link between a PC (printer parallel port interface) and a target
microcontroller and both poll the status flag in software (timing is thus not too critical).

>
> In your case the owner of the token is indicated by the state of the FF
> in your first design, and the output of the XOR in your second design.
>

that's how it works.

>
> The tragic problem of using the asynchronous reset for passing the token
> in one of the two directions is that it must meet some minimal pulse width
> to guarantee that the reset occurs. To calculate the delay, you must use
> the minimum delay of the various delay elements, and your use of a slew
> rate limited output certainly was novel. (the permanently enabled input
> latch would have always been trimmed, so that would have been
> problematic).

You're right, is there a way to prevent such trimming (if the delay element is
used, this should not happend) ?

Even now that I dropped the '552 design, I will keep this pulse generator in
my bag of tricks, despite it's limitations (consumes a lot of power, generate
unpredictable and not unit to unit repetable EMI interference, mostly with
bonded pads) it might save the day in the future.

> Unfortunately the real silicon is probably not at its very
> best and so the typical delay would have been longer.

I don't like relying on silicon being slow, reminds me PC loop based delay
programming when peoples designed as if a PC would never be more than
2 to 3 times a 5 Mhz 8088 !

In facts the design relied on the delay element, because it's the only part
of the Spartans that have a specified minimum delay. (more complete
specification, including max delay would be nice).
The "slew rate limited" output was more an attempt to limit EMI and increase
safety margin than the main delay, because min delay for it is not specified
and highly capacitive (thus package/pin location) dependent.

> As Rick Collins
> pointed out, there then arises the issues of recovery time, since the
> write side will be ignored during the reset pulse, and for a little time
> more.

That's what I discovered reading his reply !

>
>
> What you really want is a flipflop with two edge triggered clock pins.
>
> >looks like the whole synchro described in the 74F552 data sheet that I was trying to duplicate
> >is somehow flawed.
>
> Yep. It is a sucky design.
>

I finally realised it ...

>
> >I've made my own little mailbox, and it seems to work much better, read and write clock
> >being completely independent and edge triggered (CLR is no more used except as a global
> >reset). Delay from reading the flag to either reading/writing the next data (the one you
> >mentionned as being tREC in the '552 data sheet) is now 1 FD delay + 1combinatorial delay
> >+ routing, and output should be glitch free (only 1 input of the XOR changes at a time).
> >
> >Schematic diagram :
> >http://www3.sympatico.ca/erv/mailbox.gif
> >
> >Simulated behavior (various illegal condition tested, always behaved as expected) :
> >http://www3.sympatico.ca/erv/mailbox_sim.gif
> >(write data supposed valid on the rising edge of W)
>
> Your circuit is one of that I have seen many times (which is good, because it
> means great minds think alike) and I have used it several times my self. This
> circuit was in fact used in the PAL22IP6 from MMI (at the time a wholly owned
> subsidiary of AMD) in 1988, and made the cover of Electronic Design magazine
> on July 14, 1988. Unfortunately the claims for it included getting rid of
> metastability (it doesn't, it just pushes it somewhere else).
>

Damned, I already prepared myself for nobel prize ;-)

In facts, it's just a stripped down FIFO controller (2 saturated counters + comparator).

The discussions around metastability often remind me discussions with peoples
who believe they just discovered *the* trick that would make multi level marketing
work, and can't get why it never will ...

>
> More recently, this circuit appeared in Xilinx's XCELL magazine this month, on
> page 54. (Fall 2000 issue, #37.) Although it has yet to appear on the Xilinx
> web site, the author (from Memec Design Services) has had it available
> at his web site for several months.
>
>     http://www.memecdesign.com/resources/guides/Flancter_App_Note.pdf
>

Thanks for the link, it's very interresting, even if it somehow pisses me off ;-)

BTW, the author would equally dislike your reference to the 1988 EDM article.

>
> >Is here a better, standard solution to design a mailbox ?
>
> There are lots of solutions. This one is fairly good.
>
> But you must still be careful with it. We will assume that your reader and
> writer are in different clock domains (otherwise you wouldn't be using this
> circuit). As such, each side will be looking at the output of the circuit when
> it does not have the token (i.e. waiting). When the token is passed (the
> circuit toggles to the other state), the leading edge of the transition
> occurs in the other clock domain, and cannot be reliably used directly
> to initiate state changes, as there is the very real probability of setup or
> hold time violation. This can be reasonably dealt with by following the
> circuit with a two stage synchronizer, for each domain (total of 4
> flip flops.). In the Memec article, two of these are shown in their figure
> 4, for the SYSCLK domain. I believe they should have also shown
> two more for the uP domain.

This figure 4 is an almost perfect illustration of my app, except the
microcontroller side gets the flag by polling instead of int.
This way, the data is (single stage) latched when the register is accessed.

I can't do better, since I don't have access the processor's clock.

However, since the communication can be over a long cable, there are
provisions for retransmit at the higher level (software).

The omission of the synchroniser in the interrupt generation could be just
that, or it could be a sign that they rely on the glitch suppression circuit
that is present in most processor's interrupt line circuitry.

> Let me clarify for your application:
> The output of the XOR feeds the D input of two flipflops, one
> clocked by the W domain clock, and the other clocked by the R
> domain clock. The output of the W domain FF feeds a second FF
> also clocked by the W domain clock, and the output of this second
> synchronizing FF can then be used in the W domain. Likewise,
> the output of the first R domain synchronizing FF feeds a second FF
> clocked by the R domain clock, and its output can be used in the R
> domain. This adds two cycles of latency in transfering the token, but
> it is necessary to minimize metastability issues. So the whole circuit
> is 6 FFs and an XOR and an inverter. FFs are cheap in an FPGA, so
> its not like this is expensive.
>

one of the reasons peoples (like me) who discover FPGA want to put them
everywhere ;-)

>
> >Best regards,
> >Eric.
> >
> >BTW, do you know about schematic libraries of little logic circuits for such
> >common functions that would prevent re-inventing the wheel over and over ?
>
> Unfortunately the only book I regularly refer to is the 1973 TTL applications
> handbook (out of print for about 25 years), much of which is still relevant
> in todays high speed logic designs. My copy is autographed by the editor,
> Peter Alfke.
>

I did the same (Fairchild databook), but hit the wrong number (74F552) !

I would be glad to use & contribute to a website containing schematic libraries of
"invented weels" if such a thing existed (the model is already proven to work for
software "objects") ...

have a nice day,

Eric.


Article: 26567
Subject: Re: Very Lucrative FPGA Jobs
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 20 Oct 2000 15:52:30 +0200
Links: << >>  << T >>  << A >>
Ron Huizen <rhuizen@bittware.com> writes:

> >
> >
> > Essential Skills:
> >
> > Power PC

> Power PC? I never thought of that as a marketable skill, although I
> guess have years of experience plugging in my PC.

He probably meant PowerPC, as in MPC7400(*).

(*) No, that's not AND-gates, it's a proecssor.

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 26568
Subject: Re: VHDL vs Verilog
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Fri, 20 Oct 2000 14:57:55 +0100
Links: << >>  << T >>  << A >>
On Thu, 19 Oct 2000 13:26:09 -0700, Andy Peters <"apeters <"@> n o a o
[.] e d u> wrote:

>Muzaffer Kal wrote:
>> 
>> Ray Andraka <ray@andraka.com> wrote:
>> 
>> >I don't think there is such a thing as neutral ground when it comes to that
>> >subject.  It is more like religion.  That said, I use VHDL because it gives me
>> >more control for getting the design to exactly what I want.  

>> Ray,
>> would you like to expand little bit on what things VHDL does better
>> for you ?
>
>Here's my take on it.  I had a Verilog refresher yesterday.
>
>VHDL forces you to think more about what you're trying to accomplish. 
>It's verbose, but by being verbose, things are clearly specified.
>
>Also, Verilog gives you enough rope to hang yourself.  For instance, it
>allows you to connect things (vectors, ports, etc) with mismatched
>sizes.  

Another way of looking at it; Verilog more closely resembles C, while
VHDL resembles academically designed programming languages like Modula-2
or Ada.

Verilog users prefer Verilog because of its resemblance to C; 
I prefer VHDL for precisely the same reason!

;-)

- Brian

Article: 26569
Subject: "Number of logic levels" in xilinx PAR reports
From: Steven Derrien <sderrien@irisa.fr>
Date: Fri, 20 Oct 2000 16:06:24 +0200
Links: << >>  << T >>  << A >>
Hello,

I am looking for precisions regarding the "number of logic levels"
figure provided in the PAR clock performance report. 
Specifically I was wondering what is exactly considered as a "logic
level": is it the number of primitive(such as MUXCY, XORCY or LUT) in
the path ? or is it the number of logic cells delay (considering that a
logic cell is a LUT+its assocaited carry logic)?

Article: 26570
Subject: Re: How safe is the algorithm implemented with FPGA?
From: "Ulf Samuelsson" <ulf@atmel.spammenot.com>
Date: Fri, 20 Oct 2000 17:58:00 +0200
Links: << >>  << T >>  << A >>
As people have pointed out, there is no 100% solution to protection.
You can make it harder.
The FPSLIC AVR+FPGA will soon come out in a multichip package
where the configurator is inside the package without visibility of the
bitstream.
You can program the part and you can erase the part.
Not sure how verification works though!

While it is not perfect, you cannot easily read the contents without
opening up the package and even then you have to use advanced equipment.


--
Best regards,
ulf at atmel dot com
The contents of this message is intended to be my private opinion and
may or may not be shared by my employer Atmel Sweden

"Yu Chen" <yuchen@edson.ee.ualberta.ca> wrote in message
news:8sn8vg$pd4$1@rover.ucs.ualberta.ca...
>
> Hi, there,
>
> I'd like to know more about this topic:
> How safe is the algorithm which is implemented using Altera's products? I
mean, in case someone less got the FPGA(or ASIC)with the algorithm coded in
it and he wanted to steal the algorithm, how much effort is needed for him
to get the algorithm or just duplicate another FPGA( or ASIC) with the same
function? We are thinking about using Altera's product to protect our own
algoithms from being stolen. Please also let me know where I could get more
information about this.
>
> Thank you in advance.
> Yu Chen
>





Article: 26571
Subject: Re: "Number of logic levels" in xilinx PAR reports
From: Ray Andraka <ray@andraka.com>
Date: Fri, 20 Oct 2000 16:13:08 GMT
Links: << >>  << T >>  << A >>
TRCE counts the number of primitives the signal passes through between
registers.  So yes, each carry chain element counts as a logic level in this
context.

Steven Derrien wrote:
> 
> Hello,
> 
> I am looking for precisions regarding the "number of logic levels"
> figure provided in the PAR clock performance report.
> Specifically I was wondering what is exactly considered as a "logic
> level": is it the number of primitive(such as MUXCY, XORCY or LUT) in
> the path ? or is it the number of logic cells delay (considering that a
> logic cell is a LUT+its assocaited carry logic)?

-- 
-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  or http://www.fpga-guru.com

Article: 26572
Subject: Re: How safe is the algorithm implemented with FPGA?
From: nweaver@soda.CSUA.Berkeley.EDU (Nicholas Weaver)
Date: 20 Oct 2000 16:22:47 GMT
Links: << >>  << T >>  << A >>
In article <d_ZH5.2863$Z75.8018@nntpserver.swip.net>,
Ulf Samuelsson <ulf@atmel.spammenot.com> wrote:

> As people have pointed out, there is no 100% solution to protection.
> You can make it harder.  The FPSLIC AVR+FPGA will soon come out in a
> multichip package where the configurator is inside the package
> without visibility of the bitstream.  You can program the part and
> you can erase the part.  Not sure how verification works though!

>While it is not perfect, you cannot easily read the contents without
>opening up the package and even then you have to use advanced equipment.

	One observation: Opening up and probing a set of leads on a
multichip module should be easier than opening up and probing for a
set of eeprom bits or write once or laser programmed ROM bits within a
single chip.

	I'd personally wonder about the reason for the multichip
module format, it seems like pretty expensive and exotic packaging.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 26573
Subject: Re: UCF Question
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Fri, 20 Oct 2000 09:30:39 -0700
Links: << >>  << T >>  << A >>
yuryws@my-deja.com wrote:
> 
> Need to create UCF constraints to cover the following scenario:
> 
> 1. 16 bits are being clocked on the falling edge of CLK.
> 2. 16 bits are being clocked on the rising edge of CLK.
> 3. Data is valid 6 ns before and 6 ns after every CLK edge.
> 4. Shortest time between CLK edges is 25 ns.
> 5. Data and the clock come into Xilinx (Spartan XL) through input pads.
> 6. CLK is fed through a non-clock pad.
> 
> So, the circuit is:
> 
> CLK @ non-clock pad---IBUF---BUFGLS--->FF
> Data @ pad------------IBUF-------------FF

Put a period constraint of 25 ns on CLK.

Put an OFFSET constraint on the data pins.

-- a
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u

Article: 26574
Subject: Re: CoolRunner news :(
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Fri, 20 Oct 2000 09:36:35 -0700
Links: << >>  << T >>  << A >>
Tom Burgess wrote:
> 
> Discontinuation notice here:
> http://www.xilinx.com/partinfo/notify/pdn0007.htm
> 
> Looks like everything but the XPLA3 family goes.
> Last time buy April 27/01.

I like how the recommended replacement for the 22V10 is the 9536.  OK,
so the replacement chip has three times the amount of logic.

What if I don't need all of that logic?

I guess Lattice/Vantis still does 22V10s and 16V8s.

-- a
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u



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