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 28425

Article: 28425
Subject: Re: Spartan-II DLL Usage
From: murray@pa.dec.com (Hal Murray)
Date: 12 Jan 2001 02:29:57 GMT
Links: << >>  << T >>  << A >>

[My initial msg.]

> > [Context is wanting to run a DLL at 24 MHz when the min spec is 25.]
> >
> > > Now,  I am assuming you are not going below 0C, so there will be some
> > > margin there.  But if not, then definitely don't do it.
> >
> > In general, CMOS prop time is linear in temp and supply voltage.  He's
> > only off by 4% so we should be able to draw the forbidden zone on a graph
> > with voltage on one axis and temp on the other.
> >
> > Does that sort of reasoning work with DLLs?
> >


In article <3A561466.534B42DB@xilinx.com>,
 Austin Lesea <austin.lesea@xilinx.com> writes:
> Hal,
> 
> Yes.
> 
> I just can't say "go ahead" for all of the reasons I stated.  Someday, some
> lot might be just a little too fast (even though it is pretty unlikely).

That's exactly the point I was trying to make.  Why can't you say "go ahead"?
Is there a flaw in my reasoning or is that due to legal issues?

In most interesting projects, a designer has to use a lot of information
that isn't in the data sheet.  What's the "contract" between the vendor
and the designer?  How can I be sure that a design will work correctly
if I use information from app notes or general common sense or rumors
from usenet?

Note that there are two types of extra information.  One is things like
how to get the tools to do what you want or explainations of what a
particular line on the data sheet really means.

The other type of information is extra - things you won't find in the
data sheet at all.  The obvious example is speed being linear with
temperature and VCC.

In this context, I guess that some of the tools are part of the contract,
next to the data sheet.  I'm thinking of the timing verifier or report
generator and the power estimator.


The particular case that I proposed is tricky because it depends upon
minimum prop times and the general party line is things might go faster.

But in this particular case, there is a requirement for that min in the
spec sheet.  The spec sheet says it will work down to 25 MHz.

Most people know it's "legal" to reduce the prop times in a data sheet
if you can keep a part cool and/or keep the VCC above min.  My proposal
uses the same approach, just with the reverse sign bit.  If it will
work at 25 MHz at max VCC, will it run at 24 MHz if I keep VCC at least
5% below max?




-- 
These are my opinions, not necessarily my employers.  I hate spam.

Article: 28426
Subject: Re: address of ram using the clk net
From: Peter Alfke <palfke@earthlink.net>
Date: Fri, 12 Jan 2001 04:48:16 GMT
Links: << >>  << T >>  << A >>
Well, the delay becomes longer and less precise. So the "clock" signal is
delayed. Whether that matters depends on your total timing.

Peter A

erika_uk@my-deja.com wrote:

> thanks peter,
> i was just thinking if there is any negative points from routing the
> clk net through the non dedicated routing ressources
>
> In article <3A5DE811.C46239FF@xilinx.com>,
>   peter.alfke@xilinx.com wrote:
> >
> > --------------674E81B0FE10E2CB432BC052
> > Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-
> mac-creator="4D4F5353"
> > Content-Transfer-Encoding: 7bit
> >
> > erika_uk@my-deja.com wrote:
> >
> > > hi all,
> > >
> > > Is there any harm from using the clock net to drive some ram
> address. (
> > > one address wire for example toggle between 1 and zero),
> > >
> >
> > No, no harm. The address input doesn't know anything about the source
> of
> > its signal. If you wiggle very fast, the power consumption may go up.
> But
> > no real problem. What makes you even think so?
> >
> > Peter Alfke
> >
> > --------------674E81B0FE10E2CB432BC052
> > Content-Type: text/html; charset=us-ascii
> > Content-Transfer-Encoding: 7bit
> >
> > <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> > <html>
> > &nbsp;
> > <p>erika_uk@my-deja.com wrote:
> > <blockquote TYPE=CITE>hi all,
> > <p>Is there any harm from using the clock net to drive some ram
> address.
> > (
> > <br>one address wire for example toggle between 1 and zero),
> > <br><a href="http://www.deja.com/"></a>&nbsp;</blockquote>
> > No, no harm. The address input doesn't know anything about the source
> of
> > its signal. If you wiggle very fast, the power consumption may go up.
> But
> > no real problem. What makes you even think so?
> > <p>Peter Alfke
> > <br>&nbsp;</html>
> >
> > --------------674E81B0FE10E2CB432BC052--
> >
> >
>
> Sent via Deja.com
> http://www.deja.com/


Article: 28427
Subject: Re: Alliance for Linux
From: bjrosen <bjrosen@polybus.com>
Date: Fri, 12 Jan 2001 05:12:31 GMT
Links: << >>  << T >>  << A >>
In article <Xns902683BA6shivawellcom@207.126.101.100>,
  shiva@well.com (Kenneth Porter) wrote:
> bjrosen <bjrosen@polybus.com> wrote in <93jj36$c4a$1@nnrp1.deja.com>:
>
> >Windows systems suffer from DLL hell, there is no
> >equivalent on Linux. When you install a new program on Linux you
never
> >have to worry that it will stomp on some other program. On Windows
you
> >have a 50/50 chance of mangling your system every time you install
> >something.
>
> Why does Windows suffer from DLL hell, but Linux doesn't? Both use
shared
> libraries. When Windows apps install DLL's into the system directory,
isn't
> it usually to deal with a prior shortcoming in Windows? Might we not
see
> apps trying to do the same thing in Linux, installing their own
updates to
> system libraries, like libc, gtk, or kde? (Experienced developers and
> admins won't allow this, but what about inexperienced developers
coupled
> with ignorant users?)
>

The Redhat Package Manager makes sure that this doesn't happen on Linux.
When you do an install it checks all of the dependencies and tells you
what applications you are going to break. On Windows every installer
assumes that it's free to replace anything it wants. Also on Linux you
can use different libraries for every app if you want, thats what the
LD_LIBRARY_PATH env variable is for.


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

Article: 28428
Subject: Re: grey code counters
From: Kent Orthner <korthner@hotmail.nospam.com>
Date: 12 Jan 2001 15:17:07 +0900
Links: << >>  << T >>  << A >>
Bill Lenihan <lenihan3weNOSPAM@earthlink.net> writes:
> I know how to make binary up/down counters and LFSR-based counters in
> verilog, but does anyone know of an algorithmic/equation-based way to
> make grey-code counters?
> 
> The only examples I've seen are from old PAL application notes, and they
> are for 4-bit grey counters that are described as 16-state state
> machines, which is ok if you are keeping the counter at 4-bits, but
> impractical if you are going to much wider bit widths.

When I wanted the same thing, a generic grey code counter, without 
having to do it manually for each bit-width, I did the following:

Created an bin2grey function, and a grey2bin function, each of 
which converted a unsigned or slv of any width from grey to bin 
or vice-versa.

When I went to implement it, I wrote:

next_grey_counter <= bin2grey( grey2bin( grey_counter ) +1 );

and let my synthesizer loose on ity to see what it came up with.

I'm sure this isn't the highest performance way of doing it, 
but for moderate speeds, it *is* easy.

Synthesized with Foundation Express v3.3, each counter has Reset, Clk,
Enable, and Count output, counting up only.

Counter  4-input   FFs     CYs
Width    LUTs

4        4         4
5	 8	   5
6        9         6
7        11        7
20       38        20      19

