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 8600

Article: 8600
Subject: Re: serial conf. PROMS
From: "Erwin Oertli" <oertli@inf.ethz.ch>
Date: Mon, 12 Jan 1998 15:01:57 +0100
Links: << >>  << T >>  << A >>
i) As far as I know, 256k is the largest part. But you can daisy-chain them
without problem.

ii) How to program the parts is described in 'FPGA Configuration E2PROM
Programming Specification' and can be found on the Web.

With a little imagination you can easily build a programmer for these parts:
a) in system placed
b) daisy-chainded

Best regards
Erwin



Article: 8601
Subject: Re: Xilinx Stock
From: dark7room@ix.netcom.com (Austin Franklin)
Date: Mon, 12 Jan 1998 09:13:07 -0500
Links: << >>  << T >>  << A >>
> actually, i downloaded the statecad demo version and find it, so far, a
> really nice way to work as you can concentrate on the problem solving and
> not the mechanism of a state machine.  i draw the state diagrams in the
> tool the same way that i do on a piece of paper and it has a nice graphical
> simulation capability too.  anybody have any detailed experience with this
> tool or any other similar tools?

Let me know if you can make a PCI target and master state machine that 
runs at 33MHz in a -3 4013 part with it, then I'll be impressed ;-)  P.S. 
Oh, don't forget to provide logic to make up for the /STOP-/FRAME Intel 
chip set bug that requires 5 destinations for the raw /FRAME signal...see 
if you can make timing for that...was that a 7ns setup?

I certainly do not like to have to design state machines in schematic but 
due to most of these tools not having any feedback from the place and 
route tools, they do not arrange the logic in the most optimal way to 
achieve speed.

I found that I end up fussing with HDLs (and their compilers) to compile 
the way I want them to.  It seems to always be faster to do high speed 
logic in schematic.  Now, if speed is not a problem, then HDLs can be 
quite useful.

