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
Andy Peters wrote: > On Apr 3, 3:10 am, Antti <Antti.Luk...@googlemail.com> wrote: > >> PS, I was thinking that 10.1 is not suggested for ML505, but when i >> just NOW opened the ml505 support PDFs they list ISE 10.1 and EDK 10.1 >> >> Xilinx, if you say ML505 is to be used with EDK 10.1 then PLEASE fix >> the revup or make the 10.1 version of EDK ref design available! >> >> I dont want spend weeks to troubleshoot why xilinx ML505 ref design >> doesnt work with EDK 10.1 > > FWIW, our Avnet FAE told us that the 10.1 EDK was exactly the same as > the 9.2 EDK. It was given a rev bump so that Xilinx wouldn't get the > usual howls about the EDK shipping months after the ISE tools. > This is absolutely not true. EDK 10.1 is not equal to EDK 9.2. EdArticle: 130901
ni wrote:
> On Apr 4, 7:28 am, "Ben Jones" <ben.jo...@xilinx.com> wrote:
>> "ni" <nbg2...@gmail.com> wrote in message
>>
>> news:5f6e1999-3ce9-43c2-bb4a-f9336b3b3edd@s50g2000hsb.googlegroups.com...
>>
>>> What I dont understand is SRL16 is a simple shift reister and the
>>> output of SRL16 is just like any other flipflop output with no
>>> combinational logic at the output.
>> Wrong.
>>
>> An SRL16 *functions* just like a simple shift register, but physically it is
>> a special configuration of a LUT primitive. The setup time and clock-to-out
>> time is very different from a FF primitive in the fabric. When you are doing
>> a high-speed design, you should always try to make the last stage of your
>> shift register pipeline use a dedicated FF. Most synthesis tools will do
>> this for your automatically if you just write a straightforward shift
>> register in RTL. No need to go instantiating things.
>>
>> -Ben-
>
> So what your are implying is that its advisable to write the code in
> the following way
> ---------------------------------------------------------------------------------------------------------------------------------------------
> PROCESS(clock,reset)
> begin
> if reset = '1' then
> en4 <= '0';
> elsif clock'event and clock ='1' then
> en4 <= en3;
> end if;
> end process;
>
> SR : SRL16 generic map
> (INIT => x"0000")
> port map (Q => en3,
> A0 => '0',
> A1 => '1',
> A2 => '0',
> A3 => '0',
> CLK => clock,
> D => input);
>
> ---------------------------------------------------------------------------------------------
> instead of
>
>
>
> SR : SRL16 generic map
> (INIT => x"0000")
> port map (Q => en4,
> A0 => '1',
> A1 => '1',
> A2 => '0',
> A3 => '0',
> CLK => clock,
> D => input);
> Is that right?
No, no--he's suggesting you write behavioral code, which infers the SRL
you would don't have to instantiate it. If you use Synplify, for
example, it will make the last stage of the delay line a packed flipflop
depending upon the timing requirements. So then you needn't worry about
what primitives are being used. You shouldn't instantiate primitives
unless completely necessary. It destroys clarity, maintainability, and
portability. This is an example from the Synplify help files that shows
how to make a byte-wide 4-cycle delay line:
entity srltest is
port ( inData: std_logic_vector(7 downto 0);
clk, en : in std_logic;
outStage : in integer range 3 downto 0;
outData: out std_logic_vector(7 downto 0)
);
end srltest;
architecture rtl of srltest is
type dataAryType is array(3 downto 0) of std_logic_vector(7 downto 0);
signal regBank : dataAryType;
begin
outData <= regBank(outStage);
process(clk, inData)
begin
if (clk'event and clk = '1') then
if (en='1') then
regBank <= (regBank(2 downto 0) & inData);
end if;
end if;
end process;
end rtl;
It's cleaner in Verilog, of course.
-Kevin
Article: 130902"Symon" <symon_brewer@hotmail.com> wrote in message news:ft5neg$a38$1@aioe.org... > sky465nm@trline4.org wrote: > > Yes, not reading the "Troubleshooting hints" section of AN19 first. > Particularly hint 12. > Google :- > AN19 site:linear.com LOL!Article: 130903
Un bel giorno David Brown digiṭ:
> The reason (I presume) they don't use bittorrent is basically because it
> would not work for this sort of software. Only a small proportion of
> users would be interested in using bittorrent downloads in a
> professional setting, and only a few of these would be allowed by their
> IT department, and even fewer would leave the torrents running with fast
> enough upload capacity for other downloaders to see decent download
> speeds. Add to that the common misunderstandings of bittorrent ("How do
> we know we are getting the proper software - maybe the file is corrupt,
> or it's picked up a virus from some sharer's PC?" and "Isn't bittorrent
> only for (sic) pirated files?") and some ISP's brain-dead
> anti-bittorrent schemes to cheat users out of their bandwidth, and you
> get a very poor choice of distribution method for this kind of software.
BitTorrent would be an alternative way, not the only way for the download.
Then everyone would choose their preferred way, and I bet that at least a
half of the users would choose the torrent. Many companies distribute their
professional software with either http/ftp and BitTorrent (OpenOffice and
most Linux distributions are the first that come to mind).
--
emboliaschizoide.splinder.com
Article: 130904
ni wrote:
> So what your are implying is that its advisable to write the code in
> the following way
If I were having trouble making timing,
I would use a generic shifter.
It is faster in nS and in work hours.
Registers are free on many fpga designs.
-- Mike Treseler
Article: 130905John McCaskill wrote: > On Mar 23, 6:40 pm, Jon Elson <el...@pico-systems.com> wrote: > >>I got a batch of "Xilinx" Spartan XCS30 FPGAs from a Chinese >>seller, and am having problems with random failures at first >>power up. Sometimes it is a stuck I/O pin, sometimes a failure >>to configure. I first thought maybe we had an ESD problem, but >>I'm now thinking these may be counterfeit. They have white ink >>printed labels on the front, whereas other Xilinx chips have >>laser-etched labels. Also, these Spartan chips don't have the >>Spartan logo just below the Xilinx logo, like my other Xilinx >>chips. Anyone have any comments on this? >> >>Jon > > > > While I have never had to use them for counterfeit detection, I have > use Process Sciences for process control, inspection and rework for > several years now. I have always been very happy with their work. They > have some information about their counterfeit detection services here: > > http://www.process-sciences.com/services/counterfeit_detection.asp > > One of the trade journals I get has been running a series of articles > about counterfeit parts. I think it was either EE Times, or EDN. Some > of the things that they mentioned include remarking to a better speed > grade, a lower power version, or a larger memory size. This was a very small batch of parts, so it doesn't make much sense to spend a lot of money on it. I still have no idea whether there was any funny business, or these parts were just mishandled in some way to cause them to deteriorate. A number of them would not do the master mode configuration, so that can't be a speed grade problem. But, half of them work! I still don't know if I have some kind of process problem here in my shop, but I am coming around to think it is not something I caused here. JonArticle: 130906
What is the current status now about inferring FIFOs in Virtex 4 or 5 with VHDL ? Brad Smallridge Ai VisionArticle: 130907
Jon Elson wrote: > > This was a very small batch of parts, so it doesn't make much sense to > spend a lot of money on it. I still have no idea whether there was any > funny business, or these parts were just mishandled in some way to cause > them to deteriorate. A number of them would not do the master mode > configuration, so that can't be a speed grade problem. But, half of > them work! I still don't know if I have some kind of process problem > here in my shop, but I am coming around to think it is not something I > caused here. > > Jon Some ideas: Did you bake the parts before assembly? Are you hand-soldering the deviecs?Article: 130908
austin <austin@xilinx.com> wrote: > >Go here: > >http://www.xilinx.com/products/design_resources/power_central/ > >Then scroll down to the manufacturers. > >Pick the one you like, and go to their Xilinx FPGA power supply pages. > >All choices are "approved" for use with ALL Xilinx product. > >We (I personally) spend a lot of time with these folks, to ensure a >smooth (pun intended) powering experience. > >Not sure why the other negative posts...perhaps these are the folks who Perhaps a lot of designers are not happy with the fact they are treated as complete idiots when it comes to SMPS design :-) -- Programmeren in Almere? E-mail naar nico@nctdevpuntnl (punt=.)Article: 130909
craig.taylor@xilinx.com wrote: >Hello all, > >I am a Quality manager at Xilinx, and I have asked to provide >specific >guidance on the question of counterfieting. I would like to start by >saying that the ONLY way to protect yourself is to purchase your >devices from an authorized Xilinx distributor. A list can be found >at >this link. http://www.xilinx.com/company/sales/ww_disti.htm > > >If you a buying outside of this channel you are taking on a fair >amount of risk. Over the past 1.5 years Xilinx along with the Dept >of >Homeland Security have become aware of an escalatng issue out of SE >Asia, where Xilinx component are being marked up for sale into grey >market channels. We currently are looking into how to limit this >activity. Simple, burn the batch code (fabrication date) and speedgrade into the die and make them readable through JTAG. -- Programmeren in Almere? E-mail naar nico@nctdevpuntnl (punt=.)Article: 130910
Nico Coesel wrote: > austin <austin@xilinx.com> wrote: > > >>Go here: >> >>http://www.xilinx.com/products/design_resources/power_central/ >> >>Then scroll down to the manufacturers. >> >>Pick the one you like, and go to their Xilinx FPGA power supply pages. >> >>All choices are "approved" for use with ALL Xilinx product. >> >>We (I personally) spend a lot of time with these folks, to ensure a >>smooth (pun intended) powering experience. >> >>Not sure why the other negative posts...perhaps these are the folks who > > > Perhaps a lot of designers are not happy with the fact they are > treated as complete idiots when it comes to SMPS design :-) I'd be less worried about SMPS design, and more worried about the undocumented interaction of things like fold-back and StartUp current peaks. It's what they DONT say that matters, and there is a lot to be said for a design that has been tested (and one hopes, fully margined by Austin!) -jgArticle: 130911
On Sat, 05 Apr 2008 11:48:43 +1200, Jim Granville <no.spam@designtools.maps.co.nz> wrote: >Nico Coesel wrote: > >> austin <austin@xilinx.com> wrote: >> >> >>>Go here: >>> >>>http://www.xilinx.com/products/design_resources/power_central/ >>> >>>Then scroll down to the manufacturers. >>> >>>Pick the one you like, and go to their Xilinx FPGA power supply pages. >>> >>>All choices are "approved" for use with ALL Xilinx product. >>> >>>We (I personally) spend a lot of time with these folks, to ensure a >>>smooth (pun intended) powering experience. >>> >>>Not sure why the other negative posts...perhaps these are the folks who >> >> >> Perhaps a lot of designers are not happy with the fact they are >> treated as complete idiots when it comes to SMPS design :-) > > I'd be less worried about SMPS design, and more worried about the >undocumented interaction of things like fold-back and StartUp >current peaks. > It's what they DONT say that matters, and there is a lot to be said for >a design that has been tested (and one hopes, fully margined by Austin!) Sometimes the app notes and datasheets are wrong as well. For example, I've seen plenty of DC/DC converter module datasheets that indicate that adding more low-ESR capacitance on the output of a DC/DC converter module will improve transient response. A closer look reveals that the app note or datasheet was written around the turn of the century, before modern large ceramic or organic polymer electrolytic caps became commonly available. These have much lower ESR than the app note authors anticipated, and are capable of making older DC/DC converter modules oscillate, or at least exhibit poor transient response. This isn't a problem if you design your own DC/DC converter (in which case you can tune the compensation network to suit the load) or a more modern module with a compensation network designed for a large capacitive load. This pdf gives more information: http://www-03.ibm.com/procurement/proweb.nsf/objectdocswebview/file15+-+ibm+06+capacitance+and+transient/$file/15+-+ibm+06+capacitance+and+transient+06_08_18.pdf Regards, AllanArticle: 130912
craig.taylor@xilinx.com wrote: >I am a Quality manager at Xilinx, and I have asked to provide >specific >guidance on the question of counterfieting. I would like to start by >saying that the ONLY way to protect yourself is to purchase your >devices from an authorized Xilinx distributor. A list can be found >at >this link. http://www.xilinx.com/company/sales/ww_disti.htm The official distributors all have their own loops & hoops. So it's not always practical to buy from them. What we want to know is how to evaluate the authenticity of the product not how to procure it.Article: 130913
On Apr 4, 3:38 pm, Mike Treseler <mike_trese...@comcast.net> wrote: > ni wrote: > > So what your are implying is that its advisable to write the code in > > the following way > > If I were having trouble making timing, > I would use a generic shifter. > It is faster in nS and in work hours. > Registers are free on many fpga designs. > > -- Mike Treseler I have recently started(1 week) using Synplify pro. For two years in my fpga designs I never used synplify pro. For most of the generic component I used to use core generator and then instantiate those component in my vhdl code. I was using xilinx XST extensivley and hence never go these problems. Unfortunately before using synplify pro for mycurrent design I have used core genrator in most of the components. So now I am thingkin of cleaning up the code by changing the cores for example adders , subtractors, SRL16s, BRAMs, ROMS etc to vhdl statements. Are ther any good documents for vhdl coding styles to infer the various components in synplify pro? Thanks for all the suggestions above.Article: 130914
On 4 Apr., 20:03, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > This is absolutely not true. EDK 10.1 is not equal to EDK 9.2. Some software is more equal than other software .... George O.Article: 130915
Nico Coesel wrote: > craig.taylor@xilinx.com wrote: > > >>Hello all, >> >>I am a Quality manager at Xilinx, and I have asked to provide >>specific >>guidance on the question of counterfieting. I would like to start by >>saying that the ONLY way to protect yourself is to purchase your >>devices from an authorized Xilinx distributor. A list can be found >>at >>this link. http://www.xilinx.com/company/sales/ww_disti.htm >> >> >>If you a buying outside of this channel you are taking on a fair >>amount of risk. Over the past 1.5 years Xilinx along with the Dept >>of >>Homeland Security have become aware of an escalatng issue out of SE >>Asia, where Xilinx component are being marked up for sale into grey >>market channels. We currently are looking into how to limit this >>activity. > > > Simple, burn the batch code (fabrication date) and speedgrade into the > die and make them readable through JTAG. Speed is not known until final test, so that would require OTP fuse capability, but that may already be there, at least at the factory level ?. Now, a really clever counterfeit will clone this too, but it would catch slippage, easypath, and really dumb (wrong die) attempts. Unique ID is another natural spin off, for expensive IP. -jgArticle: 130916
Jon Elson wrote: > This was a very small batch of parts, so it doesn't make much sense to > spend a lot of money on it. I still have no idea whether there was any > funny business, or these parts were just mishandled in some way to cause > them to deteriorate. A number of them would not do the master mode > configuration, so that can't be a speed grade problem. But, half of > them work! I still don't know if I have some kind of process problem > here in my shop, but I am coming around to think it is not something I > caused here. That reminds me of another scam : Quantity padding. Someone in the supply line decides to 'pad the numbers', and the report I remember had lower failures on the end of tubes, and higher failures (non blank OTP devices) in the centres. They hope the user will shrug it off. Can you pop the top on some failures and look at the die ? -jgArticle: 130917
Nico, My hat is off to you if know how to calculate Ldi/dt, and determine the gap in the ferrite inductor, but yes, if we are talking in VHDL/verilog, which we do 99.999% of the time, then the people require a power supply solution, canned, and ready to go. AustinArticle: 130918
Allan, That is why our power partners read my app notes, and wee read their appnotes, and every Xilinx circuit app note must be built and tested (if it is hardware, it has to have a pcb...). AustinArticle: 130919
Brad, No issue whatsoever. In V4, the solftware places the extra circuits to bypass the flags that didn't work under some conditions, and in V5 all that hardware works perfectly. You do need to use the appropriate version for V4 with the fixes (which I believe is any 9.X or later). AustinArticle: 130920
Hello everyone i have been working on FPGA and CPLD's for the past 6 months and i have gained sufficent expertise to do something innovative or atleast challenging in my final year project.I have designed ALU units,also implemented the Dice game and also made a processor on a FPGA so my mentor has asked me to come up with an idea using the Dragon FPGA board.Here is the link http://www.fpga4fun.com/PCI.html The idea should revolve around using the PCI bus for example PCI bus master or PCI bus analyzer doing something useful,he suggested me that i should think in terms of what is missing or incomplete on the board.Waiting for your replies. Regards Ankit AnandArticle: 130921
On 2 Apr., 18:22, Antti <Antti.Luk...@googlemail.com> wrote: > On 1 Apr., 14:31, "Nial Stewart" > > <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > I've read all the posts here but have lost track of how you're > > getting on. > > > Can you post an update and describe what the problem turned out > > to be? > > > Nial. > > Quote from Actel website: "In March 2008, it was discovered that a > potential advanced optimization could cause a logic gating of a global > signal. This optimization is part of a set of other routing > optimizations that could be invoked if a user sets the Routing High > Effort Mode in the Advanced Option of the Layout." > > This is fixed in Libero 8.3 released march 31 2008 > > I use the exact target device and setting as described at actel > website, so I assume at least some of the mess i have had may as well > be caused by this global signal gating in high effort mode. > > Folks, dont think I am not trying hard enough, I am, but the tools > sometimes choke as well. The code that I currently have, and that is > randomly failing, whatever constraints, in any normal FPGA fabric with > no tool injected mess, it SHOULD WORK, but it isnt. > > Of course, the tools should be the last thing to blaim on, but > sometimes they are the root of evil > > I try the 8.3 tools and hope it is fixing the issues i have > > Antti updating to 8.3 did not fix the problems, but I am getting closer status: in desing exist async strobes A1, A2 (A1 byte rd/wr strobe, A2 spi slave from ext mcu) loadable LFSR in A1 domain 2:1 MUX for the selecting the load value 1 input of mux = const, loaded at powerup 2 input of mux connected to 24 bit shift register in A2 domain LFSR is loaded with constant at powerup, and loaded with current value in spi shift register ONCE, after that load the load enable signal is FULLY DISABLED now, the actual loads to the LFSR work 100% but when the there is data shifted in into the spi shift register connected to the input mux of the LFSR load input then some sequences of data make the LFSR content corrupt these sequences are REPEATABLE, that is not random! for different FPGA implementiation runs the sequences are different, but still for given PCB/FPGA bitstream they are constant. That is the LFSR gets corrupted at certaing values being visible on the load input via mux I already have forced the LFSR enable and mux select to global clocks of course the SPI clock and LFSR clocks are global clocks as well AnttiArticle: 130922
Ankit wrote: > http://www.fpga4fun.com/PCI.html > > The idea should revolve around using the PCI bus for example PCI bus > master or PCI bus analyzer doing something useful,he suggested me that > i should think in terms of what is missing or incomplete on the > board.Waiting for your replies. PCI is fast and FPGAs have many IOs. Maybe buy some RGB LEDs, think how to build some drivers, which are controlled with PWM signals from the FPGA and build the next Cubatron: http://www.nw.com/nw/projects/cubatron/ The FPGA works as a FIFO for precise timing for controlling the LEDs. The PCI bus would be idle most of the time, but you'll need more speed for a high resolution version of a spinning globe: http://www.youtube.com/watch?v=oLygWkHo9nw In this video you can see how it works: http://www.youtube.com/watch?v=gBZywmIYw4o -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 130923
Hi all, I am looking for the datasheet of the PLS161 which was a PLA. My interest in it is purely academic. I am teaching a high level digital electronics course and would like my students to see a datasheet of a PLA before progressing to CPLD and FPGA's I would be very grateful if someone could give me the datasheet of this device or a similar PLA. Many thanks Regards Joseph A. Zammit MaltaArticle: 130924
rickman wrote: (snip) > Actually, it is not that you *can* produce all logic from NAND gates, > in effect that is how it *is* done. The basic logic element consists > of transistors configured to be a NAND gate, an inverter (a degenerate > form of a NAND gate), a NOR gate (a NAND gate with inverted logic) and > transmission gates. So inside of a chip designed at the gate level, > there really is no distinction between NAND and NOR gates and there > are no OR and AND gates. I believe that is pretty much true for TTL, and I believe also for ECL, PMOS and NMOS, but not for CMOS. CMOS can directly implement either NAND or NOR gates. For non-inverted gates CMOS might require inverters at the input or output. -- glen
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