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 55550

Article: 55550
Subject: Re: PLL in fpga
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Mon, 12 May 2003 07:27:31 -0700
Links: << >>  << T >>  << A >>
Jochen,

The Spartan III DCM is the same design (with some improvements) as the
Virtex II, and the Virtex II Pro.  That said, the min input F is 1 MHz
if using the DFS alone (and a multiplier to get the Fout to the
minimum).  The max Fout is still being charachterized in order to set
the low frequency more, and the high frequency mode (LF and HF)
attributes for the bitstream.

If you use the DLL, (or the DLL+DFS) then the min Fin is the same as the
min Fout.  Just like VII and VII Pro.

Austin


Jochen Frensch wrote:
> 
> Hi Austin,
> 
> haven't found any specification for Spartan-III-DCM yet, but "DS099-3
> (v1.0) April 11, 2003" says Minimum 25 MHz as a DLL-Input !?!!! - NOT
> 1 MHz
> 
> Are there any further specifications (I haven't found yet) ?

Article: 55551
Subject: Re: OK I am pissed off with Xilinx webpack.
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Mon, 12 May 2003 07:31:36 -0700
Links: << >>  << T >>  << A >>
Jan,

Take a deep breath, count to ten.

Computers always do what they are told, that is why programmers are
often seen banging their heads against the walls.

"Do what I want, not what I told you to do!"

When someone figures out how to do that, they will be rich.  And famous.

Austin


Jan Panteltje wrote:
> 
> It should:
> Do as it is told.
> Not change things.
> Not give cryptographic messages like:
>  'udc0_uf1_s2_Mrom_dout_inst_mux_f5_48'
>  I can find out what it is perhaps, but it should refer to the verilog code
>  names.
> I do not care if it is driving a 'MUXF6', a F16 or an apple tree.
> It should just do it if I requested it.
> EVEN IF IT DOES NOT WORK OR CAUSES AN EARTHQUAKE
> Else you get in a loop of endless trying.
> 
> If I use a hammer and break it on something fine.
> I do NOT want a hammer that warns me and refuses to hit any nail it
> thinks is bend.
> 'I' am the designer.
> And I never asked for a MUXF5 OR a MUXF6.
> This whole thing is just GATES!
> 
> Oh, I see, GATES -> Microsoft -> oh, should have known.
> OK, cut that remark, it is unfair, but it shows US acquired Taliban...
> OK cut that too.
> But what has MS brought us? Advertizing on internet.
> NSA backdoor, they know everything.
> I bet they also know good tools to program FPGA.
> 
> Design Summary
> --------------
>    Number of errors:      0
>    Number of warnings:   27
>    Number of Slices:              2,350 out of  2,352   99%
>    Number of Slices containing
>       unrelated logic:               37 out of  2,350    1%
>    Total Number Slice Registers:    281 out of  4,704    5%
>       Number used as Flip Flops:                  280
>       Number used as Latches:                       1
>    Total Number 4 input LUTs:     4,183 out of  4,704   88%
>       Number used as LUTs:                      3,761
>       Number used as a route-thru:                422
>    Number of bonded IOBs:             3 out of    140    2%
>    Number of GCLKIOBs:                2 out of      4   50%
> Total equivalent gate count for design:  38,728
> Additional JTAG gate count for IOBs:  240
> 
> Table of Contents
> -----------------
> Section 1 - Errors
> Section 2 - Warnings
> Section 3 - Informational
> Section 4 - Removed Logic Summary
> Section 5 - Removed Logic
> Section 6 - IOB Properties
> Section 7 - RPMs
> Section 8 - Guide Report
> Section 9 - Area Group Summary
> Section 10 - Modular Design Summary
> 
> Section 1 - Errors
> ------------------
> 
> Section 2 - Warnings
> --------------------
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_48" (output
> 
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_48) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_49" (output
> 
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_49) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_50" (output
> 
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_50) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_51" (output
> 
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_51) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_52" (output
> 
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_52) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_53" (output
> 
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_53) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_54" (output
> 
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_54) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_55" (output
> 
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_55) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_40" (output
> 
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_40) can be reduced to a constant
> 
>    driver. However, since it is driving a MUXF6, such optimization will not be
> 
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_41" (output
> 
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_41) can be reduced to a constant
> 
>    driver. However, since it is driving a MUXF6, such optimization will not be
> 
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_42" (output
> 
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_42) can be reduced to a constant
> 
>    driver. However, since it is driving a MUXF6, such optimization will not be
> 
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_43" (output
> 
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_43) can be reduced to a constant
> 
>    driver. However, since it is driving a MUXF6, such optimization will not be
> 
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_44" (output
> 
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_44) can be reduced to a constant
> 
>    driver. However, since it is driving a MUXF6, such optimization will not be
> 
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_45" (output
> 
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_45) can be reduced to a constant
> 
>    driver. However, since it is driving a MUXF6, such optimization will not be
> 
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_46" (output
> 
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_46) can be reduced to a constant
> 
>    driver. However, since it is driving a MUXF6, such optimization will not be
> 
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_47" (output
> 
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_47) can be reduced to a constant
> 
>    driver. However, since it is driving a MUXF6, such optimization will not be
> 
>    carried out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_8" (output
> 
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_8) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_9" (output
> 
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_9) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_10" (output
> 
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_10) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_11" (output
> 
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_11) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_12" (output
> 
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_12) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_13" (output
> 
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_13) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_14" (output
> 
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_14) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_15" (output
> 
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_15) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> 
> And indeed it gives an error and asks me to RELOC or whatever something
> that I cannot even locate as it has not mapped anything....
> 
> All this stuff takes too much time.
> 
> And this is highly expanded optimized logic for SPEED.
> 
>

Article: 55552
Subject: Re: Price of CPLDs
From: Jim Stewart <jstewart@jkmicro.com>
Date: Mon, 12 May 2003 08:30:59 -0700
Links: << >>  << T >>  << A >>
rickman wrote:
> Jim Granville wrote:
> 
>>rickman wrote:
>>
>><snip>
>>
>>>>>Price and Availability
>>>>>The ispXPLD 5512MX in the 1.0mm ball pitch, 484 fpBGA package will sample later this quarter
>>>>>with initial production scheduled for Q4. Pricing for the ispXPLD 5512MC in volumes of >1000
>>>>>pieces starts at $17.75. Additional members of the ispXPLD 5000MX family are expected to be
>>>>>released over the coming year.
>>>>
>>>>-jg
>>>
>>>I remember looking at the XPLD parts and there is something about them
>>>that does not fit the socket.  I remember now.  It was the price...
>>
>><snip>
>>
>>>I wonder how nicely I would have to ask to get the price down from $83 to
>>>$20???  :)
>>
>> I'd start by quoting their press release back to them, that states
>>$17.75/1000 :)
>>
>> This was not a 'Price 2 years out in million pcs' as I have seen other
>>do,
>>but claims to be a 2002 price, 1000 pcs column.
> 
> 
> Thanks, that's a good idea.  Not only did I find the press release you
> describe, but there is also one on the 4000V family which has a $15
> price on the 512 part.  I am only asking them to meet a $20 price
> point.  I have printed both pages to PDF and will forward them on to the
> sales rep.  He had already sent me an email indicating an interest in
> discussing the price disparity after I told him what I had posted here. 
> This will give me a bit more ammunition for him to work with.  
> 
> Of course I am asking for pricing on qty 100 rather than 1000, but I
> would hope there would not be a 2x difference in price.  

Unless you're concerned it will jeopardize your negotiations,
please let us know what you find out.




Article: 55553
Subject: Re: OK I am pissed off with Xilinx webpack.
From: Chen Wei Tseng <chenwei.tseng@xilinx.com>
Date: Mon, 12 May 2003 11:52:44 -0600
Links: << >>  << T >>  << A >>
Hi Jan,

You may first want to find out where this net name is coming from. You can track it
in your netlist or your ncd file. If you have edn/edf file for your netlist, it's
easy enough to open it with wordpad or vi to find the net/comp name. With XST, you
can use the RTLviewer function. If not in the netlist, then it's likely a physical
net/comp name that can be tracked with FPGA Editor. Do note that Webpack may not
have FPGA Editor or RTL viewer.

Such names are usually the results of inferred logic or macro primitves. If you're
having trouble locating the problem, the Xilinx support hotline are equipped with
tools to probe into such problems.

Best Regard, Wei
Xilinx Applications

Jan Panteltje wrote:

> It should:
> Do as it is told.
> Not change things.
> Not give cryptographic messages like:
>  'udc0_uf1_s2_Mrom_dout_inst_mux_f5_48'
>  I can find out what it is perhaps, but it should refer to the verilog code
>  names.
> I do not care if it is driving a 'MUXF6', a F16 or an apple tree.
> It should just do it if I requested it.
> EVEN IF IT DOES NOT WORK OR CAUSES AN EARTHQUAKE
> Else you get in a loop of endless trying.
>
> If I use a hammer and break it on something fine.
> I do NOT want a hammer that warns me and refuses to hit any nail it
> thinks is bend.
> 'I' am the designer.
> And I never asked for a MUXF5 OR a MUXF6.
> This whole thing is just GATES!
>
> Oh, I see, GATES -> Microsoft -> oh, should have known.
> OK, cut that remark, it is unfair, but it shows US acquired Taliban...
> OK cut that too.
> But what has MS brought us? Advertizing on internet.
> NSA backdoor, they know everything.
> I bet they also know good tools to program FPGA.
>
> Design Summary
> --------------
>    Number of errors:      0
>    Number of warnings:   27
>    Number of Slices:              2,350 out of  2,352   99%
>    Number of Slices containing
>       unrelated logic:               37 out of  2,350    1%
>    Total Number Slice Registers:    281 out of  4,704    5%
>       Number used as Flip Flops:                  280
>       Number used as Latches:                       1
>    Total Number 4 input LUTs:     4,183 out of  4,704   88%
>       Number used as LUTs:                      3,761
>       Number used as a route-thru:                422
>    Number of bonded IOBs:             3 out of    140    2%
>    Number of GCLKIOBs:                2 out of      4   50%
> Total equivalent gate count for design:  38,728
> Additional JTAG gate count for IOBs:  240
>
> Table of Contents
> -----------------
> Section 1 - Errors
> Section 2 - Warnings
> Section 3 - Informational
> Section 4 - Removed Logic Summary
> Section 5 - Removed Logic
> Section 6 - IOB Properties
> Section 7 - RPMs
> Section 8 - Guide Report
> Section 9 - Area Group Summary
> Section 10 - Modular Design Summary
>
> Section 1 - Errors
> ------------------
>
> Section 2 - Warnings
> --------------------
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_48" (output
>
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_48) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_49" (output
>
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_49) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_50" (output
>
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_50) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_51" (output
>
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_51) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_52" (output
>
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_52) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_53" (output
>
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_53) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_54" (output
>
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_54) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_55" (output
>
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_55) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_40" (output
>
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_40) can be reduced to a constant
>
>    driver. However, since it is driving a MUXF6, such optimization will not be
>
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_41" (output
>
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_41) can be reduced to a constant
>
>    driver. However, since it is driving a MUXF6, such optimization will not be
>
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_42" (output
>
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_42) can be reduced to a constant
>
>    driver. However, since it is driving a MUXF6, such optimization will not be
>
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_43" (output
>
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_43) can be reduced to a constant
>
>    driver. However, since it is driving a MUXF6, such optimization will not be
>
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_44" (output
>
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_44) can be reduced to a constant
>
>    driver. However, since it is driving a MUXF6, such optimization will not be
>
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_45" (output
>
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_45) can be reduced to a constant
>
>    driver. However, since it is driving a MUXF6, such optimization will not be
>
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_46" (output
>
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_46) can be reduced to a constant
>
>    driver. However, since it is driving a MUXF6, such optimization will not be
>
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_47" (output
>
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_47) can be reduced to a constant
>
>    driver. However, since it is driving a MUXF6, such optimization will not be
>
>    carried out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_8" (output
>
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_8) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_9" (output
>
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_9) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_10" (output
>
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_10) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_11" (output
>
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_11) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_12" (output
>
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_12) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_13" (output
>
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_13) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_14" (output
>
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_14) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_15" (output
>
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_15) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
>
> And indeed it gives an error and asks me to RELOC or whatever something
> that I cannot even locate as it has not mapped anything....
>
> All this stuff takes too much time.
>
> And this is highly expanded optimized logic for SPEED.
>
>


Article: 55554
Subject: Re: Exploting the DDR input registers in Virtex2
From: "Avrum" <avrum@REMOVEsympatico.ca>
Date: Mon, 12 May 2003 14:17:27 -0400
Links: << >>  << T >>  << A >>
What do you want to do with the DDR flops. These are not general purpose
flops that can be used in place of a core flop; they are specifically there
to clock the data on the input pin - the D input of both INFF flops in an
IOB can ONLY be connected to the input receiver of the IOB.

That being said, their only use is for clocking in data from the pin. If a
particular IOB is used by the PCI-X core, then the second INFF flop can only
be used to clock in data from the same pin, potentially using a different
clock (since the two INFF flops can be clocked using different clocks). They
are called "DDR" flops, because the most common application is to clock the
same signal on the rising and falling edge of the clock (hence double data
rate) - one INFF is configured to clock the data on the rising edge of a
particular clock, and the other INFF is configured to clock the data on the
falling edge of the clock, either using the local inversion available for
the clock port of the IOB, or by providing a second clock from a BUFG which
is 180 degrees out of phase with the first.

Synthesis tools that understand the DDR input flops will infer them when
they sees the following code (with a number of variations having to do with
RST, etc...)

reg q_ck1, q_ck2;
always @(posedge clk1)
  q_ck1 <= in;

always @(posedge clk2)
  q_ck2 <= in;

