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 6975

Article: 6975
Subject: request for Xilinx 6200 FPGA mappings
From: Matt Hosler <mhosler@nwu.edu>
Date: Thu, 17 Jul 1997 22:34:29 -0500
Links: << >>  << T >>  << A >>
I am currently working on improved compression techniques for partial
reconfiguration of the Xilinx 6200 series FPGAs.  I am hoping to find
some 6200 mappings (specifically in the form of .cal files)
that I could use as test data for my compression techniques.

If you have any 6200 mappings that I could use in this project, please
contact me.

Thank you for your help.

Matt Hosler
Northwestern University
Article: 6976
Subject: Re: FPGA design tools
From: Richard Schwarz <aaps@erols.com>
Date: Thu, 17 Jul 1997 23:45:05 -0400
Links: << >>  << T >>  << A >>
You would need placement tools (router for each vendor). It is usually
cheaper to get packages for specific vendors. For instance if you new
you were going to use XILINX, you could get the APS FOUNDATION Kits
which include VHDL compiler/schematic capture and VHDL tutorial, plus an
FPGA Development board with examples and C templates, all for $2800.00.
However if you need to Synthesize many vendors you could use our
Synth-All VHDL compiler which works for Actel ACT1, ACT2, ACT3, ACT-32
EDIF,Altera All devices EDIF AMD/Vantis MACH Devices DSL Lattice PLSI
EDIF, Lucent ORCA EDIF, Quicklogic pASIC EDIF, Xilinx 3K, 4K, 4Ke, 4Kex,
5K, 7K, 9K XNF, EDIF. This package can be gotten for $4200.00, and
synthesizes all the parts mentioned and can be purchased with Routers
and test boards. Other vendors like Synopsis, Exemplar, and Synplicity
are also good multivendor syntheis packages. You can see our stuff at
http://www.associatedpro.com/aps  Feel free to email me with any other
questions you might have.

--
----------------------------------------------------------------
Richard Schwarz,     President
Associated Professional Systems (APS)
EDA and Communications Tools
http://www.associatedpro.com
richard@associatedpro.com
410.569.5897  fx:410.661.2760


Article: 6977
Subject: Re: Problem with unexpanded logic in xnf synhesized by Leonardo
From: david.storrar@gecm.com (David Storrar)
Date: 18 Jul 1997 07:41:24 GMT
Links: << >>  << T >>  << A >>
In article <33CE0B2D.2153@martis.fi>, Mark Sandstrom says...
>
>Hi,
>
>I get an error of unexpanded logical blocks when trying to 
>map a xnf synthesized by Leonardo to an xc4000 fpga.
>
>How can get over that?
>
>Any advice is appreciated!
>
>Best regards,
>
>        Mark H. Sandstrom
>
>
>Belowe are excerpts of the Leonardo and M1 runs:
> 
[snip transcripts]

Mark,

Your problem is due to the currently unsupported interface 
between Leonardo and M1.  What you have to do is - before 
writing out your netlist - decompose the LUTs.  This is in the 
Optimise menu.  Your design will then be described in terms of 
gates and M1 can then do the LUT mapping.

I have been told that the next release of Leonardo will support 
the M1 EDIF flow - but then, according to Mentor/Exemplar, all 
the world's problems are fixed in the next release :-)

Hope this helps.

David Storrar
Development Engineer
GEC - Marconi Avionics
Radar Systems Division


Article: 6978
Subject: Re: Problem with unexpanded logic in xnf synhesized by Leonardo
From: Mark Sandstrom <Mark.Sandstrom@martis.fi>
Date: Fri, 18 Jul 1997 16:50:23 +0300
Links: << >>  << T >>  << A >>
David Storrar wrote:
> 
> In article <33CE0B2D.2153@martis.fi>, Mark Sandstrom says...
> Mark,
> 
> Your problem is due to the currently unsupported interface
> between Leonardo and M1.  What you have to do is - before
> writing out your netlist - decompose the LUTs.  This is in the
> Optimise menu.  Your design will then be described in terms of
> gates and M1 can then do the LUT mapping.
> 
> I have been told that the next release of Leonardo will support
> the M1 EDIF flow - but then, according to Mentor/Exemplar, all
> the world's problems are fixed in the next release :-)
> 
> Hope this helps.
> 
> David Storrar
> Development Engineer
> GEC - Marconi Avionics
> Radar Systems Division


Thank you, David!

It was worthwile to learn that Leonardo -> M1 interface is not yet
supported. I'm using Leonardo V4.0.3 and M1.2.11.