Austin Franklin
darkroom@ix.netcom.com
Article: 8602
Subject: Re: Xilinx Stock
From: husby@fnal.gov
Date: Mon, 12 Jan 1998 10:33:04 -0600
Links: << >>  << T >>  << A >>
My vote on the schematics vs. HDL question (We are voting aren't we?)

While it would be nice to be able to use an HDL for FPGA design, there
are still a number of problems that make it impractical.  Primarily,  HDL
doesn't give the tight mapping control necessary for dense, high speed
designs.

Ideally, we will see a hybrid of HDL/schematic entry which allows data
paths to be expressed graphically while control logic expressed as text.
I've been using something like this for about 4 years now and wouldn't
trade it for anything else.  It's an extension to Viewlogic that allows
you to put logic equations right on a schematic page.  An example
schematic can be found at:
    http://eseserver1.fnal.gov/eseproj/trigger/fpga2c6x.pdf

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet
Article: 8603
Subject: Asynchronous square root.
From: husby@fnal.gov
Date: Mon, 12 Jan 1998 11:02:03 -0600
Links: << >>  << T >>  << A >>
Pasquale Corsonello <pascor@nwdeis1.unical.it>
> Does anyone know a source for hardware systems computing square root
> using self-timed asinchronous approach?


Here's an algorithm written in C to simulate both a synchronous and
asynchronous hardware implementations in an FPGA.
-------------------------------------------------------------------------
--- ----------------- // Synchronous Sqrt simulates the following
hardware // N[15:0] := LOAD ? Din[15:0] : N[13:0],0,0  # 16-bit 2-1
Registered Mux // N[23:16]:= Carry ? Sub[7:0] : N[21:14]  #  8-bit 2-1
Registered Mux // R[7:0]  := R[6:0],Carry;  <Reset=LOAD>  #  8-bit Shift
Register // Sub[9:0]== (N[23:14]-R[7:0],0,1) <Cout=Carry> # 10-bit adder

#include <stdio.h>

void Printb(char *S, long A)     // Bit print function for diagnostics
{ int I;
  for (I=32; I--;) if (A&(1L<<I)) putchar('1'); else putchar('0');
  printf(" %8lx %s\n",A,S);
}

int Root(unsigned int N)   // Iterative (Synchronous) version
{ int   Bit=8;  // Bit counter
  long  N_reg= N; // Simulate 24-bit N register
  long  R_reg=0;  // Simulate 10-bit Root register as bits 23:14
  long  Tmp;  // Temporary
  long  Rt=0;  // Root

  while (Bit--)  { R_reg = (Rt<<16)|0x4000;  // Note this is for free in
FPGA  Tmp= (N_reg-R_reg);  // Note only 10-bit subtractor (23:14) needed 
if (Tmp >= 0)  // If next bit is a 1 (carry-out of subtractor)	{ N_reg=
Tmp << 2;  // Accept subtraction and shift N_reg  Rt= (Rt << 1)|1;  }  //
Shift 1 into result  else  { N_reg= N_reg<<2;  // Ignore subtraction, but
shift  Rt= (Rt << 1)  ;  }  // Shift 0 into result  }  return ((int)Rt);
}

int Unrolled(unsigned int N)  // Unrolled loop (Asynchronous) version
{ int T;     // Temp
  int R=0;   // Root
  int A;     // Intermediate result

  // We can fit the logic for the first two stages into 2 ORCA PFUs
  // with one level of delay.  These lookup tables simulate this.
  int RTABLE[16]={0,1,1,1,2,2,2,2,2,3,3,3,3,3,3,3};  // 2-bit root
  int ATABLE[16]={0,0,1,2,0,1,2,3,4,0,1,2,3,4,5,6};  // 3-bit result

#define SubMux(Mask)    /* Simulate subtractor followed by Mux */ \
{ T= A - ((R<<2) + 1);  /* Subtraction                         */ \
  R<<=1;                /* Shift Root to accept next bit       */ \
  if (T >= 0) { R|=1; A=T; }     /* Mux: select old A or T     */ \
  A &= Mask; }          /* Constrain A to current data width   */

  A= ATABLE[N>>12];     // Do first 2 stages in lookup table
  R= RTABLE[N>>12];
  A= (A<<2)|((N>>10)&3);  SubMux(0x00f);   // Stage 3: 4-bit adder
  A= (A<<2)|((N>> 8)&3);  SubMux(0x01f);   // Stage 4: 5-bit adder
  A= (A<<2)|((N>> 6)&3);  SubMux(0x03f);
  A= (A<<2)|((N>> 4)&3);  SubMux(0x07f);
  A= (A<<2)|((N>> 2)&3);  SubMux(0x0ff);
  A= (A<<2)|( N&3 );      SubMux(0x1ff);

  return(R);
}

main() { unsigned int I,R;  for (I=256; I--;)  { R= Unrolled(I*I);  if
(I>=30 && I<40) printf("I= %3d I*I= %6d R=%3d\n",I,I*I,R);  // Print
samples data  if (R != I) printf("Error: Root was %d should be
%d\n",R,I);  // Check all combinations	}  return(0); }

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet
Article: 8604
Subject: Re: Altera Flex10K Standby Current
From: dwtdw <dwtdw@tulsa.oklahoma.net>
Date: Mon, 12 Jan 1998 11:09:45 -0600
Links: << >>  << T >>  << A >>
I can only offer conjecture about why the 10mA standby current is being
consumed.  I have a hunch that it is a result of some tweaking to get
higher speed devices.  Maybe your supposition about sense amp currents
might be on the right trail.

Since the 10mA standby current is quoted as a "typical" value, it is
most probably not valid as a worst-case figure across temperature.  I am
concerned about how much the standby current will increase when I begin
testing at my upper temperature spec. of 85 Celsius.

I'm hoping that I'm not required to jump ship to an Altera competitor.
But I guess that I need to start looking at alternative vendors who
offer good software like Altera with devices similar in size to the
Altera 10K100.  I will be using the embedded memory on the Altera device
so that it is another requirement I must satisfy.

-------------------------------------------------------------------------------

richard katz wrote:

> dwtdw <dwtdw@tulsa.oklahoma.net> wrote in article
> <34B6AB45.98333AE7@tulsa.oklahoma.net>...
> : Attention Altera FLEX10K users:
> :
> : Is anyone else concerned about the imminent increase in Standby
> Current
> : for the 10K100A from only 0.5mA to 10mA???
> :
> : I design mobile/battery-powered products and this increase is
> gigantic
> : relative to my
> : overall power budget.  Is there anyone else designing mobile,
> : battery-powered, and/or
> : other products which require low-power consumption or do I have the
> only
> : application
> : that is power critical?
> :
> : It seems like Altera could continue to offer a low-power version of
> the
> : device for those
> : who need it.  Maybe something like a 10K100AL?
>
> out of curiousity (and an attempt to get some technical stuff
> discussed
> here), do you know where the power is going in the chip?  10 mA is a
> pile
> of current if you're doing low-powered stuff and yes, i do that sort
> of
> design too.  most of the fpga's that i use consume < 1 mA for
> Iccstdby,
> with many models running around 130 uA or so.  for a cmos part, 10 mA
> suggests that they're running some oscillators, sense amps w/ bias
> currents, or just have poor quality parts.  any other ideas?  also, i
> assume that the 10 mA spec is for the inputs at cmos levels.  is that
> number over temperature?
>
> just a thought or two,
>
> --------------------------------------------------------------
> rk
>
> "there's nothing like real data to screw up a great theory"
> - me (modified from original, slightly more colorful version)
> --------------------------------------------------------------



Article: 8605
Subject: Re: Xilinx Configuration Problem
From: "Martin Mason" <mtmason@ix.netcom.com>
Date: Mon, 12 Jan 1998 11:59:31 -0800
Links: << >>  << T >>  << A >>
Folks,
    We at Atmel relised that this may be a problem and didn't like the
alternatives much either - so we have put a feature on our AT17C010 and
AT17C512 ISP serial configuration memories to help simplify the system
design at system power-up.  The 512K and 1MBit EEPROM configurators have a
system friendly READY pin that signifies when the power supply has reached a
good voltage level - this Configurator open collector o/p can be used to
hold FPGAs (inc. Xilinx and our AT40K
http://www.atmel.com/atmel/products/prod3.htm) in RESET until the power
suply is seen as good - the voltage trip level is crude - but is all you
need in most cases - oh and it's a 'free' feature on our parts.  For more
details check out :

http://www.atmel.com/atmel/products/prod22.htm

Martin Mason
Atmel corp.



Article: 8606
Subject: Re: serial conf. PROMS
From: "Martin Mason" <mtmason@ix.netcom.com>
Date: Mon, 12 Jan 1998 12:04:25 -0800
Links: << >>  << T >>  << A >>


Erwin Oertli wrote in article <69d7u6$h6a@neptune.ethz.ch>...

>i) As far as I know, 256k is the largest part. But you can daisy-chain them
>without problem.
>
Now available upto 1MBit

http://www.atmel.com/atmel/products/prod182.htm

>ii) How to program the parts is described in 'FPGA Configuration E2PROM
>Programming Specification' and can be found on the Web.

http://www.atmel.com/atmel/products/prod183.htm

>
>With a little imagination you can easily build a programmer for these
parts:
>a) in system placed
>b) daisy-chainded

Happy to help:  e-mail  configurator@atmel.com for more details.

Martin Mason
Atmel corp.

>
>Best regards
>Erwin
>
>
>


Article: 8607
Subject: Re: SDRAM model
From: Robert Paley <rpaley@ti.com>
Date: Mon, 12 Jan 1998 14:25:26 -0600
Links: << >>  << T >>  << A >>

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

Lars wrote:

> Hi,
> does anyone where I can find a VHDL model for Synchronous DRAM?

 Check out the synopsys homepage

http://www.synopsys.com

--
Sincerely,

Robert Paley



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

<HTML>
Lars wrote:
<BLOCKQUOTE TYPE=CITE>Hi,
<BR>does anyone where I can find a VHDL model for Synchronous DRAM?</BLOCKQUOTE>
&nbsp;Check out the synopsys homepage

<P><A HREF="http://www.synopsys.com">http://www.synopsys.com</A>
<PRE>--&nbsp;
Sincerely,

Robert Paley</PRE>
&nbsp;</HTML>

--------------CC9C2FB45BC7F4C0D1E93A0F--

Article: 8608
Subject: Re: Parallel port interface
From: ymi@citr.nospam.itc.com.au (Nic)
Date: Tue, 13 Jan 1998 04:50:25 GMT
Links: << >>  << T >>  << A >>
In article <884284415.1093926925@dejanews.com>, jhon@geocities.com wrote:
>Does anybody know how to connect an Altera Flex10k device to a PC
>Parallel Port, particularly the electrical specifications do to this (not
>to program the device, but to exchange data between PC and Flex10k).
>
>Thank you in advance.
>
>-------------------==== Posted via Deja News ====-----------------------
>      http://www.dejanews.com/     Search, Read, Post to Usenet

Depends on what you want. Standard unidirectional PC to EPLD is easy (look in 
any PC book). If you want bidirectional you have to decide on 4 bit (old type 
parallel port using control lines for input) or 8 bit (newer bidirectional or 
IEEE 1284 compatible port).

There are some good web pages on parallel ports, try this one :

http://www.geocities.com/SiliconValley/Bay/8302/parallel.htm

Take care to terminate signals properly. I have found that some cards 
oscillate wildly if you don't. (Say a 100R series resistor and a 240R resistor 
to +5V or something like that).

Nic
Article: 8609
Subject: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: "richard katz" <stellare@erols.com.NOSPAM>
Date: 13 Jan 1998 04:58:11 GMT
Links: << >>  << T >>  << A >>
Austin Franklin <dark7room@ix.netcom.com> wrote in article
<MPG.f23ef00e507139f989680@nntp.ix.netcom.com>...
: > actually, i downloaded the statecad demo version and find it, so far, a
: > really nice way to work as you can concentrate on the problem solving
and
: > not the mechanism of a state machine.  i draw the state diagrams in the
: > tool the same way that i do on a piece of paper and it has a nice
graphical
: > simulation capability too.  anybody have any detailed experience with
this
: > tool or any other similar tools?
: 
: Let me know if you can make a PCI target and master state machine that 
: runs at 33MHz in a -3 4013 part with it, then I'll be impressed ;-)  P.S.

: Oh, don't forget to provide logic to make up for the /STOP-/FRAME Intel 
: chip set bug that requires 5 destinations for the raw /FRAME signal...see

: if you can make timing for that...was that a 7ns setup?

well, guess i can't really impress you, sorry.  as for high performance
logic, HDL's and graphical designs are probably not the way to go, they
can't seem to beat a good humanoid yet.  my designs, as i posted earlier,
tend to be a mixture of schematics, output of macro generators, and vhdl. 
the type used for each block depends, of course, on the block.  now, while
i haven't seen either great device efficiency or performance from the HDL
compilers (and have from macro generators, btw), i have used them to save a
lot of drafting time and some tedious logic minimization and state machine
design.  and for certain blocks, which may be conceptually not that bad but
are of reasonable size and have reasonable performance requirements, they
can save many, many hours of work.  and as stu pointed out, the designs are
more portable, which can also save quite a bit of labor when it's time to
move to another device.

for the highest performance designs, or other exceptional conditions (i.e.,
micropower, radiation-hardness, etc.) i'm in agreement, HDL's are not the
optimal way to go.  i've witnessed engineers, working on a pci target,
spend FAR too much time on the design, with rather wide performance swings
from each compilation-P&R cycle, which they couldn't control.


: I certainly do not like to have to design state machines in schematic but

: due to most of these tools not having any feedback from the place and 
: route tools, they do not arrange the logic in the most optimal way to 
: achieve speed.
 
interestingly, husby@fnal.gov comments on control logic expressed as text:

>: My vote on the schematics vs. HDL question (We are voting aren't we?)
>: 
>: While it would be nice to be able to use an HDL for FPGA design, there
>: are still a number of problems that make it impractical.  Primarily, 
HDL
>: doesn't give the tight mapping control necessary for dense, high speed
>: designs.
>: 
>: Ideally, we will see a hybrid of HDL/schematic entry which allows data
>: paths to be expressed graphically while control logic expressed as text.
>: I've been using something like this for about 4 years now and wouldn't
>: trade it for anything else.  It's an extension to Viewlogic that allows
>: you to put logic equations right on a schematic page.  An example
>: schematic can be found at:
>:     http://eseserver1.fnal.gov/eseproj/trigger/fpga2c6x.pdf


back to austin:

: I found that I end up fussing with HDLs (and their compilers) to compile 
: the way I want them to.  It seems to always be faster to do high speed 
: logic in schematic.  Now, if speed is not a problem, then HDLs can be 
: quite useful.


agreed - for many parts of a design, or even entire designs (just did one
at day job, complex sequencer @ 2.5 MHz) speed is not an issue, but
managing complex machines or design time is.  that is where a tool such as
state cad may be of use.  have any experience with it or it's competitors? 
i've continued to do some sample designs and found that relatively complex
state machines can be designed quite quickly and simulated easily too.  i
haven't experimented with moving the "synthesizable" code directly into my
vhdl compiler - anyone have experience with that?  (big fear that tool
integration could take more work than designing with pencil and berols
template).

Chris Tscharner, US Dept of Defense, adds a few comments about HDL's and
their simulation capabilities:

	This is one of the great things about having a whole simulation
	environment based on Verilog or VHDL.  I have one common language to do
	simulation in, be it RTL, structural extract from a schematic, or
whatever.
	If you are using Altera, MaxPlu2 will output structural Verilog and 
	accompanying timing SDF for your post-route design.  In the case of both
	Xilinx (M1) and Lucent (Foundry) you can use ngd2ver to do the same thing.
	I believe all will basically mirror the structure of your design, so
things
	like skew are simulated.  Modules to model the primitives are included -
you
	can use anyone's simulator.  For pre-layout simulation of schematics,
there
	should be a tool available to generate the needed netlist (example:
Viewlogic
	Powerview uses their Verilnet tool to extract Verilog).


--------------------------------------------------------------
rk

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
Article: 8610
Subject: Anybody using Orcad Express?
From: "Erik de Castro Lopo" <e.de.castro@fairlightesp.com.au>
Date: 13 Jan 1998 06:41:11 GMT
Links: << >>  << T >>  << A >>
Hi All,

I'd be interested in hearing from anybody who is using 
Orcad Express for FPGA design; especially if they are
using VHDL. Does this tool work for you? Do you think 
the VHDL language implementation is complete enough?
Yada, yada yada.

Thanks in advance,
Erik

Article: 8611
Subject: Re: Clock net skew simulation
From: fliptron@netcom.com (Philip Freidin)
Date: Tue, 13 Jan 1998 08:41:37 GMT
Links: << >>  << T >>  << A >>
In article <01bd1f47$36532680$7780accf@default> "richard katz" <stellare@erols.com.NOSPAM> writes:
>Philip typed here, possibly a tad too fast:
>: I believe that Richards problems with rampant clock skews are because he 
>: is not using Xilinx global clock buffers.
>Me types here, possibly too early in the morning, slightly insulted. :-)

No insult was intended. I'm sorry. It was meant as humor, since I knew 
you were using Actel chips.

>so, i can repeat my question, possibly the fpga manufacturers can answer:
>do the models that they supply model clock skew in the logic simulation
>accurately enough for timing analysis?

I suspect that the answer will be no, because the timing information that 
the place and route tools that I am familiar with, only report worstcase 
delays, and usually for the situation that generates longest delays, 
which is high temp, and low voltage. Skews that are derived from such 
info are not the worst case, which is when a long clock delay is at its 
worst, while simultaneously, some other clock delay is at better than its 
worst. The situation is exacerbated by the issue that you are doing stuff 
at (I believe) low temperature, for which the FPGA timing analyzers do 
not report temperature based delay info.

Sorry again for the un-intended insult.

Philip Freidin

Article: 8612
Subject: Call for Papers: FPL-98
From: nageldin@rhrk.uni-kl.de (Ulrich Nageldinger [Inf.])
Date: 13 Jan 1998 09:58:11 GMT
Links: << >>  << T >>  << A >>

_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
_|                                                                  _|
_|                                                                  _|
_|        _|_|_|_|  _|_|_|_|  _|       _|  _|_|_|_|  _|_|_|_|       _|
_|        _|        _|    _|  _|       _|  _|    _|  _|    _|       _|
_|        _|        _|    _|  _|           _|    _|  _|    _|       _|
_|        _|_|_|    _|_|_|_|  _|           _|_|_|_|  _|_|_|_|       _|
_|        _|        _|        _|                 _|  _|    _|       _|
_|        _|        _|        _|                 _|  _|    _|       _|
_|        _|        _|        _|_|_|_|     _|_|_|_|  _|_|_|_|       _|
_|                                                                  _|
_|                                                                  _|
_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
 
 
 
                              F P L '98
 
        E I G H T H  I N T E R N A T I O N A L  W O R K S H O P 
                                 on 
                FIELD PROGRAMMABLE LOGIC AND APPLICATIONS
 
_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
_|                                                                  _|
_|       August 31 - September 2, 1998  (Monday - Wednesday)        _|
_|                                                                  _|
_|             Tallinn Technical University , Estonia               _|
_|                                                                  _|
_|                     http://www.ttu.ee/fpl98                      _|
_|                                                                  _|
_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
 
 
 
                     C A L L  F O R  P A P E R S
 
 
_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
_|                                                                  _|
_|                    Paper Deadline March 7, 1998                  _|
_|                                                                  _|
_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
 
 
 
AIM: FROM TINKERTOY TO PARALLEL COMPUTING PARADIGM
 
The methodology of reconfigurable circuits and systems is evolving from 
tinkertoy approach to an: 
  Innovative Parallel Computing Paradigm which combines computing in
time with computing in space. The aim of this workshop is to bring
together workers from throughout the world for a wide ranging
discussion of all forms of field programmable logic, particularly
field programmable gate arrays and complex programmable logic devices,
and their applications. It is intended to discuss the increasing range
of device types, industrial applications, advanced design tool
development, research applications, novel system architectures and
educational experiences. The workshop will include regular
presentations, posters and discussion sessions, and it is expected
that most of the delegates will wish to make some contribution to one
or more of these. The workshop is the eighth in a series of workshops
which were held in Oxford (1991, 1993 and 1995), Vienna (1992), Prague
(1994), Darmstadt (1996) and London (1997).
 
 
CALL FOR CONTRIBUTIONS
 
Contributions are invited for regular presentation, poster and
discussion sessions. Prospective authors are invited to submit an
abstract of at least 500 words or a full paper of about 10 pages by 
7 March 1998 
to the Program Chairman. Please send also your full correspondence address,
including e-mail, and fax, and a list of (at most) 5 one-line
statements that best encapsulate the essence of your proposed
contribution. Submissions by e-mail to: abakus@informatik.uni-kl.de in
postscript format (ghostscript-compatible) are highly encouraged.
Notification of acceptance will be posted by 15 May 1998 and final
papers must be received by 15 June 1998 to guarantee distribution at
the workshop. The workshop proceedings will be published by
Springer. For the publication of accepted papers, an electronic as
well as a camera-ready version of the paper and the registration of at
least one author will be required. Potential exhibitors and tutorial
presenters are also invited to contact the Program Chairman. The
official conference language as well as the language of submissions
and accepted papers will be English.
 
 
SCOPE
 
Workshop topics include, but are not restricted to:
 
- Novel device, machine and system architectures
- New software and hardware development tools
- Run-time reconfigurable and partially reconfigurable designs
- High-level design and compilation research
- Industrial applications and experiences
- Trade-offs between devices, architectures and technologies 
- Benchmarking and profiling
- Applications from a wide variety of areas
- Reconfigurable custom computing machines
- Hardware/Software Co-Design using field programmable devices
- Evolvable and adaptable systems
- ASIC emulators, hardware modellers and compiled accelerators
- Fault modelling, testability methods and reliability issues
- Educational experiences and opportunities
- Reconfigurable accelerators and their applications
- Speed-up effects - survey and analysis
- Testing of reconfigurable circuits
 
 
GENERAL CHAIRMAN
 
Prof. Andres Keevallik
Tallinn Technical University
Raja 15 
Tallinn EE-0026 
Estonia 
Phone:  +372-6104440            
Fax:    +372-6202246
email:  akeev@cc.ttu.ee
http://www.ttu.ee/fpl98
 
 
PROGRAM CHAIRMAN
 
Prof. Reiner W. Hartenstein
University of Kaiserslautern
P. O. Box 3049  
D-67653 Kaiserslautern
Germany 
Phone:  +49 631 205-2606
Fax:    +49 631 205-2640
email:  hartenst@rhrk.uni-kl.de
http://xputers.informatik.uni-kl.de/FPL/index_fpl.html
 
 
PROGRAM COMMITTEE
 
Doug Amos, Altera, UK
Peter Athanas, Virginia Tech, USA
Samary Baranov, Ben Gurion U. Negev,Israel
Stephen Brown, U. of Toronto, CA
Klaus Buchenrieder, Siemens AG, FRG
Steven Casselman, VCC, USA
Bernard Courtois, INPG, Grenoble, France
Carl Ebeling, U. of Washington, USA
Norbert Fristacky, Slovak Technical U., SK
Manfred Glesner, TH Darmstadt, FRG
John Gray, Xilinx, UK
Herbert Gruenbacher, Vienna U., Austria
Reiner Hartenstein, U. of Kaiserslautern, FRG
Brad Hutchings, Brigham Young U., UAS
Udo Kebschull, U. of Tuebingen, FRG
Andres Keevallik, Tallinn Technical U., Estonia
Wayne Luk, Imperial College, UK
Patrick Lysaght, U. of Strathclyde, Scotland
Toshiaki Miyazaki, NTT Laboratories, Japan
Will Moore, Oxford U., UK
Wolfgang Nebel, U. of Oldenburg, FRG
Paolo Prinetto, Politecnico di Torino, Italy
Jonathan Rose, U. of Toronto, Canada
Zoran Salcic, U. of Auckland, New Zealand
Eduardo B. Scalvinoni, U. Autnoma de Madrid, Spain
Michal Servit, Czech T. U., Czech Republic
Marc Shand, Digital Systems Research Center, USA
Steve Trimberger, Xilinx, USA
 
 
LOCAL DETAILS
 
The workshop will be held from 1st to 3rd September, 1998 at the
National Library of Estonia near the center of Tallinn, the capital of
the Republic of Estonia. Tallinn lies in the Northern Europe, in the
northeast of the Baltic sea region. The good geographical location of
Tallinn has favored its becoming an important harbor and a center of
industry and trade.

The workshop is organized by Tallinn Technical University which is
situated about 5 km from the center of city.

 
FURTHER INFORMATION AND REGISTRATION
 
All the latest information about FPL'98 as well as registration info
can be accessed via a WWW-page.  The URL for this document is:
http://www.ttu.ee/fpl98
Article: 8613
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: dark7room@ix.netcom.com (Austin Franklin)
Date: Tue, 13 Jan 1998 10:06:11 -0500
Links: << >>  << T >>  << A >>
> and as stu pointed out, the designs are
> more portable,

I hear a lot about porting designs to other technologies, yet I 
personally have never done that....and...I don't know anyone who has 
either.  I'm sure SOMEONE SOMEWHERE has....but I certainly don't believe 
it is as prevelant as the proponents of portable design methodologies 
have like 'us' to believe...

And...why aren't schematics portable?  Mine are (for the most part...).  
I make hierarchical one bit symobols for elements like flops, I/O 
elements etc, and these are all that has to change from technology to 
technology.  I've developed an entire library of different combinations 
or elements and pin counts for I/O elements (say 16 bit bi-directional 
flop in, tri-state out...) and for registers and counters and tri-state 
buffers and muxes and...  Random logic is a bit more difficult, but you 
can do a global change on the symbol named AND3B2 to what ever the new 
technology name is...it really does't take that long.

Austin
Article: 8614
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: terry.harris@dial.pipex.com (Terry Harris)
Date: Tue, 13 Jan 1998 18:59:06 GMT
Links: << >>  << T >>  << A >>
dark7room@ix.netcom.com (Austin Franklin) wrote:

>> and as stu pointed out, the designs are
>> more portable,
>
>I hear a lot about porting designs to other technologies, yet I 
>personally have never done that....and...I don't know anyone who has 
>either.  I'm sure SOMEONE SOMEWHERE has....but I certainly don't believe 
>it is as prevelant as the proponents of portable design methodologies 
>have like 'us' to believe...

It can work, I 'ported' a recent CPLD design between Xilinx, Altera
and Lattice at design time. Identical source (unless you have to
resort to vendor specify design tweaks). Identical testbench with a
few ifdefs to work around tool idiosyncrasies. 

Being able to easily fit and test a design in parts from different
vendors gives a lot of insight into their architecture and your
design.


Cheers Terry...
Article: 8615
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: s_clubb@die.spammer.netcomuk.co.uk (Stuart Clubb)
Date: Tue, 13 Jan 1998 22:02:53 GMT
Links: << >>  << T >>  << A >>
On Tue, 13 Jan 1998 10:06:11 -0500, dark7room@ix.netcom.com (Austin
Franklin) wrote:

>I hear a lot about porting designs to other technologies, yet I 
>personally have never done that....and...I don't know anyone who has 

Have you ever had reason to want to do it?
Have you ever had a need to do it?
Have you ever thought : "Hell, there must be a better way."

>either.  I'm sure SOMEONE SOMEWHERE has....but I certainly don't believe 
>it is as prevelant as the proponents of portable design methodologies 
>have like 'us' to believe...

I see it almost all the time. HDL based customers who have specific
design requirements tend now to use HDL's and then pick the
architecture that's right for the job in hand. They base their
decision on:
1
Does the part do the job?
2
Is it available?
3
How much is it.

Answer yes to 1 and 2, and then you decide who wins on price. Payback
on your tools is usually rapid. I do not know many large programmable
logic users who does not have at least two vendors that they use as
appropriate. I've seen some with four or five.

Here's an example, a company last year recently switched over 300K+
gates from a mixture of Xilinx and Actel, to ORCA.

The evaluation of the FPGA architecture took about 3 weeks, and in
that time key elements like parallel 32 bit CRC's, complex state
machines, discrete FIFO's etc. were benchmarked. System clock speed is
66 MHz. Absolutely no schematics were used, although some
instantiation was done to help in the XOR term generation (because
ORCA does an 11 input cascaded XOR in one level of logic with use of a
PFU gate). This was kept heirarchical to ensure swift transition
should ORCA have crapped out. Macro-block generators such as Lucent's
SCUBA were used to generate device specific blocks such as ROM's and
(DP)RAM's for tables and FIFOs and instantiated as components.
Eventually a new prototype board was up and running in around 5 weeks
after the decision had been made to convert to ORCA.

Design flow was all VHDL with simulation pre and post synthesis & P&R.

So in this design...

Plus sides of HDL design methodology
------------------------------------
Customer is free to find a solution that meets his needs. (Performance
and power consumption were key)
Customer is not beholden to one manufacturer.
Customer is not beholden to one manufacturer. (needs saying twice)
Design manageability within a large team is improved.
Speed of simulation at a more abstract level.
Testbenches that can be interactive and self documenting.
Design change flexibility and manageability.
Time to board, time to market.

Down sides of HDL design methodology
------------------------------------
Good QOR tools have a higher purchase price than schematics. But IMHO
a lower cost of ownership when the above plus points are considered.
Engineers who don't know HDL feel threatened with new technology.
Sometimes not suitable where you really push the edge, but this is
becoming very much less of an issue.
Little benefit at low density.
Sometimes tricky in syntax and synthesis implementation, but that's
why we have stepping simulators isn't it?

OK, so this wasn't what many would consider a "normal" design, but if
you believe the marketing hype (translation : Bullshit), we'll all be
able to use 1M gate FPGAs at $1 per 5K gates by next year. Therefore
we'll all need higher level tools. Perhaps even moving to the higher
level of system block (schematic?) visualisation before design task
assignment to multiple engineers?

Stuart
--
For Email remove "die.spammer." from the address
Article: 8616
Subject: Implementing Altera FIFOs without EABs
From: Greg Hoffman <hoffman@adichi.com>
Date: Tue, 13 Jan 1998 18:54:54 -0600
Links: << >>  << T >>  << A >>
I'd like to know if there's any way, using a 10K50 part, to compile a
CSFIFO block into the part and not let it use the EABs. What I need to
do is generate a register-only implementation of the FIFO for later
compatibility with an ASIC process.

Also, is there any way to generate a VHDL/EDIF/Verilog output file
without all of those delay cells?

Thanks,
Greg Hoffman
hoffman@adichi.com
Article: 8617
Subject: Altera and Xilinx
From: GDBOT@CCGATE.HAC.COM (GUSTAVO D. BOTVINIKOFF)
Date: Tue, 13 Jan 1998 17:14:24 -0800
Links: << >>  << T >>  << A >>
1) What are the main differences between Xilinx and Altera FPGAs?