If the original code only uses one of these (i.e. the posedge clk2 part
doesn't exist), then it uses only one of the two INFF flops, and the other
is unused. To use it, you need to add the second posedge statement. The
right hand side of the assignment MUST be the same in the two always @
statements, the clocks can be different.

I am not sure if the second always @ can exist in a different module (i.e.
outside the PCI-X core) - I would suspect not. Therefore you would have to
modify the source of the core to bring in the second clock, bring out the
new output (q_ck2), and add the second posedge statement.

Be aware that there are a fair number of rules regarding the use of the
second INFF; rules regarding reset and enables, rules regarding the
distribution of clocks to a PAIR of IOBs (there can only be 2 clocks for the
4 INFFs in a pair of IOBs, 2 clocks for the 4 OUTFFs and 4 tristate FFs),
etc...

Avrum

"John Daae" <john.daae@datarespons.no> wrote in message
news:3ebf4368$0$9499$4d4ebb8e@read.news.no.uu.net...
> I am implementing a system using a PCI-X core from Xilinx and I want to to
> use the spare input registers (the second DDR input register) that the
core
> is not using. I have tried using IOB attribute on the actual signals in my
> VHDL code and I have tried IOB = TRUE constraint in the UCF file, but the
> PAR seems to ignore these guidings.
>
> Any suggestions?
> Is there a primitive for inputs register that I can instatiate?
>
>
> Thanks
>
>
> John
>
>
>
>



Article: 55555
Subject: ModelSim and Specman: on the fly generation
From: tardi69@hotmail.com (Paolo Tardivel)
Date: 12 May 2003 11:44:28 -0700
Links: << >>  << T >>  << A >>
Hi,

I have implemented a testbench in e that drives a VHDL design on the fly.

The VHDL file I drive acts as a shell for the design and simply
contains the signals that I need to drive.  This file contains the
necessary code to link Specman and ModelSim and is called macro.vhd. 
These signals are then driven into the design in a file called sig_lib
as follows:

   inst_mstim: macro
   PORT MAP (
      master_datain => master_datain,
      master_addr => master_addr,
      ...
      clk => CLK,
      resetn => resetn
   );

This all works fine and the values driven into the signals can be seen
in ModelSim's waveform viewer.  However I want to be able to view all
the signals from the design (not just the ones I am driving), in order
to view the dataout signals.

So what I want to be able to do is Specman to drive macro.vhd, but
ModelSim to load sig_lib.vhd, while keeping the "on the fly" nature of
my implementation.

I am currently using the following command to invoke Specman and
ModelSim (after everything is compiled):

   specview vsim -keepstdout macro

The problem seems to be that I need to be able to supply Specman and
ModelSim with different entities.

Does anyone know of a way of doing this, on the fly or otherwise?

Thanks,

Paolo

Article: 55556
Subject: Re: PacMan game in FPGA
From: "Wil Limbacher" <phony@nowhere.cc>
Date: Mon, 12 May 2003 11:57:10 -0700
Links: << >>  << T >>  << A >>
Thanks for the info.

"Dave Vanden Bout" <devb@xess.com> wrote in message
news:3EBF9448.DDD3197B@xess.com...
> Wil Limbacher wrote:
>
> > I'm looking at the XSA100 for a project, but there's one thing I can't
seem
> > to find in the literature. What's the speed grade of the XC2S100 part on
the
> > board?
>
> It's a -5 part.
>



Article: 55557
Subject: Re: OK I am pissed off with Xilinx webpack.
From: "Theron Hicks" <hicksthe@egr.msu.edu>
Date: Mon, 12 May 2003 15:43:56 -0400
Links: << >>  << T >>  << A >>
Wei,
    He said he was using WEBPACK.  You cannot get support from the hotline
for WEBPACK can you?
Theron Hicks

"Chen Wei Tseng" <chenwei.tseng@xilinx.com> wrote in message
news:3EBFDF6C.5503E124@xilinx.com...
> Hi Jan,
>
> You may first want to find out where this net name is coming from. You can
track it
> in your netlist or your ncd file. If you have edn/edf file for your
netlist, it's
> easy enough to open it with wordpad or vi to find the net/comp name. With
XST, you
> can use the RTLviewer function. If not in the netlist, then it's likely a
physical
> net/comp name that can be tracked with FPGA Editor. Do note that Webpack
may not
> have FPGA Editor or RTL viewer.
>
> Such names are usually the results of inferred logic or macro primitves.
If you're
> having trouble locating the problem, the Xilinx support hotline are
equipped with
> tools to probe into such problems.
>
> Best Regard, Wei
> Xilinx Applications
>
> Jan Panteltje wrote:
>
> > It should:
> > Do as it is told.
> > Not change things.
> > Not give cryptographic messages like:
> >  'udc0_uf1_s2_Mrom_dout_inst_mux_f5_48'
> >  I can find out what it is perhaps, but it should refer to the verilog
code
> >  names.
> > I do not care if it is driving a 'MUXF6', a F16 or an apple tree.
> > It should just do it if I requested it.
> > EVEN IF IT DOES NOT WORK OR CAUSES AN EARTHQUAKE
> > Else you get in a loop of endless trying.
> >
> > If I use a hammer and break it on something fine.
> > I do NOT want a hammer that warns me and refuses to hit any nail it
> > thinks is bend.
> > 'I' am the designer.
> > And I never asked for a MUXF5 OR a MUXF6.
> > This whole thing is just GATES!
> >
> > Oh, I see, GATES -> Microsoft -> oh, should have known.
> > OK, cut that remark, it is unfair, but it shows US acquired Taliban...
> > OK cut that too.
> > But what has MS brought us? Advertizing on internet.
> > NSA backdoor, they know everything.
> > I bet they also know good tools to program FPGA.
> >
> > Design Summary
> > --------------
> >    Number of errors:      0
> >    Number of warnings:   27
> >    Number of Slices:              2,350 out of  2,352   99%
> >    Number of Slices containing
> >       unrelated logic:               37 out of  2,350    1%
> >    Total Number Slice Registers:    281 out of  4,704    5%
> >       Number used as Flip Flops:                  280
> >       Number used as Latches:                       1
> >    Total Number 4 input LUTs:     4,183 out of  4,704   88%
> >       Number used as LUTs:                      3,761
> >       Number used as a route-thru:                422
> >    Number of bonded IOBs:             3 out of    140    2%
> >    Number of GCLKIOBs:                2 out of      4   50%
> > Total equivalent gate count for design:  38,728
> > Additional JTAG gate count for IOBs:  240
> >
> > Table of Contents
> > -----------------
> > Section 1 - Errors
> > Section 2 - Warnings
> > Section 3 - Informational
> > Section 4 - Removed Logic Summary
> > Section 5 - Removed Logic
> > Section 6 - IOB Properties
> > Section 7 - RPMs
> > Section 8 - Guide Report
> > Section 9 - Area Group Summary
> > Section 10 - Modular Design Summary
> >
> > Section 1 - Errors
> > ------------------
> >
> > Section 2 - Warnings
> > --------------------
> > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_48"
(output
> >
> >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_48) is configured as a
route-thru.
> >
> >    However, since it is driving a MUXF6, such transformation will not be
carried
> >
> >    out.
> > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_49"
(output
> >
> >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_49) is configured as a
route-thru.
> >
> >    However, since it is driving a MUXF6, such transformation will not be
carried
> >
> >    out.
> > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_50"
(output
> >
> >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_50) is configured as a
route-thru.
> >
> >    However, since it is driving a MUXF6, such transformation will not be
carried
> >
> >    out.
> > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_51"
(output
> >
> >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_51) is configured as a
route-thru.
> >
> >    However, since it is driving a MUXF6, such transformation will not be
carried
> >
> >    out.
> > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_52"
(output
> >
> >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_52) is configured as a
route-thru.
> >
> >    However, since it is driving a MUXF6, such transformation will not be
carried
> >
> >    out.
> > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_53"
(output
> >
> >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_53) is configured as a
route-thru.
> >
> >    However, since it is driving a MUXF6, such transformation will not be
carried
> >
> >    out.
> > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_54"
(output
> >
> >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_54) is configured as a
route-thru.
> >
> >    However, since it is driving a MUXF6, such transformation will not be
carried
> >
> >    out.
> > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_55"
(output
> >
> >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_55) is configured as a
route-thru.
> >
> >    However, since it is driving a MUXF6, such transformation will not be
carried
> >
> >    out.
> > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_40"
(output
> >
> >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_40) can be reduced to a
constant
> >
> >    driver. However, since it is driving a MUXF6, such optimization will
not be
> >
> >    carried out.
> > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_41"
(output
> >
> >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_41) can be reduced to a
constant
> >
> >    driver. However, since it is driving a MUXF6, such optimization will
not be
> >
> >    carried out.
> > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_42"
(output
> >
> >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_42) can be reduced to a
constant
> >
> >    driver. However, since it is driving a MUXF6, such optimization will
not be
> >
> >    carried out.
> > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_43"
(output
> >
> >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_43) can be reduced to a
constant
> >
> >    driver. However, since it is driving a MUXF6, such optimization will
not be
> >
> >    carried out.
> > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_44"
(output
> >
> >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_44) can be reduced to a
constant
> >
> >    driver. However, since it is driving a MUXF6, such optimization will
not be
> >
> >    carried out.
> > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_45"
(output
> >
> >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_45) can be reduced to a
constant
> >
> >    driver. However, since it is driving a MUXF6, such optimization will
not be
> >
> >    carried out.
> > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_46"
(output
> >
> >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_46) can be reduced to a
constant
> >
> >    driver. However, since it is driving a MUXF6, such optimization will
not be
> >
> >    carried out.
> > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_47"
(output
> >
> >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_47) can be reduced to a
constant
> >
> >    driver. However, since it is driving a MUXF6, such optimization will
not be
> >
> >    carried out.
> > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_8"
(output
> >
> >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_8) is configured as a
route-thru.
> >
> >    However, since it is driving a MUXF6, such transformation will not be
carried
> >
> >    out.
> > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_9"
(output
> >
> >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_9) is configured as a
route-thru.
> >
> >    However, since it is driving a MUXF6, such transformation will not be
carried
> >
> >    out.
> > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_10"
(output
> >
> >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_10) is configured as a
route-thru.
> >
> >    However, since it is driving a MUXF6, such transformation will not be
carried
> >
> >    out.
> > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_11"
(output
> >
> >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_11) is configured as a
route-thru.
> >
> >    However, since it is driving a MUXF6, such transformation will not be
carried
> >
> >    out.
> > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_12"
(output
> >
> >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_12) is configured as a
route-thru.
> >
> >    However, since it is driving a MUXF6, such transformation will not be
carried
> >
> >    out.
> > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_13"
(output
> >
> >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_13) is configured as a
route-thru.
> >
> >    However, since it is driving a MUXF6, such transformation will not be
carried
> >
> >    out.
> > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_14"
(output
> >
> >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_14) is configured as a
route-thru.
> >
> >    However, since it is driving a MUXF6, such transformation will not be
carried
> >
> >    out.
> > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_15"
(output
> >
> >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_15) is configured as a
route-thru.
> >
> >    However, since it is driving a MUXF6, such transformation will not be
carried
> >
> >    out.
> >
> > And indeed it gives an error and asks me to RELOC or whatever something
> > that I cannot even locate as it has not mapped anything....
> >
> > All this stuff takes too much time.
> >
> > And this is highly expanded optimized logic for SPEED.
> >
> >
>



Article: 55558
Subject: Re: OK I am pissed off with Xilinx webpack.
From: Chen Wei Tseng <chenwei.tseng@xilinx.com>
Date: Mon, 12 May 2003 13:53:45 -0600
Links: << >>  << T >>  << A >>
Theron,

I believe hotline does support customer who uses Webpack. The exception are
university students. I believe university professors and researchers who uses
webpack are all supported by the hotline still.

Regards, Wei

Theron Hicks wrote:

> Wei,
>     He said he was using WEBPACK.  You cannot get support from the hotline
> for WEBPACK can you?
> Theron Hicks
>
> "Chen Wei Tseng" <chenwei.tseng@xilinx.com> wrote in message
> news:3EBFDF6C.5503E124@xilinx.com...
> > Hi Jan,
> >
> > You may first want to find out where this net name is coming from. You can
> track it
> > in your netlist or your ncd file. If you have edn/edf file for your
> netlist, it's
> > easy enough to open it with wordpad or vi to find the net/comp name. With
> XST, you
> > can use the RTLviewer function. If not in the netlist, then it's likely a
> physical
> > net/comp name that can be tracked with FPGA Editor. Do note that Webpack
> may not
> > have FPGA Editor or RTL viewer.
> >
> > Such names are usually the results of inferred logic or macro primitves.
> If you're
> > having trouble locating the problem, the Xilinx support hotline are
> equipped with
> > tools to probe into such problems.
> >
> > Best Regard, Wei
> > Xilinx Applications
> >
> > Jan Panteltje wrote:
> >
> > > It should:
> > > Do as it is told.
> > > Not change things.
> > > Not give cryptographic messages like:
> > >  'udc0_uf1_s2_Mrom_dout_inst_mux_f5_48'
> > >  I can find out what it is perhaps, but it should refer to the verilog
> code
> > >  names.
> > > I do not care if it is driving a 'MUXF6', a F16 or an apple tree.
> > > It should just do it if I requested it.
> > > EVEN IF IT DOES NOT WORK OR CAUSES AN EARTHQUAKE
> > > Else you get in a loop of endless trying.
> > >
> > > If I use a hammer and break it on something fine.
> > > I do NOT want a hammer that warns me and refuses to hit any nail it
> > > thinks is bend.
> > > 'I' am the designer.
> > > And I never asked for a MUXF5 OR a MUXF6.
> > > This whole thing is just GATES!
> > >
> > > Oh, I see, GATES -> Microsoft -> oh, should have known.
> > > OK, cut that remark, it is unfair, but it shows US acquired Taliban...
> > > OK cut that too.
> > > But what has MS brought us? Advertizing on internet.
> > > NSA backdoor, they know everything.
> > > I bet they also know good tools to program FPGA.
> > >
> > > Design Summary
> > > --------------
> > >    Number of errors:      0
> > >    Number of warnings:   27
> > >    Number of Slices:              2,350 out of  2,352   99%
> > >    Number of Slices containing
> > >       unrelated logic:               37 out of  2,350    1%
> > >    Total Number Slice Registers:    281 out of  4,704    5%
> > >       Number used as Flip Flops:                  280
> > >       Number used as Latches:                       1
> > >    Total Number 4 input LUTs:     4,183 out of  4,704   88%
> > >       Number used as LUTs:                      3,761
> > >       Number used as a route-thru:                422
> > >    Number of bonded IOBs:             3 out of    140    2%
> > >    Number of GCLKIOBs:                2 out of      4   50%
> > > Total equivalent gate count for design:  38,728
> > > Additional JTAG gate count for IOBs:  240
> > >
> > > Table of Contents
> > > -----------------
> > > Section 1 - Errors
> > > Section 2 - Warnings
> > > Section 3 - Informational
> > > Section 4 - Removed Logic Summary
> > > Section 5 - Removed Logic
> > > Section 6 - IOB Properties
> > > Section 7 - RPMs
> > > Section 8 - Guide Report
> > > Section 9 - Area Group Summary
> > > Section 10 - Modular Design Summary
> > >
> > > Section 1 - Errors
> > > ------------------
> > >
> > > Section 2 - Warnings
> > > --------------------
> > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_48"
> (output
> > >
> > >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_48) is configured as a
> route-thru.
> > >
> > >    However, since it is driving a MUXF6, such transformation will not be
> carried
> > >
> > >    out.
> > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_49"
> (output
> > >
> > >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_49) is configured as a
> route-thru.
> > >
> > >    However, since it is driving a MUXF6, such transformation will not be
> carried
> > >
> > >    out.
> > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_50"
> (output
> > >
> > >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_50) is configured as a
> route-thru.
> > >
> > >    However, since it is driving a MUXF6, such transformation will not be
> carried
> > >
> > >    out.
> > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_51"
> (output
> > >
> > >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_51) is configured as a
> route-thru.
> > >
> > >    However, since it is driving a MUXF6, such transformation will not be
> carried
> > >
> > >    out.
> > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_52"
> (output
> > >
> > >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_52) is configured as a
> route-thru.
> > >
> > >    However, since it is driving a MUXF6, such transformation will not be
> carried
> > >
> > >    out.
> > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_53"
> (output
> > >
> > >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_53) is configured as a
> route-thru.
> > >
> > >    However, since it is driving a MUXF6, such transformation will not be
> carried
> > >
> > >    out.
> > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_54"
> (output
> > >
> > >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_54) is configured as a
> route-thru.
> > >
> > >    However, since it is driving a MUXF6, such transformation will not be
> carried
> > >
> > >    out.
> > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_55"
> (output
> > >
> > >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_55) is configured as a
> route-thru.
> > >
> > >    However, since it is driving a MUXF6, such transformation will not be
> carried
> > >
> > >    out.
> > > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_40"
> (output
> > >
> > >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_40) can be reduced to a
> constant
> > >
> > >    driver. However, since it is driving a MUXF6, such optimization will
> not be
> > >
> > >    carried out.
> > > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_41"
> (output
> > >
> > >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_41) can be reduced to a
> constant
> > >
> > >    driver. However, since it is driving a MUXF6, such optimization will
> not be
> > >
> > >    carried out.
> > > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_42"
> (output
> > >
> > >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_42) can be reduced to a
> constant
> > >
> > >    driver. However, since it is driving a MUXF6, such optimization will
> not be
> > >
> > >    carried out.
> > > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_43"
> (output
> > >
> > >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_43) can be reduced to a
> constant
> > >
> > >    driver. However, since it is driving a MUXF6, such optimization will
> not be
> > >
> > >    carried out.
> > > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_44"
> (output
> > >
> > >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_44) can be reduced to a
> constant
> > >
> > >    driver. However, since it is driving a MUXF6, such optimization will
> not be
> > >
> > >    carried out.
> > > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_45"
> (output
> > >
> > >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_45) can be reduced to a
> constant
> > >
> > >    driver. However, since it is driving a MUXF6, such optimization will
> not be
> > >
> > >    carried out.
> > > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_46"
> (output
> > >
> > >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_46) can be reduced to a
> constant
> > >
> > >    driver. However, since it is driving a MUXF6, such optimization will
> not be
> > >
> > >    carried out.
> > > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_47"
> (output
> > >
> > >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_47) can be reduced to a
> constant
> > >
> > >    driver. However, since it is driving a MUXF6, such optimization will
> not be
> > >
> > >    carried out.
> > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_8"
> (output
> > >
> > >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_8) is configured as a
> route-thru.
> > >
> > >    However, since it is driving a MUXF6, such transformation will not be
> carried
> > >
> > >    out.
> > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_9"
> (output
> > >
> > >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_9) is configured as a
> route-thru.
> > >
> > >    However, since it is driving a MUXF6, such transformation will not be
> carried
> > >
> > >    out.
> > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_10"
> (output
> > >
> > >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_10) is configured as a
> route-thru.
> > >
> > >    However, since it is driving a MUXF6, such transformation will not be
> carried
> > >
> > >    out.
> > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_11"
> (output
> > >
> > >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_11) is configured as a
> route-thru.
> > >
> > >    However, since it is driving a MUXF6, such transformation will not be
> carried
> > >
> > >    out.
> > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_12"
> (output
> > >
> > >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_12) is configured as a
> route-thru.
> > >
> > >    However, since it is driving a MUXF6, such transformation will not be
> carried
> > >
> > >    out.
> > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_13"
> (output
> > >
> > >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_13) is configured as a
> route-thru.
> > >
> > >    However, since it is driving a MUXF6, such transformation will not be
> carried
> > >
> > >    out.
> > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_14"
> (output
> > >
> > >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_14) is configured as a
> route-thru.
> > >
> > >    However, since it is driving a MUXF6, such transformation will not be
> carried
> > >
> > >    out.
> > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_15"
> (output
> > >
> > >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_15) is configured as a
> route-thru.
> > >
> > >    However, since it is driving a MUXF6, such transformation will not be
> carried
> > >
> > >    out.
> > >
> > > And indeed it gives an error and asks me to RELOC or whatever something
> > > that I cannot even locate as it has not mapped anything....
> > >
> > > All this stuff takes too much time.
> > >
> > > And this is highly expanded optimized logic for SPEED.
> > >
> > >
> >


Article: 55559
Subject: Re: OK I am pissed off with Xilinx webpack.
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Mon, 12 May 2003 19:55:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
Theron Hicks <hicksthe@egr.msu.edu> wrote:
: Wei,
:     He said he was using WEBPACK.  You cannot get support from the hotline
: for WEBPACK can you?
: Theron Hicks

But you can enter WebCases and you can ask for help here.

Bye
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 55560
Subject: Re: OK I am pissed off with Xilinx webpack.
From: Ray Andraka <ray@andraka.com>
Date: Mon, 12 May 2003 20:04:27 GMT
Links: << >>  << T >>  << A >>
Take a break, you are spending too much time in front of the computer.
Unfortunately with synthesis, unless you do a structural instantiation, you are
going to get internal nodes that don't map directly to the nodes in your verilog
design, hence the cryptic machine generated names.   Unfortunately there isn't a
whole lot you can do about that, and it isn't unique to webpack.  Webpack (or any
other synthesizer) is going to use your logic description to create logic that
matches what you conveyed in your description (whether it is right or wrong).  If
the synthesis tool is half decent, it will do that mapping while attempting to make
the resulting circuit as efficient as it can given the input you gave it.
Frequently, that means using primitives such as carry chain components, or in your
case the MUXF6 primitives.

