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 27075

Article: 27075
Subject: Re: Spartan2 macros in WebPACK
From: Tim Jaynes <tim.jaynes@xilinx.com>
Date: Thu, 09 Nov 2000 12:59:16 -0800
Links: << >>  << T >>  << A >>
RAM is a primitive- therefore you can use it.
Note the first post (RAMB4_S8 was successful).
Tim

Eric Smith wrote:

> Tim Jaynes <tim.jaynes@xilinx.com> writes:
> > Macros can only be used if you have a schematic flow-
> > If you had a supported schematic tool you could use them in an HDL flow by
> > creating a netlist w/ hierarchical ports and instantiating that in your code,
> > but as of now schematic entry in WebPACK only supports CPLDs.
>
> Does this mean that I can't use RAM in my VHDL designs when using
> WebPACK?  That would seem like quite a limitation.


Article: 27076
Subject: Re: Non routable design
From: Tim Jaynes <tim.jaynes@xilinx.com>
Date: Thu, 09 Nov 2000 13:07:00 -0800
Links: << >>  << T >>  << A >>
Hi Steven,
Better PAR performance on routing pwr/gnd nets was one of the major
enhancements contained in the 3.1i tools and it's associated service packs.
Without seeing the design and without knowing your budgetary constraints I'd
recommend a software upgrade (assuming that that's a possibility).
What I'd do is contact the support hotline (submit a case on the web-
support.xilinx.com) to open a case.  An engineer here at xilinx could easily
run your design in the 3.1i tools to see if that migration fixes the
problem- that way you can make sure that an upgrade would be beneficial.
Regards,
Tim


Steven Derrien wrote:

> Hi,
>
> I've some really weird results (design does not route) from PAR for a
> Xilinx Virtex design, here is my experimental setup :
>
>  - My design is a 16 stage pipelined floating point
>  - M2.1 (latest SP) targeting Virtex xcv800
>  - It takes no more than 7% of the xcv800 slices...
>
>
> I've tried various implementations with different compress factor (from
> -c 1 to -c 0) results are the following :
>
> Command Line   : map -r -c 0 -cm speed -detail -o ret_fmul_16_c0
> ret_fmul_16
> Target Device  : xv800
> Target Package : bg432
> Target Speed   : -4
> Mapper Version : virtex -- C.22
>
> Design Summary
> --------------
>    Number of errors:      0
>    Number of warnings:    4
>    Number of Slices:              724 out of  9,408    7%
>       Slice Flip Flops:     537
>       4 input LUTs:         629 (13 used as a route-thru)
>       Shift registers:      173
>    Number of Slices containing
>       unrelated logic:              0 out of    724    0%
>    Number of bonded IOBs:          97 out of    316   30%
>
> Command Line   : map -r -c 1 -cm speed -detail -o ret_fmul_16_c1
> ret_fmul_8
> Target Device  : xv800
> Target Package : bg432
> Target Speed   : -4
> Mapper Version : virtex -- C.22
>
> Design Summary
> --------------
>    Number of errors:      0
>    Number of warnings:    3
>    Number of Slices:              450 out of  9,408    4%
>       Slice Flip Flops:     324
>       4 input LUTs:         629 (15 used as a route-thru)
>       Shift registers:      101
>    Number of Slices containing
>       unrelated logic:            118 out of    450   26%
>    Number of bonded IOBs:          97 out of    316   30%
>
> In all cases with and without timing constraints, with multiple PAR
> passes, the design always fail to route completely. Specifically GND and
> Vcc signals (among others) do not route : below is an example of one of
> the PAR report file which ask me to use a larger device while i uses at
> most 7% of its slices ....
>
> What I don't understand is that a relatively equivalent design in terms
> of complexity (floating point adder) with much more pipelmine stage and
> less regularity place an route successfully !!
>
> Any Xilinx guru to shed the light on this :) ?
>
> Steven Derrien
> IRISA, France
>
> Total REAL time: 17 mins 24 secs
> Total CPU  time: 17 mins 22 secs
> End of route.  3897 routed (84.35%); 15 unrouted active,
>    708 unrouted PWR/GND.
> No errors found.
> The signal "mul/C3690_C85O" is not completely routed.
> The signal "GLOBAL_LOGIC1" is not completely routed.
> The signal "mul/retiming_reg_239Q" is not completely routed.
> The signal "mul/retiming_reg_237Q" is not completely routed.
> The signal "mul/C3690_C267/O" is not completely routed.
> The signal "mul/C3690_C631O" is not completely routed.
> The signal "GLOBAL_LOGIC0" is not completely routed.
> The signal "mul/C3690_C1008/O" is not completely routed.
> The signal "mul/C3690_C1003O" is not completely routed.
> The signal "mul/retiming_reg_38Q" is not completely routed.
> The signal "mul/C3690_C1420O" is not completely routed.
> The signal "mul/retiming_reg_91Q" is not completely routed.
> The signal "mul/C3690_C1440O" is not completely routed.
> The signal "mul/retiming_reg_97Q" is not completely routed.
> The signal "mul/retiming_reg_115Q" is not completely routed.
> The signal "mul/C3690_C1493/O" is not completely routed.
> The signal "mul/C3690_C1492O" is not completely routed.
>
> This design was not fully routed.  To help fully route the design, you
> may try
> the following:
>   * Retarget the design to the next larger device in this family.
>
> --> I only use 7% of the chip ressource !!!!!
>
> Total REAL time to Router completion: 17 mins 28 secs
> Total CPU time to Router completion: 17 mins 26 secs
>
> The Number of signals not completely routed for this design is: 17
>
> The Average Connection Delay for this design is:        2.890 ns
> The Maximum Pin Delay is:                              10.541 ns
> The Average Connection Delay on the 10 Worst Nets is:   7.578 ns
>
> Listing Pin Delays by value: (ns)
>
>  d < 2.00   < d < 4.00  < d < 6.00  < d < 8.00  < d < 11.00  d >= 11.00
> ---------   ---------   ---------   ---------   ---------   ---------
>   1987        1065         228         246         371           0


Article: 27077
Subject: Re: Non routable design
From: Ray Andraka <ray@andraka.com>
Date: Thu, 09 Nov 2000 21:39:51 GMT
Links: << >>  << T >>  << A >>
There were problems with the pwr/gnd routing in 2.1, but I'm not sure that is
your problem.  I've seen misplaced carry chain elements generate a similar
error.