I tried decomposing the LUTs before writing out the xnf, but I got 
the same errors about unexpanded logical blocks from M1 during the
logical DRC that preceeds mapping.
With edif (LUTs decomposed or not) I get errors already during the
M1 ngdbuild -program.

So my problem has not been solved yet.

Best regards,

	Mark H. Sandstrom
Article: 6979
Subject: Clock generator
From: tivpc@geocities.com (Gianpaolo Scassellati)
Date: Fri, 18 Jul 1997 14:05:27 GMT
Links: << >>  << T >>  << A >>
How can I implement a clock generator in a Altera device ?
(Vhdl or Ahdl)
I need to specify clock frequency, so I cannot make a simple feedback
chain.

Thanks.
Article: 6980
Subject: Production testing of Design with CPLD's
From: Klaus Falser <"Klaus Falser<durst"@durst.it>>
Date: Fri, 18 Jul 1997 14:15:10 +0000
Links: << >>  << T >>  << A >>
Hello,
can anybody recommend me some literature about production testing when
using CPLD's?
Is it really true, that the design inside the CPLD must not be tested an
can be assumed as working correctly (apart from design errors)? Does it
make sense to have test pins where internal signals can be monitored?

I'm very gratefull for every hint I can get.
Thank you very much
    K. Falser

Article: 6981
Subject: Re: Generating Sine/Cosine digitally
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 18 Jul 1997 08:54:57 -0700
Links: << >>  << T >>  << A >>
The phase-accumulating sine-wave generator was described in the 1993 and
1994 Xilinx data books, page 9-18.

Peter Alfke, Xilinx Applications
Article: 6982
Subject: Xabel mapping into xilinx
From: kho@phobos.gent.bg.barco.com (Kim Hofmans)
Date: 18 Jul 97 13:51:08 CET
Links: << >>  << T >>  << A >>
Hi,

does somebody know how one can force the mapping of equations (written in
xabel) into Fmaps and Hmaps ?
The only option I know is : xilinx property map ...
But this forces only the mapping into one CLB and not into Fmaps or Hmaps.

Tnx in advance,

Kim
Article: 6983
Subject: FPGA design tools
From: sidhu@halcyon.usc.edu (Reetinder P. S. Sidhu)
Date: 18 Jul 1997 15:18:12 -0700
Links: << >>  << T >>  << A >>
Hi

	Our research group is interested in 

1. Designing using HDL/schematic entry tools,
2. Simulating the placed and routed design on various vendors' FPGA
architectures.

	We understand that for step 1 architecture independent tools
from Synopsys/Viewlogic can be used.

	But it is not clear what is required for step 2. Would
libraries of some sort for each architecture suffice? Or is separate
place and route software from each vendor required for each
architecture?

	Thanks in advance for advice.

Article: 6984
Subject: Re: Problem with unexpanded logic in xnf synhesized by Leonardo
From: Ruth Mayeda <ruth.mayeda@xilinxZZZ.com>
Date: Fri, 18 Jul 1997 15:42:04 -0700
Links: << >>  << T >>  << A >>
Mark,

This looks like 2 separate, but similar issues:

When you compile your VHDL code, Leonardo reports that it can't
find an "entity binding" for the RAMDATA component.  I'm not
familiar with Exemplar, so I can only guess that this means it
can't find a VHDL description for this component.  If you have
an XNF file for this component, then M1 should be able to
merge this in.  Since NGDBUILD 1.2.11 seems to be unable to
locate the XNF file, you can run XNFMERGE foom the XACT 5.2/6.0 
toolset before running NGDBUILD (but read the next paragraph first).

The other "unexpanded blocks" are XBLOX components.  You have
2 choices: prevent Leonardo from inferring the XBLOX components,
or process the design using the XACT 5.2/6.0 tools up to an
XTF file, then run NGDBUILD on the XTF file.

Mark Sandstrom wrote:
> Hi,
> 
> I get an error of unexpanded logical blocks when trying to
> map a xnf synthesized by Leonardo to an xc4000 fpga.

<snip>

> Leonardo - V4.0.3

<snip>

> -- Compiling entity ram_memgen(spec)
> "gma.vhd",line 1746: Warning, component ramdata has no visible entity
> binding.

<snip>