2) Are there features in which Xilinx or Altera excells?

3) Are there specific applications where a specific vendor is recommended?

4) Are there articles in professional publications which compare different
FPGA manufacturers? Do you know of any in particular?

Dan
Article: 8618
Subject: Xilinx 4000E Series Ram Problem
From: ryan@amaroq.com (Ryan Herbst)
Date: 14 Jan 1998 00:21:16 -0800
Links: << >>  << T >>  << A >>

It has come to my attention that the 4000E series xilinx
have a series problem when it comes to using the ram elements.

It is my understanding that if the write clock signal is held high
for more than a millisecond, permanent damage to the device can be
caused. This is suppose to be true even if only a single ram device 
is held in this state. 

My only question is: 

1. Is it possible to avoid this burn out if the write enable signal
   is held low if a clock failure is detected, or is a gate on the
   clock signal, not a preffered practice, required?

I am still amazed that this is possible. I never thought a simple
clock failure could possibly cause physical damage to a device.


-- 
Ryan Herbst                          ryan@amaroq.com       KF6CDD
http://www.amaroq.com/ryan/          rherbst@verilink.com
PGP Public Key: ftp://ftp.amaroq.com/rherbst.asc
GCS GE GS d-- -p+ c++(++++) l+++ u++ s--/-- n--(---) h-- !f g+ t+ 
Article: 8619
Subject: VLSI Design of an FPGA
From: Mark Willey <willey@etla.ml.org>
Date: 14 Jan 1998 08:38:26 GMT
Links: << >>  << T >>  << A >>
We are looking for some information about the way SRAM-based programming is
done in FPGA designs.  Specifically, what sorts of circuit design
structures are used to create the programming cells, how are they given the
programming data, and what is the organization and distribution of the
cells throughout the chip?  ie, is there typically a bank of SRAM on chip
that is routed to each programmable element, or is the memory element
adjacent to or a part of the programmable element?  We are looking for VLSI
design information (CMOS process) or any pointers to books, papers, etc
that might have this sort of information.  Most of the papers that we have
cover the various types of CLBs and some cover the interconnect, but we
have found very little containing specific VLSI implementation details.