Now to your problem, it looks like part of your mux is being optimized to eliminate
a whole 'leg' on the muxF6 or MUXF5 inputs.  The synthesis software is optimizing
that out, but is not putting a buffer in its place.  The implementation software
doesn't know how to change a VCC or Ground into a buffer so you are getting the
error you see.  I think this is indeed a bug.  CHeck the Xilinx answer database,
there may already be an answer in there for it (I've seen this problem before).  If
not, the work around is to put syn_keep or similar attributes on the signals
connecting layers of the mux together to keep the synthesis from optimizing the LUTs
out, or to turn off use of the MUXF5's and 6's.  I'm not sure what the control for
that is in the webpack, but I am sure there is something there somewhere.

The other point I wanted to make is that your design is not a real nice mapping to
an FPGA: your LUT count is about 20 times the flip-flop count, which means you are
probably going to be rather dissappointed with the performance (your average logic
levels is greater than 5)..  As a contrast, our designs usually have a FF count that
is larger than the LUT count by more than 5%.

Jan Panteltje wrote:

> It should:
> Do as it is told.
> Not change things.
> Not give cryptographic messages like:
>  'udc0_uf1_s2_Mrom_dout_inst_mux_f5_48'
>  I can find out what it is perhaps, but it should refer to the verilog code
>  names.
> I do not care if it is driving a 'MUXF6', a F16 or an apple tree.
> It should just do it if I requested it.
> EVEN IF IT DOES NOT WORK OR CAUSES AN EARTHQUAKE
> Else you get in a loop of endless trying.
>
> If I use a hammer and break it on something fine.
> I do NOT want a hammer that warns me and refuses to hit any nail it
> thinks is bend.
> 'I' am the designer.
> And I never asked for a MUXF5 OR a MUXF6.
> This whole thing is just GATES!
>
> Oh, I see, GATES -> Microsoft -> oh, should have known.
> OK, cut that remark, it is unfair, but it shows US acquired Taliban...
> OK cut that too.
> But what has MS brought us? Advertizing on internet.
> NSA backdoor, they know everything.
> I bet they also know good tools to program FPGA.
>
> Design Summary
> --------------
>    Number of errors:      0
>    Number of warnings:   27
>    Number of Slices:              2,350 out of  2,352   99%
>    Number of Slices containing
>       unrelated logic:               37 out of  2,350    1%
>    Total Number Slice Registers:    281 out of  4,704    5%
>       Number used as Flip Flops:                  280
>       Number used as Latches:                       1
>    Total Number 4 input LUTs:     4,183 out of  4,704   88%
>       Number used as LUTs:                      3,761
>       Number used as a route-thru:                422
>    Number of bonded IOBs:             3 out of    140    2%
>    Number of GCLKIOBs:                2 out of      4   50%
> Total equivalent gate count for design:  38,728
> Additional JTAG gate count for IOBs:  240
>
> Table of Contents
> -----------------
> Section 1 - Errors
> Section 2 - Warnings
> Section 3 - Informational
> Section 4 - Removed Logic Summary
> Section 5 - Removed Logic
> Section 6 - IOB Properties
> Section 7 - RPMs
> Section 8 - Guide Report
> Section 9 - Area Group Summary
> Section 10 - Modular Design Summary
>
> Section 1 - Errors
> ------------------
>
> Section 2 - Warnings
> --------------------
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_48" (output
>
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_48) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_49" (output
>
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_49) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_50" (output
>
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_50) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_51" (output
>
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_51) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_52" (output
>
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_52) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_53" (output
>
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_53) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_54" (output
>
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_54) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_55" (output
>
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_55) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_40" (output
>
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_40) can be reduced to a constant
>
>    driver. However, since it is driving a MUXF6, such optimization will not be
>
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_41" (output
>
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_41) can be reduced to a constant
>
>    driver. However, since it is driving a MUXF6, such optimization will not be
>
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_42" (output
>
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_42) can be reduced to a constant
>
>    driver. However, since it is driving a MUXF6, such optimization will not be
>
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_43" (output
>
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_43) can be reduced to a constant
>
>    driver. However, since it is driving a MUXF6, such optimization will not be
>
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_44" (output
>
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_44) can be reduced to a constant
>
>    driver. However, since it is driving a MUXF6, such optimization will not be
>
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_45" (output
>
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_45) can be reduced to a constant
>
>    driver. However, since it is driving a MUXF6, such optimization will not be
>
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_46" (output
>
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_46) can be reduced to a constant
>
>    driver. However, since it is driving a MUXF6, such optimization will not be
>
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_47" (output
>
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_47) can be reduced to a constant
>
>    driver. However, since it is driving a MUXF6, such optimization will not be
>
>    carried out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_8" (output
>
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_8) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_9" (output
>
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_9) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_10" (output
>
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_10) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_11" (output
>
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_11) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_12" (output
>
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_12) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_13" (output
>
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_13) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_14" (output
>
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_14) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_15" (output
>
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_15) is configured as a route-thru.
>
>    However, since it is driving a MUXF6, such transformation will not be carried
>
>    out.
>
> And indeed it gives an error and asks me to RELOC or whatever something
> that I cannot even locate as it has not mapped anything....
>
> All this stuff takes too much time.
>
> And this is highly expanded optimized logic for SPEED.
>
>

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 55561
Subject: Re: OK I am pissed off with Xilinx webpack.
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Mon, 12 May 2003 13:12:26 -0700
Links: << >>  << T >>  << A >>
Chen,

