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
climber.tim@gmail.com wrote: > It is most cost-optimal for crypto-tasks, if I'm correct, of course. > Like it was done there: http://www.copacobana.org/faq.html Just a couple more thoughts on this (I'm not a crypto person but hey, this is Usenet): I'm not sure how interesting having such a device (as described at that URL) would actually be. They talk about being able to crack symmetric cyphers with "roughly" 64-bit keys. Well for standard DES "roughly" is only 56 bits as I recall, so when they say the average time to break a DES key was 6.4 days, that means a real 64-bit cypher would take an average of 4.5 years with a worst case of 9 years at the same speed. Cracking plain DES is a clever demonstration of parallel computing, but these days just isn't all that interesting any more I think. The 120 FPGA device described is unlikely to be good for anything other than brute-force parallel tasks, and in the crypto world I don't know that there are many other interesting things you can do that are of similar complexity to cruddy old single DES. It seems to me (again not being a crypto guy) that all these cracking machines may be somewhat uninteresting for many real-world applications because they must be known-plaintext attacks as they rely not only on being able to do fast decrypt operations to test each possible key, but also being able to determine whether the key was correct or not in a similarly short period of time. This might not be so easy to do depending on how much knowlege you have about the plain text of the message you're trying to decrypt. Anyhow, I can't really think of anything interesting to do with a device such as the one you're asking about. G.Article: 131926
It works! Yes! Thanks in particular to Martin and Mikhail, as well
as to everyone else who offered suggestions.
In the interest of saving someone else from this particular tar-pit, I
thought I'd detail what the problem was. Here is the relevant code
from the app note:
/* Wait at least the specified number of
microsec. */
/* Use a timer if possible; otherwise estimate the number of
instructions */
/* necessary to be run based on the microcontroller speed. For this
example */
/* we pulse the TCK port a number of times based on the processor
speed. */
void waitTime(long microsec)
{
static long tckCyclesPerMicrosec = 1;
long tckCycles = microsec * tckCyclesPerMicrosec;
long i;
/* For systems with TCK rates >= 1 MHz; This implementation is
fine. */
for ( i = 0; i < tckCycles; ++i )
{
pulseClock();
}
#if 0
/* For systems with TCK rates << 1 MHz; Consider this
implementation. */
if ( microsec >= 50L )
{
/* Make sure TCK is low during wait for XC18V00/XCF00 */
/* Or, a running TCK implementation as shown above is an OK
alternate */
setPort( TCK, 0 );
/* Use Windows Sleep(). Round up to the nearest millisec */
_sleep( ( microsec + 999L ) / 1000L );
}
else /* Satisfy Virtex-II TCK cycles */
{
for ( i = 0; i < microsec; ++i )
{
pulseClock();
}
}
#endif
#if 0
/* If Virtex-II support is not required, then this implementation
is fine */
/* Make sure TCK is low during wait for XC18V00/XCF00 */
/* Or, a running TCK implementation as shown above is an OK
alternate */
setPort( TCK, 0 );
/* Use Windows Sleep(). Round up to the nearest millisec */
_sleep( ( microsec + 999L ) / 1000L );
#endif
}
As you can see, there are three different examples of implementations
for waitTime. The first method (the "default") does indeed pulse TCK,
while the third one definitely does not, and the second one only
pulses for "short" delays! Because I am using a Spartan-3, and
because I wanted to use an OS sleep function, it seemed the third
approach was valid, but, well, I guess not... I opened a Xilinx
support case, and I'm going to request they clarify this code -
hopefully, no one else makes my mistake!
Thanks again, everybody!
-Bob
Article: 131927Bob, Congratulations! I am curious if the second method will work?... I think there is a good chance that it will... /MikhailArticle: 131928
On May 7, 6:36 pm, "MM" <mb...@yahoo.com> wrote: > Bob, > > Congratulations! Thanks! > I am curious if the second method will work?... I think there is a good chance that it will... Without fully understanding things, I'm guessing so too, especially if my suspicion that the Spartan-3 is related to the Virtex-II in some important way; that sounds familiar now. Suppose I could look it up, but I'm too busy now making up for lost time! Anyway, I was going to say I don't have time to try, but since you've been so good to me, I figure I could return the favor. Yes, the second method does indeed work! Seems to suggest there are two separate uses of this function, one which the FPGA requires pulses for whatever reason, and the other just time (erasing flash?)... Take care, BobArticle: 131929
On Wed, 7 May 2008 12:19:40 -0700 (PDT), John_H <newsgroup@johnhandwork.com> wrote: >John Larkin wrote: >> >> To Lattice: >> >> We dumped Lattice over buggy compilers and dinky performance. Now that >> you're spamming our group, I'll make the ban permanent. >> >> >> To the group: >> >> Whenever anybody spams us, please >> >> 1. Blackball them as a vendor >> >> 2. Say bad things about their companies and products, preferably with >> lots of google-searchable keywords. >> >> John > >Was this really necessary? > >If there were technical webcasts from any of the big vendors, I'd like >to know about them though preferably more than 8 minutes beforehand. >If the posts of this nature got to be more than a couple a month from >any one source I'd agree with the spam catagorization but it isn't >that frequent. > >I'm disappointed that you had problems with them in the past and won't >trust them for future designs because of your history; competition is >almost always good. But is it reason to be publicly vocal? > >Kill-lists are easy to manage if bart's messages offend you. > >- John_H If we don't discourage commercial posts, newsgroups will be flooded with them. I can't kill-file the tens of thousands of companies who would spam newsgroups if they thought it would pay off. So let's make sure it *doesn't* pay off. If they want to advertise, let them pay for it somewhere else. JohnArticle: 131930
On Thu, 08 May 2008 07:37:44 +1200, Jim Granville <no.spam@designtools.maps.co.nz> wrote: >John Larkin wrote: > >> On Wed, 7 May 2008 10:52:01 -0700 (PDT), bart >> <bart.borosky@latticesemi.com> wrote: >> >> >>>Lattice is holding a webcast today, Wednesday, May 7th, on our latest >>>version of our FPGA software design tools "ispLEVER 7.1 FPGA Design >>>Tool Technical Rollout." The presenter will be Troy Scott, from our >>>software marketing group. >>> >>>If you're interested, the event takes place live at 11am Pacific, >>>18:00 GMT. In addition, you will be able to view this webcast archive >>>on-demand, at your convenience, starting a few hours after the live >>>event takes place. >>> >>>You can register by clicking: >>>http://www.latticesemi.com/corporate/webcasts/isplever7.1fpgadesigntool.cfm >>> >>>Bart Borosky, Lattice >> >> >> >> >> To Lattice: >> >> We dumped Lattice over buggy compilers and dinky performance. Now that >> you're spamming our group, I'll make the ban permanent. > >General Comment: >I've not found complex Sw yet that does not have some bugs/blindspots. >I've also improved (pretty much) all the engineering SW I use, by >giving usable errata reports to the supplier(s). > >'dinky' I have no idea about, does not sound like an engineering term ? > >Do all your design decisions have the same carefull reasoning basis ? > >What Bart could do is include a link to the Tools Revision History, >so potential (and past) users can see what has been changed. > >-jg > > What Bart could do is advertise in advertising venues. Usenet ain't one. JohnArticle: 131931
On May 7, 12:21 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Eric Smith wrote: > > There were quite a few asynchronous computers in the old days, but > > the world settled on synchronous designs for various reasons. In recent > > years there has been a resurgence of interest in asynchronous designs, > > partly due to the possibility of power savings. There are still no > > mainstream asynchronous processors, though. > > There are rumors of asynchronous functional modules, such as > multipliers or dividers. That might make more sense in current > systems than a completely asynchronous design. The industry trend for the last few years have been GALS, globally Asynchronous, Locally Synchronous for many good reasons, including: - managing the clock skew across a large design is hard, expensive, and power hungry. - it's a natural paradigm when you want to run islands a different speeds, or even power it down for power savings. I expect it could also be a life saver, isolating a speed path to just its island rather than impacting the whole chip. I don't know how common this is in FPGA design, but the LPRP reference design uses a handful of clocks. Tommy From rich@example.net Wed May 07 16:58:34 2008 Path: flpi142.ffdc.sbc.com!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!newshub.sdsu.edu!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!spamkiller.gnilink.net!gnilink.net!trnddc01.POSTED!dd653b87!not-for-mail From: Rich Grise <rich@example.net> Subject: Re: ANNC: FPGA Design Software Webcast User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Message-Id: <pan.2008.05.08.00.57.12.29099@example.net> Newsgroups: comp.arch.fpga,comp.lang.verilog,comp.arch.embedded,sci.electronics.design,comp.lang.vhdl References: <425d29bf-5370-4de3-878b-7e7a6233f144@d45g2000hsc.googlegroups.com> <svr324tqboadq6k9qcvpena8gir54ookvm@4ax.com> <48220549@clear.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lines: 9 Date: Wed, 07 May 2008 23:58:34 GMT NNTP-Posting-Host: 71.119.122.152 X-Complaints-To: abuse@verizon.net X-Trace: trnddc01 1210204714 71.119.122.152 (Wed, 07 May 2008 19:58:34 EDT) NNTP-Posting-Date: Wed, 07 May 2008 19:58:34 EDT X-Original-Bytes: 1309 Xref: prodigy.net comp.arch.fpga:144395 comp.lang.verilog:38763 comp.arch.embedded:290859 sci.electronics.design:901140 comp.lang.vhdl:74675 X-Received-Date: Wed, 07 May 2008 19:58:35 EDT (flpi142.ffdc.sbc.com) On Thu, 08 May 2008 07:37:44 +1200, Jim Granville wrote: > Do all your design decisions have the same carefull reasoning basis ? Does all your writing show the same careful editing? >:-> Cheers! RichArticle: 131932
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:o1e424d2h2uldtu4qm4589v667lu96hip8@4ax.com... > On Wed, 7 May 2008 12:19:40 -0700 (PDT), John_H > <newsgroup@johnhandwork.com> wrote: > >>John Larkin wrote: >>> >>> To Lattice: >>> >>> We dumped Lattice over buggy compilers and dinky performance. Now that >>> you're spamming our group, I'll make the ban permanent. >>> >>> >>> To the group: >>> >>> Whenever anybody spams us, please >>> >>> 1. Blackball them as a vendor >>> >>> 2. Say bad things about their companies and products, preferably with >>> lots of google-searchable keywords. >>> >>> John >> >>Was this really necessary? >> >>If there were technical webcasts from any of the big vendors, I'd like >>to know about them though preferably more than 8 minutes beforehand. >>If the posts of this nature got to be more than a couple a month from >>any one source I'd agree with the spam catagorization but it isn't >>that frequent. >> >>I'm disappointed that you had problems with them in the past and won't >>trust them for future designs because of your history; competition is >>almost always good. But is it reason to be publicly vocal? >> >>Kill-lists are easy to manage if bart's messages offend you. >> >>- John_H > > > If we don't discourage commercial posts, newsgroups will be flooded > with them. I can't kill-file the tens of thousands of companies who > would spam newsgroups if they thought it would pay off. So let's make > sure it *doesn't* pay off. > > If they want to advertise, let them pay for it somewhere else. > > > John > For what it's worth, I agree with John. It's a real shame that we, now, have to go out of our way to filter commercial and sexual posts. There are proper places for both of those. Usenet is not one of them, in my opinion. Bob -- == NOTE: I automatically delete all Google Group posts due to uncontrolled SPAM ==Article: 131933
On May 7, 2:38=A0pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Hi Peter, Ken, > > Peter Alfke wrote: > > The quadrature encoder has been tested and proven to work ( thank you, > > Ken Chapman), detecting every transition as a count pulse, > > It also seems to bundle all illegal transistions into 'rotary_left' bucket= ? > > ie Missing is : > Illegal_event <=3D (rotary_q1 xor delay_rotary_q1) and (rotary_q2 xor > delay_rotary_q2); > > > never an > > accumulated error. The only flaw is a one-pulse backlash. > > That could be a quite serious drawback in a closed loop system ? > eg a DC servo system with a relatively coarse quadrature encoder, > should be able to seek any edge, and 'dither-lock' there. > > > That means, > > it does not recognize the first change after a reversal of direction. > > You could call it hysteresis, analogous to a +/- 1 count ambiguity, > > known to exist in many conversions. > > Do you have device report files ? > This seems to use quite few flip-flops. > Tolerable in a FPGA, less desirable in a CPLD. > > What is the latency, and the max count speed, in clk terms ? > > -jg You are right, it uses few flip-flops: four to be exact, plus 4 LUTs. Call that four Logic cells. Obviously fits also into PALs and CPLDs. Latency is 2 clock ticks. I have explained the "electronic backlash". It's inherent to the design. You either can tolerate it or you cannot. For crying out loud: This was a simple, almost trivial, cute and clever design idea. Let's not make a big issue out of it....It works, and I explained the limitation. We built hundreds of instruments, and it is nice (but not earth- shakingly so) that we can trust this trivial circuit to never give us any bad surprise. Peter Alfke Peter Alfke Peter Alfke Peter AlfkeArticle: 131934
Rich Grise wrote: > On Thu, 08 May 2008 07:37:44 +1200, Jim Granville wrote: > >> Do all your design decisions have the same carefull reasoning basis ? > > Does all your writing show the same careful editing? >:-> > > Cheers! > Rich Damn that comp.sci.electronics cross-posting! That's the biggest thing I would fault bart for - cross-posting. - John_HArticle: 131935
On Wed, 07 May 2008 17:35:23 -0400, CBFalconer <cbfalconer@yahoo.com> wrote: >John Larkin wrote: >> bart <bart.borosky@latticesemi.com> wrote: >> >>> Lattice is holding a webcast today, Wednesday, May 7th, on our >>> latest version of our FPGA software design tools "ispLEVER 7.1 >>> FPGA Design Tool Technical Rollout." The presenter will be Troy >>> Scott, from our software marketing group. >>> >>> If you're interested, the event takes place live at 11am Pacific, >>> 18:00 GMT. In addition, you will be able to view this webcast >>> archive on-demand, at your convenience, starting a few hours >>> after the live event takes place. >>> >>> You can register by clicking: >>> http://www.latticesemi.com/corporate/webcasts/isplever7.1fpgadesigntool.cfm >> >> We dumped Lattice over buggy compilers and dinky performance. >> Now that you're spamming our group, I'll make the ban permanent. > >You're wrong. Proper announcements are quite topical. The quality >may be questionable, and that is also suitable for discussion. Of >course, making the announcement less than one hour before the event >begins is indicative of poor thinking. Even 24 hours notice would >be cutting it close. Since s.e.d. is unmoderated, there is no real right or wrong. We each get one vote. I intend to say bad things about companies that spam the group, and not buy their junk, and I hope that others will act similarly. You do whatever pleases you. I believe the charter, which has no force, does recommend against commercial posts. JohnArticle: 131936
Sure, you can use CORDIC to generate a chirp at 200 MHz, even with older FPGAs (e.g. original virtex in the faster speed grades was capable of this). However, with the large memories available on modern devices, it probably makes sense to use a combination of a look-up and an interpolation or Taylor series to get resolutions you are likely to need. The CORDIC is still handy if you have very high phase or amplitude resolution requirements, but generally speaking it is no longer the best way to generate a sine in current FPGAs. XSterna wrote: > Hello, > > I am on a project of developping a chirp generator on a FPGA. Reading > from the internet I learned that the CORDIC algorithm is broadly used > when we want to synthesis sin functions. > > My supervisor told me that we will be doing the "mathematical" part > with Matlab and then store the data in the FPGA, the signal will then > be "produced" by the FPGA to the output and we will use a DAC to > convert into an analog signal. > > The explanation about using data stored into the FPGA is the need of > fast generation, the signal will be at 200 MSps. > > Here is my question (because I have to be honnest I don't know > anything about analog signal generation with an fpga), is it possible > with the CORDIC algorithm to produce such a signal with high speed of > 200 MSps. Is there any "better" solution since we will be using a > VIRTEX V. > > Do you think the MATLAB solution is the best option (maybe the easiest > at least), because we will have to connect the FPGA to a PC, which > makes me think (but only by intuition) that it is a loss a FPGA > capabilities. > > XArticle: 131937
Peter Alfke wrote: > The quadrature encoder has been tested and proven to work ( thank you, > Ken Chapman), detecting every transition as a count pulse, never an > accumulated error. The only flaw is a one-pulse backlash. That means, > it does not recognize the first change after a reversal of direction. > You could call it hysteresis, analogous to a +/- 1 count ambiguity, > known to exist in many conversions. > Peter Alfke > > Below is the vhdl file, courtesy of my friend Ken Chapman: Do you have a link to a Compilable File ? (or set of files) -jgArticle: 131938
Hi Thorsten, have a look on my website: http://www-user.rhrk.uni-kl.de/~alles/fpga/ In the Files-section there is the source code of a realtime fractal. It includes the VHDL sources of a PS/2 mouse controller. It took me also many hours until the mouse did what I wanted.. Hope this helps, Matthias Thorsten Kiefer schrieb: > Hi, > I'm trying to communicate with the ps2 mouse. > So I first force the ps2c line to '0' for 100us. > Then I force the ps2d line to '0' and ps2c to high impedance. > Now the mouse should take over the ps2c line and send a falling edge on > ps2c. > But it does not, and ps2c stays '1'. > And thus my state machine infinitely waits for the falling edge. > > Can anyone help me with that ? > > Best Regards > Thorsten >Article: 131939
Hi, Do you know of any particular product that will help to interface between SMA connectors(from an FPGA board) and PCIe lanes (from a PCI Express Switch from PLX). Philip On May 2, 5:48 pm, Kolja Sulimma <ksuli...@googlemail.com> wrote: > There is a development board from PLX where a passive PCIe board > connects the PCIe lanes to coax connectors that interface to an > external board with some PLX parts. > This is out of spec but works even at 5gbps (PCIe 2.0) > > Kolja Sulimma > > On 30 Apr., 15:03, shakith.ferna...@gmail.com wrote: > > > Hi all, > > > Wanted to verify a idea. > > Is is possible use XilinxPCIexpresscore in FPGA to use SMA ports > > for the physical layers rather than the normalPCIexpressslots? > > probably some parameters needs to be modified. > > > Thanks > > > ShakithArticle: 131940
Hi, We have a PC104 board with a spartan2 device. I tried to compile a microblaze system for this device but got the error "not supported for architecture spartan2". I've seen however that in the past this was possible. I'm using EDK9.2. Is the 10.1 supporting this device or is there still some old version lying around somewhere? TacoArticle: 131941
Hi, all, I am trying to make a PowerPC system with dual rank DDR2 on Xilinx ML410 board. When I set 2 banks and different addresses for the 2 banks in the plb_ddr2, some output signals about the DDR2 controler are increased to 2 bit due to the increase of the number of the memory bank (e.g. DDR_CSn_pin). But I can not find information about which I/ O pins I should connect these extra bits. Could anyone give some hints for this? Thank you in advance, louisArticle: 131942
taco schrieb: > Hi, > We have a PC104 board with a spartan2 device. I tried to compile a > microblaze system for this device but got the error "not supported for > architecture spartan2". I've seen however that in the past this was > possible. I'm using EDK9.2. Is the 10.1 supporting this device or is there > still some old version lying around somewhere? > Taco Contact the Xilinx Support, they will give you access to the old software versions. A lot of up-to-date IP cores are not valid for Spartan and VirtexII devices in EDK 9.2. If you enable the access to old/experimental core versions in XPS, you can use them probably with spartan2 -MarkusArticle: 131943
As I need to develop this solution in about 4 months, all the people on the project advice me to use the matlab idea because it's the easiest to have the work done within the deadlines. There are no longer problem with a PC Link because the FPGA boards have a embedded Flash memory where i will be able to save the datas. I still be curious about the lookup table because as I told you I don't have any experience in all that. Do you have any information (links or book references) about this method ? I have at the moment no idea about the memory I will need for all the chirps, so it could be a good solution. Finally, even if it's maybe not the "philosophic" way of doing it, what do you think about storing all the datas we need (different chirps) and just using the FPGA to generate the signal at the speed wanted ? XavierArticle: 131944
Good day! Have: -Quartus 7.2 SP3 -Megacore IP SP2 Need: -PCI Express. But I have only time_limited.sof In Quartus/tools/license Setup/MegaCore functions I see PCI Express. And Quartus give a warinig: using OpenCore Plus Hardvare evalution for a following cores PCI Express Compiler (6A66_00A9) will use OpenCore Plus hardware Evalution It is uncorrect license file? Help!!! I need a crack :)Article: 131945
"BobW" <nimby_NEEDSPAM@roadrunner.com> wrote in message news:q9KdnYE_8uqU2r_VnZ2dnUVZ_hmtnZ2d@giganews.com... > > "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in > message news:o1e424d2h2uldtu4qm4589v667lu96hip8@4ax.com... >> On Wed, 7 May 2008 12:19:40 -0700 (PDT), John_H >> <newsgroup@johnhandwork.com> wrote: >> >>>John Larkin wrote: >>>> >>>> To Lattice: >>>> >>>> We dumped Lattice over buggy compilers and dinky performance. Now that >>>> you're spamming our group, I'll make the ban permanent. >>>> >>>> >>>> To the group: >>>> >>>> Whenever anybody spams us, please >>>> >>>> 1. Blackball them as a vendor >>>> >>>> 2. Say bad things about their companies and products, preferably with >>>> lots of google-searchable keywords. >>>> >>>> John >>> >>>Was this really necessary? >>> >>>If there were technical webcasts from any of the big vendors, I'd like >>>to know about them though preferably more than 8 minutes beforehand. >>>If the posts of this nature got to be more than a couple a month from >>>any one source I'd agree with the spam catagorization but it isn't >>>that frequent. >>> >>>I'm disappointed that you had problems with them in the past and won't >>>trust them for future designs because of your history; competition is >>>almost always good. But is it reason to be publicly vocal? >>> >>>Kill-lists are easy to manage if bart's messages offend you. >>> >>>- John_H >> >> >> If we don't discourage commercial posts, newsgroups will be flooded >> with them. I can't kill-file the tens of thousands of companies who >> would spam newsgroups if they thought it would pay off. So let's make >> sure it *doesn't* pay off. >> >> If they want to advertise, let them pay for it somewhere else. >> >> >> John >> > > For what it's worth, I agree with John. > > It's a real shame that we, now, have to go out of our way to filter > commercial and sexual posts. There are proper places for both of those. > Usenet is not one of them, in my opinion. Come on guys, get over it, really. The heading clearly had "ANNC:" and what it was about clearly stated, so the OP did the right thing. It only takes a split second to scan the header to see if you are interested. If you aren't interested then you shouldn't have even opened it. I'd consider this ON TOPIC and not spam as it was a one-off announcement to the correct groups with the correct formatting. Some people might very well be interested, this is a professional design group with many FPGA designers afer all. Dave.Article: 131946
On May 8, 8:35 am, "David L. Jones" <altz...@gmail.com> wrote: > "BobW" <nimby_NEEDS...@roadrunner.com> wrote in message > > news:q9KdnYE_8uqU2r_VnZ2dnUVZ_hmtnZ2d@giganews.com... > > > > > > > "John Larkin" <jjlar...@highNOTlandTHIStechnologyPART.com> wrote in > > messagenews:o1e424d2h2uldtu4qm4589v667lu96hip8@4ax.com... > >> On Wed, 7 May 2008 12:19:40 -0700 (PDT), John_H > >> <newsgr...@johnhandwork.com> wrote: > > >>>John Larkin wrote: > > >>>> To Lattice: > > >>>> We dumped Lattice over buggy compilers and dinky performance. Now that > >>>> you're spamming our group, I'll make the ban permanent. > > >>>> To the group: > > >>>> Whenever anybody spams us, please > > >>>> 1. Blackball them as a vendor > > >>>> 2. Say bad things about their companies and products, preferably with > >>>> lots of google-searchable keywords. > > >>>> John > > >>>Was this really necessary? > > >>>If there were technical webcasts from any of the big vendors, I'd like > >>>to know about them though preferably more than 8 minutes beforehand. > >>>If the posts of this nature got to be more than a couple a month from > >>>any one source I'd agree with the spam catagorization but it isn't > >>>that frequent. > > >>>I'm disappointed that you had problems with them in the past and won't > >>>trust them for future designs because of your history; competition is > >>>almost always good. But is it reason to be publicly vocal? > > >>>Kill-lists are easy to manage if bart's messages offend you. > > >>>- John_H > > >> If we don't discourage commercial posts, newsgroups will be flooded > >> with them. I can't kill-file the tens of thousands of companies who > >> would spam newsgroups if they thought it would pay off. So let's make > >> sure it *doesn't* pay off. > > >> If they want to advertise, let them pay for it somewhere else. > > >> John > > > For what it's worth, I agree with John. > > > It's a real shame that we, now, have to go out of our way to filter > > commercial and sexual posts. There are proper places for both of those. > > Usenet is not one of them, in my opinion. > > Come on guys, get over it, really. > The heading clearly had "ANNC:" and what it was about clearly stated, so the > OP did the right thing. > It only takes a split second to scan the header to see if you are > interested. If you aren't interested then you shouldn't have even opened it. > I'd consider this ON TOPIC and not spam as it was a one-off announcement to > the correct groups with the correct formatting. > Some people might very well be interested, this is a professional design > group with many FPGA designers afer all. > > Dave. I have to agree with John L on this one. I don't think we should in any way encourage commercial posts here. The issue is quantity. If we are happy with one post, why not 100? There are a couple of groups I visit that have been virtually ruined by advertising. No, it is not on topic advertising, but I don't think that is the point. The quantity is the problem. I can see some groups getting hundreds or thousands of on topic posts a day if all vendors did this. Can you imagine how flooded comp.arch.embedded would be if every maker of MCUs, memory, I/O chips, etc. posted just one message a day? If you like these messages and want to receive them, why not get on the vendor's email list? I'm sure they will only be too happy to directly email you with all sorts of information. Isn't that what opt- in mail lists are for???Article: 131947
axalay pisze: > Good day! > Have: > -Quartus 7.2 SP3 > -Megacore IP SP2 > Need: > -PCI Express. > > But I have only time_limited.sof > In Quartus/tools/license Setup/MegaCore functions I see PCI Express. > > And Quartus give a warinig: > using OpenCore Plus Hardvare evalution for a following cores > PCI Express Compiler (6A66_00A9) will use OpenCore Plus hardware > Evalution > > It is uncorrect license file? Help!!! I need a crack :) > So ,go to dealer :) AdamArticle: 131948
Thorsten Kiefer wrote: > Can anyone help me with that ? Maybe you know this already, but here is an invaluable source of information, that i used for PIC uC : http://www.computer-engineering.org/ps2protocol/ The original page has disappeared but fortunately has been mirrored by countless people. > Best Regards > Thorsten YGArticle: 131949
On May 7, 2:11 pm, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > On Wed, 7 May 2008 10:52:01 -0700 (PDT), bart > > <bart.boro...@latticesemi.com> wrote: > >Lattice is holding a webcast today, Wednesday, May 7th, on our latest > >version of our FPGA software design tools "ispLEVER 7.1 FPGA Design > >Tool Technical Rollout." The presenter will be Troy Scott, from our > >software marketing group. > > >If you're interested, the event takes place live at 11am Pacific, > >18:00 GMT. In addition, you will be able to view this webcast archive > >on-demand, at your convenience, starting a few hours after the live > >event takes place. > > >You can register by clicking: > >http://www.latticesemi.com/corporate/webcasts/isplever7.1fpgadesignto... > > >Bart Borosky, Lattice > > To Lattice: > > We dumped Lattice over buggy compilers and dinky performance. Now that > you're spamming our group, I'll make the ban permanent. > > To the group: > > Whenever anybody spams us, please > > 1. Blackball them as a vendor > > 2. Say bad things about their companies and products, preferably with > lots of google-searchable keywords. > > John I didn't realize that this thread is cross posted to... five different groups. I guess we get to read it more than once as well. I can't exactly blackball Lattice. I just designed in one of their parts because it was almost the only part that would suit all of the requirements. Altera has their new zero power PLDs (it's about time guys) and Xilinx is still stuck in the 90's with their near total lack of Flash based FPGAs. (yeah, I know they have a dual die spartan flash chip, but they blew the packaging). So Lattice may not be perfect, (is anyone?) but I can't blacklist them because they posted to a newsgroup I read. Rick
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