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 8625

Article: 8625
Subject: Re: Asynchronous square root.
From: husby@fnal.gov
Date: Wed, 14 Jan 1998 11:02:32 -0600
Links: << >>  << T >>  << A >>
z80@ds.com (Peter) wrote:

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

I don't know, it could be Newton-Raphson.  It's based on an
algorithm for long-hand square roots that my Father taught
me when I was but a wee child:  "Multiply by 2 and shift left
one digit."  Fortunately, this works in base 2 as well as base
10.  There's no initial guess -- the alogorithm consumes exactly
two bits and produces exactly 1 result bit for each iteration.
The "Unrolled version" is simply an asynchronous implementation
of the loop with some FPGA-based optimization for the initial
two iterations.

A schematic representation of the (asynchronous) algorithm
can be found at
   http://eseserver1.fnal.gov/eseproj/trigger/sqrt16.pdf

(Sorry about the text formatting on my original post.  The
news poster seems to have wrapped all of my lines together.
I don't really write code like that.)

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet
Article: 8626
Subject: FPGA core for ASIC?
From: Dmitry Cherniavsky <cdm@NOSPAM.javad.ru>
Date: 14 Jan 1998 20:06:38 +0300
Links: << >>  << T >>  << A >>
  There are now a lot of IP cores makers around, that make business on
providing cores for the system-on-a-chip. Does anybody produce FPGA
cores, since FPGA is also part of system often. Does it possible at all?
-- 
 Dmitry Cherniavsky,
 ASIC designer.
 MailTo:cdm@javad.ru
Article: 8627
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: Todd KLine <tkline@wgate.com>
Date: Wed, 14 Jan 1998 13:23:49 -0500
Links: << >>  << T >>  << A >>
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
> 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 agree that the number of people using the portability of HDLs is
small, 
but we are out here.  We started our design in an Orca 2C40, migrated to
a Xilinx XC4062XL for more "leg-room," moved to a Chip Express gate
array
for initial shipping volume, and will ultimately be targeting a standard 
cell process for minimum piece price.

Our design is Schematic capture for block connectivity only and VHDL 
below that.  We use component instantiation for clock buffers only.  
Our system clock is 28.6 MHz, so we don't have PCI's 66 MHz speeds to 
deal with, but we do have 13 DMA channels including video and audio
feeds.  

We made no code changes going from Orca to Xilinx and only had to change 
the clock buffers going from Xilinx to Chip Express.  (We had to add the
clock buffer instantiations to ease the Chip Express synthesis process.)

No one can argue that a good schematic design will be smaller AND faster 
then an HDL design.  If we had used schematics, we possibly could have 
stayed in the 2C40, however, our migration to Chip Express and the 
follow-on standard cell would have been significantly harder and more
time
consuming.  

I don't have the time or the desire to develop a generic symbol set into 
which I could plug all of the possible libraries I may use.  Also, since
we knew that our ultimate target was an ASIC, an HDL was a natural
choice.
We just happened to benefit from that choice when we had to move from
Orca
to Xilinx.  

What it comes down to is use the appropriate tool for the job.  You
don't
use a hammer to pound a screw.  Don't use an HDL if speed or gate count
are your primary concerns.  Don't use a schematic if portability (or 
arguably) time-to-market is what you need.  If you need all of the
above,
good luck!

Todd
Article: 8628
Subject: Re: Xilinx 4000E Series Ram Problem
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 14 Jan 1998 18:37:47 +0000
Links: << >>  << T >>  << A >>
Ryan Herbst wrote:

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

Hold it ! It's not that bad.Our documentation just got overly careful in
warning the user that: "...excessive current and even damage to the
larger devices if many CLBs are configured as edge-triggered RAM". This
problem exists only on XC4000E devices. It is fixed on all XC4000EX and
XC4000XL devices.

The problem on XC4000E stems from a dynamic node in the write circuitry.
After the active write edge, the addressing and data lines in the RAM
are not held at a dc level, but can float. This does not affect the
write operation in any way, but it can result in poorly defined
cross-current when the input to an inverter drifts through the
half-supply-voltage range. The max current per inverter is something
like 100 microamps ( I will post the exact value later, right now I
quote from memory ). Each CLB has 18 of such nodes ( difficult to
explain why 18, please believe me ).
For a short while ( milliseconds ) after parking write clock at the
"forbidden" level, each CLB configured as a synchronous RAM can thus
conduct up to 1.8 mA, but he current disappears again as the nodes drift
away from the "bad" voltage. There is no local problem with this
current. Transistors and metal can carry that current forever, and the
localized heating is minuscule. The problem comes when large numbers of
CLBs are used this way.

