1994 Jul Aug Sep Oct Nov Dec 1994 1995 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1995 1996 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1996 1997 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1997 1998 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1998 1999 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1999 2000 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2000 2001 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2001 2002 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2002 2003 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2003 2004 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2004 2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2005 2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2006 2007 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2007 2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2008 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2009 2010 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2010 2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2011 2012 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2012 2013 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2013 2014 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 2015 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2015 2016 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2016 2017 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2017 2018 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2018 2019 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2019 2020 Jan Feb Mar Apr May 2020

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 22400

Article: 22400
Subject: Re: How to Prevent theft of FPGA design
From: David Kessner <davidk@free-ip.com>
Date: Mon, 08 May 2000 08:39:10 -0600
Links: << >>  << T >>  << A >>
Rickman wrote:
> This sounds like a good excuse for me to read a few books on
> cryptography. I have been waiting for an excuse to do this for a long
> time.

Rick,  Definitely check out the book Applied Crypto by Bruce
Schneier (he can also be found at http://www.counterpane.com).
In the book there is a fairly large section on LFSR's and their
use in Cryptography.

> I know that DES is not a simple algorithm to implement in hardware. But
> by doing things in a bit serial manner and using CLB RAMs as much as
> possible, do you have any idea how small it can be made? Even if only 1
> K bits per second can be produced, this would be enough to use in an
> application like this.

Check out my web page at http://www.free-ip.com and go to the cores
section.  You'll find the VHDL source to a DES core.  In short, DES
isn't small and doesn't lend itself well to a bit serial
implementation.  It certainly won't fit into a CPLD.

There are two types of encryption:  block and stream cyphers.  DES
is a block cypher because it takes a 64 bit block and encrypts it
all in one shot.  A stream cypher is, well, for a bit stream.  The
simplest stream cypher would be an XOR between the data stream and
the output of an LFSR-- of course there are good and bad LFSR's to
use for encryption...

David Kessner
davidk@free-ip.com


Article: 22401
Subject: Re: Virtex clock buffers
From: Matt Gavin <mtgavin@collins.rockwell.com>
Date: Mon, 08 May 2000 10:09:47 -0500
Links: << >>  << T >>  << A >>
Guys,

I looked and Synplify seems to be giving me a garden-variety IBUF (not an
IBUFG)
for my input which I want to tie to a pin supporting global buffers (pin 213).
So I don't think using "syn_noclockbuf" in Synplify will accomplish
anything - I don't really have a clock buffer there, just a plain IBUF.

Should I really have trouble using a garden-variety IBUF on
a pin supporting global clocks?  Do I need to make it a BUFGP somehow
(like my typical input clocks are)?

By the way, I am not using DLLs in any way.

Matt

Rick Filipkiewicz wrote:

> David Bishop wrote:
>
> > I'm pretty sure that I've hit this one before with Synplicity.  Put
> > a "syn_noclockbuf" attribute on the pins that you are tying to IBUFGs
> > in your design and it should work.
> >
> > In Synplicity, if you put a clock buffer on a pin, it will happily
> > place another one right after it.  I've filed this one as a bug.
> >
> > > 1.  Shouldn't I be able to use global buffer pins for inputs
> > > that do NOT require the global buffer?  Recall that synplify
> > > is instantiating the buffers for me.
> >
> > Yup, but it looks to me like the router is trying to use one of the
> > IBUFGs as a BUFG, then is sees a pin already connected to it, and gets
> > confused.  It doesn't take much to blow the mind of Design Mangler 2.1i.
> >
> [snip]
>
> Yeah, its this sort of problem that has lead me to the decision to
> instantiate all the global clock buffering stuff rather than let the synth
> tool generate it.

[snip]


Article: 22402
Subject: Re: ANNOUNCE: Embedded Systems Glossary and Bibliography
From: OneStone <onestone@chariot.net.au>
Date: Tue, 09 May 2000 01:10:00 +0930
Links: << >>  << T >>  << A >>
Jon Kirwan wrote:
>
> On Mon, 08 May 2000 03:36:56 -0400, Jerry Avins <jya@ieee.org> wrote:
>
> >I'm hardly a CS expert, but I know a few and I'll check with them. I've
> >been dealing with semaphores (though I mostly call them flags) for
> >years, but I heard of "mutex" for the first time in this thread. This
> >post in particular disabuses me of the notion that the name is akin to
> >"mutate". It sounds like pointless (probably academic) jargon to me. Am
> >I benighted?
>
> A semaphore maintains a count between zero and some specified maximum
> value.  The state of a semaphore is set to signaled when its count is
> greater than zero, and nonsignaled when its count is zero.  Used in
> producer/consumer problems, for example.  I suppose you are already
> familiar with that.
>
> A mutex is a semaphore whose state is set to signaled (unlocked) when
> it is not owned by any thread, and nonsignaled (locked) when it is
> owned.  A mutex is a semaphore set to 1, when created.  It's a special
> purpose semaphore designed to control access to a critical region of
> code and data.  If one or more threads are waiting on a mutex, exactly
> one is released when the mutex is unlocked by the holder.
>

A flag in plain English then if the 'mutex' is binary?

> It's the usage that decides which it is, I believe, and not the
> details of the underlying implementation in the O/S.  So from the
> point of view of an operating system author, you might implement them
> the same way.  But they are put to different purposes.
>
> You can usually recognize a mutex when you see something like this:
>
>     myobject.down();
>     // ...
>     myobject.up();
>
> Operations on a mutex travel in pairs, like nuns.  This the above
> example, myobject is a mutex.
>
> But if you see something like:
>
>     myobject01.down();
>     myobject.down();
>     // ...
>     myobject.up();
>     myobject02.up();
>
> chances are that myobject01 and myobject02 are common semaphores.
>
> Maybe that's just academic, as you suggest, but that is still my sense
> of the terms.
>
> Jon

Article: 22403
Subject: Re: ANNOUNCE: Embedded Systems Glossary and Bibliography
From: OneStone <onestone@chariot.net.au>
Date: Tue, 09 May 2000 01:11:59 +0930
Links: << >>  << T >>  << A >>
"Clay S. Turner" wrote:
>
> Jerry Avins wrote:
> >
> > Rennie Allen wrote:
> > >
> > > OneStone wrote:
> > > >
> > > > 1. You list Binary Semaphore and the even less known term mutex yet omit
> > > > the simplest term which is a flag or flag bit.
> > >
> > > Mutex is an "even less known term" than binary semaphore ?  You must
> > > move in very different circles than I.  The pthreads standard (for which
> > > there are at least three popular book titles) mentions little else in
> > > the way of mutual exclusion mechanisms, besides mutexes; besides, what
> > > could be a better name for a mutual exclusion mechanism than mutex ?
>
> Hello Jerry,
>         If you do multithreaded programming in windows, you will probably use
> "mutexes."  They been a part of windows for quite some time.  The
> computer word that gaulls me the most is "dereferencing"  This is about
> as bad as flammable and inflammable.  As George Carlin says "either it
> flamms or it doesn't!"
>
> Clay

So in this case it either mute's or it speaks?

Al

P.S. can't get a version of windows for my micros thankfully.

>
> > >
> > > Rennie
> >
> > I'm hardly a CS expert, but I know a few and I'll check with them. I've
> > been dealing with semaphores (though I mostly call them flags) for
> > years, but I heard of "mutex" for the first time in this thread. This
> > post in particular disabuses me of the notion that the name is akin to
> > "mutate". It sounds like pointless (probably academic) jargon to me. Am
> > I benighted?
> >
> > Jerry
> > --
> > Engineering is the art of making what you want from things you can get.
> > -----------------------------------------------------------------------

Article: 22404
Subject: Programming FPGA
From: "J. Boss" <jboss@wxs.nl>
Date: Mon, 8 May 2000 18:40:26 +0200
Links: << >>  << T >>  << A >>
Hi,

I've just made a very easy design, which I want to implement in a Xilinx
SpartanXL FPGA using a processor-bus. I'm using the Foundation Series F2.1i.
The design is schematic-based. The implementation-file has been succesfully
created (bit-file). When I upload the program to the FPGA, everything works
fine (INIT remains low during programming and DONE becomes high after all
bits have been send and after this at least four CCLK-cycles follow!). Also
all timing-specs of programming the FPGA are applied. But when I measuring
some output pins, I just don't see what I would expect. For example: I've
used a clock-divider which divides the busclock (33 MHz) with 2048. Then I
send this signal (16 kHz)  to an output-pin. But when measuring this pin, I
just see a low signal (not any clock-signal)! What options should I be awear
off before implementing my design? Or could there be another problem? Has
anyone a bit-file (which consists of a very simple schematic) which I can
try to program in the Xilinx XCS30XL-4-PQ208? Maybe my software is invalid.
I'm using a 3-months version. You cannot use the constraints manager in this
version. Maybe I can't use some more properties of this software (without
knowing it!)? It's the first time I'm working with an FPGA and programming
it through a processor-bus. So could anyone give me any hints?

