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
> Since you have no signal or module named "done" and I wouldn't expect the > tools to rename your int_done wire, are you sure this code generated the > "error warning" (please specify if it's an error or a warning) that > done.RSTF was minimized to ground? Here are all the warnings generated. If you compile it you will see the same: WARNING:Xst:905 - "vv.v" line 22: The signals <sel> are missing in the sensitivity list of always block. WARNING:Xst:737 - Found 1-bit latch for signal <y>. WARNING:Xst:1355 - Unit mmux is merged (low complexity) WARNING:Cpld:828 - Signal 'int_done.SETF' has been minimized to 'GND'. WARNING:Cpld:310 - Cannot apply TIMESPEC TS1000 = The first one I know how to fix. The 2nd one, I assume it's because of the bus bit associated with it, so ok. 3rd one, stange, but ok, I have no objections. 4th one, SETF, what is that ? Last one, TIMESPEC ? Waiting with anticipation Thanks.Article: 121701
Does anyone know the status of the promised Altera MAX III CPLDs ? These were supposed to roll out early in 2007, but they are now not even registering on any Altera road-maps ? Has Altera pruned plans for this line ? - or has it gone back for 're-work' ? -jgArticle: 121702
On Jul 11, 2:50 pm, Peter Alfke <p...@xilinx.com> wrote: > There is a simple answer: > Click onhttp://www.xilinx.com/ise/logic_design_prod/classics.htm > and get all the old software for FREE. > Sorry to rain on your parade, but you asked for it. > Peter Alfke Sorry to rain your YOUR parade Peter, but you know just as clearly as Austin that Xilinx dropped support for XC4K synthesis and was unable to issue licenses to customers that had current, valid, ISE registrations. That Xilinx failed to provide a replacement for existing license holders in XST, basicly telling them to go to your 3rd party and purchase ANOTHER copy at 5X the price, and that Xilinx would not honor the license it sold in ISE, or provide a replacement in XST. Email at the time, refusing to honor licenses I purchased .... > The license that you would be referring to is the > FPGA express license.dat file. Since FPGA Express was a third party tool this was > the only tool that was licensed. You could actually still use design manager without > this license. I'm sorry to be the barer or bad news but as of April 1st of this year we > can no longer generate or rehost FPGA Express licenses due to legal reasons. Therefor, > I can not provide you with a new license file because we no longer have the mean to > make them. Below is the letter hat we send out to customer who are asking for a new > license for FPGA Express. Please contact Synopsys if you need a compiler that > is compatible with your version of software. > > I hope the above information is of help. Please let me know if you have anymore questions > regarding this issue by the end of the business day tomorrow. > > Very Best regards, > > Shaun Grosser > Xilinx Applications > Phone: 800.255.7778 - option 3 then option 1 - enter your case number > Email: mailto:shaun.grosser@xilinx.com > please ensure email is not sent to <clarify@xilinx.com> - > > Subject: FPGA Software Licensing > > Dear Valued Customer: > Thank you for your continued support of Xilinx products. We want to inform > you that our OEM agreement with Synopsys ends this month. As of March 31, > 2003, Xilinx Inc. will no longer issue FPGA ExpressO re-host or re-issue licenses > to our customers. > > Synopsys offers FPGA Compiler II that is fully backward compatible with FPGA > Express through their direct sales channel. FPGA Compiler II includes retiming > capability to achieve higher clock frequencies and Synopsys DesignWareO support. > If you would like more information on Synopsys FPGA Compiler II or would like to contact > a Synopsys sales representative, please call 800-441-1439, email a Synopsys Sales > Representative at: fpga_sales@synopsys.com <mailto:fpga_sales@synopsys.com> or > visit the Synopsys web site at <http://www.synopsys.com/fpga> > > Once again, thank you for your continued support of Xilinx Products. > Sincerely, > Xilinx Inc.Article: 121703
Jim, I was corrected by Ken Chapman, that to download PicoBlaze, one has to acknowledge they have read and agree to the "use restrictions." Peter and I had a chat about this subject: any IP that is specific to a device (that would be Lattice, Altera, or Xilinx) is optimized for their device, and would be suitably poor in any other technology. So, if you want something that is technology agnostic, you would end up buying something from a 3rd party, and paying them (or your own team) to make different versions of it that are all code and cycle identical, and technology independent (? I am presuming this is possible: it may not be!). So, that is why if I designing an ASIC I buy an 'XYZ' (insert ARM, PPC, MIPS, or whatever you like here) core: I know what I am getting, I can get it for 130nm, 90nm, 65nm, etc.; I can emulate it in an FPGA (if I have to); I can ask questions and get answers. If I want to get the most for my money, I decide whose chip I am going to use, and I use their tools and IP. I "hope" that my c code can be compiled and run on another vendor if I decide I must switch to another vendor (for whatever reason). The one time I had a major project of many uP's on many pcb's, and we changed from Intel to Motorola (gasp!), it was not trivial to port all the code (written in c) from one to the other platform....I wouldn't want to do it today, either. But at least, it was possible, and it could be done (and we did it successfully). As for support of old code: http://www.xilinx.com/ise/logic_design_prod/classics.htm Xilinx offers the last best and debugged version of each code build, for free, to customers who need to maintain an old design. Of course, we can not provide the old Windoze version, but a trip to the Saturday Flea Market at Foothill (or equivalent) will get you all the old Microsquat stuff you want. As well, we no longer have rights to distribute nor support certain old schematic tools, or simulators, but as customers, you have the rights to use the old versions to fix old stuff (they have archives, too). So, be my guest, pick a processor: pick the one that you will get the most use from, be the most efficient to implement in the technology targeted, make the best use of code already written, and will be maintainable for the lifetime of your product lines. AustinArticle: 121704
<miche> wrote in message news:469549e3$1_1@mk-nntp-2.news.uk.tiscali.com... >> Since you have no signal or module named "done" and I wouldn't expect the >> tools to rename your int_done wire, are you sure this code generated the >> "error warning" (please specify if it's an error or a warning) that >> done.RSTF was minimized to ground? > > Here are all the warnings generated. If you compile it you will see the > same: > > WARNING:Xst:905 - "vv.v" line 22: The signals <sel> are missing in the > sensitivity list of always block. > WARNING:Xst:737 - Found 1-bit latch for signal <y>. > WARNING:Xst:1355 - Unit mmux is merged (low complexity) > WARNING:Cpld:828 - Signal 'int_done.SETF' has been minimized to 'GND'. > WARNING:Cpld:310 - Cannot apply TIMESPEC TS1000 = > > The first one I know how to fix. > The 2nd one, I assume it's because of the bus bit associated with it, so > ok. > 3rd one, stange, but ok, I have no objections. > 4th one, SETF, what is that ? > Last one, TIMESPEC ? > > Waiting with anticipation > Thanks. If you fix the problem for y (in mdetect which drives int_done) your int_done warning will probably go away. The SETF is probably a control pin for the latch element that XST was trying to produce for you. As it tried to contort your intent into a latch, I'm guessing it generated a set signal that - in the end - wasn't needed. By the way, I can only compile and get the same results if I have ISE8.2i (of unknown service pack) and know what CPLD family you're targeting. Since I'm up to ISE9.1i+, I won't bother. Good code produces few warnings.Article: 121705
So Austin and Peter, let's just say the Xilinx track record stinks, and you will do or say anything to pump and dump your stock. Xilinx was quick to walk away from existing XC4K customer leaving them high and dry, and HARD obsoleting their current shipping products. So, when Austin is doing this pump and dump crap: > Xilinx recognizes the investment made when choosing a > processor/architecture/language; and has made every effort to follow the >"golden rule": Never obsolete your processor. it certainly didn't recongnize the investment it's customers made in XC4K product, why should we believe they will not walk away from any current product just as easily if they think it will save them a buck. > And, so far, we have never given any customer cause to worry. Open, lie. > There are no plans to (ever) change this policy. It's the existing policy of walking way from XC4K customers when you can save a buck that I'm pretty sure will never change. > Our track record also speaks to keeping this commitment. yep ... no commitment, just the allusion of commitment. > The same can not be said for our competitors. That might actually be true ... they might actually get product support right. AustinArticle: 121706
Totally_Lost wrote: > So Austin and Peter, let's just say the Xilinx track record stinks, > and you will do or say anything to pump and dump your stock. Xilinx > was quick to walk away from existing XC4K customer leaving them high > and dry, and HARD obsoleting their current shipping products. > > So, when Austin is doing this pump and dump crap: > > >>Xilinx recognizes the investment made when choosing a >>processor/architecture/language; and has made every effort to follow the >>"golden rule": Never obsolete your processor. > > > it certainly didn't recongnize the investment it's customers made in > XC4K product, why should we believe they will not walk away from any > current product just as easily if they think it will save them a buck. > > >>And, so far, we have never given any customer cause to worry. > > > Open, lie. > > >>There are no plans to (ever) change this policy. > > > It's the existing policy of walking way from XC4K customers when you > can save a buck that I'm pretty sure will never change. > > >>Our track record also speaks to keeping this commitment. > > > yep ... no commitment, just the allusion of commitment. > > >>The same can not be said for our competitors. > > > That might actually be true ... they might actually get product > support right. > Austin Probably the truth is somewhere in the middle: Austin does tend to spin, and only see the rosy apple, whilst your example focuses very much on the worm. The specific example here was a 3rd party tool flow issue, and quite a long time ago. As a 3rd party issue it is not entirely Xilinx's fault. It even seemed there was a design solution, just no longer free. What we can see since then, is that the bigger FPGA vendors have expanded much of the tool flow in-house, and Xilinx have even done an in-house simulation tool (IIRC?) EOL dead ends are relatively rare (even the example you quote is not a true dead-end, more an annoyance ) - other EDA sectors have more. I'd say a far bigger cost issue in the FPGA sector, is Tool quality, and regression. I can understand their issues - the Silicon changes at a rapid rate, in EDA software terms, so they always have to juggle support for the hot-new-chips, with stability on older devices. Things like the open-source cable drivers, look like a very good move. -jgArticle: 121707
Jim Granville wrote:
> EOL dead ends are relatively rare (even the example you quote is not a
> true dead-end, more an annoyance ) - other EDA sectors have more.
And I expect that few besides Mr. Lost
mourned the passing of fpga express :)
-- Mike Treseler
Article: 121708
Jim Granville wrote:
> Totally_Lost wrote:
>
>> So Austin and Peter, let's just say the Xilinx track record stinks,
>> and you will do or say anything to pump and dump your stock. Xilinx
>> was quick to walk away from existing XC4K customer leaving them high
>> and dry, and HARD obsoleting their current shipping products.
>>
>> So, when Austin is doing this pump and dump crap:
>>
>>
>>> Xilinx recognizes the investment made when choosing a
>>> processor/architecture/language; and has made every effort to follow the
>>> "golden rule": Never obsolete your processor.
>>
>>
>> it certainly didn't recongnize the investment it's customers made in
>> XC4K product, why should we believe they will not walk away from any
>> current product just as easily if they think it will save them a buck.
>>
>>
>>> And, so far, we have never given any customer cause to worry.
>>
>>
>> Open, lie.
>>
>>
>>> There are no plans to (ever) change this policy.
>>
>>
>> It's the existing policy of walking way from XC4K customers when you
>> can save a buck that I'm pretty sure will never change.
>>
>>
>>> Our track record also speaks to keeping this commitment.
>>
>>
>> yep ... no commitment, just the allusion of commitment.
>>
>>
>>> The same can not be said for our competitors.
>>
>>
>> That might actually be true ... they might actually get product
>> support right.
>> Austin
>
> Probably the truth is somewhere in the middle: Austin does tend to
> spin, and only see the rosy apple, whilst your example focuses very much
> on the worm.
>
> The specific example here was a 3rd party tool flow issue, and quite
> a long time ago. As a 3rd party issue it is not entirely Xilinx's fault.
> It even seemed there was a design solution, just no longer free.
>
> What we can see since then, is that the bigger FPGA vendors have
> expanded much of the tool flow in-house, and Xilinx have even
> done an in-house simulation tool (IIRC?)
>
> EOL dead ends are relatively rare (even the example you quote is not a
> true dead-end, more an annoyance ) - other EDA sectors have more.
>
> I'd say a far bigger cost issue in the FPGA sector, is Tool quality,
> and regression. I can understand their issues - the Silicon changes
> at a rapid rate, in EDA software terms, so they always have to juggle
> support for the hot-new-chips, with stability on older devices.
> Things like the open-source cable drivers, look like a very good move.
>
> -jg
Thanks, Jim. I appreciate a well-considered post like this. The
discussion has a familiar, unpleasant ring to it and you've shown it in
a decent perspective.
Oh, and I liked the sleeping bag instructions from Totally_Lost above:
Open, lie.
- John_H :-)
Article: 121709On Jul 11, 5:41 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > The specific example here was a 3rd party tool flow issue, and quite > a long time ago. As a 3rd party issue it is not entirely Xilinx's fault. > It even seemed there was a design solution, just no longer free. The specific issue was ISE and it's synthesis tool, and that Xilinx terminated a 3rd party agreement and went inhouse with XST, failing to provide continutity of synthesis ability for existing registered users of ISE because they didn't want to spend the money to include XC4K support in XST. That was a breach of contract for registered ISE users like myself at the time, as when I asked for a new license, they were unable to deliver an alternate synthesis for the product I purchased when they terminated the 3rd party contract. It's in this specific context that Austin's statements are a clear missrepresentation. That XC4K business decison by Xilinx cost me dearly, almost loosing my home, and business. So when he slams their competitors and states Xilinx has always taken the mornal high ground here, and never caused their customers concern about product support .... let's just agree, that is a lie. The point is, that Xilinx could have included XC4K support in XST, and by choosing not do, caused thousands of Xilinx users (including many students with XC4K student boards and educational ISE licenses) an clear economic loss from the decision removing VHDL/Verilog license availablity or replacement with XST. So, this is not spin (AKA a politically or socially correct lie) ... this is gross missrepresentation by Austin, specifically to place Xilinx competitors at a disadvantage, and misslead new Xilinx customers about their past.Article: 121710
On Jul 11, 5:52 pm, Mike Treseler <mike_trese...@comcast.net> wrote: > Jim Granville wrote: > > EOL dead ends are relatively rare (even the example you quote is not a > > true dead-end, more an annoyance ) - other EDA sectors have more. > > And I expect that few besides Mr. Lost > mourned the passing of fpga express :) > > -- Mike Treseler I expect Mr Tease forgot about thousands of FPGA student boards and ISE educational licenses that became worthless without VHDL/Verilog support in ISE. I know more than a few students that took that hit. From dont@email.me Wed Jul 11 17:51:20 2007 Path: newsdbm02.news.prodigy.net!newsdst02.news.prodigy.net!prodigy.com!newscon02.news.prodigy.net!prodigy.net!news.glorb.com!nntpserver.com!zeus.nntpserver.com!10.1.1.41.MISMATCH!pfilter-v0.1!not-for-mail From: Berk Birand <dont@email.me> Subject: Re: Virtex-II Pro Flip-Flop Setup time Date: Wed, 11 Jul 2007 20:51:20 -0400 User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.) Message-Id: <pan.2007.07.12.00.51.20.480826@email.me> Newsgroups: comp.arch.fpga References: <pan.2007.07.10.16.44.58.878045@email.me> <4695473e$1@clear.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lines: 28 NNTP-Posting-Date: 11 Jul 2007 23:59:19 GMT X-Complaints-To: abuse@teranews.com Xref: prodigy.net comp.arch.fpga:133577 X-Received-Date: Wed, 11 Jul 2007 20:51:52 EDT (newsdbm02.news.prodigy.net) On Thu, 12 Jul 2007 09:12:15 +1200, Jim Granville wrote: > Berk Birand wrote: > Can you be more exact on what 'very short pulses' actually means ? > > If "very short' means 2ns, then you have bigger problems than Tsu. Th :) > > You can design pulse capture latches, that will signal the presence of > a shorter pulse than your sample rate, but you just know 'it happened in > this window', not how narrow it actually was. > > The actual FF-Sample-aperture in a modern FF, is well under 1ns, but the > actual alignment of that varies with process, routing etc Thank your Jim and Matthew for your answers. After a lot of thinking with our project group, we came to the conclusion that setup time wasn't going to be an issue. Since the pulses we have are supposed to be random, we cannot guarantee that they will be synchronized with the clock. So it may violate the setup time, but it turns out that's what we want, since that adds another level of randomness to the problem. By the way the pulses that we are dealing with are indeed shorter than 2ns. Theoretically, they have a mean width of 1ns. Why did you say we would have bigger problems than Tsetup? Thanks again for your answers, Berk -- Posted via a free Usenet account from http://www.teranews.comArticle: 121711
On Jul 11, 6:48 pm, Totally_Lost <air_b...@yahoo.com> wrote: > On Jul 11, 5:52 pm, Mike Treseler <mike_trese...@comcast.net> wrote: > > > Jim Granville wrote: > > > EOL dead ends are relatively rare (even the example you quote is not a > > > true dead-end, more an annoyance ) - other EDA sectors have more. > > > And I expect that few besides Mr. Lost > > mourned the passing of fpga express :) > > > -- Mike Treseler > > I expect Mr Tease forgot about thousands of FPGA student boards and > ISE educational licenses that became worthless without VHDL/Verilog > support in ISE. I know more than a few students that took that hit. And I should also note, thousands of Spartan student boards and products. Just so Xilinx could force their obsolence and jump start it's new product sales following the 2002 down turn off the backs of students and universities. There was probably a few $M in product in the educational market that Xilinx killed, and didn't need to other than to save a few hundred thousand by omitting XC4K/Spartan support from XST. So tell me, why don't those few count?Article: 121712
I think what Austin ment to say was no fortune 100 customer has these problems. (Nobody else counts)Article: 121713
Berk Birand wrote: > On Thu, 12 Jul 2007 09:12:15 +1200, Jim Granville wrote: > > >>Berk Birand wrote: > > >>Can you be more exact on what 'very short pulses' actually means ? >> >>If "very short' means 2ns, then you have bigger problems than Tsu. Th :) >> >>You can design pulse capture latches, that will signal the presence of >>a shorter pulse than your sample rate, but you just know 'it happened in >>this window', not how narrow it actually was. >> >>The actual FF-Sample-aperture in a modern FF, is well under 1ns, but the >>actual alignment of that varies with process, routing etc > > > Thank your Jim and Matthew for your answers. After a lot of thinking with > our project group, we came to the conclusion that setup time wasn't going > to be an issue. Since the pulses we have are supposed to be random, we > cannot guarantee that they will be synchronized with the clock. So it may > violate the setup time, but it turns out that's what we want, since that > adds another level of randomness to the problem. > > By the way the pulses that we are dealing with are indeed shorter than > 2ns. Theoretically, they have a mean width of 1ns. Why did you say we > would have bigger problems than Tsetup? Because you could miss one entirely :) It sounds however, that you are making effectively a sampling oscilloscope, which relies on the signals being repetitive, and not locked ? In that context your width-limit will probably be the pin-buffers low-pass effect, but the edge limit will be better - most likely the system jitter. Actual FF aperture times I'd expect to be less than clock jitter time, which is itself less than the system jitter. You could also use multiple FFs and do some correlation, to see what adjacent channel differences are, There was another recent thread about mixing clock domains in CPLDs, and the jitter effects of that. -jgArticle: 121714
Hello every one,
We have designed a board which
contains an ALTERA fpga and an EPROM(EPC2LC20).The design is done with
respect to some existing reference schematics.We have populated our
PCB so as to get the power to all the components and then we have
placed the components making up the JTAG circuitary along with the
FPGA and EPROM.
,Altera's Byte blaster is being used
which is working fine. have checked all the circuitary which seems to
be alright but we keep getting the error"Unable to access the JTAG
chain".We have also tried the steps in the ALTERAs trouble shooters.
Do we need to proceed in a different
way while programming the chip/EPROM for the first time.And also what
is the passive serial mode in the Quartus tool for programming. Any
help would be highly appreciated.Thanks in advance.
Article: 121715> Peter and I had a chat about this subject: any IP that is specific to a > device (that would be Lattice, Altera, or Xilinx) is optimized for their > device, and would be suitably poor in any other technology. So, if you > want something that is technology agnostic, you would end up buying > something from a 3rd party, and paying them (or your own team) to make > different versions of it that are all code and cycle identical, and > technology independent (? I am presuming this is possible: it may not be!). So what i understand here is that If i want something technology agnostic, i will get it from opencores or develop it myself (my budget is limited). Note that there is usually only a 2%-10% of the overall code that needs to be differentiated across vendors (i'm referring to soft core i'm writing which works for a 2-processor system on an X- FPGA but would work with little work on an A-, L- etc one). I've written a 32-bit 5-stage pipeline RISC core (no coprocessor for exceptions accounted) that maps its brains out on block RAM for all storage (except pipeline registers) and only takes up 35% of the XC3S200 slices and runs at decent speed (~50MHz). It is a great speed given that most parts are written at almost behavioral level (the ALU, PC update logic, branch unit, load-store unit, all this stuff). And i also don't remember the source code line count but should be quite small. Anyway, i stand my ground, the KCPSM2 is beautiful on the XC3S200, 170 to 96 slices make no big difference to me. And it is device-agnostic. Still i can't understand why people are restricted to use X reference designs that are provided AS-IS. > The one time I had a major project of many uP's on many pcb's, and we > changed from Intel to Motorola (gasp!), it was not trivial to port all > the code (written in c) from one to the other platform....I wouldn't > want to do it today, either. But at least, it was possible, and it > could be done (and we did it successfully). This is different to changing implementation medium for a given soft core. This is not a proper example if you refer to what i understand. Nikolaos KavvadiasArticle: 121716
Hi Xilinx Killers, It is really annoying to rename and group all the signals everytime when design is modified and new bit file is used to configure the fpga. Anybody knows how to avoid renaming and regrouping signals in the analyzer when new bit file is loaded to FPGA? And one more quick question, how to investigate state_reg of a FSM by using chipscope? Because the original name of the interesting state_reg is modified after synthesis, I dont't know which signal I should investigate now. For Altera signaltapII, it is very easy to use for on-chip debugging. And it is very easy to learn too. Miss those days when using Quartus. Thanks in advance for your input, SicsArticle: 121717
mailsatishv@gmail.com wrote:
> Hello every one,
> We have designed a board which
> contains an ALTERA fpga and an EPROM(EPC2LC20).The design is done with
> respect to some existing reference schematics.We have populated our
> PCB so as to get the power to all the components and then we have
> placed the components making up the JTAG circuitary along with the
> FPGA and EPROM.
> ,Altera's Byte blaster is being used
> which is working fine. have checked all the circuitary which seems to
> be alright but we keep getting the error"Unable to access the JTAG
> chain".We have also tried the steps in the ALTERAs trouble shooters.
> Do we need to proceed in a different
> way while programming the chip/EPROM for the first time.And also what
> is the passive serial mode in the Quartus tool for programming. Any
> help would be highly appreciated.Thanks in advance.
Hello.. Satish?
Please tell us what voltage your
FPGA's JTAG port is configured for. Does your Byte Blaster have a
voltage range that's compatible with this chain? The programmers have
been around in various forms for ages; if you're using an old
programmer, it may not be compatible (or may require special tweaks) to
interface properly.
,As far as programming using the
passive serial mode, have you read up on the (most probably) abundant
literature that focuses explicitly on configuration? Because *all*
designs need to be configured, *all* the engineers need to understand
how to work in their mode.
Do you have more than just the Altera
FPGA and EPROM on board? Do you have a processor that can store the
configuration file and bit-bang some FPGA pins through the processor
GPIO? If so, you have all the access you need for the passive serial
configuration; it's just a matter of reading up on how to do what when.
Good luck,
- John_H
Article: 121718I posted last year about a strange problem I was having with a Flex 10K100 board. At one time, I figured out how to setup programming files so that the EPC2 would correctly configure the FPGA. Apparently, I should have written that down more than once, because I have lost the secret sauce. I recently made a modification to the design, and tested it by directly JTAG loading the FPGA. Everything works great, I have a design that makes timing, and it works correctly when downloaded to the FPGA directly (using the .sof) file.The trouble comes when I try to load the design into the configuration PROM. The board has a single EPF10K100GC503-3 FPGA (yes, an old-school part), and an EPC2. The configuration logic is modeled on the Altera app note exactly. I can also program the EPC2, and verify the contents, correctly. (I can verify, and extract, successfully) However; when I cycle power, the LED's just come on and randomly flicker out, with no relationship to the clock (I suspect capacitive effects, since I'm driving the LED's through a buffer-driver chip) I am using the INIT_DONE output in the design, but it's pretty apparent that the design isn't getting loaded properly. Now, I know the EPC2 isn't bad, nor is the board design. I have a .pof file that I extracted from the device that correctly configures the board. (starts up reliably every time) Given all this, I know it's a configuration problem - but for the life of me, I can't remember what I did the last time to get this thing going. What have I forgotten to set in Quartus? Note, I'm using Quartus II 6.0 SP1 (webpack). Thanks! -SethArticle: 121719
On Thu, 12 Jul 2007 04:03:36 -0000, Yao Sics <yao.sics@gmail.com> wrote: >Hi Xilinx Killers, > >It is really annoying to rename and group all the signals everytime >when design is modified and new bit file is used to configure the >fpga. Anybody knows how to avoid renaming and regrouping signals in >the analyzer when new bit file is loaded to FPGA? Take a look at .cdc files (they are importd or exported from Chipscope) They contain a list of signals and aliases that you may create/edit with a text editor. Thus, you may maintain your signal list with a text editor and import it after connecting the CipScope analyzer > >And one more quick question, how to investigate state_reg of a FSM by >using chipscope? Because the original name of the interesting >state_reg is modified after synthesis, I dont't know which signal I >should investigate now. You shoulld create some intermediate signal that translates your FSM states into some binary code you may read with the ChipScope. I never found any other way, but this one works nice. ZaraArticle: 121720
Hi Zara, Thank you for your input. It helps a lot. Have a nice day, Sics On Jul 12, 1:31 pm, Zara <me_z...@dea.spamcon.org> wrote: > On Thu, 12 Jul 2007 04:03:36 -0000, Yao Sics <yao.s...@gmail.com> > wrote: > > >Hi Xilinx Killers, > > >It is really annoying to rename and group all the signals everytime > >when design is modified and new bit file is used to configure the > >fpga. Anybody knows how to avoid renaming and regrouping signals in > >the analyzer when new bit file is loaded to FPGA? > > Take a look at .cdc files (they are importd or exported from > Chipscope) They contain a list of signals and aliases that you may > create/edit with a text editor. Thus, you may maintain your signal > list with a text editor and import it after connecting the CipScope > analyzer > > > > >And one more quick question, how to investigate state_reg of a FSM by > >using chipscope? Because the original name of the interesting > >state_reg is modified after synthesis, I dont't know which signal I > >should investigate now. > > You shoulld create some intermediate signal that translates your FSM > states into some binary code you may read with the ChipScope. I never > found any other way, but this one works nice. > > ZaraArticle: 121721
On 2007-07-12, Zara <me_zara@dea.spamcon.org> wrote: > > Take a look at .cdc files (they are importd or exported from > Chipscope) They contain a list of signals and aliases that you may > create/edit with a text editor. But how do you name busses? Naming signals is easy... -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 121722
On 2007-07-12, radarman <jshamlet@gmail.com> wrote: > I posted last year about a strange problem I was having with a Flex > 10K100 board. At one time, I figured out how to setup programming > files so that the EPC2 would correctly configure the FPGA. Apparently, > I should have written that down more than once, because I have lost > the secret sauce. I just made a FLEX 6000 board (still more obsolete, mainly to test out geda/pcb). I looked into putting a config device down, but decided not to considering the rest of the board could be made with junkbox parts. So I have just been reading the old docs, but I have not actually tried to make it work. I suspect what's wrong in your case is the setting of the special options that go with the old EPC1/2-era config devices. When you program them, you have to set bits that set the voltage and other features of the chip. I think if you drill down into Assignments|Settings|Device| Device and Pin Options you'll see some of what you need. You have to set up the CLKUSR, INIT_DONE support under 'General' and also set up all the 'Dual-Purpose Pins' as well as go to Configuration and set the 'Configuration Device Options' for the EPC2. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 121723
On Jul 11, 10:27 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Does anyone know the status of the promised Altera MAX III CPLDs ? > These were supposed to roll out early in 2007, but they are > now not even registering on any Altera road-maps ? > Has Altera pruned plans for this line ? - or has it gone back for > 're-work' ? > -jg Actually Altera's statement was that C-3 comes first (before APR07), then S-3 and M-3 as last one..So it really looks like this schedule. Also the status of M-3 was never firmly confirmed, so maybe it is even cancelled what would be a pity of course. surprisingly the current low cost leader is: A3P060 - it kills all "cross-over FPGA-CPLD" machXO-MAX-II A3/IGLOO 030 devices are not yet shipping, but when they will they should kill every CPLD above 64/72 macrocell as well. (price wise at least) but I also hope MAX-III comes, with nice packages and single voltage option, and user flash mem, and... anttiArticle: 121724
Jarek There are a number of companies doing development boards like ourselves that will ship to Poland. Being in the EEC should mean there are no duties if you are shipped for another EEC country. John Adair Enterpoint Ltd. www.enterpoint.co.uk On 9 Jul, 21:00, Jarek Rozanski <jarek.rozan...@gmail.com> wrote: > On Jul 9, 6:59 pm, Nial Stewart <n...@nialstewartdevelopments.co.uk> > wrote: > > > > > > > Jarek Rozanski wrote: > > > Hi, > > > > Does anyone have experience with Altium LiveDesign (Xilinx Spartan-3 > > > XC3S1000) ? How does it perform with ISE WebPack, are there any odd > > > issues with it? Any comment will be appreciated. > > > > I would like to use it for my CPU project. Size of FPGA is more than I > > > need currently but I don't mind getting bigger device :) > > > The Altium tools are all very well in principle, but as soon as you start > > working out of their box things can get difficult. > > > I presume their IP should plug and play as advertised, but as soon as you > > design some custom logic of your own it's a different ball game. > > If you get timing/routing/constraint problems you're going to have to > > dig into the Altera/Xilinx tools that are running in the background. > > > IMHO. > > > Nial. > > I intend to use only ISE WebPack. Altium tools are of no interest for > me, only the spartan board. I am interested in this starter kit, > because it is well priced and moreover there are not many alternatives > on Polish market.- Hide quoted text - > > - Show quoted text -
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