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

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 55575

Article: 55575
Subject: Re: OK I am pissed off with Xilinx webpack.
From: Ken McElvain <ken@synplicity.com>
Date: Tue, 13 May 2003 04:24:11 GMT
Links: << >>  << T >>  << A >>
You could always pay for a synthesis tool ...
We usually see quite large area savings over the "free" tools
which would certainly help with your design.  I put quotes
around "free" because blowing out of a part or speed grade
can be very expensive.

Ken McElvain
Synplicity, Inc

Bill Hanna wrote:

> 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: 55576
Subject: Re: MJL Stratix Dev Kit
From: H. Peter Anvin <hpa@zytor.com>
Date: 12 May 2003 22:47:26 -0700
Links: << >>  << T >>  << A >>
Followup to:  <6ed146ef.0305091923.5d70181d@posting.google.com>
By author:    azafar@iupui.edu (Atif Zafar)
In newsgroup: comp.arch.fpga
>
> Does anyone know prices for a "loaded" MJL Stratix board (32 MB
> SDRAM+16 MB FLASH) and is it shipping now? I have emailed the MJL
> sales guys but no one responded. Thanks.
> 

$595 (until end of June) and it's shipping.  Expect 2-3 week delivery
time to the U.S. though.  I bugged them a few times last week and now
their online ordering web page is back up.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Article: 55577
Subject: Re: Atmel, just another case of bad support?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 13 May 2003 19:13:56 +1200
Links: << >>  << T >>  << A >>
rickman wrote:
> 
> 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.

 Not quite fifty, you can expect to have to factor in a few variables
such as Vcc/Freq and Macrocell mode, but using those I find pretty
simple.
 And as always, estimate, then verify with measurement in 
your application.
 
> 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.

No, I think he was just used to 'that sand pit'. The Atmel devices
are technically better than Altera, and we use them on their merits.
Some in sales do not appreciate that, and find it easier to 'socket
chase'

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

I don't find those part numbers in the ATF1504 data sheet ? 

All that's legal numbering are ATF1504AS and ATF1504ASL, with V option
for 3.3V.

There is a ATF1500AL, but that's another, (older) 32MC device.
More connectivity, static Icc of low mA, not low uA, so is a generation
behind the Icc learning.

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

They are not even sampling yet, so just keep them on the 'distant'
radar.

-jg

Article: 55578
Subject: Re: OK I am pissed off with Xilinx webpack.
From: "Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com>
Date: Tue, 13 May 2003 20:40:57 +1200
Links: << >>  << T >>  << A >>
"Ken McElvain" <ken@synplicity.com> wrote in message
news:3EC07363.5040802@synplicity.com...
> You could always pay for a synthesis tool ...
> We usually see quite large area savings over the "free" tools
> which would certainly help with your design.  I put quotes
> around "free" because blowing out of a part or speed grade
> can be very expensive.
>
> Ken McElvain
> Synplicity, Inc

Perhaps Synplicity could do a web tool where you upload your files and it
tells you the outcome of synthesis in terms of area and timings.

Ralph



Article: 55579
Subject: Ramb16_s18_s18
From: Toby <to_be_ass@hotmail.com>
Date: Tue, 13 May 2003 04:01:59 -0700
Links: << >>  << T >>  << A >>
I am now creating a FFT application there I use a Ram(Ramb16_s18_s18) in libray connected to the FFT(vfft32v2) in library. The problem is how a good instantion is creating in the right
way. 

how many numbers horizontal? 
or columbs? 

x"0000000....64nr.....00000"; 
       . 
       . 
I'm using (0 to 15) vector to the application. 

Please help me? 


Article: 55580
Subject: Altera SignalTap and Incremental Route
From: petersommerfeld@hotmail.com (Peter Sommerfeld)
Date: 13 May 2003 05:06:33 -0700
Links: << >>  << T >>  << A >>
I am having trouble using the incremental route feature of SignalTap.
Any time I enable incremental route for even just one signal in my
SignalTap list, the Quartus fitter refuses to fit the design.

Any ideas?

Article: 55581
Subject: Re: Exploting the DDR input registers in Virtex2
From: "Avrum" <avrum@REMOVEsympatico.ca>
Date: Tue, 13 May 2003 09:16:26 -0400
Links: << >>  << T >>  << A >>
Marc,

