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 8100

Article: 8100
Subject: Re: What is the difference between CPLD and FPGA ?
From: Tim Warland <twarland@NOSPAMnortel.ca>
Date: Mon, 17 Nov 1997 16:15:51 -0500
Links: << >>  << T >>  << A >>
Jean-Paul Ricaud wrote:
> 
> What is the difference between CPLD and FPGA 

A CPLD is a complex programmable logic device of which
the FPGA - Field programmabel gate array is a subset.

the CPLD makes logic with huge sum of products _arrays_
which drive a few registers.

FPGAs generate logic functions through small clusters
of look-up tables each of which drives its own register.

CPLDs are typically built from ROM type processes which
means they retain their "program" when power is turned off.

FPGAs are typically built from SRAM processes which 
means power maintains the program.

CPLDs are better for wide equations
FPGAs are better for pipelined processes

CPLDs are small and quick for wide equations
FPGAs are huge and quickish for sequential processes

etc.
Tim.
-- 
Strong words softly spoken.

My opinions != Nortel's opinion.
Article: 8101
Subject: Re: Xilinx Logiblox in Synopsys
From: Terry Graessle <graessle@vlsi.gsfc.nasa.gov>
Date: Mon, 17 Nov 1997 16:29:59 -0500
Links: << >>  << T >>  << A >>
Jens-Peter Kaps wrote:
> 
> Hi,
> 
> I'm using Synopsys in school and want to use the Xilinx Logiblox. How can
> simulate them? Currently I create them with the M1 software on a Windows
> machine and export the edn file. This file I include in Synopsys which
> runs on a Unix machine. I tell Synopsys not to touch these files. That
> should work fine, but also causes some trouble. It seems to me that the
> Logiblox are not implemented at all. Simulation I can do currently only

To simulate before synthesis, you need to include the path to the
library in your .synopsys_vss.setup file.  The line should look
something like this:

logiblox   : $XILINX/synopsys/libraries/sim/lib/logiblox

The logiblox tool should output a behavioral model with a .vhd
extension.  Make sure you select "Synopsys" as the Vendor name; and 
"Behavioral VHDL netlist" as the Simulation Netlist in the Setup window.

Add the component definition and instantiation of the logiblox module to
your vhdl code, compile and simulate.  

For synthesis, you need to put a set_dont_touch property on each
component that you instantiate.  You will still get warnings about
"Unable to resolve reference ..." and "Can't find the design ..." but
you can ignore these.  

-- 
Terry L. Graessle         
Lockheed Martin - Space Mission Systems
NASA Code 521/ Microelectronics Systems Branch
graessle@vlsi.gsfc.nasa.gov
(301) 286-9698
Article: 8102
Subject: Design Resource
From: deepka <deepka@best.com>
Date: Mon, 17 Nov 1997 21:50:18 +0000
Links: << >>  << T >>  << A >>
Check out CircuitOnline...Searchable directory of services designed for
the electronics/semiconductor design and manufacturing industry:
http://www.circuitonline.com
Article: 8103
Subject: Re: Register Intensive Designs and Dynamically Reconfigurable FPGAs
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 17 Nov 1997 18:12:38 -0800
Links: << >>  << T >>  << A >>
I don't have an answer to the original question, but I want to clarify
some possible confusion created by Markus' answer:

Yes all FPGAS are reconfigurable, even Atmel's, but not Actel's and
Quicklogic's antifuse devices.
XC6200 has a unique ( I hate that word, but here it is applicable )
feature, not found in any other FPGA:
You can directly write to and read from any flip-flop or register in the
array. The array is memory-mapped and directly addressable via a 32-bit
bus. That's how the devices ( XC6016 and XC6064 ) can be used as
co-processors, even without any I/O. You just shoot a configuration and
data into it, let it crunch, then read the result back via the same
port. The configuration is also "garbage-tolerant" since there can never
be internal contention, all metal lines are unidirectional.
There is no other part with these features.

Peter Alfke, Xilinx Applications

Article: 8104
Subject: Re: What is the difference between CPLD and FPGA ?
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 17 Nov 1997 18:23:36 -0800
Links: << >>  << T >>  << A >>
Tim Warland wrote:

> A CPLD is a complex programmable logic device of which
> the FPGA - Field programmabel gate array is a subset.
>  

This is not the generally accepted opinion.

Most engineers, editors and marketeers agree that CPLD are PAL-derived,
with an AND-OR structure, and FPGAs are not a subset of this species.
FPGAs (SRAM or antifuse-based) are look-up-table or multiplexer-based,
and form a separate species.