Steven Derrien wrote:
> 
> Hi,
> 
> I've some really weird results (design does not route) from PAR for a
> Xilinx Virtex design, here is my experimental setup :
> 
>  - My design is a 16 stage pipelined floating point
>  - M2.1 (latest SP) targeting Virtex xcv800
>  - It takes no more than 7% of the xcv800 slices...
> 
> 
> I've tried various implementations with different compress factor (from
> -c 1 to -c 0) results are the following :
> 
> Command Line   : map -r -c 0 -cm speed -detail -o ret_fmul_16_c0
> ret_fmul_16
> Target Device  : xv800
> Target Package : bg432
> Target Speed   : -4
> Mapper Version : virtex -- C.22
> 
> Design Summary
> --------------
>    Number of errors:      0
>    Number of warnings:    4
>    Number of Slices:              724 out of  9,408    7%
>       Slice Flip Flops:     537
>       4 input LUTs:         629 (13 used as a route-thru)
>       Shift registers:      173
>    Number of Slices containing
>       unrelated logic:              0 out of    724    0%
>    Number of bonded IOBs:          97 out of    316   30%
> 
> Command Line   : map -r -c 1 -cm speed -detail -o ret_fmul_16_c1
> ret_fmul_8
> Target Device  : xv800
> Target Package : bg432
> Target Speed   : -4
> Mapper Version : virtex -- C.22
> 
> Design Summary
> --------------
>    Number of errors:      0
>    Number of warnings:    3
>    Number of Slices:              450 out of  9,408    4%
>       Slice Flip Flops:     324
>       4 input LUTs:         629 (15 used as a route-thru)
>       Shift registers:      101
>    Number of Slices containing
>       unrelated logic:            118 out of    450   26%
>    Number of bonded IOBs:          97 out of    316   30%
> 
> In all cases with and without timing constraints, with multiple PAR
> passes, the design always fail to route completely. Specifically GND and
> Vcc signals (among others) do not route : below is an example of one of
> the PAR report file which ask me to use a larger device while i uses at
> most 7% of its slices ....
> 
> What I don't understand is that a relatively equivalent design in terms
> of complexity (floating point adder) with much more pipelmine stage and
> less regularity place an route successfully !!
> 
> Any Xilinx guru to shed the light on this :) ?
> 
> Steven Derrien
> IRISA, France
> 
> Total REAL time: 17 mins 24 secs
> Total CPU  time: 17 mins 22 secs
> End of route.  3897 routed (84.35%); 15 unrouted active,
>    708 unrouted PWR/GND.
> No errors found.
> The signal "mul/C3690_C85O" is not completely routed.
> The signal "GLOBAL_LOGIC1" is not completely routed.
> The signal "mul/retiming_reg_239Q" is not completely routed.
> The signal "mul/retiming_reg_237Q" is not completely routed.
> The signal "mul/C3690_C267/O" is not completely routed.
> The signal "mul/C3690_C631O" is not completely routed.
> The signal "GLOBAL_LOGIC0" is not completely routed.
> The signal "mul/C3690_C1008/O" is not completely routed.
> The signal "mul/C3690_C1003O" is not completely routed.
> The signal "mul/retiming_reg_38Q" is not completely routed.
> The signal "mul/C3690_C1420O" is not completely routed.
> The signal "mul/retiming_reg_91Q" is not completely routed.
> The signal "mul/C3690_C1440O" is not completely routed.
> The signal "mul/retiming_reg_97Q" is not completely routed.
> The signal "mul/retiming_reg_115Q" is not completely routed.
> The signal "mul/C3690_C1493/O" is not completely routed.
> The signal "mul/C3690_C1492O" is not completely routed.
> 
> This design was not fully routed.  To help fully route the design, you
> may try
> the following:
>   * Retarget the design to the next larger device in this family.
> 
> --> I only use 7% of the chip ressource !!!!!
> 
> Total REAL time to Router completion: 17 mins 28 secs
> Total CPU time to Router completion: 17 mins 26 secs
> 
> The Number of signals not completely routed for this design is: 17
> 
> The Average Connection Delay for this design is:        2.890 ns
> The Maximum Pin Delay is:                              10.541 ns
> The Average Connection Delay on the 10 Worst Nets is:   7.578 ns
> 
> Listing Pin Delays by value: (ns)
> 
>  d < 2.00   < d < 4.00  < d < 6.00  < d < 8.00  < d < 11.00  d >= 11.00
> ---------   ---------   ---------   ---------   ---------   ---------
>   1987        1065         228         246         371           0

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com

Article: 27078
Subject: Re: Microprocessor Verilog/VHDL Models
From: Jeremy Cooke <jercooke@yahoo.com>
Date: Thu, 09 Nov 2000 18:29:13 -0700
Links: << >>  << T >>  << A >>
Might want to check this site:

http://www.fpgacpu.org/

-Jeremy

"S. Ramirez" wrote:

> Andy,
>      A "leading" design verification "expert" told me that I could get this
> model from the vendor,i.e., Motorola, very easily.  "Just ask them," he
> said.  I have learned from experience that in our business, anyone who has a
> quick, fast answer to a complicated problem is just blurting out BS.  Of
> course this has to be verified.
>      And so I did.  I found the IBIS and BDSL files at the Mot site, but I
> couldn't find any behavioral models.  So I registered and posted my request
> to their technical support team.  I got back a response directing me to the
> IBIS and BDSL files!  A second post telling them that there is a HUGE
> difference between these files and what I wanted got me a response back with
> a link to the Synopsis site.  I have a message in to the local Synopsis rep
> asking him for the cost of this model, but I am bracing myself for sticker
> shock (and a long wait for the response).  This is why I posted the original
> message.
>      At least I know that there are others looking for similar things.  I
> will post the results when I get them.  Hmm, this is what ABC, NBC and CBS
> said on the night of the election, and they still don't know!
>      Thanks.
> Simon Ramirez, Consultant
> Synchronous Design, Inc.
>
> "Andy Peters n o a o [.] e d u>" <"apeters <"@> wrote in message
> news:8uelp5$rqp$3@noao.edu...
> > "S. Ramirez" wrote:
> > >
> > >      Does anyone here know of sources for microprocessor Verilog or VHDL
> > > behavioral models?
> > >      I am doing a board level simulation that involves FPGAs, memories,
> > > peanut components, and a Mot ColdFire microprocessor.  I checked with
> Mot
> > > about providing a C behavioral model or an encrypted Verilog/VHDL
> behavioral
> > > model, and they referred me to the Big S -- Synopsis.  This means that
> it
> > > will cost an ARM and a leg, and I'm not talking about an ARM processor!
> > >      Does anyone know of alternatives?
> >
> > Ugh.  I'm in the same boat.  I started a ColdFire 5206e model a while
> > ago -- just bus transactions -- and it's not ready for prime time (other
> > things interfered).  It would be nice if the chip vendors had some kind
> > of USABLE model; then again, they usually don't even have IBIS models,
> > so whom are we kidding?
> >
> > -- a
> > ----------------------------
> > Andy Peters
> > Sr. Electrical Engineer
> > National Optical Astronomy Observatory
> > 950 N Cherry Ave
> > Tucson, AZ 85719
> > apeters (at) n o a o [dot] e d u
> >
> > "It is better to be silent and thought a fool,
> >  than to send an e-mail to the entire company
> >  and remove all doubt."
> >


Article: 27079
Subject: Re: Linux/Unix code to drive Xilinx download cable
From: Adam Hawes <adam_hawes@dingoblue.net.au>
Date: Fri, 10 Nov 2000 17:38:26 +1030
Links: << >>  << T >>  << A >>
> Anybody got some code I can scrounge?  I'll bet others
> have done this already.
> 
> I've got the schematics from the Xilinx web site and
> I've worked with peek/poke code to drive the printer
> port and I've written code to do the serial download
> over home-brew hardware so I'm pretty sure I can do
> it all.  But why reinvent a wheel if I can scrounge it?


Poke around on Xess.com there was some stuff there to drive a Xilinx
download cable that I saw.  Not sure how relevant, but it was source
code...

Cheers,
Adma

-- 
Adam Hawes

Web:       http://overfiend.iwarp.com
Email:     adam_hawes@dingoblue.com.au
ICQ:       2492016

Voicemail: +61 (08) 8219-3238
Fax:       +61 (08) 8219-3238

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GAT dpu s+: a-- C++++ UL++ P+ L+++ E W- N+++ o+ K- w--- 
O- M V-- PS+ PE Y++ PGP++ t 5- X+++ R* tv b+ DI+ D---- 
G e* h! r--- y** 
------END GEEK CODE BLOCK------

Article: 27080
Subject: Re: Non routable design
From: "fred" <x@y.z>
Date: Fri, 10 Nov 2000 09:23:12 -0000
Links: << >>  << T >>  << A >>
Tim,

I hope you will forgive an immediate deep-end response, but
I am frankly appalled by your reply. You admit you have not
seen the user's design but immediately suggest he shells out
for an upgrade. I can only hope that you did not notice that
the user has only a 7% utilisation within his device.

Irrespective of his design type, a failure to route a <any?>
design with 7% utilisation is a likely tool bug or fault.
Your suggestion that he upgrade to get round the problem is
IMNSHO a major cop out and unworthy of you as a
representative of Xilinx. I am unaware whether this guy is
in maintenance or not but if it turns out he is not, and the
solution is indeed that he upgrade to get round a bug, may I
suggest he be provided with the upgrade for nowt as the F2.1
he was sold is 'not fit for purpose'.

I notice Ray has provided what may be a more constructive
reply.

Regards,

D McLeod
XEC

Disclaimer: I have assumed that Stephen's design does not
contain a fatal error which has caused the tools to give a
misleading error message (that never happens). My comments
on the 'upgrade regardless' approach remain.

"Tim Jaynes" <tim.jaynes@xilinx.com> wrote in message
news:3A0B11F4.E0AAD7AA@xilinx.com...
> Hi Steven,
> Better PAR performance on routing pwr/gnd nets was one of
the major
> enhancements contained in the 3.1i tools and it's
associated service packs.
> Without seeing the design and without knowing your
budgetary constraints I'd
> recommend a software upgrade (assuming that that's a
possibility).
> What I'd do is contact the support hotline (submit a case
on the web-
> support.xilinx.com) to open a case.  An engineer here at
xilinx could easily
> run your design in the 3.1i tools to see if that migration
fixes the
> problem- that way you can make sure that an upgrade would
be beneficial.
> Regards,
> Tim
>