I place and routed all of these counters in a Spartan-II 150-5, 
not adjusting any synthesis or place-and-route options, and came 
up with a frequency of 160MHz for the 7-bit counter.

Anyone who's intereseted in the code (VHDL only.) is welcome to it,
just let me know.

-Kent




Article: 28429
Subject: Re: Alliance for Linux
From: Thomas Reinemann <thomas.reinemann@mb.uni-magdeburg.de>
Date: Fri, 12 Jan 2001 08:49:22 +0100
Links: << >>  << T >>  << A >>


Kenneth Porter wrote:
> 
> bjrosen <bjrosen@polybus.com> wrote in <93jj36$c4a$1@nnrp1.deja.com>:
> 
> >Windows systems suffer from DLL hell, there is no
> >equivalent on Linux. 
> 
> Why does Windows suffer from DLL hell, but Linux doesn't? Both use shared
> libraries. 

Yes, but usually in Linux/Unix contain file names the version of a
shared lib. Therefore you can have different versions of the same lib
installed. You can solve problems concerning different programs which
need different versions of the same library with an appropriate symbolic
link.

Furthermore, one can use the ldd-command for checking whether the needed
libraries are available.


-- 
Dipl.-Ing. Thomas Reinemann
IMAT
Otto-von-Guericke-Universität Magdeburg
Universitätsplatz 2
39106 Magdeburg
Germany

Article: 28430
Subject: APEX20K multi-device configuration
From: Meta Fernando <Fernando.Meta@tei.ericsson.se>
Date: Fri, 12 Jan 2001 11:46:43 +0100
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------1543F5974182AF4E64D9DA8B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have to configure 3 APEX20K1500 by a Flash memory controller.
I chosen a PPA scheme for the configuration (Doc. : Altera AN116)
My questions is:

After first device's configuration...
- Do I have to move again the signals nCONFIG, nCS and CS for the second
and  the third  device?


Thanks in advance!

--------------1543F5974182AF4E64D9DA8B
Content-Type: text/x-vcard; charset=us-ascii;
 name="Fernando.Meta.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Meta Fernando
Content-Disposition: attachment;
 filename="Fernando.Meta.vcf"

begin:vcard 
n:Meta;Fernando
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:Fernando.Meta@tei.ericsson.se
note:Hardware Designer
x-mozilla-cpt:;-7088
fn:Fernando Meta
end:vcard

--------------1543F5974182AF4E64D9DA8B--


Article: 28431
Subject: Re: Altera free software
From: "Martin.J Thompson" <Martin.J.Thompson@trw.com>
Date: Fri, 12 Jan 2001 03:05:37 -0800
Links: << >>  << T >>  << A >>
Hi Luigi,

>
>Hi,
>Does anyone know what devices are supported by the
>free Altera development software?
>It is not clear on the Altera web pages,
>and I would know it before download a lot of
>MBytes. I'm specially interested in FLEX 8000
>family. Thanks!
>

Try a quick browse at...
http://www.altera.com/html/tools/emax_baseline.html 

Cheers,
Martin



-- Martin Thompson BEng(Hons) MIEE
TRW Automotive Advanced Product Development,         
Stratford Road, Solihull, B90 4GW. UK
Tel: +44 (0)121-627-3569 
mailto:martin.j.thompson@trw.com




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

Article: 28432
Subject: SRAM fpga cell
From: "Simon Fielder" <please_reply@to.newsgroup.thanks>
Date: Fri, 12 Jan 2001 03:50:52 -0800
Links: << >>  << T >>  << A >>
Thankyou for any help.

Please could someone point me to the relevant information on the folowing subjects.

1) What does the basic FPGA SRAM cell or element look like?  A description of how it is constructed (to the component level - transistors, resistors etc.) and a diagram of a single cell (does it look like a six transistor SRAM memory cell or does it differ?) would be very useful.

2) Has any failure analysis been carried out on the SRAM elements themselves and if so where can I get the results please?  Has anyone any useful information on failures of the SRAM cells?

3) What is the effectiveness of the engineering and stability of programming configuration.  For example if an SRAM FPGA is left powered but unused for a period of time, say a few weeks, at the end of this period would the SRAM element, and hence the FPGA itself, still be exactly as it was when originally programmed?

Thankyou.

Article: 28433
Subject: Re: CRC - from long division to XOR, how?
From: eml@riverside-machines.com.NOSPAM
Date: Fri, 12 Jan 2001 12:01:03 GMT
Links: << >>  << T >>  << A >>
On Thu, 11 Jan 2001 14:28:13 -0500, "Jamie Sanderson"
<jamie@nortelnetworks.com> wrote:

>I think I have a good understanding of CRCs, and I can work out examples on
>paper or follow the various software examples given. Where I'm stuck is in
>understanding how to go from the definition of the CRC to the requisite XOR
>statements, as seen in code generated by Jan's CRC tool. I would greatly
>appreciate a pointer to this information. While I could just use the code I
>have, I'd much rather understand how it was made.

What you want (I think) is info on how to do a parallel factorisation.
The best reference I've seen is an old AMD app note for TAXI devices,
which unfortunately I've lost (if you can find it online I'd
appreciate a link). Jack Ganssle also wrote an article in 1991 on how
to do it, which he's got at http://www.ganssle.com/articles/acrc.htm.
I went through this in detail a few years ago and decided that it has
problems with CRC inversion and bit ordering, but it's a good start if
you can't find the AMD ref.

Evan

Article: 28434
Subject: Re: grey code counters
From: seamus <woodyj@my-deja.com>
Date: Fri, 12 Jan 2001 13:47:08 GMT
Links: << >>  << T >>  << A >>
In article <3A5C2AE9.52717DAD@earthlink.net>,
  lenihan3weNOSPAM@earthlink.net wrote:
> I know how to make binary up/down counters and LFSR-based counters in
> verilog, but does anyone know of an algorithmic/equation-based way to
> make grey-code counters?

Here is a VHDL package to use gray-code structures in a high-level
manner.  Below that is a sample program that uses the package.

 - WJ

------------------------------------------------------------------------
------
library ieee;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;

package gray_pkg is
   type gray is array (natural range <>) of std_logic;
   function TO_GRAY (arg: unsigned) return gray;
   function TO_GRAY (arg, size: natural) return gray;
   function TO_UNSIGNED (arg: gray) return unsigned;
   function TO_INTEGER (arg: gray) return natural;
   function "+" (l: gray; r: natural)  return gray;
   function "-" (l: gray; r: natural)  return gray;
   function "=" (l: gray; r: natural)  return boolean;
end gray_pkg;