For non-technical reasons, Altera used to call their FLEX8K and 10K
devices "CPLDs", but the community considers them FPGAs. ( "If it walks
like a duck, and sounds like a duck, and smells like a duck...")

CPLD and EPLD is often used interchangably, but when they are erasable
or even Flash-based, then it may be more meaningful to call them CPLDs.

Religious wars have been fought over more insignificant
distinctions......

Peter Alfke

Article: 8105
Subject: M1 router crash
From: "E.M. Shattock" <""@see sig.>
Date: Mon, 17 Nov 1997 18:53:09 -0800
Links: << >>  << T >>  << A >>
I'm using M1 (ver. M1.3.7) on an XC4008E. For this particular
design, the software generally crashes (in LIBX4KDY.DLL) just
after completing a route. The problem seems to be related to
my timing constraints in the UCF file - if I remove all (or
possibly some) of the constraints the design will complete
normally.
I'm using win95, on an Intel motherboard, with 32Mbytes. Has
anyone else seen this? Needless to say, Xilinx tech support
is keeping quiet.

Thanks

Evan

----------------------------------------------------------------
-- E.M. Shattock                                              --
-- Riverside Machines Ltd.                                    --
-- 19 De Freville Ave.     tel:   (+44) 1223 566083           --
-- Cambridge CB4 1HW       fax:   (+44) 1223 566983           --
-- UK                      mailto:ems@riverside-machines.com  -- 
----------------------------------------------------------------

Article: 8106
Subject: Re: Register Intensive Designs and Dynamically Reconfigurable FPGAs
From: "Richard B. Katz" <stellare_nospam@erols.com>
Date: 18 Nov 1997 03:24:02 GMT
Links: << >>  << T >>  << A >>

Peter Alfke <peter@xilinx.com> wrote in article
<3470F8F9.6111872D@xilinx.com>...
> I don't have an answer to the original question, but I want to clarify
> some possible confusion created by Markus' answer:
> 
> Yes all FPGAS are reconfigurable, even Atmel's, but not Actel's and
> Quicklogic's antifuse devices.
> XC6200 has a unique ( I hate that word, but here it is applicable )
> feature, not found in any other FPGA:
> You can directly write to and read from any flip-flop or register in the
> array. The array is memory-mapped and directly addressable via a 32-bit
> bus. That's how the devices ( XC6016 and XC6064 ) can be used as
> co-processors, even without any I/O. You just shoot a configuration and
> data into it, let it crunch, then read the result back via the same
> port. The configuration is also "garbage-tolerant" since there can never
> be internal contention, all metal lines are unidirectional.
> There is no other part with these features.
> 
> Peter Alfke, Xilinx Applications
> 

hi pete,

well, i like the phrase, 'garbage tolerant' and obviously the concept to
prevent internal contention.  what might be handy is an external pin to
lock the bidirectional i/o pin configurations during a chip logic
re-configuration to prevent external contention (i.e., turning an input
into an output and having a bus fight) in case of a system crash and an
erroneous 'garbage load'.

any other devices out there garbage tolerant?  is this a xilinx
trade-marked name? :-)

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

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
-------------------------------------------------------------

 
Article: 8107
Subject: Re: Register Intensive Designs and Dynamically Reconfigurable FPGAs
From: leberech@informatik.tu-muenchen.de (Markus Leberecht)
Date: 18 Nov 1997 11:19:46 GMT
Links: << >>  << T >>  << A >>
In article <3470B1C5.2781E494@nospamnortel.ca>,
	Tim Warland <twarland@NOSPAMnortel.ca> writes:
> I'm a little confused as to what you're saying.
>    1) FPGAs are register intensive

Of course. 

>    2) The XC6200 is a regular (ie reconfigurable device) which
>     is designed to interface to a CPU.

... which additionally means that you can reconfigure the interconnect
matrix by this as well as read and write the content of each CLB's 
flipflop through this I/F.

>    3) Most FPGAs are reconfigurable with the exception of Atmel
>      which are write once.

Yes, but not dynamically, in-the-running-system reconfigurable, and 
they usually do not allow to read and write register content through
the configuration port.

> In an FPGA the registers must be connected
> to the outside world (pins) through programable connections
> within the device.  

This is not the only way in the XC6200 which also allows you to access
these through the CPU interface.

> By default the registers are not connected to
> the pins.  You could "program" the fpga to connect groups of the 
> registers to the CPU bus but this would take many reconfigurations
> as there are way more registers than pins.  

No, this wasn't what I meant. Since the on-chip infrastructure 
for accessing the registers is already available through the CPU
interface in the XC6200, we'd like to use it for exactly this 
task. But then the question remains: How do you properly and
seamlessly design for such an architecture?