Article: 27081
Subject: Re: Non routable design
From: "S. Ramirez" <sramirez@deleet.cfl.rr.com>
Date: Fri, 10 Nov 2000 10:43:20 GMT
Links: << >>  << T >>  << A >>
D McLeod,
     I think that Tim is justified in telling Steve that 3.1 might fix the
problem.  After all, it might, and this is what matters to Tim.  If Tim
doesn't want to shell out the money for 3.1, then so be it -- he should find
a way around his 2.1 problem himself.  If 3.1 fixes the problem, then he
goes on with his design.
     These tools upgrades do indeed fix problems (and create problems), and
that is one reason they are done.
-Simon Ramirez, Consultant
 Synchronous Design, Inc.



"fred" <x@y.z> wrote in message news:8ugerb$dga$1@news6.svr.pol.co.uk...
> Tim,
>
> I hope you will forgive an immediate deep-end response, but
> I am frankly appalled by your reply. You admit you have not
> seen the user's design but immediately suggest he shells out
> for an upgrade. I can only hope that you did not notice that
> the user has only a 7% utilisation within his device.
>
> Irrespective of his design type, a failure to route a <any?>
> design with 7% utilisation is a likely tool bug or fault.
> Your suggestion that he upgrade to get round the problem is
> IMNSHO a major cop out and unworthy of you as a
> representative of Xilinx. I am unaware whether this guy is
> in maintenance or not but if it turns out he is not, and the
> solution is indeed that he upgrade to get round a bug, may I
> suggest he be provided with the upgrade for nowt as the F2.1
> he was sold is 'not fit for purpose'.
>
> I notice Ray has provided what may be a more constructive
> reply.
>
> Regards,
>
> D McLeod
> XEC
>
> Disclaimer: I have assumed that Stephen's design does not
> contain a fatal error which has caused the tools to give a
> misleading error message (that never happens). My comments
> on the 'upgrade regardless' approach remain.
>
> "Tim Jaynes" <tim.jaynes@xilinx.com> wrote in message
> news:3A0B11F4.E0AAD7AA@xilinx.com...
> > Hi Steven,
> > Better PAR performance on routing pwr/gnd nets was one of
> the major
> > enhancements contained in the 3.1i tools and it's
> associated service packs.
> > Without seeing the design and without knowing your
> budgetary constraints I'd
> > recommend a software upgrade (assuming that that's a
> possibility).
> > What I'd do is contact the support hotline (submit a case
> on the web-
> > support.xilinx.com) to open a case.  An engineer here at
> xilinx could easily
> > run your design in the 3.1i tools to see if that migration
> fixes the
> > problem- that way you can make sure that an upgrade would
> be beneficial.
> > Regards,
> > Tim
> >
>
>
>
>



Article: 27082
Subject: VHDL: FFS in IOBs
From: Harry <Harry_Mullerus@yahoo.com>
Date: Fri, 10 Nov 2000 05:25:13 -0700
Links: << >>  << T >>  << A >>
Hi,
How to instantiate FFs in Xilinx IOBs in VHDL?? Please advise.
Harry

Article: 27083
Subject: Re: unique serial nr
From: "Gary Watson" <gary2@nexsan.com>
Date: Fri, 10 Nov 2000 13:14:11 -0000
Links: << >>  << T >>  << A >>
"Gary Watson" <gary2@nexsan.com> wrote in message
news:IIdO5.7216$Fi.29641@NewsReader...
> Someone privately suggested to me that you could put the serial number in
> the config prom after the config data, and use an external mux on cclk to
> milk the bits out ot the config prom and into an I/O pin.   I'm concerned
> about the MTBF reduction caused by using a low-tech part in such a
critical
> area, though it only has to work once, at power up...


And another person privately mentioned a trick from the 4000 days -- that
the CCLK signal becomes a keeper once the config is complete, and if you
simply hook an I/O pin to it and keep clocking it you can read past the
config file bits.

He didn't know if the Spartan II chips were designed the same way.  Anybody?


--

Gary Watson
gary2@nexsan.com
Nexsan Technologies Ltd.
Derby DE21 7BF  ENGLAND
http://www.nexsan.com




Article: 27084
Subject: Re: Non routable design
From: Steven Derrien <sderrien@irisa.fr>
Date: Fri, 10 Nov 2000 14:50:15 +0100
Links: << >>  << T >>  << A >>


Ray Andraka wrote:
> 
> There were problems with the pwr/gnd routing in 2.1, but I'm not sure that is
> your problem.  I've seen misplaced carry chain elements generate a similar
> error.
> 

Thank Ray, sounds like you have given to me the probable cause of the
problem...

Basically i'm working on an "retimer" (or automatic pipeliner) which
converts a combinational datapath into a N stage pipelined datapath. My
input file is an flatten EDIF description of the datapath. I assume that
this edif file only consists of the following virtex primitives :
LUT,XORCY,MUXCY and MUL_AND (no MUXF5 and MUXF6 for the moment. Then
using a very rough delay estimator I place registers in their datapath
in order to reduce its critical path. Whe placing registers I took into
consideration some constraints due to the Virtex slice topology:

- I assume that my orginal EDIF file is consistent with the Virtex
architecture (this is the case for example for EDIF generated by
F-Compiler2, but not by F-Express) I don't know for other synthesizers.

- I merge a LUT with its assoaciated MUXCY and XORCY logic, so that
registers are placed correctly between primitives (no registers between
a LUT output and XOR input for example)

But I did not address the following point :

- I didn't made a distinction between MUXCY_L and MUXCY ( neither
between XORCY_L and XOR_CY), and that may be the cause of the problem.
From what I've guessed from Xilinx documentation, when it founds a
"MUXCY_L"  primitive, it tries to use carry chain routing  (CIN and COUT
port of a slice). However my pipeliner can decide to place a register
between two MUXCY_L primitives which may cause the par tool to fail to
route correctly the design.


By the way, I tried the design with M3.2.sp4 (without timing
constraints) and it managed to route completely (with very very very
poor results anyway). I'll try with timing constraints this afternoon.

Thank you for your help, 

Steven




> Steven Derrien wrote:
> >
> > Hi,
> >
> > I've some really weird results (design does not route) from PAR for a
> > Xilinx Virtex design, here is my experimental setup :
> >
> >  - My design is a 16 stage pipelined floating point
> >  - M2.1 (latest SP) targeting Virtex xcv800
> >  - It takes no more than 7% of the xcv800 slices...
> >
> >
> > I've tried various implementations with different compress factor (from
> > -c 1 to -c 0) results are the following :
> >
> > Command Line   : map -r -c 0 -cm speed -detail -o ret_fmul_16_c0
> > ret_fmul_16
> > Target Device  : xv800
> > Target Package : bg432
> > Target Speed   : -4
> > Mapper Version : virtex -- C.22
> >
> > Design Summary
> > --------------
> >    Number of errors:      0
> >    Number of warnings:    4
> >    Number of Slices:              724 out of  9,408    7%
> >       Slice Flip Flops:     537
> >       4 input LUTs:         629 (13 used as a route-thru)
> >       Shift registers:      173
> >    Number of Slices containing
> >       unrelated logic:              0 out of    724    0%
> >    Number of bonded IOBs:          97 out of    316   30%
> >
> > Command Line   : map -r -c 1 -cm speed -detail -o ret_fmul_16_c1
> > ret_fmul_8
> > Target Device  : xv800
> > Target Package : bg432
> > Target Speed   : -4
> > Mapper Version : virtex -- C.22
> >
> > Design Summary
> > --------------
> >    Number of errors:      0
> >    Number of warnings:    3
> >    Number of Slices:              450 out of  9,408    4%
> >       Slice Flip Flops:     324
> >       4 input LUTs:         629 (15 used as a route-thru)
> >       Shift registers:      101
> >    Number of Slices containing
> >       unrelated logic:            118 out of    450   26%
> >    Number of bonded IOBs:          97 out of    316   30%
> >
> > In all cases with and without timing constraints, with multiple PAR
> > passes, the design always fail to route completely. Specifically GND and
> > Vcc signals (among others) do not route : below is an example of one of
> > the PAR report file which ask me to use a larger device while i uses at
> > most 7% of its slices ....
> >
> > What I don't understand is that a relatively equivalent design in terms
> > of complexity (floating point adder) with much more pipelmine stage and
> > less regularity place an route successfully !!
> >
> > Any Xilinx guru to shed the light on this :) ?
> >
> > Steven Derrien
> > IRISA, France
> >
> > Total REAL time: 17 mins 24 secs
> > Total CPU  time: 17 mins 22 secs
> > End of route.  3897 routed (84.35%); 15 unrouted active,
> >    708 unrouted PWR/GND.
> > No errors found.
> > The signal "mul/C3690_C85O" is not completely routed.
> > The signal "GLOBAL_LOGIC1" is not completely routed.
> > The signal "mul/retiming_reg_239Q" is not completely routed.
> > The signal "mul/retiming_reg_237Q" is not completely routed.
> > The signal "mul/C3690_C267/O" is not completely routed.
> > The signal "mul/C3690_C631O" is not completely routed.
> > The signal "GLOBAL_LOGIC0" is not completely routed.
> > The signal "mul/C3690_C1008/O" is not completely routed.
> > The signal "mul/C3690_C1003O" is not completely routed.
> > The signal "mul/retiming_reg_38Q" is not completely routed.
> > The signal "mul/C3690_C1420O" is not completely routed.
> > The signal "mul/retiming_reg_91Q" is not completely routed.
> > The signal "mul/C3690_C1440O" is not completely routed.
> > The signal "mul/retiming_reg_97Q" is not completely routed.
> > The signal "mul/retiming_reg_115Q" is not completely routed.
> > The signal "mul/C3690_C1493/O" is not completely routed.
> > The signal "mul/C3690_C1492O" is not completely routed.
> >
> > This design was not fully routed.  To help fully route the design, you
> > may try
> > the following:
> >   * Retarget the design to the next larger device in this family.
> >
> > --> I only use 7% of the chip ressource !!!!!
> >
> > Total REAL time to Router completion: 17 mins 28 secs
> > Total CPU time to Router completion: 17 mins 26 secs
> >
> > The Number of signals not completely routed for this design is: 17
> >
> > The Average Connection Delay for this design is:        2.890 ns
> > The Maximum Pin Delay is:                              10.541 ns
> > The Average Connection Delay on the 10 Worst Nets is:   7.578 ns
> >
> > Listing Pin Delays by value: (ns)
> >
> >  d < 2.00   < d < 4.00  < d < 6.00  < d < 8.00  < d < 11.00  d >= 11.00
> > ---------   ---------   ---------   ---------   ---------   ---------
> >   1987        1065         228         246         371           0
> 
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com  or http://www.fpga-guru.com