> {rausku:mark} [7] % ngdbuild -p xc4028xlhq208 gma gma.ngd
> ngdbuild:  version M1.2.11
> Copyright (c) 1995-1997 Xilinx, Inc.  All rights reserved.
> 
> Launcher: Using rule XNF_RULE
> Launcher: gma.ngo being compiled because it does not exist
> Launcher: Running xnf2ngd from /asic2/gma/xilinx/
> Launcher: Executing xnf2ngd -p xc4000xl -u "gma.xnf" "gma.ngo"
> xnf2ngd:  version M1.2.11
> Copyright (c) 1995-1997 Xilinx, Inc.  All rights reserved.
>    using XNF gate model
>    reading XNF file 'gma.xnf' ...
>    writing NGO file 'gma.ngo' ...
> Launcher: xnf2ngd exited with an exit code of 0

<snip>

> Running Logical Design DRC...
> WARNING:basnu - logical block
>    'instance_xbus_sc1_converter_instance_rx1cas_dpram_u1' with type
> 'ramdata' is
>    unexpanded
> WARNING:basnu - logical block
>    'instance_xbus_sc1_converter_instance_rx1data_dpram_u1' with type
> 'ramdata'
>    is unexpanded
> ...
> WARNING:basnu - logical block
> 'instance_mc_sbus_if_instance_mc_if_modgen_5_p1'
>    with type 'MUXBUS' is unexpanded
> WARNING:basnu - logical block
> 'instance_mc_sbus_if_instance_mc_if_modgen_5_bd1'
>    with type 'BUS_DEF' is unexpanded
> WARNING:basnu - logical block
> 'instance_mc_sbus_if_instance_mc_if_modgen_5_q0'
>    with type 'ELEMENT' is unexpanded
> WARNING:basnu - logical block
>    'instance_mc_sbus_if_instance_mc_if_modgen_5_q0_duplicate_name_0'
> with type
>    'ELEMENT' is unexpanded

<MAP output snipped, NGDBUILD warnings become MAP errors>

=====================================================================
/ /\/  Ruth Mayeda                   E-mail:  hotline@xilinx.com 
\ \    Applications Engineer            Tel:  1-800-255-7778 
/ /    Xilinx, Inc.                     
\_\/\  2100 Logic Drive                 Web:  http://www.xilinx.com
       San Jose, CA 95124
=====================================================================
Article: 6985
Subject: Re: free FPGA software from actel
From: "L. Kumpa" <LKumpa@nonet.net>
Date: 19 Jul 1997 15:22:46 +0200
Links: << >>  << T >>  << A >>


The "Try Actel Software / Free Software!" link is STALE...  (19/7/97)



Herbert Kleebauer <klee@mistress.informatik.unibw-muenchen.de> wrote in
article <5qklqc$s9h@thorgal.et.tudelft.nl>...
> Has somebody tested the free actel software? Is it worth to download?
> Is programmer support included? Is the ACTIVATOR needed or is there
> a free design for a simple programming hardware.
> 
> If Vielogic would release the old DOS Workview as freeware this maybe
> could be a good system for homberew chips.
> 
> -------------------------------------------------------------------------

Article: 6986
Subject: Re: FPGA design tools
From: timolmst@cyberramp.net
Date: Sat, 19 Jul 1997 13:34:17 GMT
Links: << >>  << T >>  << A >>
sidhu@halcyon.usc.edu (Reetinder P. S. Sidhu) wrote:

>Hi

>	Our research group is interested in 

>1. Designing using HDL/schematic entry tools,
>2. Simulating the placed and routed design on various vendors' FPGA
>architectures.

>	We understand that for step 1 architecture independent tools
>from Synopsys/Viewlogic can be used.

>	But it is not clear what is required for step 2. Would
>libraries of some sort for each architecture suffice? Or is separate
>place and route software from each vendor required for each
>architecture?

>	Thanks in advance for advice.

ORCAD has a tool that they call EXPRESS, which will handle your
question #1 above. It will allow you to write a design in VHDL, and
re-target at will among the supported FPGA vendors, which are :ACTEL,
AMD, ALTERA, LATTICE, and XILINX.. It DOES, however, require that you
have the back-end place and route tools for each vendors FPGA's.
EXPRESS acts as a front-end design entry tool for the vendors tools.
It does do an admirable job of  letting you move a design between
vendors.

Article: 6987
Subject: Survey
From: zoltank@shell02.ozemail.com.au (Zoltan Kocsi)
Date: 19 Jul 1997 14:09:56 GMT
Links: << >>  << T >>  << A >>
This is a survey form in which I'd like to gather some statistics
about Linux in embedded system development work.
(If you prefer one of the free BSD variants over Linux, then treat the 
word Linux as *BSD just tell me what do you mean by it.)

If you are in embedded systems design, could you please fill out the 
following survey and post it back to me. 