Students are supported thru the University program, where they have
their own "hotline" sponsored by another university.

Austin

Chen Wei Tseng wrote:
> 
> Theron,
> 
> I believe hotline does support customer who uses Webpack. The exception are
> university students. I believe university professors and researchers who uses
> webpack are all supported by the hotline still.
> 
> Regards, Wei
> 
> Theron Hicks wrote:
> 
> > Wei,
> >     He said he was using WEBPACK.  You cannot get support from the hotline
> > for WEBPACK can you?
> > Theron Hicks
> >
> > "Chen Wei Tseng" <chenwei.tseng@xilinx.com> wrote in message
> > news:3EBFDF6C.5503E124@xilinx.com...
> > > Hi Jan,
> > >
> > > You may first want to find out where this net name is coming from. You can
> > track it
> > > in your netlist or your ncd file. If you have edn/edf file for your
> > netlist, it's
> > > easy enough to open it with wordpad or vi to find the net/comp name. With
> > XST, you
> > > can use the RTLviewer function. If not in the netlist, then it's likely a
> > physical
> > > net/comp name that can be tracked with FPGA Editor. Do note that Webpack
> > may not
> > > have FPGA Editor or RTL viewer.
> > >
> > > Such names are usually the results of inferred logic or macro primitves.
> > If you're
> > > having trouble locating the problem, the Xilinx support hotline are
> > equipped with
> > > tools to probe into such problems.
> > >
> > > Best Regard, Wei
> > > Xilinx Applications
> > >
> > > Jan Panteltje wrote:
> > >
> > > > It should:
> > > > Do as it is told.
> > > > Not change things.
> > > > Not give cryptographic messages like:
> > > >  'udc0_uf1_s2_Mrom_dout_inst_mux_f5_48'
> > > >  I can find out what it is perhaps, but it should refer to the verilog
> > code
> > > >  names.
> > > > I do not care if it is driving a 'MUXF6', a F16 or an apple tree.
> > > > It should just do it if I requested it.
> > > > EVEN IF IT DOES NOT WORK OR CAUSES AN EARTHQUAKE
> > > > Else you get in a loop of endless trying.
> > > >
> > > > If I use a hammer and break it on something fine.
> > > > I do NOT want a hammer that warns me and refuses to hit any nail it
> > > > thinks is bend.
> > > > 'I' am the designer.
> > > > And I never asked for a MUXF5 OR a MUXF6.
> > > > This whole thing is just GATES!
> > > >
> > > > Oh, I see, GATES -> Microsoft -> oh, should have known.
> > > > OK, cut that remark, it is unfair, but it shows US acquired Taliban...
> > > > OK cut that too.
> > > > But what has MS brought us? Advertizing on internet.
> > > > NSA backdoor, they know everything.
> > > > I bet they also know good tools to program FPGA.
> > > >
> > > > Design Summary
> > > > --------------
> > > >    Number of errors:      0
> > > >    Number of warnings:   27
> > > >    Number of Slices:              2,350 out of  2,352   99%
> > > >    Number of Slices containing
> > > >       unrelated logic:               37 out of  2,350    1%
> > > >    Total Number Slice Registers:    281 out of  4,704    5%
> > > >       Number used as Flip Flops:                  280
> > > >       Number used as Latches:                       1
> > > >    Total Number 4 input LUTs:     4,183 out of  4,704   88%
> > > >       Number used as LUTs:                      3,761
> > > >       Number used as a route-thru:                422
> > > >    Number of bonded IOBs:             3 out of    140    2%
> > > >    Number of GCLKIOBs:                2 out of      4   50%
> > > > Total equivalent gate count for design:  38,728
> > > > Additional JTAG gate count for IOBs:  240
> > > >
> > > > Table of Contents
> > > > -----------------
> > > > Section 1 - Errors
> > > > Section 2 - Warnings
> > > > Section 3 - Informational
> > > > Section 4 - Removed Logic Summary
> > > > Section 5 - Removed Logic
> > > > Section 6 - IOB Properties
> > > > Section 7 - RPMs
> > > > Section 8 - Guide Report
> > > > Section 9 - Area Group Summary
> > > > Section 10 - Modular Design Summary
> > > >
> > > > Section 1 - Errors
> > > > ------------------
> > > >
> > > > Section 2 - Warnings
> > > > --------------------
> > > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_48"
> > (output
> > > >
> > > >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_48) is configured as a
> > route-thru.
> > > >
> > > >    However, since it is driving a MUXF6, such transformation will not be
> > carried
> > > >
> > > >    out.
> > > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_49"
> > (output
> > > >
> > > >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_49) is configured as a
> > route-thru.
> > > >
> > > >    However, since it is driving a MUXF6, such transformation will not be
> > carried
> > > >
> > > >    out.
> > > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_50"
> > (output
> > > >
> > > >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_50) is configured as a
> > route-thru.
> > > >
> > > >    However, since it is driving a MUXF6, such transformation will not be
> > carried
> > > >
> > > >    out.
> > > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_51"
> > (output
> > > >
> > > >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_51) is configured as a
> > route-thru.
> > > >
> > > >    However, since it is driving a MUXF6, such transformation will not be
> > carried
> > > >
> > > >    out.
> > > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_52"
> > (output
> > > >
> > > >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_52) is configured as a
> > route-thru.
> > > >
> > > >    However, since it is driving a MUXF6, such transformation will not be
> > carried
> > > >
> > > >    out.
> > > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_53"
> > (output
> > > >
> > > >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_53) is configured as a
> > route-thru.
> > > >
> > > >    However, since it is driving a MUXF6, such transformation will not be
> > carried
> > > >
> > > >    out.
> > > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_54"
> > (output
> > > >
> > > >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_54) is configured as a
> > route-thru.
> > > >
> > > >    However, since it is driving a MUXF6, such transformation will not be
> > carried
> > > >
> > > >    out.
> > > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_55"
> > (output
> > > >
> > > >    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_55) is configured as a
> > route-thru.
> > > >
> > > >    However, since it is driving a MUXF6, such transformation will not be
> > carried
> > > >
> > > >    out.
> > > > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_40"
> > (output
> > > >
> > > >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_40) can be reduced to a
> > constant
> > > >
> > > >    driver. However, since it is driving a MUXF6, such optimization will
> > not be
> > > >
> > > >    carried out.
> > > > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_41"
> > (output
> > > >
> > > >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_41) can be reduced to a
> > constant
> > > >
> > > >    driver. However, since it is driving a MUXF6, such optimization will
> > not be
> > > >
> > > >    carried out.
> > > > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_42"
> > (output
> > > >
> > > >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_42) can be reduced to a
> > constant
> > > >
> > > >    driver. However, since it is driving a MUXF6, such optimization will
> > not be
> > > >
> > > >    carried out.
> > > > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_43"
> > (output
> > > >
> > > >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_43) can be reduced to a
> > constant
> > > >
> > > >    driver. However, since it is driving a MUXF6, such optimization will
> > not be
> > > >
> > > >    carried out.
> > > > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_44"
> > (output
> > > >
> > > >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_44) can be reduced to a
> > constant
> > > >
> > > >    driver. However, since it is driving a MUXF6, such optimization will
> > not be
> > > >
> > > >    carried out.
> > > > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_45"
> > (output
> > > >
> > > >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_45) can be reduced to a
> > constant
> > > >
> > > >    driver. However, since it is driving a MUXF6, such optimization will
> > not be
> > > >
> > > >    carried out.
> > > > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_46"
> > (output
> > > >
> > > >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_46) can be reduced to a
> > constant
> > > >
> > > >    driver. However, since it is driving a MUXF6, such optimization will
> > not be
> > > >
> > > >    carried out.
> > > > WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_47"
> > (output
> > > >
> > > >    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_47) can be reduced to a
> > constant
> > > >
> > > >    driver. However, since it is driving a MUXF6, such optimization will
> > not be
> > > >
> > > >    carried out.
> > > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_8"
> > (output
> > > >
> > > >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_8) is configured as a
> > route-thru.
> > > >
> > > >    However, since it is driving a MUXF6, such transformation will not be
> > carried
> > > >
> > > >    out.
> > > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_9"
> > (output
> > > >
> > > >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_9) is configured as a
> > route-thru.
> > > >
> > > >    However, since it is driving a MUXF6, such transformation will not be
> > carried
> > > >
> > > >    out.
> > > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_10"
> > (output
> > > >
> > > >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_10) is configured as a
> > route-thru.
> > > >
> > > >    However, since it is driving a MUXF6, such transformation will not be
> > carried
> > > >
> > > >    out.
> > > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_11"
> > (output
> > > >
> > > >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_11) is configured as a
> > route-thru.
> > > >
> > > >    However, since it is driving a MUXF6, such transformation will not be
> > carried
> > > >
> > > >    out.
> > > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_12"
> > (output
> > > >
> > > >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_12) is configured as a
> > route-thru.
> > > >
> > > >    However, since it is driving a MUXF6, such transformation will not be
> > carried
> > > >
> > > >    out.
> > > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_13"
> > (output
> > > >
> > > >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_13) is configured as a
> > route-thru.
> > > >
> > > >    However, since it is driving a MUXF6, such transformation will not be
> > carried
> > > >
> > > >    out.
> > > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_14"
> > (output
> > > >
> > > >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_14) is configured as a
> > route-thru.
> > > >
> > > >    However, since it is driving a MUXF6, such transformation will not be
> > carried
> > > >
> > > >    out.
> > > > WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_15"
> > (output
> > > >
> > > >    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_15) is configured as a
> > route-thru.
> > > >
> > > >    However, since it is driving a MUXF6, such transformation will not be
> > carried
> > > >
> > > >    out.
> > > >
> > > > And indeed it gives an error and asks me to RELOC or whatever something
> > > > that I cannot even locate as it has not mapped anything....
> > > >
> > > > All this stuff takes too much time.
> > > >
> > > > And this is highly expanded optimized logic for SPEED.
> > > >
> > > >
> > >