We welcome any advice, pointers, or communication on this aspect, or any
aspect of the design.

Sincerely,
Mark Willey (willey@etla.ml.org)
Gun Unsal (unsal@leland.stanford.edu)

If you want to know:
We are doing a custom VLSI design of an FPGA using a new type of CLB which
we believe has never been implemented in silicon before.  This device will
be fabricated and tested.  The CLB is described in a paper by Chih-Chang
Lin, Malgorzata Marek-Sadowska, and Duane Gatlin, "On Designing Universal
Logic Blocks and Their Application to FPGA Design", IEEE TRANSACTIONS ON
COMPUTER-AIDED DEISGN OF INTEGRATED CIRCUITS AND SYSTEMS.  VOL. 16, No. 5,
MAY 1997.  This is an academic project and will have full disclosure.

Article: 8620
Subject: Re: Asynchronous square root.
From: z80@ds.com (Peter)
Date: Wed, 14 Jan 1998 10:58:20 GMT
Links: << >>  << T >>  << A >>

Impressive.

But unless I am wrong, this is based on the Newton-Raphson method
((N/a)+a)/2 with a fixed number of iterations. That is what the
unrolled loop is about. So the accuracy depends strongly on the
initial guess.


Peter.

Return address is invalid to help stop junk mail.
E-mail replies to z80@digiXYZserve.com but
remove the XYZ.
Article: 8621
Subject: Foundation or Workview Office?
From: Nikos <nmo@teletel.gr>
Date: Wed, 14 Jan 1998 13:02:17 +0200
Links: << >>  << T >>  << A >>
Hi all.