Jurjen Boss (trainee)


Article: 22405
Subject: Re: ANNOUNCE: Embedded Systems Glossary and Bibliography
From: Jerry Avins <jya@ieee.org>
Date: Mon, 08 May 2000 13:06:24 -0400
Links: << >>  << T >>  << A >>
Jon and Clay,

Thank you for the patient explanation. I regret having flown off the
handle; I hope that impatience with new things isn't a sign of old age!
After all, "mutex" is no worse a coinage than "modem". Part of my
impatience stems from my history of "just doing it", rather than
following a formal paradigm. Much of my work has been done without any
operating system at all (or with a simple ASOS* I wrote myself). I have
written multitasking programs that way where the distribution of
If it has a name, I'm unaware of it. It took me less time to design and
implement it than it would have taken me to search the literature.

Nevertheless, formalism has a valuable place. Perhaps I would profit
more from it if I gave it more respect.

Jerry
________________________
* Application-specific Operating System. I can coin words too!
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
Jon Kirwan wrote:
>
...
>
> A semaphore maintains a count between zero and some specified maximum
> value.  The state of a semaphore is set to signaled when its count is
> greater than zero, and nonsignaled when its count is zero.  Used in
> producer/consumer problems, for example.  I suppose you are already
> familiar with that.
>
> A mutex is a semaphore whose state  ...
>
> Jon