All data is kept confidential (well, as confidential as email on the net is),
final (statistical) result will be posted back to these groups and may 
also 
be published in a technical magazine.
There is no commercial gain associated with this survey, it's more of my 
curiosity than anything else. Your help would be much appreciated and
I can promise a 'Thank you' for every reply :-)
Please don't send hate mail, spam, flames, OS religious war letters and 
other goodies.

Could you please send replies to zoltan@bendor.com.au (It would be more 
convenient to me, that's all).

Thanks in advance,

Zoltan

The survey:
------------

Do you design

1.1 Hardware
1.2 Software
1.3 EPLDs/FPGAs

What operating system(s) do you use for

2.1 HW design
2.2 SW design
2.3 chip design

3. Do you know about Linux (or any other free unix variant) ?
   (heard about it, saw it, use(d) it, wrote it :-)

4. If all the tools you need were available, would you use Linux instead of
   Windows XX or commercial unix versions (or any other OS) ?
   (Assuming that your managers let you choose what you want.)
   
5. If you are a Linux fan :-) and happen to be in embedded systems, and you
   are still not bored to death by this survey, what (commercial or free) 
   tools do you know that can be used in such a design process apart from
   the obvious like gcc, gdb, gnu make perl e.t.c.
   
6. Do you work for a small or large organisation (by your scale) ?   

That's all, thanks again.

Article: 6988
Subject: Re: Clock generator
From: Symon Brewer <symon.brewer@wago.de>
Date: Sat, 19 Jul 1997 16:12:14 +0100
Links: << >>  << T >>  << A >>
Dear Gianpaolo,
	You could use a recirculating adder scheme. For instance you could have
a 20 bit accumalator which, on each clock cycle, adds its present sum to
a value you set in a register. If you clock this circuit at 2^20 Hz,
1048576
Article: 6989
Subject: Re: Clock generator
From: Symon Brewer <symon.brewer@wago.de>
Date: Sat, 19 Jul 1997 16:23:10 +0100
Links: << >>  << T >>  << A >>
Dear Gianpaolo,
        You could use a recirculating adder scheme. For instance you
could have a 20 bit accumulator which, on each clock cycle, adds its
present output to a value you set in a register. If you clock this
circuit at 2^20 Hz, 1048576 Hz, then the carry out bit from the
accumulator toggles at the frequency specified in the register. For
example, If you write 1 to the register the carry occurs at 1Hz. You use
this carry as your generated clock. It may have jitter, depending on the
frequency set, of course.
	You can modify this technique to work at different clock speeds by
changing the modulus of the accumulator to coincide with the clock speed
you wish to use. Using a clock speed which is a power of two keeps the
circuit simple.
	I hope this helps. Symsx.
Article: 6990
Subject: fpga
From: Ron N. Boissoneault <arby@ix.netcom.com>
Date: Sun, 20 Jul 1997 04:15:35 GMT
Links: << >>  << T >>  << A >>

Article: 6991
Subject: Larger designs with Lattice fitter ???
From: albo@pi.net (Alfred Bos)
Date: Sun, 20 Jul 1997 12:50:04 GMT
Links: << >>  << T >>  << A >>
Hi,

I'm trying to get aquainted with the IspLsi and pLsi series from
lattice. I'm must admit they're fun to play around with. But I'm
trying to get some bigger design in them...but the fitter that
actually translate my design only accepts the smallest one  : 1016.

I would like to use some bigger ones, I've found out that the only
reason that I can't use bigger ones is the fact that the fitter
program doesn't know them (Pds+). Only  files in the config directory
of the fitter program wrt the 1016 are available.

Could someone help me finding these addional files, I think they have
extensions like *.TDF and *.SDF.

Cya,
	Alfred.
Greetings,
     Alfred Bos (albo@pi.net)