package body gray_pkg is
   function TO_GRAY (arg: unsigned)  return gray is
   begin
      return gray(arg xor '0' & arg(arg'LEFT downto arg'RIGHT+1));
   end; -- TO_GRAY

   function TO_GRAY (arg, size: natural)  return gray is
   begin
      return TO_GRAY(TO_UNSIGNED(arg, size));
   end; -- TO_GRAY

   function TO_UNSIGNED (arg: gray) return unsigned is
       variable vect: unsigned(arg'RANGE);
   begin
      vect := unsigned(arg);
      for i in vect'LEFT-1 downto VECT'RIGHT loop
         vect(i) := vect(i+1) xor vect(i);
      end loop;
      return vect;
   end; -- TO_UNSIGNED

   function TO_INTEGER (arg: gray) return natural is
   begin
      return TO_INTEGER(TO_UNSIGNED(arg));
   end; -- TO_INTEGER

   function "+" (l: gray; r: natural)  return gray is
      variable vect : unsigned(l'RANGE);
      variable num : natural;
   begin
      return TO_GRAY(TO_UNSIGNED(l) + r);
   end; -- "+"

   function "-" (l: gray; r: natural)  return gray is
   begin
      return TO_GRAY(TO_UNSIGNED(l) - r);
   end; -- "-"

   function "=" (l: gray; r: natural)  return boolean is
   begin
      return r = TO_UNSIGNED(l);
   end; -- "="
end gray_pkg;


------------------------------------------------------------------------
------
library ieee;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
use WORK.gray_pkg.all;

entity gray_tst is
   port (
      Rst         : in std_logic;      -- High active reset.
      Clk         : in std_logic;      -- Clock.
      Ena         : in std_logic;      -- Active-high syncronous count
enable.
      Cnt         : out std_logic_vector(9 downto 0));-- Gray code
count.
end gray_tst;

architecture rtl of gray_tst is
   signal cnt_q         : gray(9 downto 0);  -- Counter register bits.

begin  --rtl
------------------------------------------------------------------------
------
--  cnt_reg - gray counter that counts from 700 to 779
------------------------------------------------------------------------
------
   cnt_reg : process (Clk, Rst)
   begin --  cnt_reg
      if (Rst = '1') then
         cnt_q <= TO_GRAY(700, cnt_q'LENGTH);
      elsif (Clk'event and Clk = '1') then
         if ( Ena = '1' ) then
            if ( cnt_q = 779 ) then
               cnt_q <= TO_GRAY(0, cnt_q'LENGTH);
            else
               cnt_q <= cnt_q + 1;
            end if;
         end if;
      end if;
   end process cnt_reg;

   Cnt <= std_logic_vector(TO_UNSIGNED(cnt_q));
end rtl;


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

Article: 28435
Subject: Re: Alliance for Linux
From: Jamie Lokier <spamfilter.jan2001@tantalophile.demon.co.uk>
Date: 12 Jan 2001 15:12:16 +0100
Links: << >>  << T >>  << A >>
Andy Peters writes:
> ModelSim and Synplify both use dongles (which I vastly prefer over
> that FlexLM bogosity) but the Mac ain't got a parallel port so I'm SOL
> there.

And even if the MAC did have a parallel port...

I vastly prefer FlexLM because there is some hope of it working in an
emulator.  In my experience dongle reading code does seriously weird
things to your parallel port, and doesn't work in an emulator.

-- Jamie

Article: 28436
Subject: Re: CRC - from long division to XOR, how?
From: "Jamie Sanderson" <jamie@nortelnetworks.com>
Date: Fri, 12 Jan 2001 09:48:07 -0500
Links: << >>  << T >>  << A >>
I guess what I thought was a clear question really wasn't, since I've had a
number of responses which didn't address the issue. (not that I don't
appreciate the effort)

I think it would be illuminating if I posted an example of Jan's code. To
keep it short, I used the polynomial from E1, which is a CRC-4 with a
generating polynomial of x^4 + x + 1, calculated over a byte.

Looking at the code below, you'll find that it contains a set of four XOR
statements which compute successive values of the CRC. What I don't
understand is how these statements were generated. Clearly there is an
algorithm for doing this since Jan's tool obviously makes use of one. I'd
like to know what that is (assuming it's not proprietary).

Regards,
Jamie

///////////////////////////////////////////////////////////////////////
// File:  CRC4_D8.v
// Date:  Fri Jan 12 15:42:09 2001
//
// Copyright (C) 1999 Easics NV.
// This source file may be used and distributed without restriction
// provided that this copyright statement is not removed from the file
// and that any derivative work contains the original copyright notice
// and the associated disclaimer.
//
// THIS SOURCE FILE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS
// OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
// WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
//
// Purpose: Verilog module containing a synthesizable CRC function
//   * polynomial: (0 1 4)
//   * data width: 8
//
// Info: jand@easics.be (Jan Decaluwe)
//       http://www.easics.com
///////////////////////////////////////////////////////////////////////


module CRC4_D8;

  // polynomial: (0 1 4)
  // data width: 8
  // convention: the first serial data bit is D[7]
  function [3:0] nextCRC4_D8;

    input [7:0] Data;
    input [3:0] CRC;

    reg [7:0] D;
    reg [3:0] C;
    reg [3:0] NewCRC;

  begin

    D = Data;
    C = CRC;

    NewCRC[0] = D[6] ^ D[4] ^ D[3] ^ D[0] ^ C[0] ^ C[2];
    NewCRC[1] = D[7] ^ D[6] ^ D[5] ^ D[3] ^ D[1] ^ D[0] ^ C[1] ^ C[2] ^
                C[3];
    NewCRC[2] = D[7] ^ D[6] ^ D[4] ^ D[2] ^ D[1] ^ C[0] ^ C[2] ^ C[3];
    NewCRC[3] = D[7] ^ D[5] ^ D[3] ^ D[2] ^ C[1] ^ C[3];

    nextCRC4_D8 = NewCRC;

  end

  endfunction

endmodule


"x-guy" <x-guy@hotmall.com> wrote in message
news:3A5E4DCC.695200B6@hotmall.com...
> Don't understand what your question is. Are you talking about how to code
in
> HDL or how to find those polynomial?
>
> Jamie Sanderson wrote:
>
> > Greetings;
> >
> > I need to implement a small CRC function in an FPGA design I'm currently
> > working on. I've scoured the net for information, and have read (and
> > re-read) various articles:
> >
> > http://www.netrino.com/Connecting/2000-01/index.html by Michael Barr
> > ftp://ftp.rocksoft.com/clients/rocksoft/papers/crc_v3.txt by Ross
Williams
> >
> > I've also generated the code I need using Jan Decaluwe's CRC tool
> > (http://www.easics.com/webtools/crctool).
> >
> > I think I have a good understanding of CRCs, and I can work out examples
on
> > paper or follow the various software examples given. Where I'm stuck is
in
> > understanding how to go from the definition of the CRC to the requisite
XOR
> > statements, as seen in code generated by Jan's CRC tool. I would greatly
> > appreciate a pointer to this information. While I could just use the
code I
> > have, I'd much rather understand how it was made.
> >
> > Thanks,
> > Jamie
>



Article: 28437
Subject: Re: APEX
From: "Le Mer Michel" <michel.lemer@sta.fr>
Date: Fri, 12 Jan 2001 16:03:46 +0100
Links: << >>  << T >>  << A >>
Hi
The exact message is :
# ** Warning: */APEX20k_ASYNCH_MEM SETUP High VIOLATION ON WADDR(1) WITH
RESPECT TO WE;
#   Expected := 2.06 ns; Observed := 1.41 ns; At : 49989.401 ns
#    Time: 49989401 ps  Iteration: 4  Instance:
/test/i1/i1_ai3_ai2_ai1_alpm_ram_dp_component_asram_asegment_a0_a_a4_a/apexm
em
# ** Warning: */APEX20k_ASYNCH_MEM SETUP  Low VIOLATION ON WADDR(0) WITH
RESPECT TO WE;
#   Expected := 2.06 ns; Observed := 1.41 ns; At : 49989.401 ns
#    Time: 49989401 ps  Iteration: 4  Instance:
/test/i1/i1_ai3_ai2_ai1_alpm_ram_dp_component_asram_asegment_a0_a_a4_a/apexm
em
....

Michel Le Mer.

S.K. Sharma <sanjay.kumar.sharma@philips.com> a écrit dans le message :
93hoat$r9c$1@porthos.nl.uu.net...
> Hi Michel,
> Could you post the exact error message!
> Thanks
> Sanjay
>
> --
> Sanjay Kumar Sharma
> ASIC Design Engineer
> Philips Semiconductors
> Eindhoven, The Netherlands
> "Le Mer Michel" <michel.lemer@sta.fr> wrote in message
> news:93c9gj$kk4$1@s1.read.news.oleane.net...
> > Hello
> >
> > I have a strange message about APEX20K_ timing violation during
simulation
> > despite I use the APEX 20KE family and that all the frequencies are met
> > according to Quartus.
> >
> > Any suggestions?
> >
> > Thanks
> > --
> > Michel Le Mer     immeuble Cerium
> > STA                    12, square du Chene Germain
> > 02 23 20 04 72   35510 Cesson-Sevigne
> >
> >
>
>
>



Article: 28438
Subject: Stereo vision on Virtex
From: "Sven Fleck" <fleck@informatik.uni-tuebingen.de>
Date: Fri, 12 Jan 2001 16:33:11 +0100
Links: << >>  << T >>  << A >>
Hi there,

can anybody give me good references for stereo vision algorithms which are
best suited for the parallel execution nature of FPGAs to better solve the
correspondence problem using a correlation based approach? I know about the
CMU group using DSPs and so on, but FPGA designs are rather hard to find,
but should in my eyes be far superior in performance.
(small overview is included in Kurt Konolige's "Extra-Pair-Of-Eyes"
DSP-design)

I would like to use a Xilinx Virtex-1000 board running @ 100MHz for this
task.

Thanks in advance!

Sincerely,

Sven Fleck


----------------------------------
Sven Fleck
University of Tuebingen
Germany






Article: 28439
Subject: Re: Spartan-II DLL Usage
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 12 Jan 2001 08:40:24 -0800
Links: << >>  << T >>  << A >>

--------------B8C7AD462CF21207EA77122C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hal,

I will comment below.

Austin

Hal Murray wrote:

> [My initial msg.]
>
> > > [Context is wanting to run a DLL at 24 MHz when the min spec is 25.]
> > >
> > > > Now,  I am assuming you are not going below 0C, so there will be some
> > > > margin there.  But if not, then definitely don't do it.
> > >
> > > In general, CMOS prop time is linear in temp and supply voltage.  He's
> > > only off by 4% so we should be able to draw the forbidden zone on a graph
> > > with voltage on one axis and temp on the other.
> > >
> > > Does that sort of reasoning work with DLLs?
> > >
>
> In article <3A561466.534B42DB@xilinx.com>,
>  Austin Lesea <austin.lesea@xilinx.com> writes:
> > Hal,
> >
> > Yes.
> >
> > I just can't say "go ahead" for all of the reasons I stated.  Someday, some
> > lot might be just a little too fast (even though it is pretty unlikely).
>
> That's exactly the point I was trying to make.  Why can't you say "go ahead"?
> Is there a flaw in my reasoning or is that due to legal issues?

There is an implicit contract here.  We state in the specifications that the
product will do X.  If it doesn't do X, you get it replaced with one that does.

>
>
> In most interesting projects, a designer has to use a lot of information
> that isn't in the data sheet.  What's the "contract" between the vendor
> and the designer?  How can I be sure that a design will work correctly
> if I use information from app notes or general common sense or rumors
> from usenet?

Spec sheet = contract.  App note = we will support it just like the spec sheet.
A email from a Xilinx engineer is a written document, so it also must be treated
as a statement of 'suitablity for use' ... ie we would have to supply chips that
do what was said.  Thus, my caution.  Anything else, well, have fun.

>
>
> Note that there are two types of extra information.  One is things like
> how to get the tools to do what you want or explainations of what a
> particular line on the data sheet really means.
>
> The other type of information is extra - things you won't find in the
> data sheet at all.  The obvious example is speed being linear with
> temperature and VCC.

True.  There are a lot of implicit assumptions engineers make everday.  I did it
for 20 years in telecom, and I still have to do it now.  Sometimes the common
knowledge isn't all that common, and it may not be true (e.g. maybe there is
temperature compensation in the circuit, and it isn't getting faster as it gets
colder, or there is a voltage regulator hidden on chip that we don't talk
about).  Usually a phone call, or an email will clear up little things like
that.  That is what this question was all about -- is there any reason why one
shouldn't use it at 24 MHz?  I went around, and unanimously everyone said "no
problem," but then I asked OK, so then why don't we change the spec?  No takers.
0, Nada.  So, if the spec won't change, I can not recommend its use -- for all of
thereasons stated.

>
>
> In this context, I guess that some of the tools are part of the contract,
> next to the data sheet.  I'm thinking of the timing verifier or report
> generator and the power estimator.

Yes.

>
>
> The particular case that I proposed is tricky because it depends upon
> minimum prop times and the general party line is things might go faster.
>
> But in this particular case, there is a requirement for that min in the
> spec sheet.  The spec sheet says it will work down to 25 MHz.
>
> Most people know it's "legal" to reduce the prop times in a data sheet
> if you can keep a part cool and/or keep the VCC above min.  My proposal
> uses the same approach, just with the reverse sign bit.  If it will
> work at 25 MHz at max VCC, will it run at 24 MHz if I keep VCC at least
> 5% below max?

OK.  Now that is a good question.  If you kept the Vccint below the recommended
maximum limit by 5%, you have gained some margin.  If you additionally never go
below 10 C (an asian indoor telecom limit -- it never really gets cold in Taiwan
or Hong Kong), they you have some more margin.

But remember the comments about the possibility of a hidden voltage regulator,
and temperature compensation?  Maybe the margin gained isn't all that much.

>
>
> --
> These are my opinions, not necessarily my employers.  I hate spam.

What I would do, if there was a clear reason to do this (save a ton of money, or
make the board smaller, or ...) is to take apart, find the low frequency limit,
and then change the voltage, and change the temperature, and see how it changes.
I'll save you some of the work:  the voltage is regulated for part of the
circuit, so it won't get as fast as expected with voltage.  There was also a lot
of work on removing temperature sensitivity, but it is still there.  The DLL will
get faster as it gets colder, but not faster as fast as the core logic.

Then, I would see what my margin is.  If I have a 2X margin, then I would
probably just go to it, and be done with it (standard engineering derating).  If
my margin was only 50%, then I probably still would go ahead, as it would take a
lot of process changes, and perhaps even design changes to eat that up -- but I
could never be sure.  I might put in place an incoming inspection, and I might
ask for a letter from my distributor to inform me of any change to the process on
that part (a standard service for customers).

I always got that letter in my telecom job, because in telecom, if anything
changes, it scares the hell out of the phone companies.  They have only been in
business for 130+ years, so they know that change = bad in any design.  Changes
in components required an immediate re-qualification of the product, regardless
of the change (unless it was the ink on the top, or some other silly change).

When Matra changed the 80C31 (did a shrink for yield and cost), they shrank a
transistor pullup that should have stayed big (strong).  It caused an immense
amount of **** because we had to add a 10K pullup resistor.  You would think the
world came to an end!  The wailing, the nashing of teeth .... you get the
picture.


--------------B8C7AD462CF21207EA77122C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hal,
<p>I will comment below.
<p>Austin
<p>Hal Murray wrote:
<blockquote TYPE=CITE>[My initial msg.]
<p>> > [Context is wanting to run a DLL at 24 MHz when the min spec is
25.]
<br>> >
<br>> > > Now,&nbsp; I am assuming you are not going below 0C, so there
will be some
<br>> > > margin there.&nbsp; But if not, then definitely don't do it.
<br>> >
<br>> > In general, CMOS prop time is linear in temp and supply voltage.&nbsp;
He's
<br>> > only off by 4% so we should be able to draw the forbidden zone
on a graph
<br>> > with voltage on one axis and temp on the other.
<br>> >
<br>> > Does that sort of reasoning work with DLLs?
<br>> >
<p>In article &lt;3A561466.534B42DB@xilinx.com>,
<br>&nbsp;Austin Lesea &lt;austin.lesea@xilinx.com> writes:
<br>> Hal,
<br>>
<br>> Yes.
<br>>
<br>> I just can't say "go ahead" for all of the reasons I stated.&nbsp;
Someday, some
<br>> lot might be just a little too fast (even though it is pretty unlikely).
<p>That's exactly the point I was trying to make.&nbsp; Why can't you say
"go ahead"?
<br>Is there a flaw in my reasoning or is that due to legal issues?</blockquote>
<i>There is an implicit contract here.&nbsp; We state in the specifications
that the product will do X.&nbsp; If it doesn't do X, you get it replaced
with one that does.</i>
<blockquote TYPE=CITE>&nbsp;
<p>In most interesting projects, a designer has to use a lot of information
<br>that isn't in the data sheet.&nbsp; What's the "contract" between the
vendor
<br>and the designer?&nbsp; How can I be sure that a design will work correctly
<br>if I use information from app notes or general common sense or rumors
<br>from usenet?</blockquote>
<i>Spec sheet = contract.&nbsp; App note = we will support it just like
the spec sheet.&nbsp; A email from a Xilinx engineer is a written document,
so it also must be treated as a statement of 'suitablity for use' ... ie
we would have to supply chips that do what was said.&nbsp; Thus, my caution.&nbsp;
Anything else, well, have fun.</i>
<blockquote TYPE=CITE>&nbsp;
<p>Note that there are two types of extra information.&nbsp; One is things
like
<br>how to get the tools to do what you want or explainations of what a
<br>particular line on the data sheet really means.
<p>The other type of information is extra - things you won't find in the
<br>data sheet at all.&nbsp; The obvious example is speed being linear
with
<br>temperature and VCC.</blockquote>
<i>True.&nbsp; There are a lot of implicit assumptions engineers make everday.&nbsp;
I did it for 20 years in telecom, and I still have to do it now.&nbsp;
Sometimes the common knowledge isn't all that common, and it may not be
true (e.g. maybe there is temperature compensation in the circuit, and
it isn't getting faster as it gets colder, or there is a voltage regulator
hidden on chip that we don't talk about).&nbsp; Usually a phone call, or
an email will clear up little things like that.&nbsp; That is what this
question was all about -- is there any reason why one shouldn't use it
at 24 MHz?&nbsp; I went around, and unanimously everyone said "no problem,"
but then I asked OK, so then why don't we change the spec?&nbsp; No takers.&nbsp;
0, Nada.&nbsp; So, if the spec won't change, I can not recommend its use
-- for all of thereasons stated.</i>
<blockquote TYPE=CITE>&nbsp;
<p>In this context, I guess that some of the tools are part of the contract,
<br>next to the data sheet.&nbsp; I'm thinking of the timing verifier or
report
<br>generator and the power estimator.</blockquote>
<i>Yes.</i>
<blockquote TYPE=CITE>&nbsp;
<p>The particular case that I proposed is tricky because it depends upon
<br>minimum prop times and the general party line is things might go faster.
<p>But in this particular case, there is a requirement for that min in
the
<br>spec sheet.&nbsp; The spec sheet says it will work down to 25 MHz.
<p>Most people know it's "legal" to reduce the prop times in a data sheet
<br>if you can keep a part cool and/or keep the VCC above min.&nbsp; My
proposal
<br>uses the same approach, just with the reverse sign bit.&nbsp; If it
will
<br>work at 25 MHz at max VCC, will it run at 24 MHz if I keep VCC at least
<br>5% below max?</blockquote>
<i>OK.&nbsp; Now that is a good question.&nbsp; If you kept the Vccint
below the recommended maximum limit by 5%, you have gained some margin.&nbsp;
If you additionally never go below 10 C (an asian indoor telecom limit
-- it never really gets cold in Taiwan or Hong Kong), they you have some
more margin.</i><i></i>
<p><i>But remember the comments about the possibility of a hidden voltage
regulator, and temperature compensation?&nbsp; Maybe the margin gained
isn't all that much.</i>
<blockquote TYPE=CITE>&nbsp;
<p>--
<br>These are my opinions, not necessarily my employers.&nbsp; I hate spam.</blockquote>

<p><br><i>What I would do, if there was a clear reason to do this (save
a ton of money, or make the board smaller, or ...) is to take apart, find
the low frequency limit, and then change the voltage, and change the temperature,
and see how it changes.&nbsp; I'll save you some of the work:&nbsp; the
voltage is regulated for part of the circuit, so it won't get as fast as
expected with voltage.&nbsp; There was also a lot of work on removing temperature
sensitivity, but it is still there.&nbsp; The DLL will get faster as it
gets colder, but not faster as fast as the core logic.</i><i></i>
<p><i>Then, I would see what my margin is.&nbsp; If I have a 2X margin,
then I would probably just go to it, and be done with it (standard engineering
derating).&nbsp; If my margin was only 50%, then I probably still would
go ahead, as it would take a lot of process changes, and perhaps even design
changes to eat that up -- but I could never be sure.&nbsp; I might put
in place an incoming inspection, and I might ask for a letter from my distributor
to inform me of any change to the process on that part (a standard service
for customers).</i>
<p><i>I always got that letter in my telecom job, because in telecom, if
anything changes, it scares the hell out of the phone companies.&nbsp;
They have only been in business for 130+ years, so they know that change
= bad in any design.&nbsp; Changes in components required an immediate
re-qualification of the product, regardless of the change (unless it was
the ink on the top, or some other silly change).</i><i></i>
<p><i>When Matra changed the 80C31 (did a shrink for yield and cost), they
shrank a transistor pullup that should have stayed big (strong).&nbsp;
It caused an immense amount of **** because we had to add a 10K pullup
resistor.&nbsp; You would think the world came to an end!&nbsp; The wailing,
the nashing of teeth .... you get the picture.</i>
<br>&nbsp;</html>

--------------B8C7AD462CF21207EA77122C--


Article: 28440
Subject: Re: Stereo vision on Virtex
From: Steven Derrien <sderrien@irisa.fr>
Date: Fri, 12 Jan 2001 18:14:08 +0100
Links: << >>  << T >>  << A >>


Sven Fleck wrote:
> 
> Hi there,
> 
> can anybody give me good references for stereo vision algorithms which are
> best suited for the parallel execution nature of FPGAs to better solve the
> correspondence problem using a correlation based approach? I know about the
> CMU group using DSPs and so on, but FPGA designs are rather hard to find,
> but should in my eyes be far superior in performance.

There was some work made by the Perle-1 team 6 or 7 years ago on the
early xc3000 series (authors were O.Faugeras and J.Vuillemin). I'm not
aware of recent work with FPGA on this field. 

Olivier Faugeras et al.
Real time correlation-based stereo: algorithm, implementations and
application, 
http://www-sop.inria.fr/robotvis/personnel/faugeras/publications.html 

The thing is that there would be no reason (except power consumption) to
implement correlation based approach in an FGPA since you can already
get real-time in sowtware with recent CPUs or DSPs...

> (small overview is included in Kurt Konolige's "Extra-Pair-Of-Eyes"
> DSP-design)

> > I would like to use a Xilinx Virtex-1000 board running @ 100MHz for this
> task.

You wouldn't need such a huge Virtex to do that ! An xcv300 should be
enough (operation are on 8 to 12 bits with almost no multiplications !)


Steven

> 
> Thanks in advance!
> 
> Sincerely,
> 
> Sven Fleck
> 
> ----------------------------------
> Sven Fleck
> University of Tuebingen
> Germany

Article: 28441
Subject: Re: Stereo vision on Virtex
From: "Jan Gray" <jsgray@acm.org>
Date: Fri, 12 Jan 2001 17:16:59 GMT
Links: << >>  << T >>  << A >>
"Sven Fleck" <fleck@informatik.uni-tuebingen.de> wrote in message
news:93n834$14d$1@newsserv.zdv.uni-tuebingen.de...
> Hi there,
>
> can anybody give me good references for stereo vision algorithms which are
> best suited for the parallel execution nature of FPGAs to better solve the
> correspondence problem using a correlation based approach?

I don't know what the correspondence problem is, but have you seen Woodfill
and Von Herzen's paper "Real Time Stereo Vision on the PARTS Reconfigurable
Computer" [http://www.fpga.com/papers/stereovis.pdf]?

"The first application implemented on the PARTS engine is a depth from
stereo vision algorithm that computes 24 stereo disparities on 320 by 240
pixel images at 42 frames per second. Running at this speed, the engine is
performing approximately 2.3 billion RISC-equivalent operations per second,
accessing memory at a rate of 500 million bytes per second and attaining
throughput of over 70 million point x disparity measurements per second. "

Jan Gray, Gray Research LLC




Article: 28442
Subject: Re: SRAM fpga cell
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Fri, 12 Jan 2001 09:33:26 -0800
Links: << >>  << T >>  << A >>

--------------D862F087FDE4A8FCACC3AC41
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

I wrote an app note on the subject. You can click on

http://www.xilinx.com/xapp/xapp092.pdf

Peter Alfke, Xilinx Applications
======================================
Simon Fielder wrote:

> Thankyou for any help.
>
> Please could someone point me to the relevant information on the folowing subjects.
>
> 1) What does the basic FPGA SRAM cell or element look like?  A description of how it is constructed (to the component level - transistors, resistors etc.) and a diagram of a single cell (does it look like a six transistor SRAM memory cell or does it differ?) would be very useful.
>
> 2) Has any failure analysis been carried out on the SRAM elements themselves and if so where can I get the results please?  Has anyone any useful information on failures of the SRAM cells?
>
> 3) What is the effectiveness of the engineering and stability of programming configuration.  For example if an SRAM FPGA is left powered but unused for a period of time, say a few weeks, at the end of this period would the SRAM element, and hence the FPGA itself, still be exactly as it was when originally programmed?
>
> Thankyou.

--------------D862F087FDE4A8FCACC3AC41
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I wrote an app note on the subject. You can click on
<p><u><A HREF="http://www.xilinx.com/xapp/xapp092.pdf">http://www.xilinx.com/xapp/xapp092.pdf</A></u>
<p>Peter Alfke, Xilinx Applications
<br>======================================
<br>Simon Fielder wrote:
<blockquote TYPE=CITE>Thankyou for any help.
<p>Please could someone point me to the relevant information on the folowing
subjects.
<p>1) What does the basic FPGA SRAM cell or element look like?&nbsp; A
description of how it is constructed (to the component level - transistors,
resistors etc.) and a diagram of a single cell (does it look like a six
transistor SRAM memory cell or does it differ?) would be very useful.
<p>2) Has any failure analysis been carried out on the SRAM elements themselves
and if so where can I get the results please?&nbsp; Has anyone any useful
information on failures of the SRAM cells?
<p>3) What is the effectiveness of the engineering and stability of programming
configuration.&nbsp; For example if an SRAM FPGA is left powered but unused
for a period of time, say a few weeks, at the end of this period would
the SRAM element, and hence the FPGA itself, still be exactly as it was
when originally programmed?
<p>Thankyou.</blockquote>
</html>