"Clay S. Turner" wrote:
>
...
>
> Hello Jerry,
>     If you do multithreaded programming in windows, you will probably use
> "mutexes."  They been a part of windows for quite some time.  The
> computer word that gaulls me the most is "dereferencing"  This is about
> as bad as flammable and inflammable.  As George Carlin says "either it
> flamms or it doesn't!"
>
> Clay

Article: 22406
Subject: Re: Virtex clock buffers
From: Phil Endecott <phil_endecott@spamcop.net>
Date: Mon, 08 May 2000 17:08:27 +0000
Links: << >>  << T >>  << A >>
Matt Gavin wrote:

> Should I really have trouble using a garden-variety IBUF on
> a pin supporting global clocks?

Yes you will have trouble doing this, as I understand it this
is not permitted by the hardware.

--Phil.

Article: 22407
Subject: Re: INIT pin on Virtex FPGAs
From: Tom McLaughlin <tomm@arl.wustl.edu>
Date: Mon, 08 May 2000 13:05:25 -0500
Links: << >>  << T >>  << A >>
All,
We are programming multiple FPGAs with the same configuration on
mulitple boards through a backplane.  Because of many reasons, we are
not going to tie all the INIT pins back to the PROMs,  but just one.  We
are going to delay the INIT signal to the PROM to ensure that all of the
FPGAs are ready to program.  The problem is we don't know how long to
delay it.

So, if you had 1000 FPGAs (All Virtex E) and they all went through Vcc
threshold at the same time, what would be the time delta between the
first FPGA INIT signal going high and the last.  We really only need the
order.  Right now we have a delay of 100ms built in which we believe is
way more than enough....any thoughts.

Yes, I know this is unconventional, but so are most things we do around
here.

Tom


Article: 22408
Subject: Re: INIT pin on Virtex FPGAs
From: Rickman <spamgoeshere4@yahoo.com>
Date: Mon, 08 May 2000 14:42:16 -0400
Links: << >>  << T >>  << A >>
Tom McLaughlin wrote:
>
> All,
> We are programming multiple FPGAs with the same configuration on
> mulitple boards through a backplane.  Because of many reasons, we are
> not going to tie all the INIT pins back to the PROMs,  but just one.  We
> are going to delay the INIT signal to the PROM to ensure that all of the
> FPGAs are ready to program.  The problem is we don't know how long to
> delay it.
>
> So, if you had 1000 FPGAs (All Virtex E) and they all went through Vcc
> threshold at the same time, what would be the time delta between the
> first FPGA INIT signal going high and the last.  We really only need the
> order.  Right now we have a delay of 100ms built in which we believe is
> way more than enough....any thoughts.
>
> Yes, I know this is unconventional, but so are most things we do around
> here.
>
> Tom

I looked in the virtex E datasheet and found on page 18 the timing spec
Tpl listed as 100 uSec. The diagram shows this as the time from PRGM-
going high to INIT- going high. So if you are willing to use a common
PRGM- signal, then this number is defined.