Has anyone used both Xilinx Foundation class tools and Viewlogic
Workview Office? Which one do you prefer? I have used the latter
but was not able to evaluate Foundation so your help will be 
appreciated.

Please answer with e-mail to : nmo@teletel.gr

Thank you,

Nikos.
Article: 8622
Subject: Jam - Anyone using it ?
From: Billy Bagshaw <bill@highwater.co.uk>
Date: Wed, 14 Jan 1998 11:57:54 +0000
Links: << >>  << T >>  << A >>
Hi all,
    I'm looking at Jam. Has anyone any advice. I downloaded the kit but
it would not decompress. (I've fallen at the first hurdle).

Any comments wecome.

Billy Bagshaw
bill@highwater.co.uk


Article: 8623
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: dark7room@ix.netcom.com (Austin Franklin)
Date: Wed, 14 Jan 1998 09:07:37 -0500
Links: << >>  << T >>  << A >>
> >I hear a lot about porting designs to other technologies, yet I 
> >personally have never done that....and...I don't know anyone who has 
> 
> Have you ever had reason to want to do it?
> Have you ever had a need to do it?
> Have you ever thought : "Hell, there must be a better way."

No to all three ;-)  The 'better way' is to understand the problem at 
hand and pick the correct tools and parts to meet the task before hand.
 
