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
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
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
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
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
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
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: 55556Thanks 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
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: 55558Theron, 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
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
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: 55561Chen, 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
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
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: 55564In 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.eduArticle: 55565
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 FAXArticle: 55566
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: 55567I'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 MaciejArticle: 55568
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
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
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. - jgArticle: 55571
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
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
"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: 55574
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:
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