Otherwise I would guess that because you have not heard from anyone that
this information is not provided (or possibly even measured) on Xilinx
parts. My guess is that you would need to measure it yourself on a group
of chips from different manufacturing lots. Then take the longest number
you get and double it.

I also would not count on the 100 mSec number unless you tested it as
above. If you don't want to do the testing from multiple manufacturing
lots, then as a part of system test, you might include multiple startup
delay values. The test procedure would be to test with the shortest
startup delay, doubling the startup delay each time the test fails. Once
the startup is successful, you could double the startup delay once more
to provide some safty margin.

But even these approaches are risky. Although the chips in general get
faster as the process is improved, if you are counting on an unspec'ed
parameter, it might get changed because of a "bug" fix. For example, if
they found a problem with the power up circuit, the fix might add some
significant time to the startup delay. Then even if you had set the
startup delay in system test, the unit might not be maintainable in the
field. The tech changes a bad chip and now the system won't boot!

To be safe, I would tie the PRGM- signals together and use that as a
reset.

--

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.

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: 22409
Subject: Re: Q: simplest FPGA structure for novel technology demonstration
From: Paul Bunyk <paul@pbunyk.physics.sunysb.edu>
Date: 08 May 2000 15:44:17 -0400
Links: << >>  << T >>  << A >>


Tom Burgess <tom.burgess@home.com> writes:

> While I appreciate that you are thrilled about the possibilities of RSFQ technology,
> I think that your initial request was unfortunately phrased, leading people to
> waste their valuable time supplying simple structure ideas...

Oh, sorry... My wording was probably misleading indeed, thugh I tried
to emphasize that what I needed was an idea for a PROGRAMMABLE
structure as in F_P_GA. Sorry again if I was not clear enough...

> O.K., so you REALLY need
> to use a couple thousand femtosecond gates in an interesting way, not really having
> anything to do with FPGAS. Given the high on/off chip speed ratio, prime number
> factorization or maybe high speed "ILOVEYOU" pattern matching might do,

Unfortunate time to ask questions via e-mail, huh? :)

> though to
> really wow the suits you will have to boot Apple II Basic and run VisiCalc :)

Yes, the simplest 16-bit processor with on-chip memory is what we promised
to do now, memory would not be large enough to stor VisiCalc though!
:) Maybe in the next version... I was thinking of a back-up plan for a demo.

>
> regards, tom

Paul

>
> Paul Bunyk wrote:
> >
> > Hello everyone! Thank you all for your replies!
> >
> > You all basically suggest the simplest experiments ann of which have
> > already been done. What I needed is an idea for "something" which requires
> > couple thousand gates (sponsor's limitation on the simplicity of the demo).
> >

--
("-''-/").___..--''"-._   UNIX *is* user-friendly, he is just very
6_ 6  )   -.  (     ).-.__.) picky about who his friends are...
(_Y_.)'  ._   )  ._ . -..-'      Paul Bunyk, Research Scientist
_..--'_..-_/  /--'_.' ,'art by           (and part-time UN*X sysadm)
(il),-''  (li),'  ((!.-' F. Lee http://pbunyk.physics.sunysb.edu/~paul

Article: 22410
Subject: Re: Q: simplest FPGA structure for novel technology demonstration
From: Paul Bunyk <paul@pbunyk.physics.sunysb.edu>
Date: 08 May 2000 15:50:02 -0400
Links: << >>  << T >>  << A >>

Thank you, Rick! This was kind of information I was lookig for.

Sincerely,

Paul

Rickman <spamgoeshere4@yahoo.com> writes:

