Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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-64Article: 55577
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. -jgArticle: 55578
"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. RalphArticle: 55579
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: 55580I 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
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, > > MarcArticle: 55582
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
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
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
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
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: 55588Ken 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 TreselerArticle: 55589
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: 55590Mike 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
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: 55592Thanks, 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
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 BrazilArticle: 55594
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 GorgoArticle: 55595
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 TreselerArticle: 55596
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 JanArticle: 55597
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, AustriaArticle: 55598
Does anyone know if the 50K gate Spartan3 has a DLL since it doesn't have a DCM? TIA, Michael BillsArticle: 55599
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:
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