--------------D862F087FDE4A8FCACC3AC41--


Article: 28443
Subject: Re: APEX20K multi-device configuration
From: eteam <eteam@aracnet.com>
Date: Fri, 12 Jan 2001 10:09:17 -0800
Links: << >>  << T >>  << A >>
The answer is no, if your hookup is as fig 23 in AN116.

In this hookup, the multiple FPGAs look (to the uP) like a single
huge FPGA.  FPGA #1 (first in the string) inhibits its nCEO output
until it is programmed, so that FPGA #2 (and successive FPGAs) are
simply waiting and doing nothing.  When FPGA #1 is programmed, its
nCEO output is asserted, and FPGA #2 then starts responding to the
data strobes.  When FPGA #2 is programmed, its nCEO output is then
asserted, allowing the next successive FPGA to program, etc. etc.
until the whole chain is configured.

I personally prefer to avoid the daisy chain mode of programming,
because it is more difficult to debug in case of failure.  An
intermediate approach is to bring each of the nSTATUS and CONFIG_DONE
lines to the uP, without bussing them together.  This gives the uP
a clear picture of which FPGA is programmed (or not), or generated
an error.

Cheers,

Bob Elkind, eteam@aracnet.com 

Meta Fernando wrote:
> 
> I have to configure 3 APEX20K1500 by a Flash memory controller.
> I chosen a PPA scheme for the configuration (Doc. : Altera AN116)
> My questions is:
> 
> After first device's configuration...
> - Do I have to move again the signals nCONFIG, nCS and CS for the second
> and  the third  device?
> 
> Thanks in advance!