It seems that you are right - the tools have some ability to use otherwise
unused IOBs (bonded or unbonded) as resources.

However, the answer to the original question is the same - if the IOB is
used as an input (in the original posting it was used by the PCI-X core),
the other INFF flop is only useable for clocking in data from the pin - the
D inputs of the two INFF flops are hard wired together.

Avrum


"Marc Randolph" <mrand@my-deja.com> wrote in message
news:15881dde.0305122001.1f5946e9@posting.google.com...
> "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: 55582
Subject: CLK_SIGNAL CONSTRAINT
From: Jimmy <jimmyjonsson_79@hotmail.com>
Date: Tue, 13 May 2003 06:41:13 -0700
Links: << >>  << T >>  << A >>
Hi! 
I get a message from the XST: 
(*) These 13 clock signal(s) are generated by combinatorial logic, 
and XST is not able to identify which are the primary clock signals. 
Please use the CLOCK_SIGNAL constraint to specify the clock signal(s) generated by combinatorial logic. 

I have tried with the following attribute: 

attribute clock_signal : string; 
attribute clock_signal of clk : signal is "yes"; 

in the architecture but it does not work.How will I get rid of the gates?????? 




Article: 55583
(removed)


Article: 55584
Subject: Re: OK I am pissed off with Xilinx webpack.
From: Ken McElvain <ken@synplicity.com>
Date: Tue, 13 May 2003 16:31:30 GMT
Links: << >>  << T >>  << A >>
A web evaluation tool is possible, but there is already a
downloadable full evaluation version.   The basic procedure is to
go to our web site, download Synplify and install
it.  When you run it the first time it will help you
request a license by email.   The license will most
likely come the same or next day.  I think the evaluation
license generally lasts for 20 days and is a full license
for Synplify Pro.  It would be hard to see the value of parts
of the tool like HDL Analyst over the web.

Ken McElvain
Synplicity, Inc.

Ralph Mason wrote:

> "Ken McElvain" <ken@synplicity.com> wrote in message
> news:3EC07363.5040802@synplicity.com...
> 
>>You could always pay for a synthesis tool ...
>>We usually see quite large area savings over the "free" tools
>>which would certainly help with your design.  I put quotes
>>around "free" because blowing out of a part or speed grade
>>can be very expensive.
>>
>>Ken McElvain
>>Synplicity, Inc
>>
> 
> Perhaps Synplicity could do a web tool where you upload your files and it
> tells you the outcome of synthesis in terms of area and timings.
> 
> Ralph
> 
> 
> 


Article: 55585
Subject: Spartan 3 Power requirements
From: "Rick HORMIGO" <rhormigo@removethisspamprot.pesa.com>
Date: Tue, 13 May 2003 11:34:07 -0500
Links: << >>  << T >>  << A >>
Does somebody have an idea of power requirements for SP3. I am
designing an evaluation board for the 3S1000 and the data sheet
doesn't give data for Quiescent DC currents. Can you say what minimum
current requirements this have. I assume that everybody still has the
J version "optimized" for lab use ;-)

Thanks,

Rick.





Article: 55586
Subject: Re: Spartan 3 Power requirements
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Tue, 13 May 2003 10:10:33 -0700
Links: << >>  << T >>  << A >>
Rick,

Since the DC leakage component in 90 nm is higher, but the dynamic
currents are lower, the actual power is still being evaluated so we can
publish power estimating tools.

I would use the Virtex II Pro estimator, without the MGTs or PPC as a
WORST CASE estimate.  The 2VP7 is about the same CLB count as a 3S1000.

The Vccaux is 2.5 volts (same as the 2VP7) and powers the same
structures as in Pro, and the Vcco for the IO banks is going to be
predicted accurately, as the IOBs have not changed for a particular IO
standard.

Only the Vccint current will be over-estimated by the Pro estimator. 
The Spartan 3 has a much smaller CLB, and operates at a lower voltage
1.2v, so the dynamic power is expected to be less than that of Pro which
is at 1.5V.  Since the static current is larger, the estimate may be
pretty good.

Austin



Rick HORMIGO wrote:
> 
> Does somebody have an idea of power requirements for SP3. I am
> designing an evaluation board for the 3S1000 and the data sheet
> doesn't give data for Quiescent DC currents. Can you say what minimum
> current requirements this have. I assume that everybody still has the
> J version "optimized" for lab use ;-)
> 
> Thanks,
> 
> Rick.