Article: 55562
Subject: How do I know of Xilinx connectivity restrictions?
From: "Francisco Rodriguez" <prodrig@disca.upv.es>
Date: Mon, 12 May 2003 22:35:38 +0200
Links: << >>  << T >>  << A >>
Hello all

I'm trying to create some RPMs using VHDL for a virtex-II device.
Trying to pack a carry chain and an unrelated register gives me this
error:

ERROR:Pack:679 - Unable to obey design constraints
(MACRONAME=hset,RLOC=X0Y0)
which require ... (2 FLOPs, 2LUTs, 2 MUXCYs, 2 XORCYs)
Unable to pack the register because of connectivity restrictions.

However, from the fpga editor block window, FLOP inputs (DX and DY) are no
related with the
carry-chain. So it seems it should be possible to pack them together. Am i
right?

Where can i read about those connectivity restrictions?
What can be packed together and what not? Neither the datasheet nor the
software manuals talk about this
(those I have read, of course!).

Best regards
    Francisco
================================================================
Francisco Rodriguez Ballester (prodrig-REMOVEME-@disca.upv.es)
Postal address: Dept. DISCA, EUI - Univ. Politecnica de Valencia
                c/Camino de Vera s/n, E-46022, VALENCIA (SPAIN)
tlf: +(34) 96 387 70 07 ext. 75759   -   fax: +(34) 96 387 75 79
================================================================






Article: 55563
Subject: Re: OK I am pissed off with Xilinx webpack.
From: billh40@aol.com (Bill Hanna)
Date: 12 May 2003 14:14:50 -0700
Links: << >>  << T >>  << A >>
Jan Panteltje <panteltje@yahoo.com> wrote in message news:<b9oab7$lv1$1@reader1.tiscali.nl>...
> It should:
> Do as it is told.
> Not change things.
> Not give cryptographic messages like:
>  'udc0_uf1_s2_Mrom_dout_inst_mux_f5_48'
>  I can find out what it is perhaps, but it should refer to the verilog code
>  names.
> I do not care if it is driving a 'MUXF6', a F16 or an apple tree.
> It should just do it if I requested it.
> EVEN IF IT DOES NOT WORK OR CAUSES AN EARTHQUAKE
> Else you get in a loop of endless trying.
> 
> If I use a hammer and break it on something fine.
> I do NOT want a hammer that warns me and refuses to hit any nail it
> thinks is bend.
> 'I' am the designer.
> And I never asked for a MUXF5 OR a MUXF6.
> This whole thing is just GATES!
> 
> Oh, I see, GATES -> Microsoft -> oh, should have known.
> OK, cut that remark, it is unfair, but it shows US acquired Taliban...
> OK cut that too.
> But what has MS brought us? Advertizing on internet.
> NSA backdoor, they know everything.
> I bet they also know good tools to program FPGA.
> 
> 
> 
> Design Summary
> --------------
>    Number of errors:      0
>    Number of warnings:   27
>    Number of Slices:              2,350 out of  2,352   99%
>    Number of Slices containing
>       unrelated logic:               37 out of  2,350    1%
>    Total Number Slice Registers:    281 out of  4,704    5%
>       Number used as Flip Flops:                  280
>       Number used as Latches:                       1
>    Total Number 4 input LUTs:     4,183 out of  4,704   88%
>       Number used as LUTs:                      3,761
>       Number used as a route-thru:                422
>    Number of bonded IOBs:             3 out of    140    2%
>    Number of GCLKIOBs:                2 out of      4   50%
> Total equivalent gate count for design:  38,728
> Additional JTAG gate count for IOBs:  240
> 
> Table of Contents
> -----------------
> Section 1 - Errors
> Section 2 - Warnings
> Section 3 - Informational
> Section 4 - Removed Logic Summary
> Section 5 - Removed Logic
> Section 6 - IOB Properties
> Section 7 - RPMs
> Section 8 - Guide Report
> Section 9 - Area Group Summary
> Section 10 - Modular Design Summary
> 
> Section 1 - Errors
> ------------------
> 
> Section 2 - Warnings
> --------------------
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_48" (output
> 
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_48) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_49" (output
> 
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_49) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_50" (output
> 
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_50) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_51" (output
> 
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_51) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_52" (output
> 
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_52) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_53" (output
> 
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_53) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_54" (output
> 
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_54) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf1_s2_Mrom_dout_inst_mux_f5_55" (output
> 
>    signal=udc0_uf1_s2_Mrom_dout_inst_mux_f5_55) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_40" (output
> 
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_40) can be reduced to a constant
> 
>    driver. However, since it is driving a MUXF6, such optimization will not be
> 
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_41" (output
> 
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_41) can be reduced to a constant
> 
>    driver. However, since it is driving a MUXF6, such optimization will not be
> 
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_42" (output
> 
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_42) can be reduced to a constant
> 
>    driver. However, since it is driving a MUXF6, such optimization will not be
> 
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_43" (output
> 
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_43) can be reduced to a constant
> 
>    driver. However, since it is driving a MUXF6, such optimization will not be
> 
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_44" (output
> 
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_44) can be reduced to a constant
> 
>    driver. However, since it is driving a MUXF6, such optimization will not be
> 
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_45" (output
> 
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_45) can be reduced to a constant
> 
>    driver. However, since it is driving a MUXF6, such optimization will not be
> 
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_46" (output
> 
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_46) can be reduced to a constant
> 
>    driver. However, since it is driving a MUXF6, such optimization will not be
> 
>    carried out.
> WARNING:MapLib:155 - MUXF5 symbol "udc0_uf1_s3_Mrom_dout_inst_mux_f5_47" (output
> 
>    signal=udc0_uf1_s3_Mrom_dout_inst_mux_f5_47) can be reduced to a constant
> 
>    driver. However, since it is driving a MUXF6, such optimization will not be
> 
>    carried out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_8" (output
> 
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_8) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_9" (output
> 
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_9) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_10" (output
> 
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_10) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_11" (output
> 
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_11) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_12" (output
> 
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_12) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_13" (output
> 
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_13) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_14" (output
> 
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_14) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> WARNING:MapLib:157 - MUXF5 symbol "udc0_uf2_s7_Mrom_dout_inst_mux_f5_15" (output
> 
>    signal=udc0_uf2_s7_Mrom_dout_inst_mux_f5_15) is configured as a route-thru.
> 
>    However, since it is driving a MUXF6, such transformation will not be carried
> 
>    out.
> 
> And indeed it gives an error and asks me to RELOC or whatever something
> that I cannot even locate as it has not mapped anything....
> 
> All this stuff takes too much time.
> 
> And this is highly expanded optimized logic for SPEED.

  First:

       1)You are at the capacity limit for the device.

          Try the next larger device in the family or reduce your