Article: 28444
Subject: Re: Problem with Simulation of VirtexE Block SelectRAM
From: Newsbrowser@Newsbrowser.com (Newsbrowser)
Date: Fri, 12 Jan 2001 20:00:30 GMT
Links: << >>  << T >>  << A >>
On Thu, 11 Jan 2001 17:06:31 +0100, Christian Wiencke
<christian.wiencke@stud.uni-rostock.de> wrote:

><!doctype html public "-//w3c//dtd html 4.0 transitional//en">
><html>
>Hi,
><br>I'm using a Block SelectRAM in a VirtexE Design. During the timing
>simulation with Synopsys VHDL Debugger (version 1999-10) I get the following
>warning:
><p>Assertion WARNING at ... in design unit VPACKAGE from ... "Invalid ADDRESS:
>0101010101. Memory contents will be set to 'X'."
><p>The address, data, enable and write enbalbe signals are correct, but
>the simulation produces this assertion. I had a look at the SIMPRIM model
>of the BlockRAM. There is a function ADDR_IS_VALID, which checks for the
>validity of the argument.
><p><font face="Courier New,Courier"><font size=-1>&nbsp; function ADDR_IS_VALID
>(</font></font>
><br><font face="Courier New,Courier"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>SLV : in std_logic_vector</font></font>
><br><font face="Courier New,Courier"><font size=-1>&nbsp; ) return boolean
>is</font></font>
><br><font face="Courier New,Courier"><font size=-1>&nbsp;</font></font>
><br><font face="Courier New,Courier"><font size=-1>&nbsp; variable IS_VALID
>: boolean := TRUE;</font></font>
><br><font face="Courier New,Courier"><font size=-1>&nbsp;</font></font>
><br><font face="Courier New,Courier"><font size=-1>&nbsp; begin</font></font>
><br><font face="Courier New,Courier"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>for I in SLV'high downto SLV'low loop</font></font>
><br><font face="Courier New,Courier"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>if (SLV(I) /= '0' AND SLV(I) /= '1') then</font></font>
><br><font face="Courier New,Courier"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>IS_VALID := FALSE;</font></font>
><br><font face="Courier New,Courier"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>end if;</font></font>
><br><font face="Courier New,Courier"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>end loop;</font></font>
><br><font face="Courier New,Courier"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>return IS_VALID;</font></font>
><br><font face="Courier New,Courier"><font size=-1>&nbsp; end ADDR_IS_VALID;</font></font>
><p>The address (SLV) is "0101010101", but the function generates FALSE.
>Is it a bug in the simulation software?
><br>Do you know this problem?
><p>Thanks
><br>Christian</html>
>
really hate it when people post in HTML crap. 