An XC4010 has 400 CLBs, If each one were configured as a synchronous RAM
( a perverse assumption of a meaningless design, but it is the
worst-worst case ) then the dc current could be as high as 720 mA = 3.6
W. But it would last only a fraction of a second each time.. Well, you
might exercise this circuit again and again. That's why we are cautious.

On bigger parts, under the same unrealistic assumptions, the total
current would be proportionally larger. That's why the data book issues
that infamous warning.
We should have said:
"100 CLBs can conduct up to 180 mA i.e. up to one watt for a limited
time".
Instead we chose to say:
"Don't do this, it might hurt the device".

Sometimes it is wise to isolate the user from the gory details,
sometimes it is unwise. You be the judge.

Anyhow, the XC4000EX and XC4000XL  don't have this floating node and
tolerate, therefore, any clock High and Low time.

I hope this  clarified the situation, I will follow this up with a later
e-mail giving you the exact number. The peak current is clearly
determined by the transistor geometry. The duration depends on leakage
current and thus temperature.

Peter Alfke, Xilinx Applications
 
 

Article: 8629
Subject: SDRAM Interface from an FPGA
From: Todd KLine <tkline@wgate.com>
Date: Wed, 14 Jan 1998 13:47:16 -0500
Links: << >>  << T >>  << A >>
Hello,

Is anyone doing a synchronous DRAM interface in an FPGA?  If so, at what
speeds?  This is for ASIC prototyping only, so FPGA cost is not a big
issue.  Anybody got some Orca -20's or Xilinx -01's lying around?  :-)

SDRAMs are rated at speeds up to 100 MHz.  When my boss tells me he
wants to do this in an FPGA, I just look at him funny.

Todd
Article: 8630
Subject: Re: Asynchronous square root.
From: "Dann Corbit" <dcorbit@solutionsiq.com>
Date: Wed, 14 Jan 1998 11:52:48 -0800
Links: << >>  << T >>  << A >>
It's often called the "schoolbook" algorithm.
-- 
C-FAQ ftp sites: ftp://ftp.eskimo.com ftp://rtfm.mit.edu
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ Book: ISBN 0-201-84519-9.
Want Software?  Algorithms?  Pubs? http://www.infoseek.com