Article: 27085
Subject: Leonardo for Altera
From: flavioas@my-deja.com
Date: Fri, 10 Nov 2000 14:18:30 GMT
Links: << >>  << T >>  << A >>



     Hi people,

     I am using Leonardo Spectrum for altera, trying to use a
synthesizer better than maxplus2 for VHDL. But despite of
checking 'setup maxplus2( create ACF file)option at Place&Route menu,
it didn´t generate any ACF. So every time it runs maxplus2 to P&R it
loses family, device and all information.
      Any answer/suggestion is welcome,

      Thanks in advance,

      Flávio


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 27086
Subject: Re: Non routable design
From: Ray Andraka <ray@andraka.com>
Date: Fri, 10 Nov 2000 14:30:12 GMT
Links: << >>  << T >>  << A >>
As a first cut, you might try changing the _L and _D elements to the generic
unsuffixed ones with your parser.  Sounds like this is indeed the source of your
problems.

Steven Derrien wrote:
> 
> Ray Andraka wrote:
> >
> > There were problems with the pwr/gnd routing in 2.1, but I'm not sure that is
> > your problem.  I've seen misplaced carry chain elements generate a similar
> > error.
> >
> 
> Thank Ray, sounds like you have given to me the probable cause of the
> problem...
> 
> Basically i'm working on an "retimer" (or automatic pipeliner) which
> converts a combinational datapath into a N stage pipelined datapath. My
> input file is an flatten EDIF description of the datapath. I assume that
> this edif file only consists of the following virtex primitives :
> LUT,XORCY,MUXCY and MUL_AND (no MUXF5 and MUXF6 for the moment. Then
> using a very rough delay estimator I place registers in their datapath
> in order to reduce its critical path. Whe placing registers I took into
> consideration some constraints due to the Virtex slice topology:
> 
> - I assume that my orginal EDIF file is consistent with the Virtex
> architecture (this is the case for example for EDIF generated by
> F-Compiler2, but not by F-Express) I don't know for other synthesizers.
> 
> - I merge a LUT with its assoaciated MUXCY and XORCY logic, so that
> registers are placed correctly between primitives (no registers between
> a LUT output and XOR input for example)
> 
> But I did not address the following point :
> 
> - I didn't made a distinction between MUXCY_L and MUXCY ( neither
> between XORCY_L and XOR_CY), and that may be the cause of the problem.
> From what I've guessed from Xilinx documentation, when it founds a
> "MUXCY_L"  primitive, it tries to use carry chain routing  (CIN and COUT
> port of a slice). However my pipeliner can decide to place a register
> between two MUXCY_L primitives which may cause the par tool to fail to
> route correctly the design.
> 
> By the way, I tried the design with M3.2.sp4 (without timing
> constraints) and it managed to route completely (with very very very
> poor results anyway). I'll try with timing constraints this afternoon.
> 
> Thank you for your help,
> 
> Steven
> 
> > Steven Derrien wrote:
> > >
> > > Hi,
> > >
> > > I've some really weird results (design does not route) from PAR for a
> > > Xilinx Virtex design, here is my experimental setup :
> > >
> > >  - My design is a 16 stage pipelined floating point
> > >  - M2.1 (latest SP) targeting Virtex xcv800
> > >  - It takes no more than 7% of the xcv800 slices...
> > >
> > >
> > > I've tried various implementations with different compress factor (from
> > > -c 1 to -c 0) results are the following :
> > >
> > > Command Line   : map -r -c 0 -cm speed -detail -o ret_fmul_16_c0
> > > ret_fmul_16
> > > Target Device  : xv800
> > > Target Package : bg432
> > > Target Speed   : -4
> > > Mapper Version : virtex -- C.22
> > >
> > > Design Summary
> > > --------------
> > >    Number of errors:      0
> > >    Number of warnings:    4
> > >    Number of Slices:              724 out of  9,408    7%
> > >       Slice Flip Flops:     537
> > >       4 input LUTs:         629 (13 used as a route-thru)
> > >       Shift registers:      173
> > >    Number of Slices containing
> > >       unrelated logic:              0 out of    724    0%
> > >    Number of bonded IOBs:          97 out of    316   30%
> > >
> > > Command Line   : map -r -c 1 -cm speed -detail -o ret_fmul_16_c1
> > > ret_fmul_8
> > > Target Device  : xv800
> > > Target Package : bg432
> > > Target Speed   : -4
> > > Mapper Version : virtex -- C.22
> > >
> > > Design Summary
> > > --------------
> > >    Number of errors:      0
> > >    Number of warnings:    3
> > >    Number of Slices:              450 out of  9,408    4%
> > >       Slice Flip Flops:     324
> > >       4 input LUTs:         629 (15 used as a route-thru)
> > >       Shift registers:      101
> > >    Number of Slices containing
> > >       unrelated logic:            118 out of    450   26%
> > >    Number of bonded IOBs:          97 out of    316   30%
> > >
> > > In all cases with and without timing constraints, with multiple PAR
> > > passes, the design always fail to route completely. Specifically GND and
> > > Vcc signals (among others) do not route : below is an example of one of
> > > the PAR report file which ask me to use a larger device while i uses at
> > > most 7% of its slices ....
> > >
> > > What I don't understand is that a relatively equivalent design in terms
> > > of complexity (floating point adder) with much more pipelmine stage and
> > > less regularity place an route successfully !!
> > >
> > > Any Xilinx guru to shed the light on this :) ?
> > >
> > > Steven Derrien
> > > IRISA, France
> > >
> > > Total REAL time: 17 mins 24 secs
> > > Total CPU  time: 17 mins 22 secs
> > > End of route.  3897 routed (84.35%); 15 unrouted active,
> > >    708 unrouted PWR/GND.
> > > No errors found.
> > > The signal "mul/C3690_C85O" is not completely routed.
> > > The signal "GLOBAL_LOGIC1" is not completely routed.
> > > The signal "mul/retiming_reg_239Q" is not completely routed.
> > > The signal "mul/retiming_reg_237Q" is not completely routed.
> > > The signal "mul/C3690_C267/O" is not completely routed.
> > > The signal "mul/C3690_C631O" is not completely routed.
> > > The signal "GLOBAL_LOGIC0" is not completely routed.
> > > The signal "mul/C3690_C1008/O" is not completely routed.
> > > The signal "mul/C3690_C1003O" is not completely routed.
> > > The signal "mul/retiming_reg_38Q" is not completely routed.
> > > The signal "mul/C3690_C1420O" is not completely routed.
> > > The signal "mul/retiming_reg_91Q" is not completely routed.
> > > The signal "mul/C3690_C1440O" is not completely routed.
> > > The signal "mul/retiming_reg_97Q" is not completely routed.
> > > The signal "mul/retiming_reg_115Q" is not completely routed.
> > > The signal "mul/C3690_C1493/O" is not completely routed.
> > > The signal "mul/C3690_C1492O" is not completely routed.
> > >
> > > This design was not fully routed.  To help fully route the design, you
> > > may try
> > > the following:
> > >   * Retarget the design to the next larger device in this family.
> > >
> > > --> I only use 7% of the chip ressource !!!!!
> > >
> > > Total REAL time to Router completion: 17 mins 28 secs
> > > Total CPU time to Router completion: 17 mins 26 secs
> > >
> > > The Number of signals not completely routed for this design is: 17
> > >
> > > The Average Connection Delay for this design is:        2.890 ns
> > > The Maximum Pin Delay is:                              10.541 ns
> > > The Average Connection Delay on the 10 Worst Nets is:   7.578 ns
> > >
> > > Listing Pin Delays by value: (ns)
> > >
> > >  d < 2.00   < d < 4.00  < d < 6.00  < d < 8.00  < d < 11.00  d >= 11.00
> > > ---------   ---------   ---------   ---------   ---------   ---------
> > >   1987        1065         228         246         371           0
> >
> > --
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com  or http://www.fpga-guru.com

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com