logic to get it to fit , just for debugging purposes.

       2) Try Implement with the TRIM UNUSED LOGIC  property disabled.

       3) Because you are at the limit, try changing the SPEED
optimization to AREA


        None of these metods may help,  but whenever the device is at
its limit in capacity, then strange events occur in the error messages
or packing.

Bill Hanna

Article: 55564
Subject: Re: How do I know of Xilinx connectivity restrictions?
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Mon, 12 May 2003 22:04:15 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <b9p0hs$eoh$1@polaris.cc.upv.es>,
Francisco Rodriguez <prodrig@disca.upv.es> wrote:
>Hello all
>
>I'm trying to create some RPMs using VHDL for a virtex-II device.
>Trying to pack a carry chain and an unrelated register gives me this
>error:
>
>ERROR:Pack:679 - Unable to obey design constraints
>(MACRONAME=hset,RLOC=X0Y0)
>which require ... (2 FLOPs, 2LUTs, 2 MUXCYs, 2 XORCYs)
>Unable to pack the register because of connectivity restrictions.
>
>However, from the fpga editor block window, FLOP inputs (DX and DY) are no
>related with the
>carry-chain. So it seems it should be possible to pack them together. Am i
>right?

Look at the Jbits slice internal diagram, or similar diagram.  I can't
find a copy online at the moment.

THe BX input is also used for external carry in, INCLUDING driving a
gnd or vcc into the carry in.  So for the base of the carry chain,
where you drive in GND, you can't use the flip-flop independantly of
the lut

-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 55565
Subject: Atmel, just another case of bad support?
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 12 May 2003 18:51:01 -0400
Links: << >>  << T >>  << A >>
I was looking at the Atmel ATF150x CPLDs and did not understand the low
power modes.  So I contacted the local FAE for support.  When I started
to ask questions about the low power mode, the FAE told me that these
parts were really just for stealing sockets from Altera.  He said they
never initiate discussing this part until the customer says they are
using the Altera 7000 line.  The way he said it, I took this as a
recommendation to avoid using it.  I guess I should have asked him more
about these chips, but I have talked to this guy before and he will tell
you this sort of stuff as a friendly warning and does not like to get
into details (a little CYA I guess).  So I usually take it seriously.  

In this case, I am not sure I understand the warning.  The parts seem ok
to me, I just don't quite understand how low the power will go unless
you use a "power down" pin, which I don't want to do.  Anyone know much
about this chip line?  Are they ok chips to use?  What is the quiesent
current when being used at a very low frequency, say, < 1 MHz.  I think
part of my confusion is the multiple versions they have; A, AE, AL, AEL,
AS, ASL, ASV, SE, SEL.  Makes it hard to tell which are current and
useful unless you talk to the FAE... opps, tried that didn't I?  

How about the ATF2500 chips?  Funny how the web site continues to refer
to the 2500B, but when you go to the 2500B page, they tell you it is not
recommended for new designs and give you a link to the 2500C.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 55566
Subject: Re: How do I know of Xilinx connectivity restrictions?
From: Ray Andraka <ray@andraka.com>
Date: Mon, 12 May 2003 23:07:21 GMT
Links: << >>  << T >>  << A >>
In theory, yes the registers are mostly independent of the carry chain,
however there are a few quirks, some of which are due to the implementation
tools.
1) The bottom of the carry chain uses the BX input for the carry in.  The
register can't be shared if its input is not from the LUT or XORCY in that
case.
2) The mapper has a habit of putting the F and G or X and Y elements
'upside-down' for instantiated primitives.  In that case, it may not allow the
registers to be put in the same slice.  Normally, we use the carry chain with
registers and this can create routing restriction problems because the
flip-flop is not in the same half-slice as the logic feeding it.  The fix in
that case is to attach bel constraints to force the placement of the flip-flop
and logic in the correct slice half.
3) The S/R, inv and  CE pins of the two flip-flops in the slice have to be
shared.  Synthesis will often break up wide fanout signals (which these tend
to be) with buffered subtrees.  At least with synplify, there is little rhyme
or reason to the partitioning of the buffer tree, so unless you proactively
avoid it you will wind up with some instances where the two flip-flops in a
slice have different signals driving one of these common inputs.  One fix is
to force the construction of the buffered tree using syn-keeps so that signal
names in related registers are kept uniform.

FIrst thing to do would be to look at the FPGA editor for what the PAR tools
did and see if you can legally move the registers into the carry chain slice
with the route solution the automated tools used.  If not, it should become
obvious why.

Francisco Rodriguez wrote:

> Hello all
>
> I'm trying to create some RPMs using VHDL for a virtex-II device.
> Trying to pack a carry chain and an unrelated register gives me this
> error:
>
> ERROR:Pack:679 - Unable to obey design constraints
> (MACRONAME=hset,RLOC=X0Y0)
> which require ... (2 FLOPs, 2LUTs, 2 MUXCYs, 2 XORCYs)
> Unable to pack the register because of connectivity restrictions.
>
> However, from the fpga editor block window, FLOP inputs (DX and DY) are no
> related with the
> carry-chain. So it seems it should be possible to pack them together. Am i
> right?
>
> Where can i read about those connectivity restrictions?
> What can be packed together and what not? Neither the datasheet nor the
> software manuals talk about this
> (those I have read, of course!).
>
> Best regards
>     Francisco
> ================================================================
> Francisco Rodriguez Ballester (prodrig-REMOVEME-@disca.upv.es)
> Postal address: Dept. DISCA, EUI - Univ. Politecnica de Valencia
>                 c/Camino de Vera s/n, E-46022, VALENCIA (SPAIN)
> tlf: +(34) 96 387 70 07 ext. 75759   -   fax: +(34) 96 387 75 79
> ================================================================

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 55567
Subject: GSR
From: "Maciej" <netscape.net(@)maciusk>
Date: Mon, 12 May 2003 23:13:40 GMT
Links: << >>  << T >>  << A >>
I'm looking for some clarification as to the operation of GSR in Spartan
IIE.
I have the GSR tied to an internal signal, this signal can accessed by a bus
connected to a DSP.
Will this create any problems?
From what I understand about GSR, when the FPGA comes out of reset (GSR)
resets all the 'flops' and goes low.
My internal signal should not interfere with the operation of the GSR. (the
signal is a register in FPGA is not accessed during power up/reset)
Is my understanding correct?
Thank you
Maciej



Article: 55568
Subject: Re: QuartusII issue
From: "pc" <acosmos@freemail.gr>
Date: Tue, 13 May 2003 01:44:02 +0200
Links: << >>  << T >>  << A >>
Thanks for your reply but my license has only one "FEATURE quartus_lite
alterad ..." statement with the specific HOSTID.
It is recognized by Quartus only if i change the HOSTID to zero (HostID =
0 ). But then the software is useless. :(



Article: 55569
Subject: VitalGlitch
From: tatto0_2000@yahoo.com (Wong)
Date: 12 May 2003 17:04:44 -0700
Links: << >>  << T >>  << A >>
Hi,
  Everything is fine with my functional simulation of a state machine
using ModelSim. But once I go for Post-Layout Simulation, ModelSim
shows me the following warnings:

# ** Warning: VitalGlitch: GLITCH Detected on port Y ; Preempted
Future Value := 1 @ 200152.541 ns; Newly Scheduled Value := 0 @
200153.004 ns;
#    Time: 200152317 ps  Iteration: 0  Instance:
/mooredemo_tb/moore_pm/current_state_h/current_state_ns_0_and2_0
 ..
 ..
 ..

Generally, I would need someone to give me some pointers:
1. What is Preempted Future Value and Newly Scheduled Value ?
2. How these glitches can be removed ? Of course, I am not talking
about switching off the glitch-detect option in ModelSim.

Thanks.

Article: 55570
Subject: Re: Atmel, just another case of bad support?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 13 May 2003 14:45:42 +1200
Links: << >>  << T >>  << A >>
rickman wrote:
> 
> I was looking at the Atmel ATF150x CPLDs and did not understand the low
> power modes.  So I contacted the local FAE for support.  When I started
> to ask questions about the low power mode, the FAE told me that these
> parts were really just for stealing sockets from Altera.  He said they
> never initiate discussing this part until the customer says they are
> using the Altera 7000 line.  The way he said it, I took this as a
> recommendation to avoid using it.  I guess I should have asked him more
> about these chips, but I have talked to this guy before and he will tell
> you this sort of stuff as a friendly warning and does not like to get
> into details (a little CYA I guess).  So I usually take it seriously.
> 
> In this case, I am not sure I understand the warning.  The parts seem ok
> to me, I just don't quite understand how low the power will go unless
> you use a "power down" pin, which I don't want to do. 

Pin wakeup (ITD in Atmel parlance) can give very low static Iccs, of
some uA. eg ATF1508ASVL curve in the data shows 2uA at 3.3V

I've never used the dedicated pin-power down, but for some strange
reason,
their curves show it higher than the ITD power down.

> Anyone know much about this chip line?  

Yes :)

