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 22375

Article: 22375
Subject: Re: Why are there no "cheap" FPGAs?
From: z80@ds2.com (Peter)
Date: Sat, 06 May 2000 13:58:10 +0000
Links: << >>  << T >>  << A >>

>As of May 2000 you can buy an XC2S15 in quantity 1 through 24 for $ 7.10

How many would I have to buy to get it for $2?

The point is that there are lots of apps, e.g. in miniaturised
battery-powered products, where you want a full-CMOS device (not a
typical PLD) but which can do a lot more than a 22V10 (which you *can*
get in full-CMOS for $2) - for example something with 50 buried
D-types. One also needs a small package, e.g. a TSOP-28.

Not everybody wants do do a "256-deep, 16-wide FIFO with independent
read and write clocks running >100 MHz". And if somebody does, they
don't mind paying serious money for the device (just imagine the
likely application...) - and I accept that is the market Xilinx likes
to be in.


Peter.
--
Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but remove the X and the Y.
Please do NOT copy usenet posts to email - it is NOT necessary.

Article: 22376
Subject: Re: edif
From: Christian Mautner <at@utanet.cmautner>
Date: 06 May 2000 19:01:06 +0200
Links: << >>  << T >>  << A >>
Jon Elson <jmelson@artsci.wustl.edu> writes:

> Christian Mautner wrote:
> 
> > just installed FPGA express 3.4 today, and had to accept that now the
> > step from XNF to EDIF has been taken. So I guess I'll have to dump my
> > xnf-parsing perl scripts.
> 
> (Moan), this is not good news at all.  I don't care for the Aldec
> schematic
> editor, in a big way!  I have Protel, and they can output XNF, EDIF, VHDL
> and a host of other formats.  But, the only format that I have seen work
> is
> XNF.  The EDIF and VHDL files out of Protel are NOT acceptable to
> the Xilinx tools (and probably anyone else).  So, there's no way to make
> the new tools accept an XNF?  If not, is there an XNF to EDIF translator?
> (I guess that would be XNF2EDF.EXE or something like that.)

No, that's a misunderstanding. The Xilinx tools still accept XNF, but
FPGA Express cannot create it anymore. So, what I am looking for, is
actually an edif_to_xnf translator. But that's an idea, I'll check
whether the Xilinx tools contain such a tool.

chm.