> Paul Bunyk wrote:
> >
> > Hello everyone! Thank you all for your replies!
> >
> > You all basically suggest the simplest experiments ann of which have
> > already been done. What I needed is an idea for "something" which requires
> > couple thousand gates (sponsor's limitation on the simplicity of the demo).
>
> > By the way, another group here (well, two more people :) ) is
> > designing like 16-bit oversampling ADC chips with digital filters (run
> > now at about 15 GHz internal frequency) and DACs (including a real
> > cool device - voltage amplifier with exactly INTEGER gain - it's a
> > quantum technology, many weird things are possible). But for
> > prolitical reasons our demo should not resemble "just" a digital
> > filter, it should be programmable...
> >
> > Any further suggestions? :)
>
> If you are interesed in FPGAs with simple structures, then you might
> want to look at the Atmel 6000 family. The repeated logic element is a
> single FF with three gates and a tristate buffer. Of course there are
> muxes used to select the paths and SRAM to control the muxes. But this
> is a rather simple logic block compared to the other vendors. You might
> even get them to work with you and provide bitstream info so that you
> can use their software. This structure is very useful for systolic
> processing since it uses direct connects between cell neighbors.
>
> Or based on the signal processing devices being built by others in your
> company, you might want to build an NCO and/or a Digital Down Converter.
> If your circuits really run at multiple GHz speeds, then you could do
> the accumulators and filters in bit serial fashion to keep the circuit
> size down to 1 or 2 K gates. You might even be able to generate the sine
> and cosine as a calculation using the CORDIC (sp?) algorithm. Ray
> his web site about it.
>
>
> --
>
> Rick Collins
>
> rick.collins@XYarius.com
>
> remove the XY to email me.
>
>
>
> 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

--
("-''-/").___..--''"-._   UNIX *is* user-friendly, he is just very
6_ 6  )   -.  (     ).-.__.) picky about who his friends are...
(_Y_.)'  ._   )  ._ . -..-'      Paul Bunyk, Research Scientist
_..--'_..-_/  /--'_.' ,'art by           (and part-time UN*X sysadm)
(il),-''  (li),'  ((!.-' F. Lee http://pbunyk.physics.sunysb.edu/~paul

Article: 22411
Subject: Non-BGA High Pin Count FPGA/CPLD
Date: 8 May 2000 20:06:05 GMT
Links: << >>  << T >>  << A >>
Hallo,

are there any high pin count ( around 220 usable IO pins) FPGA/CPLD
available in Non-BGA package?

Thanks for pointers.

Bye

--

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 22412
Subject: How do I lock down Macro Routing
From: "Nick" <nikberto@ncsc.mil>
Date: Mon, 8 May 2000 16:39:18 -0400
Links: << >>  << T >>  << A >>
I'm using the Xilinx Alliance 2.1i_sp6 FPGA Editor software to build a
design Macro.

When can I lock down the routing of my Macro?

Do I lock it when I'm creating the macro (*.nmc) or do I lock it when I
instantiate into a design (*.ncd).

I'm finding that the timing of the macro instance in the design doesn't
match the timing of the original macro. I thought that locking down routing
would produce the same timing results. I'm using the exact same part when
creating the macro and the design.

--
Nick


Article: 22413
Subject: Re: Non-BGA High Pin Count FPGA/CPLD
From: Greg Neff <gregneff@my-deja.com>
Date: Mon, 08 May 2000 21:34:32 GMT
Links: << >>  << T >>  << A >>
In article <8f76nd$rp4$1@sun27.hrz.tu-darmstadt.de>,
> Hallo,
>
> are there any high pin count ( around 220 usable IO pins) FPGA/CPLD
> available in Non-BGA package?
>
> Thanks for pointers.
>
> Bye
>
> --
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
>

It looks like some Xilinx XC4000E and XC4000XL devices are available in
304pin QFPs, with 256 I/Os.  Check with Xilinx for real availability.

--
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com

Sent via Deja.com http://www.deja.com/

Article: 22414
Subject: Re: Programming FPGA
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Mon, 8 May 2000 15:35:14 -0700
Links: << >>  << T >>  << A >>
J. Boss wrote in message <8f6qnq$6uhd5$1@reader1.wxs.nl>...
>Hi,
>
>I've just made a very easy design, which I want to implement in a Xilinx
>SpartanXL FPGA using a processor-bus. I'm using the Foundation Series
F2.1i.
>The design is schematic-based. The implementation-file has been succesfully
>created (bit-file). When I upload the program to the FPGA, everything works
>fine (INIT remains low during programming and DONE becomes high after all
>bits have been send and after this at least four CCLK-cycles follow!). Also
>all timing-specs of programming the FPGA are applied. But when I measuring
>some output pins, I just don't see what I would expect. For example: I've
>used a clock-divider which divides the busclock (33 MHz) with 2048. Then I
>send this signal (16 kHz)  to an output-pin. But when measuring this pin, I
>just see a low signal (not any clock-signal)! What options should I be
awear
>off before implementing my design? Or could there be another problem? Has
>anyone a bit-file (which consists of a very simple schematic) which I can
>try to program in the Xilinx XCS30XL-4-PQ208? Maybe my software is invalid.
>I'm using a 3-months version. You cannot use the constraints manager in
this
>version. Maybe I can't use some more properties of this software (without
>knowing it!)? It's the first time I'm working with an FPGA and programming
>it through a processor-bus. So could anyone give me any hints?