Article: 27087
Subject: Pull-up
From: Jonas <>
Date: Fri, 10 Nov 2000 08:04:14 -0700
Links: << >>  << T >>  << A >>
Hi
Is it possible to configurate a pin as an open drain and at the same time use an internal pull up? I use a SpartanXL (XCS40XL). If this i possible, how do I describe it in VHDL?
Jonas.

Article: 27088
Subject: Re: Non routable design
From: Steven Derrien <sderrien@irisa.fr>
Date: Fri, 10 Nov 2000 16:08:43 +0100
Links: << >>  << T >>  << A >>


Ray Andraka wrote:
> 
> As a first cut, you might try changing the _L and _D elements to the generic
> unsuffixed ones with your parser.  Sounds like this is indeed the source of your
> problems.
> 

Right, but there is (as usual) a problem, output pin for MUXCY and
MUX_CY do not have the same names (O for MUXCY and LO for MUXCY_L). So i
guess it's going to be non neglectable work :((.

By the way do you have references about the routing problem related to
an incorrect use of carry chain logic ? I'd like to have more precise
info before getting into my retiming code.

Thanks again

Steven



> Steven Derrien wrote:
> >
> > Ray Andraka wrote:
> > >
> > > There were problems with the pwr/gnd routing in 2.1, but I'm not sure that is
> > > your problem.  I've seen misplaced carry chain elements generate a similar
> > > error.
> > >
> >
> > Thank Ray, sounds like you have given to me the probable cause of the
> > problem...
> >
> > Basically i'm working on an "retimer" (or automatic pipeliner) which
> > converts a combinational datapath into a N stage pipelined datapath. My
> > input file is an flatten EDIF description of the datapath. I assume that
> > this edif file only consists of the following virtex primitives :
> > LUT,XORCY,MUXCY and MUL_AND (no MUXF5 and MUXF6 for the moment. Then
> > using a very rough delay estimator I place registers in their datapath
> > in order to reduce its critical path. Whe placing registers I took into
> > consideration some constraints due to the Virtex slice topology:
> >
> > - I assume that my orginal EDIF file is consistent with the Virtex
> > architecture (this is the case for example for EDIF generated by
> > F-Compiler2, but not by F-Express) I don't know for other synthesizers.
> >
> > - I merge a LUT with its assoaciated MUXCY and XORCY logic, so that
> > registers are placed correctly between primitives (no registers between
> > a LUT output and XOR input for example)
> >
> > But I did not address the following point :
> >
> > - I didn't made a distinction between MUXCY_L and MUXCY ( neither
> > between XORCY_L and XOR_CY), and that may be the cause of the problem.
> > From what I've guessed from Xilinx documentation, when it founds a
> > "MUXCY_L"  primitive, it tries to use carry chain routing  (CIN and COUT
> > port of a slice). However my pipeliner can decide to place a register
> > between two MUXCY_L primitives which may cause the par tool to fail to
> > route correctly the design.
> >
> > By the way, I tried the design with M3.2.sp4 (without timing
> > constraints) and it managed to route completely (with very very very
> > poor results anyway). I'll try with timing constraints this afternoon.
> >
> > Thank you for your help,
> >
> > Steven
> >
> > > Steven Derrien wrote:
> > > >
> > > > Hi,
> > > >
> > > > I've some really weird results (design does not route) from PAR for a
> > > > Xilinx Virtex design, here is my experimental setup :
> > > >
> > > >  - My design is a 16 stage pipelined floating point
> > > >  - M2.1 (latest SP) targeting Virtex xcv800
> > > >  - It takes no more than 7% of the xcv800 slices...
> > > >
> > > >
> > > > I've tried various implementations with different compress factor (from
> > > > -c 1 to -c 0) results are the following :
> > > >
> > > > Command Line   : map -r -c 0 -cm speed -detail -o ret_fmul_16_c0
> > > > ret_fmul_16
> > > > Target Device  : xv800
> > > > Target Package : bg432
> > > > Target Speed   : -4
> > > > Mapper Version : virtex -- C.22
> > > >
> > > > Design Summary
> > > > --------------
> > > >    Number of errors:      0
> > > >    Number of warnings:    4
> > > >    Number of Slices:              724 out of  9,408    7%
> > > >       Slice Flip Flops:     537
> > > >       4 input LUTs:         629 (13 used as a route-thru)
> > > >       Shift registers:      173
> > > >    Number of Slices containing
> > > >       unrelated logic:              0 out of    724    0%
> > > >    Number of bonded IOBs:          97 out of    316   30%
> > > >
> > > > Command Line   : map -r -c 1 -cm speed -detail -o ret_fmul_16_c1
> > > > ret_fmul_8
> > > > Target Device  : xv800
> > > > Target Package : bg432
> > > > Target Speed   : -4
> > > > Mapper Version : virtex -- C.22
> > > >
> > > > Design Summary
> > > > --------------
> > > >    Number of errors:      0
> > > >    Number of warnings:    3
> > > >    Number of Slices:              450 out of  9,408    4%
> > > >       Slice Flip Flops:     324
> > > >       4 input LUTs:         629 (15 used as a route-thru)
> > > >       Shift registers:      101
> > > >    Number of Slices containing
> > > >       unrelated logic:            118 out of    450   26%
> > > >    Number of bonded IOBs:          97 out of    316   30%
> > > >
> > > > In all cases with and without timing constraints, with multiple PAR
> > > > passes, the design always fail to route completely. Specifically GND and
> > > > Vcc signals (among others) do not route : below is an example of one of
> > > > the PAR report file which ask me to use a larger device while i uses at
> > > > most 7% of its slices ....
> > > >
> > > > What I don't understand is that a relatively equivalent design in terms
> > > > of complexity (floating point adder) with much more pipelmine stage and
> > > > less regularity place an route successfully !!
> > > >
> > > > Any Xilinx guru to shed the light on this :) ?
> > > >
> > > > Steven Derrien
> > > > IRISA, France
> > > >
> > > > Total REAL time: 17 mins 24 secs
> > > > Total CPU  time: 17 mins 22 secs
> > > > End of route.  3897 routed (84.35%); 15 unrouted active,
> > > >    708 unrouted PWR/GND.
> > > > No errors found.
> > > > The signal "mul/C3690_C85O" is not completely routed.
> > > > The signal "GLOBAL_LOGIC1" is not completely routed.
> > > > The signal "mul/retiming_reg_239Q" is not completely routed.
> > > > The signal "mul/retiming_reg_237Q" is not completely routed.
> > > > The signal "mul/C3690_C267/O" is not completely routed.
> > > > The signal "mul/C3690_C631O" is not completely routed.
> > > > The signal "GLOBAL_LOGIC0" is not completely routed.
> > > > The signal "mul/C3690_C1008/O" is not completely routed.
> > > > The signal "mul/C3690_C1003O" is not completely routed.
> > > > The signal "mul/retiming_reg_38Q" is not completely routed.
> > > > The signal "mul/C3690_C1420O" is not completely routed.
> > > > The signal "mul/retiming_reg_91Q" is not completely routed.
> > > > The signal "mul/C3690_C1440O" is not completely routed.
> > > > The signal "mul/retiming_reg_97Q" is not completely routed.
> > > > The signal "mul/retiming_reg_115Q" is not completely routed.
> > > > The signal "mul/C3690_C1493/O" is not completely routed.
> > > > The signal "mul/C3690_C1492O" is not completely routed.
> > > >
> > > > This design was not fully routed.  To help fully route the design, you
> > > > may try
> > > > the following:
> > > >   * Retarget the design to the next larger device in this family.
> > > >
> > > > --> I only use 7% of the chip ressource !!!!!
> > > >
> > > > Total REAL time to Router completion: 17 mins 28 secs
> > > > Total CPU time to Router completion: 17 mins 26 secs
> > > >
> > > > The Number of signals not completely routed for this design is: 17
> > > >
> > > > The Average Connection Delay for this design is:        2.890 ns
> > > > The Maximum Pin Delay is:                              10.541 ns
> > > > The Average Connection Delay on the 10 Worst Nets is:   7.578 ns
> > > >
> > > > Listing Pin Delays by value: (ns)
> > > >
> > > >  d < 2.00   < d < 4.00  < d < 6.00  < d < 8.00  < d < 11.00  d >= 11.00
> > > > ---------   ---------   ---------   ---------   ---------   ---------
> > > >   1987        1065         228         246         371           0
> > >
> > > --
> > > -Ray Andraka, P.E.
> > > President, the Andraka Consulting Group, Inc.
> > > 401/884-7930     Fax 401/884-7950
> > > email ray@andraka.com
> > > http://www.andraka.com  or http://www.fpga-guru.com
> 
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com  or http://www.fpga-guru.com