> Are they ok chips to use?  

Yes. We use ATF1502/04/08, and the older ATF1500 and ATV2500B

> What is the quiesent current when being used at a very low frequency, say, < 1 MHz. 

Go to the Graphs in the data sheets.
There are two graphs to use
a) The Icc/Vcc F=0 / 25'C  graph shows static icc, after reset.
 typically Vcc dependant, and of some uA levels.

 We have found there is also a node-state dependance on static Icc,
their
data sheet is for Power-ON, all LOW.

b) The Icc vs MHz curves
Below a knee freq, you can work out a mA/MHz rating, and use that to
extrapolate Icc towards DC.

Above the Knee freq, the wake-up monostable is always on, and the 
slower L spec 'morphs' into the next speed grade device.

> I think part of my confusion is the multiple versions they have; A, AE, AL, AEL,
> AS, ASL, ASV, SE, SEL.  

For low power you want ASL (5v) and ASVL (3.3V) - the 'L' is the key
tag.

AE and SE are still 'comming', so don't get distracted by them - they
are
basically a shrink.


> Makes it hard to tell which are current and
> useful unless you talk to the FAE... opps, tried that didn't I?

 Forward this to the FAE :)
 
> How about the ATF2500 chips?  Funny how the web site continues to refer
> to the 2500B, but when you go to the 2500B page, they tell you it is not
> recommended for new designs and give you a link to the 2500C.

 ATV2500B is an OTP device (remember those ?) and ATF2500C is the flash
replacement. 
 The 2500C is relatively new, and they still make 2500Bs, but want those
designs to migrate to the 2500C.

 I'd call the ATF2500C a niche device, LOTS of cross-points,
so if you need that, it's great. Otherwise, use the ATF1502/04/08, 
which are ISP devices.

 The Atmel PLDs are good for covering 5V/3V/Single Rail, which the 
other vendors have somewhat left behind. 

 Their static Icc is the best of anyone, but their mA/MHz is not leading
edge.

 They do have good logic coverage, and with floor-planning  you can get
more into their devices. eg a Design that fits in a 64 macrocell
ATF1504,
has to bump to XC2128 (60-70% full) when design moves to Coolrunner.

  - jg

Article: 55571
Subject: Re: QuartusII issue
From: "Subroto Datta" <sdatta@altera.com>
Date: Tue, 13 May 2003 02:55:15 GMT
Links: << >>  << T >>  << A >>
Did you try using Altera's online support available at

https://mysupport.altera.com/eservice/start.swe?SWECmd=Login

- Subroto Datta
Altera Corp.

"pc" <acosmos@freemail.gr> wrote in message
news:b9p83o$goh$1@usenet.otenet.gr...
> Thanks for your reply but my license has only one "FEATURE quartus_lite
> alterad ..." statement with the specific HOSTID.
> It is recognized by Quartus only if i change the HOSTID to zero (HostID =
> 0 ). But then the software is useless. :(
>
>



Article: 55572
Subject: Xilinx ISE Student Edition
From: "Kyle Davis" <kyledavis@nowhere.com>
Date: Tue, 13 May 2003 03:22:56 GMT
Links: << >>  << T >>  << A >>
What is the different between Xilinx ISE Student Edition 4.2i and Xilinx ISE
BaseX 4.2i? They look the same to me. It looks to me that they have the same
device support and both of them can use the same service pack.
Thanks!



Article: 55573
Subject: Re: Exploting the DDR input registers in Virtex2
From: mrand@my-deja.com (Marc Randolph)
Date: 12 May 2003 21:01:09 -0700
Links: << >>  << T >>  << A >>
"Avrum" <avrum@REMOVEsympatico.ca> wrote in message news:<XzRva.2205$mK2.183157@news20.bellglobal.com>...
> What do you want to do with the DDR flops. These are not general purpose
> flops that can be used in place of a core flop; they are specifically there
> to clock the data on the input pin - the D input of both INFF flops in an
> IOB can ONLY be connected to the input receiver of the IOB.
> 

Howdy Avrum,

   I don't believe this is correct.  Certainly, there are some
restrictions, but investigate the "use Bonded I/Os" option on the par
(Place & Route) program.

In fact (I just discovered), it appears you can even use the registers
in UNbonded IOB's!  Learn something new everyday... see

http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=12209

for details (if the link wraps, click here instead:
http://tinyurl.com/bmb4 ).

Have fun,

   Marc

Article: 55574
Subject: Re: Atmel, just another case of bad support?
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 13 May 2003 00:07:13 -0400
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> 
> rickman wrote:
> >
> > I was looking at the Atmel ATF150x CPLDs and did not understand the low
> > power modes.  So I contacted the local FAE for support.  When I started
> > to ask questions about the low power mode, the FAE told me that these
> > parts were really just for stealing sockets from Altera.  He said they
> > never initiate discussing this part until the customer says they are
> > using the Altera 7000 line.  The way he said it, I took this as a
> > recommendation to avoid using it.  I guess I should have asked him more
> > about these chips, but I have talked to this guy before and he will tell
> > you this sort of stuff as a friendly warning and does not like to get
> > into details (a little CYA I guess).  So I usually take it seriously.
> >
> > In this case, I am not sure I understand the warning.  The parts seem ok
> > to me, I just don't quite understand how low the power will go unless
> > you use a "power down" pin, which I don't want to do.
> 
> Pin wakeup (ITD in Atmel parlance) can give very low static Iccs, of
> some uA. eg ATF1508ASVL curve in the data shows 2uA at 3.3V
> 
> I've never used the dedicated pin-power down, but for some strange
> reason,
> their curves show it higher than the ITD power down.

This is the sort of stuff I did not understand from reading their data
sheet.  It seems there are about fifty different factors to consider
when estimating power.  There is the power down pin, the self-monitored
low power mode (is that the ITD you refer to?), the mode of the
macrocells and other things.  

I am looking for the short answer considering that I don't need speed
out of this device, just low power.  

I also could not figure out if they make a 1516 yet or not.  So I guess
not...


> > Anyone know much about this chip line?
> 
> Yes :)
> 
> > Are they ok chips to use?
> 
> Yes. We use ATF1502/04/08, and the older ATF1500 and ATV2500B
> 
> > What is the quiesent current when being used at a very low frequency, say, < 1 MHz.
> 
> Go to the Graphs in the data sheets.
> There are two graphs to use
> a) The Icc/Vcc F=0 / 25'C  graph shows static icc, after reset.
>  typically Vcc dependant, and of some uA levels.
> 
>  We have found there is also a node-state dependance on static Icc,
> their
> data sheet is for Power-ON, all LOW.
> 
> b) The Icc vs MHz curves
> Below a knee freq, you can work out a mA/MHz rating, and use that to
> extrapolate Icc towards DC.
> 
> Above the Knee freq, the wake-up monostable is always on, and the
> slower L spec 'morphs' into the next speed grade device.

As I said, there seem to be too many modes and features for me to know
under what conditions the graphs apply.   That was when I called the FAE
and it seemed like he was telling me it was best not to use these
parts.  He literally told me that they *only* sell these chips to grab
sockets away from Altera.  I thought that was very weird at the time
since I don't see how that alone prevented the chips from being good in
a new design.  I figured that there was something he wasn't telling me
like maybe you get raped on the price unless you have an Altera price
for them to beat or something.  


> > I think part of my confusion is the multiple versions they have; A, AE, AL, AEL,
> > AS, ASL, ASV, SE, SEL.
> 
> For low power you want ASL (5v) and ASVL (3.3V) - the 'L' is the key
> tag.

What about the AL or AEL?  


> AE and SE are still 'comming', so don't get distracted by them - they
> are
> basically a shrink.

When you say "coming", any idea of when?  


> > Makes it hard to tell which are current and
> > useful unless you talk to the FAE... opps, tried that didn't I?
> 
>  Forward this to the FAE :)

I'm staying away from that FAE for awhile.  I figure either there is
something strange or maybe he just doesn't want to support a smallish
volume user (even if I have plans to be a high volume user :).  


>  I'd call the ATF2500C a niche device, LOTS of cross-points,
> so if you need that, it's great. Otherwise, use the ATF1502/04/08,
> which are ISP devices.
> 
>  The Atmel PLDs are good for covering 5V/3V/Single Rail, which the
> other vendors have somewhat left behind.
> 
>  Their static Icc is the best of anyone, but their mA/MHz is not leading
> edge.
> 
>  They do have good logic coverage, and with floor-planning  you can get
> more into their devices. eg a Design that fits in a 64 macrocell
> ATF1504,
> has to bump to XC2128 (60-70% full) when design moves to Coolrunner.

The 32/64 cell socket may be going away since I got the price from
Lattice that I wanted.  By using the larger Lattice part in place of the
Xilinx XCR3256XL part I was considering, I get extra cells and IOs.  So
I may not need the smaller part on the board.  But I would still like to
learn about these devices.  

BTW, Xilinx is pretty ridiculous on price for the XCR3384XL part while I
got the right price on the Lattice LC4384B part I needed.  I guess
Xilinx doesn't think the Lattice parts are "competition".  

Maybe I need to rethink the SpartanIIE part as well...  ;)

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX



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