Did you do a functional simulation on your design, to ensure that your logic
works as you expect?

-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"A sufficiently advanced technology is indistinguishable from magic"
--Arthur C. Clarke


Article: 22415
Subject: Re: Programming FPGA
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Mon, 08 May 2000 17:39:08 -0500
Links: << >>  << T >>  << A >>


"J. Boss" wrote:

> Hi,
>
> I've just made a very easy design, which I want to implement in a Xilinx
> SpartanXL FPGA using a processor-bus. I'm using the Foundation Series F2.1i.
> The design is schematic-based. The implementation-file has been succesfully
> created (bit-file). When I upload the program to the FPGA, everything works
> fine (INIT remains low during programming and DONE becomes high after all
> bits have been send and after this at least four CCLK-cycles follow!). Also
> all timing-specs of programming the FPGA are applied. But when I measuring
> some output pins, I just don't see what I would expect.

Well, I have a bit of experience with the XC9500 parts, but I'm just moving
into the FPGA world, too.  I did see some knowledge base articles on the
correct settings for the clock source selection for programming to function
passed the checksum, so it sounds like the programming was correctly
loaded into the device.  Is there some simply combinatorial signal you can
check?  My guess is that the internal clock is set up wrong, and is not
taking the clock from the source you intend it to.

Jon


Article: 22416
Subject: Re: Virtex clock buffers
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Mon, 08 May 2000 17:42:12 -0500
Links: << >>  << T >>  << A >>


Matt Gavin wrote:

>
>    Running directed packing...
>    ERROR:xvkpu:19 - The symbol XTAL1200K.PAD failed to join a regular
> I/O
>       component as required.  The symbol has a constraint (LOC=P213)
> that specifies
>       an illegal physical site for the component.  Please correct the
> constraint
>       value.
>    Problem encountered during the packing phase.

I think you should look closely at the data book for the part.  I think
you are
correct that global clock buffers can be used for user signals, but the
XTAL pads are not the same as a normal global clock buffer, they are
used to compose a crystal oscillator.

Jon


Article: 22417
Subject: Re: How to Prevent theft of FPGA design
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 09 May 2000 10:42:13 +1200
Links: << >>  << T >>  << A >>
Catalin Baetoniu wrote:
>
> Hi Jim,
>
> The context discussed here is that of an open core protection scheme for FPGAs. Something
> that it is posted on a www page for all to see (including the potential copier) but is
> still very hard to break if you do not know the key. While your approach is valid for a do
> it your self protection good for your own use (if you really trust it) it is not good for
> what we are discussing here. If I will use your system I want to be sure it works and you
> will have to make it public. All your hidden tricks lose their advantage then. The system
> must be strong by design not by hiding information. It doesn't have to be triple DES or
> PGP but it must be hard enough, at least as hard as reverse engineering the FPGA
> bitstream.

I agree, a public source/private table(key) system is preferred.

>
> I would like to propose the following system:
>
> A 48-bit LFSR with the position of the taps public is loaded at reset with a secret
> initial value. The 48-bit state is broken into 6 groups of 4 bits which pass trough six
> look-up tables. The content of the look-up tables is also secret and is fixed (your key is
> then 144 bits). The six look-up table outputs are xored together and are the only signal
> output by the CPLD. There is no input except for the clock and the reset. The output of
> the CPLD is both long enough to be captured, stored and played back in a copy of the
> system and hopefully complex enough to defy analysis. Everything should fit in a 72
> macrocell CPLD and in less than 10 FPGA CLBs.

This is actually very similar to what I had in mind - a combination of
shifter and PROM/Tables
( a lot of our IP has this type of code, and I have often thought it
woud be a dog to
reverse engineer )

The only difference is whether you allow external, or self 'seed' of the
shifter.
I guess a public source version of this could allow users either option,
or maybe
more a seed select, than a seed load ( too open ).

So, if we accept that this raises the bar sufficently on CPLD and
handshake attack, that
leaves just bitstream attack on the FPGA.

There are potential weaknesses here :-

a) If just one copy exists in FPGA, correlation of PROM to bitstream
location starts to
look simpler. A Hacker can get 100's of your bitstreams quite easily,
plus generate their
own reference ones.
b) I am sure a std HDL compile ( common source code ) will tend to place
cells in
a similar bitstream order, again aiding hacking.