> >either.  I'm sure SOMEONE SOMEWHERE has....but I certainly don't believe 
> >it is as prevelant as the proponents of portable design methodologies 
> >have like 'us' to believe...
> 
> I see it almost all the time.

12 years of ASIC/FPGA consulting....100+ designs, 47 customers, never 
seen it.

> HDL based customers who have specific
> design requirements tend now to use HDL's and then pick the
> architecture that's right for the job in hand. They base their
> decision on:

Whether the design is HDL or schematic based does not mean it does or 
doesn't have specific design requirements.

<snip> 

> <snip> System clock speed is
> 66 MHz.

One can heavily pipeline a design and achieve higher clock speeds, and 
this is generally the technique with any FPGA.  66MHz usually means only 
one level of logic between flops, and very localized routing.  Usually, 
the entire design does no run at 66MHz, as there are usually many multi-
cycle paths.

> Absolutely no schematics were used, although some
> instantiation was done to help in the XOR term generation (because
> ORCA does an 11 input cascaded XOR in one level of logic with use of a
> PFU gate).

Whether schematic or HDL there will always be device specific elements 
that should be understood and will require some special attention.

> This was kept heirarchical to ensure swift transition
> should ORCA have crapped out. Macro-block generators such as Lucent's
> SCUBA were used to generate device specific blocks such as ROM's and
> (DP)RAM's for tables and FIFOs and instantiated as components.

