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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 2050

Article: 2050
Subject: Programming a daisy chain of XC4000
From: <cha>
Date: 6 Oct 1995 17:39:57 GMT
Links: << >>  << T >>  << A >>
I want to program a daisy chain of XC4000, but I'm not sure what pins I must
connect. I don't know if it's neccesary to connect HDC & LDC to Vcc & GND.
Can you help me? 

Another question: in the slave chips, are the DONE, INIT & PROGRAM pins unused?

                    Thanks in advance for your help,

                                    Fernando.



Article: 2051
Subject: VHDL and Xilinx (Hard/Soft) Macros
From: Gerard Williams III <gerard>
Date: 6 Oct 1995 18:50:25 GMT
Links: << >>  << T >>  << A >>
I am working on a design which requires instantiation of the clock oscillator
in the Xilinx 4K library for Mentor Graphics.  I would like to include this 
information directly in VHDL without having to use Design Architect create
a top level sheet.  Any help whether this can be done would be appreciated.

  Thank,

    Gerard Williams
    (gerard@ee.umr.edu)



Article: 2052
Subject: Re: cheap (free) fpga design software (VHDL
From: David Mauro <08962500524-0001@t-online.de>
Date: 6 Oct 1995 19:16:27 GMT
Links: << >>  << T >>  << A >>
Re: cheap (free) fpga design software (VHDL

I heard about a new software for Xilinx FPGAs that runs under Windows.
The package that works together with Xact consists of design entry and 
simulation.

For upgraders: Orcad and Viewlogic designs can be imported.

At the moment I'm waiting for the suggestion of an application engineer 
who is testing the system right now.

As soon as I've results or new infos I'll post a message.

By the way: The name of the software is Susicad or Suzicad (or similar)

cu
David


Article: 2053
Subject: Re: VHDL and Xilinx (Hard/Soft) Macros
From: yjhou@Qualcomm.com (Y. Jason Hou)
Date: Fri, 06 Oct 1995 13:46:52 -0700
Links: << >>  << T >>  << A >>
In article <453tph$drk@hptemp1.cc.umr.edu>, Gerard Williams III <gerard> wrote:

> I am working on a design which requires instantiation of the clock oscillator
> in the Xilinx 4K library for Mentor Graphics.  I would like to include this 
> information directly in VHDL without having to use Design Architect create
> a top level sheet.  Any help whether this can be done would be appreciated.
> 
>   Thank,
 

Unless I am mistaken, XC4000 does not have a crystal oscillator amplifier
inside.  XC3000 has it.  Or maybe the new family of XC4000 have included
it also?

I successfully instantiated the clock oscillator on XC3000 before (1 year).  
The same rule should also apply to including modules generated by the
schematic.

The trick is, instantiate the oscillator amp in VHDL as a component.
Synthesize it (I did it in Synopsys) and get your .xnf netlist.  One thing
to note, when you instantiate the component, remember to assign pin names
(in/out) correspondingly to the names assigned to the macro's.  Check
the .xnf of your macro (hard or soft).  In your case, the macro is gxtl
and there is only one pin as the output, O: out std_logic.

Merge your netlists.  Remember to include the gxtl.xnf file.
Then you can have what you want.

Good luck!


Y. Jason Hou,
Qualcomm Inc.,
yjhou@qualcomm.com


Article: 2054
Subject: Sockects for AMD MACH-445 anywhere ?
From: mercure@primenet.com (Ray Saarela)
Date: Fri, 06 Oct 95 21:46:53 GMT
Links: << >>  << T >>  << A >>

	I have a few samples of MACH-445's, and would like to play with them
	in practice as well, but I haven't been able to find QFP SOCKETS for
	them. AMP 100 pin sockects are 4 x 25 pin rows ( square package ) ,
	but AMD MACH 445 has 2 x 30 pin rows and 2 x 20 pin rows ... 
	( rectangular ) qfp ..

	If anyone knows any place making sockets for such package, would 
	really appreciate to know who and where ... 

	I just wouldn't like to design a small adapter-board and have the 
	chips soldered just to play with them ... 

			Appreciate your help, Ray Saarela		
	
	


Article: 2055
Subject: Needed: PCI prototyping board, for use testing with FPGA interface
From: weathert@park (William N. Eatherton)
Date: 7 Oct 1995 00:07:02 GMT
Links: << >>  << T >>  << A >>
	I am begining work on an ultrasound card to be implemented on a PCI 
card.  We would like to find a PCI protoyping card to play with writing and
reading a ram and then so we can work out the bugs in an FPGA interface.  WE
are planning on using the XC4000E series when xilinx comes out with it.  However,
we would really like a prototyping board that we could begin playing with in the
next couple weeks.  Under a $1000 would be desired.
Thanks
WIlliam Eatherton
Washington University



Article: 2056
Subject: [Q] Looking for VHDL models for FPGA
From: imago@leo.bekkoame.or.jp (Masahiko Imahashi)
Date: 7 Oct 1995 04:28:17 GMT
Links: << >>  << T >>  << A >>
Hi, there.

I'm looking for VHDL models for classical Intel
peripheral devices.
(e.g. 8251,8253,8254,8255,8259,8237)

I need VHDL models which will try to create
and test large circuits on PLD or FPGA.
If you have any suggestions, please contact me
at the email addresses below.

Thanks.

-----
M.Imahashi CyVerse Co.,Ltd.
e-mail:  imago@leo.bekkoame.or.jp
tel: +81-44-888-1944
fax: +81-44-888-1094
-----

Regards.


Article: 2057
Subject: XsimMake fails
From: <cha>
Date: 7 Oct 1995 16:08:35 GMT
Links: << >>  << T >>  << A >>
I notice XsimMake fails when I run it. I changed one thing in a design I'd
simulated and I ran Xmake&XsimMake again. However, Xsimmake failed in Check
program. After I "deltree" the s<design> directory and s<design>.vsm file I
ran XsimMake again. This time the program ended succesfully. Why ?
Of course, I do the Check & Export before running Xmake & Xsimmake.

                     Regards,

                        Fernando



Article: 2058
Subject: Re: Programming a daisy chain of XC4000
From: fliptron@netcom.com (Philip Freidin)
Date: Sat, 7 Oct 1995 19:18:35 GMT
Links: << >>  << T >>  << A >>
In article <453pld$35m@diable.upc.es> <cha> writes:
>I want to program a daisy chain of XC4000, but I'm not sure what pins I must
>connect. I don't know if it's neccesary to connect HDC & LDC to Vcc & GND.
>Can you help me? 
>
>Another question: in the slave chips, are the DONE, INIT & PROGRAM pins unused?
>
>                    Thanks in advance for your help,
>
>                                    Fernando.
>

To daisy chain XC4000 chips, just take the dout of the upstream chip and 
connect it to the din of the next chip. connects the dout of the secon 
chip to din of the third chip, etc. all are fed the same cclk.
Do NOT connect the HDC or LDC pins together, as they are outputs with
both low and high drive. Connect the program pins together. Init pins
can be tied together, and use a single pull up resistor. Done pins can
be tied together with a single pull up resistor. (the done pins must be
tied together if you will be using cclk_sync or uclk_sync startup modes, 
see page 2-29 of data book).

There is also a less than totaly useful diagram that shows XC3000 devices 
in daisychain mode on page 2-126 of the data book.

Hope this enough info for you (if not, ask for more)

Philip Freidin





Article: 2059
Subject: Re: Sockects for AMD MACH-445 anywhere ?
From: fliptron@netcom.com (Philip Freidin)
Date: Sat, 7 Oct 1995 19:25:16 GMT
Links: << >>  << T >>  << A >>
In article <454bir$dnk@nnrp1.news.primenet.com> mercure@primenet.com (Ray Saarela) writes:
>
>	I have a few samples of MACH-445's, and would like to play with them
>	in practice as well, but I haven't been able to find QFP SOCKETS for
>	them. AMP 100 pin sockects are 4 x 25 pin rows ( square package ) ,
>	but AMD MACH 445 has 2 x 30 pin rows and 2 x 20 pin rows ... 
>	( rectangular ) qfp ..
>
>	If anyone knows any place making sockets for such package, would 
>	really appreciate to know who and where ... 
>
>	I just wouldn't like to design a small adapter-board and have the 
>	chips soldered just to play with them ... 
>
>			Appreciate your help, Ray Saarela		
>	
>	
Test sockets for these types of packages are made by Yamaichi 
Electronics, and probably others. 

(408) 456-0797

partnumbers are IC51-xxxx-yyy-zzz.   Call and get a catalog


All the best, Philip Freidin



Article: 2060
Subject: Re: REPOST: Design Contest Write-up ( was "Jury Verdict + Test Benches" )
From: Jan Decaluwe <jand>
Date: 8 Oct 1995 17:24:45 GMT
Links: << >>  << T >>  << A >>
Jonathan AH Hogg <jonathan@dcs.gla.ac.uk> wrote:

>it's still early days yet for hardware synthesis. no-one really
>understands what an HDL should look like. an HDL that's based on a
>software language is not a good starting point in my opinion. designing
>software and designing hardware are two different paradigms. since when 
>did gate arrays have `for' loops? software is based on control flow, 
>hardware is based on data flow.

Many HDLs have been designed "with hardware in mind". Typically they 
only support the concurrent ("hardware") domain. Indeed, as "gate arrays 
don't have for loops", why should there be a procedural ("software") domain?

Notable exceptions are Verilog and VHDL, that support both the concurrent
and the procedural domain. They are also the most popular HDLs. I believe
that's no coincidence. Although many hardware designers have difficulties in
understanding or accepting it, procedural statements such as for loops are
a great way to describe complex hardware, including combinatorial logic.
Procedural descriptions allow you to describe complicated dependencies 
elegantly -  but this doesn't prevent a synthesis tool from extracting
the maximal parallelism. These days, many `for' loops actually make it to
gate arrays! 

Many people suggest that it is a disadvantage that Verilog / VHDL have 
not been designed "with hardware (or synthesis) in mind". Personally, 
I believe that this has been a key to their success, because the
language designers were not hindered by prejudices. 

Regards, Jan

-- 
===================================================================
Jan Decaluwe              ===              Easics               ===
Design Manager            ===  VHDL-based ASIC design services  ===
E-mail: jand@easics.be       ===================================
Tel: +32-16-270 400
Fax: +32-16-270 319         Kapeldreef 60, B-3001 Leuven, BELGIUM



Article: 2061
Subject: Re: Programming a daisy chain of XC4000
From: John Forrest <jf@ap.co.umist.ac.uk>
Date: 8 Oct 1995 19:40:39 GMT
Links: << >>  << T >>  << A >>
In article <453pld$35m@diable.upc.es> , cha writes:
>I want to program a daisy chain of XC4000, but I'm not sure what pins I must
>connect. I don't know if it's neccesary to connect HDC & LDC to Vcc & GND.
>Can you help me? 
>
>Another question: in the slave chips, are the DONE, INIT & PROGRAM pins unused?

Dare I just say "Read the databook"?

_____________________________________________________________
Dr John Forrest           Tel: +44-161-200-3315
Dept of Computation       Fax: +44-161-200-3321
UMIST                  E-mail: jf@ap.co.umist.ac.uk
MANCHESTER M60 1QD
UK


Article: 2062
Subject: Re: FFT in FPGAs ?
From: lurch@ee.latrobe.edu.au (Geoffrey Liersch)
Date: 9 Oct 1995 09:12:09 +1000
Links: << >>  << T >>  << A >>
In article <44hvo5$l31@su102w.ess.harris.com>,
John Noll <jnoll@su19bb.ess.harris.com> wrote:
>In article lpo@marina.cinenet.net, kirani@cinenet.net (kayvon irani) writes:
>> 	I'd like to know if any brave designer out there has tried to 
>> 	implement an FFT algorithm in an FPGA. Any one has experience
>> 	with Mentor/Synopsys tools that take your algorithms and output
>> 	VHDL synthesizable code?
>> 
>> 	Regrards,
>> 	Kayvon Irani
>> 	Lear Astronics
>> 	Los Angeles
>
>
>I doubt it seriously.  With the largest FPGAs around you would be lucky
>to get one decent size
>complex multiplier.  If you could get a CMPLY to fit in an FPGA with some 
>room leftover (good 
>luck) then you could add some logic to read a RAM/PROM for the twiddle 
>factors and sequence 
>through the input data.  Several passes and you would have an FFT.  
>I have given it serious 
>thought in the past as I have built many FFT processing boards and the answer,
>so far, has always
>been the same:  not enough logic in and FPGA to do enough to make it worth 
>while.  I have always
>bought an FFT processor - Plessey, Sharp, LSI - there are many different 
>good options out there
>depending on what you need.

I have implemented an FFT butterfly in a Xilinx FPGA.  The design is based on 
a DIT butterfly and uses 16 bit words in a bit serial architecture.  
The initial design was implemented in a XC4010PG191-6.  
It uses just over half of the 400 available clb's and was placed and routed 
using the standard Xilinx tools.  The maximum clock rate for the butterfly is
just over 20Mhz for the -6 grade part.  While I am the first to admit that
this is not breaking any land speed records,  it shows that it can be done
with the current technology.  I am also looking at several other designs:
one that reduces the number of CLB's by sharing some of the delay elements in
the complex multipy, one which is a pipelined parallel version and a third 
which uses a completely different technique to compute the complex multiply.
Initial investigation shows that all three designs are capable of fitting 
comfortably inside a single Xilinx device.

Lurch
lurch@ee.latrobe.edu.au


Article: 2063
Subject: Re: Powerdown & Xilinx devices
From: fliptron@netcom.com (Philip Freidin)
Date: Mon, 9 Oct 1995 05:21:02 GMT
Links: << >>  << T >>  << A >>
>From: "Michael Pot" <michael@digitech.co.nz>
>Organization: Digi-Tech Ltd, Wellington, New Zealand
>To: "replys"                       <comp-arch-fpga@super.org>
>Subject:    Re:- Powerdown & Xilinx devices
>
>Hi Folks,
>
>When we recently needed to look into battery back etc, I searched through
>lots of old xilinx manuls, Best of XCELL, & app notes, etc, to gleen more
>info.  Some of the old writings were quite open about how things were
>done and what was going on.  Not so much market speak, eh.  Anyway,
>this is what I concluded:-
>
>Xilinx once said in the XC2000 & XC3000 days that their powerdown
>current was naff all.  The function generators still work, so if it
>isn't naff all, then make sure the powerdown state of the IOB etc is
>not causing contention or oscilation within the device.  If you look
>at the way the IOB's and CLB flipflops appear to behave to the
>configured logic, it is all quite nicely done.  They must have given
>quite a bit of thought to this in the early days.

Xilinx FPGAs (specifically the XC3000 and XC3000A and XC3000L families)
have the lowest power down current of any programmable logic device
available. The Iccpd spec on page 2-155 of the data book shows 50 to 250 uA
depending on product. At the bottom of the page it refers to devices in
the range of 1 to 5 uA !!. 

In a CMOS device that is not switching, the only current drawn is a
combination of parasitic leakage current, and circuit elements that have
a DC current consumption. In XC3000 the DC current consumptions circuits
are:
	I/Os that drive low into a load that is also passively/actively
	pulled high

	I/Os that drive high into a load that is also passively/actively
	pulled low

	TBUF lines that are driven low and high simultaneously (design error)

	TBUF lines that are driven low, and the pullup resistors are enabled

	Floating internal inputs (quite minimal effect. the purpose of the
	'tie' function)

	Parasitic leakage.

Assuming good circuit design, and no outputs driving loads that require DC
current, and no TBUF fights, CMOS threshold inputs, a 3020 can have an 
Icco of 500 uA (page 2-155).  Adding TTL threshold inputs bumps it up by 
a factor 20 to 10mA. This is a clue.

When the device is placed in power down mode, the outputs are disabled,
all the internal flipflops are reset, and the TBUFs are all disabled.
Then if the device is still at 5V, then Iccpd is the parameter that is 
relevant rather than Icco. If you then lower VCC to as low as 2.3 V, the
Iccpd will also drop below the 50 to 250 uA value, but I can't find any
values in the data sheet.

The 3100 and 3100A parts have a baseline of 8mA (page 2-179), and TTL
thresholds adds another 6 for a total of 14mA. The baseline of 8mA is why
3100/3100A powerdown does not make much sense. These parts are much 
faster than the 3000/3000A, so these extra milliamps might have something 
to do with it. seems like a good tradeoff to me. 


>
>They also said their configuration RAM was very reliable vs typical
>SRAM (Cross coupled invrters, 5K, vs resistor pullup, 5M).

The configuration memory cells in all these devices are much more like
74F374 flipflops rather than high density high speed SRAM cells. The
cells have not been seen to be effected by alpha particles (page 2-107).
Unlike highspeed RAMS, the config cells do not have to be fast, as they
are all continuously being read out (to control the chip), so access
time is not an issue. The tradeoff here is high reliability and low
power consumption vs access speed.


>
>They state 3100 (and XC4000?) are not suitable for battery back, very
>low current applications.  Our tests have confirmed this.  The
>powered down current varies with temperture & probably from device to
>device.  Have they changed their configruation RAM implementation to
>one that uses resistive pullup in order to shrink the die in newer
>parts?  If so, what type of config RAM does the XC5000 use?

The XC4000 and XC4000A only support TTL threshold, and there is the clue
in the XC3000 data sheet that this accounts for 6 to 10 mA. The XC4000H
and the new XC4000E devices do allow the CMOS input mode, so maybe they
are capable of a low power state.

The XC5200 has an Icco of 15 mA (XC5200 data sheet, page 25), but also
has TTL and CMOS thesholds, so it seems like the XC3100/3100A devices
that have both thresholds, but don't have really low Icco. 


>
>Michael
>

Philip Freidin




Article: 2064
Subject: Re: REPOST: Design Contest Write-up ( was "Jury Verdict + Test Benches" )
From: Jonathan AH Hogg <jonathan@dcs.gla.ac.uk>
Date: Mon, 9 Oct 1995 08:09:47 GMT
Links: << >>  << T >>  << A >>
On 8 Oct 1995, Jan Decaluwe wrote:

> 
> Many people suggest that it is a disadvantage that Verilog / VHDL have 
> not been designed "with hardware (or synthesis) in mind". Personally, 
> I believe that this has been a key to their success, because the
> language designers were not hindered by prejudices. 
> 

VHDL was designed with simulation in mind, not synthesis. It is a 
language for describing behaviour based on an event simulator. It was 
never designed for automatic generation of hardware. What we would call a 
specification language not an implementation language.

:-jonathan

-- 
Jonathan AH Hogg, Computing Science, The University, Glasgow G12 8QQ, Scotland.
jonathan@dcs.gla.ac.uk http://www.dcs.gla.ac.uk/~jonathan (+44)141 3398855x2069



Article: 2065
Subject: [Need] large VHDL codes.
From: kyung@cslsun10.sogang.ac.kr (Cho Kyung Choon)
Date: 9 Oct 1995 09:50:00 GMT
Links: << >>  << T >>  << A >>

- I'm looking for a lots of large vhdl codes. -

I have been develope a partition program runing on FPGA, 
which place a large circuit into several FPGAs.
I feel lack of benchmark circuit because I don't design any circuit, 

Is there anyone who allow me to use a circuit, written in vhdl,
designed by an angel.  =)
or let me know where can I get some benchmark circuit. ( ftp site list ok! )

The bigger, the better.

--
email : kyung@dalab2.sogang.ac.kr


Article: 2066
Subject: Re: trends in reconfigurable computing??
From: hutch@timp.ee.byu.edu (Brad Hutchings)
Date: 09 Oct 1995 17:16:44 GMT
Links: << >>  << T >>  << A >>
>>>>> "Marcelo" == Marcelo Hoffmann <Hoffmann@sri.com> writes:
In article <Hoffmann-290995100542@bic9.sri.com> Hoffmann@sri.com (Marcelo Hoffmann) writes:

    Marcelo> I have been pleasantly surprised with the level of
    Marcelo> research activity in the last couple of years on
    Marcelo> reconfigurable computing (I went to the 1993 "FPGAs for
    Marcelo> Custom Computing Machines Workshop" by the IEEE, and
    Marcelo> there was very little work then...), and the growth of
    Marcelo> commercial activity. Some folks, directly involved in the
    Marcelo> business of making FPGAs, suggest that dynamically
    Marcelo> reconfigurable computing components could be a billion
    Marcelo> dollar market in 3-4 years...., while we hardly have the
    Marcelo> terminology available now...

I would guess that the FPGA business will hit close to a billion this
year, based on past growth. So things on the general FPGA front are
moving along pretty well. We have quite a ways to go in the
reconfigurable computing venue, though. Most of the work that has been
published thus far is reminiscent of the VLSI craze in the 70s and
early 80s where there were many reports of application-specific
hardware. Much of the reported FPGA work is of that variety. This is
to be expected because people are still trying to figure out what is
*possible* with FPGAs. Don't get me wrong, BTW.  Good reports of
application-mapping are still very important. What we probably need to
see more of are larger (or, at least complete) applications that are
based on FPGAs. This will give us a better idea of the actual performance
that can be achieved (which is quite good in many cases) and of the
actual costs.

    Marcelo> Although I understand the potential of the hardware, what
    Marcelo> would it take to make "software" available for these
    Marcelo> reconfigurable elements? How do you go about
    Marcelo> converting/originating code for hardware that is so
    Marcelo> malleable?  Is there a way to mix object-orientation,
    Marcelo> with reconfigurable computing (specific configurations
    Marcelo> for specific objects, that you change on-the-fly??)  What
    Marcelo> do you optimize: the "hardware," the "software" (terms
    Marcelo> which become hard to separate with reconfiguration....)?
    Marcelo> Who will develop the compilers, development tools...?
    Marcelo> Will there be a "reconfigurable operating system" in the
    Marcelo> near future?

Some of the work we are doing in run-time reconfiguration has a 
decidedly object-oriented feel to it. I have hesitated to mention
that point though because it sounds too much like marketing hype.
If interested, check out http://splish.ee.byu.edu for some of our
papers. Look at the DISC ones (look at 'em all :-). You can also
check out our bibliography for more information. Most of the references
include abstracts.

    Marcelo> Certainly the potential for customized-and-also-flexible
    Marcelo> computing engines is very high, but who, and how long
    Marcelo> will it take to develop the supporting infrastructure?

As I said there is still much work to be done here. Xilinx seems to be
quite interested in the reconfigurable logic market (whatever that
is).  No doubt, if there is a market, they will come :-). Take a look
at the Teramac stuff at HP. They have done an excellent job of dealing
with a lot of the low level issues (place and route, partitioning) in
automated fashion thereby making it much easier to map applications to
hardware. It does not look much like software yet, but they have made
good progress nonetheless.

    Marcelo> I am very intrigued by the possibilities of mixing
    Marcelo> hardware/software concepts for more cost-effective
    Marcelo> computing... Comments??

Some of the hardware-software stuff has been addressed by Ian Page's
group at Oxford. You can get to them from our home page on the
the related links page. Look for Oxford Hardware Compilation Group.
They use a variant of Occam called Handel. Because Occam was based
on CSP, it directly supports concurrency making it suitable for
hardware description at some level.



--
            Brad L. Hutchings - (801) 378-2667 - hutch@ee.byu.edu 
Brigham Young University - Electrical Eng. Dept. - 459 CB - Provo, UT 84602
                       Reconfigurable Logic Laboratory




Xref: netcom.com comp.arch.fpga:2208
Article: 2067
Subject: Workview Pro-series doesn't work with windows 95.
From: husby@fnal.gov (Don Husby)
Date: 9 Oct 1995 18:57:37 GMT
Links: << >>  << T >>  << A >>

Apparently still not the types to jump on a bandwagon too soon, View Logic 
will not be releasing a windows-95 compatible version of the pro-series till 
at least December.

Unfortunately, I learned about this the hard way. 



Article: 2068
Subject: Re: Powerdown & Xilinx devices
From: davem@hbmltd.demon.co.uk
Date: Mon, 09 Oct 95 19:42:24 XAC
Links: << >>  << T >>  << A >>

>When we recently needed to look into battery back etc, I searched through
>lots of old xilinx manuls, Best of XCELL, & app notes, etc, to gleen more
>info.  Some of the old writings were quite open about how things were
>done and what was going on.  Not so much market speak, eh.  Anyway,
>this is what I concluded:-
.. <snip>

I would concur - Xilinx have become very conservative compared to the "old 
days".  I guess we all know what the probable reason for this is.

I spent a lot of time developing products which used battery backed-up Xilinxs 
(2018's).  During the course of the development, I discovered that it is a far 
from simple exercise, and that there are many pitfalls which will cause 
sporadic loss of configuration in the field. This IMO was a result of Xilinx 
not "thinking it through" quite enough.

After we had a working product selling for over a year, Xilinx changed mask on 
us, and disabled the "disable reprogramme" bit (this prevented "DONE" low from 
killing the configuration).  We found out about this change the hard way 
(failures in the field)  :-( 

If you are seriously considering a battery backup option, e-mail me & I'll 
summarise my findings - it is definately possible, but requires a bit more 
external circuitry than is obvious.

=========================
Dave Mould
=========================




Article: 2069
Subject: Re: FPGA for a 20k gates micro-controller.
From: John Forrest <jf@ap.co.umist.ac.uk>
Date: 10 Oct 1995 06:30:40 GMT
Links: << >>  << T >>  << A >>
In article <44cro0$b00@mailman.xilinx> Steven K. Knapp, stevek writes:
>>Xilinx 6200 parts which are being introduced this fall/winter are supposed
>>to address exactly that situation!  i don't know the prices yet.
>>
>The Xxilinx XC6200 is the first FPGA family optimized for co-processing in
>embedded system applications.
>
>You can find out more information about the Xilinx XC6200 FPGA on the Web at...

Apart from the fact that the spec sheet has the diagram many of us put in
our codesign papers, we (the public) know virtually nothing about this
device. If it is to be released that soon, it is about time Xilinx
released some datasheets. Since they haven't, I expect the any
forthcoming data to be an anouncement, with the date when both silicon
and design tools to be available at a long time in the future. Just think
how long it is for 5k2's to be introduced - at the moment I can get hold
of the silicon but no tools - and when were they announced?

_____________________________________________________________
Dr John Forrest           Tel: +44-161-200-3315
Dept of Computation       Fax: +44-161-200-3321
UMIST                  E-mail: jf@ap.co.umist.ac.uk
MANCHESTER M60 1QD
UK


Article: 2070
Subject: IEE Colloquium : Verification of hardware-software codesigns
From: rwt@hplb.hpl.hp.com (richard taylor)
Date: Tue, 10 Oct 1995 07:29:03 GMT
Links: << >>  << T >>  << A >>
[ Article crossposted from comp.cad.synthesis ]
[ Author was richard taylor ]
[ Posted on Tue, 10 Oct 1995 07:25:58 GMT ]

[ Article crossposted from comp.lsi.cad ]
[ Author was richard taylor ]
[ Posted on Mon, 9 Oct 1995 15:54:32 GMT ]

IEE Colloquium. 
--------------
Verification and Validation of Hardware/Software Codesigns

The second one day colloquium in the IEE "Hardware/Software Codesign"
series, 'Verification of hardware-software codesigns' is being
organised by PG C2 (Hardware and Systems Engineering) and PG C6
(Systems Engineering for Automation) at Savoy Place, London on Tuesday 17
October 1995.

Codesign refers to the simultaneous process of designing both hardware
and software to meet some specified performance objectives. Unlike
more traditional approaches to system engineering where the hardware
and software partitions are relatively rigid, codesigns are
characterised by flexible partitions that may be shifted to meet
changing performance criteria. One consequence of this is that
sophisticated and flexible specification, synthesis, verification &
validation tools become essential to the design process.

The first colloquium in this series addressed current research and
practice in the area of partitioning codesigns. The purpose of this
colloquium is to examine the verification and validation processes
essential for effective hardware-software codesign. Papers being
presented at this colloquium address the requirements for verification
and validation procedures, formal models for describing codesigns, and
practical tools for their realisation. Speakers have been drawn from
across Europe.

The morning session will concentrate on models and formalisms for
codesigns. After lunch, experimental toolsets for design exploration,
validation and verification will be presented. The colloquium will
conclude with a panel session addressing the practical problems of
migrating laboratory tools and techniques to industrial applications.

For further details and registration, please contact Claire Coleshill,
IEE, Savoy Place, London, WC2R 0BL, United Kingdom. Phone (44) 171 344
5419, Fax (44) 171 497 3633, Email : ccoleshill@iee.org.uk

***************             Program          **********************

Chair : R Taylor, Hewlett-Packard Laboratories, Bristol, England.

10.00 - 10.30 Registration and Coffee

10.30 - 11.00 T Ismail and A Jerraya, TIMA/INPG Grenoble, France,
``Design Models and Steps for Codesign''

11.00 - 11.30 R Nicholls, Manchester Metropolitan University,
Manchester, ``Verification or Validation of Hardware/Software
Codesigns ?''

11.30 - 12.00 N Jayaramn, University of Westminster, London,
``Verification of Real Time Systems - Issues and Perspectives''

12.00 - 12.30 J Staunstrup, Technical University of Denmark, Denmark,
``Interface Models in Hardware/Software Codesigns''

12.40 - 1.30 Lunch

1.30 - 2.00 M Sheeran, Chalmers Technical University, Sweden , S
Singh, Glasgow University, Scotland , ``Ruby as a Basis for
Hardware/Software Codesign''

2.00 - 2.30 W Luk and Peter Cheung, Imperial College of Science,
Technology and Medicine, London, ``A Toolkit for Exploring
Hardware/Software Systems''

2.30 - 3.00 W Rosentiel, University of T'ubingen and Forshungszentrum
Informatik, Germany, ``Source Level Emulation to Bridge the Gap
Between High Level Synthesis and Emulation''

3.00 - 3.30 G Evans and D Morris, UMIST, Manchester, ``Validation and
Verification of System Designs using MOOSE''

3,30 - 3.45 Coffee

3.45 - 4.45 Panel Discussion ``Transferring Laboratory Techniques to
Industry, Requirements, Aspirations and Practicality'', Chair : J
Harrison, Hewlett-Packard Limited

4.45 Close



--
Richard Taylor,                               __o      o            __o  __o 
Hewlett-Packard Laboratories, Bristol, UK.   `\<,      \\_/\_,     `\<,-`\<, 
rwt@hplb.hpl.hp.com                          O/ O      O   O       O/----/ O 
phone : +44 (0) 117 922 9545
fax   : +44 (0) 117 922 8925





--
Richard Taylor,                               __o      o            __o  __o 
Hewlett-Packard Laboratories, Bristol, UK.   `\<,      \\_/\_,     `\<,-`\<, 
rwt@hplb.hpl.hp.com                          O/ O      O   O       O/----/ O 
phone : +44 (0) 117 922 9545
fax   : +44 (0) 117 922 8925


--
Richard Taylor,                               __o      o            __o  __o 
Hewlett-Packard Laboratories, Bristol, UK.   `\<,      \\_/\_,     `\<,-`\<, 
rwt@hplb.hpl.hp.com                          O/ O      O   O       O/----/ O 
phone : +44 (0) 117 922 9545
fax   : +44 (0) 117 922 8925



Article: 2071
Subject: Re: Good materials schools?
From: bobsun@aol.com (BobSun)
Date: 10 Oct 1995 05:26:08 -0400
Links: << >>  << T >>  << A >>
Ryan,

Let me add to your confusion, but from a different perspective - that of a
"customer" for graduates from  these schools. For the most part, the
inputs you have gotten have been good advise. Let me add (or re-emphasize)
some general points.

1. Go to a large, well-known school, if possible. One day you will be
graduating and the breadth of opportunities (job or grad school) will be
greater at a school with a better reputation. Some people may object to
this, but, nevertheless, it is a fact. A significant fraction of
undergraduates find part time employment in grad research programs, and
summer intern jobs. Your chances for this are also greater at a well-known
"Research" university. The only two schools you listed which fit into this
catagory (no flames, please) are Penn State and Lehigh. 

2. Your strong interests in photonics and/or polymers might be difficult
to meet in most Materials Sci (or Eng.) curricula. Good polymer schools
include MIT, U Mass, VIT and Michigan, in the East. Photonic efforts tend
to reside in the EE departments, and mainly in graduate programs. The
suggestion to look at Chem E for polymers is a good one. My own experience
is that my interests in specialization changed greatly while in school,
and even more after going to work. So make certain to get a strong, well
rounded undergraduate degree, taking every opportunity to broaden your
background with courses in areas such as EE, ChemE, PChem, CompSci, MechE
and Statistics.

3. Good luck.

Bob Sundahl
Intel


Article: 2072
Subject: Help - Searching an PLD/FPGA Selection Software
From: beltle@augusta.de (Hans Jörg Beltle)
Date: 10 Oct 1995 09:51:25 GMT
Links: << >>  << T >>  << A >>
Hello,

I want to use programmable logic devices (CPLDs and FPGAs) in my
future developments and I need an overview of the market.

Is there any program or database out there ?

Thanks
  Hans


Article: 2073
Subject: Re: Workview Pro-series doesn't work with windows 95.
From: steve@sj.co.uk (Steve Wiseman)
Date: Tue, 10 Oct 1995 15:50:32 GMT
Links: << >>  << T >>  << A >>
In article <45brb1$plq@fnnews.fnal.gov>, husby@fnal.gov says...
>
>Apparently still not the types to jump on a bandwagon too soon, View Logic 
>will not be releasing a windows-95 compatible version of the pro-series till 
>at least December.
>
>Unfortunately, I learned about this the hard way. 

Yes, us too. Is there a Viewlogic Users Group out there, so we don't _all_ have 
to find things out the hard way? It's not as if the documentation's getting 
better, either....
  (Proseries does work under '95 and NT, except for PROSIM, the only tool to use 
Win32S. Aargh! So close, yet so, so far.... You'll need much patience, some mad 
dongle-redirecting code, and some more patience. _How_ can it take ProCapture 3 
seconds to ask the dongle each time I load a new component? (On a twin P90, 
running NT 3.51 with 32M Ram)
  Roll on Workview Office, or is it just going to have all the 'features' that 
make each day such a joy (ahem...)?

  Steve, speaking for Steve, not SJ Research.




Article: 2074
Subject: Re: VHDL and Xilinx (Hard/Soft) Macros
From: Gerard Williams III <gerard>
Date: 10 Oct 1995 17:22:47 GMT
Links: << >>  << T >>  << A >>
Do you still have the VHDL code used for the component instantiation?  An 
example would greatly be appreciated.





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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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