> the connections can not be
> reached independantly (yet).

They can, at least the Xilinx data sheet for the XC6200 series 
says so. And I know of another vendor, Atmel, who claimed to have
the same capability for their 6000 series, albeit through a much
less comfortable interface. 

> The port you are probably interested in is the boundary scan port.
> (I encourage you to refer to Boundary Scan and BIST literature).  
> This allows you to run a pattern through all the registers in a
> device (not limited to FPGAs) to check the integrety of the
> device.

Boundary scan ports are (from what I know) - due to their serial 
nature - much too slow to address our issues. Still, the original
question would remain: How does one integrate such stuff in a 
proper design flow such that one could simulate and verify accessing 
the registers through the scan port.

> The "compilers" from the FPGA manufacturers contain the timing info
> for delay through a register cell and the delay of the programmable
> interconnect.  You can use these tools to generate a timing annotated
> VHDL netlist which you can simulate to verify performance.

But as far as I know, no single tool is able to model the timing 
behaviour of the synthesized logic as well as deliver an appropriate
functional or timing model for the register access through the dynamic
reconfiguration interface, be it CPU-like, boundary scan, or any 
way else.


Maybe I have to rephrase the question in order to make myself more 
understandable. The situation is as follows:

- We have an upcoming design that is *very* register intensive, meaning
  CPU-like registers that are supposed to me memory-mapped in the 
  final design. Thus, there are probably tons of datapaths to a number
  of external pins in this design. Furthermore, a bus interface would 
  have to be designed.

- We have to use FPGAs for the physical implementation.

- A VHDL more-or-less behavioural model with a logic synthesis tool would 
  be the easiest way for us to convert the idea into a circuit.


Now, the first and obvious option is: 

- Let's take whatever high-density FPGA there is, design the stuff, and
  it runs (hopefully).

The drawback of this solution is, however, that probably a lot of area
is wasted for the simple (complexity-wise) yet important functionality
of accessing the registers. And we'd like to use any area we can get for
the synthesized logic as we'd be able to extend the number of some 
functionally identical modules to the maximum possible. So maybe this is 
the better approach:

- Choose a *dynamically* reconfigurable FPGA (like the XC6200, for 
  instance). They do enable adaptive hardware, and for this it is 
  essential that not only the interconnect matrix and the CLB functions
  are programmable. They also allow the reading and writing of 
  register contents and offer ways of signaling this to CLBs.
  (I am normally not in the synthesis community but I assumed this 
  to be known by those who have already worked with FPGAs like these.)

- As the read/write interface to the registers already exists (and so
  does the internal infrastructure which I had named datapaths), it
  should be possible to use the dynamic-reconfiguration interface for
  exactly this task. This seems to be especially appropriate with those
  FPGAs where the reconfiguration interface is CPU-like.

- The rest of the logic would have to be implemented the usual way, 
  with some signals crossing the barrier between the built-in reconf.
  interface and the synthesized logic.

And now again the question: Is there any good / seamless / only 
partially painful design flow that enables us to use a more-or-less
behavioural VHDL model? Signals going from the internal dynamic 
reconf. i/f are probably the most difficult.

Any ideas? Thanks again for your help 


--
-----------------------------------------------------------------------
Markus Leberecht, Ph.D. student, TU Muenchen, Germany      #####  #####
www  : http://wwwbode.informatik.tu-muenchen.de/~leberech/   # #  # # #
phone: +49-89-289-25357     fax: +49-89-289-28232            # #### # #

Article: 8108
Subject: Electronics Directory
From: deepka <deepka@best.com>
Date: Tue, 18 Nov 1997 11:47:03 +0000
Links: << >>  << T >>  << A >>
Check out Circuitonline...Searchable directory of services designed for
the electronics/semiconductor design and manufacturing industry:
http://www.circuitonline.com
CAD Tools, IC Design Servicec, VLSI Research, FPGA, Meagacells,
Assembly, Board, Wafer Processing...
Article: 8109
Subject: Re: Register Intensive Designs and Dynamically Reconfigurable FPGAs
From: leberech@informatik.tu-muenchen.de (Markus Leberecht)
Date: 18 Nov 1997 15:29:58 GMT
Links: << >>  << T >>  << A >>
In article <3471EE5B.59CC@no.spam>,
	"E.M. Shattock" <@no.spam> writes:
