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
> Some of the newer ARM devkits we've been using lately have come with 2x5 0.05" through hole > instead. 75% of your surface area back is a pretty decent victory. Rob, 1.27mm pitch sounds a bit flimsy but if ARM are using them for programming headers they must be happy enough with reliability and robustness. Do they use a shrouded part? You wouldn't have a part number would you (or an ARM kit number), as usual Digikey has too many options. Nial.Article: 147676
"Thomas Entner" <thomas.entner@entner-electronics.com> wrote in message news:25e512b7-8076-495a-b1ee-95e080e01ff5@k17g2000yqf.googlegroups.com... > With our EEBlaster (http://www.entner-electronics.com/tl/index.php/ > eeblaster.html), we support a 2x3 2mm pitch header which uses just > about 1/3 of the area of the 2x5 header. We think this is a good > compromise of size, price, reliability and availability. We have the > pinout made public on the mentioned link, so everyone can use it, > either together with our EEBlaster or with a self-made adapter-cable. > Best regards > Thomas Entner > www.entner-electronics.com That certainly looks a good option Thomas, top of the contenders so far! Nial.Article: 147677
> I use a 2x4 pin 2mm header for JTAG programming of Xilinx CPLDs. This seems to work quite well, > but maybe for chipscope or similar testing, you need a couple more pins. > Jon Jon, I think for Altera's SignalTap you only need the JTAG signals so Thomas has pipped you with a 2x3mm header rather than 2x4mm header! NialArticle: 147678
On 11 Mai, 17:21, Gabor <ga...@alacron.com> wrote: > On May 11, 6:55=A0am, "maxascent" > > <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote: > > I would of thought if the PCIe spec says that you can do this then it w= ould > > be possible to do it. If the Virtex 6 hardblocks operate independently = from > > each other then it comes down to what the PCIe spec says. > > > Regards > > > Jon =A0 =A0 =A0 =A0 > > > --------------------------------------- =A0 =A0 =A0 =A0 > > Posted throughhttp://www.FPGARelated.com > > I don't think the PCIe specification requires a system to > connect to multiple endpoints in a multi-lane slot. =A0In fact > I would bet that if you tried this in a typical PC you would > at best get a single 4-lane endpoint detected You probably would get a single 1-lane endpoint. Many mainboards will sync a 8x slot only at 8x and 1x width. This is sufficient to meet the spec. For the switch chips that I know the information, which lanes belong to one port is hardwire by strap pins, so there can only be one port per slot. KoljaArticle: 147679
On 14/05/2010 09:53, Martin Thompson wrote: > rickman<gnuarm@gmail.com> writes: > >> On May 11, 3:11 am, Christopher Head<ch...@cs.ubc.ca> wrote: >>> On Mon, 10 May 2010 23:31:23 -0700 (PDT) >>> >>> backhus<goous...@googlemail.com> wrote: >>> >>> [snip]> Also you have no reset scheme, just default assignments in the >>>> declarations. >>>> Xilinx ISE can handle that, but other tools ignore it. >>> >>> [snip] >>> >>> Sorry for hijacking the thread, but... do you mean that if I write this >>> code: >>> >>> signal foo : std_ulogic_vector(3 downto 0) := "1010"; >>> >>> I would *not* normally expect the FPGA to power up with "1010" in the >>> signal!? I've only ever worked with Xilinx FPGAs using ISE, so I >>> assumed it worked everywhere; is this not the case? (kind of nice to >>> know in case I do some day end up using a different make of FPGA...) >>> >>> Chris >> >> I can't say for sure, but I think the reason *why* declaration >> assignments are not used in synthesis is because they are not >> associated with any sort of signal. > > The point is that those assignments *are* used in synthesis by some > tools. XST does it for one. It makes no sense for an ASIC, but for > FPGAs which have a well defined startup condition defined by the > bitstream it makes eminent sense. > <snip> Just one word of warning - I've been caught out by this using Mentor Precision. Precision *does* support initialisation at declaration, but I had to add an attribute to the (VHDL) code to make it happen. Quartus and ISE seem be ok. Synplify seems to accept initialisations by default (i.e. without extra attibutes). I can't speak for other tools, but I know Synplify will even initialize ROM contents by reading a file into a constant using a function. > Now whether you want to take advantage of it depends on how portable > to ASIC you want your code to be > Exactly. I must admit, I still feel happier having a functional reset pin - and if you have a functional reset pin then of course that won't use any initial states, they'll only get applied when the bitstream is downloaded. I suppose you could design a system where the reset procedure was to download the bitstream, of course. regards Alan -- Alan Fitch Senior Consultant Doulos – Developing Design Know-how VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project Services Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24 1AW, UK Tel: + 44 (0)1425 471223 Email: alan.fitch@doulos.com Fax: +44 (0)1425 471573 http://www.doulos.com ------------------------------------------------------------------------ This message may contain personal views which are not the views of Doulos, unless specifically stated.Article: 147680
Hi all, Which one's better to invest in the next project ? TIA and TGIF ;-)Article: 147681
On 5/14/2010 1:53 AM, Nial Stewart wrote: >> Some of the newer ARM devkits we've been using lately have come with 2x5 0.05" through hole >> instead. 75% of your surface area back is a pretty decent victory. > > > Rob, 1.27mm pitch sounds a bit flimsy but if ARM are using them for > programming headers they must be happy enough with reliability and > robustness. > > Do they use a shrouded part? > > You wouldn't have a part number would you (or an ARM kit number), as usual > Digikey has too many options. > > > Nial. > We're just trying this plan out on our boards for the first time, so I'll have to let you know how it turns out. This time we're using an unshrouded connector, since we've got giant DC/DC converters next to them providing mechanical cover. Digikey part S9015E-05-ND. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 147682
Nial Stewart wrote: > It would be good to have a more compact 'standard' surface mount programming > header. > I've used Molex Picoblade vertical headers and connectors reasonably sucessfully > but these probably aren't robust enough for high volume operation (it's only > rated at 30 mating cycles though I've had a lot more out of it). 30 only ? damn... > Has anyone any better solutions? I don't know if mine is better but after having used other programming means than JTAG, I have come to these conclusions : - the target should have the female connector, less likely to be damaged. OTOH, the probe has the male pins and they can be easily damaged so I plan interchangeable/disposable headers. It's better to spend a fraction of dollar on a new probe header than to fix an existing board :-/ - My next projet will use 2mm or 1.27mm connectors with the usual 2x5 configuration for JTAG. No idea which one I'll finally choose. I'll also make a small adapter for the 2.54mm probe. - spring-loaded test probes are also great : they're 10 or 100x more expensive per pin but there is no part to solder on the target, no hole to drill or height problem. Well, it's extreme, right... - Do never forget to key the connectors ! it is a safe to sacrifice at least one pin to prevent reverse connexions or shifted connexions. > Come on Altera (and the rest), give us a standard. don't count on them to "give" a "good" standard ;-) they're in for the money, they follow the money... > Nial. yg -- http://ygdes.com / http://yasep.orgArticle: 147683
On May 13, 2:43=A0pm, John McCaskill <jhmccask...@gmail.com> wrote: > On May 13, 4:13=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote: > > > > > On 5/13/2010 1:56 PM, rickman wrote: > > > > On May 13, 3:25 pm, John McCaskill<jhmccask...@gmail.com> =A0wrote: > > >> On May 13, 1:14 pm, rickman<gnu...@gmail.com> =A0wrote: > > > >>> On May 13, 10:18 am, John McCaskill<jhmccask...@gmail.com> =A0wrote= : > > > >>>> On May 13, 8:53 am, Sharath Raju<brshar...@gmail.com> =A0wrote: > > > >>>>> Hello, > > > >>>>> I am facing a problem of clock signals being generated by > > >>>>> combinatorial logic. > > > >>>>> Here is the timing report: > > > >>>>> TIMING REPORT > > > >>>>> NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE. > > >>>>> =A0 =A0 =A0 =A0FOR ACCURATE TIMING INFORMATION PLEASE REFER TO TH= E TRACE REPORT > > >>>>> =A0 =A0 =A0 =A0GENERATED AFTER PLACE-and-ROUTE. > > > >>>>> Clock Information: > > >>>>> ------------------ > > >>>>> -----------------------------------+------------------------+----= ---+ > > >>>>> Clock Signal =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Clock = buffer(FF name) =A0| Load =A0| > > >>>>> -----------------------------------+------------------------+----= ---+ > > >>>>> clk =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| BUFGP =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| 23 =A0 =A0| > > >>>>> Dec_cnt(Dec_cnt1:O) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| NONE(*)(Int_= count_1) =A0 | 10 =A0 =A0| > > >>>>> -----------------------------------+------------------------+----= ---+ > > >>>>> (*) This 1 clock signal(s) are generated by combinatorial logic, > > >>>>> and XST is not able to identify which are the primary clock signa= ls. > > >>>>> Please use the CLOCK_SIGNAL constraint to specify the clock signa= l(s) > > >>>>> generated by combinatorial logic. > > > >>>>> clk is my "true" clock signal, whereas Dec_cnt is some other > > >>>>> combinatorial signal. > > > >>>>> I have tried using the CLOCK_SIGNAL constraint both in my source = file, > > >>>>> as follows: > > > >>>>> attribute clock_signal : string; > > >>>>> attribute clock_signal of clk : signal is "yes"; > > >>>>> attribute clock_signal of Dec_cnt : signal is "no"; > > > >>>>> and in the xilinx constraints file (.xcf) > > > >>>>> BEGIN MODEL sdmac > > >>>>> =A0 NET "clk" CLK_SIGNAL =3D yes; > > >>>>> END; > > > >>>>> In either case, I get the same problem. > > > >>>>> Here is my source file:http://sites.google.com/site/brsharath/sdm= ac_signal_sched.vhd?attredi... > > > >>>>> Please help > > > >>>> The problem is this bit of code: > > > >>>> process (Inc_cnt, Dec_cnt) > > >>>> begin > > >>>> =A0 =A0if Inc_cnt =3D '1' then > > >>>> =A0 =A0 =A0Int_count<=3D Int_count + 1; > > >>>> =A0 =A0elsif Dec_cnt =3D '1' then > > >>>> =A0 =A0 =A0Int_count<=3D Int_count - 1; > > >>>> =A0 =A0end if; > > > >>>> end process; > > > >>>> Inc_cnt looks like an asynchronous reset, and Dec_cnt looks like t= he > > >>>> clock. > > > >>>> If you wanted this to be a clocked process, put the clock in the > > >>>> sensitivity list and remove Inc_cnt and Dec_cnt. > > > >>>> Regards, > > > >>>> John McCaskillwww.FasterTechnology.com > > > >>> This is not describing edge sensitive clocked logic. =A0It is descr= ibing > > >>> a latch. =A0But both signals, Inc_cnt and Dec_cnt would be used to > > >>> generate the latch enable. =A0So the question is whether the OP int= ended > > >>> this to use a latch or if it was supposed to be clocked by a system > > >>> clock edge. =A0The danger in this case is that the logic is a feedb= ack > > >>> loop and if the enable is asserted long enough for a change on the > > >>> output to reach back around to the input, it would be counting up o= r > > >>> down at its fastest possible rate the entire time the enable is > > >>> asserted. > > > >>> I haven't looked at the code. =A0Is it possible this was meant to u= se > > >>> separate signals for cur_count and nxt_count with cur_count a regis= ter > > >>> and nxt_count the logic output? > > > >>> Rick > > > >> Actually, it is just incorrect. > > > >> If if is supposed to be a latch (but I hope not), it should also hav= e > > >> Int_count in the sensitivity list. As written, it will synthesize wi= th > > >> warnings as a latch, but not simulate as one. =A0This is still the c= ause > > >> of Dec_cnt being reported as a clock. > > > >> Int_count is not used outside of this process, so it is not clear wh= at > > >> the intention was. > > > >> Int_count is also defined as std_logic_vector, which is a problem. = =A0A > > >> std_logic_vector has no numerical value. > > > >> I would also replace: > > > >> use IEEE.STD_LOGIC_ARITH.ALL; > > >> use IEEE.STD_LOGIC_UNSIGNED.ALL; > > > >> with: > > > >> use IEEE.NUMERIC_STD.ALL; > > > > Yeah, I guess the code is pretty ugly. =A0Why, after all these years = of > > > people discussing the issues with std_logic_unsigned, et. al., do > > > people still start out this way? =A0Do they teach this in the > > > universities or something? > > > > Rick > > > I know that all of Xilinx's example code and templates still don't use > > numeric_std. =A0No idea how the template code from the other vendors lo= oks. > > > -- > > Rob Gaddi, Highland Technology > > Email address is currently out of order > > This is starting to change. =A0The Xilinx VHDL course recommends > numeric_std since the 11.1 version, and the create new source wizard > in ISE 12.1 uses numeric_std now. =A0I still see templates and examples > that don't use it. I expect (but don't know) that will change over the > next few releases. It only took about a decade of complaints and Web Cases to make this happen ... -aArticle: 147684
On May 13, 8:17=A0pm, "jt_eaton" <z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > >hi > >In virtexpro/spartan3a/spartan3 kit when we using system > clock(100Mz/50Mhz) > >and take this clock on i/o pin(by writing VHDL program) on digital C.R.O= . > >it will show corrupred signal , I also tried this by DCM CORE GENERATOR > >again it is giving wrong o/p. Can anybody suggested me solution of this > >problem. > > >--------------------------------------- =A0 =A0 =A0 =A0 =A0 =A0 > >Posted throughhttp://www.FPGARelated.com > > How are you measuring this? scope? probe? analyzer? He said "digital C.R.O." Funny, my digital scope does not have a cathode ray tube! -aArticle: 147685
On May 14, 4:23=A0am, Alan Fitch <alan.fi...@spamtrap.com> wrote: > > I suppose you could design a system where the reset procedure was to > download the bitstream, of course. I suppose it depends on the complexity of the design, but it seems to me that if something's so out of whack that it needs an explicit reset to get going again, perhaps a total system reset that includes reloading the bitstream is in order? -aArticle: 147686
Hi, Is there any public information available about the roll-out schedule of production (non-ES) Spartan 6 devices, and their final price? Thanks, -- S=E9bastien Bourdeauducq The Milkymist project http://www.milkymist.orgArticle: 147687
There is a rollout schedule but as far as I know it is only supplied under NDA and you need to talk to your Xilinx distributor for that. What I can say is that there are C grade parts available now at Avnet and their pricing is on their website. Not many yet but it's a start. John Adair Enterpoint Ltd. - Home of Raggedstone2. The Spartan-6 PCIe Board. On 15 May, 13:48, Sebastien Bourdeauducq <sebastien.bourdeaud...@gmail.com> wrote: > Hi, > > Is there any public information available about the roll-out schedule > of production (non-ES) Spartan 6 devices, and their final price? > > Thanks, > -- > S=E9bastien Bourdeauducq > The Milkymist projecthttp://www.milkymist.orgArticle: 147688
We are selling off some our Craignell1 (original version) stock that we found in our recent move. One is on Ebay with no reserve. More will follow over the next few weeks or months. We have a small pile of these allocated to give away for deserving student or educational institution projects. Contact our sales team if you have a deserving project and want one or two. Email is on our website if you don't know it already. John Adair Enterpoint Ltd.Article: 147689
Am 13.05.2010 16:18, schrieb John McCaskill: > The problem is this bit of code: > > process (Inc_cnt, Dec_cnt) > begin > if Inc_cnt = '1' then > Int_count <= Int_count + 1; > elsif Dec_cnt = '1' then > Int_count <= Int_count - 1; > end if; > > end process; > > > Inc_cnt looks like an asynchronous reset, and Dec_cnt looks like the > clock. You pointed out a very bad piece of code, but it is not a flipflop - it is a latch as rickman has already pointed out. It has 2 big design errors: 1) muxed latch: Inc_cnt and Dec_cnt drive latch-enable and mux-select. This is very bad design because no one can say if the latch-enable or the mux-select chances first in the moment when Inc_cnt / Dec_cnt become inactive. 2) infinite loop: As long as Inc_cnt / Dec_cnt is enable, Int_count is incremented / decremented. During simulation this problem did not show up, because the sensitivity list of this process is incomplete. Put Int_count into the sensitivity list and the simulator will freeze forever. RalfArticle: 147690
Spartan 2 docs clearly says that, even though you are configuring the FPGA in serial mode, you should keep CS pin high. What about Spartan 3? I don't see something like: "Yes, Spartan 2 had an error, but it has been fixed in Spartan 3"Article: 147691
> - the target should have the female connector, > less likely to be damaged. OTOH, the probe has the > male pins and they can be easily damaged so I plan > interchangeable/disposable headers. It's better > to spend a fraction of dollar on a new probe header > than to fix an existing board :-/ It's probably also the case that it's the female side of the pair that fails first, a male probe header will last longer than a female. On the other hand putting females on the board is probably more expensive. Having said that if cost is that sensitive you'll probably be using test probes as below... > - spring-loaded test probes are also great : > they're 10 or 100x more expensive per pin > but there is no part to solder on the target, > no hole to drill or height problem. > Well, it's extreme, right... Is it that extreme? It isn't much hassle adding probably test points to allow the option of no-fitting he headers and probably wouldn't be too hard making a jig to hold the bits. You wouldn't have to get full a bed of nails jig done. >> Come on Altera (and the rest), give us a standard. > don't count on them to "give" a "good" standard ;-) > they're in for the money, they follow the money... Aye, but it's getting to the stage where an FPGA and programming memory footprint is matched by the programming header! It could start to affect device selection. Nial.Article: 147692
Sebastien Bourdeauducq <sebastien.bourdeauducq@gmail.com> wrote: > Hi, > Is there any public information available about the roll-out schedule > of production (non-ES) Spartan 6 devices, and their final price? Beginning of March I asked at the Xilinx Booth at Embedded World, and some manager came up with a lists, showing all parts well on their way though manufacturing, expectable soon. digikey and "buy online" on xilinx.com tell another story... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 147693
On 17 May, 11:47, Uwe Bonnes <b...@elektron.ikp.physik.tu- darmstadt.de> wrote: > Sebastien Bourdeauducq <sebastien.bourdeaud...@gmail.com> wrote: > > Hi, > > Is there any public information available about the roll-out schedule > > of production (non-ES) Spartan 6 devices, and their final price? > > Beginning of March I asked at the Xilinx Booth at Embedded World, and some > manager came up with a lists, showing all parts well on their way though > manufacturing, expectable soon. digikey and "buy online" on xilinx.com tell > another story... Same old Xilinx I'm afriad! /Awaits post from Austin saying they have been selling them since 1996.Article: 147694
Hello, I am new to FPGA debugging using ChipScope. I know that ChipScope Pro tool is an internal logic analyser for FPGA Hardware designs.... But, is there a way to debug a hardware design that is not made on FPGA, using FPGA's ChipScope tool? Thanks for your help! Roger --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147695
Andy Peters <google@latke.net> writes: > On May 14, 4:23 am, Alan Fitch <alan.fi...@spamtrap.com> wrote: >> >> I suppose you could design a system where the reset procedure was to >> download the bitstream, of course. > > I suppose it depends on the complexity of the design, but it seems to > me that if something's so out of whack that it needs an explicit reset > to get going again, perhaps a total system reset that includes > reloading the bitstream is in order? Indeed so - given that getting "that out-of-whack" may have involved (for example) a clock glitch - in which case corrupt BRAMs may be the result (program code, state machines...), which can only be "reset" by a bitstream load (or some kind explicit scrubbing in the design). Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 147696
> The point is that those assignments *are* used in synthesis by some > tools. XST does it for one. It makes no sense for an ASIC, but for > FPGAs which have a well defined startup condition defined by the > bitstream it makes eminent sense. > > Now whether you want to take advantage of it depends on how portable > to ASIC you want your code to be Or whether you want to have completely unpredictable/broken behaviour if you decide to change FPGA vendors! Nial.Article: 147697
Chipscope is only for debugging Xilinx FPGAs. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147698
On May 17, 1:49=A0am, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > >> Come on Altera (and the rest), give us a standard. > > don't count on them to "give" a "good" standard ;-) > > they're in for the money, they follow the money... > > Aye, but it's getting to the stage where an FPGA and programming > memory footprint is matched by the programming header! > > It could start to affect device selection. Are you serious? I don't think that Xilinx, Altera or ARM really care what header is used on the target board. Each of use picked something that we think makes sense and provided a ribbon cable that mates the JTAG cable to the target board. Nothing prevents you from using an alternative connector on the target board and creating an adapter that connects to the JTAG cable. Ed McGettigan -- Xilinx Inc.Article: 147699
> > It could start to affect device selection. > Are you serious? Well, probably not. > I don't think that Xilinx, Altera or ARM really care what header is > used on the target board. Each of use picked something that we think > makes sense and provided a ribbon cable that mates the JTAG cable to > the target board. It did make sense 15 years ago, but it's a bit ridiculous if you're using 0201/0402 components to have to use the behemoth 2x5 0.1" pin header. :-) > Nothing prevents you from using an alternative connector on the target > board and creating an adapter that connects to the JTAG cable. Adaptors lead to un-reliability, wires getting crossed or shorted etc. It would be nice to have a more compact 'standard'. The EEBlaster that Thomas linked to earlier in the thread... http://www.entner-electronics.com/tl/index.php/eeblaster.html ...has two 'programming heads' which seems a good solution. Nial.
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