husby@fnal.gov wrote in message <884797100.345767949@dejanews.com>...
>z80@ds.com (Peter) wrote:
>
>> 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.
>
>I don't know, it could be Newton-Raphson.  It's based on an
>algorithm for long-hand square roots that my Father taught
>me when I was but a wee child:  "Multiply by 2 and shift left
>one digit."  Fortunately, this works in base 2 as well as base
>10.  There's no initial guess -- the alogorithm consumes exactly
>two bits and produces exactly 1 result bit for each iteration.
>The "Unrolled version" is simply an asynchronous implementation
>of the loop with some FPGA-based optimization for the initial
>two iterations.
>
>A schematic representation of the (asynchronous) algorithm
>can be found at
>   http://eseserver1.fnal.gov/eseproj/trigger/sqrt16.pdf
>
>(Sorry about the text formatting on my original post.  The
>news poster seems to have wrapped all of my lines together.
>I don't really write code like that.)
>
>-------------------==== Posted via Deja News ====-----------------------
>      http://www.dejanews.com/     Search, Read, Post to Usenet

Article: 8631
Subject: Byteblaster
From: "Gianluca" <xxx@xx.xx>
Date: Wed, 14 Jan 1998 22:57:39 +0100
Links: << >>  << T >>  << A >>
Does anyone know if it is possible to program a Flex10k device through a
parallel port following the schematics in the byteblaster datasheet without
using a byteblaster cable, or we must necessarily employ a byteblaster cable
?
In other words, I'm asking if the byteblaster is a simple cable or it has
some associated circuitry.

Thank you.



Article: 8632
Subject: Re: VHDL to GigaOps
From: Muhammad Hamid <mhamid@cs.wright.edu>
Date: Wed, 14 Jan 1998 16:59:18 -0500
Links: << >>  << T >>  << A >>


On 12 Jan 1998, Eric Lo wrote:

> Date: 12 Jan 1998 09:58:57 GMT
> From: Eric Lo <mflo@cse.cuhk.edu.hk>
> Newsgroups: comp.arch.fpga
> Subject: VHDL to GigaOps
>=20
> How can I transfer VHDL to GigaOps Board? How can I interface it??
> I have found in the GigaOps homepage, however, I can't nothing useful.
>=20
> Thanks
>=20
> --=20
>=20
> +------------------------------------------------------------------+
>   Eric, Lo Man Fai                         =BFc=A4=E5=BD=F7

One way to solve the problem is as follows (roughly) :

1. From the .lnk file produce a .vhd and .xnf using XGEN and XCNT
programs. This contains the interface design. (you may need to make
changes in the variable names which is restricted to some length.
ex : host_rd_data is too long...)

2. Using Xilinx Foundation, generate a macro of the interface.

3. Write user code in .vhd and convert that into macro.

4. Connect the macros (interface & design) in the schematic.

5. Convert the schematic to edn/edif netlist format and using subsequent
tools convert it to a .bit file.

I hope this helps.

-Hamid


Article: 8633
Subject: Using Xiling schematic library macro from VHDL
From: Remek Lipinski <Remek.Lipinski@sr.com.au>
Date: Thu, 15 Jan 1998 09:07:05 +1100
Links: << >>  << T >>  << A >>
Hi,

I am relatively new to VHDL and FPGAs in general and have a bit of a
problem.
I was told that it is possible to use a schematic entry macro from
within VHDL,
but I am unable to get this to work. The particular macro which I want
to use
is an 8 bit counter (CC8CLE). I define the interface and instantiate the
counter
in VHDL and then synthesise a macro from the VHDL code, all this seems
to
work. However, when I then use this macro back in schematic entry and
try and
comile it I get the following error :

ERROR:basnu - logical block "U1/CNT" of type "cc8cle" is unexpanded.

My guess is that my specification of the interface to the counter is not
right,
but I do not know how else to specify it.

I am using Foundation 1.3.

The VHDL code is I am trying to get to work is:

-- vhdl test

library IEEE;
use IEEE.std_logic_1164.all;

entity test4 is
    port (
        D_IN: in STD_LOGIC_VECTOR(0 to 7);
        L_IN: in STD_LOGIC;
        CE_IN: in STD_LOGIC;
        C_IN: in STD_LOGIC;
        CLR_IN: in STD_LOGIC;
        Q_OUT: out STD_LOGIC_VECTOR(0 to 7);
        CEO_OUT: out STD_LOGIC;
        TC_OUT: out STD_LOGIC
    );
end test4;

architecture test4_arch of test4 is
component
 cc8cle port ( D: in STD_LOGIC_VECTOR(7 downto 0);
    L: in STD_LOGIC;
    CE: in STD_LOGIC;
    C: in STD_LOGIC;
    CLR: in STD_LOGIC;
    Q: out STD_LOGIC_VECTOR(7 downto 0);
    CEO: out STD_LOGIC;
    TC: out STD_LOGIC);
end component;

begin

CNT: cc8cle port map (D=>D_IN,
                      L=>L_IN,
                      CE=>CE_IN,
                      C=>C_IN,
                      CLR=>CLR_IN,
                      Q=>Q_OUT,
                      CEO=>CEO_OUT,
                      TC=>TC_OUT);


end test4_arch;


Any help wold be greatly appreciated. Thanks.

Remek.

Article: 8634
Subject: Re: serial conf. PROMS
From: "John M. Moore" <jmoore@netgate.net>
Date: Wed, 14 Jan 1998 14:56:45 -0800
Links: << >>  << T >>  << A >>
Ivan wrote:

>   Does Atmel cary any larger EEPROMS (larger than 256K)? I also saw
> that Atmel has a programmer for the EEPROMS. Are there
> schematics/software available for the ones who would like to build it
> themselves?
>
>   Thanks, Ivan
>
> >In article <34B33324.7BFA@netas.com.tr>,
> >  Yekta Ayduk <yekta@netas.com.tr> wrote:
> >>
> >> Do serial EEPROMS exist for Xilinx configuration in the market to
> >> replace Xilinx OTP PROMS?
> >
> >Atmel makes them, for more details check out :
> >
> >http://www.atmel.com/atmel/products/prod182.htm
> >
> >Martin Mason
> >Atmel Corp.
> >
> >-------------------==== Posted via Deja News ====-----------------------
> >      http://www.dejanews.com/     Search, Read, Post to Usenet


Check out the cost of those EEPROMS. They look more expensive than standard
UV
and Flash parts in the parallel arrangement. Depending on board space and
cost
constraints, you might want to consider using a standard parallel part and a
cheap
PLD to serialize it. There are advantages to that approach for debugging
too.

Xilinx has an app note outlining this approach, along with the PLD code
(ABEL).
See http://www.xilinx.com/apps/config.htm
App note XAPP079 (PDF format).

Good luck.
John Moore
Cisco Systems

Article: 8635
Subject: Re: Jam - Anyone using it ?
From: graeme@wallaby.digideas.com.au (Graeme Gill)
Date: 15 Jan 1998 10:45:04 +1100
Links: << >>  << T >>  << A >>
Billy Bagshaw (bill@highwater.co.uk) wrote:
: 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).