Article: 27089
Subject: Re: Xilinx PCI Core
From: Newsbrowser@Newsbrowser.com (Newsbrowser)
Date: Fri, 10 Nov 2000 15:32:43 GMT
Links: << >>  << T >>  << A >>
On Thu, 09 Nov 2000 17:11:25 GMT, Andrea Sorio <a.sorio@libero.it>
wrote:

>Hi
>
>    I'm working on my first VHDL design.
>I'm tring to interface the Xilinx PCI core with a MPC860 bus.
>I have same problem with the map application.
>It report this error (one of about 162!)
>
>ERROR:OldMap:648 - BUFT symbol "PCI_CORE/PCI_LC/5/UPPER/T6" (output
>   signal=ADIO<22>, enable signal=PCI_CORE/PCI_LC/BAR1_T) on signal
>"ADIO<22>"
>   has been reduced to a permanently-driving buffer.  (The enable signal
>was
>   probably either grounded or reduced to ground.)  However, another
>active
>   three-state BUFT symbol "USER_APP/BusSwitchC/C513" (output
>signal=ADIO<22>,
>   enable signal=USER_APP/BusSwitchC/N430) is driving this signal;
>therefore,
>   the signal is multiply sourced.
>
>ModelSim simulation is OK!
>
>I guess that the logic that manage the pci  core is reduced to a costant
>value.
>
>Could someone be so kind as to suggest me a plausible cause?
>
>Thank you in advance
>
>Andrea
>
>--
>A.Sorio
>R&D Electronic Engineer
>
>Atenix E.E.
>Via S.Dona' 106
>30170 Mestre (VE)
>ITALY
>
>Tel.    +39-041-2621035
>email:  andrea.sorio@atenix.it
>
>
Not sure if this is the cause of your problem 
But........................
One of the pain in the Butt things about the Xilinx PCI cores is that
certain signals have to be tied to a fixed value via D- Flip-Flops so
that during 
compilation some of the logic doesn't get reduce. Oh, You have 
make it so that these D-Flip-Flops don't get reduce either. This is
actually explained in their documentation somewhere.

I initially did not do this and found my post-complilation simulation
core driving the bus all of the time 

         iREQUESTHOLD
         iCFG_SELF 
         iKEEPOUT 
         iC_READY
         iC_TERM  

Here are the signals that I tied high/low  via output of D-Flip Flop,
not all of these may be required. 

good luck 


Return Email Address is: 
ralphwat dot home at excite dot com 

Article: 27090
Subject: Re: ISO C -> VHDL translator, prefer open source
From: "Peter Dennett" <pdennett@padsoft.com>
Date: Fri, 10 Nov 2000 10:24:15 -0600
Links: << >>  << T >>  << A >>

<timjeno@my-deja.com> wrote in message news:8ue9t6$nni$1@nnrp1.deja.com...
> I don't know of any such product.  I would question whether such an
> approach would be the best way to get your "feet wet" anyway. The code
> produced by such a process would unlikely be clean and would therefore
> offer little help as an educational tool.  I can almost gaurantee it
> won't do everything you want without tweaking which will ultimately
> involve learning VHDL.

Basically I agree with all of what you said but not with the conclusion.
I do expect "ratty VHDL" to be generated, I do expect to have to learn
why it does not do what I expect.  But I do think it seems like a good
way to learn VHDL.  It's also how I expect to be programming FPGA
devices in the future.

I see VHDL and schematic capture is the equivalent to assembly
language.  Longer ago then I like to think I learned programming
using assemblers.  I understand what is happening below the skins.
I seldom use assembler any more and when I do I normally start
by coding it in C and looking at its output as a starting point.

I've moved on to systems that may be a bit sloppy in the details but
they handle them so I don't have to.  I'd like to apply the same
concept to FPGAs.

> Besides this, there's a good chance that only a
> subset of C would be supported, perhaps a "synthesizable C".  This
> would involve a learning curve for the C-side also.

Yep, expected.

> Perhaps a book on VHDL targetted to programmers would work best?  I
> haven't read any but I could probably at least find names.

I'd love to hear of one.  Those authors in the audience should take
heed.  The next source of FPGA developers will come from the
software side.  The don't want to know logic design they want to
know algorythm implementation.

>          Good luck with whatever you decide to do!

Thanks, and thank you for the input.

> p.s. - If it helps, I went from a programming background to VHDL.  It
> requires a conceptual shift but the language is simple.  It's similar
> to going from C to object oriented C++.  The syntax jump is easy but
> the concepts are very different.  I learned VHDL from VHDL tutorials.
> They're all over the place.

I've been cruising the net for awhile now looking that the tutorials,
there indeed a lot and many are high quality.  I have some books
on order and have been working on getting an Altera UP1 board.
I'll be heading down a comparable path.

--
Peter Dennett                     Email: pdennett@padsoft.com
61 Harbor Lane                  Web:  www.padsoft.com
Kemah, TX 77565               Web: www.boatbrains.com
Voice: 281 334 3800         Cell: 713 899 6100       Fax: 281 521 1032



Article: 27091
Subject: Re: Non routable design
From: Ray Andraka <ray@andraka.com>
Date: Fri, 10 Nov 2000 16:31:54 GMT
Links: << >>  << T >>  << A >>
You should be able to re-label without too much difficulty.  Sure, it's
non-trivial but it ain't rocket science either.  I don't have a xilinx case
reference, as the problem really isn't a tools problem as much as an input error
problem, although a more descriptive/pertinent error message would have been
helpful in finding it the first time around (in other words, I didn't open a
case for this as I considered it my fault).