Ralph Watson 
Return Email Address is: 
ralphwat dot home at excite dot com 
just type the address in like it should look like

Article: 28445
Subject: Re: Nondeterministic FSMs in hardware?
From: handleym@ricochet.net (Maynard Handley)
Date: Fri, 12 Jan 2001 12:15:53 -0800
Links: << >>  << T >>  << A >>
In article <TCb56.8725$4c.743972@ruti.visi.com>,
amolitor-at@visi-dot-com.com wrote:

> In article <3A552F9E.61B88CDB@igs.net>, Paul DeMone  <pdemone@igs.net> wrote:
> >What exactly do you mean? An FSM with probablistic state transitions
> >governed by a pseudo random sequence generator like an LFSR or a linear
> >congruence modulo multiplier? Or governed by a truely random noise
> >source like amplified thermal background noise?
> 
>         _Compilers:_Principles,_Techniques,_and_Tools_
> discusses this. What you do with an NFA is that you essentially
> "take" all the transitions that are possible in a state,
> at once.
> 
>         Your current "state" is really the set of all the states
> of the NFA (Non-deterministic Finite Automaton) that you could
> be in. You take all the possible transitions out of all those
> states that you could be in. I think if one of the new
> states is a terminating state, you stop.

From a different point of view, all this comes across as very much like
"quantizing" traditional FSMs. Recall that to quantize a classical
"system", you construct the free complex vector space over the state space
of the classical system, ie the elements, |psi> of your quantized theory
are vectors associating a complex number with every possible state of of
the underlying classical system. You then define some linear scheme for
these states to evolve which is trivially defined by the underlying FSM. 
The only real difference would appear to be that the NFA is filling that
vector with 1s and 0s rather than complex numbers. Obviously this works
well for simulation and hardware construction. For more general discussion
of mathematical properties, the more general free complex vector space
(with 0 treated as 0 and non-zero treated as 1 at the end of the day) may
be more powerful.