> there's a pretty amusing article in this week's (15th november '97)
> new scientist. a 'researcher' loaded random configurations into
> a device (he doesn't say which one, but it's probably a xilinx XC4003)

It's actually again an XC6200 which was chosen because complete 
populations could be tested easily within a very short time, 
just reprogramming the circuit in a much easier way through the
CPU interface.

> in an attempt to produce a tone discriminator. by selecting
> configurations according to how successful they were, and 'breeding'
> these configurations (ie. randomly swapping bits between
> configurations), he eventually, after 3500 generations, found a
> configuration that successfully discriminated between a 1KHz and a 
> 10KHz tone. the circuit is unclocked. the cover describes
> this circuit as 'smart, strange, and beyond our understanding'.
> 
> according to the article, he produced this solution with "fewer
> than one-tenth of the components that a human designer would
> have used" (he appears to have used 37 cells out of the 100).
> 
> but...
> 1   the circuit works only over a 10 degrees C range
> 2   it only works on one device
> 3   he doesn't seem to have checked the voltage range over which
>     it works
> 4   5 of the cells are not logically connected to the others.
>     but the circuit doesn't work without these cells.
> 5   and so on...
> 
> apparently, motorola is interested in the work.

You can read the whole article at 

http://www.newscientist.com/ns/971115/features.html

--
-----------------------------------------------------------------------
Markus Leberecht, Ph.D. student, TU Muenchen, Germany      #####  #####
www  : http://wwwbode.informatik.tu-muenchen.de/~leberech/   # #  # # #
phone: +49-89-289-25357     fax: +49-89-289-28232            # #### # #

Article: 8110
Subject: Re: Register Intensive Designs and Dynamically Reconfigurable FPGAs
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 18 Nov 1997 09:26:06 -0800
Links: << >>  << T >>  << A >>
Richard B. Katz wrote:

>  what might be handy is an external pin to
> lock the bidirectional i/o pin configurations

Exists on every XC4000. You can configure any pin to be the input to the
Global-Three-State (GTS) net.

> during a chip logic re-configuration to prevent external contention
> (i.e., turning an input into an output and having a bus fight) in case
> of a system crash and an
> erroneous 'garbage load'.
>
> Any other devices out there garbage tolerant?

No, the XC6200 family cornered the market.

Peter Alfke, Xilinx Applications
 

Article: 8111
Subject: Altera Flash EPX880 devices
From: Rick Filipkewicz <rick@xxxxz.co.uk>
Date: Tue, 18 Nov 1997 18:44:46 +0000
Links: << >>  << T >>  << A >>
We have been using these - now obsolete - devices for some time and
have just scoured the world for 40 or so parts for the last batch of
board using them before we change FPGA families. We seem to be having
problems with some of these parts which don't seem to configure
the SRAM properly (we don't use the Flash). In fact the problems seem to
relate to one particular date code - 9621. Any one else out there had
any problems with these parts ?
-- 

_________________________________________________________________________

 Dr. Richard Filipkiewicz 	phone: +44 171 700 3301
 Algorithmics Ltd.		fax: +44 171 700 3400
 3 Drayton Park			email: rick@algor.co.uk
 London N5 1NU
 England
Article: 8112
Subject: Re: Register Intensive Designs and Dynamically Reconfigurable FPGAs
From: Richard.Radix@BTinternet.com (Richard Dungan)
Date: Tue, 18 Nov 1997 18:54:52 GMT
Links: << >>  << T >>  << A >>
"E.M. Shattock" <@no.spam> wrote:

>there's a pretty amusing article in this week's (15th november '97)
>new scientist.

[snip to appease my ISP]

Yes, I read this article as well. I hope it's a case of an
over-simplification by the magazine.

If it's all true and seriously intended then I'm worried.

Richard
------------Richard Dungan-------------
Radix Electronic Designs, Orpington, UK
  Email: Richard.Radix@BTinternet.com
---------------------------------------
Unsolicited Commercial Email is not welcome.
All email from previously unknown or invalid
addresses which contain financial references
will be automatically killed.
Article: 8113
Subject: Re: Register Intensive Designs and Dynamically Reconfigurable FPGAs
From: "E.M. Shattock" <@no.spam>
Date: Tue, 18 Nov 1997 11:36:59 -0800
Links: << >>  << T >>  << A >>
there's a pretty amusing article in this week's (15th november '97)
new scientist. a 'researcher' loaded random configurations into
a device (he doesn't say which one, but it's probably a xilinx XC4003)
in an attempt to produce a tone discriminator. by selecting
configurations according to how successful they were, and 'breeding'
these configurations (ie. randomly swapping bits between
configurations), he eventually, after 3500 generations, found a
configuration that successfully discriminated between a 1KHz and a 
10KHz tone. the circuit is unclocked. the cover describes
this circuit as 'smart, strange, and beyond our understanding'.

according to the article, he produced this solution with "fewer
than one-tenth of the components that a human designer would
have used" (he appears to have used 37 cells out of the 100).

but...
1   the circuit works only over a 10 degrees C range
2   it only works on one device
3   he doesn't seem to have checked the voltage range over which
    it works
4   5 of the cells are not logically connected to the others.
    but the circuit doesn't work without these cells.
5   and so on...

apparently, motorola is interested in the work.

evan

----------------------------------------------------------------
-- E.M. Shattock                                              --
-- Riverside Machines Ltd.                                    --
-- 19 De Freville Ave.     tel:   (+44) 1223 566083           --
-- Cambridge CB4 1HW       fax:   (+44) 1223 566983           --
-- UK                      mailto:ems@riverside-machines.com  -- 
----------------------------------------------------------------

Article: 8114
Subject: Free verilog models , examples
From: rajesh@comit.com
Date: 18 Nov 1997 19:52:13 GMT
Links: << >>  << T >>  << A >>
Hi All



	I want to add verilog models, examples to Verilog FAQ.

Please send them to me rajesh@comit.com



	Next release of FAQ will carry them. I will keep on adding 

examples as soon as I get them. It will help verilog learners

and students a lot.



	Thanks for your cooperation.

	Regards

	Rajesh



Verilog FAQ page : http://www.comit.com/~rajesh/verilog/faq/alt_FAQ.html






--

Posted using Reference.COM                         http://www.reference.com
Browse, Search and Post         Usenet and Mailing list Archive and Catalog.

Sift, Inc. accepts no responsibility for the content of this posting.
Article: 8115
Subject: Re: XC: bitfile to ASCII file
From: Bob Walance <bwalance@harris.com>
Date: Tue, 18 Nov 1997 14:39:30 -0800
Links: << >>  << T >>  << A >>
Laurent Gauch wrote:
> 
> Help me !
> 
> I will convert a bitfile to a user-readable ASCII without use the
> Makebits. How do you make?
> 
> Thank you for you help.
> 
> Laurent Gauch
> 
>             \\://
>             (o -)
> ---------ooO-(_)-Ooo---------------------
> Laurent Gauch
> Ecole d'Ingenieurs du Valais (EIV)
> Route du Rawyl 47
> CH - 1950 Sion
> 
> tel:++41 27 / 32 43 363
> fax:++41 27 / 32 43 315
> E-mail: laurent.gauch@eiv.vsnet.ch
> http://www.vsnet.ch:80/eiv/electro/micro/
>   .oooO
>   (   )   Oooo.
> ---\ (----(   )--------------------------
>     \_)    ) /
>           (_/

You can create various hex file formats with MAKEPROM, but you'll still
need to run MAKEBITS.
Article: 8116
Subject: Re: ? State Machine Design
From: z80@ds.com (Peter)
Date: Wed, 19 Nov 1997 10:14:45 GMT
Links: << >>  << T >>  << A >>
You need a state machine compiler. CUPL has a good one, and I believe
one now comes with the free PALASM. You can then simply type in
statements like

 If present_state=6 and input1=1 goto ...
 etc

One can do state machines by hand. Plenty of books have been written
on this. But it is time-consuming, and the resulting circuit is
usually incomprehensible.

>
>I`m looking for a State Machine 
>basics material in Internet.
>
>Could you help me, please?


Peter.

Return address is invalid to help stop junk mail.
E-mail replies to z80@digiXYZserve.com but
remove the XYZ.
Article: 8117
Subject: Re: Register Intensive Designs and Dynamically Reconfigurable FPGAs
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Wed, 19 Nov 1997 10:26:51 -0500
Links: << >>  << T >>  << A >>
> 
> >    2) The XC6200 is a regular (ie reconfigurable device) which
> >     is designed to interface to a CPU.
> 
Regular and reconfigurable have nothing to do with each other.  THe
Actel 1020 is a regular array (an array of identical elements) but it is
in no way reconfigurable, as it is anti-fuse (one time programmable)


> 
> >    3) Most FPGAs are reconfigurable with the exception of Atmel
> >      which are write once.
> 

Patently untrue.  The Atmel FPGAs are SRAM based devices, and were the
first device to support *partial* reconfiguration (partial
reconfiguration allows part of the FPGA program to be changed while the
circuit in the rest of the device is operating).  I think you may have
meant to say Actel, which are antifuse one time programmable devices.

> Yes, but not dynamically, in-the-running-system reconfigurable, and
> they usually do not allow to read and write register content through
> the configuration port.
> 
True, the Atmel AT6K, AT40K, the Xilinx 6200, and the motorola device
are the only ones that share the partial reconfiguration distinction at
this time.  The Xilinx 6200 is unique in that the CLB configurations are
memory mapped and accessible using an interface specifically designed to
interface a CPU.  The Atmel 6k device uses a protocol of rectangular
window parameters in the configuration bitstream to describe the area to
be reconfigured.  Most of the pins on the Atmel configuration port
become user i/o when configuration is complete.

> > In an FPGA the registers must be connected
> > to the outside world (pins) through programable connections
> > within the device.
> 
> This is not the only way in the XC6200 which also allows you to access
> these through the CPU interface.
> 
The 6200 is unique in this regard.  It is a neat feature...if you are
going to be tightly coupled to a cpu.

> > By default the registers are not connected to
> > the pins.  You could "program" the fpga to connect groups of the
> > registers to the CPU bus but this would take many reconfigurations
> > as there are way more registers than pins.
> 
> No, this wasn't what I meant. Since the on-chip infrastructure
> for accessing the registers is already available through the CPU
> interface in the XC6200, we'd like to use it for exactly this
> task. But then the question remains: How do you properly and
> seamlessly design for such an architecture?
> 
> > the connections can not be
> > reached independantly (yet).
> 
> They can, at least the Xilinx data sheet for the XC6200 series
> says so. And I know of another vendor, Atmel, who claimed to have
> the same capability for their 6000 series, albeit through a much
> less comfortable interface.
> 
The xilinx mechansm for accessing accessing register content is alot
cleaner than the Atmel.  It should be, seeing the 6200 was designed
specifically to do this and is newer by more than half a decade (The
Atmel 6K is the stepchild of the Concurrent Logic device designed in the
late '80s. The AT6K's tenure on the market is actually rather
remarkable, as it still competes for speed and density with many of the
new FPGAs).  The Atmel 6K does not give direct access to the register
state.  State is obtainable by doing a partial reconfiguration to wire
the register output to a pin where it can be observed (done with the
clock turned off so that register states can't change).  Register state
is preserved in the At6k when cells are reconfigured.  Writing the Atmel
register state via the configuration port is done by reconfiguring the
input to the register to a constant, clocking the register, then putting
the configuration back to what it was.  As you can see, the interface is
kind of clutzy for doing this. Then again, this capability was not
specifically intended when the device was designed.


> But as far as I know, no single tool is able to model the timing
> behaviour of the synthesized logic as well as deliver an appropriate
> functional or timing model for the register access through the dynamic
> reconfiguration interface, be it CPU-like, boundary scan, or any
> way else.

And then on top of that there are the footprint issues which can be hard
to control in current HDLs.  When placing and replacing peices of logic
in an operating design, one has to be careful the layout and routing
meshes with the in place part of the design.  I find this a little
easier to manage using hierarchical schematic entry.

>

-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka
Article: 8118
Subject: The Top UK Opportunities in ASIC, Systems & Hardware R&D, ECM
From: ECM Selection Ltd <vanessa@ecmsel.demon.co.uk>
Date: Wed, 19 Nov 1997 16:39:10 +0000
Links: << >>  << T >>  << A >>


        The Top UK Opportunities in ASCI, FPGA, Systems & Hardware R&D


For the pick of the UKs top Resarch & Design opportunities in
applications ranging from:

                Advanced Video Systems
                Telecommunications
                Graphics Processing
                DSP
                High Speed Networks
                Broadcast Video Systems
                Consumer Products

visit:          http://www.ecmsel.co.uk


 




 

For further information on ECM and to search our ONLINE VACANCY DATABASE 
visit  http://www.ecmsel.co.uk.

Please contact us by Email: topjob@ecmsel.co.uk.

Alternatively Snail, Fax or Phone:
ECM Selection Ltd, The Maltings, Burwell, Cambridge, CB5 0HB
Phone: 01638 742244                             Fax: 01638 743066
Article: 8119
Subject: Re: Register Intensive Designs and Dynamically Reconfigurable FPGAs
From: Tom Burgess <tburgess@drao.nrc.ca>
Date: Wed, 19 Nov 1997 10:21:44 -0800
Links: << >>  << T >>  << A >>
Richard Dungan wrote:
> 
> "E.M. Shattock" <@no.spam> wrote:
> 
> >there's a pretty amusing article in this week's (15th november '97)
> >new scientist.
> 
> [snip to appease my ISP]
> 
> Yes, I read this article as well. I hope it's a case of an
> over-simplification by the magazine.
> 
> If it's all true and seriously intended then I'm worried.
> 

I think some people may be missing the most interesting point here -
that when evolutionary circuit design techniques are not constrained
to "play by the rules", they will explore the whole space of possible
solutions, many if not most of which which would be dismissed out of
hand by any sane engineer as incomprehensible or unsafe. As they say
in 'Jurassic Park' - "Nature will find a way".

	regards, tom (tburgess@drao.nrc.ca)
Article: 8120
Subject: Re: changing default eprom output in MaxPlusII
From: johna@dvorak.amd.com (John Archambeault)
Date: 19 Nov 1997 21:01:50 GMT
Links: << >>  << T >>  << A >>
In article <346ABBD2.3AEE@sh.bel.alcatel.be>,
Koenraad Schelfhout VH14 8993  <ksch@sh.bel.alcatel.be> wrote:
>Hello,
>
>Some time ago somebody mentioned that the default eprom output
>of Maxplus2 (ed 8.11) is not any more for the EPC1.  Unfortunately
>I have lost that info.
>I think Maxplus2 now generates by default output for the EPC1441.
>
>Can anyone tell me how I make MaxPlus2 use EPC1 as default, or
>what I have to do to generate outputs for the EPC1 ?
>
>Thanks

I've had some experiance with the ALLMAX prom burners.  Usually their options
are located under the PROGRAM menu under OPTIONS.  This is where I found the
ability to switch ATMEL's RESET/OE_ polarity (for example).  I'm not sure what
the EPC1 is, though.

Although I'd like to note for the group that this switch for the ATMEL EEPROM 
is opposite of what is printed on the screen.  ie, if it says that the prom is
programmed with a RESET active high, it is REALLY programmed with a RESET
active low.

	John
	
-- 
John Archambeault
Article: 8121
Subject: Re: Register Intensive Designs and Dynamically Reconfigurable FPGAs
From: "Steven K. Knapp" <sknapp@optimagic.com>
Date: Wed, 19 Nov 1997 13:25:43 -0800
Links: << >>  << T >>  << A >>

E.M. Shattock <@no.spam> wrote in message <3471EE5B.59CC@no.spam>...
>there's a pretty amusing article in this week's (15th november '97)
>new scientist. a 'researcher' loaded random configurations into
>a device (he doesn't say which one, but it's probably a xilinx XC4003)

Actually, the device is a Xilinx XC6216 FPGA
(http://www.cogs.susx.ac.uk/users/adrianth/ices96/node2.html#SECTION00020000
000000000000)

>in an attempt to produce a tone discriminator. by selecting
>configurations according to how successful they were, and 'breeding'
>these configurations (ie. randomly swapping bits between
>configurations), he eventually, after 3500 generations, found a
>configuration that successfully discriminated between a 1KHz and a
>10KHz tone. the circuit is unclocked. the cover describes
>this circuit as 'smart, strange, and beyond our understanding'.
>
>according to the article, he produced this solution with "fewer
>than one-tenth of the components that a human designer would
>have used" (he appears to have used 37 cells out of the 100).

.... and, if I remember correctly, it does not use any clocked elements.  In
other words, the circuit discriminates between two tone without any external
timing reference.
>
>but...
>1   the circuit works only over a 10 degrees C range
>2   it only works on one device
>3   he doesn't seem to have checked the voltage range over which
>    it works
>4   5 of the cells are not logically connected to the others.
>    but the circuit doesn't work without these cells.
>5   and so on...


.... ah, but it demonstrates some powerful and emergine concepts in evolvable
hardware and genetic programming.

If you're interested in this sort of thing, take a look at the following
links.

Researcher:  Adrian Thompson
http://www.cogs.susx.ac.uk/users/adrianth/ices96/paper.html
http://www.cogs.susx.ac.uk/users/adrianth/ade.html

Researcher:  Hugo de Garis

http://www.hip.atr.co.jp/~degaris/


-----------------------------------------------------------
Steven K. Knapp
OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally"
E-mail:  sknapp@optimagic.com
   Web:  http://www.optimagic.com
-----------------------------------------------------------



Article: 8122
Subject: Re: XC: bitfile to ASCII file
From: gah@u.washington.edu (G. Herrmannsfeldt)
Date: 19 Nov 1997 21:59:54 GMT
Links: << >>  << T >>  << A >>
Bob Walance <bwalance@harris.com> writes:


>You can create various hex file formats with MAKEPROM, but you'll still
>need to run MAKEBITS.


It should be possible to convert the rawbits output of makebits
to ASCII bit format, and vice versa, without running makebits.

If you have makebits, it is probably easier to do that.

I believe it is pretty much one ascii character per bit, but the
ascii form also adds newlines at certain points.  If you don't
care about those, you can do it directly.

It should be easy to do this in C, for example.

-- glen
Article: 8123
Subject: Re: What is the difference between CPLD and FPGA ?
From: "John Birkner" <birkner@quicklogic.com>
Date: Wed, 19 Nov 1997 14:15:27 -0800
Links: << >>  << T >>  << A >>
Jean-Paul Ricaud wrote:
>What is the difference between CPLD and FPGA ?

The simplest definition that I have heard is that,
  CPLDs are product term based and
  FPGAs are not product term based.

For more on this see:
  Selecting the Appropriate Programmable Logic Solution
  By Rhondalee Rohleder
  http://techweb.cmp.com/edtn/news/columns/Rohleder/rohleder_9_17.htm


Jean-Paul Ricaud wrote in message
<01bcf2ee$c10b1b00$e4679ec2@club-internet.club-internet.fr>...
>What is the difference between CPLD and FPGA ?
>
>Thanks
>--
>
>Jean-Paul RICAUD
>jpricaud@club-internet.fr
>


Article: 8124
Subject: XACT 5.0 problem under DOS
From: Stephen Molloy <molloy@ix.netcom.com>
Date: Wed, 19 Nov 1997 16:38:52 -0800
Links: << >>  << T >>  << A >>
A co-worker of mine recently dusted off an old
version 5.0 of Xact running under DOS on a PC
and is running into a problem during xnfprep.
Xilinx will no longer support this version. If
anyone has a quick answer to this problem we
would appreciate it.

The basic problem occurs during the xnfprep
part of xmake, and has something to do with
trouble finding/opening/using the message
files. All of the usual environment 
variables, paths, etc. seem to be set up ok.

There is an $XACT/msg directory with the
full set of message files in it.

Attached is the log file:


----------------------------------------------------
XMAKE Version 5.0.0
Copyright (c) 1989-1994 Xilinx Inc. All rights reserved
386|DOS-Extender 4.1 - Copyright (C) 1986-1993 Phar Lap Software, Inc.

XMAKE: Generating makefile 'top.mak'...
XMAKE: Set the part type to '4005PC84-10' from the command line,
overriding
       the part type specified in the design, if any.
XMAKE: Profile used is the current XDM settings.

XMAKE: Execute command 'wir2xnf -B -OD xnf -P 4005PC84-10 top top.xnf'.
******************************************************************************
WIR2XNF Version 5.0.0
(c) Copyright 1988-1994 Xilinx Inc.  All rights reserved.

386|DOS-Extender 4.1 - Copyright (C) 1986-1993 Phar Lap Software, Inc.


Input project     : top
Output XNF file   : top.xnf
Output CRS file   : top.crs
Output error file : top.err
B option          : ON
C option          : OFF
X option          : OFF
F option          : OFF
Parttype          : 4005PC84-10
Sub directory     : xnf
Components written to file
xnf\m2_1.xnf.                                       
Components written to file
xnf\top.xnf.                                       
0 Errors and 0 Warnings occurred during processing.

XMAKE: Running with the following XMAKE options:
       -P 4005PC84-10 
  >>>  XDELAY is run always with '-D' and '-W' options by XMAKE.
XMAKE: Makefile saved in 'top.mak'.

XMAKE: Making 'top.bit'...

XMAKE: Execute command 'xnfmerge -A -D xnf -D . -P 4005PC84-10
xnf\top.xnf top.xff'.
******************************************************************************
XNFMERGE Ver. 5.0.0
(c) Copyright 1987-1994 Xilinx Inc. All rights reserved
386|DOS-Extender 4.1 - Copyright (C) 1986-1993 Phar Lap Software, Inc.


List of files read
    Read file xnf\top.xnf
    Read file xnf\m2_1.xnf
Netlist written to file top.xff

XMAKE: Execute command 'xnfprep top.xff top.xtg parttype=4005PC84-10'.
******************************************************************************
xnfprep: FATAL ERROR: 
---------------------------------------------------
The message set for "msg" does not exist
in any of the standard message files.  Check to make sure that the
$XACT/msg directory exists and contains message files.  The message
set must be defined before program execution can continue
---------------------------------------------------

XMAKE: ERROR: Command 'xnfprep top.xff top.xtg parttype=4005PC84-10'
failed (rc=3). 'top.xtg' removed.
XMAKE: ERROR: Failed to make 'top.bit'.


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