Article: 6992
Subject: GAL Programmer
From: "Marcin Czeczko" <czeczmar@polbox.com>
Date: 20 Jul 97 13:17:03 GMT
Links: << >>  << T >>  << A >>
I`M	Looking for Gal programmer
-- 
Marcin Czeczko
InterNet:  czeczmar@polbox.com
                marcin@most-wanted.com
FidoNet:  2:481/42.8
Article: 6993
Subject: Re: FPGA design tools
From: Martin Vorbach <Martin.Vorbach@SCRAP.de>
Date: Sun, 20 Jul 1997 16:07:54 +0200
Links: << >>  << T >>  << A >>
> Or is separate
> place and route software from each vendor required for each
> architecture?
> 
	[M.Vorbach]  The question is, what kind of chip do you want to
design? If you design FPGAs you need the FPGA-software from Altera or
Xilinx or somebody else. This software includes the FITTER (similar to
an automatic floorplanner) and all libraries.

	If you want to design ASICs you need the library of your ASIC
vendor for the synthesis. Also you should do in newer technologies
(<0.5um) floorplanning. Good tools are avaiable from SYNOPSYS or
COMPASS.


Best regards
Martin


martin.vorbach@scrap.de
Fon +49 721 97243 35
Fax +49 721 97243 28



Article: 6994
Subject: AM186 to P/C104 PLD design
From: Malcolm Bugler <100551.3163@CompuServe.COM>
Date: 20 Jul 1997 17:25:14 GMT
Links: << >>  << T >>  << A >>
I need some assitance in implementing a AM186ES embedded 
processor to the P/C104 bus. 

Has anyone got any ideas on this or could point me in the right 
direction?

Thanks

-- 

Article: 6995
Subject: PCI burst transfers
From: jhallen@world.std.com (Joseph H Allen)
Date: Mon, 21 Jul 1997 03:17:01 GMT
Links: << >>  << T >>  << A >>
Suppose I'm doing a read burst.  The target must watch the IRDY# line from
the initiator to determine whether to hold the current read data or to send
out the next word.  IRDY# can arrive as late as 7ns before the clock edge,
and the data must be out by 11ns after to the clock edge- thus you have 18ns
for this decision to occur, including pad propagation delays and big routing
delays between IRDY# and (perhaps) an output mux.  Is this correct or am I
missing something here?

This sucks big time, if true.  It means you can't use pad output flip-flops
for the bus (once IRDY is received it's too late to change the data in any
output flip-flops).  The only way I thought of getting around the problem is
to feed IRDY# to TRDY# (only a single fast net), so that if the initiator
inserts a wait state, the target will also insert a wait state on the next
cycle, to give it time to back up through the pipeline and put the old data
back on the bus.  But this is dangerous, because if both an initiator and a
target use this strategy, there will be deadlock.

So (assuming I'm not missing something here), what moron designed PCI
without thinking about pipeline delays?  There are several easy ways to fix
this: one is to change irdy to mean that the number of times it is asserted
on a clock edge is the number of words which the initiator can accept at
full speed.  A corresponding number of trdys would be given by the target to
match it.
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 6996
Subject: Re: PCI burst transfers
From: "Bruno Sauter" <BSauter423@Xaol.com>
Date: 21 Jul 1997 08:39:05 GMT
Links: << >>  << T >>  << A >>

Now divide the 7ns/2 and 11ns/2, add those two results and that
is the time you have (yes, 9ns) available to do a target-read
for 66Mhz PCI. FPGAs can hardly meet 33Mhz. Most of them cannot.

Joseph H Allen <jhallen@world.std.com> wrote in article
<EDnFsD.Hx@world.std.com>...
> Suppose I'm doing a read burst.  The target must watch the IRDY# line
from
> the initiator to determine whether to hold the current read data or to
send
> out the next word.  IRDY# can arrive as late as 7ns before the clock
edge,
> and the data must be out by 11ns after to the clock edge- thus you have
18ns
> for this decision to occur, including pad propagation delays and big
routing
> delays between IRDY# and (perhaps) an output mux.  Is this correct or am
I
> missing something here?
> 
> This sucks big time, if true.  It means you can't use pad output
flip-flops
> for the bus (once IRDY is received it's too late to change the data in
any
> output flip-flops).  The only way I thought of getting around the problem
is
> to feed IRDY# to TRDY# (only a single fast net), so that if the initiator
> inserts a wait state, the target will also insert a wait state on the
next
> cycle, to give it time to back up through the pipeline and put the old
data
> back on the bus.  But this is dangerous, because if both an initiator and
a
> target use this strategy, there will be deadlock.
> 
> So (assuming I'm not missing something here), what moron designed PCI
> without thinking about pipeline delays?  There are several easy ways to
fix
> this: one is to change irdy to mean that the number of times it is
asserted
> on a clock edge is the number of words which the initiator can accept at
> full speed.  A corresponding number of trdys would be given by the target
to
> match it.
> -- 
> /*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H.
Allen */
> int
a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
>
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+
q*2
> ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n","
#"[!a[q-1]]);}
> 
Article: 6997
Subject: Re: Problem with unexpanded logic in xnf synhesized by Leonardo
From: Mark Sandstrom <Mark.Sandstrom@martis.fi>
Date: Mon, 21 Jul 1997 13:13:56 +0300
Links: << >>  << T >>  << A >>
Ruth Mayeda wrote:
> 
> Mark,
> 
> This looks like 2 separate, but similar issues:
> 
> When you compile your VHDL code, Leonardo reports that it can't
> find an "entity binding" for the RAMDATA component.  I'm not
> familiar with Exemplar, so I can only guess that this means it
> can't find a VHDL description for this component.  If you have
> an XNF file for this component, then M1 should be able to
> merge this in.  Since NGDBUILD 1.2.11 seems to be unable to
> locate the XNF file, you can run XNFMERGE foom the XACT 5.2/6.0
> toolset before running NGDBUILD (but read the next paragraph first).
> 
> The other "unexpanded blocks" are XBLOX components.  You have
> 2 choices: prevent Leonardo from inferring the XBLOX components,
> or process the design using the XACT 5.2/6.0 tools up to an
> XTF file, then run NGDBUILD on the XTF file.
> 
Thanks, Ruth. It is true that if I don't load and resolve the Xilinx 
4K XBLOX modgen with Leonardo, only the DPRAMs remain unexpanded.
However, without 4K XBLOX mogen, the Leonardo synthesis result is 
a lot worse.

I tried MEMGEN to produce ramdata.xnf:

{rausku:mark} [49] % memgen ramdata parttype=4028xlhq208 
memgen [5.2.1]  --  Xilinx Automatic CAE Tools
Copyright (c) 1997 Xilinx Inc.  All Rights Reserved.

+ memgen @ 1997/07/21 10:51:24 [00:00:00]
  
  + Parameters
    -----------------------
    file_name        = ramdata
    type             = ***
    parttype         = 4028xlhq208
    memory_depth     = 0
    word_width       = 0
    v                = FALSE
    b                = FALSE
    o                = FALSE
    old_library      = FALSE
    output_directory =
    logfile          = memgen.log
    -----------------------
  
  MEMGEN:  The Xilinx XC4000 RAM and ROM Compiler.
  
  
What type of memory do you want to build?
Type:  1 for RAMs
       2 for ROMs
       3 for SYNC_RAMs (XC4000E only)
       4 for DP_RAMs (XC4000E only)

4

How many bits wide is each memory word (1 to 32 bits)?
8

How many words deep is the memory (2 to 256 words)?
64

What type of schematic symbol do you want to create?
Type:  1 for VIEWlogic's VIEWdraw and VIEWdraw-LCA editors,
       2 for OrCAD's SDT editor, or
       3 for NONE

3
  
  Automatically creating a Memory Definition File for your new design
...
  
   - It is called 'ramdata.mem'
   - If you run this design again, type 'memgen ramdata'
     without having to re-enter any values.
   
  The 64-by-8 DP_RAM memory requires 2 logic levels and 20.0 CLBs.
  Your DP_RAM memory uses 4380 two-input NAND-gate equivalents.
  4 banks of size 16 memory(s) with 6 address lines.
  
  The Xilinx Netlist File for your memory was saved as 'ramdata.xnf' ...
  
    +------------------------------------------------------------------+
    | NOTE:  See 'memgen.log' if you want to review the screen output. |
    +------------------------------------------------------------------+
    
- memgen @ 1997/07/21 10:51:45 [00:00:00]
= ------ @ 1997/07/21 00:00:21 [00:00:00]

+ memgen used [108.325] Kbytes of dynamic/allocated memory during
execution
{rausku:mark} [50] % h
--
{rausku:mark} [51] % ngdbuild -p xc4028xlhq208 gma gma.ngd 
ngdbuild:  version M1.2.11
Copyright (c) 1995-1997 Xilinx, Inc.  All rights reserved.

Launcher: Using rule XNF_RULE
Launcher: gma.ngo being compiled because it does not exist
Launcher: Running xnf2ngd from /asic2/gma/xilinx/
Launcher: Executing xnf2ngd -p xc4000xl -u "gma.xnf" "gma.ngo"
xnf2ngd:  version M1.2.11
Copyright (c) 1995-1997 Xilinx, Inc.  All rights reserved.
   using XNF gate model
   reading XNF file 'gma.xnf' ...
   writing NGO file 'gma.ngo' ...
Launcher: xnf2ngd exited with an exit code of 0

Reading NGO file '/asic2/gma/xilinx/gma.ngo' ...
Reading component libraries for design expansion...

Launcher: Using rule XNF_RULE
Launcher: ramdata.ngo being compiled because it does not exist
Launcher: Running xnf2ngd from /asic2/gma/xilinx/
Launcher: Executing xnf2ngd -p xc4000xl "ramdata.xnf" "ramdata.ngo"
xnf2ngd:  version M1.2.11
Copyright (c) 1995-1997 Xilinx, Inc.  All rights reserved.
   using XNF gate model
   reading XNF file 'ramdata.xnf' ...
   writing NGO file 'ramdata.ngo' ...
Launcher: xnf2ngd exited with an exit code of 0

Loading NGO design '/asic2/gma/xilinx/ramdata.ngo'...
WARNING:basnb - Pin mismatch between block
   'instance_xbus_sc1_converter_instance_rx1cas_dpram_u1',
TYPE='ramdata', and
   file '/asic2/gma/xilinx/ramdata.ngo' at pin 'dpo<7>'
WARNING:basnb - Pin mismatch between block
   'instance_xbus_sc1_converter_instance_rx1data_dpram_u1',
TYPE='ramdata', and
   file '/asic2/gma/xilinx/ramdata.ngo' at pin 'dpo<7>'
WARNING:basnb - Pin mismatch between block
   'instance_xbus_sc1_converter_instance_rx2cas_dpram_u1',
TYPE='ramdata', and
   file '/asic2/gma/xilinx/ramdata.ngo' at pin 'dpo<7>'
WARNING:basnb - Pin mismatch between block
   'instance_xbus_sc1_converter_instance_rx2data_dpram_u1',
TYPE='ramdata', and
   file '/asic2/gma/xilinx/ramdata.ngo' at pin 'dpo<7>'
WARNING:basnb - Pin mismatch between block
   'instance_xbus_sc1_converter_instance_tx1cas_dpram_u1',
TYPE='ramdata', and
   file '/asic2/gma/xilinx/ramdata.ngo' at pin 'dpo<7>'
WARNING:basnb - Pin mismatch between block
   'instance_xbus_sc1_converter_instance_tx1data_dpram_u1',
TYPE='ramdata', and
   file '/asic2/gma/xilinx/ramdata.ngo' at pin 'dpo<7>'
WARNING:basnb - Pin mismatch between block
   'instance_xbus_sc1_converter_instance_tx2cas_dpram_u1',
TYPE='ramdata', and
   file '/asic2/gma/xilinx/ramdata.ngo' at pin 'dpo<7>'
WARNING:basnb - Pin mismatch between block
   'instance_xbus_sc1_converter_instance_tx2data_dpram_u1',
TYPE='ramdata', and
   file '/asic2/gma/xilinx/ramdata.ngo' at pin 'dpo<7>'

Running Timing Specification DRC...
Timing Specification DRC complete with no errors or warnings

Running Logical Design DRC...
WARNING:basnu - logical block
   'instance_xbus_sc1_converter_instance_rx1cas_dpram_u1' with type
'ramdata' is
   unexpanded
WARNING:basnu - logical block
   'instance_xbus_sc1_converter_instance_rx1data_dpram_u1' with type
'ramdata'
   is unexpanded
WARNING:basnu - logical block
   'instance_xbus_sc1_converter_instance_rx2cas_dpram_u1' with type
'ramdata' is
   unexpanded
WARNING:basnu - logical block
   'instance_xbus_sc1_converter_instance_rx2data_dpram_u1' with type
'ramdata'
   is unexpanded
WARNING:basnu - logical block
   'instance_xbus_sc1_converter_instance_tx1cas_dpram_u1' with type
'ramdata' is
   unexpanded
WARNING:basnu - logical block
   'instance_xbus_sc1_converter_instance_tx1data_dpram_u1' with type
'ramdata'
   is unexpanded
WARNING:basnu - logical block
   'instance_xbus_sc1_converter_instance_tx2cas_dpram_u1' with type
'ramdata' is
   unexpanded
WARNING:basnu - logical block
   'instance_xbus_sc1_converter_instance_tx2data_dpram_u1' with type
'ramdata'
   is unexpanded
Logical Design DRC complete with 8 warnings

Ngdbuild Design Results Summary:
  There were 8 Logical Design DRC warnings
   1753 total blocks expanded
Writing NGD file 'gma.ngd' ...

Writing ngdbuild log file 'gma.bld'...

Ngdbuild Done.
{rausku:mark} [52] %

Any information or ideas on where that mismatch on pin dpo<7> may arise
from?
Or is there some other (handy) way to instantiate 64 byte DPRAMs using
VHDL
synthesis design style and targetting XC4000EX/XL technology? 
I've got Leonardo and Synopsys FPGA Compiler synthesis tools.

Best regards,

	Mark H. Sandstrom
Article: 6998
Subject: Re: PCI burst transfers
From: Duane Clark <Duane.Clark@jpl.nasa.gov>
Date: Mon, 21 Jul 1997 08:39:47 -0700
Links: << >>  << T >>  << A >>
Joseph H Allen wrote:
> 
> Suppose I'm doing a read burst.  The target must watch the IRDY# line from
> the initiator to determine whether to hold the current read data or to send
> out the next word.  IRDY# can arrive as late as 7ns before the clock edge,
> and the data must be out by 11ns after to the clock edge- thus you have 18ns
> for this decision to occur, including pad propagation delays and big routing
> delays between IRDY# and (perhaps) an output mux.  Is this correct or am I
> missing something here?
> 
> This sucks big time, if true.  It means you can't use pad output flip-flops
> for the bus (once IRDY is received it's too late to change the data in any
> output flip-flops).  The only way I thought of getting around the problem is
> to feed IRDY# to TRDY# (only a single fast net), so that if the initiator
> inserts a wait state, the target will also insert a wait state on the next
> cycle, to give it time to back up through the pipeline and put the old data
> back on the bus.  But this is dangerous, because if both an initiator and a
> target use this strategy, there will be deadlock.

I would be interested in what others have done for this. A possible
solution I see to this problem is to feed IRDY (almost) directly to the
clock enable pin on the output flipflops. This of course assumes that
the technology you are using has a clock enable pin on the output
flipflops (XC4KE for example).

While the timing is tight, you are helped by the fact that both IRDY and
the PCI CLK are both going through approximately the same buffers and
paths in a race to the output flipflop. The XC4KE parts have the
unfortunate requirement that IRDY has to be inverted before being
applied to the clock enable pin. With the fastest XC4KE parts, it
appears to be possible to meet the timing requirements.

The other solution is to take a performance hit in favor of easier
circuitry. Always deassert target for the first clock of each word
transferred, which gives you a chance to see whether the initiator is
going to assert IRDY. This of course means a (minimum) 50 percent cut in
maximum performance.

On the other hand, if your board is going into an Intel system, AFAIK no
Intel system will do full speed burst reads (burst writes may occur
though). I believe you will only get burst reads if some other bus
mastering PCI device generates them.

-- 

-Duane
Article: 6999
Subject: Re: PCI burst transfers
From: Dave Dea <daved@wmi.com>
Date: Mon, 21 Jul 1997 11:44:29 -0400
Links: << >>  << T >>  << A >>
Joseph H Allen wrote:
> 
> Suppose I'm doing a read burst.  The target must watch the IRDY# line from
> the initiator to determine whether to hold the current read data or to send
> out the next word.  IRDY# can arrive as late as 7ns before the clock edge,
> and the data must be out by 11ns after to the clock edge- thus you have 18ns
> for this decision to occur, including pad propagation delays and big routing
> delays between IRDY# and (perhaps) an output mux.  Is this correct or am I
> missing something here?

You aren't missing anything.  The answer is to use an FPGA that has
clock-enabled output flip-flops.  Then use IRDY# (and TRDY#, if you are
both a target and initiator) through one LUT to switch the clock
enable.  You may need to duplicate the clock enable reduce fanout and
minimize routing delays.  This may be makable in the fastest FPGA's.

> 
> This sucks big time, if true.  It means you can't use pad output flip-flops
> for the bus (once IRDY is received it's too late to change the data in any
> output flip-flops).  The only way I thought of getting around the problem is
> to feed IRDY# to TRDY# (only a single fast net), so that if the initiator
> inserts a wait state, the target will also insert a wait state on the next
> cycle, to give it time to back up through the pipeline and put the old data
> back on the bus.  But this is dangerous, because if both an initiator and a
> target use this strategy, there will be deadlock.

This is also a spec violation, since the source of the data must assert
its RDY# unconditionally (independent of the other guy's RDY#).

> 
> So (assuming I'm not missing something here), what moron designed PCI
> without thinking about pipeline delays?  There are several easy ways to fix
> this: one is to change irdy to mean that the number of times it is asserted
> on a clock edge is the number of words which the initiator can accept at
> full speed.  A corresponding number of trdys would be given by the target to
> match it.

PCI was designed with full custom or semi-custom (i.e. ASIC) interface
chips in mind.

> --
> /*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
> int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
> +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
> ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

--
Dave Dea            Woodward McCoach, Inc.
daved@wmi.com


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