Maynard

>         You can implement these things pretty efficiently (for
> a fixed maximum number of states) by managing your current state
> as a bit-vector which indicates which of the NFA states you
> are currently in.
> 
>         You should be able to, um, use the current bit vector as
> enables on a set of functional units (one per state) each of
> which consumes the current input symbol and emits a new
> bit vector of possible states. Then OR the results of all
> the functional units together to get your new state. And the
> current state vector with a vector representing terminating
> states, if the result is non-zero, stop.
> 
>         Your hardware will set a Really Hard cap on the maximum
> number of NFA states you support. The details of how input symbols
> select transitions will determine the inner structure of the
> functional units. If, for eaxmple, you are doing string matching,
> there is a straightforward way to convert a regular expression into an
> NFA. If you support up to, say, 64 states (which will capture regular
> expressions up to something near 64 characters long, I think), each
> state (functional unit) can be a 256 element memory 64 bits wide. The
> input symbol is a character, and acts as the address. Address all
> the little RAMs at once, and use the current input state as output
> enables on the RAMs. This could go quite fast, though where you'd
> find RAMs that shape I have no idea. I guess you could do this in
> an FPGA and do regexp matching at 100M characters/second? Network
> Intrusion Detection, anyone?
> 
>         Why I don't get is what makes this interesting,
> it all seems pretty trivial to me. Am I missing something?
>         
>         A previous poster basically summed it up. You implement
> an NFA as a DFA (Deterministic Finite Automaton) whose states are
> collections of the NFA state. The point of doing it as an NFA is
> that you don't have to construct the entire DFA, you essentially
> "dynamically" construct that states and transitions of an equivalent
> DFA as you go. The NFA is generally quite a bit smaller than equivalent
> DFAs (I think one can construct examples where equivalent DFAs all have
> 2^n states). Furthermore, if you need to run a finite automaton on one
> input only, it is more efficient to run the NFA and (inefficiently)
> construct only the DFA states you NEED instead of constructing the
> entire DFA.
> 
> 
>         The referenced book has a nice discussion of many of these issues.
> 
>         [ by the way, I forget, or never knew, whether one NFA can have
>           more than one equivalent DFA. I used the plural above, because
>           it feels right, but there may always be one DFA ]

Article: 28446
Subject: Re: JTAG configuration fails with XC95144XL
From: Petter Gustad <spam@gustad.com>
Date: 12 Jan 2001 21:25:32 +0100
Links: << >>  << T >>  << A >>
arast@inficom.com (Alex Rast) writes:

> If you look at the output of the cable with a scope, none of the JTAG lines 
> ever see data on them. I'm suspicious we may have a bad cable, but are there 
> other possibilities? Is there some oddball software incompatibility? Strange 
> idisyncracies in the XC95144? 

I've configured the XC95144 by generating a svf file under solaris
using jtagprog, then transfer the svf file to a PC with software and
jtag supporting hardware from JTAG Technologies. I can't seem to
remember any XC95144 idisyncracies...

Petter
-- 
________________________________________________________________________
Petter Gustad            8'h2B | ~8'h2B            http://www.gustad.com
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}

Article: 28447
Subject: CHES 2001 --- 2nd CFP
From: Christof Paar <christof@ece.wpi.edu>
Date: Fri, 12 Jan 2001 15:58:42 -0500
Links: << >>  << T >>  << A >>
We apologize for multiple mailings. -Christof Paar

===================================================================

           WORKSHOP ON CRYPTOGRAPHIC HARDWARE AND EMBEDDED SYSTEMS
                                 (CHES 2001)
                            
                             www.chesworkshop.org

				Paris - France
			       May 13 - 16, 2001 

                            Second Call for Papers

General Information

The focus of this workshop is on all aspects of cryptographic
hardware and embedded system design. The workshop will be a forum of
new results from the research community as well as from the industry.
Of special interest are contributions that describe new methods for
efficient hardware implementations and high-speed software for
embedded systems, e.g., smart cards, microprocessors, DSPs, etc. We
hope that the workshop will help to fill the gap between the
cryptography research community and the application areas of
cryptography. Consequently, we encourage submission from academia,
industry, and other organizations. All submitted papers will be
reviewed.