Article: 55587
Subject: Re: CLK_SIGNAL CONSTRAINT
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Tue, 13 May 2003 10:17:51 -0700
Links: << >>  << T >>  << A >>
Jimmy wrote:
> Hi!
> I get a message from the XST:
> (*) These 13 clock signal(s) are generated by combinatorial logic,
> and XST is not able to identify which are the primary clock signals.
> Please use the CLOCK_SIGNAL constraint to specify the clock signal(s) 
> generated by combinatorial logic.


Your compiler is wise.

Consider connecting one global constant clock signal
to all of the registers and use the clock_enable
inputs to get the derived signals that you need.

If you are using an hdl, this advice translates to:
"Use the standard synchronous process format"

    -- Mike Treseler


Article: 55588
Subject: Re: OK I am pissed off with Xilinx webpack.
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Tue, 13 May 2003 11:03:24 -0700
Links: << >>  << T >>  << A >>
Ken McElvain wrote:
> A web evaluation tool is possible, but there is already a
> downloadable full evaluation version.

I think you are missing Ralph's point.
The designer would like to quickly know
if buying tool M or S would make *this* file set
fit in *this* device.

Loading a new tool and getting it licensed and
running burns a day or two or three
that might instead be used to solve the problem another way.

If the designer could offload files and a t_clk constraint
to a secure web sever and get an answer back the same
day, the designer would be very impressed and perhaps very
inclined to buy the new tool.

 >  It would be hard to see the value of parts
> of the tool like HDL Analyst over the web.

True, but if the webserver tells me,
"Yes, it fits, and passes timing for average routes"
I'm already 95% sold.

If it tells me "Missed by 10ns on ten paths"
I'm still intrigued. You've got a new contact at least.


  -- Mike Treseler



Article: 55589
Subject: Re: VitalGlitch
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Tue, 13 May 2003 11:44:52 -0700
Links: << >>  << T >>  << A >>


Wong wrote:

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

> How these glitches can be removed ? 

They may not have to be removed if it is an internal node
of a synchronous design.
If it is a device pin, you may need an output register.

In a synchronous design, glitches on internal combinational
nodes that do not cause a setup violation at the next
register are tolerable. For example, I might make a glitchy
ripple counter driving an output register. Glitches
on the D side would be expected, but not on the Q side.

> Of course, I am not talking
> about switching off the glitch-detect option in ModelSim.

It probably makes sense to do just that for expected glitches.

      -- Mike Treseler


Article: 55590
Subject: Re: OK I am pissed off with Xilinx webpack.
From: Ken McElvain <ken@synplicity.com>
Date: Tue, 13 May 2003 18:51:39 GMT
Links: << >>  << T >>  << A >>


Mike Treseler wrote:

> Ken McElvain wrote:
> 
>> A web evaluation tool is possible, but there is already a
>> downloadable full evaluation version.
> 
> 
> I think you are missing Ralph's point.


Actually, I didn't miss it, I forwarded it to our
marketing group - we will look into it.   I just wanted
to point out that there is already a pretty easy method
to do an evaluation that would serve Ralph today.  If it
takes a day to get the evaluation copy up and running on a
normal PC (aside from waiting for the license to arrive) then
we have goofed something up and I would like to hear
about it.


> The designer would like to quickly know
> if buying tool M or S would make *this* file set
> fit in *this* device.
> 
> Loading a new tool and getting it licensed and
> running burns a day or two or three
> that might instead be used to solve the problem another way.
> 
> If the designer could offload files and a t_clk constraint
> to a secure web sever and get an answer back the same
> day, the designer would be very impressed and perhaps very
> inclined to buy the new tool.
> 
>  >  It would be hard to see the value of parts
> 
>> of the tool like HDL Analyst over the web.
> 
> 
> True, but if the webserver tells me,
> "Yes, it fits, and passes timing for average routes"
> I'm already 95% sold.
> 
> If it tells me "Missed by 10ns on ten paths"
> I'm still intrigued. You've got a new contact at least.
> 
> 
>  -- Mike Treseler
> 
> 


Article: 55591
Subject: Re: How do I know of Xilinx connectivity restrictions?
From: "Francisco Rodriguez" <prodrig@disca.upv.es>
Date: Tue, 13 May 2003 21:07:32 +0200
Links: << >>  << T >>  << A >>
Thank you both for your comments.