-- 
cmautner@  -  Christian Mautner
utanet.at  -  Vienna/Austria/Europe
Article: 22377
Subject: Re: ANNOUNCE: Embedded Systems Glossary and Bibliography
From: Rennie Allen <rennieallen@earthlink.net>
Date: Sat, 06 May 2000 18:16:21 GMT
Links: << >>  << T >>  << A >>
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
Article: 22378
Subject: Re: How to Prevent theft of FPGA design
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sat, 06 May 2000 16:26:15 -0400
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> regarding the discovery of the LFSR:
> 
> Consider the structure of an LFSR:  it is a shift register, whose input is a modulo
> sum of selected taps.  The subsequent bits are just time shifted copies of the input
> bit.  Thus after N clocks you know exactly the current state of the LFSR assuming
> the output comes from the shift register input (if it comes from a different tap it
> is just time shifted, so your state might be time shifted...not a big deal).  If you
> know the structure of the LFSR, then you just back it up (on paper) to get the
> initial value (this works because you know the modulo sum and all but one of the
> inputs to that sum.  Since you also know the structure, it is just a matter of
> solving for the unknown bit.  Once that is found then you know the state at time
> N-1, and you repeat that until you get back to the initial state.
> 
> If you don't know the structure, then you run N clocks to get to a known state.
> From there each additional clock provides you with the sum from the known state.
> After N clocks you have N simultaneous equations from which it is easy to solve for
> the N coefficients (which are 0 or 1).  So that is how the LFSR is broken.
> 
> Encryption adds permutations and "S boxes" to further obfuscate the stream.  In DES,
> the S boxes are 6 input combinatorial functions that select 6 bits each and through
> a ROM replace one bit value.  There is an S box for each bit, so in addition to the
> LFSR, you get a data dependent permutation of the data stream.

I figured it would be this for the case of a LFSR with the structure you
describe (Fibonacci implementation). However there is an alternate form
where the taps are inputs to the stages rather than outputs (Galois
implementation). The output is feed back to the taps which are XORed
with the output of the preceding stage to drive the FF D input. I am
sure that this is also analyzable with a little more effort. I would
think that you would half to solve the state and the taps at the same
time with this configuration. 

I guess it just becomes a tradeoff between how much work it is for
someone to break and copy the protection scheme vs. the cost of
developing and implementing the protection scheme... just like
cryptography. But I am pretty sure that an affordable solution exists
that will protect designs short of state secrets. I expect that I will
be looking into this over the next few weeks. 

I guess one place to start is to see what is being done in the dongles.
I used to know how to break them back when they were simple counters or
memories. But now they seem to have gone to architectures like we are
discussing. Anyone know what algorithms they use?


-- 

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: 22379
Subject: Re: How to Prevent theft of FPGA design
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sat, 06 May 2000 18:05:41 -0400
Links: << >>  << T >>  << A >>
David Kessner wrote:
> 
> Rickman wrote:
> > Can you define, or better yet give an example of a "cryptographically
> > strong LFSR"? I do believe it when people have stated that if you know

> > So how do you design a LFSR that can not be easily analyzed?
> 
> I posted a message describing some better LFSRs, but in my news server
> mess (I switched ISP's, and had to use Deja between) I think it got
> lost...

Can you post that message again? I was not aware that among the maximal
length LFSRs there would be any difference in "strength". 

 
> The book "Applied Crypto, 2nd edition" by Bruce Schneier shows several
> PRBS generators based on LFSR's that are much better.  The book also
> nicely describes several that are not at all secure.
> 
> One type that is reasonably secure is called a "Bilateral Stop-and-Go
> Generator".  This generator uses two LFSRs of the same length.  The
> output is the XOR of each LFSR outputs.  If the output of LFSR #1
> at T-1 is 0 and the output at time T-2 is 1 then LFSR #2 does not
> clock at time T.  Conversely, if the output of LFSR #2 at time T-1
> is 0 and 1 at T-2 then LFSR #1 doesn't clock at time T.
> 
> This is just one example, the book describes several that would
> be suitable.


 
> Check out the Xilinx web site and search for JBits.  While I wouldn't
> call it easy to use, it does allow someone to analyze and FPGA and
> essentially extract a netlist that LUT contents.  After that, the rest
> is just an excersize for the reader...  :(

If this is true, what is the reason for keeping the configuration
bitstream format secret anymore? It originally was because of security
for customer's designs. Now it is said to be about support for what they
build and document. But if JBits brings that to light, will they have to
support it as well? Surely it is not all that simple to reverse engineer
the bitstream with JBITs?

 
> > If you have
> > to use Jbits to twiddle a bit then you load it into an FPGA and see what
> > you just changed, then I don't consider this to be an easy way to
> > reverse engineer a Xilinx configuration bitstream.
> 
> With Jbits you can do rather high level things in a very predictable
> way.  It isn't just flipping bits and seeing what happens.  You can
> reroute traces, change LUT's, etc. without having to resort to trial
> and error.
> 
> > Others have indicated that the LFSR is less robust and I feel that the
> > Xilinx design and the CPLD (or micro in my case) are more robust than my
> > requirements. So depending on just how hard it is to attack the LFSR
> > initial state, we may need a more robust algorithm.
> 
> But a more robust algorithm isn't going to help as long as we can
> reverse engineer CPLD's and Jbits exists.

Yes, if this is true, then there is nearly no hope for security unless
you just plain put a critical part of the design into a CPLD or microP. 

 
> The point is that the oscillators will tend to lock to other things
> happening in the FPGA.  The original posted suggested that a single
> inverting feedback oscillator be used in conjunction with a more stable
> crystal oscillator.  The crystal clock is ran to the clock input on a
> flip flop and the D input is fed from this inverting feedback clock.
> In the most simplistic sense, this oscillator will tend to lock to
> a harmonic of the crystal clock-- causing the flip flop to capture
> more 0's (or 1's) than the other.  This is hardly random and would
> reduce the effective "key size" (since we would know that 80% of the
> key bits are 0).

That is true to some extent. But this problem is not the same as
cracking a cypher. In this case having a bias for the random key would
not be a big deal. It is still random enough that it prevents attacks on
the key. Although we use the term random, it does not need to be
"random" in the mathematical sense. It only needs to be unpredictable
enough that it won't be the same very often. It could be the same number
every other time as long as you are not suseptable to the reset attack
where you would just reconfigure the device if it does not come up with
the same key. The point here is that it reduces the amount of data that
can be gleaned about the CPLD by not feeding the bitstream continously.
Then as long as it will not keep repeating a small subset of possible
keys, the attacker can not capture all of the used keys. So if you end
up only using 2^24 keys instead of 2^32 keys, it is not a problem. 

 
> How reproducible the results are is really something that only
> experimentation can provide.  It wouldn't surprise me at all if it
> was very repeatable given the same temp and voltage.  I'm fairly
> sure that if you let the board warm up then reset it 10 times in
> a row you would probably get at least 2 or 3 "random number matches".

Yes, this is true. I will be looking into this at a point in the future.
Another way to do it is to put the random number generator in the CPLD
and let a three way transaction take place. Random Number is sent to
FPGA, E(RN) is sent back to CPLD, E(E(RN) is returned to FPGA for
verification. If a microP is used in place of the CPLD, it may provide a
way to generate true random numbers via an ADC or other method. 
 
> > I would be willing to bet that a form of stimulus, response approach
> > would be the most resistant to attack.
> 
> Not as long as Jbits is around.  That alone would kill it.  This type
> of attack is independent of the algorithm used.  Just find the signal
> that disables some important internal state machine and force that
> signal inactive.  Since you can read the netlist from the FPGA this is
> a relatively simple thing to do.
> 
> Then there is the question of being able to "disable" the security
> bit in Flash CPLD's and uC's.  I think that this is difficult, but
> possible.

It may be possible, but again we are not trying to protect state
secrets. Personally, I feel that any method that requires you to take
the "lid" off of a chip is not likely to be used to reverse engineer a
design. Tapping a bitstream and using a computer program to decode a
LFSR or configuration bitstream is very much a viable, low dollar
attack. So if JBits can really be used to find and reverse engineer the
circuit in the FPGA, (or really just disable it!) then none of these
methods will work. 

 
> Given the above two attacks, a reasonably design LFSR is just as secure
> as a stimulus/response type of algorithm and a lot easier and smaller
> to implement.  I'm not saying that an LFSR approach is totally secure,
> just that it is no less secure than a stimulus/response method given
> these likely methods of attack.

Except that a constantly running LFSR can be reverse engineered very
easily, no need for JBits or any other software. This is likely true for
any circuit short of DES that runs full time spitting out its data. Even
cyphers are used according to how they want to protect them. The most
important cyphers are used for only the highest level messages so that
less data is available to attack. The same would be true here. 

I would like to hear from Peter Alfke about the capabilities of JBits.
Peter, is it true that JBits allows a design to be reverse engineered
and even modified relatively easily?


-- 

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: 22380
Subject: Re: [BitGen] - pb option UserClk
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sat, 06 May 2000 18:34:23 -0400
Links: << >>  << T >>  << A >>
Christian Mautner wrote:
> 
> Rickman <spamgoeshere4@yahoo.com> writes:
> 
> > I think what is being said is that you must have mistakenly selected the
> > USERCLK for the Startupclk in the GUI. There in normally not a strong
> > reason for changing the default from CCLK to USERCLK. If you do have a
> > reason for this change, then you need to provide a USERCLK to the
> > StartUp component in your design. Otherwise just change it back to CCLK!
> >
> 
> I'm using the USERCLK (being the system clock of the fully synchronous
> design) always at the startup clock. I believe that, if CCLK is used,
> timing constraints might be violated (since CCLK is asynchronous to
> the system clock) at startup. Is this more carful than necessary?
> 
> chm.

This is exactly the reason that you would want to use a USERCLK for
startup. But it may or may not be necessary depending on how your
circuit works. If you have a reset that is external to the FPGA, then
you can hold the entire circuit in reset when it is done configuring.
Then when the reset is released, the FPGA will start correctly. If you
don't have an external reset, using a USERCLK for startup would be a
good idea. But then you have to tell the design software that this is
what you are doing by adding the startup block to your design and
showing where the USERCLK is coming from. Just selecting the bit in the
configuration stream is not enough.


-- 

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: 22381
Subject: Re: Q: simplest FPGA structure for novel technology demonstration
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sat, 06 May 2000 18:54:51 -0400
Links: << >>  << T >>  << A >>
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
Andraka knows a lot about this. I believe he has some papers posted on
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
Article: 22382
Subject: Re: How to Prevent theft of FPGA design
From: Ray Andraka <ray@fpga-guru.com>
Date: Sun, 07 May 2000 01:01:49 GMT
Links: << >>  << T >>  << A >>
I believe if you work thru the boolean equations, you'll find the Fibonnaci and Galois
forms are mathematically equivalent - they can be made to generate the same sequence when
observed at a particular point on the shift register.  That means of course, you can use
the form most convenient for the analysis or the particular circuit design.  I'm not sure
off hand what happens to the analysis if you start modifying the feedback by XORing with
parallel input data, like you would do for a CRC.

Rickman wrote:

> I figured it would be this for the case of a LFSR with the structure you
> describe (Fibonacci implementation). However there is an alternate form
> where the taps are inputs to the stages rather than outputs (Galois
> implementation). The output is feed back to the taps which are XORed
> with the output of the preceding stage to drive the FF D input. I am
> sure that this is also analyzable with a little more effort. I would
> think that you would half to solve the state and the taps at the same
> time with this configuration.
> --
>
> 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

--
P.S.  Please note the new email address and website url

-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: 22383
Subject: Re: How to Prevent theft of FPGA design
From: David Bishop <dbishop@vhdl.org>
Date: Sun, 07 May 2000 02:49:15 GMT
Links: << >>  << T >>  << A >>


Hal Murray wrote:
> 
> > What the industry needs for FPGAs to take off is some sort of DES like
> > encription which can be OPTIONALLY used on the bit stream.
> 
> Do you have any data to verify that "take off" claim?  Do you really
> think the volume of parts shipped would double if they had a solid
> anti-theft story?

Not double, but it would have an impact.  I wound up doing several small
ASIC designs that should (by cost + EWO) be put into FPGAs.  They are
not
because FPGAs are just too easy to copy.  I've heard of several cases
over
the last few years (some on this group) where people have lost their
shirts to people who create knock offs of their boards.

People do ASICs mainly for high volume, or high performance.  FPGAs are
catching up fast in both of these areas.  Crypto is a very small thing
that an FGPA vendor could do that would give them an edge on their (and
our) competition.

> I'll toss in my two cents worth.  All of the FPGAs I've worked on
> didn't have any security issues.  They were used in complicated
> systems that were low volume.  (If you could make them significiantly
> cheaper we would buy them from you rather than build them ourselves.)

Where it may hit you is on an interface board.  I've seen several
designs
that were an FGPA, some memory, and some standard I/O interfaces and
nothing
else.  If you put a design like this design out there, and it does
something useful, (worth coping) be assured that there will be a knock
off of it appearing on the market quickly.  If it shows up on the Asian
market, you may not even find out about it until one of your customers
comes back to you with a problem.

-- 
NAME:     David W. Bishop           INTERNET: dbishop@vhdl.org  (  \  )
US MAIL:  Hilton NY 14468-9101      A Long time ago,             \__\/
PHYSICAL: 43:17:17N 77:47:37W 281'  In a Galaxy far, far away...  | |
For Supernova info:  http://www.ggw.org/asras/snimages            | |
For VHDL/Synthesis info:  http://www.vhdl.org/siwg              _/___\_
All standard disclaimers apply.                                [_______]

Article: 22384
Subject: Re: Virtex clock buffers
From: David Bishop <dbishop@vhdl.org>
Date: Sun, 07 May 2000 03:01:40 GMT
Links: << >>  << T >>  << A >>


Matt Gavin wrote:
> 
> FPGA gurus,
> 
> I am programming a Virtex XC400, after synthesizing
> with Synplify.  Synplify claims to be finding my three clocks
> requiring global buffers (two input clocks, one internal.)
> I am hardwiring the locations of the two input clocks to pins
> 89 and 92 (which of course are global buffer pins).
> 
> I am having problems putting a normal (non-clock) input
> on one of the global buffer input pins that I am not using
> for a global buffer (pin 213).   The error message from the mapper
> follows.
> 
>    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'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.

> 2. Also, is there a way for me to find out which of the four buffers
> are being used for the internal nets requiring clock buffers?
> I can't find it in the logs.

I found the problem by parsing the net list.  You can also use the
Synplicity RTL view window if you have that feature.

-- 
NAME:     David W. Bishop           INTERNET: dbishop@vhdl.org  (  \  )
US MAIL:  Hilton NY 14468-9101      A Long time ago,             \__\/
PHYSICAL: 43:17:17N 77:47:37W 281'  In a Galaxy far, far away...  | |
For Supernova info:  http://www.ggw.org/asras/snimages            | |
For VHDL/Synthesis info:  http://www.vhdl.org/siwg              _/___\_
All standard disclaimers apply.                                [_______]
Article: 22385
Subject: Re: How to Prevent theft of FPGA design
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sat, 06 May 2000 23:09:31 -0400
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> I believe if you work thru the boolean equations, you'll find the Fibonnaci and Galois
> forms are mathematically equivalent - they can be made to generate the same sequence when
> observed at a particular point on the shift register.  That means of course, you can use
> the form most convenient for the analysis or the particular circuit design.  I'm not sure
> off hand what happens to the analysis if you start modifying the feedback by XORing with
> parallel input data, like you would do for a CRC.

Actually, it did not occur to me that you really don't care about how
the machine is implemented, you only care about the sequence. The two
forms are exactly equivalent according to the reference I found. They
produce the same output sequence, although the initial state of the FFs
will be different for that sequence. But if you are doing a copy, you
really don't care if you are building one form with it's initial state
and the original was the other form with it's initial state. As long as
they both produce the same output vector, you are in business. 

So it does not matter how you analyze it, you just need to produce the
vector and 2N bits is enough data to reproduce a simple LFSR. 

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.

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. 

 
-- 

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: 22386
Subject: Re: Start Up Reset after config on Virtex design
From: murray@pa.dec.com (Hal Murray)
Date: 7 May 2000 04:24:53 GMT
Links: << >>  << T >>  << A >>

> What is the recommended way to start up the FPGA after configuration
> to a known state?  My flops are currently synchronous reset only, so I
> wasn't using GSR.  I thought maybe I could use the DONE line connected
> to an I/O?  Or is it just better to make all my flops asynchronous
> reset so I can use GSR?  BTW, my flops as sync reset because that is
> how they are implemented on the asic I am eventually going to target.

There was a lot of discussion on this topic a few months ago.  You
might find something interesting in deja-news.  I don't remember what
the Subject was.

I think the answer depends upon whether you are trying to target
for the ASIC and have plenty of room in your FPGA or if you are
working on a design that pushes the limits (both space or speed)
of the FPGA.

Here is what I remember from the previous discussion.

The Xilinx CLBs include a free asynchronous reset connected to GSR.
GSR is so slow that you can't use it cleanly - there is no way to
meet setup times.

If your design calls for a synchronous reset, that will turn into
extra logic.  As a first cut, it needs one of the CLB/LUT terms.  If
your design has them to spare it might not cost you much.  If your
design is heavily optomized it might add another layer of logic.  

I think consensus was that the best approach was to use GSR to
reset state machines and then make sure that the first transition
out of reset was clean.  That probably involves another FF local
to each state machine to delay the first state transition a few cycles.

-- 
These are my opinions, not necessarily my employers.
Article: 22387
Subject: Re: edif
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Sun, 07 May 2000 01:08:50 -0500
Links: << >>  << T >>  << A >>


Christian Mautner wrote:

> No, that's a misunderstanding. The Xilinx tools still accept XNF, but
> FPGA Express cannot create it anymore. So, what I am looking for, is
> actually an edif_to_xnf translator. But that's an idea, I'll check
> whether the Xilinx tools contain such a tool.

I just got Foundation Base Express, and am getting it figured out.  I
DID get it to take in a top-level schematic in XNF, but have had no luck
in bringing in 2nd level schematics, which were really my own macros called by
symbols on the main page.  It keeps complaining about those macro
definition XNF's, and I have tried a WHOLE lot of things with no
luck.  I'm just about to give up, and enter the whole thing over in Aldec,
entirely within foundation.

I'm pretty sure there is a way to do edif -> xnf, darn sure I came across
that somewhere.  Might be part of the Synopsys software, and not explicitly
part of express, but the .exe included for completeness.

Thanks for the info,

Jon

Article: 22388
Subject: Re: ANNOUNCE: Embedded Systems Glossary and Bibliography
From: OneStone <onestone@chariot.net.au>
Date: Sun, 07 May 2000 22:34:37 +0930
Links: << >>  << T >>  << A >>
I probably just move in much older circles than you, before the computer
world went insane with jargon. Mutual exclusion mechanism smacks of the
same sort of mentality that turned housewifes into domestic engineers,
and directory enquiries operators into information consultants. Since
pthreads are a POSIX multithreading standard I have never had cause to
read about them extensively or use them in any embedded systems. And a
review in Amazon showed that only the Butenhof book seemed to be really
popular, the numbers sold on this subject hardly makes the book
'popular'. Perhaps reasonably popular amongst POSIX programmers, but my
HC12, HC16, and even my MCORE systems aren't running POSIX, definitely
none of my 8 bitters do.

Al

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
Article: 22389
Subject: Re: edif
From: "Mark Harvey" <mark.harvey@iol.it>
Date: Sun, 07 May 2000 15:07:09 GMT
Links: << >>  << T >>  << A >>

Jon Elson <jmelson@artsci.wustl.edu> wrote in message
news:39132DDE.8A14AD1E@artsci.wustl.edu...

> (Moan), this is not good news at all.  I don't care for the Aldec
> schematic editor, in a big way!
>I have Protel, and they can output XNF, EDIF, VHDL
> and a host of other formats.  But, the only format that I have seen work
> is  XNF.  The EDIF and VHDL files out of Protel are NOT acceptable to
> the Xilinx tools (and probably anyone else).  So, there's no way to make
> the new tools accept an XNF?  If not, is there an XNF to EDIF translator?
> (I guess that would be XNF2EDF.EXE or something like that.)

I think the original statement about FPGA Express meant that it will only
output an edif file instead of xnf.
But the Xilinx P&R tools (Alliance) are completely independent of the
front-end design entry tools - they accept edif or xnf files
and will continue to do so (or at least that's what I've heard).

Mark Harvey.




Article: 22390
Subject: Re: [BitGen] - pb option UserClk
From: Christian Mautner <at@utanet.cmautner>
Date: 07 May 2000 20:48:05 +0200
Links: << >>  << T >>  << A >>
Rickman <spamgoeshere4@yahoo.com> writes:

> Christian Mautner wrote:
> > 
> > Rickman <spamgoeshere4@yahoo.com> writes:
> > 
> > > I think what is being said is that you must have mistakenly selected the
> > > USERCLK for the Startupclk in the GUI. There in normally not a strong
> > > reason for changing the default from CCLK to USERCLK. If you do have a
> > > reason for this change, then you need to provide a USERCLK to the
> > > StartUp component in your design. Otherwise just change it back to CCLK!
> > >
> > 
> > I'm using the USERCLK (being the system clock of the fully synchronous
> > design) always at the startup clock. I believe that, if CCLK is used,
> > timing constraints might be violated (since CCLK is asynchronous to
> > the system clock) at startup. Is this more carful than necessary?
> > 
> > chm.
> 
> This is exactly the reason that you would want to use a USERCLK for
> startup. But it may or may not be necessary depending on how your
> circuit works. If you have a reset that is external to the FPGA, then
> you can hold the entire circuit in reset when it is done configuring.
> Then when the reset is released, the FPGA will start correctly. If you
> don't have an external reset, using a USERCLK for startup would be a
> good idea. But then you have to tell the design software that this is
> what you are doing by adding the startup block to your design and
> showing where the USERCLK is coming from. Just selecting the bit in the
> configuration stream is not enough.
> 

Certainly. This is where this thread started, selecting the bit, but
not using the startup block. If USERCLK is selected, the startup clock
input should fed by the system clock, as I said.

Another point is: What timing can I expect from the GSR signal? I
mean, at a clock cycle period of t, how small may t be, so that all
flip flops are ready at the first clock edge after the GSR? And is
this covered by any timing constraints?

chm.

-- 
cmautner@  -  Christian Mautner
utanet.at  -  Vienna/Austria/Europe
Article: 22391
Subject: Re: Beginner's Guide
From: vsundaram@my-deja.com
Date: Mon, 08 May 2000 01:50:31 GMT
Links: << >>  << T >>  << A >>
In article <2063ed28.2d0ad971@usw-ex0102-
016.remarq.com>,
  erica <ericaNOerSPAM@remarq.com.invalid> wrote:
> I am taking a class in computer organinzation
and design.  We
> can use XLINX or Altera.  I chose to user
Altera MAX PLUS II.  I
> need a good web source on how to create
modules.  Can you help
> me please?
>
> Thanks,
>
> Erica
>
> * Sent from RemarQ http://www.remarq.com The
Internet's Discussion Network *
> The fastest and easiest way to search and
participate in Usenet - Free!
>
>


If you are a new user to MaxplusII then you
should use the getting started guide at
http://www.altera.com/html/literature/lsoft.html
and for examples you can refer to
http://www.altera.com/html/atlas/examples/examples
.html.

If you have problems using the software you can
also call Altera Technical Support line. It is
absolutely free and they are always willing to
help. 1-800-800-EPLD.

Vikram


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 22392
Subject: Re: [BitGen] - pb option UserClk
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sun, 07 May 2000 23:43:32 -0400
Links: << >>  << T >>  << A >>
Christian Mautner wrote:
> Another point is: What timing can I expect from the GSR signal? I
> mean, at a clock cycle period of t, how small may t be, so that all
> flip flops are ready at the first clock edge after the GSR? And is
> this covered by any timing constraints?
> 
> chm.

If there is a spec on the delay time for GSR, it will be in the data
book. But you will likely want to design your circuit so that it does
not matter. If you have some other signal holding the important logic in
the reset state, then the GSR will not matter. Typically you only need
to worry about a portion of the logic in such a circuit. For example in
a FSM, only the transition from the reset state needs to be held off by
the synchronous signal. Also any logic in the data path will be
controlled by the FSM and does not need the synchronous signal. 

You can look up the GSR delay time, but it will be slow compared to what
you will likely need to run. So find other ways to work around 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
Article: 22393
Subject: Re: ANNOUNCE: Embedded Systems Glossary and Bibliography
From: Jerry Avins <jya@ieee.org>
Date: Mon, 08 May 2000 03:36:56 -0400
Links: << >>  << T >>  << A >>
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
-- 
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
Article: 22394
Subject: Re: ANNOUNCE: Embedded Systems Glossary and Bibliography
From: Jon Kirwan <jkirwan@easystreet.com>
Date: Mon, 08 May 2000 01:50:00 -0700
Links: << >>  << T >>  << A >>
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.

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();
    // serialized access to data
    // ...
    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();
    // serialized access to data
    // ...
    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: 22395
Subject: Re: How to Prevent theft of FPGA design
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 08 May 2000 10:00:16 +0100
Links: << >>  << T >>  << A >>

Reverting to my idea of a stimulus/response approach we could modify from 1 shot as
I originally intended to a continuous stream of S/R pairs. Making the assumption
that we have a reasonably good RNG it might still be possible to use a simple LFSR
type structure if we let it evolve with time. i.e. the XOR structure for the
stimulus/response pair N is determined by the random number used in pair N-1.

It appears, on the face of it, that this would be much harder to analyse.

BTW: I've never looked at JBITS - what exactly does it do ?


Article: 22396
Subject: Re: Virtex clock buffers
From: Phil Endecott <phil_endecott@spamcop.net>
Date: Mon, 08 May 2000 09:06:49 +0000
Links: << >>  << T >>  << A >>
Hi Matt,

I'm using a different front-end flow (Exemplar) but have got the
same error from the Xilinx tools.  It seems to me that a signal
connected to a global clock pin must go through the associated
buffer; have a look at the sections on clock distribution and 
input/output blocks in the Virtex datasheet. As a result it is 
possible to run out of clock buffers for internally generated
clocks even though the total number of clocks in the system is
less than four.

The solution is to design the board (prototype board manufacturers
please take note!) so that oscillators are connected to a global
clock pin AND to a general-purpose input.

--Phil.


Matt Gavin wrote:
> 
> FPGA gurus,
> 
> I am programming a Virtex XC400, after synthesizing
> with Synplify.  Synplify claims to be finding my three clocks
> requiring global buffers (two input clocks, one internal.)
> I am hardwiring the locations of the two input clocks to pins
> 89 and 92 (which of course are global buffer pins).
> 
> I am having problems putting a normal (non-clock) input
> on one of the global buffer input pins that I am not using
> for a global buffer (pin 213).   The error message from the mapper
> follows.
> 
>    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.
> 
> 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.
> 2. Also, is there a way for me to find out which of the four buffers
> are being used for the internal nets requiring clock buffers?
> I can't find it in the logs.
> 
> Thanks,
> 
>   Matt
Article: 22397
Subject: Re: Virtex clock buffers
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 08 May 2000 10:26:39 +0100
Links: << >>  << T >>  << A >>


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.
>
> > 2. Also, is there a way for me to find out which of the four buffers
> > are being used for the internal nets requiring clock buffers?
> > I can't find it in the logs.
>
> I found the problem by parsing the net list.  You can also use the
> Synplicity RTL view window if you have that feature.
>
> --
> NAME:     David W. Bishop           INTERNET: dbishop@vhdl.org  (  \  )
> US MAIL:  Hilton NY 14468-9101      A Long time ago,             \__\/
> PHYSICAL: 43:17:17N 77:47:37W 281'  In a Galaxy far, far away...  | |
> For Supernova info:  http://www.ggw.org/asras/snimages            | |
> For VHDL/Synthesis info:  http://www.vhdl.org/siwg              _/___\_
> All standard disclaimers apply.                                [_______]

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. It does mean the design's not completely portable at the
HDL level but this stuff is self contained & so can be placed in a
per-technology include file. If you do instantiate anything you will need a
line something like this somewhere in your file [assuming you are using
Verilog]:

`include "??/synplify/lib/xilinx/virtex.v"

Anyway you are almost obliged to use this approach if you want to use the
Virtex DLLs since the only component the Synplify can synthesise is a
``BUFDLL'' which doesn't give any access to useful things like the RESET,
LOCKED, x2 etc. outputs.


Article: 22398
Subject: Re: ANNOUNCE: Embedded Systems Glossary and Bibliography
From: "Clay S. Turner" <csturner@peachnet.campuscwix.net>
Date: Mon, 08 May 2000 06:18:42 -0400
Links: << >>  << T >>  << A >>


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




> >
> > 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: 22399
Subject: Re: Code request
From: Alan Fitch <alan.fitch@doulos.com>
Date: Mon, 8 May 2000 11:22:54 +0100
Links: << >>  << T >>  << A >>
In article <0CF260C495FED111A6610000F866308D0E00DDBF@mail3.ntu.edu.sg>,
#YEO WEE KWONG# <P7102672H@ntu.edu.sg> writes
>Hi Evan,
>
>Thanks for your help. Below is my code for your examination. You are
>right to say that it is slightly diff. at the initial state. Thereafter,
>it should be the same after the 1st clock. I tested the code with
>Synopsys DC and FPGA express. Both give me the same warning for code
>(1). Are you suggesting that I should revert to code (2) style to pass
>the synthesis test. If that is the case, why there is a couple of
>textbook still used code (1) as a synthesizable reference code which is
>quite misleading!
>I am one of the victim which I hope not.


The "problem" is not with your code, but with Synopsys. Both styles are
acceptable, and both will produce the result you expect. Synopsys is
simply *warning* you that a signal is being read that is in not in the
sensitivity list. However, it will produce the correct results.

In this case, Synopsys is being a bit paranoid. If you look at the text
of the message for HDL-400, you'll see that it says that this "could
cause a mismatch between synthesis and simulation" - the important word
is "could"!

Synplify and Leonardo Spectrum will not give you this warning.

regards
Alan

P.S. I tried your example below in both styles and got the correct
results using FPGA Express. 
>
>Look forward to your reply.
>
>architecture arcCounter of ntyCounter is
>  type typCounterState is (s0, s1, s2, s3);
>  signal sNextState : typCounterState;
>  signal sCurrState : typCounterState;
>
>begin  -- arcCounter
>
>  
>  lblUpdState: process(pClk)       --> code (2) style
>--   lblUpdState: process             --> code (1) style
>  begin
>    
>--    wait until rising_edge(pClk); --> code (1) style
>    if rising_edge(pClk) then          --> code (2) style
>      if pRst_b = '0' then
>        sCurrState <= s0;
>      else
>        sCurrState <= sNextState;
>      end if;
>    end if;                                      --> code (2) style
>    
>  end process lblUpdState;
>
>end arcCounter;

-- 
Alan Fitch
DOULOS Ltd. 
        Church Hatch, 22 Market Place, Ringwood, BH24 1AW, Hampshire, UK
Tel: +44 (0)1425 471 223                    Email: alan.fitch@doulos.com
Fax: +44 (0)1425 471 573             
**               Visit THE WINNING EDGE  www.doulos.com               **



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