Steven Derrien wrote:
> 
> Ray Andraka wrote:
> >
> > As a first cut, you might try changing the _L and _D elements to the generic
> > unsuffixed ones with your parser.  Sounds like this is indeed the source of your
> > problems.
> >
> 
> Right, but there is (as usual) a problem, output pin for MUXCY and
> MUX_CY do not have the same names (O for MUXCY and LO for MUXCY_L). So i
> guess it's going to be non neglectable work :((.
> 
> By the way do you have references about the routing problem related to
> an incorrect use of carry chain logic ? I'd like to have more precise
> info before getting into my retiming code.
> 
> Thanks again
> 
> Steven
> 
> > Steven Derrien wrote:
> > >
> > > Ray Andraka wrote:
> > > >
> > > > There were problems with the pwr/gnd routing in 2.1, but I'm not sure that is
> > > > your problem.  I've seen misplaced carry chain elements generate a similar
> > > > error.
> > > >
> > >
> > > Thank Ray, sounds like you have given to me the probable cause of the
> > > problem...
> > >
> > > Basically i'm working on an "retimer" (or automatic pipeliner) which
> > > converts a combinational datapath into a N stage pipelined datapath. My
> > > input file is an flatten EDIF description of the datapath. I assume that
> > > this edif file only consists of the following virtex primitives :
> > > LUT,XORCY,MUXCY and MUL_AND (no MUXF5 and MUXF6 for the moment. Then
> > > using a very rough delay estimator I place registers in their datapath
> > > in order to reduce its critical path. Whe placing registers I took into
> > > consideration some constraints due to the Virtex slice topology:
> > >
> > > - I assume that my orginal EDIF file is consistent with the Virtex
> > > architecture (this is the case for example for EDIF generated by
> > > F-Compiler2, but not by F-Express) I don't know for other synthesizers.
> > >
> > > - I merge a LUT with its assoaciated MUXCY and XORCY logic, so that
> > > registers are placed correctly between primitives (no registers between
> > > a LUT output and XOR input for example)
> > >
> > > But I did not address the following point :
> > >
> > > - I didn't made a distinction between MUXCY_L and MUXCY ( neither
> > > between XORCY_L and XOR_CY), and that may be the cause of the problem.
> > > From what I've guessed from Xilinx documentation, when it founds a
> > > "MUXCY_L"  primitive, it tries to use carry chain routing  (CIN and COUT
> > > port of a slice). However my pipeliner can decide to place a register
> > > between two MUXCY_L primitives which may cause the par tool to fail to
> > > route correctly the design.
> > >
> > > By the way, I tried the design with M3.2.sp4 (without timing
> > > constraints) and it managed to route completely (with very very very
> > > poor results anyway). I'll try with timing constraints this afternoon.
> > >
> > > Thank you for your help,
> > >
> > > Steven
> > >
> > > > Steven Derrien wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I've some really weird results (design does not route) from PAR for a
> > > > > Xilinx Virtex design, here is my experimental setup :
> > > > >
> > > > >  - My design is a 16 stage pipelined floating point
> > > > >  - M2.1 (latest SP) targeting Virtex xcv800
> > > > >  - It takes no more than 7% of the xcv800 slices...
> > > > >
> > > > >
> > > > > I've tried various implementations with different compress factor (from
> > > > > -c 1 to -c 0) results are the following :
> > > > >
> > > > > Command Line   : map -r -c 0 -cm speed -detail -o ret_fmul_16_c0
> > > > > ret_fmul_16
> > > > > Target Device  : xv800
> > > > > Target Package : bg432
> > > > > Target Speed   : -4
> > > > > Mapper Version : virtex -- C.22
> > > > >
> > > > > Design Summary
> > > > > --------------
> > > > >    Number of errors:      0
> > > > >    Number of warnings:    4
> > > > >    Number of Slices:              724 out of  9,408    7%
> > > > >       Slice Flip Flops:     537
> > > > >       4 input LUTs:         629 (13 used as a route-thru)
> > > > >       Shift registers:      173
> > > > >    Number of Slices containing
> > > > >       unrelated logic:              0 out of    724    0%
> > > > >    Number of bonded IOBs:          97 out of    316   30%
> > > > >
> > > > > Command Line   : map -r -c 1 -cm speed -detail -o ret_fmul_16_c1
> > > > > ret_fmul_8
> > > > > Target Device  : xv800
> > > > > Target Package : bg432
> > > > > Target Speed   : -4
> > > > > Mapper Version : virtex -- C.22
> > > > >
> > > > > Design Summary
> > > > > --------------
> > > > >    Number of errors:      0
> > > > >    Number of warnings:    3
> > > > >    Number of Slices:              450 out of  9,408    4%
> > > > >       Slice Flip Flops:     324
> > > > >       4 input LUTs:         629 (15 used as a route-thru)
> > > > >       Shift registers:      101
> > > > >    Number of Slices containing
> > > > >       unrelated logic:            118 out of    450   26%
> > > > >    Number of bonded IOBs:          97 out of    316   30%
> > > > >
> > > > > In all cases with and without timing constraints, with multiple PAR
> > > > > passes, the design always fail to route completely. Specifically GND and
> > > > > Vcc signals (among others) do not route : below is an example of one of
> > > > > the PAR report file which ask me to use a larger device while i uses at
> > > > > most 7% of its slices ....
> > > > >
> > > > > What I don't understand is that a relatively equivalent design in terms
> > > > > of complexity (floating point adder) with much more pipelmine stage and
> > > > > less regularity place an route successfully !!
> > > > >
> > > > > Any Xilinx guru to shed the light on this :) ?
> > > > >
> > > > > Steven Derrien
> > > > > IRISA, France
> > > > >
> > > > > Total REAL time: 17 mins 24 secs
> > > > > Total CPU  time: 17 mins 22 secs
> > > > > End of route.  3897 routed (84.35%); 15 unrouted active,
> > > > >    708 unrouted PWR/GND.
> > > > > No errors found.
> > > > > The signal "mul/C3690_C85O" is not completely routed.
> > > > > The signal "GLOBAL_LOGIC1" is not completely routed.
> > > > > The signal "mul/retiming_reg_239Q" is not completely routed.
> > > > > The signal "mul/retiming_reg_237Q" is not completely routed.
> > > > > The signal "mul/C3690_C267/O" is not completely routed.
> > > > > The signal "mul/C3690_C631O" is not completely routed.
> > > > > The signal "GLOBAL_LOGIC0" is not completely routed.
> > > > > The signal "mul/C3690_C1008/O" is not completely routed.
> > > > > The signal "mul/C3690_C1003O" is not completely routed.
> > > > > The signal "mul/retiming_reg_38Q" is not completely routed.
> > > > > The signal "mul/C3690_C1420O" is not completely routed.
> > > > > The signal "mul/retiming_reg_91Q" is not completely routed.
> > > > > The signal "mul/C3690_C1440O" is not completely routed.
> > > > > The signal "mul/retiming_reg_97Q" is not completely routed.
> > > > > The signal "mul/retiming_reg_115Q" is not completely routed.
> > > > > The signal "mul/C3690_C1493/O" is not completely routed.
> > > > > The signal "mul/C3690_C1492O" is not completely routed.
> > > > >
> > > > > This design was not fully routed.  To help fully route the design, you
> > > > > may try
> > > > > the following:
> > > > >   * Retarget the design to the next larger device in this family.
> > > > >
> > > > > --> I only use 7% of the chip ressource !!!!!
> > > > >
> > > > > Total REAL time to Router completion: 17 mins 28 secs
> > > > > Total CPU time to Router completion: 17 mins 26 secs
> > > > >
> > > > > The Number of signals not completely routed for this design is: 17
> > > > >
> > > > > The Average Connection Delay for this design is:        2.890 ns
> > > > > The Maximum Pin Delay is:                              10.541 ns
> > > > > The Average Connection Delay on the 10 Worst Nets is:   7.578 ns
> > > > >
> > > > > Listing Pin Delays by value: (ns)
> > > > >
> > > > >  d < 2.00   < d < 4.00  < d < 6.00  < d < 8.00  < d < 11.00  d >= 11.00
> > > > > ---------   ---------   ---------   ---------   ---------   ---------
> > > > >   1987        1065         228         246         371           0
> > > >
> > > > --
> > > > -Ray Andraka, P.E.
> > > > President, the Andraka Consulting Group, Inc.
> > > > 401/884-7930     Fax 401/884-7950
> > > > email ray@andraka.com
> > > > http://www.andraka.com  or http://www.fpga-guru.com
> >
> > --
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com  or http://www.fpga-guru.com

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com

Article: 27092
Subject: Re: Xilinx PCI Core
From: Andrea Sorio <a.sorio@libero.it>
Date: Fri, 10 Nov 2000 16:35:51 GMT
Links: << >>  << T >>  << A >>
> Not sure if this is the cause of your problem
> But........................
> One of the pain in the Butt things about the Xilinx PCI cores is that
> certain signals have to be tied to a fixed value via D- Flip-Flops so
> that during
> compilation some of the logic doesn't get reduce. Oh, You have
> make it so that these D-Flip-Flops don't get reduce either. This is
> actually explained in their documentation somewhere.
>
> I initially did not do this and found my post-complilation simulation
> core driving the bus all of the time
>
>          iREQUESTHOLD
>          iCFG_SELF
>          iKEEPOUT
>          iC_READY
>          iC_TERM
>
> Here are the signals that I tied high/low  via output of D-Flip Flop,
> not all of these may be required.
>

Yes I done it.

Bye
Andrea

--
A.Sorio
R&D Electronic Engineer

Atenix E.E.
Via S.Dona' 106
30170 Mestre (VE)
ITALY