Once the bottom of the carry chain is excluded from register packing
everything works fine.
And yes, I didn't realize but the BEL attribute is needed to correctly order
the register bits.

Best regards
    Francisco

"Ray Andraka" <ray@andraka.com> escribió en el mensaje
news:3EC02A0B.E1B98630@andraka.com...
> 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: 55592
Subject: Re: Spartan 3 Power requirements
From: "Rick HORMIGO" <rhormigo@removethisspamprot.pesa.com>
Date: Tue, 13 May 2003 14:45:51 -0500
Links: << >>  << T >>  << A >>
Thanks, that was fast!

"Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message
news:3EC12709.EA0B6081@xilinx.com...
> Rick,
>
> Since the DC leakage component in 90 nm is higher, but the dynamic
> currents are lower, the actual power is still being evaluated so we
can
> publish power estimating tools.
>
> I would use the Virtex II Pro estimator, without the MGTs or PPC as
a
> WORST CASE estimate.  The 2VP7 is about the same CLB count as a
3S1000.
>
> The Vccaux is 2.5 volts (same as the 2VP7) and powers the same
> structures as in Pro, and the Vcco for the IO banks is going to be
> predicted accurately, as the IOBs have not changed for a particular
IO
> standard.
>
> Only the Vccint current will be over-estimated by the Pro estimator.
> The Spartan 3 has a much smaller CLB, and operates at a lower
voltage
> 1.2v, so the dynamic power is expected to be less than that of Pro
which
> is at 1.5V.  Since the static current is larger, the estimate may be
> pretty good.
>
> Austin
>
>
>
> Rick HORMIGO wrote:
> >
> > Does somebody have an idea of power requirements for SP3. I am
> > designing an evaluation board for the 3S1000 and the data sheet
> > doesn't give data for Quiescent DC currents. Can you say what
minimum
> > current requirements this have. I assume that everybody still has
the
> > J version "optimized" for lab use ;-)
> >
> > Thanks,
> >
> > Rick.



Article: 55593
Subject: Problems with Leonardo Spectrum
From: eduwenzel@yahoo.com.br (=?ISO-8859-1?Q?Eduardo_Wenzel_Bri=E3o?=)
Date: 13 May 2003 13:11:59 -0700
Links: << >>  << T >>  << A >>
Hi

I am using Leonardo Spectrum tool to create EDIF files to my project.
But I want to performed this tool in command line ($:/spectrum
file.tcl )

However, when I perform spectrum tool, just some line into file.tcl
are executed.
By example, I have these commands inside of file.tcl:

1.set part xc2v1000fg456-4
2.load_library xc2v
3.load top.vhd
4. blackbox Reconfigurable_Module
...

Spectrum tool just performed until third line. "Blackbox" command and
ALL the lines below this command  aren´t executed by Leonardo in
command line. Just in GUI tool, all lines are executed perfectly. It
seems that the tool stop its execution when a command issues warnings
in line command. What Can I do to perform all the lines inside of a
TCL file in command line without any break of execution?

Eduardo Wenzel Brião
briao@inf.pucrs.br

Catholic University of Rio Grande do Sul state - PUCRS
Porto Alegre city
Brazil

Article: 55594
Subject: XC9536 - how to make my own programing device for this chip ?
From: "Gorgo" <chudzielec21@wp.pl>
Date: Tue, 13 May 2003 22:39:57 +0200
Links: << >>  << T >>  << A >>
Hey

I'm looking for some projects how to make  my own device for programing
XC9536!

Does anybody know some places in web where I can find something like that !

I apprecaite all help !

thanks

Gorgo



Article: 55595
Subject: Re: Problems with Leonardo Spectrum
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Tue, 13 May 2003 14:03:22 -0700
Links: << >>  << T >>  << A >>


Eduardo Wenzel Brião wrote:

> 1.set part xc2v1000fg456-4
> 2.load_library xc2v
> 3.load top.vhd
> 4. blackbox Reconfigurable_Module
> ...
> 
> Spectrum tool just performed until third line. "Blackbox" command and
> ALL the lines below this command  aren´t executed by Leonardo in
> command line. Just in GUI tool, all lines are executed perfectly. It
> seems that the tool stop its execution when a command issues warnings
> in line command. What Can I do to perform all the lines inside of a
> TCL file in command line without any break of execution?