Which jam ?

	Jam the the Prolifics transaction tool ? (http://jam.prolifics.com/)
	Jam the make replacement ?               (http://www.perforce.com/jam/jam.html)
	Jam the JTAG language ?                  (http://www.altera.com/jam)

(Why didn't they pick a different name for the JTAG stuff ??)

Graeme Gill.
Article: 8636
Subject: Altera FLEX10K Prototype/Development Platform
From: Paul Krotchen <paulk@novaengr.com>
Date: Thu, 15 Jan 1998 08:19:23 +0000
Links: << >>  << T >>  << A >>
Nova's Constellation FLEX 10K Development Board, and Altera's MAX+PLUS
II
software, combine to offer logic designers unprecedented simplicity and
flexibility. The 3.5" x 3.8" circuit card currently supports FLEX 10K
devices from the 10K20 up to the 10K100A, and should accommodate future
FLEX
devices such as the 10K130 and 10K180. The PC/104 form factor brings the

power of programmable logic to the widespread markets of embedded PC
systems
and desktop PC's. The stackable PC/104 architecture gives designers
access
to gate capacities in excess of 500,000 gates!

Many Constellation users are integrating Constellation boards directly
into
their products and systems. One customer application requires the
Constellation board to be plugged into a PC ISA slot. Two electronic
systems
are then physically connected through the Constellation board via ribbon

cables. The FLEX device provides custom signal processing logic while
the PC
acts as the man-machine interface. Another customer is presently
designing
the Constellation board into an embedded PC/104 system for use with
their
data communications products.

Other customers are using Constellation boards for ASIC prototyping and
logic verification. These customers typically implement their logic
designs
in Constellation boards so they can perform real-time, real-world
testing of
their products before committing the design to an ASIC. Likewise,
several
colleges and universities are using Constellation boards for research
and
senior projects. Applications include hardware accelerated algorithms,
parallel processing, and custom logic development. Large gate capacities

combined with fast and flexible configuration methods, have made the
Constellation board the logic designers choice.

Some customers are combining AMPP Megafunctions with Constellation
boards,
to provide immediate solutions to their needs. For example, one customer

uses Nova's Bit Synchronizer Megafunction and a Constellation FLEX 10K20

board to provide critical timing synchronization when testing
communications
products at low signal to noise ratios. Constellation is also ideal for
developing, testing and demonstrating Megafunctions and soft cores.

The price and availability of Constellation boards offer quick and cost
effective access to PLD hardware. The design, debug, layout, fabrication
and
test, of a circuit card similar to Constellation, would typically cost
thousands of dollars in NRE and take several weeks, if not months, to
complete. Many designers don't have access to the manufacturing
technologies
required to fabricate boards using devices with 0.0197" pin spacing.
Nova
Engineering's Constellation FLEX 10K boards are fabricated using
state-of-the-art manufacturing equipment, are fully tested and can be
purchased for under $500, with next day delivery. Each board also
includes
ISA design examples and C source code to accelerate PC/104 and ISA
designs.
Educational and quantity discounts are available.

Constellation development boards have been shipped to customers all over
the
U.S., Canada, Italy, Norway, Sweden, and Japan. Customer satisfaction
appears to be very high. (Example: www.acte.no/freecore/nova.htm).
Constellation customers include companies such as Seagate Technologies,
Altima Corp., Cleveland State University, Epson R&D, Motorola, Intel,
Escort Corp.
(a.k.a. Cincinnati Microwave), Caterpillar, San Francisco Telecom,
IOWave ,
and many more. A few customers have even upgraded their MAX+PLUS II
software
to the full featured Magnum package, so they can maximize their use of
Constellation.

Please call us at 1-800-341-NOVA or visit our Constellation web page at:

www.nova-eng.com/constellation.html for the latest technical information
and
pricing.

----------------------------
Paul Krotchen
Nova Engineering
5 Circle Freeway
Cincinnati, Ohio 45246

Email:  paulk@novaengr.com
Voice:  513.860.3456 ext102
Fax:    513.860.3535
Web:  www.nova-eng.com
----------------------------

Article: 8637
Subject: Re: Byteblaster
From: "D.H. Chung" <dhchung@soback.kornet.nm.kr>
Date: Thu, 15 Jan 1998 19:00:41 +0900
Links: << >>  << T >>  << A >>
Actually, Byteblaster is made with a 74LS744 and 4-5 registers.

Thanks

Gianluca 이(가) <69jgas$5ld@deun23.corp.newmont.com> 메시지에서 작성하였습니다...
>Does anyone know if it is possible to program a Flex10k device through a
>parallel port following the schematics in the byteblaster datasheet without
>using a byteblaster cable, or we must necessarily employ a byteblaster
cable
>?
>In other words, I'm asking if the byteblaster is a simple cable or it has
>some associated circuitry.
>
>Thank you.
>
>
>


Article: 8638
Subject: Re: Byteblaster
From: Steve Emm <steve.emm@soton.sc.philips.com>
Date: Thu, 15 Jan 1998 10:27:05 GMT
Links: << >>  << T >>  << A >>
Gianluca wrote:
> 
> Does anyone know if it is possible to program a Flex10k device through a
> parallel port following the schematics in the byteblaster datasheet without
> using a byteblaster cable, or we must necessarily employ a byteblaster cable
> ?
> In other words, I'm asking if the byteblaster is a simple cable or it has
> some associated circuitry.
> 
> Thank you.

We made our own byteblaster from a datasheet (not sure if it is the same
as the one you have) and it is very simple. A 74HCT244 is the only IC
involved and a few resistors. Pennies to make when the one from Altera
cost ~120 pounds sterling. The only problem we had was that when we
daisy chained several 10K devices together, we got write failures which
were dependent upon the I/O card we were using. This was strange because
the 244 fully isolates the 10K devices from the I/O port. We found that
older I/O cards could program at least 5 devices, whilst a modern card
could only manage about 2.

Steve.
-- 
******************************************************************
* Steve Emm, Philips Semiconductors, Southampton, U.K.           *
* email: steve.emm@soton.sc.philips.com  (seri: semm@ukpsshp1)   *
* tel  : +44 1703 316544                 (fax : +44 1703 316303) *
******************************************************************
Article: 8639
Subject: Re: Xilinx Configuration Problem
From: Rick Filipkewicz <rick@xxxxz.co.uk>
Date: Thu, 15 Jan 1998 10:57:55 +0000
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> 
> In article <01bd1c3f$fa791ac0$6aef1fce@przebienda.acromag.com>, "Louis Przebienda" <lprzebienda@acromag.com> writes:
> 

> If you are using something like a well mounted power brick
> your best bet is probably one of the magic voltage-watcher
> chips.  I gave up on RC time-delay kludges ages ago.
> 

Yes we gave up on RC and have been using the Texas TL7705 for 10+ 
years! In small amounts they cost us 0.28 = about 45 cents. And 
that's here in the U.K.

They un-reset Td after VCC reaches 4.55V where Td can be varied with
an external capacitor.

-- 

_________________________________________________________________________

 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: 8640
Subject: Re: Byteblaster
From: "Paul Baxter" <paje@globalnet.co.uk>
Date: 15 Jan 1998 14:23:48 GMT
Links: << >>  << T >>  << A >>
Checkout the freecore home page for the circuit!

try

http://193.215.128.3/freecore/

The page is well worth a look if you use Altera EPLD products

Paul


D.H. Chung wrote
> Actually, Byteblaster is made with a 74LS744 and 4-5 registers.
> 
> Gianluca wrote 
> >Does anyone know if it is possible to program a Flex10k device through a
> >parallel port following the schematics in the byteblaster datasheet
without
> >using a byteblaster cable, or we must necessarily employ a byteblaster
> cable
Article: 8641
Subject: Re: Byteblaster
From: vic@alpha.podol.khmelnitskiy.ua (Victor Levandovsky)
Date: Thu, 15 Jan 1998 19:33:10 GMT
Links: << >>  << T >>  << A >>
On Thu, 15 Jan 1998 19:00:41 +0900, "D.H. Chung"
<dhchung@soback.kornet.nm.kr> wrote:

Yes, but my Byteblaster is made with a LS244, 7 resistors and 2
capacitors.

Good luck,

Victor Levandovsky


>Actually, Byteblaster is made with a 74LS744 and 4-5 registers.
>
>Thanks
>
>Gianluca 이(가) <69jgas$5ld@deun23.corp.newmont.com> 메시지에서 작성하였습니다...
>>Does anyone know if it is possible to program a Flex10k device through a
>>parallel port following the schematics in the byteblaster datasheet without
>>using a byteblaster cable, or we must necessarily employ a byteblaster
>cable
>>?
>>In other words, I'm asking if the byteblaster is a simple cable or it has
>>some associated circuitry.
>>
>>Thank you.
>>
>>
>>
>
>

Article: 8642
Subject: XC6200 Questions
From: herman@galant.ece.cmu.edu (Herman Schmit)
Date: 15 Jan 1998 20:37:51 GMT
Links: << >>  << T >>  << A >>
Does anybody have synopsys libraries for the Xilinx 6200?  

Also, has anybody booted the XC6200 using a serial PROM and then
switched it into parallel mode to reconfigure when it is running?  Can
you describe any tricks that are necessary to get this to work
correctly?  (I haven't tried it yet, but I want to know if there are
any snafus that I can avoid.)

Herman

------------------------------------------------
Herman Schmit, Ph.D., Research Engineer
Department of Electrical and Computer Engineering
Carnegie Mellon University
5000 Forbes Ave., Pittsburgh PA 15213
Tel: (412) 268-6470	FAX: (412) 268-3204
email: herman@ece.cmu.edu
Article: 8643
Subject: Re: Using Xiling schematic library macro from VHDL
From: Bob Flatt <bobf@fishes.com>
Date: Thu, 15 Jan 1998 15:49:46 -0800
Links: << >>  << T >>  << A >>
> I was told that it is possible to use a schematic entry macro from
> within VHDL,
......
> comile it I get the following error :
> 
> ERROR:basnu - logical block "U1/CNT" of type "cc8cle" is unexpanded.
> 
> My guess is that my specification of the interface to the counter is not
> right,
> but I do not know how else to specify it.

You dont say what your schematic port names are, but problem might be the expantion of VHDL array port names matching schemtic port names.

By default this is :

  (cell cc8cle (celltype GENERIC) (view view_1 (viewType NETLIST)
    (interface 
     (port (rename D_7 "D<7>") (direction INPUT))
     (port (rename D_6 "D<6>") (direction INPUT))
     (port (rename D_5 "D<5>") (direction INPUT))
      ........

You can change this to :

  (cell cc8cle (celltype GENERIC) (view view_1 (viewType NETLIST)
    (interface 
     (port D7 (direction INPUT))
     (port D6 (direction INPUT))
     (port D5 (direction INPUT))
      ........

which might be what your schematic netlists to.
 
By adding the following after the component declaration in your VHDL.

    attribute macrocell : Boolean;
    attribute macrocell of cc8cle : component is true;

See also the section Synthesis Attributes in vhdl_mug.hlp
Article: 8644
Subject: Re: Xilinx Stock
From: arnim@atlantis.actrix.gen.nz (Arnim Littek)
Date: 16 Jan 98 01:47:41 GMT
Links: << >>  << T >>  << A >>
In article <34B90D3F.A75@ids.net>,
Ray Andraka  <no_spam_randraka@ids.net> wrote:
>what is inside the function. I continue to believe that a well laid out
>schematic is much more readable than HDL code.  I will admit that it is
>easier to put comments on an HDL design (but I also think they are more
>necessary there).

Hear, hear!  completely in concurrence...

This depends quite heavily on one's choice of schematic pkg, of course.
For instance, one of my colleagues frequently has more lines of 
explanatory text on his schematics than drawn line segments.  But, 
they're still easier to see through (for me) than pages of VHDL...

>as with schematics.  In both cases, the development of a heirarchical
>library of lower level functions speeds the design process in subsequent
>projects.

Again, some thought given to the structure of schematic libraries and
their extension, goes a long way to making abstraction just as useful
in schematic capture as it is for an HDL...

>I've always found it a bit amusing to observe that the electronics
>design industry is pushing away from a graphical design methodology
>(schematics) while most other disciplines are flocking toward graphical
>user interfaces.

Two further points:

One sees that HDL tools are laying graphical assists on top of the
text-based tools (FSM tools, Summit's block diagrammer, etc.).

Secondly, its horses for courses - use each as it might seem appropriate,
and that means for me that I don't want GUI tools stuffed down my 
throat either, like this lemming-like march towards NT.

FWIW,

Arnim.
-- 
Arnim Littek                                    arnim@actrix.gen.nz
Actrix Networks Ltd.                            fax +64-4-801-5335
uucp/PPP/SLIP/BBS accounts                      tel +64-4-801-5225
Article: 8645
Subject: Re: Clock net skew simulation
From: "richard katz" <stellare@erols.com.NOSPAM>
Date: 16 Jan 1998 05:19:32 GMT
Links: << >>  << T >>  << A >>
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.

rk writes:
: >Me types here, possibly too early in the morning, slightly insulted. :-)

philip lands nicely on his feet:
: No insult was intended. I'm sorry. It was meant as humor, since I knew 
: you were using Actel chips.

oops, sorry, thought it was a nasty-gram directed at me for someone elses
clock skews.  and comments like that are not good for business!  perhaps
next time put a smiley on - it would help, esp. when it's early in the
a.m.!

as for actel, it is *EASY* to get into clock skew trouble.  with the
a1020's you had to be a bit careful and for good solid hold times it
sometimes pays to go in with chipedit and move some stuff around, esp. w/
wide temp range.  and ppl still do designs with the old a1020 2.0 stuff. 
but with their newer clock designs they do really really well.  i heavily
loaded them (day job) with some long shift registers and they always worked
well - both in simulation and in temp testing: -55C to +125C.  but with act
3 and separate i/o clock network, again, gotta watch that skew.  the major
source of clock skew problems is when people new to the fpga architectures
do board design in an fpga and assume that a wire on the chip is like a
track on a pcb.  can't see any delay elements there and it does look good
even when not on a global net on the schematic.  another way ppl get into
trouble is with running a non-global clock into a soft macro such as a
parallel counter or a shift register.

rk babbles on:
: >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?

philip replies:
: 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.

rk replies to philip:
as for the back annotation of clock skews into the logic simulators,
perhaps peter or stu or john or hans [philly hans, not england hans]
(listed in no particular order) can answer.  if i get some time, i'll try
the actel -> viewsim path.  if i get a real lot of time (prob. in 15 years
when kids leave the house), i'll do the q-logic -> viewsim path, as i just
finished my first q-logic pasic3 design.

now, from my simulation experience, i have found that clock skew is w.c. at
high volt, low-temp case, best process. and with at least actel static
timing analysis tools (timer or dtanalyze) the temperature, voltage,
process corner is selectable for analysis.  also, you can specify whether
you want max or mins reported.  for max the tsu is included; for mins it is
not.  for min the th is reported and included, for max it is not.  IIRC
(somebody with a better memory please chime in), tskew used to be reported
and included in the calculations.  i just ran a sim in 3.1.1 update 1 and
didn't see the skew reported.

anyways, it's not that bad to have the static timing analyzer report all of
the clock delays to each of the clock pins to determine max skew, for each
given condition.

also, with limited experience w/ spde (q-logic), it seemed not too bad to
set the conditions.  details of calculations i can't comment on yet.

philip finshes up:
: Sorry again for the un-intended insult.

rk adds:
np, worst-things have happenned.  glad it all worked out quickly, who needs
hassles here?  that's what day jobs are for :-)

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

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
Article: 8646
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: "richard katz" <stellare@erols.com.NOSPAM>
Date: 16 Jan 1998 05:19:33 GMT
Links: << >>  << T >>  << A >>
rk chimed in:
: > and as stu pointed out, the designs are
: > more portable,
 
austin replies:
: 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...

rk wisecracks:

... nor quite as easy unless care is taken up front to make hdl code
portable, esp. when switching synthesis tools and architectures.  but it
will be interesting to find out.  i remember, back in the '80s, when we
were into writing portable c code, they told us how easy it was ...
... and i did as much coding as possible, secretly in pascal.

austin continues:
: 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.


rk agrees and disagrees:

i've done stuff like that too - although not for performance driven
designs.  another benefit is that it lets you use a single set of tools for
design like a good macro generator (big fan of them).  then just replace
primitive hard macros and you're in there.  more or less.

but the architectural differences can hurt you, in my opinion.  either in
time for tuning, size of circuit, or for circuit speed.  for example, for
an xor tree (important for pci) you can design a simple tree of xor gates,
logically correct.  but an implementation tuned to the architecture can be
much faster by taking into account the fpga 'module' resources.  i've seen
the output of a good macro generator and it would be tough to beat, if
possible, in quality (i.e., final circuit speed) although i hate to admit
it.  and other architecures with good-sized sram blocks could do table
lookup algorithms which wouldn't mesh well with a gate by gate translation.
 programmable clock signal polarity for flip-flops: if an architecture
doesn't support that directly, compensating for that by making a logical
equivalent would have hold time problems when the real solution would be to
use either the inverted clock tree if available or a separate clock tree. 
of course you could design a logically equivalent circuit and only use 1
edge but you burn more power in the clock distribution network.  another
factor is the available function in the i/o cells: i have seen the
following for storage in the i/o: zip, two latches, two flip-flops w/
enables, only an input flip-flop, some with feedback into the array so you
can use unused pins modules for logic, etc..  in schematics this would have
to be hand tuned.  would a good hdl synthesis tool take this into account
and do the shuffling around for the designer?  i would hope so.  it would
have to to make things high quality and portable and shield the designer
from the architecture.  another case would be the availability of f-f's
with negative outputs.  some architectures got 'em, some don't.  again, the
virual hard macro library here would work logically but not for maximum
performance, unless a netlist optimizer could pick up the slack and combine
things appropriately.  a last example would be counters: some architectures
you can do real compact, high-speed, low-power ripple counters - some
architectures don't let you and make you drive a whole column of clocks. 
some architectures are better at decoding terminal counts of 0000...000
than 1111...111 so it would favor down counters rather than up.  so state
assignment can be critical.  are the hdl tools good enough to take this
into account?  is there still room for good humanoid gate-slingers? :-) 
i've heard a bunch of ppl say no - they haven't used a schematic in ages
and get upset at the thought of using schematics.  even to hook up
reasonably sized blocks implemented in hdl.

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

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
Article: 8647
Subject: Re: Xilinx Stock
From: madarass@cats.ucsc.edu (Rita Madarassy)
Date: 16 Jan 1998 07:30:38 GMT
Links: << >>  << T >>  << A >>

It is true some people would rather "picture" the design than
to read behavioral code. Although I agree HDL is far more efficient
I do like to get a structural idea of what is going on in my code.

My preference is to have a top level schematic instantiating lower
level macros in either HDL or Schematic depending on the timing requirements.


In article <34bebc3d.0@news.actrix.gen.nz>,
Arnim Littek <arnim@atlantis.actrix.gen.nz> wrote:
>In article <34B90D3F.A75@ids.net>,
>Ray Andraka  <no_spam_randraka@ids.net> wrote:
>>what is inside the function. I continue to believe that a well laid out
>>schematic is much more readable than HDL code.  I will admit that it is
>>easier to put comments on an HDL design (but I also think they are more
>>necessary there).
>
>Hear, hear!  completely in concurrence...
>
>This depends quite heavily on one's choice of schematic pkg, of course.
>For instance, one of my colleagues frequently has more lines of 
>explanatory text on his schematics than drawn line segments.  But, 
>they're still easier to see through (for me) than pages of VHDL...


For some reason, I never found comments in schematic to be very useful.
But in HDL they certainly help when you inherit a design done by
another engineer. HDL is definitely easier to upgrade.


>
>>as with schematics.  In both cases, the development of a heirarchical
>>library of lower level functions speeds the design process in subsequent
>>projects.
>
>Again, some thought given to the structure of schematic libraries and
>their extension, goes a long way to making abstraction just as useful
>in schematic capture as it is for an HDL...
>
>>I've always found it a bit amusing to observe that the electronics
>>design industry is pushing away from a graphical design methodology
>>(schematics) while most other disciplines are flocking toward graphical
>>user interfaces.
>
>Two further points:
>
>One sees that HDL tools are laying graphical assists on top of the
>text-based tools (FSM tools, Summit's block diagrammer, etc.).
>
>Secondly, its horses for courses - use each as it might seem appropriate,
>and that means for me that I don't want GUI tools stuffed down my 
>throat either, like this lemming-like march towards NT.


I believe it depends on how the options are implemented in the GUIs.
In FPGA Express it is extremely difficult to add, for example, pin
locations. However, I consider synplicity to be one step ahead since
most of the options (almost none) are available in the GUIs.
Basically, all you have to do is to press the RUN button.

Hernan Saab
>
>FWIW,
>
>Arnim.
>-- 
>Arnim Littek                                    arnim@actrix.gen.nz
>Actrix Networks Ltd.                            fax +64-4-801-5335
>uucp/PPP/SLIP/BBS accounts                      tel +64-4-801-5225


Article: 8648
Subject: Re: Implementing Altera FIFOs without EABs
From: "D.H. Chung" <dhchung@soback.kornet.nm.kr>
Date: Fri, 16 Jan 1998 19:04:21 +0900
Links: << >>  << T >>  << A >>
The /bin directory of Max+PlusII(only for workstaion version), you can find
the utility called genmem, which generate VHDL/Verilog HDL model for
memories Altera supports. You can only use EABs when you are implementing
CSFIFO(actually you can but you need huge logic cells to create this, which
depends on the size of memory you want)with Altera device but you can have
HDL model for those memories implemented in EAB. So you can use this file
when you want to go ASIC.

Thanks
D.H.
Greg Hoffman 이(가) <34BC0CDE.1914@adichi.com> 메시지에서 작성하였습니다...
>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: 8649
Subject: Re: XC6200 Questions
From: Frank Gilbert <gilbert@informatik.uni-kl.de>
Date: Fri, 16 Jan 1998 11:28:29 +0100
Links: << >>  << T >>  << A >>
Herman Schmit wrote:
> 
> Does anybody have synopsys libraries for the Xilinx 6200?

We do have. The libraries for Synopsys DC are included in the
SunOs-version of XACTStep 6000.

> 
> Also, has anybody booted the XC6200 using a serial PROM and then
> switched it into parallel mode to reconfigure when it is running?  Can
> you describe any tricks that are necessary to get this to work
> correctly?  (I haven't tried it yet, but I want to know if there are
> any snafus that I can avoid.)

Sorry, but I never tried this!

Hope that helps.

Frank
____________________________________________________________________

    LOOK AT OUR WEB SERVER:  http://xputers.informatik.uni-kl.de

Frank Gilbert                       | University of Kaiserslautern
mailto:gilbert@informatik.uni-kl.de | Dept. of Computer Science 
   fax: ++49/0 631 205 2640         | Germany 

..._/  _/  _/_/_/  _/  _/ _/_/_/ _/_/_/  _/_/_/   _/_/ ....._/
..._/_/   _/   _/ _/  _/   _/   _/      _/   _/ _/  ......._/_/
..._/    _/_/_/  _/  _/   _/   _/_/_/  _/_/_/   _/_/ ._/_/_/_/_/
._/_/   _/      _/  _/   _/   _/      _/   _/     _/ ...._/_/
_/  _/  _/       _/_/    _/   _/_/_/  _/    _/ _/_/ ....._/


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