This will be the third CHES workshop. The first workshop, CHES '99,
was held at WPI in August of 1999 and was very well received by
academia and industry. There were 170 participants, more than half of
which were from outside the United States. The second workshop, CHES
2000, was also held at WPI in August of 2000 and had an attendance of
180.

The third workshop, CHES 2001, will be held in Paris in May of 2001. 
The topics of interest include but are not limited to:

   * Computer architectures for public-key cryptosystems
   * Computer architectures for secret-key cryptosystems
   * Reconfigurable computing and applications in cryptography
   * Cryptographic processors and co-processors
   * Modular and Galois field arithmetic architectures
   * Tamper resistance on the chip and board level
   * Smart card attacks and architectures 
   * Efficient algorithms for embedded processors
   * Special-purpose hardware for cryptanalysis
   * Fast network encryption
   * True and pseudo random number generators
   * Cryptography in wireless applications


Instructions for Authors

Authors are invited to submit original papers. The preferred
submission form is by electronic mail to submission@chesworkshop.org.
Papers should be formatted in 12pt type and not exceed 12 pages (not
including the title page and the bibliography). The title page should
contain the author's name, address (including email address and an
indication of the corresponding author), an abstract, and a small
list of key words. Please submit the paper in Postscript or PDF. We
recommend that you generate the PS or PDF file using LaTeX, however,
MS Word is also acceptable. All submissions will be refereed.

Only original research contributions will be considered. Submissions
must not substantially duplicate work that any of the authors have
published elsewhere or have submitted in parallel to any other
conferences or workshops that have proceedings.


Important Dates

 Submission Deadline:          February 15th, 2001.
 Acceptance Notification:      March	31st, 2001.
 Final Version due:            April	21st, 2001.
 Workshop:                     May      13th - 16th, 2001.
 
NOTE: The CHES dates May 13th - 16th are the Sunday - Wednesday
succeeding Eurocrypt 2001 which ends on Thursday, May 10th.


Mailing List

If you want to receive emails with subsequent Call for Papers and
registration information, please send a brief mail to:
  mailinglist@chesworkshop.org


Invited Speakers

Ross Anderson, University of Cambridge, U.K.
  Protecting Embedded Systems - the Next Ten Years


Program Committee

Ross Anderson, University of Cambridge, England
Jean-Sebastien Coron, Gemplus, France
Kris Gaj, George Mason University, USA
Jim Goodman, Chrysalis-ITS, Canada
Anwar Hasan, University of Waterloo, Canada
Peter Kornerup, Odense University, Denmark
Bart Preneel, Katholieke Universiteit Leuven, Belgium
Jean-Jacques Quisquater, Universite Catholique de Louvain, Belgium
Christoph Ruland, University of Siegen, Germany
Erkay Savas, cv cryptovision, Germany
Joseph Silverman, Brown University and NTRU Cryptosystems, Inc., USA
Jacques Stern, Ecole Normale Superieure, France
Colin Walter, Computation Department - UMIST, U.K.
Michael Wiener,   Entrust Technologies, Canada


Organizational Committee

All correspondence and/or questions should be directed to either of the
Organizational Committee Members:

Cetin Kaya Koc
(Publications Chair)
Dept. of Electrical & Computer Engineering
Oregon State University
Corvallis, Oregon 97331, USA
Phone: +1 541 737 4853 
Fax: +1 541 737 8377 
Email: Koc@ece.orst.edu 

David Naccache
(Program Chair and Local Organization)
Gemplus Card International
34 Rue Guynemer
92447 Issy les Moulineaux Cedex, FRANCE
Phone: +33 1 46 48 20 11
Fax: +33 1 46 48 20 04
Email: David.Naccache@gemplus.com 

Christof Paar
(Publicity Chair)
Dept. of Electrical & Computer Engineering
Worcester Polytechnic Institute
Worcester, MA 01609, USA
Phone: +1 508 831 5061
Fax: +1 508 831 5491
Email: christof@ece.wpi.edu 


Workshop Proceedings

The post-proceedings will be published in Springer-Verlag's Lecture
Notes in Computer Science (LNCS) series. Notice that in order to be
included in the proceedings, the authors of an accepted paper must
guarantee to present their contribution at the workshop.


Article: 28448
Subject: Re: CRC - from long division to XOR, how?
From: eml@riverside-machines.com.NOSPAM
Date: Fri, 12 Jan 2001 21:42:33 GMT
Links: << >>  << T >>  << A >>
On Fri, 12 Jan 2001 09:48:07 -0500, "Jamie Sanderson"
<jamie@nortelnetworks.com> wrote:

>I guess what I thought was a clear question really wasn't, since I've had a
>number of responses which didn't address the issue. (not that I don't
>appreciate the effort)
>
>I think it would be illuminating if I posted an example of Jan's code. To
>keep it short, I used the polynomial from E1, which is a CRC-4 with a
>generating polynomial of x^4 + x + 1, calculated over a byte.
>
>Looking at the code below, you'll find that it contains a set of four XOR
>statements which compute successive values of the CRC. What I don't
>understand is how these statements were generated. Clearly there is an
>algorithm for doing this since Jan's tool obviously makes use of one. I'd
>like to know what that is (assuming it's not proprietary).

This is exactly what a parallel factorisation is. Assume you've got 8
serial data bits going into a 4-bit LFSR. When you put in the 1st bit,
you get 4 equations for the next state of the LFSR. Iterate 7 more
times, for the remaining data bits, using the new values of the LFSR,
and the last set of 4 equations is the result; these define the value
of each bit of the LFSR after an entire byte is shifted in. You'll
find that there are lots of common terms, and you can factorise them
out. Eventually, you'll end up with lots of XORs, to give you a
parallel implementation of the CRC. The TAXI app note covers it all if
you can find it.

Evan

Article: 28449
Subject: Re: Alliance for Linux
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Fri, 12 Jan 2001 14:54:30 -0700
Links: << >>  << T >>  << A >>
Jamie Lokier wrote:
> 
> Andy Peters writes:
> > ModelSim and Synplify both use dongles (which I vastly prefer over
> > that FlexLM bogosity) but the Mac ain't got a parallel port so I'm SOL
> > there.
> 
> And even if the MAC did have a parallel port...
> 
> I vastly prefer FlexLM because there is some hope of it working in an
> emulator.  In my experience dongle reading code does seriously weird
> things to your parallel port, and doesn't work in an emulator.

Yeah, but if FlexLM is keyed to your ethernet MAC (not Macintosh!)
address and you want to, say, do some work at home, you're hosed.

And when you get a new computer with a new ethernet card (or your card
dies), you have to deal with getting a new license file, which isn't
difficult, but it IS annoying.

Here's my thought on all this: choose the software, and buy whatever OS
and machine it runs on, rather than buying (or downloading) an OS and
installing it on a particular machine and using hacks and such in an
effort to get the software to work on it.

Yes, I'd like ModelSim PE and the Xilinx tools and Synplify to all run
on Linux.  But my job is to design FPGAs, and if that requires running
NT, so be it.  Yes, I will tell the vendors that I prefer Linux.  Yes, I
will demand that the Linux versions of the tools cost the same as the NT
versions.  No, I will not frustrate myself trying to get software
written for one OS to run on another.

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

"It is better to be silent and thought a fool, 
 than to send an e-mail to the entire company
 and remove all doubt."



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