Schematics can (and should) be done heirarchically, and high level 
'macros' can (and should) be used in schematics too.

<snip>

> So in this design...
> 
> Plus sides of HDL design methodology
> ------------------------------------
> Customer is free to find a solution that meets his needs. (Performance
> and power consumption were key)

And why is this not true when using schematics?

> Customer is not beholden to one manufacturer.
> Customer is not beholden to one manufacturer. (needs saying twice)

And also why is this not true when using schematics?

> Design manageability within a large team is improved.

Same?

> Speed of simulation at a more abstract level.

Don't quite know what you mean by this...

> Testbenches that can be interactive and self documenting.
> Design change flexibility and manageability.
> Time to board, time to market.

I use VHDL to provide bus functional models, and in some cases, an entire 
simulation environment, whether my design is done in entirely schematic, 
HDL or some combination of both...  ANY design can be done poorly, or 
well, depending on the person doing it, whether it is done in HDL or 
schematic.  I have seen designs that were done in HDL that were done so 
miserably, as I have seen schematics done just as badly.  I have also 
seen very very well done HDL and schematics.  That doesn't make one 
better than the other, it makes one implementer better than the other 
though...

> Down sides of HDL design methodology
> ------------------------------------
> Good QOR tools have a higher purchase price than schematics. But IMHO
> a lower cost of ownership when the above plus points are considered.