For a) the design could 'fill' the spare space in the FPGA with
multiple copies of
this engine - now, many bits are changing.
For b) the FPGA vendors would need to add a scramble place/route
option, so that within a
block, the CLBs change order, from compile to compile.

>
> If anybody wants to try to break this I can set up a challenge test.

Send me an email, and we can discuss this further.

- jg


Article: 22418
Subject: Re: ANNOUNCE: Embedded Systems Glossary and Bibliography
From: Jon Kirwan <jkirwan@easystreet.com>
Date: Mon, 08 May 2000 16:53:54 -0700
Links: << >>  << T >>  << A >>
On Tue, 09 May 2000 01:10:00 +0930, OneStone <onestone@chariot.net.au>
wrote:

>A flag in plain English then if the 'mutex' is binary?

A mutex is often just called a "binary semaphore" in my experience.
Since you always perform a "down" on it before entering the critical
region and always release it by performing an "up," afterwards, it's
value is 0 or 1.  It never goes above 1, so it's just "binary."  But
like any semaphore, the "test and set" must be atomic, even in
multi-processor systems.

I suppose that the term mutex might be applied to any specific
implementation that guarantees "mutual exclusion," even message-based.
But most of the use I've heard put to the term relates to this
obvious, special purpose use of semaphores.

So flag works for me, so long as the "flag" can be set and tested
atomically and the purpose is understood.

Jon

Article: 22419
Subject: Re: INIT pin on Virtex FPGAs
From: fliptron@netcom.com (Philip Freidin)
Date: 9 May 2000 00:30:37 GMT
Links: << >>  << T >>  << A >>

Acording to the Xilinx data sheet,

Table 12 - "Power-up Timing Characteristics"

The time to INIT going high is the later of 2mS from Power-on Reset
occuring (VCC passing through some threshold), and 100uS from the Program
signal going high. This is the time it takes for the internal config
memory clearing to complete. If one trusted the data sheet, this value of
2mS for Tpor and 100uS for Tpl would be allowing for the slowest internal
CCLK (which is 2.5MHz +45%, -30%, see table 10), and the largest Virtex
device, since the clearing operation is done 1 frame per clock, using the
internal CCLK (not well described in the Virtex data sheets, but the way
it has been done in all previous Xilinx products ).

So your 100mS seems conservative, and could probably be safely reduced to
10mS without problems.

Good luck Tom,

Philip

In article <39107C12.E5926AA8@arl.wustl.edu>,
Tom McLaughlin  <tomm@arl.wustl.edu> wrote:
>All,
>We are programming multiple FPGAs with the same configuration on
>mulitple boards through a backplane.  Because of many reasons, we are
>not going to tie all the INIT pins back to the PROMs,  but just one.  We
>are going to delay the INIT signal to the PROM to ensure that all of the
>FPGAs are ready to program.  The problem is we don't know how long to
>delay it.
>
>So, if you had 1000 FPGAs (All Virtex E) and they all went through Vcc
>threshold at the same time, what would be the time delta between the
>first FPGA INIT signal going high and the last.  We really only need the
>order.  Right now we have a delay of 100ms built in which we believe is
>way more than enough....any thoughts.
>
>Yes, I know this is unconventional, but so are most things we do around
>here.
>
>Tom
>
>
>


Article: 22420
Subject: Re: ANNOUNCE: Embedded Systems Glossary and Bibliography
From: Eric Weaver <weav@sigma.net>
Date: Mon, 08 May 2000 18:00:44 -0700
Links: << >>  << T >>  << A >>
Jerry Avins wrote:
>
> I'm hardly a CS expert, but I know a few and I'll check with them. I've
> been dealing with semaphores (though I mostly call them flags) for
> years, but I heard of "mutex" for the first time in this thread.

It's a contraction for "Mutual Exclusion Semaphore".  Just a kind of
lock to prevent re-entrancy in some critical section.

--
Eric C. Weaver     weav@sigma.net
"Radio, that bar so low on the musical ladder you need a sump pump
to keep your hairpiece dry"   - Brancaccio