Tel.    +39-041-2621035
email:  andrea.sorio@atenix.it



Article: 27093
Subject: Re: Non routable design
From: Tim Jaynes <tim.jaynes@xilinx.com>
Date: Fri, 10 Nov 2000 08:46:27 -0800
Links: << >>  << T >>  << A >>
Fred,
You'll note that the key to my arguement is the fact that I recommended
the customer contact our _free_ support service to verify my suggestion.

And it was just that- a suggestion.
I'm not a salesman- just a support engineer, trying to give people on
this news group a hand when I can.
Regards,
Tim

fred wrote:

> Tim,
>
> I hope you will forgive an immediate deep-end response, but
> I am frankly appalled by your reply. You admit you have not
> seen the user's design but immediately suggest he shells out
> for an upgrade. I can only hope that you did not notice that
> the user has only a 7% utilisation within his device.
>
> Irrespective of his design type, a failure to route a <any?>
> design with 7% utilisation is a likely tool bug or fault.
> Your suggestion that he upgrade to get round the problem is
> IMNSHO a major cop out and unworthy of you as a
> representative of Xilinx. I am unaware whether this guy is
> in maintenance or not but if it turns out he is not, and the
> solution is indeed that he upgrade to get round a bug, may I
> suggest he be provided with the upgrade for nowt as the F2.1
> he was sold is 'not fit for purpose'.
>
> I notice Ray has provided what may be a more constructive
> reply.
>
> Regards,
>
> D McLeod
> XEC
>
> Disclaimer: I have assumed that Stephen's design does not
> contain a fatal error which has caused the tools to give a
> misleading error message (that never happens). My comments
> on the 'upgrade regardless' approach remain.
>
> "Tim Jaynes" <tim.jaynes@xilinx.com> wrote in message
> news:3A0B11F4.E0AAD7AA@xilinx.com...
> > Hi Steven,
> > Better PAR performance on routing pwr/gnd nets was one of
> the major
> > enhancements contained in the 3.1i tools and it's
> associated service packs.
> > Without seeing the design and without knowing your
> budgetary constraints I'd
> > recommend a software upgrade (assuming that that's a
> possibility).
> > What I'd do is contact the support hotline (submit a case
> on the web-
> > support.xilinx.com) to open a case.  An engineer here at
> xilinx could easily
> > run your design in the 3.1i tools to see if that migration
> fixes the
> > problem- that way you can make sure that an upgrade would
> be beneficial.
> > Regards,
> > Tim
> >


Article: 27094
Subject: Re: IOBUF's replaced by IBUF's
From: Andrea Sorio <a.sorio@libero.it>
Date: Fri, 10 Nov 2000 16:53:08 GMT
Links: << >>  << T >>  << A >>
Hi

> bidirectional data pins are implemented in VHDL; the synthesis tool
> correctly places IOBUF's. Functional simulation is o.k.
> But MAP removes all output signals including the tristate
> control signal, and replaces all IOBUF's by IBUF's.
>

I had  a similar problem with FPGAExpress.
I have a bidir data bus that feed some r/w register. the simulation is
ok, but fpgaexpress place a outb instead of a iobuf (obuft + inbuf).
I created a process to manage the bidir bus at top level.

  lddd = internal bus
  DDD = external bus

  lddd <= DDD when (RW_N = '0') else "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";

  DDD <= lddd when (RW_N = '1') else "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";

RW_N is an input signale managed from a up.

In this way the FPGAExpress instantiates a outbt and an inbuf.

Good luck!

Bye
Andrea

--
A.Sorio
R&D Electronic Engineer

Atenix E.E.
Via S.Dona' 106
30170 Mestre (VE)
ITALY

Tel.    +39-041-2621035
email:  andrea.sorio@atenix.it



Article: 27095
Subject: Re: VHDL: FFS in IOBs
From: Tim Jaynes <tim.jaynes@xilinx.com>
Date: Fri, 10 Nov 2000 08:58:30 -0800
Links: << >>  << T >>  << A >>
Harry,
There are a couple options available to you.
For the best description go to:
http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=6214

This is a xilinx answer entitled 'Virtex - How do I use the
registers/Flip-Flops in
the IOB'.  It's answer #6214.
Regards,
Tim

Harry wrote:

> Hi,
> How to instantiate FFs in Xilinx IOBs in VHDL?? Please advise.
> Harry


Article: 27096
Subject: Re: Pull-up
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Fri, 10 Nov 2000 10:23:50 -0700
Links: << >>  << T >>  << A >>
Jonas wrote:
> 
> Hi
> Is it possible to configurate a pin as an open drain and at the same time use an internal pull up? I use a SpartanXL (XCS40XL). If this i possible, how do I describe it in VHDL?

I think you have to add the pullup in the P+R stage, by placing a PULLUP
constraint on the pin.

The open-drain output is easy:

	outpin <= '0' when en_l = '0' else 'Z';

Note that FPGA Express (up to and including v3.4) is stupid and requires
active-low tristate enables, even tho' the chip architecture has a
polarity-select mux.  I haven't tested this with Synplify.

-- a
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u

"It is better to be silent and thought a fool, 
 than to send an e-mail to the entire company
 and remove all doubt."

Article: 27097
Subject: Re: Microprocessor Verilog/VHDL Models
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Fri, 10 Nov 2000 10:27:03 -0700
Links: << >>  << T >>  << A >>
Jeremy Cooke wrote:
> 
> Might want to check this site:
> 
> http://www.fpgacpu.org/

Jeremy,

Simon doesn't want to put the CPU into the FPGA.  He just wants to
simulate his FPGA as connected to an off-the-shelf Motorola CPU.

-- a
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u

"It is better to be silent and thought a fool, 
 than to send an e-mail to the entire company
 and remove all doubt."

Article: 27098
Subject: Re: Microprocessor Verilog/VHDL Models
From: "S. Ramirez" <sramirez@deleet.cfl.rr.com>
Date: Fri, 10 Nov 2000 17:52:25 GMT
Links: << >>  << T >>  << A >>
Correct!!!  Besides, the ColdFire isn't in there.
-SImon Ramirez, Consultant
Synchronous Design, Inc.


"Andy Peters n o a o [.] e d u>" <"apeters <"@> wrote in message
news:8uhb7o$10qi$3@noao.edu...
> Jeremy Cooke wrote:
> >
> > Might want to check this site:
> >
> > http://www.fpgacpu.org/
>
> Jeremy,
>
> Simon doesn't want to put the CPU into the FPGA.  He just wants to
> simulate his FPGA as connected to an off-the-shelf Motorola CPU.
>
> -- a
> ----------------------------
> Andy Peters
> Sr. Electrical Engineer
> National Optical Astronomy Observatory
> 950 N Cherry Ave
> Tucson, AZ 85719
> apeters (at) n o a o [dot] e d u
>
> "It is better to be silent and thought a fool,
>  than to send an e-mail to the entire company
>  and remove all doubt."
>



Article: 27099
Subject: Re: Pull-up
From: Ray Andraka <ray@andraka.com>
Date: Fri, 10 Nov 2000 18:34:25 GMT
Links: << >>  << T >>  << A >>
It is possible, however I strongly recommend you use an external pullup.  The
internal pull ups are weak pull ups sufficient to tie an unconnected pin high. 
However when that pin has a trace and loads attached, the pull up value is
really too small to ensure a) that the trace does not act as an antenna and b)
that the open drain output goes back high in a reasonable amount of time.  The
high impedance (>100K) of the internal pullup does little to guarantee this.

Andy Peters wrote:
> 
> Jonas wrote:
> >
> > Hi
> > Is it possible to configurate a pin as an open drain and at the same time use an internal pull up? I use a SpartanXL (XCS40XL). If this i possible, how do I describe it in VHDL?
> 
> I think you have to add the pullup in the P+R stage, by placing a PULLUP
> constraint on the pin.
> 
> The open-drain output is easy:
> 
>         outpin <= '0' when en_l = '0' else 'Z';
> 
> Note that FPGA Express (up to and including v3.4) is stupid and requires
> active-low tristate enables, even tho' the chip architecture has a
> polarity-select mux.  I haven't tested this with Synplify.
> 
> -- a
> ----------------------------
> Andy Peters
> Sr. Electrical Engineer
> National Optical Astronomy Observatory
> 950 N Cherry Ave
> Tucson, AZ 85719
> apeters (at) n o a o [dot] e d u
> 
> "It is better to be silent and thought a fool,
>  than to send an e-mail to the entire company
>  and remove all doubt."

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.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
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