Agreed.

> Engineers who don't know HDL feel threatened with new technology.

I have not see this to be the case.

> Sometimes not suitable where you really push the edge, but this is
> becoming very much less of an issue.

Agreed.

<snip>

> Therefore
> we'll all need higher level tools. Perhaps even moving to the higher
> level of system block (schematic?) visualisation before design task
> assignment to multiple engineers?

But anyone I know who is worth their weight does their designs this way 
today....  Schematic or HDL has nothing to do with partitioning the 
design so multiple people can work on it simultaneously.

I'm really confused as to why you believe the design methodology you 
state is unique to HDL.  There is not one aspect of it that does not 
apply to schematic design entry too.

Personally, I believe data path is far better in schematic than HDL.  
There is NO way of documenting data path in HDL so it is more 
understandable than schematic.  HDL is certainly better for state 
machines and usually for random logic, I have no problem with that.

I have had to convert HDL blocks into schematics due to speed and density 
requirements.  Until there is a way of providing feedback from the place 
and route tools to the HDL compiler, there is no way the HDL compiler can 
know how to partition and implement the design to make timing optimally.

One major problem I have had with HDLs is they are NOT consistent in what 
they produce as output.  I do not want to play guessing games with the 
compiler.

I believe a good engineer has a good toolbox, consisting of many design 
methodologies, and a very good understanding of their use.  S/he also has 
to have a good understanding of the problem at hand, and the architecture 
benefits/problems with the components involved.  Unless you want to rely 
on dumb luck, that is.

Austin Franklin
darkroom@ix.netcom.com



Article: 8624
Subject: Re: Foundation or Workview Office?
From: madarass@cats.ucsc.edu (Rita Madarassy)
Date: 14 Jan 1998 16:01:01 GMT
Links: << >>  << T >>  << A >>
In article <34BC9B39.4AA2@teletel.gr>, Nikos  <nmo@teletel.gr> wrote:
>Hi all.
>
>Has anyone used both Xilinx Foundation class tools and Viewlogic
>Workview Office? Which one do you prefer? I have used the latter
>but was not able to evaluate Foundation so your help will be 
>appreciated.
>


I have used Foundation probably as oftern as Workview Office (Powerview
6.0 as well). If you are mainly concerned about targetting Xilinx
devices Foundation is definitely the way to go. The VHDL-Schematic
Interface is one of the best I have seen (the best being Mentor Graphics).
Soon Foundation will have Synopsys FPGA Express integrated in its 
package making it an even more ambitious tool.
The only problem with foundation is its simulator. Viewsim has the edge
but no by a wide margin.






>Please answer with e-mail to : nmo@teletel.gr
>
>Thank you,
>
>Nikos.




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