Article: 22421
Subject: Re: ANNOUNCE: Embedded Systems Glossary and Bibliography
From: Jerry Avins <jya@ieee.org>
Date: Mon, 08 May 2000 22:30:04 -0400
Links: << >>  << T >>  << A >>
Result of check: I asked a CS friend (he has a masters degree and is
active in the profession) if he knew or could guess what a mutex is. He
had a vague memory that it is a species of mosquito.

Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
Jerry Avins wrote:
>
> Rennie Allen wrote:
> >
> > OneStone wrote:
> > >
> > > 1. You list Binary Semaphore and the even less known term mutex yet omit
> > > the simplest term which is a flag or flag bit.
> >
> > Mutex is an "even less known term" than binary semaphore ?  You must
> > move in very different circles than I.  The pthreads standard (for which
> > there are at least three popular book titles) mentions little else in
> > the way of mutual exclusion mechanisms, besides mutexes; besides, what
> > could be a better name for a mutual exclusion mechanism than mutex ?
> >
> > Rennie
>
> I'm hardly a CS expert, but I know a few and I'll check with them. I've
> been dealing with semaphores (though I mostly call them flags) for
> years, but I heard of "mutex" for the first time in this thread. This
> post in particular disabuses me of the notion that the name is akin to
> "mutate". It sounds like pointless (probably academic) jargon to me. Am
> I benighted?
>
> Jerry

Article: 22422
Subject: Xilinx Block Select Ram+ and LeonardoSpectrum
From: "Andy Krumel" <andy@krumel.com>
Date: Mon, 8 May 2000 21:31:02 -0700
Links: << >>  << T >>  << A >>
The Xilinx Spartan II and Vertex datasheets claims (and Mentor documentation
backs it up) that:
"Currently, LeonardoSpectrum does not infer dual port RAMs that read both

A dual port RAM has independent clocks and addresses which support
simultaneous read from the same/different locations and simultaneous

The possible interpretations seem to be:
1) LS does not infer dual port RAMs.
2) LS infers dual port RAMs but only one read is allowed at a time, ie
either port A or port B.
3) #2 except restriction in place only when writing data.

My best guess is #2.

Thanks,
Andy


Article: 22423
Subject: Re: ANNOUNCE: Embedded Systems Glossary and Bibliography
Date: Mon, 8 May 2000 23:30:52 -0700
Links: << >>  << T >>  << A >>
"Jerry Avins" <jya@ieee.org> wrote in message
news:3917782C.97DB1182@ieee.org...
> Result of check: I asked a CS friend (he has a masters degree and is
> active in the profession) if he knew or could guess what a mutex is. He
> had a vague memory that it is a species of mosquito.

But is he active in multi-threaded programming under Windows NT or perhaps
VMS?  We've got plenty of people with their CS degrees at work, and only a
small fraction of them could tell you what a mutex (or semaphore) is.

Rumor has it that David uh... Cutler?, formerly of Digital/father of
VMS/hired by Microsquish to architect Windows NT, calls the things "mutants"
in NT because he didn't like the way they were implemented.


Article: 22424
Subject: Re: Programming FPGA
From: "Maurice" <m.balk@hetnet.nl>
Date: Tue, 9 May 2000 08:52:26 +0200
Links: << >>  << T >>  << A >>
Did you do a functional simulation on your design, to ensure that your logic
works as you expect?
To ANDY: Yes, I did do a functional simulation and everything works fine!

Well, I have a bit of experience with the XC9500 parts, but I'm just moving
into the FPGA world, too.  I did see some knowledge base articles on the
correct settings for the clock source selection for programming to function
passed the checksum, so it sounds like the programming was correctly
loaded into the device.  Is there some simply combinatorial signal you can
check?  My guess is that the internal clock is set up wrong, and is not
taking the clock from the source you intend it to.
To JON: That's also where I'm thinking of. But I've used the GCK-pin (P2 of
the Xilinx XCS30XL) for the clock-signal and designed a IPAD, followed by a
BUFG. The signal is divided by using a LogiBLOX-symbol. the output is then
send to a OBUF, followed by an OPAD. For both PAD's have used the
LOC-attribute in which I specify the pinlocation (e.g. the clock-pin = P2
and the output-pin is P160). I've also used the STARTUP-symbol, to which you
can connect the clock-signal, this also doesn't work.



 1994 Jul Aug Sep Oct Nov Dec 1994 1995 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1995 1996 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1996 1997 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1997 1998 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1998 1999 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1999 2000 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2000 2001 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2001 2002 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2002 2003 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2003 2004 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2004 2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2005 2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2006 2007 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2007 2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2008 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2009 2010 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2010 2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2011 2012 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2012 2013 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2013 2014 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 2015 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2015 2016 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2016 2017 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2017 2018 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2018 2019 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2019 2020 Jan Feb Mar Apr May 2020

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