Read the log file. Maybe it's an error rather than
a warning in the command line case.

If Reconfigurable_Module is an unbound component instance in your
code, the blackbox comamnd should not be needed.
Try taking it out.

  --Mike Treseler


Article: 55596
Subject: Re: OK I am pissed off with Xilinx webpack.
From: Jan Panteltje <panteltje@yahoo.com>
Date: Tue, 13 May 2003 21:39:08 GMT
Links: << >>  << T >>  << A >>
On a sunny day (Mon, 12 May 2003 20:04:27 GMT) it happened Ray Andraka
<ray@andraka.com> wrote in <3EBFFF2D.9899D504@andraka.com>:

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

OK Ray, yes I am spending many hours in front of the monitor.
But let's get things strait here, I just rebooted in Linux from the windows
webpack re-wrote that design to bring some function back into the 'offending'
part.
That resulted in now 2 of the 16 units (they are all the same) getting a
similar report.
Since they are all the same I concluded that perhaps the design was to full
up for webpack, and removed some logic (my serial routines) to see if the
error would disappear.
It did, but now you get 'programming error' in Impact without a reason WHY.
(No its not hardware, the other stuff gives no programming error).
So now I will be quite honest, and maybe Xilinx reads this too:
My FIRST impression of Xilinx webpack was: total crap.
Once I had a ZX81 (Sinclair) and a 'silversoft compiler' (some sort of basic
compiler on tape), and it was JUST like webpack: slow, only some instructions
works in some configuration, peculiar errors, never managed to make a working
program with that.

The FPGA without the right soft is useless.
In stead of focusing on 10 GB links maybe it would be a lot wiser to focus
on high quality soft.
So people can actually use this stuff.
Else I can only see webpack as an act of terrorism, and maybe I can get some
European  company to make FPGA so at least in the WW3 you guys provoke with
it we will win because of better soft if not for better other reasons.
Yes, I am sitting here now with the sandwiches with French Cheese and I am in
a free country and can say this.
When you look at good soft, like for example gcc, well, the guy who wrote
webpack needs to do some study.
Although some people (like that head -banging guy) CANNOT seem to understand
how to program, for example Stroussup and C++. 
I wrote many a program, and many for the open source.
I am not the greatest programmer, but at least it does what it needs to do.
No I never had that problem of 'do what I want it to do', because I can write
whatever I can think of and it will work.
So I am canceling some FPGA projects now until there is sane software, lets
say you are 20 years behind the state of the art with webpack.
Now for my sandwiches.
Regards
Jan

Article: 55597
Subject: Re: XC9536 - how to make my own programing device for this chip ?
From: Bertram Geiger <bgeiger@aon.at>
Date: Tue, 13 May 2003 23:44:22 +0200
Links: << >>  << T >>  << A >>
Gorgo schrieb:
> Hey
> 
> I'm looking for some projects how to make  my own device for programing
> XC9536!
> 
> Does anybody know some places in web where I can find something like that !
> 
> I apprecaite all help !
> 
> thanks
> 
> Gorgo
> 
> 

XILINX !

-- 
Bertram Geiger <bgeiger@aon.at>
HTL-Bulme Graz, Austria


Article: 55598
Subject: Spartan3 DLL?
From: Michael Bills <mbbillsREMOVE_THIS@raytheon.com>
Date: Tue, 13 May 2003 14:48:15 -0700
Links: << >>  << T >>  << A >>
Does anyone know if the 50K gate Spartan3 has a DLL since it doesn't 
have a DCM?

TIA,
Michael Bills


Article: 55599
Subject: Re: XC9536 - how to make my own programing device for this chip ?
From: ben@ben.com (Ben Jackson)
Date: Tue, 13 May 2003 22:05:16 GMT
Links: << >>  << T >>  << A >>
In article <b9rl6t$n$1@korweta.task.gda.pl>, Gorgo <chudzielec21@wp.pl> wrote:
>
>I'm looking for some projects how to make  my own device for programing
>XC9536!

Google for "Parallel Cable III" (with quotes) and you'll find a lot of
info.  I built one to their specs but I haven't built a proto board for
the XC9536 to try it yet.

-- 
Ben Jackson
<ben@ben.com>
http://www.ben.com/



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

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